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

尋思，建表除了擺放一般數據之外，是否可以建立一個 function address 的表？並藉由表內的 address 直接 call function 執行動作？如此便可省下一大筆 CPU 判斷指令的執行時間。

經過實作(table_sample.c)：

#include <stdio.h>

void switch_zero(void)
{
    printf("Hello! Mr. Zero\n");
}

void switch_one(void)
{
    printf("Hello! Mr. One\n");
}

int main(int argc, char** argv)
{
    int i;
    /* 定義一個表儲存函式位置 */
    void (* switch_function[])() = { switch_zero, switch_one };

    if (argc<2)
        return 1;

    i = atoi(argv[1]);
    /* 直接 call 對應之函式 */
    switch_function[i]();

    return 0;
}

編譯：

# gcc -o table_sample table_sample.c

實際執行：

# ./table_sample 0
Hello! Mr. Zero
# ./table_sample 1
Hello! Mr. One

實作結果很順利，跑出了預期的結果。雖然分別寫成 function 時稍嫌麻煩，但若碰到大量 switch-case 的情況，相信效能會和辛苦成正比才是。