Jserv's blog

關於本 Blog 的原則

說「原則」有點沈重，不過我想表達的是，這個 blog 寫作的想法、方式，以及類型，這些「原則」如下：

• 首先，關於 blog 內文的授權，在一開始並沒有明確的指出，未來考慮會採用 [Creative Commons] 授權，但在此之前，如您願意轉載，只要指明出處，都相當歡迎，而更換到 [Creative Commons] 授權後，對於之前的 blog / post 將既往不究。
• 有網友來信，質疑為何一個寫過 Web browser 的開發者，自己的網頁與 blog 不甚美觀？我的回覆是這樣的開發者相當多，不是嗎？ *笑* 明確來說，我的 [首頁] 用 CSS+XHTML，而本 blog 用 MT 架設，在我更新文章的過程中，只是很自然的堆積 HTML tag 與文字符號，我相信大部分的意思能被表達出來，而預設的 theme 也符合我的需求，所以沒有更換的必要。
• 關於主題，有網友寫信提到，說可否花些篇幅介紹 XXX (代詞，可以是許多領域) 呢？這是我的榮幸，不過基本上我還不確定是否有能力介紹 *笑* 這個 blog 的所有內文都是紀錄備忘、自己野人獻曝的作品，甚至是鬼畫符，您願意閱讀，在下就覺得相當欣慰了，只是我實在沒有太多時間與精力來維護。
• 關於分類，基於玩票性質的 blog 創作，我不認為能夠提出一套完備的分類系統，以涵蓋本 blog 所有的文章，同時，我相信電腦科學的進步，能夠很快速的作 context-free / context-bound 的分類或進一步的彙整，所以，未來仍不作任何分類。是的，這個 blog 就是大雜燴，您或許會看到資訊技術的連結、工讀生的感情抒發、文學習作、在台北打零工的苦命生活、狂人的札記，還有許多難以理解的符號集合，雜處於這個 blog 中。

以上，再次感謝您對本 blog 的興趣，謝謝！

日本核能發展先驅

前天閱讀日本原子之父仁科芳雄博士 (Yoshio Nishina, 1890-1951) 的傳記，略為整理紀錄。仁科芳雄博士是丹麥著名科學家 Niels Bohr 的高徒，承續哥本哈根學派，在 Niels Bohr 建立的量子理論大道上，開創新的局面，日本第一位諾貝爾物理獎得主湯川秀樹 (Hideki Yukawa, 1907-1981) 即是仁科芳雄博士的高徒。自東京大學畢業後，仁科芳雄赴英與 Niels Bohr 從事量子力學的研究，返回日本後，以宇宙射線研究的基礎，在核物理學、放射生物學，以及放射性同位素示蹤等應用作研究。1937 年，仁科芳雄博士完成東洋第一台 cyclotron 裝置，透過產生的中子照射 U 元素，進行核子反應的研究。

1940 年秋季，日本陸軍航空本部相信，建構一顆具有毀滅性的原子彈是可行的，稍後於 1941 年 5 月，安田武雄中將接到東條英機關於研制原子彈的密令，指派日本物理化學研究所立即展開原子彈的研制計劃，該計畫的負責人就是仁科芳雄博士，該計畫代號為 "Ni"，取自仁科芳雄博士的拼音字母。日本海軍也在悄悄地進行代號為 "F－GO" 的超級炸彈製造計畫 ("F" 字母為 fission 的縮寫，表示「原子裂變」)，海軍計劃的負責人是日本的另一名物理學家荒勝文策，"F－GO" 於 1942 年在京都福岡啟動。

日據時代台北帝國大學 (即台灣大學前身) 的「物理學講座」，首位講座教授為荒勝文策博士 (Arakatsu Bunsaku)，荒勝文策與仁科芳雄年歲相仿，同為日本物理史的領袖人物。荒勝文策博士來台後，在台北帝國大學完成一座 Cockcroft-Walton 加速器，是當時亞州是最先進的研究設備之一。1934 年，荒勝文策博士的團隊在台北帝國大學的二號館 101 室架設完成了 240 Kev 直流高壓加速器，同年七月 25 五日成功完成了以人工加速粒子撞擊原子核的實驗，是繼 1932 年英國劍橋大學 Cavendish Laboratory (培養了 25 個諾貝爾獎得主) 之後，世界第二個完成人工撞擊原子核的實驗團隊。

荒勝文策博士的實驗成功，消息傳遍全台，並轟動日本，實驗團隊立刻被徵召回到日本，於京都帝國大學原子核實驗室建造更大型的直線加速器和迴旋加速器，這也是日後 "F-GO" 的基礎建設。日本海軍研發原子彈的力度比陸軍大得多，甚至試圖與納粹德國聯合研發原子彈，以捷克東歐的核能與重水來彌補日本境內對放射物的短缺。1945 年 5 月，德國的 U－234 潛艇執行了一項極機密的任務，運載著 560 公斤的鈾氧化物和 3.5 公斤的 U-235 前往日本，供日本開發原子彈用，這些核原料相當於製造一顆原子彈全部原料的五分之一。不過，德國潛艇 U-234 被美國海軍發現並予以重創，所有的核原料落入美軍手中，這也讓我們覺得歷史軌跡巧妙之處，倘若窮兵黷武的日本軍閥獲得此關鍵性原料，並成功研製原子彈，與美軍對抗，屆時整個亞太區，說不定早已成為人間煉獄。

如我們所知，原子彈的基本原理相對來說，不是特別高深，但問題是如何純化 U-235，並以中子彈照射後，使其進行一系列的分裂反應，才是問題所在。二次大戰期間，日本並沒有成功分離、濃縮出 U-235 的技術，而仁科芳雄博士的想法類似於今日的核能電廠設計，亦即為使核分裂的連鎖反應更易於進行，必須降低中子的速度，但是問題在於如果不能讓連鎖反應在百萬分之一秒內完成，是無法釋出強大的破壞力的。

後來有些消息指出，仁科芳雄博士事實上相當清楚上述的難題，甚至有提出對應的解決方案，並且在日本先進核能研究上有所發揮，不過博士當時在軍令難違，又不是具有高度意願完成毀滅性的殺人機器，才在二次大戰期間，做了些緩和性的設計。

Reference:

• [核能博物館]

KDE@Taiwan 第二次使用者聚會

2005 年初舉辦 [KDE@Taiwan 首度使用者聚會]，會後我寫了一份紀錄 [首度 KDE@Taiwan 使用者聚會圓滿落幕]，而 2006 年度的聚會則將在一月 7 日，以下是聚會資訊：

