星期一, 七月 06, 2009

HTML 5

firefox 3.5日前已經release了
最重要的一個新功能我認為是原生支援了HTML 5的Video tag,
也就是未來的瀏覽器不再需要flash就可以直接播放ogg Theora/Vorbis編碼的影片。

測試的方法:

1. 首先先用youtube-dl這隻程式隨便抓一個youtube的flv檔案下來
http://bitbucket.org/rg3/youtube-dl/

2. 透過ffmpeg2theora將flv轉成ogg
http://www.v2v.cc/~j/ffmpeg2theora/index.html

3. 寫一個html檔

<html>
<body>

html5 video test!

<div>
<video controls source src="sample2.ogg" type="video/ogg;codecs=theora,vorbis" autoplay >
your browser does not support the video tag

</video>
</div>

</body>
</html>


網路上也有其他人做了一些fallback to flash/java applet player的方法, 例如這個 http://www.dailymotion.com/openvideodemo 還有一隻 firefox的plugin firefogg http://firefogg.org/ 可以直接在firefox將影片即時編碼+mux成Theora/Vorbis ogg格式後再上傳。

星期四, 七月 02, 2009

想要變成艾托畢利卡的企鵝? 誤會大了~~

話說最近在迷GONZO的 咲-Saki- (台譯: 天才麻將少女)

女主角中的原村和在高中麻將大賽中帶著一隻企鵝抱枕打麻將,

沉醉於麻將中臉色微紅的樣子真是萌啊~~

企鵝其實不是第一次出現在秋葉原系動畫中了,

在動畫IdolM@ster中,

女主角天海春香的房間就貼有最喜歡的Gentoo Penguin (ジェンツーペンギン) 的海報~~

春香的電腦桌布跟手機也都是企鵝~~

不過Gentoo Penguin (巴布亞企鵝) 因為名稱跟我使用的Linux Distribution同名 所以很清楚這企鵝的樣子

但是, 從第一次看到就很好奇~~ 咲-Saki-的原村和抱著的這隻エトペン (艾托企鵝) 到底是什麼 ?



在東立出版的天才麻將少女漫畫中,

原村和睡醒時對當時正在說夢話的Saki說

艾托企鵝是這本"想要變成艾托畢利卡的企鵝" (エトピリカになりたかったペンギン)繪本的主角

但是, 疑問又來了 艾托畢利卡又是什麼??? 聽起來像是某個偉人或是繪本中其他角色的名字

企鵝有什麼不好~~ 為什麼好端端的企鵝不當~~ 要去當什麼艾托畢利卡呢???

經不起好奇心的引誘~~ 不禁google了起來~~

"エトピリカになりたかったペンギン"

這個時候就發現懂一點日文真不錯~ 透過google跟日文維基 查到了

艾托畢利卡 --> エトピリカ --> 花魁鳥 (エトピリカ)



恍然大悟!

原來是想要變成花魁鳥的企鵝啊~~~

什麼想要變成艾托畢利卡的企鵝? 誤會大了~~ XDXD

註: エトピリカになりたかったペンギン繪本是漫畫虛構杜撰的~~ 現實世界中並沒有這部作品~~

星期五, 五月 22, 2009

[tips] benq FP222WH + nvidia 達到原生解析度1680x1050的方法

最近辦公室的電腦換了一張nvidia 9400的顯示卡,
可是搭配上benq FP222WH ,
解析度怎麼調最大都只有640x480, (各種方法都試過了)
後來總算讓我查出是EDID的問題,
原本舊版的nvidia driver有一招是在xorg.conf設定
"IgnoreEDID" "true",
不過我新版的180.51 driver根本不適用這個方法,
後來我研究了快一天,
不過最後研究出來的解決方法倒是很簡單,
放在這提供有需要的人參考,
首先我先去抄ATI顯卡列出的EDID,
然後將它做成一個128 byte 的EDID
HEX file, 我已經做好了所以直接抓這個檔案擺在/etc/x11就可以

http://kalug.linux.org.tw/~tim/benq/benq-c.bin

