Jserv's blog: October 2005 彙整

「Linux 國際化與區域化發展」簡報上線

今天應 [TnLUG] 之邀，去台南社區大學給了一場 [演講：Linux 國際化與區域化發展]，圓滿落幕，感謝與會朋友的指教，簡報可 [在此取得] (PDF格式)，這份簡報將技術性的細節忽略，主要是強調除了我們熟悉的中文資訊處理外，其他語文的支援與潛在的問題，請多指教，謝謝！

由 jserv 發表於 09:28 PM | 迴響 (1)

用 UrMap 找公司新地址

剛剛閱讀 Jouston 的 blog [在Flock裡搜尋你家的地圖(firefox適用)] 後，讓我想起目前任職的公司的這個部門最近搬到內湖，那就牛刀小試，看看 [UrMap] 的能耐：

還不錯耶，很清楚，這是新地址，如果恰好有朋友在附近服務，可以找我喝下午茶 (errr... 早上不用考慮，可能起不來)。

由 jserv 發表於 09:10 PM | 迴響 (0)

這才是牛人

對岸喜歡用「牛b」這詞稱讚高手的技能，而高手也自然成為「牛人」，基本上我每天都會掛在 #debian-zh IRC channel，有時候會有朋友戲稱我為「牛人」，不過我可擔當不起，咱們來看看貨真價實的「牛」人吧。

LinuxDevices.com 有篇報導 [Device Profile: DeLaval Voluntary Milking System]，提到一家有 122 年歷史的牛奶供應商 DeLaval 也採用 Linux 來監控這些乳牛的產能與環境狀況，之前的 blog [幕後的英雄：談 Embedded Systems 設計] 提到 Embedded Systems 以許多不同的風貌與型態存在，DeLaval 的系統也可算是，其系統規格如下：

硬體：
軟體：

如果對系統運作有興趣，可以觀賞該公司製作的影片 [Automatic milking movies]。說來說去，這跟第一段提到的「牛人」有什麼關係呢？看看新聞稿裡面的圖片：

看吧，真正的牛人就是這樣的！有乳牛作陪，這位「牛人」在電腦前面專心的分析報表，研究箇中的數據呢 :-)

由 jserv 發表於 10:27 AM | 迴響 (3)

介紹軟體發展的科普文章

最近我的 blog 似乎寫了一些沒營養的「無病呻吟」，明明就在休息，哪來專案壓力，更別說專案管理了，不過如果真的在趕專案，似乎更沒有時間發表感言 *笑*

剛剛閱讀 [cctg - yaocl，資訊焦慮的程式設計師，兼容科技與人文的園圃] 的 blog [軟系統的硬工程]，這的確是少見的 Software Programming 的科普文章，不僅提及概論性的軟體架構，更引導讀者去思考「為什麼要採用架構？」與「如何作架構？」的議題，也用很淺顯的文字，從建築的 Pattern Languages，切入到軟體工程與物件導向設計，推薦閱讀！

由 jserv 發表於 12:10 AM | 迴響 (0)

Free Culture 和賦予與支配的權利

休假的這個月，開始對 [Lawrence Lessig] 提出的 Free Culture 感到興趣，找了幾篇 blog 來配合閱讀：

Jedi's [Free Culture]
Jedi's [CC - 賦予與支配的權利]
Michael Dominic's [Weekly paradox]

在閱讀 [Lawrence Lessig] 的新書《Free Culture》前，可以先看概念性的 [簡報介紹] (Macromedia Shockware Flash)。

套句 Jedi 的話作結：

願自由文化與妳同在

由 jserv 發表於 05:59 PM | 迴響 (0)

幕後的英雄：談 Embedded Systems 設計

剛剛讀到 [Embedded System Design] 主編 Jim Turley 的文章 [A rose by any other name] (中文翻譯可參考 [為「嵌入式系統」正名] 一文)，給我頗多感觸。回到台北內湖瑞光路上班後，往往在下班時段除了見到車水馬龍的狀景外，抬頭張望還會看到許多「地標」，如仁寶大樓、光寶大樓、BenQ 大樓，以及其他大樓，可參考之前的 blog [內湖俯瞰]，周旋其中，更覺得自己的渺小，跟這些企業相比，我這個小小工讀生一點價值也沒有，我看到光鮮亮麗的商標與產品櫥窗，也見到琳琅滿目的消費性電子裝置，此時耳畔彷彿浮現出 BenQ 董事長李焜耀的專訪內容，基本上就是提到品牌與科技人才該如何在 IT 產業這個大舞台，演出最佳的戲碼。這些電子裝置，無論是消費性電子、主動與被動元件，還是車用移動電子裝置等等，都是所謂的 Embedded Systems，如果我們今天不看技術層面，而是核心價值的展現，就如 Jim Turley 的文章所提及：

Indeed, that's part and parcel of what makes an embedded system: one where you don't really see the technology. Contrast that with a computer (PC, Mac, workstation, supercomputer-take your pick) where the technology is the product. We talk about buying a 4-GHz PC with 512 Mbytes of RAM, but never about an 8-bit microwave with six interrupts and a 10-bit A/D. With computers, the guts come first (can you say, "Intel Inside"?), whereas embedded products are more coy and demure about their private parts. Embedded Systems 的定義無論是學界或者業界，都有相當多種說法，應用的範疇更是遠超出一般人的想像，但是當我們手上拿著行動移動裝置，頂多只會留意這是 Moto 的手機、iPaq PDA、mio 的 GPS 裝置、... 一類的直覺想法，第一眼所見還是品牌，但這其中到底有多少技術需求，如果不是身在研發單位的人員，實在是難以察覺。於是 Jim Turley 又說了：

That's got to be frustrating for many embedded engineers. Their work defines the product, yet the work itself goes unnoticed. Indeed, it's generally required to be unnoticed. An overly technoid product is often a failure in the market. It's the deceptively simple ones that fly off the retail shelves. 從歷史的軌跡可以看出，一個過分技術化的嵌入式產品往往會在市場中失敗，而簡單的產品往往非常易於銷售，這個概念在我成長的年代，Palm 與其他同時代的競爭產品就是很好的例子，Palm 並不是開 PDA 濫觴的創始者，但我們大多只記得 Palm，不是嗎？這方面的評論不需要我多說，但回到 Embedded Systems 產品的議題，設計開發人員的挫折與失落感相對來說，面對媒體的對於非技術項目高度 highlighting，更為明顯，Jim Truley 說的實在太精確，不禁讓我沾染一襲淡淡的憂傷：

If you work on a recognizable product like an F/A-18 Hornet, a Whirlpool refrigerator or a Nokia phone, you can proudly point to your work and say, "I did that." For most of us, however, the "product" is a bit too nerdy and unrecognizable for the general populace. Grandma can grok a gramophone, but a real-time preemptive multitasking scheduler might be a bit beyond her ken. 作為一個軟體開發人員，可能會為了需求完成 Realtime System Design/Architecture 後，興高采烈的把心得紀錄成 [簡報：Approaches to Realtime Linux] 與 [Priority inversion 簡介] 一類的文章，就算真正被掛上品牌，成為商品後，也很難向一般人介紹自己的工作成果與貢獻，頂多只能苦笑說「我過去的加班是值得的」，Jim Truley 文章中的這句話寫得頗貼切：

Yet we're left staring at our shoes or waving our hands when asked to describe an embedded system. We're embedded designers and programmers, but we can't adequately define what that means. The very term, embedded, is weighted with contradictory and incompatible definitions, and it's not a word most people use frequently. It's time for a better description of what we do. Jim Truley 提及 [Don Norman] (可參考：[Wikipedia 的介紹]) 的知名著作 [《The Invisible Computer - Why Good Products Can Fail, the Personal Computer Is So Complex, and Information Appliances Are the Solution》] 作為佐證。Donald Norman 在很多公司和教育機構擔任董事和理事，包括芝加哥設計學院，現為美國西北大學計算機和心理學教授，是 Nielsen Norman Group 諮詢公司的創辦人之一，曾任蘋果電腦公司先進技術部副總裁。他的著作包括《The Design of Everyday Things》、《Things That Make Us Smart》和《The Invisible Computer》，最近的著作《Emotional Design》強調情感在產品設計中所扮演的重要角色，他的目標不僅是幫助企業製造出滿足人們的理性需求，更要滿足情感需求的產品。在《The Invisible Computer》一書提到真正的電腦是極其複雜的，然而卻是無形的，也就是說嵌入式電腦無處不在，Jim Truley 更補充說：

讀到這邊，讓我這個工讀生嘴角揚起會心一笑，好似一個產業外頭貼著二次大戰時，美國徵招入伍的廣告：

We Need YOU
是的，電腦是無形的，潛在其中的技術更是無所不在，作為一個技術人員，這個工作雖然辛苦，也不會有光鮮的外表，或許可能會被媒體遺忘，但無形的電腦發展中，技術人員的貢獻與突破是不會被埋沒的，你的產業需要你！類似的說法，除了之前的 blog [我為何選擇工程技術，而非其他行業？] 外，[Embedded System Design] 的兩篇文章：[Naming Things] 與 [The Name Game Continues: Invisible Computing] 很值得一看，後者提到：

Bernard Cole 寫作的時間是 2001 年，可以想見四年後的今天，複雜度更是提高，不僅軟體如此，硬體亦然，這些 "invisible" 的技術對許多技術人員來說，已經到了難以掌握的局面，各種 Hardware-Software Co-Design 的途徑相繼被提出，而 Bernard Cole 也舉出消費性電子裝置多元化的今天，MCP 從 4-bits, 8-bits, 16-bits，一直移轉到今日普遍的 32-bit MCP，GPS 的例子更是無比複雜的黑盒子 (black box)，讓人面對這些設計與技術時，不免感嘆說：