• 活動網頁：[KDE@TaiwanSecondMeeting]
時間：2006 年 1 月 7 日 (星期六) 14:00 ~ 17:00
• 地點：天瓏書局旁的 Starbucks
• 地址: 台北市衡陽路7號B1 (228公園旁，[地圖])
• 聚會流程 (暫訂)
  • Introduction
  • KDE@Taiwan 現況報告 - AceLan
  • KDE-i18n 翻譯現況 - AceLan
  • Qt Quarterly(Traditional Chinese) 正體中文翻譯現況 - AceLan
  • KDE KParts 元件技術與新發展 - jserv
  • 散會

我將會分享 [KDE KParts 元件技術與新發展] 這個主題，簡要介紹自 KDE 2.x 即扮演重要角色的 KParts 技術，並從此看桌面整合發展的議題，涵蓋 KParts、 XParts，以及 GParts。有興趣參加的朋友請簽到，以利活動統計，謝謝！

PX-GUI - 用 SDL 寫 Window System

SDL 是個很理想的 Graphics library，之前的 blog [有趣的 ZWM -- pure SDL Window Manager] 提過 zwm 這種較為複雜的 Window System，而 [PX-GUI] 則是另一個用 SDL 打造的簡易 GUI。

[PX-GUI] 目前的版本號為 0.0.1，只有雛型，不過還是相當有趣，原本的程式碼只能在 Win32 運作，我稍微改了一下，就在 Linux Desktop 愉快的運作：

下載 [修改過的程式碼]。

C99 的 offsetof macro

歷久彌新的 C 語言在 1999 年時，ANSI/ISO 批准之前的 C90 Draft，成為新標準，也稱為 C99，offsetof 是個其中制定的新 macro，在規格中提到：

"The offsetof() macro returns the offset of the element name within the struct or union composite. This provides a portable method to determine the offset."

Nigel Jones 在 Embedded.com 撰寫了一篇名為 [Learn a new trick with the offsetof() macro] 的文章，介紹如何使用該 macro，並以具體的 Embedded Systems 開發作例子，相當有參考價值。首先，Nigel Jones 引用了幾個 C compiler 的實做：

// Keil 8051 compiler
#define offsetof(s,m) (size_t)&(((s *)0)->m)

// Microsoft x86 compiler (version 7)
#define offsetof(s,m) (size_t)(unsigned long)&(((s *)0)->m)

// Diab Coldfire compiler
#define offsetof(s,memb) ((size_t)((char *)&((s *)0)->memb-(char *)0))

Nigel Jones 給了相當詳盡的解釋：

To better understand the magic of the offsetof() macro, consider the details of Keil's definition. The various operators within the macro are evaluated in an order such that the following steps are performed:
• ((s *)0) takes the integer zero and casts it as a pointer to s.
• ((s *)0)->m dereferences that pointer to point to structure member m.
• &(((s *)0)->m) computes the address of m.
• (size_t)&(((s *)0)->m) casts the result to an appropriate data type.

By definition, the structure itself resides at address 0. It follows that the address of the field pointed to (Step 3 above) must be the offset, in bytes, from the start of the structure. At this point, we can make several observations:
• We can be a bit more specific about the term "structure name." In a nutshell, if the structure name you use, call it s, results in a valid C expression when written as (s *)0->m, you can use s in the offsetof() macro. The examples shown in Listings 3 and 4 will help clarify that point.
• The member expression, m, can be of arbitrary complexity. Indeed, if you have nested structures, then the member field can be an expression that resolves to a parameter deeply nested within a structure.
• It's easy enough to see why this macro also works with unions.
• The macro won't work with bitfields. You simply can't take the address of a bitfield member of a structure or union.

以上的設計非常 tricky，不過需要留意的是，上述的運作方式是高度平台相依的，也預先做了定址方式、size_t 轉換，以及 bit-fields operations 上的假設，所以 Keith Thompson 做了這樣的評論：

That's why the offsetof() macro is defined in the standard library; there's no portable way to implement it, but there's always a non-portable way that works for a given implementation. The implementer is allowed to do things that you aren't.

GNU GCC 作為一個高度可攜性的 C compiler 實做，勢必無法透過以上的 "magic"，以 GCC 4.0.2 來說，相關的定義在 /usr/lib/gcc/i486-linux-gnu/4.0.2/include/stddef.h，其 offsetof macro 定義為：

/* Offset of member MEMBER in a struct of type TYPE. */
#define offsetof(TYPE, MEMBER) __builtin_offsetof (TYPE, MEMBER)

看到 __builtin_ 開頭的 symbol，事實上我們知道這是 GCC 內部的實做，GCC 線上文件版本 4.0.0 的 [5.43 Offsetof] 提到這方面的細節：

GCC implements for both C and C++ a syntactic extension to implement the offsetof macro.


     primary:
     	"__builtin_offsetof" "(" typename "," offsetof_member_designator ")"
     
     offsetof_member_designator:
     	  identifier
     	| offsetof_member_designator "." identifier
     	| offsetof_member_designator "[" expr "]"

This extension is sufficient such that
#define offsetof(type, member) __builtin_offsetof (type, member)
is a suitable definition of the offsetof macro. In C++, type may be dependent. In either case, member may consist of a single identifier, or a sequence of member accesses and array references.

除了可攜性考量外，dependent expressions 也是 GCC 在內部 parsing tree 實做 __builtin_offsetof 的考量。倘若深入去追 __builtin_offsetof 實做方式，可參閱 gcc/cp/parser.c 。gcc/cp/parser.c 用以處理 primary-expression parsing 的部份在於 cp_parser_primary_expression function ，而 primary expression 的形式：

• literal
• this
• ( expression )
• id-expression

在識別為 CPP_KEYWORD 並確認為 RID_OFFSETOF (Reserved Identifier) 後，將透過 cp_parser_builtin_offsetof() 來傳回其 representation form。

回到 Nigel Jones 的 [Learn a new trick with the offsetof() macro] 這篇文章，舉了 EEPROM 的應用案例，EEPROM 是 Embedded Systems 最常見的 nonvolatile memory，他提到存取的方式：

Normally, such memories are byte addressable. The result is often a serial EEPROM driver that provides an API that includes a read function that looks like this:
ee_rd(uint16_t offset, uint16_t nBytes, uint8_t * dest)
In other words, read nBytes from offset offset in the EEPROM and store them at dest. The problem is knowing what offset in EEPROM to read from and how many bytes to read (in other words, the underlying size of the variable being read).

ee_rd() 這類的 API 可在許多系統發現，但是我們的問題就在於如何得知 EEPROM 中的 offset 與預讀入的 bytes 數量，常見的解法是：

typedef struct
{
    	int 	i;
    	float 	f;
    	char 	c;

} EEPROM;