然後在你的xorg.conf裡加上幾行,
(請自行比對xorg.conf的相異處)

Section "Monitor"

Identifier "Monitor0"
VendorName "Monitor Vendor"
ModelName "Monitor Model"
HorizSync 30.0 - 86.0
VertRefresh 60.0

# 1680x1050 @ 60.00 Hz (GTF) hsync: 65.22 kHz; pclk: 147.14 MHz
Modeline "1680x1050_60.00" 147.14 1680 1784 1968 2256 1050 1051 1054 1087 -HSync +Vsync

EndSection

Section "Screen"
Identifier "Screen0"
Device "Card0"
Monitor "Monitor0"

Option "ConnectedMonitor" "DFP"
Option "CustomEDID" "DFP-0:/etc/X11/benq-c.bin"
Option "UseDisplayDevice" "DFP" # DVI out

SubSection "Display"
Viewport 0 0
EndSubSection
EndSection

我的是DVI接頭,
另外一個同事用的是DSUB(VGA) 的,
他說只要DFP改成CRT也可以用,
我們一個是用debian一個是用gentoo,
在預設情形下解析度都是錯誤的,
但是透過這個方法就可以達到原生解析度1680x1050. :)

星期一, 五月 04, 2009

[rant] igoogle gmail gadget: The Gmail gadget does not support the "Always use https"

最近我經常使用的igoogle gmail gadget突然出現:

The Gmail gadget does not support the "Always use https" setting that you chose in full Gmail. If you would like to use https, please open full Gmail. Learn more


問題是我一直以來Always https都是用得好好的啊,怎麼突然就出問題了,
我點下Learn more之後出現了標準的廢話連篇又毫無用處的典型答非所問的問答集:


Google 說明 › Gmail 說明 › 您的帳戶 › 隱私權與安全性 › 啟用 HTTPS 設定
啟用 HTTPS 設定
-「Gmail 通知器」使用者必須下載相關修補程式,才能使用這個設定。 瞭解更多資訊
- 啟用此設定可能會使 Gmail 行動版應用程式發生錯誤。 瞭解更多資訊

透過不安全的網際網路連線 (例如公用無線網路或未加密的網路) 登入 Gmail 時,可能會讓人可輕易盜用您的 Google 帳戶。在不安全的網路中,他人很容易偽裝成您,並取得您「Google 帳戶」的完整存取權,藉以存取您帳戶中的機密資料,例如銀行帳戶資料或線上登入憑證。您使用有安全疑慮的網路時,建議您在 Gmail 中選取 [永遠使用 https] 選項。 HTTPS (亦稱「超文字安全傳輸通訊協定」) 安全通訊協定會將通訊內容加以驗證及加密。

在 Gmail 中啟用這個功能:

1. 登入 Gmail。
2. 按一下任何 Gmail 頁面頂端的 [設定]。
3. 將 [瀏覽器連線] 設定為 [永遠使用 https]。
4. 按一下 [儲存變更]。
5. 重新載入 Gmail。

請注意,選取 [永遠使用 https] 後,您將無法透過 HTTP (超文字傳輸通訊協定) 存取 Gmail, 且 Gmail 的運作速度可能會變慢。 如果您使用的網路安全無虞,可以隨時關閉這個功能。

如果您使用公用電腦查看電子郵件,請務必在要關閉 Gmail 時,按一下任何 Gmail 頁面頂端的 [登出],並關閉所有 Gmail 瀏覽器視窗。


廢話,騙小孩唷,算了 自己搜尋一下看看是甚麼情形,看了一堆抱怨串之後找到始作俑者:

http://www.google.com/support/forum/p/Web+Search/thread?tid=41f74befcd5f3d28&hl=en&fid=41f74befcd5f3d28000468c96d31ef91

Paul
Google Employee

Hi everyone,

As several of you have noticed, we made a change in iGoogle to the way that iGoogle's Gmail gadget works. If you previously set Gmail to only access your mail using https by selecting "Always use https" in Gmail's settings, you will now see a message in iGoogle's Gmail gadget asking you to open the full version of Gmail. We made this change in iGoogle for those users who want to ensure that their Gmail is transmitted using https.