will it make it possible for embedded devices to return to their former state of invisibility? 無論如何，每個 Embedded System Devices / Designs / Mechanicals 背後都有 "invisible" 的幕後英雄，或許該商品不見得能在市場上獲得良好的評價，但是建構的過程絕對是可敬的，感謝這些投入電子產業的前輩和參與其中的開發者，而 Embedded Systems 絕對是值得投入的領域，我也相信無論是從硬體、軟體、機構，還是其他層面切入，有朝一日可以如 Donald Norman 的新書《Emotional Design》，讓設計師努力與投入的熱情，可以感染於消費者，發揮設計所存在三個層面，感官層面 (Visceral)、行為層面 (Behavioral)，以及反思 (Reflective) 層面。

群於台北內湖瑞光路

由 jserv 發表於 04:56 PM | 迴響 (1)

Use the Source, Luke!

之前的 blog [Linux - 原力與你同在] 提到星際大戰裡頭 "Repeat the former steps - And may the source be with you always" 與 Linux 吉祥物企鵝的趣味展示，而剛剛在 [Free Electron] 找資料的時候，想起以前有看過類似的畫面，摘錄如下：

是的，這就是 Free / Open Source Software 最迷人的地方，一切的力量來源就是 "Source" 阿：

由 jserv 發表於 08:07 AM | 迴響 (0)

X server 的 low-level 觀點

"low-level" 這個詞很妙，通常程度比較粗淺的開發者 (Low-level Programmer) 會從高階應用 (High-level application) 切入，而經驗豐富後，就稱為資深開發者 (High-level Programmer)，卻往往可能是擔任 Low-level Application 的主力。

在 Linux Kernel 中，driver 如果要存取 I/O memory，如 X server 為了效能考量，通常會直接存取 Graphics Devices，那就須在有 CPU 能處理的 virtual address，而這也涉及 virtual memory 中 mapping I/O memory 的議題。Kernel API 中，有個 ioremap 函式：

#include <asm/io.h>

void *ioremap(unsigned long phys_addr,
              unsigned long size);
void iounmap(void *address);

而在 user-space 的應用程式如果需要對 physical address 作存取，可以透過 /dev/mem 這個特別的 device：

$ ls -l /dev/mem 
crw-r-----  1 root kmem 1, 1 2005-10-26 17:42 /dev/mem

不過 /dev/mem 事實上只能針對 non-RAM (I/O memory) address 作處理，透過 Kernel 設定的特殊 flags 來標示可存取的範圍，簡單來說，不會動到 physical RAM address，但這個設計對於 X server 是相當重要的。在 TinyX / FeeDesktop.org Xserver 中，[hw/kdrive/vesa/vm86.c] 處理了這部份的細節，以下是 X server 配置 video memory I/O 的 Vm86Setup 函式實作：

Vm86InfoPtr
Vm86Setup(int mapHoles)
{
    int devmem = -1, devzero = -1;
    void *magicMem, *loMem, *hiMem;
    void *hole1, *hole2;
    U32 stack_base, ret_code;
    Vm86InfoPtr vi = NULL;

    devmem = open("/dev/mem", O_RDWR);
    if(devmem < 0) {
	perror("open /dev/mem");
	goto fail;
    }

    devzero = open("/dev/zero", O_RDWR);
    if(devzero < 0) {
	perror("open /dev/zero");
	goto fail;
    }

    magicMem = MAP_FAILED;
    loMem = MAP_FAILED;
    hiMem = MAP_FAILED;
    hole1 = MAP_FAILED;
    hole2 = MAP_FAILED;


    magicMem = mmap((void*)MAGICMEM_BASE, MAGICMEM_SIZE,
		    PROT_READ | PROT_WRITE | PROT_EXEC,
		    MAP_PRIVATE | MAP_FIXED, devmem, MAGICMEM_BASE);
    
    if(magicMem == MAP_FAILED) {
	ErrorF("Couldn't map magic memory\n");
	goto unmapfail;
    }

    if(mapHoles) {
        hole1 = mmap((void*)HOLE1_BASE, HOLE1_SIZE,
                     PROT_READ | PROT_WRITE | PROT_EXEC,
                     MAP_PRIVATE | MAP_FIXED, devzero, HOLE1_BASE);
    
        if(hole1 == MAP_FAILED) {
            ErrorF("Couldn't map first hole\n");
            goto unmapfail;
        }
    }

    loMem = mmap((void*)LOMEM_BASE, LOMEM_SIZE,
		 PROT_READ | PROT_WRITE | PROT_EXEC,
		 MAP_PRIVATE | MAP_FIXED, devzero, LOMEM_BASE);
    if(loMem == MAP_FAILED) {
	ErrorF("Couldn't map low memory\n");
	munmap(magicMem, MAGICMEM_SIZE);
	goto unmapfail;
    }

    if(mapHoles) {
        hole2 = mmap((void*)HOLE2_BASE, HOLE2_SIZE,
                     PROT_READ | PROT_WRITE | PROT_EXEC,
                     MAP_PRIVATE | MAP_FIXED, devzero, HOLE2_BASE);
    
        if(hole2 == MAP_FAILED) {
            ErrorF("Couldn't map first hole\n");
            goto unmapfail;
        }
    }

    hiMem = mmap((void*)HIMEM_BASE, HIMEM_SIZE,
		 PROT_READ | PROT_WRITE | PROT_EXEC,
		 MAP_SHARED | MAP_FIXED,
		 devmem, HIMEM_BASE);
    if(hiMem == MAP_FAILED) {
	ErrorF("Couldn't map high memory\n");
	goto unmapfail;
    }

    vi = xalloc(sizeof(Vm86InfoRec));
    if (!vi)
	goto unmapfail;

    vi->magicMem = magicMem;
    vi->hole1 = hole1;
    vi->loMem = loMem;
    vi->hole2 = hole2;
    vi->hiMem = hiMem;
    vi->brk = LOMEM_BASE;

    stack_base = Vm86AllocateMemory(vi, STACK_SIZE);
    if(stack_base == ALLOC_FAIL)
	goto unmapfail;
    ret_code = Vm86AllocateMemory(vi, sizeof(retcode_data));
    if(ret_code == ALLOC_FAIL)
	goto unmapfail;

    vi->stack_base = stack_base;
    vi->ret_code = ret_code;

    memset(&vi->vms, 0, sizeof(struct vm86_struct));
    vi->vms.flags = 0;
    vi->vms.screen_bitmap = 0;
    vi->vms.cpu_type = CPU_586;
    memcpy(&vi->vms.int_revectored, rev_ints, sizeof(rev_ints));

    iopl(3);
    
    if(devmem >= 0)
	close(devmem);
    if(devzero >= 0)
	close(devzero);

    return vi;

unmapfail:
    if(magicMem != MAP_FAILED) munmap(magicMem, MAGICMEM_SIZE);
    if(hole1 != MAP_FAILED) munmap(hole1, HOLE1_SIZE);
    if(loMem != MAP_FAILED) munmap(loMem, LOMEM_SIZE);
    if(hole2 != MAP_FAILED) munmap(hole2, HOLE2_SIZE);
    if(hiMem != MAP_FAILED) munmap(hiMem, HIMEM_SIZE);
fail:
    if(devmem >= 0)
	close(devmem);
    if(devzero >= 0)
	close(devzero);
    if(vi)
	xfree(vi);
    return NULL;
}

在要到 /dev/mem 的 Mapping 後，我們來看 GLIBC 提供的 Memory I/O Mapping 的 API：

void * mmap(void *start, size_t length, int prot,
            int flags, int fd, off_t offset);
int munmap(void *start, size_t length);

這兩個函式允許 user-space 的應用程式，也就是探討的 X server 直接存取 device memory，這對於需要高頻寬 I/O 處理的應用程式來說相當重要，因為效能會比直接讀寫 /dev devices 來得快許多。所謂的 VMA (Virtual Memory Area) 就是來描述在同樣的 permission flags 情況下的 process virtual memory 的連續區域，以系統第一個 process，也就是 /sbin/init，來說，我們可以看看其 VMA 配置：

$ cat /proc/1/maps
08048000-08050000 r-xp 00000000 03:01 592323     /sbin/init
08050000-08051000 rw-p 00007000 03:01 592323     /sbin/init
08051000-08072000 rw-p 08051000 00:00 0          [heap]
b7dcb000-b7dec000 rw-p b7dcb000 00:00 0 
b7dec000-b7dee000 r-xp 00000000 03:01 1533       /lib/tls/i686/cmov/libdl-2.3.5.so
b7dee000-b7df0000 rw-p 00001000 03:01 1533       /lib/tls/i686/cmov/libdl-2.3.5.so
b7df0000-b7f21000 r-xp 00000000 03:01 1531       /lib/tls/i686/cmov/libc-2.3.5.so
b7f21000-b7f22000 r--p 00131000 03:01 1531       /lib/tls/i686/cmov/libc-2.3.5.so
b7f22000-b7f25000 rw-p 00132000 03:01 1531       /lib/tls/i686/cmov/libc-2.3.5.so
b7f25000-b7f27000 rw-p b7f25000 00:00 0 
b7f27000-b7f37000 r-xp 00000000 03:01 337350     /lib/libselinux.so.1
b7f37000-b7f38000 rw-p 00010000 03:01 337350     /lib/libselinux.so.1
b7f38000-b7f5d000 r-xp 00000000 03:01 337351     /lib/libsepol.so.1
b7f5d000-b7f5e000 rw-p 00025000 03:01 337351     /lib/libsepol.so.1
b7f5e000-b7f68000 rw-p b7f5e000 00:00 0 
b7f75000-b7f76000 rw-p b7f75000 00:00 0 
b7f76000-b7f8b000 r-xp 00000000 03:01 30973      /lib/ld-2.3.5.so
b7f8b000-b7f8d000 rw-p 00014000 03:01 30973      /lib/ld-2.3.5.so
bfb75000-bfb8b000 rw-p bfb75000 00:00 0          [stack]
ffffe000-fffff000 ---p 00000000 00:00 0          [vdso]