EEPROM * const pEE = 0x0000000;

ee_rd(&(pEE->f), sizeof(pEE->f), dest); 

類似上面提到的 trick，不過這降低了可讀性，同時因為需要 pEE pointer 來協助算 offset，也可能因為不當的操作 (如 Nigel Jones 提到的 "You can write perfectly legal code (for example, pEE->f = 3.2) and get no compiler warnings that what you're doing is disastrous.")，造成新的問題。而透過 offsetof macro，我們改寫以上的最後兩行：

ee_rd(offsetof(EEPROM,f), sizeof(float) /* f in struct EEPROM */, dest);

不能很直覺的得知 EEPROM structure 裡面 float f 的 size，是很大的遺憾，所以又施加類似的 trick：

#define SIZEOF(s,m) ((size_t) sizeof(((s *)0)->m))
#define EE_RD(M,D) ee_rd(offsetof(EEPROM,M), SIZEOF(EEPROM,M), D)

所以現在讀取 EEPROM 資料並置放於特定 member f 中，可以寫成：

EE_RD(f, &dest)

一舉克服了上面提到的問題，而 API 也更為乾淨。稍後的 [Use 3: protecting nonvolatile memory] 更是經典，篇幅稍微長了些。Linux Kernel 中，在 linux/nvram.h 規範了類似的 definition，不過透過 GCC extensions 來作 padding，比 Nigel Jones 舉例的寫法來得更漂亮且明確。以 arch/arm/kernel/asm-offsets.c 來說，也透過 offsetof macro 來增加填寫向量表格的可讀性：

