Fred's blog

台灣不下雪，總是沒有一片銀白色的雪景，也沒有對『聖誕』的感恩，但是大家卻仍然陶醉在這幻想之中的節日，每個人心中常夢想那雪飄和著歡樂的鈴聲，哪怕一切風寒刺骨，人們手心的溫度更暖暖沉沉，緊握著幸福的紅色鑰匙，期待打開綠葉下的繽紛禮物。殊不知，老天正在嘲笑，祂在這天換去了憂鬱的藍色，重新粉刷了灰白顏色，然而，天空偶爾飄下來的不是雪花，卻是扎人的雨針。 若不下雪，怎麼會有朦朧的浪漫和雪中耀眼的火光？又怎會有互相取暖的擁抱？若心中不下雪，沒有冰冷寒凍，又怎能感受到自身原始的溫度？又如何去得到耶誕節的恩賜，與人們活下去的熱情？ 下的是針，千根萬根的雨針，人們用雙手擋著天上的刺矛，自顧不暇的分東離西，卻哪還有一起握住幸福的手掌？ 諷刺，真是諷刺！灰色耶誕節讓一切現出了原形，原本的白色暖流去了哪裡？又是誰，心裡仍在下著雪？ 回到現實，火鍋才能幫助人類取暖！吃得好飽！

目前，無論是 Linux Kernel 內的 PenMount Touchscreen Module 或是 Xorg 下的 Driver，都無法支援新版的 PenMount 6000，在官方網站上也只有提供 Xorg 的 binary driver，而且並未開放原始碼。日前因某些案子需要在 kdrive 上驅動 PenMount 6000，就自行 Hack 並寫了一支粗糙的 Driver。由於在 kdrive 上的 touchscreen solution 都是藉由 tslib 來實作，所以這支 driver 是一個 tslib 的 plugin。 一個意外發現，kdrive 底下的 Xvesa 並未支援 tslib，所以就算在 configure 下 enable tslib，雖然相關的 function 會被編進去，但卻不會真正被註冊在 driver list 上。對此，也在這寫了一個小 patch 以解決這問題。 驅動程式原始碼和 Xvesa patch 可在這取得： http://people.linux.org.tw/~fred/drivers/pm6000_tslib.tgz 將編好的 pm6000.so 放到 plugin 指定目錄後，然後再將 tslib config file 的 module_raw 設定成 pm6000，就可直接用下列方法使 Xvesa 驅動 PenMount 6000 Touchscreen： Xvesa -mouse tslib,,device=/dev/input/eventX

身為一個觀察者，可以無情的看著目標，總能用最理性的視野，注目著眼前的渺小微物。當局者迷，正好反過來描述了觀察者之不迷。被觀察者，卻總是用最直觀的方式面對當前的狀況，喜怒哀樂表於臉上，往往想不開也想不透。於是，藉由觀察自己能夠容易的體會到，觀察者與被觀察者微妙的差異，以及當局者無法輕易掌控的心理狀態，甚至是因此影響到身體上的『病痛』。 生氣時的情緒，影響了當時幾乎所有的思考，不過，很有趣的，縱使當時的想法和反應都不經大腦，還是會下意識的，避開許多自己不希望公開或不想牽扯的議題，甚至會以閃電般的速度為自己找尋到出路，以逃避提及某些話題。生氣時所影響到之心理深度或許並不大，但許多反應卻常出乎意料，心中一瞬間的念頭，都會經過下意識的過濾之後，脫口而出。因此，所謂的『激將法』，其實也不過只能讓人說『是、不是』與『要或不要』，對於要當事人全盤托出某件事，似乎沒有什麼幫助。 與生氣相反的開心，是一種麻醉藥，會讓人短暫忘掉一切不想記住的事，但開心也有分深淺，一般的嘻嘻哈哈，只是單純的麻醉藥，而有些愉悅，確是有可能成為一把雙面刀插在心裡，隨時有可能讓你對麻醉藥上癮，一但解開便痛苦萬分。 最有趣的一種情緒，是憂鬱的現象，除了壓抑自己會造成憂鬱之外，有時莫明的突發事件，如失戀、寵物死掉等，也會讓自己茫茫然，甚至是胸口鬱悶、呼吸困難，身體的許多無中生有的病痛不在話下。以觀察者角度乍看之下，明明是如此大不了的事情，卻完全想不透為什麼可以令人這麼的難受，當下，在觀察者與被觀察者之間，明明顯顯的存在著一條深溝。常聽有人想不開、自殘，都是在這莫明的心理壓力下發生。但在這狀態下，其實腦袋是格外的清醒，扣除掉那莫明的想不透之外，卻能夠很快的想明白其他複雜的事，當然有些時候也包括了幻想與妄想，大腦彷彿在為這壓力尋找解答，全速的運轉。之前曾有篇論文寫道，人在憂鬱的時候，會變成天才，實驗中甚至能夠快速解開非常困難的數學式。換句話說，有人在失敗中重新振作而取得日後的成功，或許也不是沒有道理，因為，人人都有機會可以變成 IQ 200 的天才。 不過，除非是重度憂鬱到成精神病之外，通常一段時間過去，憂鬱的情緒便會逐漸解開，不知不覺中，我們的腦袋已經將一切事情都宣洩掉。坳不過去而走上不歸路的人，卻也真是可惜，何不趁憂鬱時多讀點書，多想些絕世的困難問題呢？難得頭腦超頻呢！ 所有情緒中，最無聊的就是哭，哭真的沒什麼道理...