We know that many of you would like to access your mail from iGoogle with https, and we're investigating ways to provide https support for iGoogle's Gmail gadget. In the meantime, you have a couple of choices:

- If you'd prefer to access your mail with https, please visit Gmail directly at https://mail.google.com/mail.
- If you'd rather get your Gmail on iGoogle with the Gmail gadget, visit Gmail's Settings page and select "Don't always use https."

We apologize for any inconvenience this may have caused.

只是覺得很奇怪,他不會功能做好再來給我改嗎?
原本的code跑得好好的
現在突然爛了又講一堆廢話,還要自己搜尋才找的到,Orz!

===

這真是一個可以拿去給RMS當反面宣傳的例子,
為啥我們應該要拒絕使用close source的web application... 
就算是把"Don't be evil"掛在嘴邊的google也一樣...

-- 因為一個用了一兩年的功能還是可以突然停掉並且都不用事先公告的。

ref 來自gmail gadget八百五十萬使用者的抱怨串:

http://www.google.com/support/forum/p/gmail/thread?tid=41eb24edefcd7a41&hl=en
http://www.google.com/support/forum/p/Web+Search/thread?tid=41f74befcd5f3d28&hl=en
http://groups.google.com.tw/group/Google-Desktop_Something-Broken/browse_thread/thread/71dd8b27ccacc0ba

[Note] 送patch所學到的事

這個Note是一個寫patch的經驗,前陣子寫了一個讓curl即時壓縮加密FTP/HTTP/SFTP上傳時可以續傳的一個patch,patch本身倒是沒什麼特別的,反而是在送patch跟原作者的討論過程中學到了一些東西。patch歷時約一個月才commit進cvs,不過我覺得以open source的專案來說,這樣算挺快的。

似乎還是得把前因後果交代一下,
其實一開始是我有一個想法,
就是希望我上傳到遠端伺服器的檔案都能加密起來(順便壓縮更好),
但是我覺得在local這邊先壓縮過然後再上傳的話,就會佔Local的硬碟兩份空間,所以最好的方法是realtime壓縮加密之後上傳。這樣就不會佔用local的硬碟空間,而以目前的CPU也應該都可以做到即時傳輸。
此外我希望就是能夠彈性的選擇壓縮及加密方式,不論是bz2,gzip,pkzip或是pgp及AES都要能夠自行選擇及combine。
而且最好是不需另外的伺服器程式,以目前hosting都會提供的FTP帳號就能做的方法是最好。(我需要的不是像SFTP或FTP/TLS這樣傳輸時加密或壓縮而已,我想要的是在伺服器上的最終結果也是加密及壓縮過的)

跟lloyd討論之後,他是認為lftp+namepipe的方式可行。
另外我也找到了用pipe透過curl上傳的方法。
而這兩個方法也都驗證過確實可行,不過這兩個方法都同樣有個問題,就是沒辦法續傳,而這我認為是個應該要解決的問題。

比較了兩個解決方案後,我選擇了擁有我比較喜歡的BSD license,用法也比較彈性的curl下手修改,
curl的續傳問題大概長這樣:

gzip /mnt/2311/debian-500-i386-CD-1.iso -c | curl -T - -C -
ftp://myname:mypass@192.168.23.11/debian-500-i386-CD-1.iso.gz
** Resuming transfer from byte position 46792704
% Total % Received % Xferd Average Speed Time Time Time
% Current
Dload Upload Total Spent Left
Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:--
0
curl: (31) Could not seek stream

