Google 推出網頁註解新功能~~
但我覺得這根本就是網頁推文~~ Orz
參考來源："Google 網頁註解"
- Google 網頁註解 (在「Google 網頁註解」中檢視)
星期二, 九月 29, 2009
星期一, 八月 31, 2009
[tips] get your IP address
wget -qO- http://ipwhats.appspot.com/
or just point your browser to http://ipwhats.appspot.com/
星期一, 八月 17, 2009
[tips] sphinx支持中文pdf的方法
目前 python 官方文件使用的sphinx是個不錯的文件產生系統,
可以同時由rst產生html,latex,pdf,ps等文件格式,
不過我目前試的結果似乎預設從latex產生pdf時沒有支援中文,
網路上相關的文件大都寫得很複雜,
但其實只要在文件project裡的source/conf.py加入
latex_preamble = '''\usepackage{CJKutf8}\n\AtBeginDocument{\\begin{CJK}{UTF8}{bsmi}}\n\AtEndDocument{\end{CJK}}'''
其他都不需更改,
以後make latex; cd build/latex; make all-pdf 就都可以產生出正確的
中文pdf檔了
測試環境是Gentoo linux底下的texlive 2008 (cjk) + pdflatex
星期四, 八月 13, 2009
[tips] linux裡 emacs23 utf8 中文輸入與SCIM
最近新昇到emacs 23.1
又發現SCIM中文輸入有問題, ctrl+space老是變回mark.
我的locale是zh_TW.UTF-8
其他程式輸入中文都沒啥問題
就emacs23.1無法輸入中文,
試了老半天 (暫時)解決方法如下:
啟動emacs時用 LC_CTYPE="zh_CN" emacs-23
.emacs 加上這行
(prefer-coding-system 'utf-8)
這樣就沒問題了
至於為什麼要如此我也不能理解
如果有高人肯告訴我那就再好不過了,
不過我暫時懶得去追了, 設個alias也就算了.
總之locale裡似乎只有zh_CN跟zh_CN.gbk會動.
btw,我的環境是gentoo linux.
註: 這個問題 基本上只在terminal上使用emacs -nw的使用者應該不會遇到.
星期三, 七月 29, 2009
[talk] 高雄世運結束了~~
上個禮拜起一直跑來跑去,
從世運主場館, 高雄巨蛋, 高雄縣立體育場甚至連義守大學都去了,
為了就是去看現場的世運比賽,
雖然說世運大部份都不是熱門的運動, 但是卻意外的非常好看,
特別是飛盤這項運動, 現場看起來真是特別有趣,
從後場可以直接丟到前場, 從右路可以像香蕉球一樣轉彎到左路,
這是看電視完全沒辦法欣賞到的~ 這門票實在花的很值得~~
這次唯一的遺憾就是我雖然買了開幕門票, 卻被國家抓去教育召集,
沒辦法看海莉現場了~~ 不過感謝至少MOD還有網路有一大堆影片可看
順道附上我滿喜歡的海莉的歌 Wuthering Heights:
Kate Bush的原唱
星期一, 七月 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
訂閱：
文章 (Atom)