GTK程式通常是由一個個 Object 所堆積起來，所以 GtkWidget 和 container 都記錄著 parent/child (父/子)的關係。又因為一個 GtkWidget 不能同時擁有兩個 parent，通常，所有的父子關係都是在程式初始化時就被決定好。然而在某些情況，為節省功夫或記憶體，我們會想重覆利用一個 GtkWidget 或是某 container 之下整個體系的成員，而不是重覆描繪類似或一模一樣的介面內容。 遇上這種需求，GTK 提供了一個 function call 可去改變 Widget 的 parent： void gtk_widget_reparent(GtkWidget *widget, GtkWidget *new_parent) 當然，重新被賦予 parent 的 Widget 會被當成最後一個 child widget，換句話說，若是在 Box 中，會被排列顯示在最後，這時我們可以用此 function 去調整其 widget 在 box 中的位置： void gtk_box_reorder_child(GtkBox *box, GtkWidget *child, gint position) 後記 一個簡單的小技巧，在此筆記之。

If you have the Thinkpad T60 laptop, maybe you will have a problem - ethernet device doesn't work. With command "dmesg", we can get some error messages that is just like: 0000:02:00.0: The NVM Checksum Is Not Valid ACPI: PCI interrupt for device 0000:02:00.0 disabled e1000e: probe of 0000:02:00.0 failed with error -5 It means the contents of EEPROM on the ethernet device was broken, because the checksum is not valid. For all I know, so many Thinkpad T60 laptops has the problem cause e1000e or e1000 driver return the error message and the device doesn't work. Here is a patch to add a parameter - "eeprom_bad_csum_allow" for the e1000e kernel driver: e1000e-allow_eeprom_bad_checksums.patch To enable the option will lead e1000e driver to ignore checking checksums of EEPROM. So you can use the command to load the e1000e driver be patched to enable your ethernet device: sudo modprobe e1000e eeprom_bad_csum_allow=1 BTW, I think you might see the similar patch for e...

Actually, LXDE(Lightweight X11 Desktop Environment) project has rested for a long time. Though we're getting more and more people to join us since Linux World Expo 2008, LXDE have no much improvements since July this year. It's happened due to our main developers doesn't have time to write a new code, PCMan must took time to focuses on his physician jobs, Jserv has worked for a new project which is confidential. About me, I was burdened with my family, so I also need to focus on my current jobs and my school to earn more money. Recently, we're planning to release a new version and new stuffs of some LXDE components for Merry Christmas. :D It is a great news that LXDE has a new project - "menu-cache", which is a library creating and utilizing caches to speed up the manipulation for freedesktop.org defined application menus, and also it can be used as a replacement of libgnome-menu of gnome-menus. It means the menu-cache will speed up our LXLauncher and LXPanel ...

