Fred's blog

活在 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 去做存取資料，所以速度極...