發表文章

目前顯示的是 七月, 2008的文章

Windows 好而 Linux 下不好的地方

活在 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

圖片
談到調校開機速度,就不免會提到運用『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

Lilyterm 大躍進

前陣子提到各家 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

就階層面來看, 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 去做存取資料,所以速度極快。

尋思,建表除了擺放一般數據之外,是否可以建立一個…