話說上個星期周末，隨著 N 公司的員工旅遊團去花蓮旅行，雖然我並非他們的正職員工，但與他們相處融洽，能得到一同出遊之機會，感激不已。其中一個行程是來到了一個原住民部落，不過我忘了地名了 :(，他們帶我們去撿各式的石頭，然後給我們十分鐘在石頭上畫圖。 接來了幾支畫筆，挑了幾種顏色，就匆匆忙忙的開始作畫了。由於當天沒吃什麼東西，以致肚子太餓，不自覺的就畫了櫻桃起士蛋糕，並匆匆塗上背景，然後留在桌上閃人。（這麼重的石頭誰要扛回家呀！） 這次的旅行很愉快，對於幾乎沒去過花蓮的我，很新鮮。期待下一次的出遊活動。

寫出漂亮的程式碼，是每個寫程式成痴的 Coder 所追求的，對這些人來說，每次的寫作都是在追求自己能力的極限。常耳聞，有人面對自己寫出的程式碼，可獨自欣賞久久不能自己，飲茶配酒又吟時作對以讚嘆那數十行的程式，撇清自戀成份不談，其中面對那追求頂尖的程式碼之美的渴望，可想而知。 就有一些 Online Judge 網站，提供大量的程式題目，讓高手們痛快的挑戰自己的極限，其中有人追求的是程式碼長度，有的則是追求程式的效能，網站內的評分項目雖不盡相同，卻同是追求各種程式撰寫的極限。此外，排名機制和資料庫可以讓我們清楚看到，自己在面對世界各地的高手時的程度差距，更進一步相互交流。深思『為什麼可以寫出這樣的程式？』以提升自我。 在此推薦一個網站： http://www.spoj.pl/ 對程式痴人來說，在閒暇時挑戰寫程式的極限，也真是不錯的休閒活動。而想要精進自己寫程式能力的人，由此緞練一番，確也是很好的方法。 後記 慚愧

經常做二進位的運算 ， 在 Debug 時也常會需要檢視一下二進位形式的數值內容 ， 可以自己寫一個函式去 Print 出來 ，因此筆記在這 ， 以後隨時可以 Copy & Paste :P 。 void print_binary(int type) { int size = sizeof(int) * 8; /* 1 Byte = 8 bits */ int i = size - 1; char s[size+1]; while (i+1) { s[i--] = (1 & type) ? '1' : '0'; type >>= 1; } s[size] = '\0'; printf("%s\n", s); }

最近 ， 『 Fast Boot』、『 快速開機』、『 5 秒開機』、『 XPUD』 這些關鍵字紅到爆炸 ， 經常在快速開機的討論 話題 中所聽到 。自從 EeePC 的推出 ， 自豪的標榜 15 秒開機後 ， 『 快速開機 』 的話題越來越熱門 ，然後 Aspire One 驚人的 11 秒開機 ，讓 『 開機的速度 』一時間變成了各家研究的首要方向 。不久前 。 由知名 Penk 所發展的 7 秒開機 XPUD ，直到最近 『 Intel Moblin 』 所展示的 5 秒開機 ，都著實讓人感到不可思議 。 接下來呢？難道 5 秒開機真的已經是極限了嗎？ 由於到處打工 ，也碰到許多與相關的案子 ，近來更被許多老闆們要求進行加快開機的速度 。進行加速的過程中 ， 從開始幾秒鐘為單位的計較 ，到最後連小數位以下的時間都要精精算計 ，每一次都證明了 『 5 秒鐘 』 似乎真的是極限 。 一個開機速度所會碰到的瓶頸大致上如下： Kernel Initializing Driver Initializing Filesystem Initializing I/O 通常 Kernel + Driver + Filesystem 使用 2 秒（經過數不清的調較和修改 kernel 後） ，Userspace Initializing + Xorg + Desktop Environment 用 2.x 秒 ，整個估算大概會是 5 到 6 秒鐘 。經過測試 ， 其實應該有可以再加速的空間 。 仔細觀察了 Kernel ， Synaptic Touchpad 就吃了 0.5 秒 ，IDE 的 probe 也吃了 0.6 秒 ，單是這兩支 driver 就吃掉了近五分之一的開機時間 ， 實在是慢的驚人 。其中有趣的是 ，通常在 netbook 上 ， ide1 沒有 Device ，但在這部份卻要花上 0.16 秒 ，讓人很想要 dirty hack ， 直 接讓 kernel 閃過 ide1 的 scan 。 :P 其實在整個開機流程中 ，最大的瓶頸在於 I/O ，Userspace 的程式都伴隨著大量的 config file 、Font、Library ，如何提升載入速度是很重要的課題 。這部份 ， Moblin 的 Super Readahead 作法的確很暴力 ，...

在 Linux 下監視某個資料夾的變化，有很多種方法，可以土法煉鋼的定時去掃描、檢查修改時間，也可以去將檔案一一開啟比對，不過往往這些過程，都伴隨著大量且多餘的 IO 存取。對此，使用 inotify 就顯得比較方便且有效率。自從 hal 的出現後，我們已經可以使用 inotify 去攔截某個檔案或資料夾一舉一動的 event，若是整合 GLib ，短短數行即可實作出來。 #include <glib.h> #include <sys/inotify.h> #include <sys/types.h> #include <errno.h> void inotify_events_io_func(GIOChannel *channel, GIOCondition condition, gpointer data) { char buf[1024]; struct inotify_event *event; gint index = 0; gint len = 0; gint fd = g_io_channel_unix_get_fd(channel); while(((len = read(fd, &buf, sizeof(buf))) < 0) && (errno == EINTR)); while(index<len) { event = (struct inotify_event*)(buf+index); /* read events */ switch(event->mask) { case IN_MODIFY: printf("MODIFY\n"); break; case IN_CREATE printf("CREATE\n"); break; case IN_DELETE: printf("DELETE\n"); ...

近年來 Linux 在台灣資訊業的蓬勃發展 ，讓誰都不敢漠視這一塊市場 ，就連過去與微軟緊緊相結合的硬體廠 ，都開始 『 鬆口 』 和 『 鬆手 』 來支援 Linux 。資策會這次於11月 20、21 日舉辦了一個『 Freedom 硬體工程師研討會 - Freedom Hardware Engineer Conference Taipei 』 ， 邀請了許多國外講者 ，演說內容包括了 Linux Driver 和相關硬體的開發 ，除了讓原有自由軟體開發者與相互交流外 ，也希望讓國內廠商能夠更了解 ， 如何有效參與 Linux 硬體產品的開發 。 話說議程內容還不錯 ，看到有個 ACPI EC driver 的 session ，眼睛都亮起來了 。個人希望各個廠商能夠多了解這議題 ，不要再隨便脫口就說： 『因為在 Windows 上正常 ，所以都是 Linux 的問題 』。與 Linux 的開發者共同解決才是正確之道 ，在未來也能夠更省時省力 ，也或許可以共同促使 BIOS 廠多擔起一點責任 。 心內真心的吶喊：對 Linux 的開發者來說 ，現在實在是太辛苦了 。

最近碰到個難解的問題 ，就是系統無法 Restart 的 Bug ，有 usplash 的人會卡死在關機畫面 ，在 console 底下 ，會停在 kernel 吐的最後一行訊息： 『 Restarting system 』。有趣的是 ，這 bug 只會在 suspend/resume 之後才發生 。沒錯 ，這應該是 ACPI 的 Bug ，但其實可以透過 Patch Kernel 來修正 。 這 patch 可由此下載： linux-kernel-restart.patch 後記 因為 BIOS 的人永遠不承認是自己的錯 ，我們只好自己動手 。

ACPI(Advanced Configuration & Power Interface) 是近年來廣泛被使用的電源和硬體狀態控制標準 ， 在 PC 產業中已經被用來取代 APM(Advanced Power Management) ，並做為一個電源控制的首選規範 。截至本文為止 ， ACPI 的最新版本號是 3.0a ，詳細說明資料可參閱官方網站（ http://www.acpi.info/ ） 。 常聽一些人解釋說： 『 因為 休眠 、暫停 功能在 WindowsXP 系統上沒問題 ， 所以 BIOS 在 ACPI 的處理上應該正確無誤。要是在 Linux 等其他系統上出現問題 ，那一定是其它作業系統的錯 。』 乍聽之下 ，這樣的解釋真的很合理 ，完美的證明了 BIOS 沒有問題 ， 但實際上 ，這樣的說法就好像賣藥郎中說： 『 這藥強健筋骨 、治百病 ，男人可壯陽 ，女人可改善體質 ， 絕對百利而無一害 ，要是服用後病沒好 ，仍然一厥不振 ，且頭暈目炫 、 口吐白沫 ，那肯定是你身體有問題 ，虛不受補 。藥 ，肯定是沒問題的 。』 要窺探並破解 ACPI 的迷思 ， 我們可以直接檢查存在於 BIOS 裡的 ACPI Source ， 了解到底發生了什麼事 ，會讓 ACPI 功能在不同系統上有不同的表現 ，雖然會有如霧裡看花 ， 但沒關係， 反正世上最美的事物就是最矇矓的恐龍呀:P。如果是在 Linux 系統下 ，我們可以很輕易的將 ACPI 的 DSDT(Differentiated System Description Table) 給 Dump 下來： sudo cat /sys/firmware/acpi/tables/DSDT > dsdt.aml 『dsdt.aml』是一個 Binary 的 ACPI Machine Language 檔 ，我們可以使用 isal (Intel ACPI Source Language compiler/ decompiler) 將它 disassemble ，若是 在 Debian/Ubuntu 之下 ，可直接用 apt-get 安裝該工具 ： apt-get install iasl 然後使用 iasl 直接 disassemble dsdt.aml： iasl -d dsdt.aml 完...

自去年轉移 blog 到這開始，周遭陸陸續續發生不少趣事和惡事，彷彿老天突然給我一張不能拒絕的三溫暖門票。如今近一週年，回顧，這大概是活了二十幾年以來，心理變化最大、波形最不穩定的一年，因此，臭味相投的朋友結交不少，不小心得罪的人也不在少數。不管各位看官是屬於哪一種，還請多多包涵。 近來為五斗米而連日忙錄，前陣子更是平均每日睡不到 2 小時，整個 blog 都沒時間可以添些新東西，深感對自己的要求就此停擺許久。仍記得過去，每當找不到題材來撰寫新文章，就知道自己的水已經漏光，該是要更努力充實和思考新事物。也就是如此，寫 blog 有時就像有人默默的在背後推一把，強迫自己不停地去鑽研或體會更多美好的經驗。若失去寫文章的行為，頓時便會感覺到自己在原地踏步。 值得慶賀的是，這樣特別的一年可不是每個人都有機會去體驗，相信再渡過了這最後的艱苦期，應該就會開始平順些，也可以重新再度威脅自己寫些新東西。 後記 被工作雜務逼得太緊，有時候腦袋都不會轉了，常常一些簡單的程式和問題，想破頭也想不通也解決不了，真的是變傻了。

於 Tossug 心得分享的《淺談 Hacking LXDE 》簡報上線，歡迎各界多多指教。 Hacking_LXDE.pdf * 更多細節請參閱舊文章《 讓我們輕鬆自在設計自己的 LXPanel Plugin 》

有幸受邀，將在今天（2008/10/7）晚上七點半，在 Tossug 聚會活動給予一場簡單的技術心得分享，主題是《Hacking LXDE》。今天將會談到 LXDE 為何會輕量、快速，並簡略說明其技術細節。也會提到「如何開發 LXPanel 的 Plugin」，並用一個簡單的實例解說。 地點在捷運「士林站」的《流浪觀點》，活動場地的詳細資料： 流浪觀點是一家靠近士林捷運站得咖啡店，提供餐點咖啡投影機及不定期紀錄片選映。 地址：台北市士林區福壽街13號 電話：02 28382619 士林捷運站一號出口，直走過馬路(中正路236巷)，沿公園靠右，見流浪觀點招牌即是

要好好的包個 Debian package 其實是一件大工程，除了注意事項能彙整成冊之外，如何好好設定 package 的相依性和說明文件更是一個不小的挑戰。所以，一個包得差勁的 Debian package，很有可能造成系統大亂，甚至讓系統承受不必要的額外負擔，這就是為什麼 Debian Maintainer 們會如此受人敬重的原因。 不過有的時候，我們並沒有要維護一個 project ，也沒有要上傳一個 package 到嚴肅的 Debian official repos，只是純粹想惡搞或是貪圖方便而包一個自用的 deb。我們也許不用、也不想顧慮太多細節，因為可能只是簡單的將現有的 package 拆開，加入幾個自定的檔案再包回去。這樣的需求，大致上可以這樣做： # 建立一個新資料夾 mkdir mydeb # 解開 package 的 DEBIAN 控制文件到新資料夾的 DEBIAN dpkg-deb -e mydeb.deb mydeb/DEBIAN # 解開 package 的檔案到新資料夾 dpkg-deb -x mydev.deb mydeb # 處理或惡搞完成以後再次包裝起來 dpkg-deb -b mydeb mydeb_new.deb 這樣修改和包裝 deb 非常的不正規，品質上也不合格，不過既然包出來的 package 只是自己私下用用，Why so serious?

這也不是一天兩天了，常常會對 Linux 的某些 Driver 做些 Patches，或對某些 Module 做修改，但每次要 compile 出那幾個 ko 檔時就很頭痛，既然只是修改特定的 module ，又不用重新做出新的 kernel image，為何每次都要將整個 kernel 重新 compile 呢？其實有方法可以只編譯特定的 kernel module 以並免不必要的時間浪費。 切換到目標 module 的目錄下，然後執行： make script make prepare make -C /usr/src/linux SUBDIRS=$PWD modules ※粗體字部份改成 kernel source 的位置即可。

今天是 LinuxWorld 展覽的最後一天，人潮明顯變少許多，大多數的 Booth 便在這時到處交流呀！換 T-Shirt 或到處換名片、聊天、拿糖果是今天常見的場景。而且今天有免費的 Beer 無限量供應，有人喝得不亦樂乎。 幾張熟悉的背影，明眼人猜得出來是誰嗎？ 老是看 LXDE 也覺得無聊，也到處走走逛逛拍的一些照片。 今天的 Debian Booth 更誇張，桌子椅子直接被拖走，被隔壁的 Joomla 罷佔！ 最後大家都在到處合照，是很有趣的場景。:) 這次活動，用破爛的英文介紹 LXDE，練成了一點用英文胡說八道的功夫，希望外國朋友聽得懂我在講什麼呀！如果明年有機會，希望還可以再來！就如會場上的標語 See You Next Year!