最主要是stdin不能直接SEEK_SET,這其實不是什麼大問題,不能SEEK_SET就SEQUENCIAL READ並bypass即可,看了一下原始程式便發現其實這段code早已大部完成了,只要略為更動即可,
於是略為修改了一下curl FTP/SFTP/HTTP上傳部份的code,驗證之後便將patch送出。
原以為送出patch之後就結束了,因為作者要收不收這也不是我能控制的,不過後來curl的作者回信說,功能是沒有問題,但原本的patch會影響到ABI與目前文件的相容性,問看看我是否能提供不修改ABI的作法,我原本還無法理會作者的意思,後來繼續討論才慢慢了解,作者的意思是看能否提供完整的ABI及定義回傳值供其他使用curl library部份的程式參考,因為curl不僅僅是一個客戶端程式curl,同時也包含一套廣泛的運用在其他程式甚至內建在程式語言中的library,libcurl。即使是改動小小的部份,也有可能不經意的影響到其他重要的程式。
了解了作者的目的之後,於是我又寫一個新的patch配合這個架構,測試一下續傳上傳沒問題之後就又再次的送出,這次作者將我的多個patch檔結合後又修改了一下包括說明文件的patch就直接commit到cvs上,不過問題來了,做make test的測試到HTTP PUT該項時沒過。
仔細的研究一下,還真的是第二次更動的code造成了問題。第三次的修改並驗證之後,這次就很快的patch就被接受了,目前已經commit在curl的cvs上。

這次寫patch得到一些經驗:

1. 寫patch時應配合原程式的架構及style,會比較容易被接受。
2. 寫完patch之後應照原程式的測試方式做一遍測試,而非只是測試自己的情況。
3. 大部份時候都要仔細考慮並聆聽來自原作者的意見,畢竟他是最清楚全部情況的人。
4. 不要懶的送patch,雖然可能會多費一些時間跟功夫,但送了patch通常可以學到更多。

ref: 我和curl作者討論的過程,https://sourceforge.net/tracker/?func=detail&atid=100976&aid=2709004&group_id=976

星期四, 四月 02, 2009

[tips] ssh login without password using ssh-copy-id script

應該早點知道有這種懶人script存在的
而且還是裝完openssh就有的
(.ssh/authorized_keys,這是啥難記的檔名 @@)

現在只要

ssh-copy-id -i id_dsa.pub username@host

做完就好了 orz

星期二, 三月 17, 2009

[tips] crc32 in python

python 2.X的crc32實作上跟一般的C實作上在整數有號無號的處理上略有不同, 所以使用python 2.X與一般C實作算出的crc32(如sfv)比對時,通常需要特別的方法,

這邊列出一個透過zlib.crc32快速得到所需要結果的方法:

import zlib

def crc32(st):
crc = zlib.crc32(st)
if crc > 0:
return "%x" % (crc)
else:
return "%x" % (~crc ^ 0xffffffff)

ex1 = "12345"
ex2 = "1kcaseztsa12345azy"

print "%x" % zlib.crc32(ex1)
print crc32(ex1)
print "%x" % zlib.crc32(ex2)
print crc32(ex2)


或如果你有ctypes的話:
import zlib
import ctypes

def crc32_c(st):
return "%x" % ctypes.c_uint32(zlib.crc32(st)).value

ex1 = "12345"
ex2 = "1kcaseztsa12345azy"

print "%x" % zlib.crc32(ex1)
print crc32_c(ex1)
print "%x" % zlib.crc32(ex2)
print crc32_c(ex2)



註: python 3.0以上沒有這個問題.

星期三, 三月 04, 2009

微軟: HideTaiwan()

http://msdn.microsoft.com/en-us/library/ms441219.aspx

SPUtility.HideTaiwan Method (Microsoft.SharePoint.Utilities)

Dim spWeb As SPWeb
Dim localeId As Integer
Dim returnValue As Boolean

returnValue = SPUtility.HideTaiwan(spWeb, localeId)

Parameters

spWeb

An SPWeb object that specifies the Web site.

localeId

A 32-bit integer that specifies a locale ID.


Return Value
true if the Taiwan calendar is hidden; otherwise, false. By default, this method returns true and the Taiwan calendar cannot be displayed for the following SPLangId values: PeoplesRepublicofChina, HongKongSAR, and MacaoSAR.

不小心逛到這個

微軟真強 連台灣都可以Hide() ...

星期一, 三月 02, 2009

不縮排就搗蛋!

louis今天跟我討論XPCOM文件上這一段應該是要很簡單的C++ snippet,

