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 的情況，相信效能會和辛苦成正比才是。

輪子不停重新打造，但我依然原地踏步

轉眼間 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，好想像當初的人們一同分享熱情，好想和大家一起往前開拓道路，好想，真的好想，可惜的是，我沒有機會，沒有機會和你們分享你們給我的感動，沒有機會在那拓荒的時代出一份力。

失去目標的這幾年來只有閉門造車，原地踏步，雖磨練出了一些能力，卻也只是獨自娛樂罷了。

如果說這些年來我忘了什麼，那我肯定是忘了追尋前人的熱情，並堅持走下去。

不知道，你們是否會怪罪於我？

但請您相信，我將重拾當初的感動，我的心依舊原地踏步

請祝我一帆風順

一年一度的 COSCUP 又夠來囉

你的軟體用起來有問題？請打技術支援電話，由客服人員為你服務，他或許已經儘其所能，但
未必能解決你的問題。如果問題是軟體的臭蟲，你只好痴痴地等待不知幾年後才開賣的下一版
。而你當初之所以選用Ａ軟體而不是Ｂ軟體，常常是聽信銷售員（sales）的一面之詞或同儕
的推薦。在這個行為模式下，users 面對的是銷售員和客服，coders 面對的還是銷售員和客服
，users 遇到的問題要間接地才能反應到 coders 手上，中間還可能會被過濾掉。

破除過往的迷思和痛苦，Open Source 帶來了全新的契機，所以在網路發達的今天獲得許多人的支持。在這不一樣的世界中，歡喜用的使用者，可以和歡喜做的開發者直接互動，可以更準確、快速的將問題和解決方式公開通報，並可以最快速度得到許多軟體開發者和有心人的反應和幫助。如此不一樣的軟體使用生態，令軟體不斷累積自身的價值，也造福了廣大的資訊科技使用者。 :-)

當然，除了從網路上交流，親自出來面對面接觸也是非常有意義的。在台灣一年一度的『COSCUP 2008 開源人年會』盛會，就讓樂於擁抱 Open Source 的人能共同來參與相聚。此活動將於『2008/8/23 (六) - 24 (日)』舉行，地點在『台灣大學 應用力學研究所 國際會議廳』，附有茶點，歡迎各界參加。