今天是 LinuxWorld 的第二天，依然人潮不斷呀！ LXDE Project 的各位依然努力解說！不少做硬體的廠商和 LinuWorld 的 Speaker 都很有興趣，也有很多教授和外國朋友都說他們知道 LXDE，看來我們還有點小名氣。〔可惡！不知道為什麼我照出來的照片一直有矇朧美 :(〕 話說，這次的 Debian Booth 被 FreeBSD 攻陷了，因為 Debian 的人都去 DebConf ，所以只在 Booth 的桌子上貼了一張紙條： 然後慘被 FreeBSD 催殘呀！被掛上耳朵、桌上放上 DM 和光碟片，慘不人賭。 還有照了很多相，慢慢再來整理吧！

世界級且每年一度的 Linux 盛會『LinuxWorld』在舊金山如期舉行，非常高興的是，這次 LXDE Project 的受到 Asus 和 gOS 的贊助，飛到了美國參加這大型的展覽，這真是台灣的小小專案從台灣踏出國際化的一大步。而且 LXDE 在這次的會場中，也有一個小小的 Booth，Mario、Glen、Andrew 以及 CW 都在攤位為好奇的人和廠商解說，但我大部份時間都在到處逛看美女拿贈品，慚愧 :-(。不過總體來說，外國人似乎比我們更重視這個專案呀！ 除了 LXDE booth 之外，我也在 gOS 閒晃幫忙，因為 gOS 現在正在慢慢導入 LXDE。可是，因為我不會談他們 business 的東西，只好常常偷跑出去逛。gOS 隔壁就是 OpenMoko booth，也看到了從台北公司來的美女呀！ 值得高興的是，今天是來美國後，第一天吃到沒有起士和蕃茄醬的東西，下午偷溜出會場和 Andrew、CW 到處找日本菜！Andrew 一直到處問長的像日本人的女生，好不容易才找到！〔聽說他們前一天還吃韓國烤肉，可惡！〕 展覽正式開始才第一天，繼續加油吧！

活在 Linux 世界，若這樣大力稱讚 Windows ，應該會招來不少毒舌批評。但仍然不可抹滅的是， Windows 在許多地方的確比 Linux 優良，很多不是技術比較的問題，而是歷史演變所造成的既定結果。 相信許多人正在忙著解決 Linux 上，程式視窗太大而超出螢幕的問題。尤於低價電腦的風行，讓螢幕出現了許多不可思議的規格，如 800x480、1024x600 等等。所有的規格硬是比標準的短了點，因此造成許多原本在 800x600、1024x768 下運作正常的程式，都有視窗太大的問題。除了一些 GNOME 設定程式有此類問題之外，其中最嚴重的大概就是 evolution 的對話框。 Microsoft Windows 看起來就沒有這樣的問題，每一個對話框都好好的待在螢幕範圍內，絲毫未超出去。雖然無法保證所有軟體都正常，但至少 Microsoft 自家的程式都是沒問題的，令人不得不去誇讚一下，尤其在改完這麼多 Linux 下軟體的視窗大小之後呀。仔細想想，難道是 Windows 比較聰明？技術比較高超？為什麼可以在事先就想好這問題並避免掉它？ 有一個很重要的原因，是因為所有的廠商，都是以 Windows 當基準來設計硬體，當然可以確保 Windows 是正常，而且不會有這種明顯的 Bug 存在。另一方面，是 Windows 打從娘胎起，就是針對 640x480 去設計所有的對話視窗，不僅 Win95 如此，Win98、WinME、WinXP等等皆是如此。當解析度調成 640x480 後，我們可以發現，還是可以正常使用 Windows 的所有功能。 對於不斷追求『效果』和『類 Mac』的 Linux ，可從來就沒想過這問題，大螢幕用慣了，都被寵壞了。一直到了現在，才發現有這樣的問題，不過也好，讓我這種不學無術的人有賺小錢活命的機會呀。 :-)

談到調校開機速度，就不免會提到運用『 Bootchart 』來分析開機狀況，這是一個將開機時的 CPU、IO、Process 等資訊畫成一張圖表的工具，在『 Bootchart 』的網站上就可以找到很多 Sample。其實，『 Bootchart 』的原理是利用一個在背景跑的 Daemon，每隔一段時間就取樣 CPU、IO 等系統資訊，等到開機完畢後，再將這些資訊畫成圖表。 在多數的電腦硬體中，Bootchart 都是可以正常運作的，可是在一些 Embedded System 下就會碰到不少麻煩，在『 elinux.org - Bootchart 』的 presentation 就有提到這一類的議題。其問題出在於取樣的 Daemon 是使用 shell script 所撰寫，不管是 sleep 等待下一次取樣、用 cat 讀取系統資訊或是使用 pidof 取得結束的 process，都會因為產生過多的 process 而造成可怕的系統資源消耗，其情況大致如圖： 在一些資源不多的 Embedded System 中，bootchart 會因為產生太多的 process 和 open IO，造成系統負荷過高，完全無法測得正確的開機狀況。所以，就有一些 clone 的專案，使用 C 語言將 bootchart 裡的 bootchartd 整個重新寫過一遍，『 ubootchart 』和『 Bootchart-lite 』就是因此而產生的專案。 這是利用『 Bootchart-lite 』在 OpenMoko Freerunner 上取樣並畫出來的圖表，因此發現其開機過程相當得可怕。 :P

前陣子提到各家 Terminal 和 VTE 的許多『 問題和缺點 』，其中提到，一個減少 VTE 用量的有效方法就是『多視窗共用 Process』。在當時，已知 gnome-terminal 、xfce4-terminal 和 Roxterm 等幾家 Terminal 有支援，而隨後 LXTerminal 也實作了出來該機制。方才瀏覽書籤，發現新版的『 Lilyterm 0.9.4 』也實作出來了，在作者『 Tetralet 』的 blog 上提到。 另一項重點值得一提：在之前，大多數有同樣機制的 Terminal ，都是使用 D-bus 來達成 options 的傳送，這意味它們就必須要多一個 dependency ，而且在某些情況下， D-bus Launch 也會有一些額外的資源消耗〔太雞蛋裡挑骨頭啦！〕。所以，原生的 Unix Socket 是一個很好的替代方案，由於 Terminal 本來也並不太需要用到 D-bus 的特色，如此省下豈不樂哉。 :D 不過，目前在眾家 Terminal 之中，只有 Lilyterm 和 LXTerminal 鑽牛角尖，使用 Unix Socket。有興趣的人，或許可以參閱 source code。

過去的鼠繪日子偷懶，連用 Photoshop 畫圖都模組化，畫給 MSN 用人物小圖裡，一張臉孔換髮型再加點料，就可以變成男、變成女，亦或變成各種心情。雖然張張平平無奇，但曾陪伴我在掛 MSN 的一些日子。 要是有是有人不嫌棄，就隨便拿去用好了，沒有任何使用限制條件。 :-)