基本上我XPCOM不熟, C++尚可,

拿來文件上的Code大概長的像這樣:

NS_IMETHODIMP SampleFactory::QueryInterface(const nsIID &aIID,void **aResult)
{
if (aResult == NULL) {
return NS_ERROR_NULL_POINTER;
}
*aResult = NULL;
if (aIID.Equals(kISupportsIID)) {
*aResult = (void *) this;
}
else
if (aIID.Equals(kIFactoryIID)) {
*aResult = (void *) this;
}
if (aResult != NULL) {
return NS_ERROR_NO_INTERFACE;
}
AddRef();
return NS_OK;
}



看來看去實在是讓我皺眉頭...

哪有aResult等於NULL也return

不等於NULL也return

然後return完後面還有code的道理

反正這code看起來就是怪怪的, 但一下子卻看不出怪在哪...

因為...

...

這沒縮排又排的亂七八糟的code我是要怎麼讀啦!!!???

...

反正就是看的很難過 有股想把code拿去倒掉的衝動

後來才發現真正的文件裡長的是這樣:

NS_IMETHODIMP
SampleFactory::QueryInterface(const nsIID &aIID,
void **aResult)
{
if (aResult == NULL) {
return NS_ERROR_NULL_POINTER;
}
*aResult = NULL;
if (aIID.Equals(kISupportsIID)) {
*aResult = (void *) this;
}
else if (aIID.Equals(kIFactoryIID)) {
*aResult = (void *) this;
}

if (*aResult == NULL) {
return NS_ERROR_NO_INTERFACE;
}
AddRef();
return NS_OK;
}



我咧 這一縮排 會不會感覺差太多

連這段code snippet不用註解 要表達什麼都能看的清清楚楚.

雖然我不是很熟XPCOM, 也清楚看的出:

1. 在aIID是SupportsIID或FactoryIID的情況下

*aResult不會是NULL 而如果不是SupportsIID或FactoryIID就該回傳NS_ERROR_NO_INTERFACE;

2. 原先的code把倒數第六行if (*aResult == NULL)誤值成if (aResult == NULL) 是錯的...

跟之前不知在寫什麼時不同, 馬上就看出問題點在哪...

==

我還是常聽到有人說什麼python強制縮排怎樣怎樣的...

我只想說,

人要衣裝

佛要金裝

Code要給我排整齊啦!

星期三, 二月 25, 2009

Upgrade to KDE 4.2

上次升級4.0.5的KDE其實印象很不好,
不斷的crash之外 另外登入成功後也無法正確logout,
種種的問題又讓我退回使用3.5.x,
不過這次升級到KDE 4.2.0,
使用到目前為止其實還算順暢,
除了少數plasma的applet無法正確啟動外, 使用感覺還算良好.

我的平台是gentoo linux, 大部份套件是穩定版本的,
所以升級還在測試中的KDE4.2 , 其實有遇到幾個小困難:

1. 我原本的gcc版本是在gentoo裡被列為stable的gcc 4.1.2, 但在編譯kde-base/systemsettings時遇到困難, 老是有函式找不到, 最後參考網路上的作法 換至gcc 4.3.3後就一切順利. (真是詭異的作法)

2. plasma老是啟動時crash, 還是只能參考網路上的說法, 將穩定版的 qt 4.4.2換至qt 4.5.0rc1, 就解決了這個問題.

因為遇到這兩個套件需換至測試版本, 另外就是我也很久沒更新了, 所以emerge world居然重編了一千多個套件, 老實講distcc沒有那麼有用(據說我們公司裡有一個distcc陣列 :P 不過還是直接換硬碟到build server上會比較快啊 !), 因為configure的時間其實很長, 最後還是借了一台雙核E8400的電腦來build, 不然實在是太累人了.

KDE 4.2的穩定度大約是4.0左右的水準吧, 用到現在仍然沒有crash, 用起來的感覺也還不錯, 就是可能現在還不是安裝的最佳時機,有些AP用起來也可能還有問題, 如果對KDE的程式有重度需求可以再等等.