那麼，執行中的 X server 其 VMA 又是如何呢？我們來看看：

$ cat /proc/`pgrep X`/maps
000a0000-000c0000 rwxs 000a0000 00:0b 2432       /dev/mem
000f0000-00100000 r-xs 000f0000 00:0b 2432       /dev/mem
08048000-081d6000 r-xp 00000000 03:01 27050      /usr/X11R6/bin/Xorg
081d6000-08209000 rwxp 0018d000 03:01 27050      /usr/X11R6/bin/Xorg
08209000-09be8000 rwxp 08209000 00:00 0          [heap]
   ...
b3310000-b3510000 rwxs a4102000 00:0b 15299      /dev/dri/card0
b3510000-b39f0000 rwxs a4302000 00:0b 15299      /dev/dri/card0
b39f0000-b3bf0000 rwxs a4102000 00:0b 15299      /dev/dri/card0
b3bf0000-b3bf1000 rwxs a4101000 00:0b 15299      /dev/dri/card0
b3bf1000-b3cf2000 rwxs a4000000 00:0b 15299      /dev/dri/card0
b3cf2000-b3cf4000 rwxs f8c35000 00:0b 15299      /dev/dri/card0
b3cf4000-b7cf4000 rwxs 98000000 00:0b 2432       /dev/mem
b7cf4000-b7d74000 rwxs 90000000 00:0b 2432       /dev/mem
bfd7f000-bfd95000 rwxp bfd7f000 00:00 0          [stack]
ffffe000-fffff000 ---p 00000000 00:00 0          [vdso]

由 jserv 發表於 04:30 PM | 迴響 (0)

這個 blog 值多少錢？