就階層面來看， C 語言是個不高不低的語言，造成許多語法其實都可以有其他不凡的實作方式。尤其是一個看似基本且常用的方法，其實可能大量的暗藏玄機，值得我們惡搞。而對多數人來說，有一個一定不陌生的語法『 switch 』就相當有趣。在某些情況下，是否能利用『查表法』取代 switch，得到程式效能上的提升？此議題相當具有可探討性。 這是一個簡單使用 switch 語法的例子(switch_sample.c)： #include <stdio.h> int main(int argc, char** argv) { int i; if (argc<2) return 1; i = atoi(argv[1]); switch(i) { case 0: printf("Hello! Mr. Zero\n"); break; case 1: printf("Hello! Mr. One\n"); break; } return 0; } 編譯： # gcc -o switch_sample switch_sample.c 實際執行： # ./switch_sample 0 Hello! Mr. Zero # ./switch_sample 1 Hello! Mr. One 仔細觀察該程式的內部運作，發現 switch 語法在編譯後實際執行時，是使用一連串的『比對』、『判斷』和『跳越』動作來達成任務，其實相當耗 CPU 的執行時間和寶貴的運算資源，若是 switch 的『設計龐大』，對 CPU 來說也是個相當可觀的負擔，尤其在許多 Embedded System 上會特別有明顯的影響。 由於 switch 的 CPU 時間消耗驚人，利用查表法來減少些比對判斷或許是個可行的方法。一般來說的查表法，是因為我們的資料需要『大量的運算』才能產生，所以『事先』計算好並建成一個數據表放在程式內部，以便程式在『真正執行』時直接快速提取其結果使用，而不必當場計算所需要的數據。又因查表的過程中，是直接對某個 pointer+N 去做存取資料，所以速度極...