#define DEFINE(sym, val) \
        asm volatile("\n->" #sym " %0 " #val : : "i" (val))

#define BLANK() asm volatile("\n->" : : )

int main(void)
{
  DEFINE(TSK_ACTIVE_MM,         offsetof(struct task_struct, active_mm));
  BLANK();
  DEFINE(TI_FLAGS,              offsetof(struct thread_info, flags));
  DEFINE(TI_PREEMPT,            offsetof(struct thread_info, preempt_count));
   ...

對了，讀者回應也很值得一看，Louis Huemiller 提到的 "providing an abstract interface, without having to use an object orientated high-level language (e.g. C++)" 很有意思。

32% evil, 68% good

看了 Palatis 的 blog [63% Evil, 37% Good]，我也來玩玩...

C-style 字串的最佳化

C-style 字串的最佳化有許多途徑，Timo Sirainen 撰寫的 [Secure, Efficient and Easy C programming] 是相當值得一看的文章，在實務應用上，不僅要避免 string operation 引來的 buffer overflow 外，又得避免大量的小段記憶體配置片段，這會造成 memory leaking，再來，針對特定的應用場合，如 heavy traffic networking 的環境，勢必需要發展一系列的機制來克服以上的議題。[Vstr] 這個最佳化的字串處理函式實做，有許多相當值得一看的資訊，如 [String library comparison] 比較了許多開放的實做，並且在 [Speed comparison of Vstr vs. other string APIs] 提及其比較的方法與參考實做，然而，選對 library，就意味著解決問題了？當然不是。

「最佳化」是個複雜的議題，但是這裡不打算提 global optimization，而在 gtk-devel mailing-list 上，Daniel Marjamäki 提出一個想法： [RFC: String cleanup]，敘及原本的：

const char *str

更換成：

const char str[]

可產生比較直覺的機械碼，可提昇 CPU 效能與記憶體使用。這引來 iolo 的進一步思考： [Isn't C wonderful?]，他舉出以下的程式碼片段：

static const char *str1 = "azerty";
static const char str2[] = "azerty";
void f(const char *x);
void try(void) {
        f(str1);
        f(str2);
}

透過 GCC 產生組譯碼：

gcc -O3 -S const_char.c

我將輸出用 OpenOffice Impress 做了對應比較：

在組譯碼可以發現，C compiler 對於 const char [] 會生成直接的輸出，並且字串的操作也較直覺，相對的，const char * 在語意上是 pointer，而 C compiler 則予以 indirect access，這需要留意。

新酷音進度報告5

距離上一篇 [新酷音進度報告4] 的幾個月後，[新酷音計畫] 有相當大的改變。首先是 [PCMan] 與 [Sea Monster] 先後加入開發團隊，貢獻了 win32-chewing 這個新的子計畫，現在可以直接使用 Win32 IME 來操作新酷音，同時，在這個過程中，[PCMan] 也修正了許多 Win32 IME 奇怪的問題，未來有機會可望整合回 [OpenVanilla/Win32]，細節可參考之前的 blog [酷音 native Win32 版本]。

[kanru] 主導的 libchewing-utf8 經歷兩次的重寫後，終於達到 production 的水準，目前在 win32-chewing 已經採用，同時也整合到 trunk 中，等待將近一年的 Unicode-based 新酷音核心終於現身。在 libchewing 0.2.5 時，為了避免詞庫授權的疑慮，將已經 tune 過的酷音詞庫，更換為 [PCMan] 號召下，成為一個子計畫 [新酷音輸入法詞庫 / libchewing-data]，這裡面許多的成員都是 Win32 的使用者，不過他們都協助審定詞庫的詞頻與正確性，又因為 [新酷音計畫] 支援許多平台，所以 "Correct Once, Run on Many Platforms"。

gugod 建立了新的 sqlite branch，目標就是使用 SQLite 來管理新酷音的詞庫 (系統 / 自訂)，目前已經可以載入多數的詞庫，並且 UTF-8 support 也完成了，所以在 libchewing 0.3.x 應該可整合進去。

十月底的某一個晚上，在嘉義山上喝酒的我，突然有靈感，於是設計了新的 porting_layer，實做了 POSIX 與 Win32 的 MMap 與平台相依的資訊 wrapper，於是，就可以銜接之前 [PCMan] 實做的 binary data support，這部份已經整合到 trunk，所以未來可透過 memory mapping 來載入所有的資料檔，同時 libchewing-data 與 libchewing 的相依性也可望移除。

Tiberius 貢獻了一個有趣的 patch，讓使用者在選字時，可按下 'j' 或 'k' 這兩個按鍵，就會移動到上一個字組，這對於連續打字，很有幫助，這部份也整合到 trunk 中。

為了未來的 libchewing 0.3.0 series，我也弄了一組新的 API，目前配合內建的 test suite 作開發測試，之前 kanru 已經透過 [Check: A unit test framework for C] 做了簡單的 Unit Testing for libchewing，而 porting_layer 的 MMap 也有簡單的 test，未來也可以針對個別功能作測試。

Sun Microsystems 的 [Ervin Yan] 也通知我一個有趣的消息，未來的 Solaris 10 U2 與 Solaris 11 可望內建 [新酷音] 輸入法模組，同時我們也討論了一些技術議題，稍早發表的 [IIIMF 與 SCIM 的開發經驗] 有部份資訊已經 out-of-date，並且 IIIMF 的發展有許多更新，稍後也將整理並撰寫一份文件。

對了，明天是 [新酷音計畫] 上線一週年，希望我們未來有更好的自由智慧型注音輸入法，並且，也感謝所有投入開發、測試，以及推廣的朋友們，謝謝！

AMD64 的復活節彩蛋

剛剛閱讀 Dave Jones 的 blog [cpu easter eggs]，得知 AMD64 在 cpuid 這個 instruction 有相當有趣的表現：

inline void cpuid(
    unsigned int op,
    unsigned int *eax,
    unsigned int *ebx,
    unsigned int *ecx,
    unsigned int *edx)
{
    __asm__("cpuid"
    : "=a" (*eax), "=b" (*ebx), "=c" (*ecx), "=d" (*edx)
    : "a" (op)
    : "cc");
}

int main(void)
{
    unsigned int eax,ebx,ecx,edx;
    unsigned int i=0;
    char array[17];
    char *cp=array;

    cpuid(0x8fffffff, &eax,&ebx,&ecx,&edx);

    for (i = 0; i < 4; i++)
        *cp++ = eax >> (8 * i);
    for (i = 0; i < 4; i++)
        *cp++ = ebx >> (8 * i);
    for (i = 0; i < 4; i++)
        *cp++ = ecx >> (8 * i);
    for (i = 0; i < 4; i++)
        *cp++ = edx >> (8 * i);
    *cp = 0;

    printf ("%s\n", array);
}

在 AMD64 編譯以上程式並執行後，會得到這個輸出：

IT'S HAMMER TIME

Cool !

相當有趣的 Blog

我有個優秀的大學同學，他的 blog [芭樂的三八耍白爛紀錄] 相當有趣，裡面有不少類似 [彎彎] 風格的插畫，雖然這些實在很難跟他的藝術和音樂造詣聯想在一起。

我常常被懷疑真正的年齡 (作過的心理測驗，心理年齡似乎從來沒低於 40 歲)，但看看這些插畫也不免有會心一笑。

王安電腦的興衰

無意在民族主義這議題打轉，不過我小時候的教育中，不時被灌輸「二十一世紀是中國人的世紀」一類的標語，而置身於二十一世紀的我們，也看到這樣的事實。儘管很早 (相對於同儕) 就接觸電腦，不過並沒有相當投入，只是斷斷續續的練習 Programming 或者玩著 debug.exe (或許您猜得出來，這對於撰寫 virus 很重要，不過往事不堪回首，過去作過的謬誤就不提了)，中學結束前，放棄自己期望的醫學院志願，改填寫資訊工程作為選擇，有部份程度來說，(一九) 八零年代的那些故事，對我有很大的影響，儘管這個時代已經改觀許多了。所以我願意在台北打零工度日、不時三餐匱乏之餘，作此紀錄，充當踏入 IT 產業這條路的啟蒙故事。

接觸個人電腦十餘年的今天，回想起自己用過的第一台的 PC，是在國小三年級時，家父為了追蹤股價與工程應用，透過中國鋼鐵與造船公司的關係，購買了一台當時相當新潮的 IBM-PC 80386-SX 33MHz，如果沒記錯，這台「全鎮唯一的 386 電腦」的名號，連續蟬聯好多年。稍後陸續接觸了 m86k、Alpha、Sparc，以及 HP-UX 等機器，後來因為工作，更是接觸許多廣泛的通用架構，比如 ARM 與 MIPS，不過我一直忘不了從小就耳聞的「王安電腦」，有時候會在報紙上看到其性能與商務應用的表現，當然，我也知道，那的確是「中國人的驕傲」。

王安電腦的發跡與沒落，可在許多刊物與商業分析看到，是非常著名的案例。

王安博士 (Dr. Wang An) 憑一己之力成立王安實驗室 (Wang Laboratories) 與王安電腦，在八零年代崛起，長期是公司的獨大股東，並領導企業在全球建立當時最成功的文字處理機公司。數據顯示，王安博士仙逝前，屢次名列世界前十名首富。1984 年，王安公司已創下 21 億美元的營業額的紀錄，據當時的預測指出，王安電腦可望於 1990 年達至50 億美元的營業額。然而，到 1987 年時，該企業卻有走下坡的現象。1989 年，王安去世前後，業務一蹶不振，光輝不再，若干年後，王安電腦就變成了旅美華人的一段偉大歷史。這十餘年的光景，是媒體工作者或者專家分析的焦點，歷史見證了王安電腦的創始、開拓、稱霸乃至衰落，過去王安電腦就是辦公室電腦的第一品牌，王安電腦公司享譽全球，王安也成了廣大華人的驕傲，但曾幾何時，「王安電腦」這個大名已經淡出我們的記憶。對多數人來說，電腦就是 PC，更明確來說，個人可掌握的電腦，不僅可運作商務計算、通訊，或科學運算，還能執行各式各樣的軟體，絢麗的遊戲或聲光特效更是比比皆是。王安電腦沒及時跟上改變的腳步，它還在銷售特殊功能的專屬電腦，一如過去崛起的途徑，但 PC 上的軟體卻與王安電腦硬體上的軟體徹底不相容，數量更是難以比較，然而在「美麗的錯誤」背後，王安電腦所孕育的技術與影響力，是相當巨大的。

在 1992 年王安電腦宣佈破產後，Wang Laboratories 仍有發展，例如日前喧騰一時的 [Java 侵犯到柯達的專利？！] 訴訟案，Kodak 握有的專利正是來自併購改組於 Wang Laboratories 的 Wang Software 而來的。牛津管理評論的 [美國王安電腦公司創始人王安] 一文簡述了王安生平：

1920 年 2 月 7 日生於上海，16 歲時考入上海交通大學。1945 年作為中國高級工程技術人員被派往美國深造，1945 年秋他進入哈佛大學學習。1948 年獲哈佛大學應用物理學博士學位，1951 年他出售自己發明的記憶磁芯的專利權，用所得的 50 萬美元在波士頓創辦了王安實驗室。1955 年，正式成立了王安計算機公司。1964 年推出桌面電腦，1967 年王安公司股票上市，1976 年，王安推出新型的電子文字處理機。1984 年是王安走向頂峰的一年，年收 21 億美元，其中利潤 2.1 億美元。

1986 年王安 36 歲的長子王列擔任公司總裁並負責公司的日常業務。1989 年王安公司因無力支付 2.09 億美元的欠款宣布「債務重組」，這年公司損失 4.24 億美元。王安這年撤銷了長子王列總裁的職務，由米勒擔負其職務。1990 年 3 月 24 日，王安死於癌症，米勒擔任董事長。這年公司損失 7.16 億美元。1991 年，IBM 和王安公司宣布聯合。在這種聯合下，王安公司可以銷售 IBM 電腦並提供相應的軟件。1992 年 8 月 18 日，王安公司宣布破產。

王安的遠見卓識曾使他獲得非凡的成就和榮譽，王安公司雇員最多時達 3 萬餘人，年營業額達 30 億美元，1986 年曾被列為美國第五大富豪，1989 年入選「美國發明家殿堂」，與愛迪生等大發明家齊名，曾被授與「美國總統自由勳章」。然而，其濃厚保守的家族觀念，落後於時代的內部管理機制，對 PC 和計算機網絡發展前景的錯誤預測，最終導致這位計算機界的巨人和王安電腦公司的悲劇。

至於王安電腦宣佈破產後，又是如何呢？王安電腦在 1991 年面臨破產前，Joe Tucci 接任 CEO，以一系列的策略，調整定位，逐漸轉虧為盈，為此，Joe Tucci 把王安公司絕大部分的老業務部門出售，最著名的案例就是在 1994 年，將整個軟體部門 (也就是 Wang Software) 整個出售給 Kodak，當然也伴隨前述提到的 patents。從1995年到1999年，王安電腦連續併購了十家公司，包含 Olivetti 公司，此舉讓王安電腦轉型為資訊通訊技術產業 (ICT)，公司也因此改稱「王安全球」。一連串的行動，拯救了王安公司。到 1998 年末，王安電腦公司擁有二萬多名雇員，在四十多個國家設有分公司，年收入超過35億美元，其股票市值也翻了三番。1999 年 7 月，王安公司被荷蘭著名的IT 服務企業 Getronics NV 公司收購。

寫到這裡，令我動容的是不是八零到九零年代的那段歷史，而是 1951 年王安博士創立 Wang Laboratories，到 1972 年王安電腦成功的研製出半導體為基礎的文字處理器，這是比較接近當今運算架構與設計的系統，這段時期的報導不多，但可以想見的是，是多麼艱辛。1956 年，Wang Laboratories 將「磁蕊存貯器」的專利權賣給 IBM，獲利 40 萬美元，雄心勃勃的王安並不滿足於安逸享樂，對事業的執著追求使他將這些收入全部投入研究工作。儘管我只是個工讀生，但作為一個軟體開發人員，有時必須跟硬體工程師協同工作，就算是在二十一世紀的今天，硬體設計有許多 EDA Tools 的協助，大大的減輕工作負擔，但還是相當難以控制時程，更要長期投入，我實在難以想像王安博士以及 Wang Laboratories 當時的雇員是如何接連開發出這些創新的發明與產品。我對硬體的認知，事實上只有在大學所修過的「數位電子邏輯」與「微處理器」兩門課程，翻閱教科書上許多定理、準則，以及邏輯設計時，不得不對這些遠在五零、六零，以及七零年代就已經奠定現在看到的電子工業基礎的理論以及背後的開創者，投以高度的敬意。我念的書不多，也鮮少去大學課堂上課，不過如果要我列出大學時代影響甚大的課程，這兩堂硬體絕對是相當重要的，到今日，隱約還會喚起對 J-K 正反器、DTL 電路、Logic gates，以及其他基本電路元件的記憶。

在工作之餘，我用了一些時間投入 Free / Open Source Software 的發展，其中「中文資訊化」是一個很重要的項目，雖然我的貢獻是微不足道，但是這過程中，讓我的視野開闊許多。記得第一次閱讀這方面的資料，是在國小五年級閱讀趙榮耀博士編著的「電子計算機概論」一書 (或許書名有出入)，書中即多次提到王安電腦公司以及其中文化電腦，記憶猶新的是，提到中文鍵盤種類時，有張照片顯示了大型鍵盤的畫面，也就是將數千中文字排列於一個鍵盤，每一鍵上有數個中文字，利用字鍵與選擇鍵檢出所需中文字，仔細想想，這是多麼可怕的設計。而王安電腦很早就設計出類似我們現在所用的小型鍵盤，透過特定的編碼就能迅速操作，更在中文編碼的思維，提出 3 bytes encoding 的設計，以解決跨國資訊交流即將面臨的問題，而當時國內許多廠商還在 Big5 打轉。

參考資料：

• 王安電腦：最終失敗在家族觀念上
• 短暫的輝煌--王安電腦的興衰

GParts - GTK+/GNOME 與 Qt/KDE 應用程式的整合

一個成熟的桌面系統，面對眾多桌面元件的整合，勢必要提出一套強而有效的 Desktop Object Model 來作整合，在KDE 來說是 KParts/DCOP，而 GNOME 是 Bonobo/Mico，這裡先略過這兩者複雜的設計概念，從 KDE 1.9.x (KDE 2.0 pre-release) 到現在的 KDE 3.5，甚至是未來的 KDE 4，可以預見的是，KParts 技術仍是 KDE 的核心元件，正如 [KDE 元件技術] 一文所描述的長存著。大約在 2001 年，當 FreeDesktop.org 成立後，有一組人馬試著修改 GTK+ 與 Qt 來達到兩者的整合，而今，終於開花結果了。GTK+ 底層的 event loop 是建構於 GLib，而 Qt 則是一套複雜的 C++ Framework，如果要讓兩者協同運作，首先就會遇到 main loop 的議題，Norbert 實做出一個新的途徑，稱為 [Common Main Loop]，目標就是在適度更動 Qt MainLoop 的前提下，透過 Adaptor Pattern 來讓 KDE/Qt 與 GNOME/GTK+ 應用程式可共存，並不造成 GUI blocking，使用 [download Qt-glibmainloop patch and demo] 後，可得到以下的展示畫面：
這個「雜交」 (crossover) 的畫面，我們可以發現，在同一個 process 中，可以完美的讓 GTK+ widget 與 Qt widget/component 在同一個 event loop，而不會互相干擾。

以上的 [Common Main Loop] 就是為了 [GParts] 布局，咱們來看看該網頁提到的重點：

GParts is an in-process component system for GNOME based on shared libraries and is in fact KDE's KParts adoption. GParts also implies Bonobo integration. That means that Bonobo components may be wrapped into GParts components and vice versa. The goal is to acheive the highest possible degree of interoperability between GNOME and KDE component models.
GParts for GNOME is everything that KParts is for KDE. Based on shared libraries, it provides the developer with the following objects and abstractions:
• parts - reusable widgets with XML description of UI layout and actions
• mainwindow, whose interface is described in XML so that it is able to embed parts
• a part manager, an objects whose task is to handle the activation and the deactivation of the parts
The most important aspect of GParts is its integration with Bonobo, so that together these two models form a consistent bipolar component model, providing a feature-complete development platform for GNOME developers that is fully compatible with KDE component system.

KParts 在提出之前，KDE Team 曾採用過 CORBA 作為 Desktop Component Model 現身前的空缺，不過 CORBA 實在太複雜了，而 KDE 核心設計是很重視 Design Patterns 與 code reusability 的，在 mailing-list 與 IRC 上都有相當巨量的討論 (應該說辯論)，甚至我們可以用 [DRT: A design recovery/reverse engineering tool] 這樣的工具來分析 KDE Application Framework 與其上眾多應用程式的視覺關係，就可以發現整合度的高寡，而 GNOME 則基於歷史因素，沿用了 Bonobo/Mico 的 CORBA 為基礎的設計作為桌面元件技術，事實上，必須開發相當多組 API 予以包裝，才能達到符合使用的境界，有部份 GNOME 開發者已經開始思考捨棄 Bonobo/Mico 的設計。Dmitry M. Shatrov 提出 GParts 就是希望在 GNOME 重現 KDE 相當成功的 KParts 技術，並且承諾與原有的 Bonobo 維持整合。KParts 相當重要的優勢除了其 lightweight (有興趣的話，可以去閱讀 GNOME Bonobo 的 source code，看看其如何與 Mico 這個 CORBA 接軌，再去看看之間捨棄多少 CORBA 的特徵)，再來是其 XML-GUI 的整合，簡單來說，如 KWord 這個 KOffice 元件要 Embeding 到 KSpread 同樣是 KOffice 的另一個元件時，原本附屬於 KWord 的 GUI，如選單，會 seamless 的一併 Embeding 到 KSpread 的選單中，並且能協同運作，這是桌面技術相當大的突破。

在 KDE 2.1 後，KDE 的核心架構開發者 Matthias Ettrich、Simon Hausmann，以及 Lars Knoll 共同提出 XParts 這個延伸 KDE KParts 的新設計，當時要克服的問題就是，如何讓 Konqueror 與 Mozilla 這兩個不同的程式，達到彼此間的整合，亦即引用 Mozilla 的 Gecko HTML render engine 作為 Konqueror 的一部分，但是，很明顯的，第一個問題就是，如何把 Mozilla 放進 Konqueror 的視窗中，那時候的解決方案是直接透過 X Window System 的 Repaint 機制，適度的分割資源處理方式，再來，第二個問題就是如何作 In-process / Out-process component communications，也包含如何直接使用 XML-GUI 來操控 Mozilla 的功能。在 XParts 的設計中，相當巧妙的運用 KDE DCOP 技術，透過以下三個 DCOP 元件：

• XPartHost - 在使用 XParts 的 user side，作為該程式與非 KDE 元件的溝通
• XPartManager - 於 component side，管理所有 component instance
• XPart - 包裝非 KDE 元件，並允許跟 KDE 元件溝通

於是，我們可以發現，當 Konqueror 試圖載入 Mozilla 作為 HTML renderer 時，會先建立 KMozillaPart 的 KParts 元件，而其隨後會執行 kmozilla，並產生 XPartHost與 XPartManager，這樣一來，DCOP 將可把 KMozillaPart 與 kmozilla 作牽連，進行溝通。整體來說，XParts 是 out-of-process component 技術的展現，然而，就目前的發展來說，已經沒有太強烈的需求，Konqeueror 本身的 HTML rerndering 品質已經相當高。

不同於 XPart 複雜的途徑，GParts 是期望用直接在 GNOME 對應 KParts 的觀念，引用網頁上的資訊：

Now lets look what benefits GParts offers. At first, GParts may be viewed just as a direct mapping of KParts into GNOME's development environment, so that GNOME developers don't need to care if they are interoperating with KDE and embedding a Qt-based component or are reusing GNOME's native Gtk+ code. All they need to know is that they are working with KParts. Similarly, KDE developers may use Gtk+ GParts components as if they were native KParts components. This is possible because KParts and GParts will be in fact two implementations of the same technology and will share as much code as possible. The only difference is that KParts has bindings for KDE/Qt while GParts has bindings fot GNOME/Gtk+.
GParts to KParts mapping will be quite straightforward and consist of a simple bridge between Qt and Gtk+ objects and a namespace mapping, so that KParts may be viewed as GParts and vice versa. I've tested embedding Gtk+ widgets iside Qt and Qt widgets inside Gtk+ within a single main loop and there's a working example as a proof of concept.

XParts 當初運用 X Repaint 機制，就是希望不修改既有 GTK+ 或其他 X 應用程式的前提，透過 DCOP 來達成彼此應用程式的通訊，並包裝為 KDE 的 KParts，然而這付出的成本事實上也相當可觀，GParts 的方式則更為直接，Dmitry Shatrovs 做了一個相當成功的展示，說明如何將 KParts (以 Konqueror 為例) 嵌入 GTK+ 應用程式中：
[Common Main Loop] 在這之間扮演相當重要的角色，同一的 process 中，我們看到 Qt 與 GTK+ 元件有不同的外觀，但 Konqueror 得以 Embedded in GTK+ 中。這也引發許多思考，其中，其大成者為 [Common Desktop Component Model]，試圖建構在以上技術的基礎上，讓 KDE 與 GNOME 的互動有更好的表現，在 [The way to go] 提到一個重點：

Look once again at the Environment Integrity rule. It is impossible to create a universal object model that would map well enough onto existent programming environments. The consequence is that there should not be one! One does not need an object model to reuse others' code. What is needed is a well-defined interface to access components. Now I will describe such an interface. It is the result of several redesigns and it looks simple enough to me to be close to the right thing.

基於這個想法，有 D-Bus 為基礎的 CDCM (Common Data Communication Model) conventions、 強調 Native Implementation，亦即不走複雜的 Distributed Computing Model，同時我們也看到可能的使用方式：

GObject *component = cdcm_get_kparts_component_for_name ("khtml"); GReadOnlyComponent *khtml = CDCM_READONLY_PART (component);
g_readonly_component_open_url (khtml, "http://gnome.org");

我們在 GTK+/Glib 要求 khtml 的 component creation，並將 action 帶予該 instance，至於 object activation / invocation 的方式也可望相當簡單且一致：

cdcm_call_method (CDCM_COMPONENT (khtml), "set_load_images", TRUE, CDCM_TYPE_BOOLEAN, NULL);

另外，Norbert 也提出 [Generic desktop adapter library] 的新提案，引用網頁的介紹：

The "Generic desktop adapter" tries to solve the problem by intruducing a standardized interface between applications and desktops. Filechoosers and VFS are considered as part of the host-desktop and not the application. Unlike the common-VFS, common password storage and common configuration system approach the "Generic desktop adapter" doesn't require abrupt changes of the internal design of desktop libraries and applications. The migration can be gradual. The only major requirement is the "common main loop". IPC-bridges or threads don't seem rationale for this purpose.

試圖建構一系列 desktop adater 來標準化這些介面設計與通訊議題，看來未來的桌面技術發展相當有趣 :-)

Which OS are You?

That's me...
Which OS are You?

Xynth Window System

在 LinuxDevices.com 看到 [Lightweight windowing system supports embedded Linux] 這則新聞，很興奮的把 [Xynth Window System] 抓下來玩。我用的版本是 xynth-0.7.91，發現 SDL video driver 有 memory allocation 的問題，動手 [做了個 patch 修正]，並且改了 shm 管理的方式，應該會在下個釋出版本出現。引用豆神在 [XD Programming by PCMan] 提到的這句話：

『不能用? 就把程式碼拿來, 改一改, patch一下就好啦~』

在 X11/SDL 運作 Xynth Window System 的畫面如下： 不過要注意的是，在 SDL video server 運作的情況還不是很理想，我已經發現幾個 null pointer 的現象，可能還要再花點時間追。

Xynth 採用典型的 client-server 架構，並且將可攜性列為重要考量，軟體架構圖如下： 幾個重要特徵如下：

• Clients can be configured to use "double buffer rendering" to avoid flicker that could result from direct access to the video memory
• Thread-safe source code, server API, client library, and widget set, for customizability and reliability
• Polling Input device driver structure supports PS2, IMPS2, and USB mice and console keyboards, and supports custom device drivers as plugins
• Output driver system includes drivers for svgalib and Linux frame buffer, and any output driver can be easily used for video memory buffer
• Supports SysV IPC (inter-process communication)
• Minimal set of window management features built-in, to reduce footprint

授權方式為 GNU GPL，也移植到 SONY PSP 裝置上，很值得關注的計畫。

Blog的迴響

Blog 有趣之處，有一部分是迴響的內容，基本上，本 blog 所有迴響我都會閱讀，並且視需要回覆，當然有時候會誤砍一些 comments (該死的 spam)，這裡也跟有留言過的朋友致歉，像是 "@msn.com"、"@hotmail.com"，或者 "@yahoo.com" 這一類的 email address，很容易就被 filtered。

剛剛在管理 blog 系統時，發現這份迴響：

我承認，這個 blog 是個大雜燴，近 500 篇的 blog entries 完全沒有作分類，但是，我怎麼看，都覺得 "jie" 這個女生跟 JamVM 或 Kaffe VM 有什麼關聯性？

所以呢，我想，還是等我想通這之間的關聯性，再來回覆好了，造成您的不便，請多見諒。難道，素描是 "From Scratch"，而 Free Java Runtimes 也是 "Source From Scratch"，因此有類似的建構背景，所以可相提並論呢？

IIIMF 與 SCIM 的開發經驗

任職於 Sun Microsystems 的 Yong Sun (findsun) 在出席國際會議前，邀請我寫一份 IIIMF 與 SCIM 的開發經驗談，以作為參考，之前是有打算在 [新酷音] 計畫上線一週年後，陸續發表一些概念性的文件與平台開發的經驗談，不過就略為述及。凌晨睡醒後，用簡單的英文寫了一篇短文 [Experience about IIIMF and SCIM from Taiwanese Developers] (純文字)，希望有所幫助。除了該文提及的前輩外，事實上要感謝的人實在太多了，像是我過去從來就沒想過，會直接跟 Sun Microsystems Asia/i18n Team 的工程師直接討論技術細節，以及當面跟 Hideki Hiura 請益，以及與這世界上傑出的開發者共事，相當具有啟發性。

Trac 整合性開發環境

現在開發軟體專案，已經不是一個人可以徹底掌握的，隨時都會遇到 "XD Programming" 的經驗，什麼是 "XD Programming" 呢？這是我在 #dot IRC channel 閒聊時發明的稱法，主要是描述建構一個軟體，就算有相當充足的資源，還是不免到處碰壁的挫折經驗，這時候就需要惡搞，然後就不免會補個 "XD" *笑*。例如 PCMan 兄當初打算重寫過去的 [pcman]，成為現在我們所見的 [PCManX pure GTK+ 2]，這過程有頗多艱辛，不過本週二 PCManX 本尊就會在 [TOSSUG - 台北開放源碼軟體使用社群 (Taipei Open Source Software User Group)] 給場 talk，這裡就不贅述了。但是，使用好的工具，對開發的過程絕對有相當程度的幫助，特別在多人協同開發中。

[布長輩] 提過 [Trac 介紹 & 0.8.4 中文版]，可以得知 [Trac] 實在是操作簡單，功能卻強大的整合 SCM 與專案管理的系統，而 [hcchien’s space] 也提到 [科技還是要來自人性] 一文，看來博大精深的 [RT] 也有了 trac theme：

引用 [布長輩] 的介紹敘述：

Trac 提供一套網站作業環境：有撰寫文件用的Wiki子系統、事務追蹤(issue tracking)子系統等等。而且不論是 [操作介面] 跟 [系統整合] 方面，都表現得可圈可點。也難怪 [許多知名軟體專案] 都已經採用目前才0.9版的Trac了。雖然說Trac是專門設計給軟體專案用的，可是我覺得裝在自己筆記型電腦上，管理svk也挺不錯。

十一月初，我這個 server 白痴，也終於在某種特定的需求下，自己動手安裝 [Trac]，雖然一般來說文件都寫得很詳細，可是搞這種東西，都會讓我想起以前是如何把 [KDE@Taiwan] 搞爛的往事。[Trac] 全部以 Python 撰寫，不是我懼怕的駱駝文，看來有點信心，而且還有 standalone web daemon 可用，大大的提高我的興趣，然後設定檔改一下，將變數指向 Subversion repository，apache-ctl restart 後，竟然... 就可以動了，讓我這個 server 白痴真是高興了好一段時間。

Trac 0.9 改用 BSD-like License，有更大的彈性，而且我也開始練習寫 Python module，在內部的專案管理開始作實務應用，用起來還不錯，Trac 開發團隊也相當活躍，大概除了 localization 外，沒什麼特別要挑剔的 :)

diffstat : diff 輸出的歷史統計

Debian package [diffstat] 可以建構 diff 輸出的歷史統計，這對於一個採用 version control 的專案，有參考的價值。以 xorz 來說，大致的使用方式如下：

jserv@venux:~/gui-toolkits/xorz$ svn diff -r1:HEAD | diffstat
 ChangeLog              |    7 
 ChangeLog-xorz         |  135 ++
 GL/glx/g_disptab_EXT.c |    6 
 GL/glx/g_disptab_EXT.h |    9 
 GL/glx/g_render.c      |  518 ++++----
 GL/glx/g_renderswap.c  |  454 +++----
 GL/glx/g_single.c      |  249 +++-
 GL/glx/g_singleswap.c  |  273 +++-
 GL/glx/glxcmds.c       |   17 
 GL/glx/glxcmdsswap.c   |    4 
 GL/glx/glxscreens.c    |    2 
 GL/glx/glxserver.h     |  448 +++++++
 GL/glx/render2.c       |   60 -
 GL/glx/render2swap.c   |   48 
 GL/glx/renderpix.c     |  200 +--
 GL/glx/renderpixswap.c |  200 +--
 GL/glx/rensizetab.c    |    2 
 GL/glx/single2.c       |   18 
 GL/glx/single2swap.c   |   16 
 GL/glx/singlepix.c     |   52 
 GL/glx/singlepixswap.c |   52 
 GL/glx/singlesize.c    |   11 
 GL/glx/xfont.c         |   20 
 GL/mesa/Makefile.am    |   84 +
 GL/mesa/X/xf86glx.c    |  390 ++++++
 Xext/shmint.h          |   23 
 Xext/syncint.h         |   77 -
 configure.ac           |   29 
 drm/drm.h              |    1 
 fb/fbbltone.c          |    2 
 fb/fbcompose.c         | 1045 +++++++++++++----
 fb/fbmmx.c             |  701 ++++++++++-
 fb/fbmmx.h             |   19 
 fb/fbpict.c            |   14 
 fb/fbpict.h            |  200 ++-
 hw/kdrive/src/kmode.c  |    7 
 hw/xgl/Makefile.am     |    3 
 hw/xgl/egl/Makefile.am |   16 
 hw/xgl/egl/evdev.c     |  630 ++++++++++
 hw/xgl/egl/kinput.c    | 1683 ++++++++++++++++++++++++++++
 hw/xgl/egl/kkeymap.h   |   58 
 hw/xgl/egl/xegl.c      |  799 +++++++++++++
 hw/xgl/egl/xegl.h      |  131 ++
 hw/xgl/egl/xeglinput.c |  168 ++
 hw/xgl/glx/xglx.c      |   81 +
 hw/xgl/xgl.h           |   57 
 hw/xgl/xglcopy.c       |    7 
 hw/xgl/xglget.c        |    3 
 hw/xgl/xglglx.c        | 2890 +++++++++++++++++++++++++++++++++++--------------
 hw/xgl/xglglyph.c      |  116 +
 hw/xgl/xglinput.c      |    2 
 hw/xgl/xglpixmap.c     |   13 
 hw/xgl/xglscreen.c     |   12 
 hw/xgl/xglsync.c       |   14 
 hw/xgl/xgltrap.c       |    2 
 include/GL/glxproto.h  |    6 
 include/config.h.in    |    3 
 include/picturestr.h   |  133 ++
 mi/miwideline.c        |    4 
 miext/damage/damage.c  |   16 
 render/picture.c       |  492 +++++++-
 xkb/ddxList.c          |   92 -
 xkb/ddxLoad.c          |  329 +++--
 63 files changed, 10490 insertions(+), 2663 deletions(-)

在 [diffstat] 的 man page 提到：

This program reads the output of diff and displays a histogram of the nsertions, deletions, and modifications per-file. Diffstat is a program that is useful for reviewing large, complex patch files. It reads from one or more input files which contain output from diff, producing a histogram of the total lines changed for each file referenced. If the input filename ends with .bz2, .Z or .gz, diffstat will read the uncompressed data via a pipe from the corresponding program.

所以 diffstat 基本是參考 unified diff (也就是 diff -u) 的結果，統計個別與整體的 insertions(+) 與 deletions(-) 數量。

隨手畫 - Purple

我的工作內容很有趣，可是工作的途徑很枯燥，最主要的代表就是實做並最佳化 speech codec 與 multimedia codec，對我這種缺乏足夠工程數學背景的工讀生來說，實在不是一件容易的事情。週四繼續實做之前提出的新 codec 需求並且僅可能在眾多的 spec 中，釐清設計細節，這已經讓我頭昏了好一段時間，用完晚餐後，返回辦公室打算繼續調整演算法與 test case 時，收到 [Purple] 捎來的信件，標題是「宇宙的寂寞心靈」，一如往常，Purple 的文字是如此具有張力，來信中，有一段相當切合當時的心境，也給我頗多啟發：

我是想針對「外在自我」與「內在自我」衝突的這個問題，做討論。

[... 中略 ...]
我可以自由選擇要走的道路，自由的活著。

愛情牽涉到自由意志(free will)，我無法左右他人的自由意志。所以因此受過傷，但還是很努力的爬起來，繼續往下一條路try。偶爾會覺得這樣很寂寞，就像桑德志在追求宇宙的規則一樣寂寞。人生或命運你無法預先知曉，你只能往回看，而無法預知未來。

為了讓自己往回看不要一事無成或後悔，只能盡力過好每一個當下。

疲倦的我決定立刻回家，好好休息，喝了一點葡萄酒，立即入眠，隔天週五終於有一些進度上的突破，不過要走的路肯定是遙遠的，正如桑德志在追求宇宙的規則一般寂寞。

週末在內湖住所除了作哲學思考與試著完成之前的架構設計外 (與工作項目徹底無關)，還反覆拜讀了 Purple 的來信，雖然只有一面之緣，不過這些日子來還是相當感謝意見的交流。剛剛則用了一些時間，繪製了一份素描： (click to enlarge)
試著將我所見的 Purple，作一份映射，這分創作對光影的捕捉還有待加強，我也過於強調筆觸，忽略主題的特徵，或許是我的觀察還不夠深入。

群 於台北內湖住所
Dec 10, 2005

隨手畫 - jie

之前答應 jie 要畫張素描，不過一直沒有完成。今天花了一些時間作 artwork 與實作簡單的 Graphics Toolkit，稍微完成一段落後，似乎感受到 Muse 的牽引，索性來此一畫： (click to enlarge)

當然，跟 jie 本人相比，應該有不小的落差。這份隨手畫大約花了一個小時的時間，在這份創作中，很大程度的忽略光源影響，以致於無法鮮明的呈現主題，有空的時後應該再努力捕捉。

Anyway，謹此贈予 jie，希望她會喜歡。