裝了 Google Toolbar 後，就可以很清楚看到 [Jserv's blog] 的 PageRank 是 4/10，不過我對這個評比沒有概念，但看到 JeffHung 的 blog [我的 blog 值多少錢？]，也讓我好奇了，結果是...

My blog is worth $0.00.
How much is your blog worth?

哇！本 blog 竟然已經「無價」了耶，好奇妙。

由 jserv 發表於 11:39 PM | 迴響 (2)

何時該釋出版本

之前的 blog [鼯鼠與軟體專案開發] 帶著戲謔的口吻以闡述軟體專案開發所面臨的問題以及必要的技術素養。前幾天收到 [Purple] 的來信，提到她在公司中忙著趕專案進度，看描述的情況，讓我想起 [趨勢科技] 科技長－陳怡樺 (Eva Chen) 所撰寫的文章 [產品什麼時候要出貨－掙扎在 No problem 和 Impossible 之間的藝術] (作者名稱似乎筆誤？)，我開始想像，個子嬌小的 [Purple] 該不會如文章裡面提到的 Mandy 一般「壓力大又不服輸，常躲到廁所去掉眼淚，哭完了再出來繼續奮鬥」呢？或許還不至於落淚，但是趕出貨的壓力，的確是考驗工程師能力的基本試驗，誠如文章所提及：

回到正題，陳怡樺帶領傑出的 PC-cillin 團隊締造出許多亮麗的成績，而團隊中各個崗位該如何扮演適當的角色呢？文章提到：

對我而言，當個軟體公司的研發主管，軟體產品的出貨日期訂定一直都是個大課題，雖然有各種較科學化的方法來幫助決定，但是，某個程度上，這件事又是藝術而不是科學，有點像股票市場的預測，有很多系統化的方法可用，可又沒有哪個是一定對的，因為，歸根結底，人是最重要的因素，功能書切中點，選對工程師，再加上足夠的管理加鼓勵，有時的確能把 "Impossible" 變成 "no problem" 呢！

另外，由 [趨勢科技] 出版的《e趨勢季刊》，也有一篇值得參考的文章 [談成功的產品規劃]。這篇文章提到 Geoffrey A. Moore 所撰寫的《Cross the Chasm》一書已成為高科技公司必讀的開發聖經，陳怡樺亦大力推薦有志從事高科技產業的人閱讀這本書，她笑著說：

我們可以很清楚看到產品生命周期的各級使用者的分佈：有遠見的使用者 (visionary user) 率先採用，而後扮演意見領袖的影響力使用者 (power user) 採用，逐漸影響務實的消費大眾 (practical user)，最後，產品進入成熟期，連不懂科技的保守使用者 (conservative user) 都能使用。

回到 Free / Open Source Software (F/OSS) 發展，最近在閱讀 O'Reilly 的新書《Producing Open Source Software》，作者 Karl Fogel 有相當雄厚的版本控制系統的基礎，也貢獻 CVS、Subversion，以及 GNU Emacs 等主要 F/OSS 專案的發展，可自由下載的 [Chapter 4 : Social and Political Infrastructure] 從 "Forkability" 切入，這是 F/OSS 相當特別的發展模式，雖然開發不見得完全透明，但是在不違背原有授權方式的前提，建立 fork 是可能的且是正面的，作者提出的 "Benevolent Dictators"(BD) 與 "Consensus-Based Democracy" 兩個觀點可作為廣泛性 F/OSS 專案開發時程的描述，於是乎，我開始思考是否用「烏龜聖經圖」來描述其中的相似處呢？

一個極端的例子是 [WINE] 計畫，在訪談文章 [Wine will go beta next week] 提到終於要釋出 Beta 版本的 Wine，距離 Alpha 版本已經是 11 年的發展，這在軟體發展相當特別的，正如文中提及的「這項工作確實很困難，因為我們是在重複一個擁有數十億資產公司所做的工作；我們說Wine處於alpha是因為覺的仍有工作應該做，還可以讓它更好一些，但11年確實是長了些；我們即將發布0.9這並不是說Wine已經完美了，只是覺的它或許可以給用戶更好的體驗...」(翻譯來自 [軟件: 11年的alpha後，Wine 終於迎來了beta] 新聞)，跟其他 F/OSS 一樣，[WINE] 計畫面臨的問題不只是技術挑戰，更有授權與潛在的衝擊。是此，儘管我們可以由 [WINE] 計畫的發展看到「烏龜聖經圖」的影響，今日，我們可以在配備有 nVIDIA 顯示卡的 Pentium-4 電腦中，安裝 nVIDIA 最佳化的驅動程式到 GNU/Linux 環境中，並透過 [WINE] 順暢執行若干款原本只能在 MS-Windows 作業系統才能運作的電動遊戲，這一切當然是 visionary user 率先推動，參考諸多 power user 的意見，逐漸穩定且達到預期的水準後，推廣至 practical user，甚至撼動那些 conservative user 的看法，但是這一切卻是如此的漫長...

[jserv's homepage] 羅列一部分我所參與的 F/OSS 計畫 (TODO: 該更新內文了)，恰好我在這些計畫扮演著不同的角色，有時是 Project Manager、有時是 Developer、有時候是 QA Manager，而有時只是個 Contributor，這些過程對我的影響頗大，「何時該釋出版本」一直是有其他開發者或使用者會來信問及的議題，但過去我並未仔細思索，閱讀 [趨勢科技] 兩篇文章後，給我頗多啟發，或許可試圖建立一系列的系統性分析與參考。

由 jserv 發表於 09:25 PM | 迴響 (0)

xscope : 分析 X Protocol 的工具

最近給許多社群的朋友作了無償的演講，雖然連車馬費都要自己搞定，但是獲得的啟發可不是金錢能衡量的。至少我能從互動中大致知道新書撰寫的方向，並透過潛在的讀者群對 slides 作了 review，最重要的是認識許多新朋友。 (補充一下，如果能帶我到處亂走更好 :P)

上週六應邀去台灣，給了一場 [演講：綜觀 X Window System 新發展 (台中場次)]，在議程中途，Ted Chang 問了我一個有趣的問題，他希望能對 X Protocol 作出類似 sniffer 的監控動作，雖然我發展 Xorz 時做過類似的動作，不過一時之間忘記了，只好事後寫信給他：

寄件者: Jim Huang
收件者: Ted Chang
日期: 2005/10/23 上午 10:24
主旨: Greetings & Peep X Protocol

http://mvertes.free.fr/xlab/xlab.html

http://graphics.stanford.edu/papers/profiling/

現在就補上一份介紹。

[XLab] 是以 xscope 為基礎的一個應用程式，可以扮演 proxy X server 的機制，這樣一來如下面的示意圖：

因為 X Protocol 是 X Window System 的精髓，如果讓 xscope 居中斡旋，就有機會監看 X client 與 X server 之間的 traffic，以 xclock 做範例可參考以下執行畫面： (click to enlarge)

上圖可以看出 GC 的配置情況，當 focus 離開 X client (xclock running in DISPLAY=:1)，除了要維護 Context 的 event loop，還額外作了 REQUEST: CopyArea，這只是一個操作，事實上光一個 xclock 這麼簡單的 X client，我們就可以看到 X Protocol 的變化。

因為 xscope 是個沒有維護的老程式，我剛剛重新打包過，並施加一些 patch，作了非正式的版本 [xscope-1.1.0]，捨棄 imake，而改用 autotools，所以可以很容易用 ./configure ; make 一類的方式來建構。以上的測試方式為：

允許 TCP connection，使用 xhost +localhost 來避免 xauth 問題
打開新的 X Terminal，比方說 rxvt，在裡面打 xscope -i1
另外打開新的 X Terminal，假設您用 bash，在裡面打 DISPLAY=:1 xclock
等 xclock 跳出來後，觀看前面的 X Terminal 變化

不過 xscope 或 [XLab] 都必須在 proxy X server 模式下使用，如果要更完善的動態追蹤，就得用 Dtrace 一類的新設計，這後面的學問頗複雜，詳細的議題，可參考 John Danskin 與 Pat Hanrahan 共同撰寫的 [Profiling the X Protocol]。

由 jserv 發表於 02:07 PM | 迴響 (2)

演講：Linux 國際化與區域化發展

之前的 blog [Graphics in Embedded System] 提到南下到台南社區大學，為 [TnLUG] 分享 Embedded Systems 中的圖形需求與解決方案，過了半年，又有新的演講分享主題，引述 [新聞公佈]：

你正打算在 Linux 上做多國語言軟體的發展嗎？究竟在 Linux 上頭如何實現？

當你想幫助台灣 Linux 成長而卻有沒有技術的時候該怎麼辦？協助翻譯或許是您另外一個更好的選擇。

本月 TnLUG 請到 Jserv 為台南的學員開講，jserv 從事多項 Linux 上的軟體開發與協助測試。歡迎大家來取經。

Topic: Linux 國際化與區域化發展
Aganda:
- 邁向國際化的挑戰
- 為何國際化如此重要？
- UNIX i18n 架構與 Linux 實現
- 國際化與區域化：技術觀點
- Case study
* CJK 通用漢語
* 泰文資訊化處理
* 希伯來文與阿拉伯文
- 如何參與國際專案？

時間：2005 年 10 月 29 號（六）下午 2:00 ~ 5:00
地點：台南社區大學二樓電腦教室
講師：jserv
費用：0 -
報名網址：http://tnlug.linux.org.tw/join.php

必須說明的是，我不是這方面的專家，只是恰好有機會接觸到，所以我會提及目前國際化 (Internationalization / i18n) 與區域化 (Localization / L10n) 的挑戰，會先由技術角度切入，並佐以文化方面的落差，之後再來探討我們現有的解決方案與提案。

這大概是我下半年假期中的最後一場演講，之後大概就要「息影」一段時間，努力衝刺 hacking 了，請多指教，謝謝！

由 jserv 發表於 11:51 PM | 迴響 (0)

言多必失

雖然玩電腦網路有一段時間了，可是「出道」還是最近的事情，在公開的 BBS 發表謬論、在公開的論壇亂寫，以及在 WWW 張貼許多不成熟的材料，雖然還是有可取之處，但整體來說，錯誤百出，這裡要對造成的潛在損失致上歉意。從花蓮度假回來，瞥見 [JeffHung] 前輩的 blog [雜談 2005] 再度印證「言多必失」這句話，小時候在 BBS 上閱讀 JeffHung 前輩提出的許多計畫與提案，讓愚昧的我眼睛為之一亮，就這樣陸續讀了不少 post 與他的創作，不過我一直沒有打過招呼...

如今雖然被指正，不過至少也釐清過去的疑點，小時候一直在猜此 Lady 到底是否為彼 Lady：「淑女之所以為淑女，絕非因為君子好逑」，引用該 blog 的說法：「我認為電腦之於個人，至少對於具備有些許資訊掌控能力的個人而言，最適切的形式，莫過於一台帶有 agent 色彩的 FreeBSD server，主理大小事，搭配作為操控介面的 Windows 終端，作為主要存取、呈現、工作與實現的介面。前者就是主內的 lady，後者就是主外的 gentleman，是台可以帶著到處跑的 notebook，lady and gentleman，合作愉快。若是不小心多了台 baby PDA，那可不是我的錯。」這時才恍然大悟。

在花蓮服兵役時，作了些自我要求，每天維持一個半小時的閱讀習慣並紀錄心得與所見所聞，JeffHung 前輩過去的文字當然也給我頗多啟發，剛剛想起過去寫給 [ct 小貓] 的信件中，2005-08-25 提到：(click to enlarge)

因為是大頭兵，當然不可能會有 Internet 可以使用，這些筆記多半是參考書面資料與零星記憶所拼湊的，而我甚至在兵役的假期中，試圖利用寶貴的時間透過 [Cocoon] 來作 Concept-proven 的小玩具，實現「可黏貼的網路內文」系統，不過後來就沈浸於 Embedded Systems 中，無瑕去深入思考了，反倒是現在的工作項目多半在兵役期間，建立思想體系的雛型，或許，這是來自 Ludwig Wittgenstein 在第一次世界大戰時期服役時，仍可發展出哲學邏輯理論的啟發吧？

這些日子來，透過網路認識許多新朋友，也接觸到以往認為遙不可及的前輩們，我這個井底之蛙可真是嚇著了，也免不了「言多必失」的情況，不過如果不表達出來，有可能因此沒機會受到眾人的檢視與進一不的驗證，不是嗎？當然，還是不能亂說話 *笑*

由 jserv 發表於 11:11 PM | 迴響 (1)

與淑女有約：內湖到北宜公路的散步

前天 (Oct 15，周六) 跟 robben 和一群來自 [樂山水] 的朋友去爬新店二叭山後，繼續展開「健康假期」計畫。昨天原本要跟 [Debian@Taiwan] 的朋友一起去福山，不過到新店的時候腳抽筋，所以我就脫隊了，但我感到相當不甘心，於是在休息一段時間後，抱著伏爾泰文選，心中彌漫著自由氣息，是的，我要往前衝，於是展開以下的故事。

今年三月份的時候，用了台幣一千出頭買了 GIANT 淑女車 (沒有變速功能，除了有 "GIANT" 的 mark，大概就沒什麼好說的)，這時候讓我們來考據一番。如同我們的認知，「淑女」或許出自《詩經》的首篇《關睢》之中，一句「窈窕淑女，君子好逑」的共鳴擴及兩千年後的今天，很多從事資訊領域的朋友都對於「淑女」有頗大的情感，比方說 [JeffHung] 前輩就以 "Lady BBS" 來命名他偉大的 BBS 計畫。如果要用一句話來描述我個人的話，就用「平凡又瘋狂的人」吧，不僅每日 [騎腳踏車上下班]，而且時常如 blog [御風] 一般獲得物外之趣，現在假日的活動中，也主要由這台淑女車為主角，在 [jserv的相簿] 拍了幾張「美妙的交通工具」，與其說「淑女車」，我寧可稱呼為「淑女」，所以昨天的散步，就是在這位「淑女」相伴下，處於「平凡」的環境中，也是能作些稍微「瘋狂」的事情。

這次全程騎腳踏車，而且是台幣一千元出頭的淑女車，終於創下個人紀錄 (好像沒啥好驕傲的，但看到一路上只有我一個人騎淑女車，感覺也很爽 :P)。凌晨五點多從台北內湖住所 (康寧路一段) 出發，經由南港往八德路前進，轉新生南路，後來經過台大，由羅斯福路，一路往新店方向邁進：(click to enlarge)

「淑女」後方有個鮮明的 "J" 字樣，是阿，名花有主了。(click to enlarge)

不慎於新店捷運站附近腳抽筋，頗疼，只好休息與按摩，隨身有攜帶伏爾泰的哲理美文集：(click to enlarge)

爾後繼續奮起，以「狗爬」姿勢邁進：(click to enlarge)

路經國史館：(click to enlarge)

抵達北宜公路口：(click to enlarge)

路程很舒服，逐漸忘卻腳傷，在北宜公路三段時稍作休息：(click to enlarge)

之後就再繼續衝，在過坪林的時候發生腳踏車脫練，有了上次 blog [讀聖賢書所學何事？] 的經驗後，自己當黑手把淑女的鏈帶用力挪移好，不過雙手因此沾滿油漬，不便使用這台 SONY T33 相機，繼續努力往前騎，某些路段相當窄小，而砂石車又頻頻穿越，害我只好暴力的搶車道，不然就是得下車用雙手「示警」，才能比較順暢的通行。休息時認識一位自行車騎士，他一直「稱讚」(帶有警告意味) 我的勇氣，並且幫我評估在北宜公路的里程 (為了避免自己怯場，我連地圖都沒看就上路)，看來已經超過 27 公里。

今年六月在 barrett 兄、duan 兄、精靈姊姊，以及其他朋友的陪同下，進行蘇花之旅，經過北宜公路時，我就很希望有機會能用這台「淑女」穿越，如今終於完成一部分的路程了，可惜最後飲水用完，為了安全理由回程。腳傷也變得嚴重，一路繼續硬撐，有點擔心無法安全抵達內湖住所，一路完全沒休息的猛踩踏版，下午一點半回到內湖住所。

這趟散步很舒服，下次應該多作些規劃，而不是臨時起意，但這也說明，騎單車不見得一定要像 [廖長輩]、[SoG 學長] (光他上次送我的高級口罩的價格就可以買好幾台淑女車了耶)，或者其他專業的自行車騎士 (之前提到在北宜公路上遇到的那位，他全身的裝備價值比我一個月的薪水還高) 才能上路，跟這物美價廉的「淑女」同遊不也愉快呢？ :-)

引用我在 [#dot@freenode 語錄收集中心] 的一句話作結：

警告：我每個月都有投保一定金額的保險費用，本文所敘及的內容僅供參考，不作任何擔保

由 jserv 發表於 11:16 AM | 迴響 (2)

Fiasco-UX Microkernel

前幾天追了 [Fiasco-UX Microkernel]，現在終於在 Debian GNU/Linux 上運作了：

要介紹 Fiasco-UX Microkernel，就必須提到 L4 Microkernel，比較新的作業系統教材應該會提到 L4 的設計 (實在不是我要說，某本封面有恐龍的書籍，似乎一直在 "Concepts" 打轉，好歹介紹一點 L4 這個第二代的 microkernel 吧？)。[Fiasco] 是 L4 v2 與 x0 的具體實作，以 x86 為主要支援的架構，同時擴充性相當高，已經有建構於 Fiasco/L4 基礎上的 Linux / RTLinux multi-server 支援，在網頁上則提到一些重要的資訊：

Motivation

can be studied and maintained better because it has been written in a high-level language (C++)
has better real-time properties than L4/x86 because it can be preempted at almost any time
is freely redistributable under the GPL

而 [Fiasco-UX Microkernel] 就是一個更有趣的計畫，仿效 [User-Mode-Linux Kernel] 的設計，將 Fiasco 移植到 Linux 上，作為一個普通的 Linux process，這樣一來，對於 fast prototyping 有很大的助益。[Fiasco-UX Microkernel] 內建的 Jdb debugger 功能非常強大，可以動態的追蹤大多數的系統資訊，互動性也高，對於理解 L4 microkernel 運作機制有相當正面的協助。

由 jserv 發表於 01:28 AM | 迴響 (0)

Orz.Debian.Org.Tw成立

#dot (Debian@Taiwan IRC Channel) 真是一個神奇的地方，話說昨天許多熱情的朋友一如往常在閒聊，而我突然想到一個點子：

10月 12 22:29:47 jserv--        對了，搞個 Orz.dot 吧
10月 12 22:30:02 jserv--        然後請 bibot2 不定時整理 irc log 上去
10月 12 22:30:03 jserv--        :p
10月 12 22:30:32 jserv--        [Orz] 這是要給 bibot2 丟到 orz.dot 的內容
10月 12 22:31:16 jserv--        「DOT 年度語錄」

沒想到在我盥洗完畢後，看到這個訊息：

10月 12 22:56:18 kanru  [orz] 測試測試
10月 12 22:56:27 kanru  XD
10月 12 22:56:39 kanru  http://orz.kanru.info/
10月 12 22:56:49 *      kanru 真的去寫作業
10月 12 22:56:55 chihchun       ....
10月 12 22:57:01 chihchun       這麼快就寫好。
10月 12 22:57:15 chihchun       那我是不是設定 cname orz.dot 到 orz.kanru.info ?
10月 12 22:57:58 kanru  隨便.. XD
10月 12 22:58:15 chihchun       done.
10月 12 22:58:42 kanru  真快

這時候我只能發出讚嘆：

10月 12 23:07:26 jserv--        哇！剛剛洗完澡就弄好了
10月 12 23:08:11 jserv--        
                  chihchun = DOT之伺服器達人
                  kanru = DOT之技術魔人
                  jserv = DOT之Orz總監

所以，這裡以「DOT之Orz總監」的身份宣佈，[Orz.DOT / #dot@freenode 語錄收集中心] 正式成立。

因為這是要給網友放一些「天外飛來一筆」的語錄，在內容上難免有些 Orz... :P

[Debian@Taiwan] 就是有這些熱情的朋友，所以才會有 [許多計畫] 和多樣的服務 (APT, wiki, planet, forum, cddp, irc, game, ...)，套句 AndrewLee 在 #dot 的話：

「多些人參與，會比較好玩嘛」

由 jserv 發表於 09:51 AM | 迴響 (1)

「kernel 2.6 與桌面環境的整合」簡報上線

如之前的 blog [心得分享：kernel 2.6 與桌面環境的整合] 所提及，今天去台大分享 Linux Kernel 2.6 與桌面環境整合的新進展和之中的技術介紹，簡報可 [在此取得] (PDF文件)，比較遺憾的是，許多技術細節並未詳細介紹，但相信可以對相關的技術發展與整合，建立一些基本概念。

歡迎指教，謝謝！

由 jserv 發表於 11:55 PM | 迴響 (2)

桌面系統效能調整

這個標題好像不是取得很好，因為很多人會誤解為某些同名書籍，裡面一堆圖片，要你按圖索驥的「東按西摸」的調整桌面，不過這裡說的是效能方面的議題，就算有圖，也大概只是 profiling chart。

去年我曾在之前的公司花了三個半月在調整 Linux/X11-based Desktop，當時已經能夠在 VIA/x86 400MHz 的機器上，運作許多 Thin client connnection program，Web connectivity suite，甚至是 Office suite，還外加一些 Eye-candy / Desktop Agent，整體的 storage size 是控制於 128 Mb 內。當然功能性是很重要的考量，但是沒有好的軟體效能，勢必讓硬體的選擇變少，成本的因素更是如此。

當時的效能調整的資料還很少，大部份還是用 gprof 搭配許多臆測做出來的，最後作了一個 patchset for gtk+-2.2 (Improved renderer, memory allocator, MMX-optimization, Xi18n hack)，不過現在看來似乎沒什麼意義了，因為 GTK+ 都進步這麼多了 :)

可以參考的資料有：

Lorenzo's [Analyzing and Improving GNOME Startup Time]
Rodrigo Moya's [http://blogs.gnome.org/view/rodrigo/2005/10/06/1]
Federico's [Making GNOME Fast]

看來 GTK+/GNOME 未來的版本真令人期待。

由 jserv 發表於 04:23 PM | 迴響 (1)

內湖俯瞰

昨天慫恿 robben 去爬內湖的小山，我們從圓山上山，然後從劍潭寺旁的小徑下山，回程 robben 用模擬廣角的方式拍攝了內湖俯瞰圖： (點縮圖可以看全圖)

注意：全圖有 3.7 Mb，解析度為 17774x1451，建議另存新檔後再觀看。

可以很清楚看到幾個重要的地標：內湖科技園區的幾家大樓 (如 Ali、BenQ，與 LiteOn)、美麗華、一高，與麥帥二橋等。這些區域都在我的生活圈內，不過能一眼俯瞰的感受又不一樣了 :)

誠如之前 blog [早安！台北] 所言：「北上工作 ... 一直寄居於台北內湖，我總是出自內心的對台北感到一種厭惡，印證小時候在鄉下耳聞的疏離感、忙碌的節奏、污染、陌生、...，真正的問題是，我不願意試著理解這個城市。其實，只要靜下心，慢慢體會，其實台北還不錯」

午安！內湖。

由 jserv 發表於 12:24 PM | 迴響 (0)

Liferea 抓狂了

之前的 blog [神奇的數字] 提到現在我電腦中的 Liferea 已經承受天文數字等級的負荷，現在這個情況越來越嚴重。昨天編譯 GCC 4.1-mainline 的時候發現，系統已經緩慢到無法運作，才發現 Liferea 在搞鬼：

看來這下需要取捨了。

由 jserv 發表於 10:08 AM | 迴響 (2)

XML + CSS

以前很迷 XML 相關的技術，還在 Java 週報投稿過一篇關於 [Apache Cocoon] 的文章，因而獲得 JavaTwo 免費入場券，不過我已經四年沒有從事 server-side 的技術開發，大概也忘光了。

下午跟 robben 爬山回來，想到答應 Purple 要處理一個 XML 的小問題。之前的 blog [Beautiful Solitude] 提到 Purple 與她的 blog，正如「迴響」所及，現在已經「消失」了，不過網際網路神奇之處，在於資料是共享的，所以我從 [Liferea] 的 cache 中找出舊的備份，但是真正的麻煩才開始。用 XML tree viewer 看了之後，發現 cache 雖然是 XML format (valid)，但是其 data source 的表示方式讓我暈倒：依據 [Liferea] 的設計邏輯，原始的 RSS 經過訂閱後，會擷取個別 item，並轉換成 non-XML data stream，然後餵給 Gecko (Mozilla / Firefox) 或 gtkhtml2 作顯示，所以呢，我們要的「牛肉」根本不在 XML nodes 中。

所以呢，剛剛順便複習 libxml2 & regex Programming，動手寫一個 ugly C code 來作暴力轉換，寫到一半發現，其實可以善用 XML + CSS 來處理，於是，現在的版本：[Beautiful Solitude] (beautiful-solitude.xml)，這是用最小的修改 (刪除兩行 XML) 的方式來作，當然，真正解決問題的方式，應該是透過 XHTML 來作，不過看來暴力轉換就是必要的 (code 也寫好，但是看起來頗亂)，感覺很不優雅 :(

Reference: [XML: Presentation with CSS]

由 jserv 發表於 08:42 PM | 迴響 (0)

工讀生的工作環境

在部門搬遷前，同事 [Simon] 幫我拍了一張工作環境的照片： (click to enlarge)

可以看出我這個小小工讀生的桌面放了一些「戰利品」(去參加研討會或展覽會場拿到的)，左邊是 Evaluation Board，運作一些奇奇怪怪的作業系統與軟體，中間是 Desktop，跑 MS-Windows XP，右邊 Laptop 則是跑免費好用的 Debian。

我很依賴 wiki 與 issue tracker，前者我用 [PhpWiki]，後者就用 blog [Roundup -- 簡單好用的 Issue Tracker] 所提及的 Roundup，寫文件用 [OpenOffice.org]，但是收發 email 要用 MS-OutLook，只是因為我從來就搞不清楚公司網路設定方式。

比較有趣的是，主要的軟體架構設計圖都是我用手繪製的，上面的照片張貼兩份，當我 coding 的時候，一邊看著錯綜複雜的圖形關係，一邊用指尖鍵擊，腦海逐漸浮現專案的輪廓...

由 jserv 發表於 11:17 AM | 迴響 (2)

再談自由軟體授權

之前的 blog [簡報：自由軟體授權分析] 張貼後，對岸的 [Slashdotcn] 也作了一份介紹的新聞：[IT: 自由軟件授權方式探討]，因而認識很多新朋友，甚至成為他們的諮詢對象，看來下個版本要註明「免責聲明」了 *笑*

IBM developerWorks 刊載一篇由 Linux Magazine 主編 Martin Streicher 所撰寫的文章 [Open source licensing, Part 1: The intent]，相當詳細的介紹授權、智慧財產，以及軟體開發者採用的授權方式等議題，很值得一看。開啟 License 濫觴在於 1662 年，後來經過 1710 年的安娜法案 (Statute of Anne) 確立其法律依據，隨後 1774 年大不列巔國會建立 Copyright 的標示與相關的法案，明確來說，"Copyright" 是從印刷複製的權利做出發，而安娜法案則是確立作者的行使權利與要求的合理性，是此可以避免未授權的複製品 / 印刷品 / 仿冒品，Martin Streicher 這麼提到：

Today, nearly 300 years after the Statute of Anne was passed into law, the same fundamental tenets of copyright remain, and the rights of an author prevail as an essential impetus to create new works. Indeed, copyright has been expanded frequently and greatly since 1710 to comprehend emerging technologies, to protect innovative forms of creative works of all kinds, and to protect the author's entitled monopoly. 所以我們可以發現，歷經三百年的演進，安娜法案的精神持續存在，只是轉換成各式的授權與法案條文罷了。並且舉了幾個著名的案例：1886 年 International Copyright Act 賦予作者對於作品的翻譯版本衍生物的排除權利，在 1911 年，British Copyright Act 更加強了版權保護範疇，以適用於聲音紀錄與建築架構上，更甚者，1976 年，U.S. Copyright Act 把版權保護延伸到未出版的創作。

"The privileges of the software developer" 這段我節錄翻譯如下： (很多法律用詞感覺很生澀)

生產創作的複製品並予以銷售的權利，包含電子複製品與可執行的二進位檔案
建立衍生創作的權利，這裡衍生創作的規範是指以既有或者由作者核定的原始創作為基礎的創作
有權以轉售或移轉版權認可的權利到其他對象

之後的 "A license to code" 與 "Choosing the right license" 就是本文重點了，也提到 OSI (Open Source Initiative) 是如何看待處理的 Copyright / License。在 Lawrence Rosen 的著作 [Open Source Licensing: Software Freedom and Intellectual Property Law] 提到五個基本的意圖：

Licensees are free to use open source software for any purpose whatsoever.
Licensees are free to make copies of open source software and are free to distribute those copies without payment of royalties to a licensor.
Licensees are free to create derivative works of open source software and are free to distribute those works without payment of royalties to a licensor.
Licensees are free to access and use the source code of open source software.
Licensees are free to combine open source and other software.

Martin Streicher 在 [Open source licensing, Part 1: The intent] 即針對這五個項目作了眉批，最後他提到：

All these intentions are affirmative and hardly bar the licensor or licensee from imposing additional terms. For example, a licensor could ask for reciprocity -- that a licensee must provide the software according to the same terms it agreed to -- and still remain open source software. A licensee can profit from the sale of the software. A licensor can provide the software under more than one license, perhaps one that is open source and one that's proprietary. Certainly, while the latter license is not an open source license, an open source license does not preclude other simultaneous licensing terms. 在真實情況下，所謂的 NDA 或者軟體的授權方式多少會伴隨「互惠條款」的規範，因為價值存於這樣的著作不限於程式碼本身，其隱含的專利或技術項目也是另一項重點。舉例來說，之前 blog [簡報：Approaches to Realtime Linux] 提到 [RTLinux] 的創作者 [FSMLabs] 雖以 Linux Kernel (licensed under GNU GPL v2) 為基礎開發，但 [FSMLabs] 在 RTLinux 中擁有 US-Patents 5,995,745，所以在我們 [下載 RTLinuxFree 時]，會要求同意 GNU GPLv2 與 [FSMLabs] 的 [Open Patent License]，就是聲明其專利的有效性與衍生著作的規範，如果採用 [FSMLabs] 公司的其他 Realtime solutions，則可依據「互惠條例」進行開發。

延伸閱讀：

由 jserv 發表於 09:47 AM | 迴響 (0)

鼯鼠與軟體專案開發

「鼯鼠」跟「軟體專案開發」之間有什麼關聯呢？在解釋匪夷所思的標題之前，先來探討鼯鼠。

圖片來源： http://wcm.gdf.gov.cn/dzw/upimages/19.gif

圖片來源： http://www.e-earthgeo.com/summary_pic/166/166050.jpg
稍早曾閱讀過李美嬅所撰寫的 [教師抨教改：下一代不如鼯鼠 ] 一文，該老師擔憂，在教育改革的多元化，與課程廣度的變化衝擊下，青年學子是否會連「五技而窮」的鼯鼠還不如呢？沒有受過高等教育的我，沒資格評論教育改革，但我對於「五技而窮」的出處感到很好奇，查閱了一些資料。《荀子‧勸學》述及：

「螣蛇無足而飛，梧鼠五技而窮。」相關的注釋：

[教育部成語典：梧鼠技窮]
[清風閣：梧鼠技窮]
楊倞˙注：梧鼠當為鼫鼠。
宋朝黃庭堅詩：「五技鼯鼠笑鳩拙」。
《爾雅》：鼯鼠，形似松鼠，尾長，腹旁有飛膜，目前肢之腕起，至後肢跗部而達尾根，能在樹上飛躍。
《說文》將鼫鼠稱為「五技之鼠」，並說它的「五技」是：「能飛不能過屋，能緣不能窮木，能游不能渡谷，能穴不能掩身，能走不能先人。」
螣蛇是一種龍，沒有腳，但能騰雲駕霧，飛游空際。

所以，後世比喻什麼都懂一點、卻又什麼都不甚高明，就稱作「梧鼠之技」或「梧鼠五技」。鼯鼠有五種技能，但都不專精：能飛卻不能上屋，能緣卻不能窮木，能遊卻不能渡谷，能穴卻不能掩身，能走卻不能先人，荀子用語即警惕學子要用心專一，即可事無不成。

然而經典之所以為經典，在於其永遠無法完美實現。作一個學問研究者，不可能只對一個領域或一個項目感興趣，難免會涉及非主要專長項目，換個角度來想，只專注單一技術的者，有可能讓自我的視野受侷限，並且該圈子將會越來越窄，相反的，我們很多時候都需要扮演「鼯鼠」的角色。

Fredrick P. Brooks Jr. 的經典著作《人月神話》中最重要的概念就是「概念整體性」(conceptual integrity)，用以貫穿全書，大意就是說寧可少添加雜七雜八的功能 (anomalous features)，也應該保證，整個系統體現的是完整的一套設計理念。這幾個字看起來理說當然，但等專案進來時，就不是這麼一回事，畢竟「出錢的是大爺」，我們必須竭盡所能的滿足客戶的需求 (well，你也知道，這句是官話)。就算是我這種不入流的工讀生，也會被指派成為一個計畫的專案經理，或者計畫執行人，既然領老闆給的薪資，就要謹記於心：「不賺錢的企業是罪惡的」。但是在軟體的「蘊釀」過程中，各級決策者都很容易產生強調「功能」而逐漸忽略「概念整體性」(諷刺的是，我們的確可以看到書架上擺放著《人月神話》一書)。

為了時程安排 (說難聽一點就是：怕客戶抽單)，我們 (既然作為一個「聚合體」，似乎就難脫離關係) 會在專案初期先做出 "Demo" 版本，以一個沒有妥善規劃的 codebase 出發，趕在 deadline (對每個趕過專案的開發者來說，"dead"-line 一詞實在太妙了) 前做出包含大量「功能」、但就整體而言，卻是不知所云的系統。好，現在客戶決定要下單了 (按：[Jouston] 透露說跟日本客戶打交道，要會灌酒，意識不清的情況下，規格標準才不會那麼嚴苛)，有資金下來，身為專案經理或者是軟體架構師，就需要開始好好規劃「真正」的系統設計。《人月神話》提到的「第二版效應 (the second system effect)」，簡單來說，在設計第一版系統時，往往出於較弱的自信心以及量力而行的考慮，儘量剪裁要實現的功能數量，但是當第一版系統成功發布，也就是剛剛提到的 "Demo" 版本，開始第二版的設計時，隨著自信心的增強，大量以前被壓制的提議都會重現，設計師在塞入新的功能時也會不再那麼保守，很多情況下，這導致一個臃腫而缺乏「概念整體性」的第二版系統，更可能釀成由於一兩個附加功能的實現難度，而導致整個系統開發推遲、甚至難產的事例。

所以，Brooks 認為首先要區分產品人員和開發人員：architect 和 implementor。為確保「概念整體性」，做出決定的必須是少數，甚至一個人。另，在開發過程中可以考慮「外科手術式」的開發團隊，明確來說，就是由唯一的「手術師」以及多個助手、測試人員、專案聯絡員 / 工具 / 管理員、秘書等組成的隊伍。Brooks 在其他的章節裡說過，提高軟體項目的質量的最好辦法之一，就是找到合適的人，也就是說，「偉大」的設計師和普通設計師之間的差別，比採用任何先進開發工具 / 方法論 / 管理模式前後的差別都要大。我想，這些經典相當明確的指出軟體開發的問題，而且歷久彌新，但我的疑惑是，如果有一天我們被拔擢成為前述的「手術師」，該以何種態度勝任呢？

這時候，我們可能要扮演「鼯鼠」的角色。每個人都有其長處，而且我們可以假設團隊中的每個人都有某項凌駕於其他成員的能力，一個軟體架構師或者專案管理者，面對小組成員的工作切割、專案時程規劃、技術議題，以及潛在的 blackbox (通常是需要自 3rd-parties 取得的技術或專利項目，之中有很多非技術議題)，就某些角度來說，架構師樣樣不精樣樣通，雖然無法登上個別項目的巔峰，但卻可更易使身段柔軟，更貼近專案成員。就算該架構師在某個技術領域耕耘多久，有多漫長的從業經驗，但需要考慮一個很重要的原則：「尊重做事的人」。為了顧及大局，一個架構師很難事必躬親，畢竟還可能要面對來自客戶的衝擊，更要協調箇中的衝突，每個人被安排任務後，必定有其價值，也會有其範疇，經過適度切割與交叉性的驗證與合作，才能逐漸在渾沌中逐漸勾勒專案的樣貌，但問題總是發生在成員間的交戶作用中，架構師必須以「鼯鼠」的姿態，事先將某個技術項目分派給成員，並且要在執行過程中，用不甚專精的技能基礎，來檢閱與分析執行效能與進展。

對我來說，自由自在般的生活，逐漸開拓自己的格局，才是我想要的，無論我今天負責的工作規模是如何成長、職稱與工作內容是怎樣被提升，讓我保有一點自身的缺陷，姑且作隻樣樣不精樣樣通的鼯鼠吧 :)

由 jserv 發表於 03:24 PM | 迴響 (1)

隨手畫

「隨手記」系列寫得有點悶了，而且有流水帳之嫌，所以改個主題，現在變成「隨手畫」： (click to enlarge)

突然很想飛離這個既定的生活圈，脫離這些限制，遙望遠方的飛鳥，試著幻想自身的神遊，是此，拾起素描筆作此創作。

群於台北八德路
Oct 3, 2005

由 jserv 發表於 11:56 AM | 迴響 (0)

電腦音樂與 MIDI 介紹

在 letoh 的個人板看到我以前的導師 - [蘇文鈺教授] 開的課程：

發信人: bff.bbs@goodguy.csie.ncku.edu.tw (好想永遠這樣), 看板: IIE
標  題: 「電腦音樂」課程投影片下載                                
發信站: 醉資心BBS (Tue Oct  4 14:18:35 2005)
轉信站: bbs.vision!news.ncku!news2!ccnews.ncku!WOLF
Origin: goodguy.csie.ncku.edu.tw                   

蘇文鈺老師的「電腦音樂」課程投影片已開放下載，
計有下列                                      
1.Introduction
2.Principles of sound
3.Basic acoustics    
4.Introduction to MIDI
5.MIDI basics         
6.MIDI message
有修課的同學可至SCREAM實驗室網頁( http://scream.csie.ncku.edu.tw/scream/ )下載。
--
※  Origin: 成功大學資訊工程學系[醉資心BBS] 
◆  From: bff.csie.ncku.edu.tw

Ref: [SCREAM 實驗室網頁] 中關於此課程的 [簡報下載處]。

喔，對了，最近 [Planet Classpath] 中，Anthony Green 介紹了最近 Free Java 的 MIDI 實作，可參考 [Demo app and Kepler’s] 與 [GNU Classpath MIDI happenings]。

由 jserv 發表於 12:53 AM | 迴響 (1)

心得分享：kernel 2.6 與桌面環境的整合

應葉平教授的邀請，我將在下週二在台大迴廊咖啡館分享一個主題：「kernel 2.6 與桌面環境的整合」，詳情可參閱 mailing-list 的信件 [TOSSUG 心得分享時間： kernel 2.6 與桌面環境的整合] 與 [TOSSUG (Taipei Open Source Software User Group)] 的 wiki [心得分享]。

以下引述相關資訊：

時間：10/11 星期二，分享時間 7:30pm 開始，聊天時間到十點打烊為止。
主題：簡介 Linux Kernel 2.6 與桌面環境的整合
分享人：jserv
摘要：
地點：台大體育館的迴廊咖啡（[地圖]），有免費的無線上網，請別把 notebook 忘在家裡。

以上，歡迎有興趣的朋友前來指教，謝謝！

由 jserv 發表於 12:04 AM | 迴響 (0)

C++ 與 Java 的 ABI 議題

在某個時間點 (姑且稱為 D) 開始，在我從事程式設計時，不再只考慮能否運作或結果是否正確的議題，相反的，必須將效能、擴充性，以及與其他軟體元件的整合議題列入重要考量，而在 D + K 時，我就鮮少從頭撰寫一個應用程式。這之間的落差 (K)，讓我開始思考如何以既有的軟體元件或軟體設計出發，經過「適度」的修改與調整，賦予其新的價值，這說來簡單，但是作起來不容易，很多時候重寫還可能比較快。

然而很多時候，因為許多因素，我們根本無法完成充份的修改，比方說使用到 commercial library / framework、想降低 deployment 的成本，或者考量到 ABI (Application Binary Interface) 的議題。從事過 Java VM 實作的開發者一定對於 JLS (Java Language Specification) 的第 13 章相當熟悉，這就是 Sun Microsystems 規範 Java Runtimes 的 binary compatibility 表現，除了 JLS 外，還可以參考 [TCK Tools & Info] 與 OpenGroup 的 [Test Development Services]。Java 的定義相當嚴謹且完整，ABI 甚至是其規格的必要需求，反過來看，C++ 是種特別的語言，不僅語言層面複雜，實作與實務上更有其難題在。本 blog 多次提到 "C++ sucks"，為何 [這個無聊人士] 如此厭惡 C++ Model 呢？

事實上，我是 Qt/KDE 的愛好者，也涉獵過 Embedded C++ subset，就語言層面來說，我還算喜歡 C++，但是問題在於在 D + K 時，我所面臨的難題就是軟體元件間的整合。[jmmv's weblog] 最近有兩篇很值得一讀的 blog：

jmmv 從我們常用的最佳化技巧，也是就是善用 C++ 的 inline modifier 做出發，探討在 C++ Compiler 的 object representation 的差異性，進而引發的 ABI 議題，不過呢，jmmy 在第一篇 [C++: Inlined code and the ABI] 也敘及：

It's a pity that careless C++ developers make so intensive use of such inlined code. BTW, note that although this has focused on C++, the same is true for, e.g., C99, which provides an inline keyword. 效能與空間的最佳化一直都是 tradeoff，而 optimization 與 correctness 在某種角度來說亦然，第二篇就更有意思，C++ template 的普遍實作方式是透過展開的形式，引發了一連串的疑惑後，jmmv 說到：

I'm now wondering how Java 1.5's templates work or if they suffer from these issues too... [jjhou] 前輩曾在 JavaTwo 2002 發表了 Generics 的實現，同時我們也可看出在 ABI 的考量，不過我感興趣的項目還是 C++ 的 ABI，以下這幾篇可以建立概況：

Sun's [Stability of the C++ ABI: Evolution of a Programing Language]
CodeSourcery (GCC / GNU Toolchain 的商業支援公司)'s [C++ ABI Summary]
Chad Austin's [Binary-compatible C++ Interfaces]

由 jserv 發表於 07:48 PM | 迴響 (0)

NILFS : log-structure FS

寫過 CA-Clipper 程式的開發者，或許很自然就把這個 "NIL" 聯想為語言層面的術語，依據我小時候微弱的記憶，這大約等同於 Java 的 null，那麼，NILFS 該不會是「空的檔案系統」？前天閱讀 LinuxDevices.com 的新聞 [Linux gains lossless filesystem] 看到這個突破性的發展，由 NTT Labs (Nippon Telegraph and Telephone's Cyber Space Laboratories) 所貢獻出的 [NILFS] 是新的 [log-structured file system] 實作，或許我們會納悶，比較新的 fs，如 ext3、ReiserFS、XFS，或是 JFFS2 都有能力達到 journaling 的需求，為何 NTT Labs 這個日本第二大的工業單位裡面的實驗室還要發展一套新的 fs 呢？LinuxDevices.com 這篇新聞給了一個起頭：

For example, data loss occurs on ext3 filesystems when the system crashes during a write operation. When the system reboots, the journal notes that the write did not complete, and any partial data writes are lost. 儘管 [Ext3] 檔案系統在 ext2 的基礎上，擴充很多屬性來描述所需的 journaling 資訊，而且也能夠在需要時 rollback，但是不免會在 write 時發生 data loss 的情況，Ext3 的主要開發者 Dr. Stephen Tweedie 在 2000 年作了一系列的技術報告，可參考 [EXT3, Journaling Filesystem]。對於企業或電信等級的應用來說，高 throughput 的 I/O 與 synchronization 是必要的 (data lossless)，Ext3 這樣的特徵不能徹底的符合需求，Sun Microsystems 在其 Solaris 中發展了 UFS，引入了 "snapshot" 的概念，可以避免上述的問題，顧名思義就是可以保存 UFS 在某個時間的樣貌，而不會受其他應用程式所干擾，在 Solaris 下操作很簡單： (一般的 Solaris 系統管理教材都會提到)

建立 snapshot：
「觀看」該時間點 UFS 的樣貌：
移除該 snapshot：

但 NTT Labs 指出 Solaris UFS 的缺陷：

but filesystem operation must be suspended to use the feature, reducing performance. NILFS, in contrast, can "continuously and automatically [save] instantaneous states of the file system without interrupting service. 所以基於以上考量，NTT Labs 認為 "Checkpoint" snapshot feature 是必要的，以下引述新聞稿：


   # inspect /dev/sda2
   ...
   nilfs> listcp
            1     6 Tue Jul 12 14:55:57 2005 MajorCP|LogiBegin|LogiEnd
         2048  2352 Tue Jul 12 14:55:58 2005 MajorCP|LogiEnd
   ...
   nilfs> quit

   # mount -t nilfs -r -o cp=2048 /dev/sda2 /nilfs-cp
   # df
   Filesystem           1K-blocks      Used Available Use% Mounted on
   /dev/sda2             70332412   8044540  62283776  12% /nilfs
   /dev/sda2             70332412   8044540  62283776  12% /nilfs-cp

NILFS 的功能特徵如下：

Slick snapshots
B-tree based file and inode management
Immediate recovery after system crash
64-bit data structures; support many files, large files and disks

在 [NILFS] 網頁可以下載設計給 Linux Kernel 2.6.13 的 nilfs-1.0.0，看了以上的介紹，讓我手癢不已，但是...

jserv@venux:~$ uname -a
Linux venux 2.6.12-1-686 #1 Tue Sep 27 12:52:50 JST 2005 i686 GNU/Linux

以我這台 Debian box 來說，用 Debian SID 裡面的 linux-image-2.6.12-1-686 與 headers 編譯該 module，會發生以下錯誤：

nilfs/fs/segment.c:2462: error: Arguments of `refrigerator' mismatched. 至於為何 NILFS 1.0.0 要指定 kernel version 呢？因為 kernel API 在 2.6.13 有更改，看看 2.6.12 與 2.6.13 兩個版本的 include/linux/sched.h 可以發現 refrigerator 這個 kernel API 已經更改了，又是 Linux Kernel 令人又愛又恨的例子阿，快速且有效率的發展模式，可是 API 常常更動 :(

當然啦，問問 Google 大神，看看有沒有解答，結果發現根本沒有，所以我怒了 ([autrijus] 前輩說過：「生氣是促進發展的原動力」)，於是搞了一個 patch [nilfs-1.0.0-backport-2.6.12.diff]，這樣就可以讓 NILFS-1.0.0 運作於 2.6.12 或以下的 Kernel 上。

回到 NILFS，其對於 snapshot 的支援如下：

Automatically taken without any explicit requests
Simultaneously mountable
Mountable as read-only file systems via the disk block number

在網頁尾端的 TODO List 提到頗多方向，可以作為思考電信與企業等級應用中，系統骨幹所面臨的挑戰。

由 jserv 發表於 02:39 PM | 迴響 (0)

解魔術方塊

颱風天賦閒於苗栗老家，瞥見 [yal's blog] 裡面的這篇 [3x3 魔術方塊(Rubik's Cube)的第一次成功]，yal 提供了以下的 links：

這幾個網頁都提供相當詳細的資訊，描述解魔術方塊的演算法，這讓我想起 GNU Projects 的子項目 [GNUbik]，所以我安裝了 Debian [Package: gnubik]，以下是安裝後的檔案列表： (省略圖檔與翻譯)

$ dpkg -L gnubik | grep -v locale | grep -v icons | grep -v man | grep -v pixmaps
/usr/games/gnubik
/usr/share/gnubik/guile/flubrd.scm
/usr/share/gnubik/scripts
/usr/share/gnubik/scripts/debug.scm
/usr/share/gnubik/scripts/rand.scm
/usr/share/gnubik/scripts/mellor-solve.scm

[GNUbik] 是個用 Gtk+/OpenGL 打造的解魔術方塊程式，比較有趣的是，使用 Guile 這個 Scheme interpreter 當作 scripting engine，整個運作畫面如下：

"Script-fu" 下的項目就是 /usr/share/gnubik/scripts 所羅列的 Scheme 程式，所以我們可以用 LISP-like 來實現魔術方塊的解題演算法，上圖就是展示解題過程的動態畫面。

由 jserv 發表於 12:35 PM | 迴響 (2)

酷音 native Win32 版本

「神奇」(我實在想不出來該用什麼形容詞來描述) 的 [PCMan] 兄在某一天醫學院的課程中，覺得上課有點沈悶，就把 [新酷音] 移植到 Win32/IME 下，可以參考 Kanru 的 blog [PCMan 的 ChewingIME]，現在 source code 也置放於 Subversion 管理，可參閱 [WebSVN::chewing::win32-chewing]，執行的畫面如下：

真是太棒了 :-)

所以現在 [新酷音] 計畫已經有以下子項目：

libchewing : 演算法核心與基礎服務
libchewingpp : C++ wrapper for libchewing
scim-chewing : 提供給 SCIM 的 IMEngine
xcin-chewing : 提供給 XCIN 的 module
IIIMF-chewing : 提供給 IIIMF 架構的 language engine
win32-chewing : 原生的 Win32./IME 輸入法
chewing-util : 整理與調整詞庫的工具集

歡迎新血的加入與支持。

由 jserv 發表於 11:15 AM | 迴響 (1)

Nano-X Window System 正名

在稍早的 blog [Kaffe 新的 AWT backend -- Nano-X] 提到 Kaffe 在今年開始支援 [Nano-X] 為基礎的 AWT 實作，並且已經正式於 1.1.5 release 出現，不過我們也可以發現一個事實：

著名的 MicroWindows Window System 在 Jan 30, 2005 為避免 Microsoft 的官司，從 MicroWindows 命名為 Nano-X Window System 查閱 CVS repository log 可以看到：

jserv@venux:~/gui-toolkits/microwin$ cvs diff -u -r1.3 -r1.4 README
Index: README
===================================================================
RCS file: /usr/cvs/microwin/README,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- README      25 Apr 2005 23:13:15 -0000      1.3
+++ README      14 Jun 2005 22:19:50 -0000      1.4
@@ -1,17 +1,20 @@
-To build Microwindows, see src/INSTALL and src/CONTENTS.
+To build Nano-X/Microwindows, see src/INSTALL and src/CONTENTS.

-Microwindows is an Open Source project aimed at bringing
+The Microwindows Project has been renamed to The Nano-X
+Window System, due to conflicts with the Windows trademark
+registered by Microsoft, in 2005.
+
+Nano-X is an Open Source project aimed at bringing
 the features of modern graphical windowing environments
-to smaller devices.  Microwindows' genesis was with the
-NanoGUI project, and is now the primary distribution for
-both the Microwindows and Nano-X codebase.  Microwindows
-currently runs on Linux, UNIX, X11, ELKS, MSDOS, RTEMS
+to smaller devices.  Nano-X's genesis was with the
+NanoGUI project, and is now the primary distribution.
+Nano-X currently runs on Linux, UNIX, X11, ELKS, MSDOS, RTEMS
 and bare VGA hardware.  It uses the same device-
 independent graphics engine built for the NanoGUI project.
-Microwindows compiles a sample application and the WinCE 
+Nano-X compiles a sample application and the WinCE 
 graphics api in about 42k.

-The architecture of Microwindows allows it to be ported
+The architecture of Nano-X allows it to be ported
 or run on a wide variety of systems.  Cross-compilation
 for MIPS, ARM and x86 processors is supported. There are currently
 screen drivers for Linux 2.2.x framebuffers and Linux 2.0.x
@@ -20,12 +23,12 @@
 target platform.  There exists a portable 4-planes VGA driver
 that will run on bare hardware, ELKS, MSDOS, or RTEMS.
 There are mouse drivers written for bare hardware, direct
-serial port, Linux GPM driver, and touchpads.  The Microwindows
+serial port, Linux GPM driver, and touchpads.  The Nano-X
 graphics engine is capable of running on any system that
 support readpixel, writepixel, drawhline and drawvline,
 although more advanced bit blit routines are provided.

-Microwindows features full RGB color support, optimized
+Nano-X features full RGB color support, optimized
 palette bitmap drawing, and a 3d look-and-feel.
 Overlapped and child windows are supported, with complete
 window and client area clipping.  Proportional and fixed
@@ -39,14 +42,14 @@

 WEB SITE
 ========
-The main Microwindows web site is at
-       http://microwindows.org/
+The main Nano-X web site is at
+       http://nano-x.org/

 An HTML based FAQ and Architecture document are available from
 the web site.

-Microwindows may be downloaded at
-       ftp://microwindows.org/pub/microwindows
+Nano-X may be downloaded at
+       ftp://nano-x.org/pub/microwindows

 The chief maintainer of the project is Greg Haerr 

@@ -64,4 +67,3 @@
 The ELKS mailing list is linux-8086@vger.rutgers.edu.  To subscribe,
 send a message to majordomo@vger.rutgers.edu containing the words
 subscribe linux-8086 in the body.

也因此，連 domain name 也從 [http://microwindows.org/] 更名為 [http://nano-x.org/]，所以日後書寫或引用資料時，請使用 "Nano-X Window System" 的名稱。

由 jserv 發表於 10:28 AM | 迴響 (0)

Jserv's blog

October 29, 2005

「Linux 國際化與區域化發展」簡報上線

October 28, 2005

用 UrMap 找公司新地址

這才是牛人

介紹軟體發展的科普文章

October 27, 2005

Free Culture 和賦予與支配的權利

幕後的英雄：談 Embedded Systems 設計

Use the Source, Luke!

October 26, 2005

X server 的 low-level 觀點

October 25, 2005

這個 blog 值多少錢？

October 24, 2005

何時該釋出版本

xscope : 分析 X Protocol 的工具

October 23, 2005

演講：Linux 國際化與區域化發展

言多必失

October 17, 2005

與淑女有約：內湖到北宜公路的散步

October 16, 2005

Fiasco-UX Microkernel

October 13, 2005

Orz.Debian.Org.Tw成立

October 11, 2005

「kernel 2.6 與桌面環境的整合」簡報上線

October 10, 2005

桌面系統效能調整

內湖俯瞰

Liferea 抓狂了

October 09, 2005

XML + CSS

工讀生的工作環境

再談自由軟體授權

October 08, 2005

鼯鼠與軟體專案開發

隨手畫

October 06, 2005

電腦音樂與 MIDI 介紹

心得分享：kernel 2.6 與桌面環境的整合

October 04, 2005

C++ 與 Java 的 ABI 議題

October 03, 2005

NILFS : log-structure FS

October 02, 2005

解魔術方塊

October 01, 2005

酷音 native Win32 版本

Nano-X Window System 正名