轉眼間 2008 年過了一半，時間流逝之快已不必再用言語形容，回想這十多年，自己從小毛頭長高長大到現在，到底有什麼不同了？ 還記得 1996 年的某個晚上，手拿著一張磁碟片，憑著一條 64K 的專線，靠著爛到不行的英文能力，一一下載 img 和 tgz 檔，跌跌撞撞的裝著 Slackware Linux 4.0。辛苦到了天亮，終於在下 startx 指令的那一刻，看到滿是 X 符號的畫面，當時心情是多麼興奮。沒想到，一個一點用處的沒有的系統，也能讓人滿是成就感。 我不會寫程式，頂多在 Windows95 下用 VB 拉過幾個像是程式的東西，最多是會寫一點 HTML/JavaScript 及簡單的 DOS 批次檔。當時的我，完全不知道自己可以做些什麼，只會傻傻的看著螢幕上跟著滑鼠跑的小眼睛傻傻的笑，並崇拜著寫這個程式的作者。〔一個小學生的盲目崇拜〕 也忘了是相隔多久，因『偷聽』一些 ISP 的工作人員對話知道了 FreeBSD 的存在，在泡書店時找到了一本 FreeBSD 2.x 的書〔如果沒記錯，應該是黃綠色，作者我已不記得，但前陣子好像有聽人提起過〕。不過嚴格來講，這不能稱作是書，因為實在是沒幾頁，但安裝步驟清楚且詳細，讓我不費吹灰之力就把 FreeBSD 裝起來了。在過程中，很能夠感受到這本書裡所下過的功夫，以及作者的熱情。 或許是當時國內情勢的關係，開放原始碼這時開始快速浮上檯面，陸續有許多的人用『全身上下的熱情』去擁抱，實在好不熱鬧。一股莫明的感動，從為 Linux 中文化而誕生的 CLE、印象深刻的 OLS3 和 perl 的一切，到許多早期活躍於網路上的前輩們身上散發出來，使我至今仍無法忘記。還記得，當時的零用錢，近乎全數放在購買這些 Linux/FreeBSD 相關書籍上，因為這是我唯一得到參與感的方法。 時過境遷，一切卻等不到我學會寫程式。多年前，憑著剛習得的一招半式，在某個論壇提議用新架構，寫一些新的程式，卻被回覆：『這是開放原始碼的世界，不滿意改一改就好。』，那人又道：『有這麼多軟體可以選，何必重新造輪子？況且重新寫不一定比較好。』一席話衝擊並打消了我不少念頭。長久來的憧景和滿腹熱血，頓時消失得無影無蹤。 我好想，好想和當初的前輩們一同 Hacking，好想像當初的人們一同分享熱情，好想和大家一起往前開拓道路，好想，真的好想，可惜的是，我沒有機會...

你的軟體用起來有問題？請打技術支援電話，由客服人員為你服務，他或許已經儘其所能，但 未必能解決你的問題。如果問題是軟體的臭蟲，你只好痴痴地等待不知幾年後才開賣的下一版 。而你當初之所以選用Ａ軟體而不是Ｂ軟體，常常是聽信銷售員（sales）的一面之詞或同儕 的推薦。在這個行為模式下，users 面對的是銷售員和客服，coders 面對的還是銷售員和客服 ，users 遇到的問題要間接地才能反應到 coders 手上，中間還可能會被過濾掉。 破除過往的迷思和痛苦，Open Source 帶來了全新的契機，所以在網路發達的今天獲得許多人的支持。在這不一樣的世界中，歡喜用的使用者，可以和歡喜做的開發者直接互動，可以更準確、快速的將問題和解決方式公開通報，並可以最快速度得到許多軟體開發者和有心人的反應和幫助。如此不一樣的軟體使用生態，令軟體不斷累積自身的價值，也造福了廣大的資訊科技使用者。 :-) 當然，除了從網路上交流，親自出來面對面接觸也是非常有意義的。在台灣一年一度的『 COSCUP 2008 開源人年會 』盛會，就讓樂於擁抱 Open Source 的人能共同來參與相聚。此活動將於『2008/8/23 (六) - 24 (日)』舉行，地點在『台灣大學 應用力學研究所 國際會議廳』，附有茶點，歡迎各界參加。

業界上常用的 Matlab 軟體，因為本身就是為了做數學運算而設計，所以在數值分析和處理方面非常快速好用，但是在 C 語言就中沒有那些好用的指令和數學函式庫了，得自己打造所有的運算流程和架構。舉例來說，使用 C 語言來做矩陣運算，程式開發者都是先『指定行列數量』建立一個陣列，再『指定行列數量』去對內部的值，一一做處理或高斯消去解方程式，這比起 Matlab 中用兩行就可以搞定一切運算，可說易用性相差甚遠。 所以就想到，要是我們能設計出一套好用的 C 語言矩陣函式庫，是否就可以省下這些重覆設計矩陣運算流程的時間？於是可以做一些實作，來完成這個任務。 基本的矩陣資料結構： typedef struct { int rows; int cols; int total; double *table; } Matrix; 其中定義了幾個基本的 functions 做矩陣的處理： 建立矩陣： Matrix *matrix_create(int rows, int cols) 矩陣最佳化： Matrix *matrix_optimize(Matrix *matrix) 解矩陣的方程式： Matrix *matrix_solution(Matrix *matrix) 顯示並列出矩陣內容： void matrix_print(Matrix *matrix) 清空矩陣： void matrix_clear(Matrix *matrix) 函式的程式碼： void matrix_clear(Matrix *matrix) { int i, j; double *ptr; /* initializing matrix */ ptr = matrix->table; for (i=0;i<matrix->total;i++) *(ptr++) = 0; } Matrix *matrix_create(int rows, int cols) { Matrix *matrix; /* allocate */ matrix = (Matrix *)malloc(sizeof(Matrix)); matrix->rows = rows; matrix->cols = col...

這是之前的一小則心得小記，一直記錄在桌面便條紙上，整理了一下。WEP 的密碼長度分為 40bits 和 104bits ，若是換成 byte 單位是 5bytes 和 13bytes，也就是 5 或 13 個 ASCII 字元。在 Linux 上，我們可以用 iwconfig 來設定 WEP 的 ASCII 密碼： 40bits 用 ASCII 表示： iwconfig wifi0 key "s:12345" 104bits 用 ASCII 表示： iwconfig wifi0 key "s:1234567890abc" 不過有些時候，WEP 會用十六進位表示密碼，因為每個字元由兩位十六進位碼表示，所以我們可以看到很長的密碼，用 iwconfig 來設定的話像這樣： 40bits 用 16 進位表示： iwconfig wifi0 key "AABBCCDDEE" 104bits 用 16 進位表示： iwconfig wifi0 key "AABBCCDDEEFF11223344556677" 由此可見，在一般情況下，只有在 5 和 13 個字元時會用 ASCII 表示，而其它字數時都是 16 進位型態，所以若是我們寫一個程式，判別用戶所輸入的 WEP 密碼型態，就可以用這種規則去識別。

『 GTK+ 』是個易學的 Toolkit，用它來寫 Linux/BSD 上的圖形化界面，非常的簡單。用其開發出來的程式，除了可以在 X11 上運作，甚至是可以使用 DirectFB 直接將 GTK+ 程式畫在 FrameBuffer 上，所以 GTK+ 也常見於 Embedded System。 在 GTK+ 1.x 時代發展到最後，效能、輕量程度和穩定度都很好，目前仍然被許多 Embedded Device 所採用。但 gtk+ 2.x 之後的變革極大，每個版本都有大量的新東西，導致有些版本異常肥大，或有些版本異常 Buggy 都不足為奇。曾經也撰文寫過說，在開發 GTK+ 程式時，常碰到非常奇怪的問題，而除錯所花的時間少可以很少，多可能一兩天都不見得能找出問題。 這邊有些除錯的方法，可以幫助 GTK+ 開發者能找出程式上的臭蟲： 在執行欲 Debug 的程式前，先設好 G_DEBUG 環境變數： G_DEBUG="fatal-criticals" 在產生 Makefiles 時，可下參數開啟 cast-checks 以得到更多的 debug information： ./configure --enable-cast-checks 用這幾個小技巧，就能比較容易發現 GTK+ 程式的錯誤。 不過如 PCMAN 所說，開發 GTK+ 程式時，放一套 GTK+ Source Code 在旁邊供著，還是比較有保障的〔笑〕。許多奇怪問題，還得靠 GTK+ Source Code 來釐清真相，速度可能比 Google 還來得快。 別以為『 GTK+ 哪這麼多問題？』，從很多 GNOME 和其他程式的 Code 就可以發現，為了解決 GTK+ 問題，有數不清的 Dirty Hack 和重寫。所以，和世界各地的 GTK+ Program 開發者聊到『GTK+ Sucks』時，總是能會心一笑和產生共鳴，不是沒有道理的。 :-) 後記 Open Source 最大的好處是讓開發者可以到處看 Code ，這意味著一切技術都是透明的，對於提升開發者自身能力上是很棒的。而對使用很多不同 Libraries 的 Project 來說，如果在有許多樣本的情況下，其開發者看 Code 的數量，其實就是程式碼品質的關鍵。所以，GTK+ 的 Source Code 當然也要看...

今年是『低價電腦年』，家家都打著 Low-cost PC 的旗號，從Asus、HP、Acer 再到最近的 MSI ，全都殺進這戰場。但縱觀整個發展，『低價電腦』似乎變成了『隨便一套 Linux +低等級硬體』代名詞。但也因為這樣，有了大量的 Linux 需求，讓每一家 Linux 發行商都使出渾身解數，設計出各自的特別操作界面，以取得廠商和消費者的親睞。 由於低價電腦的硬體本身比較差，所以上面運行的系統環境應該是要『快、狠、準』才是，若是使用『重量級』的環境和系統，拖著低等級硬體在跑，對使用者來說是最大的受罪呀！不過，『 LXDE 』還算夠輕盈，讓 LXDE 和低價電腦共結為連理，使 Low-cost PC 變成 LXPC，還真是個不錯的選擇！要知道，行走這『低價江湖』，結伴成『俠侶』去闖蕩總是比較溫暖和暢快的。〔別忘了 LXDE 還有隻神雕！？神燕？正可謂『神雕俠侶』呀 :D〕 EeePC 900 實體跑 LXDE 降速的 CPU - 630 Hz 在上面跑 Firefox 3.0 (只在右邊露出一小部份而已。汗) 加上桌面特效也依然不是問題 LXDE 下一階段目標是實作許多『好用』的系統工具和設定工具，如螢幕/投影機設定工具、網路連線工具、偏好設定等等；此外，也許會花些時間實作和研究一些 eye-candy 的東西，不過暫時不會當成主要工作，主要目標還是放在提升 LXDE 的可用性。 另外，除了改善對一般使用者的可用性，對進階玩家而言，尤其是 vim 和 command line 的重度使用者，Terminal Emulator 是必要的工具〔除非你是連 X 都不用的超級 Geek〕，所以 LXDE 現在也實作了一個建構在 VTE 上的 Terminal ，已經在這兩天釋出的『 LXTerminal 』就是這個實作。 LXTerminal 目前特色： * 支援多重分頁。 * 沒有任何過度不必要的依賴套件。〔除了 gtk+ 相關之外，就只有 libvte〕 * 為減少記憶體浪費，所有的程式運作可共用一個 process。 * 當視窗、分頁和 VTE 的尺寸改變時，有正確的變化行為且處理效能良好。 * 支援共用 process時，使用速度極快的原生 Unix-socket 而不使用 D-bus。 由於目前手邊只有 EeePC 可以測試和開發，所以 screens...