August 31, 2005

夢幻軟體計畫 2005 八月份進度

[夢幻軟體計畫] 是今年 Debian 中文社群的 [年度計畫] 相當重要的項目,從 [熱血三人組] 在一月份提出這個想法後,陸續找到各項目的協調人進行,而現在就 [夢幻軟體計畫] 項目作個簡介,當然,我必須聲明,這僅是個人的觀察,事實上只要您願意貢獻與參與,一定還有更驚人的成果。

這篇 blog 基本上延續 [Debian 在台灣] 的描述,但只針對 [夢幻軟體計畫],其他熱心付出的朋友以及他們的貢獻,我會在稍後的 blog 或 wiki page 中提及。

從輸入法系統來看,[kanru] 與 [PCMan] 積極投入 [OpenVanilla] 發展,貢獻了 Win32 的移植,發展的進度與概況可以參閱 [Win32Issues],目前已經有接近商業產品水準的表現,而 [vgod] 稍早成功移植 [OpenVanilla] 到 [SCIM] 輸入法平台上,所以許多經典的香草輸入法模組,像是 POJ(白話字) 與藏文輸入法,就可以在 Debian GNU/Linux 運作了,同時他也打包好 Debian 套件,詳情可參考 [OpenVanilla Debian packages!]。而 Mat 則在入伍前夕將 [UCIMF] 的程式碼放入 Subversion repository,並且改過 build script,現在 [新酷音] 已經可以透過 IIIMF 與 UCIMF 的機制,在 Linux console/tty 下顯示並輸入了。而我則利用一點空檔研讀 [OpenVanilla] 中 b6s 所實做的 Bi-Gram Generic Filter,並且 import 到 [新酷音] 的 [libchewing/branches/bigram],不過還沒具體突破,但作為新的 Language Model 是不錯的出發點,有機會再跟 b6s 兄請教。此外,之前 blog [Arne 的台灣地區通俗語言之輸入法] 提到的專案,現在已經有進展了,可參閱 [MinNan IM (台式閩南語輸入法) 進度表],楊先生發展的這套以注音輸入法為基礎的表示方式真是特別,這個月初有幸可以參與這個計畫,學到不少表示法與重音的考量,還有,看到自己被分配到的 Task 標示為 100%,不禁湧起一股熱血的衝動 :-)

至於 [TSCC (繁簡體中文用語轉換系統的基礎框架)],進度大致如 blog [中文簡繁轉換的複雜性] 所及,雖然目前有些實做,是 gaim 的 plugin,可以作為即時訊息的繁簡體轉換,主要是因為避免跟大陸網友聊天時,會有語言隔閡,但是還有不少相關資料待涉獵。

網路設定工具的項目,目前 [Linetconf] 算是完成階段性的目標,可以作為完整且複雜 [NetworkManager] 的一個輕量級選擇,我之前有一個委託的案子就是以這個計畫為主軸,加入 WirelessLAN WPA 支援,如果有時間的話,應該可以整合進去。

網路應用程式的部份,當然首推 [PCMan] 兄領導的 [PCManX-pure-GTK2] 計畫,很多熱心的朋友,比方說 [kanru]、[copyleft]、olv,以及 [FourDollars] 陸續投入,並且提出許多創新的發展,比方說 Python script 的支援、BBS 聊天機器人、美觀的字型處理、類似 MSN Messenger Popup 的來訊顯示效果,以及多個錯誤修正,這些特徵在過去 Win32 的版本甚至還沒有出現過,感謝偉大的網際網路,把這群開發者連繫起來,共同創造出更豐富的發展。

在八月中旬舉辦的 [DebianBirthdayParty2005] 中,brianhsu (墳墓) 展示了他跟暨南大學同學共同發展的 CatFS,這是一個 Linux Kernel Virtual File System 的擴充,可以在 kernel-level 做出類似 Google GMail 的分類設計,所以可以輕鬆的指定一個命名,就會對應到真實的 inode,我已經在 Notebook 裡面跑起來,不過還沒有協助 hacking,或許可以請墳墓兄把這些成果放到 [svn.csie.net] ,然後號召幾個對 kernel hacking 與 Desktop Integration 有興趣的朋友來共同改善。

正如我的 blog [2005 下半年計畫] 所及,我會用十月份整個月的時間投入 Free/Open Source Software 的發展,除了撰寫我的 paper 與作基礎研究外 (能否出席 Summit,就靠這些研究與 paper 了,希望我能有突破),當然會貢獻於上述的 [夢幻軟體計畫],並基於 [再談「自由創投」] 的理念,讓專案的進行能夠更順利。同時,軟體程式設計需要對技術有足夠的掌握,所以除了「Free Java Runtimes」與「綜觀 X Window System 新發展」這兩場已經舉辦的演講,Debian@Taiwan 今年的 [IRC Conference] 還是會繼續,如果場地、時間,以及少量資金能配合的話,說不定可以舉辦一場黑客松 (Hackthorn),可參閱之前的 blog [想玩黑客松]。

最後,[chuany] 在 [Debian@Taiwan Wiki] 中發起一個計畫 [Computer Reload / 電腦再生計畫],他寫到:
    電腦再生計畫是為了拯救許多曾經風風光光為我們賣力運作,但現在卻靜靜躺在角落的二手零件,再次賦予他們神聖的使命,讓他們為許多默默為我們寫作自由軟體的創作者運作。
    參與夢幻軟體計畫的開發者並非每一位都很富有,也並非每一位都有能力負擔開發所需要的硬體設備,希望這些曾經風光的舊零件能夠幫助的了這些開發者。
這裡呼應我之前的說法作結:
    很歡迎更多朋友協助,正所謂「有錢出錢、有力出力」,您的貢獻將會驅使整個社群能夠再邁向一步。
看來今年的成果還不錯,還是那句老話:希望能有更多朋友投入,一起來創造 Debian 在台灣的故事。
由 jserv 發表於 01:34 PM | 迴響 (2)

南方公園小配角

剛剛閱讀 [One Day More] (RedHat Desktop Group 的專業美術師 Diana Fong 的 blog),瞥見這篇 [South technology Park],Diana 製作的這個圖真是可愛,所以我也來玩一下。

首先打開 [SOURTH PARK STUDIO] (Macromedia Flash),然後依據系統提示,選用喜歡的配色與樣式,就產生出以下的圖片:

突然想到,[Planet DebianTW] 現在還沒有類似 [GOT 星球] 一般,能在每個 entry 放上可愛的圖示,如果 DOT 的老大們有空,希望能加上去 :p
由 jserv 發表於 08:19 AM | 迴響 (1)

August 30, 2005

x86 的 SIMD 參考文件

ARM core 接觸久了,x86 竟然越來越生疏了。SIMD 是近代計算機組織很重要的特徵,除了之前 blog [在 Pentium4 上透過 SIMD 作最佳化] 提到如何使用 SSE/SSE2 指令集,另外有三篇是一定要參考的: 第二篇的詳細程度與可讀性甚至比 Intel Reference Manual 還高,Apple 在 x86 投下的功夫真不容小覷,並且拜 GCC 對於 Intel MMX/XMM Intrinsics 的支援,我的測試程式已經可以在 Pentium 4 與 PCA 架構下產生 SIMD-enabled instructions。
由 jserv 發表於 05:34 PM | 迴響 (0)

Squish -- C++/Qt 應用程式的測試套件

軟體設計的挑戰之一就在於驗證 (Verification),有許多方法與工具相繼被提出來。以 C++ Programming 來說,有 [CppUnit] 這樣的設計可以作為參考,zgump 之前也翻譯了 [CppUnit Cookbook中文版],不過 CppUnit 使用上的問題是需要修改原始應用程式,並且對於 Qt 這種視覺化的應用程式類型來說,顯然不夠力,是此,[froglogic] (青蛙邏輯?) 公司就發展了一套 Squish 的工具,試圖給予開發者新的途徑。

參考 LinuxDevices.com 的新聞 [New version of Qt app tester Squish released],[froglogic] 公司的這個產品可以做到不修改 AUT (application under test) 的前提下,用若干個內建與可自訂的 Python script 來送出 GUI events/requests,並在執行時期做出診斷報告,至於詳情,先看了 [Demo of froglogc Squish 2.0] 這個使用 Macromedia Flash 製作的展示就知道了,的確非常強悍。

由 jserv 發表於 01:14 PM | 迴響 (2)

Roundup -- 簡單好用的 Issue Tracker

提到 issue tracker,大概很多人會聯想到 [Bugzilla],不過這玩意太複雜了,而且多數的應用根本不需要考慮到這樣的系統。如果是小型專案 (committer 數量小於 15 人),可以考慮用 Python 撰寫的 [Roundup],引述網頁介紹:
    Roundup is a simple-to-use and -install issue-tracking system with command-line, web and e-mail interfaces. It is based on the winning design from Ka-Ping Yee in the Software Carpentry "Track" design competition.
透過 Web-based 的操作,可以很容易的紀錄與追蹤 issues,並且安裝超級容易,只要有 Python 2.3 以上的環境,跑 "python demo.py" 就會動了,所以昨天我把原本工作用的某套商業軟體換成 [Roundup],呈現的畫面如下:(click to enlarge)
因為我的工作項目有些神秘,所以做了些處理,如果要評估的話,可參考官方的 [Roundup Screenshots],對了,[Roundup] 連 Web server 也內建,所以不需要額外的 container,但是也可掛在其他 Web engine,比方說 Apache,請參考 cgi-bin/roundup.cgi。 另外,補充一點,[Roundup] 可以 export 既有的 issues 為 CSV (Comma Separated Values) 格式,這樣 Microsoft Excel 就可以 import 了,不過現在呈現的格式不太符合我的期望,所以我要排一點時間 hacking。但整體來說,絕對是小又美的選擇,不僅可協助工作進度掌控,安排個人約會應該也用得上,只是最近好像沒有女生找我約會 (*嘆*)。
由 jserv 發表於 10:11 AM | 迴響 (1)

August 29, 2005

Liferea 惡搞3

今天使用 Liferea 閱讀 RSS Feed 時,發現程式當掉,而 Liferea 會用一個名為 lock 的檔案來識別是否重複執行,這其實不太好,所以呢,我就動手 hack 一下,改用 X Atom 的檢查來作,這樣就不需要移除失敗的 lock 檔案了,可參考 patch [liferea-lightweight-lock.diff]。

上次提到的 [Liferea 惡搞2],當時的版本還是 0.91,現在都準備要發佈 0.9.7 Release 了,進步真快 :-)

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

To be, or not to be...

之前的 blog [KDE 的 IPC 實做該採用 D-Bus?] 曾經引用莎士比亞的名言:"To be, or not to be: that is the question." (Hamlet 3/1),剛剛用餐完,借題發揮一下。

這句出於《哈姆雷特》(Hamlet) 的名句,通俗的翻譯是「活好,還是死」(To be, or not tobe…)。在那大段獨白,Hamlet 王子嘗試解釋對於「自殺」的恐懼與不確定性。但,他也不是真的怕「自殺」,他其實是怕「死」。但,他也不是真的怕「死了」,他其實是怕「熟睡」。但,他也不是真的怕「熟睡」,他其實是怕「會作夢」。接著,像是倒轉時鐘一樣,他把整個過程翻轉回來 ── 對,就是因為怕「會作夢」,人們才不敢勇敢地去「自殺」。這個一切建立在虛構中前進的過程,確實造成了某種說服力。

於是乎,這段獨白種種的不確定性,成為膾炙人口的獨白,人們用以描述身處兩難境地、進退猶豫時的窘境。有褻瀆文學嫌疑的我,姑且認定 "To be, or not to be" 這大概是用得最妙的部份,英文中 "being" 的意思就是生命,引述朗道英漢字典的說法:
    being
    *['bi:iŋ]
    n. 存在, 性質, 生命, 人, 生物, be的現在分詞
    相關詞組:
     come into being
     for the time being
     in being
所以我們可以發現,如果翻譯成「生死存亡」就太辜負莎士比亞的措辭了,整個的重心在於那種存在感,就是 Halmet 王子面臨「自殺」的恐懼,以及在那樣的情境下,嘗試探索生命存在的推理過程。我沒有看過這個歌劇表演,但是在我手頭查到的資料,這個音節是很令人玩味的。

中間的逗號可以看作樂譜上的速度標記,不是 Adagio (柔板),也非 Andante (行板),而是 Lento (慢板)。說到這,先閉目,讓自己心思沈澱。

現在,Hamlet 進入沉思狀態,開始獨白時,語言節奏該是緩慢的。Hamlet 輕聲念出的 "To be" 和 "or not to be"之間有一個無聲的間歇,逗號好比是個休止符,敲響生命終止的冥鍾。徬徨、猶豫、摸索中步伐並不會跨得又急又大。有生的煩惱,人生的困惑、生命的沉重,接著相繼而來,形成了一個個沒有解答的問號。在一片困惑中又陷入了一片茫然。又是一番徬徨、摸索,徘徊在生死邊緣。

思緒的波動,起伏很小,還沒充分進入意識領域,理性活動還處在半明半暗、被壓抑的狀態。這不是在思索,而是順著意識流在向前浮動。隨著情緒波動逐漸的增強,下意識的情緒逐漸上升為半透明的思緒...

接著,在這幕獨白中,試圖向人生尋找一個終極的答案的瞬間,理性的光芒逐漸照亮了整個意識領域,是此,思維活動越來越活躍,面對著一場嚴重的精神危機,作出對人生的哲理性思考。

此際,心坎已經徐徐道出 "To be, not to be..." 了。
由 jserv 發表於 07:59 PM | 迴響 (1)

Xorz/Embedded 展示

之前 blog [「綜觀 X Window System 新發展」簡報上線] 提到我本來要展示的 Xorz/Embedded,我用以打破 X11 相容性的實驗,用很小的 footprint 實做與 GTK+/Cairo 相似的 API,並且作為一個具體而微的 Window System,更適合 Embedded Systems。

首先看看 Xorz/Embedded 的展示畫面:

這要花多少程式碼達到以上的效果:向量繪圖、向量字型支援、半透明效果、Window Layout、簡單的 Widget Set,以及可更換的 skin,「數字會說話」:
    jserv@venux:~/gui-toolkits/xorz-embedded$ ls -lh xorz-all-in-one
    -rwxr-xr-x  1 jserv jserv 59K 2005-08-29 15:01 xorz-all-in-one
    
x86 binary 的空間是 59kb,那 Library Dependency 呢?
    jserv@venux:~/gui-toolkits/xorz-embedded$ ldd xorz-all-in-one
    	linux-gate.so.1 =>  (0xffffe000)
    	libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7ee4000)
    	/lib/ld-linux.so.2 (0xb7fd9000)
    
是的,直接透過 Linux [FBDev] (framebuffer) 作顯示,什麼負擔都沒有,套句廣告台詞:「輕鬆窈窕」。希望今年有機會釋出正式版本,也歡迎作技術交流與合作,謝謝!
由 jserv 發表於 03:18 PM | 迴響 (6)

August 28, 2005

協助 kernel bug-report 的小工具

[LKML] (Linux Kernel Mailing-List) 一直是 traffic 非常大的「聖地」,裡面有太多神奇的討論與發佈公告,其中有一部分是 bug-report。寫過 kernel driver 或者修改過 kernel routines 的朋友一定會碰過以下的畫面:
        unable to handle kernel paging request at address C0000010
        Oops: 0002
        EIP:   0010:XXXXXXXX
        eax: xxxxxxxx   ebx: xxxxxxxx   ecx: xxxxxxxx   edx: xxxxxxxx
        esi: xxxxxxxx   edi: xxxxxxxx   ebp: xxxxxxxx
        ds: xxxx  es: xxxx  fs: xxxx  gs: xxxx
        Pid: xx, process nr: xx
        xx xx xx xx xx xx xx xx xx xx
記得小時候改 kernel,看到這個 "Oops",對於 Kernel Hackers 的幽默,我只能苦笑,然後乖乖的去改 code。在 Debian 中有個套件 [reportbug],可以很方便的作 bug-reporting,那麼,LKML 是不是能提供這樣的工具呢?於是,Michał Piotrowski 提到 [ORT - Oops Reporting Tool],用 ort 這個 shell script 來處理這樣的任務,用起來方便多了。

這個 script 會詢問偏好的 editor 與 mail client,然後要求你輸入 bug 摘要與分類,之後你再慢慢描述,就會送到 LKML 了,對了,ort 下載路徑 [已更改]。
由 jserv 發表於 10:26 PM | 迴響 (1)

「綜觀 X Window System 新發展」簡報上線

昨天的 [演講:綜觀 X Window System 與新發展] 終於落幕了,而且 [簡報已上線] (PDF格式),歡迎指教,謝謝。

這次演講最有趣的插曲就是,我把 [台科大] 跟 [北科大] 混為一談,errr.... 我活到現在,才知道這是兩間不同的學校,而且距離還不近呢,所以遲到半小時,到演講廳的時候,還一直喘氣,這裡要再度感謝各位朋友包涵。

傍晚跟一位前輩有約,所以有些議題草草帶過,比較可惜些,不過這次終於把 X Extensions 與 3D Acceleration 做了粗略的介紹,因為每次看國外的文件,總是鮮少有系統性的介紹,這是試著連貫的介紹,應該對觀念的釐清會有幫助。

最可惜的是,竟然忘記展示 Xorz/Embedded,這是一個打破 X11 相容性的特殊實做,用很小的 footprint 實做與 GTK+/Cairo 相似 API 的小型實做,出發點有點類似 [Nano-X],不過相容性應該會好很多 (至少可以跑 GTK+ 與 Cairo),這是 [2005 下半年計畫] 的子項目,現在先擱著。

很顯然表達能力還要再加強 :(
由 jserv 發表於 12:18 PM | 迴響 (2)

August 26, 2005

語言的感動

最近的 TODO 項目越來越多,可是工作效能反而頗為低落,週四回家,稍作盥洗後準備要 Hacking 時,覺得有股體力透支的感覺,以及一陣昏眩。醒來時,只知道自己適才已睡去,臥室的書架上有幾本三島由紀夫的小說,隨手拾起《天人五衰》 翻閱,這是富饒之海四部曲系列的壓軸...

或許是最近的精神品質很低劣,看了好一段時間,總是沒什麼感覺,是的,我對文字的體悟能力,已經退化到如此的程度,怎不心寒?想起去年十二月14日曾寫了一篇日記:
    餓了幾個小時後,終於等到所謂的「早餐時間」(之前讀一份報導,說 7:00AM到 7:30AM 是最適合上班族的時段),可以來大快朵頤一番。徒步走到住所附近的早餐店,點了蛋餅與溫紅茶,順手拾起三島由紀夫的作品集翻閱,目光又飄移到〈太陽與鐵〉這篇,讓我不由自主產生崇高的敬仰。

    曾經年輕的我,對於「肉體的極限」這個命題具有頗高的好奇,嘗試多種途徑去探索,但往往不得其門而入,三島由紀夫的作品則是給我新的契機,因為,要知悉「肉體的極限」之前,必須先訴諸「肉體的語言」,唯有洞悉其溝通的方式,才能擺脫 Language Model 的形式限制,獲得貫串肉體到精神面的共鳴。

    三島由紀夫提到語言的自我矛盾現象:
      「我認為語言的腐蝕作用,既然同時又是營造造型的作用,那這種造型的規範正是這種『應有的肉體』的造型美、語言藝術的理想,一句話,就是這種造型美的模仿... 也就是說,絕對在於探索那種不被腐蝕的現實。」
    這席話令我相當驚訝,維根斯坦在《 邏輯哲學論》所提出的理論不啻如此的展現?!此際,我的心思在 Formal Language 理論與人生哲學實踐的具像中周旋著,盤據於方寸的,不再是 set of finite-length words,也不是 regular expression、automata,更不是 Turing machine,這些只是工具罷了,是的,我已經看到真理,多麼美妙的感受阿。

    難掩興奮的我,引三島由紀夫的話語作結:「過了很久,我承蒙太陽與鐵的恩惠,逐漸學習了一門外國語,學習了肉體的語言。」
八個月後的我,凌晨四點在內湖住所外遊蕩,試圖再次捕捉語言的感動...
由 jserv 發表於 04:20 AM | 迴響 (1)

August 25, 2005

Vectorization 的呈現

最近的一項基礎研究 [PNG 處理最佳化],讓我對 vectorization optimizations 又感到高度興致了,之前 [幾篇介紹 GPU 發展的中文文件] 所引用的資料也指出,現在計算機架構大幅採用 SIMD 的設計理念。那麼,在軟體的觀點來看,又是如何?這些艱澀的理論,其實用很簡單的小程式就可以看出來,所以我寫了一隻 Hello World 規模的測試程式:
    jserv@venux:~/simd$ cat multi.c 
    #include 
    void multi(short *a, short c)
    {
    	int i;
    #pragma vector aligned
    	for (i = 0; i < 100; i++) {
    		a[i] *= c;
    	}
    }
    int main(int argc, char **argv)
    {
    	short a[100];
    	int c;
    	for (c = 0; c < 100; c++) {
    		a[c] = c;
    	}
    	multi(a, 5);
    }
    
這個程式當然不必解說,但有趣的地方在於 "#pragma vector aligned" 的 qualifier,提示 compiler 處理 loop 時,使用 aligned instructions 來達成 vectorization。在我的測試機器上有 GCC4 與 Intel C++ compiler 8.0,以下是 GCC 的版本資訊:
    $ gcc -v
    Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr --with-gxx-include-dir=/usr/include/c++/4.0.2 --enable-shared --with-system-zlib --libexecdir=/usr/lib --enable-nls --without-included-gettext --enable-threads=posix --program-suffix=-4.0 --enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr --disable-werror --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.0.2 20050808 (prerelease) (Debian 4.0.1-4ubuntu5)
為了一般性,我不用從 cvs repository 建構的 GCC mainline (未來的 GCC 4.1),而是改用 Ubuntu/Debian 所用的版本。好,實地跑一次:
    $ make -f makefile.multi
    gcc -o multi.gcc401 \
            -march=pentium4 -msse2 -O5 \
            -ftree-vectorize --ftree-vectorizer-verbose=5 \
            multi.c
    
    multi.c:6: note: not vectorized: can't determine dependence between: 
    *D.2060_11 and *D.2060_11
    multi.c:3: note: vectorized 0 loops in function.
    multi.c:14: note: not vectorized: unsupported use in stmt.
    multi.c:6: note: not vectorized: possible dependence between data-refs
    *D.2125_16 and *D.2125_16
    multi.c:11: note: vectorized 0 loops in function.
    
看來在 GCC 4.0.1 中,autovectorization 還不夠能應付這樣的案例,那 Intel C++ compiler 8.0 呢?
    $ make -f makefile.multi-icc 
    /opt/intel_cc_80/bin/icc -o multi.icc80 -march=pentium4 multi.c
    multi.c(6) : (col. 2) remark: LOOP WAS VECTORIZED.
    multi.c(14) : (col. 2) remark: LOOP WAS VECTORIZED.
    
看來 multi() function 已經被 vectorized,那這兩者的差異到底在哪呢?用 objdump 來看看實做的組合語言,首先是 GCC 產生的:
    $ objdump -S multi.gcc401
    08048348 :
     8048348:	55                   	push   %ebp
     8048349:	89 e5                	mov    %esp,%ebp
     804834b:	53                   	push   %ebx
     804834c:	8b 5d 0c             	mov    0xc(%ebp),%ebx
     804834f:	b9 01 00 00 00       	mov    $0x1,%ecx
     8048354:	8b 55 08             	mov    0x8(%ebp),%edx
     8048357:	83 c2 02             	add    $0x2,%edx
     804835a:	0f b7 42 fe          	movzwl 0xfffffffe(%edx),%eax
     804835e:	0f af c3             	imul   %ebx,%eax
     8048361:	66 89 42 fe          	mov    %ax,0xfffffffe(%edx)
     8048365:	83 c1 01             	add    $0x1,%ecx
     8048368:	83 c2 02             	add    $0x2,%edx
     804836b:	83 f9 65             	cmp    $0x65,%ecx
     804836e:	75 ea                	jne    804835a 
     8048370:	5b                   	pop    %ebx
     8048371:	5d                   	pop    %ebp
     8048372:	c3                   	ret   
    
看起來非常「樸實」-- WYSIWYG (What You See Is What You Get),可以從剛剛的 C 語言程式碼想像出以上的片段,而 Intel C++ compiler 呢?來看看:
    $ objdump -S multi.icc80 
    08048738 :
     8048738:	55                   	push   %ebp
     8048739:	8b ec                	mov    %esp,%ebp
     804873b:	83 e4 f0             	and    $0xfffffff0,%esp
     804873e:	53                   	push   %ebx
     804873f:	83 ec 0c             	sub    $0xc,%esp
     8048742:	8b 55 08             	mov    0x8(%ebp),%edx
     8048745:	8b da                	mov    %edx,%ebx
     8048747:	8d 8a c0 00 00 00    	lea    0xc0(%edx),%ecx
     804874d:	0f bf 45 0c          	movswl 0xc(%ebp),%eax
     8048751:	66 0f 6e c0          	movd   %eax,%xmm0
     8048755:	66 0f 61 c0          	punpcklwd %xmm0,%xmm0
     8048759:	66 0f 70 c0 00       	pshufd $0x0,%xmm0,%xmm0
     804875e:	66 0f 6f 0b          	movdqa (%ebx),%xmm1
     8048762:	66 0f d5 c8          	pmullw %xmm0,%xmm1
     8048766:	66 0f 6f 53 10       	movdqa 0x10(%ebx),%xmm2
     804876b:	66 0f 6f 5b 20       	movdqa 0x20(%ebx),%xmm3
     8048770:	66 0f 6f 63 30       	movdqa 0x30(%ebx),%xmm4
     8048775:	66 0f d5 d0          	pmullw %xmm0,%xmm2
     8048779:	66 0f 7f 0b          	movdqa %xmm1,(%ebx)
     804877d:	66 0f 7f 53 10       	movdqa %xmm2,0x10(%ebx)
     8048782:	66 0f d5 d8          	pmullw %xmm0,%xmm3
     8048786:	66 0f d5 e0          	pmullw %xmm0,%xmm4
     804878a:	66 0f 7f 5b 20       	movdqa %xmm3,0x20(%ebx)
     804878f:	66 0f 7f 63 30       	movdqa %xmm4,0x30(%ebx)
     8048794:	83 c3 40             	add    $0x40,%ebx
     8048797:	3b cb                	cmp    %ebx,%ecx
     8048799:	77 c3                	ja     804875e 
     804879b:	0f b7 8a c0 00 00 00 	movzwl 0xc0(%edx),%ecx
     80487a2:	0f af c8             	imul   %eax,%ecx
     80487a5:	0f b7 9a c2 00 00 00 	movzwl 0xc2(%edx),%ebx
     80487ac:	0f af d8             	imul   %eax,%ebx
     80487af:	66 89 8a c0 00 00 00 	mov    %cx,0xc0(%edx)
     80487b6:	0f b7 8a c4 00 00 00 	movzwl 0xc4(%edx),%ecx
     80487bd:	0f af c8             	imul   %eax,%ecx
     80487c0:	66 89 9a c2 00 00 00 	mov    %bx,0xc2(%edx)
     80487c7:	66 89 8a c4 00 00 00 	mov    %cx,0xc4(%edx)
     80487ce:	0f b7 8a c6 00 00 00 	movzwl 0xc6(%edx),%ecx
     80487d5:	0f af c8             	imul   %eax,%ecx
     80487d8:	66 89 8a c6 00 00 00 	mov    %cx,0xc6(%edx)
     80487df:	83 c4 0c             	add    $0xc,%esp
     80487e2:	5b                   	pop    %ebx
     80487e3:	8b e5                	mov    %ebp,%esp
     80487e5:	5d                   	pop    %ebp
     80487e7:	90                   	nop 
    
packed/aligned 的處理,很明顯比 GCC 好很多,而且也運用到 MMX instructions,中間 movdqa/pmullw 恰好能夠處理 short integer data type (DWORD/2)。 GCC 在這部份顯然還有加強的地方,所以在 [GCC 4.1 Projects] 就有 [Autovectorization Enhancements] 的子計畫,其設計方式可以參閱 GCC source code 的 tree-vectorizer.c。
由 jserv 發表於 12:42 PM | 迴響 (1)

幾篇介紹 GPU 發展的中文文件

[電子工程專輯] 有許多一流的技術文件可以參考,而且大部分有中文翻譯,讀起來輕鬆許多,早上讀了幾篇 GPU (Graphics Processing Unit) 的文章與論文,不過有點枯燥,所以從 [電子工程專輯] 找了幾篇中文報導: 第二與第三篇顯然比較符合我的胃口,特別是我最近碰了 SIMD/DSP Programming。Stanford 大學繪圖實驗室的 Ian Buck 用淺顯的文字介紹了 SIMD 與 DSP 的差異:
    GPU在幾個主要方面有別於DSP架構。其所有運算均使用浮點演算法,而且目前還沒有位元或整數運算指令。此外,由於GPU專為影像處理設計,因此儲存系統實際上是一個二維的分段儲存空間,包括一個區段號(從中讀取影像)和二維地址(影像中的X、Y座標)。

    此外,沒有任何間接寫指令。輸出寫地址由光柵處理器確定,而且不能由程式改變。這對於自然分佈在記憶體之中的演算法而言是極大的挑戰。最後一點,不同片段的處理過程間不允許通訊。實際上,片段處理器是一個SIMD數據平行執行單元,在所有片段中獨立執行程式碼。

    儘管有上述約束,但是GPU還是可以有效地執行多種運算,從線性代數和訊號處理到數值模擬。雖然概念簡單,但新用戶在使用GPU運算時還是會感到迷惑,因為GPU需要專有的繪圖知識。
同時這篇文章也介紹到 Stanford 大學自行開發的 [BrookGPU] 計畫,作為包裝繪圖技術的高級語言,引述網頁的介紹:
  • Demonstrate general purpose programing on GPUs.
  • Provide a useful tool for developers who want to run applications on GPUs.
  • Research the stream language programing model, streaming applications, and system implementations.
文章的結論往往是最值得思考的地方,引述如下:
    對GPU運算感興趣的用戶努力將演算法映射到繪圖基本元素。類似Brook這樣的高級編程語言的問世使編程新手也能夠很容易就掌握GPU的性能優勢。存取GPU運算功能的便利性也使得GPU的演變將繼續下去,不僅僅作為繪製引擎,而是會成為個人電腦的主要運算引擎。
由 jserv 發表於 11:27 AM | 迴響 (1)

用 ImageMagick 實現 Lomography

剛剛閱讀 [Eason's Blog] 發現這篇 [Lomography],提到參考 [Lomography, UNIX Style] 一文,使用 UNIX 系統很普遍的 command line graphics package -- [ImageMagick] 來達到 Lomography 的效果。

這個 script 的原理是先模擬羽化的效果,然後調整反差與飽和度,合成後再做輸出,看起來很好玩,所以我拿 [個人首頁] 中的素描照片來測試: (左右對照,右圖是轉換後的效果)
要做出外框羽化的效果,透過 ImageMagick 可以很簡單達成:
    convert  -size 80x60 xc: \
             -fx '(1-(2*i/w-1)^4)*(1-(2*j/h-1)^4)' \
             lomo_mask.png
    mogrify -resize 800x600 -gaussian 0x5 lomo_mask.png
    
呈現的效果如下圖:
command line 的 ImageMagick 真是太神奇了。
由 jserv 發表於 08:15 AM | 迴響 (0)

補充:談踩地雷遊戲與 NP Complete

之前的 blog [落花水面皆文章 -- 談踩地雷遊戲與 NP Complete] 提到我們熟悉的踩地雷遊戲本身是 NP-complete 的問題,而剛剛閱讀 [演化的世界、變動的人生] 裡面的一篇 [原來踩地雷這個遊戲這麼困難],又提到一份更完整的介紹:[Minesweeper is NP-complete]。

這篇文章由 sed@free.fr 撰寫 (一時找不到作者本名,程式碼裡頭也沒看見),主要是補足 Richard Kaye 論文中欠缺的實做,同時將代數式轉化為視覺化的表達,文後有一份 [參考實做]。

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

August 24, 2005

MSN Messenger 帳號

雖然我是 [Jabber] 的支持者 (計畫剛開始時,我曾是一位測試開發人員),但是現在也「跟著潮流」用 Microsoft 的 [MSN Messenger] 作為 Instant Messaging 的工具。有一些朋友來信詢問我的 MSN 帳號,剛剛用 [Logogle] 產生下面的圖示:

慢慢的 key-in 進去應該就可以用了。基本上我大部份時間會開啟 MSN,並且使用 [gaim] 作為 MSN Client,所以請別傳一些「特別」的效果,這裡是看不到的。

[Logogle] 看起來不需要太複雜的技術,但是挺好玩的,可以建出類似 Google 配色的文字。
由 jserv 發表於 12:45 PM | 迴響 (4)

Mono's JIT for ARM

雖然很早就注意 [Mono 計畫],也聽過 [Miguel de Icaza 聊 Mono/GNOME],不過我是一直等到其 [Initial ARM JIT port in svn] 才去關心 Mono 的進展,畢竟 XScale (ARMv5TE) 對我的應用來說,是很重要的 target。在八月四日的 regression test on ARM JIT 顯示:


    make test in mono/tests reports 123 pass, 70 fail.

看起來已經很不錯了,也希望很快能夠在 [Nokia 770] 上面看到 Mono/,Net 的運作,我之前已經做 [Kaffe 在 Maemo 平台移植的現況] 的嘗試,現在 Mono ARM JIT 更是令我期待,也該排點時間 hacking :-)

對了,剛剛找到一篇舊文章 [跨平台的客場交鋒:.NET vs. JAVA on Linux],雖然數據都過時了,不過內容陳述相當富有趣味性,當作入門介紹還可以。

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

環境變遷

昨天寫完 [騎腳踏車上下班] 後,我閱讀到 [超越黎明] 的 blog [沙漠化的中國] 一文,當然我很清楚,這種「真相」早就被揭露,遙望衛星空拍圖再對照文字描述,的確令人怵目驚心,一份「中肯」的報告指出:


    經濟參考報(2004-08-13)報導說:土地沙漠化一直是困擾中國的環境問題之一,截至2000年,中國北方沙漠化土地面積已經達到了38.57萬平方公里,並繼續以每年3600平方公里的速度擴展。

這讓我想到,今年七月30日一早醒來,伸展筋骨後,怡然自得的徒步到附近的早餐店用餐,氣氛還不錯,所以我將身旁的報紙收起,因為種種無聊的八卦報導會打擾這樣愉悅的感覺。過了一段時間,到附近的 7-11 閱讀書報,不過我卻難過的說不出話。八月份的天下雜誌 (328 期) 的專題報導 -- 「誰來終結『鹿耳門悲歌』?」

p.226 到 p.234 的篇幅中,天下雜誌介紹的不是不可一世的大人物,更不是介紹顯赫的大企業,相反地,這是一個寧靜漁村的故事,以及一生甘願在此平安度過的人們。放眼望去一片典型波光粼粼的漁塭,到底會有什麼故事呢?我特別喜愛南台灣的人們,質樸且善良,還在成大唸書的時候,有時候會去鄉野踏青,迷路的時候,當地的居民不僅好心的帶路,甚至還會邀請我去那邊作客,最少都可以喝杯涼水。

然而,這邊報導指出這些生性質樸的人們,背負著沈重的負擔,不只來自經濟問題,更是身心無比的創傷。已停工二十餘年的中石化安順廠 (前身為台鹼公司) 在興盛的年代,是當時東亞產能最高的五氯酚工廠,但是製程中產生的大量汞與戴奧辛,不僅毒害當時的員工,更是對環境揮之不去的嚴重損害,是此,這幾十年來,吞噬著鹿耳門居民的健康...

報導中怵目驚心的圖片,讓剛用完早餐的我,渾身不自在,一個又一個的個案探討,更是讓我顫抖,這樣的報導我已經拜讀過,如今再讀一次,還是令人鼻酸。腫瘤、癌症、畸形、... 等不可思議的病症,就是戴奧辛污染的反應,這些質樸善良的人們,為何要背負台灣工業化發展的毒害呢?

可說是台灣真實版《永不妥協》電影主角的黃煥彰教授,長期從事環保運動,揭發二仁溪慘遭熔煉業者毒害的真相,至今,二仁溪才又慢慢的恢復原有的生態景觀,近年的鹿耳門是他關心且伸張環境正義的對象,面對種種阻撓,不惜動用各種管道,只為了用行動換取正義的黃教授這麼說:


    「每當深夜,我看到自己製作的鹿耳門癌症地圖,心中就有一陣酸楚, 因為每隔幾天,就有自己才探訪不久的罹癌村民去世了。」

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

August 23, 2005

騎腳踏車上下班

從今年開始,我就秉持「騎腳踏車上下班」的規律,到目前為止,都還能維持每天騎一個多小時上下班,如果每個月的工作日數是 20 天的話,來回的公車費用是新台幣三十元,那麼,省下來的金額已經可以讓我買幾台淑女車了。不同於 [廖長輩] 的超高級自行車,基本上我只騎台幣一千出頭的淑女車,反正在台北街頭也很難騎踩踏板飆車吧 *笑*

在台北騎腳踏車上下班除了毅力,就是空氣品質實在很糟糕,公車、汽車車,以及原本瀰漫的煙塵,常常讓我還沒抵達辦公室,就有些暈眩,當然,我會使用口罩,不過很容易吸不到空氣,只好摘下來,用力的吸上幾口廢氣... 這當然很糟糕,而且時常會有朋友轉寄相關的報導給我看,比方說 Yahoo!奇摩的新聞 [騎腳踏車上班 有損心臟]。英國尚有腳踏車專用道,儘管位於繁忙的公路旁,而台北呢?有這樣的設施,但一來不連續,二來沒什麼顯著效果,對於我每天往返內湖、南港,以及市政府等地,就必須擠在車陣中「博命」求生存...

我仍會繼續騎下去,也希望整個大環境能夠改觀,孱弱的我沒辦法對社會做出貢獻,但至少我不製造廢氣 (還邊騎腳踏車,邊「吸收」廢氣,大概也只是我能做的),長期來說,但願我能夠在空氣品質較好的環境工作。

雨天時,上下班彷彿都在游泳,雖然有雨衣包覆,可是還是全身濕透,整條路上只有我一個人騎著腳踏車在自虐,連我自己都不清楚為何要這麼做,或許這就是我的風格。大雨打在身上,眼鏡起霧根本無法使用,於是只好頂著四百度的近視慢慢前進...

想起黃湘怡有首歌〈吻雨〉:
    *天色有點暗 烏雲漸漸聚集結伴
     街上的人開始慌張
     和你在車站 暗喜傘被我故意忘
     今天的天氣很理想*
    
    #愛情它沒得加防腐劑 相愛要握緊
     創造些回憶 做瘋狂的事情
     太多的顧慮 會破壞此刻的即興
     露天的咖啡廳 播放著舞曲
     氣氛很A級
    
     只想和你去淋一場吻雨
     握著你濕熱的手心
     淋著吻雨 直到鼻頭麻痺
     大步大步 走向 雨後的天晴#
    
    @好想和你去淋一場吻雨
     狼狽中有一絲甜蜜
     就算引來 再多怪異目擊
     這一秒的世界 只屬於我和你
     (We're kissing the rain)@
    
    模糊的世界有一種魅力
    為平凡的一天 增加多一點點樂趣
    
我喜歡這句「狼狽中有一絲甜密」,每次在雨中猛採踏板時,總不免會有這樣的感動,我愛著我的理想,願意為創造回憶,燃燒自己整天作瘋狂的事情,就算是這樣的大雨,也不會澆熄我的熱情。

自勉之!
由 jserv 發表於 11:18 PM | 迴響 (6)

RANMAK 設計的 KDE Style

剛剛閱讀 [GOT 星球],發現 RANMAK 撰寫的這篇 [我設計的 KDE Style],提到他修改著名的 KDE Style -- keramik 與 [thin keramik],並且已經提交到 [KDE-Look.org],取名為 [Shine Keramik],明亮大方的配色,還不錯。希望很快也能移植到 Qt4,搭配之前 [Qt 4.0.1 釋出] 提到的特徵就更棒了。
由 jserv 發表於 10:15 PM | 迴響 (0)

PNG 處理最佳化

[PNG (Portable Network Graphics)] 已經成為今日相當重要的圖形格式,兼具品質與處理效能,而且沒有專利使用上的問題,近來連 [APNG (Animation PNG)] 這樣以 PNG 為基礎的動態圖形格式也現身了。我最近有一份基礎研究就是希望能針對特定的硬體平台,改善大量 PNG 圖形的顯示處理,重點會在於 renderer speed 與 memory usage 上。當然啦,這種「改善」絕對沒辦法讀篇類似 [ Optimization in GCC] 的文章,把 CFLAGS 用力調整後 (Gentoo-ish?),就可以獲得顯著的提昇。

在這個 model 中,將會在短暫的時間內載入 35 到 75 個 PNG 圖檔,解析度基本上是 QCIF / CIF,renderer 必須快速的給予呈現與切換,對於資源有限的 Embedded Systems 來說,是個很特別的挑戰。所以我決定先在 x86 上透過 Intel MMX/SSE 指令級來作驗證,並且閱讀 [A guide to PNG optimization] 一文做出發點。誠如 Cosmin Truţa 在這篇文章所提及 PNG 的特性:
    Unlike other lossless compression schemes, PNG compression does not depend solely on the statistics of the input, but it may vary within wide limits, depending on the compressor's implementation. A good PNG compressor must be able to take informed decisions about the factors that affect the size of the output.
PNG 壓縮不參考統計模型的方式,而是依據底層壓縮器的實做,影響 PNG 大小的因素有:
  • PNG 圖形的類型
  • PNG delta filter
  • Ziv-Lempel algorithm (LZ77) 的搜尋策略,依據 [zlib Reference Library] 這個參考的 Deflate 實做,透過 strategy 參數指定類型:
    • Z_DEFAULT_STRATEGY = 0, the default greedy search strategy.
    • Z_FILTERED = 1, a strategy in which the matches are accepted only if their length is 6 or bigger.
    • Z_HUFFMAN_ONLY = 2, a fast strategy in which the Ziv-Lempel algorithm is entirely bypassed, and all the symbols from the input are encoded directly by the Huffman coder.
    • Z_RLE = 3 (appeared in the zlib-1.2.x series), a fast strategy in which the LZ77 algorithm is essentially reduced to the Run-Length Encoding algorithm.
  • Deflate encoder 內部 Huffman-coding buffer 的空間
該文後半部的 [PNG (lossless) optimization programs] 就羅列許多基於以上參數處理作出發的最佳化工具程式,而我傍晚就開始依據 [ How to optimize code for MMX processors] 一文的提示,開始研讀 libpng 裡面 MMX optimization implementations 以及 zlib compressions 可以最佳化處理的部份,著手驗證。
由 jserv 發表於 07:54 PM | 迴響 (0)

JavaTwo 2005 與會紀錄

稍早在 blog [Free Java Runtimes 簡報上線] 大略提到我在 [JavaTwo 2005] 的 session,並且也在 [Planet Classpath] 寫了一篇英文的介紹,不過顯然太簡略了。與其自己描述,乾脆引述一些先進的 blog,可參考: 還有許多熱心的朋友在 [JavaWorld@Taiwan 論壇] 發表心得,這裡就不贅述了。此外,本次的收穫除了聽了很多前輩精彩的分享,就是拿到 [侯捷]、[William Yeh],以及 [Qing 老大] 這三位前輩的親筆簽名,為了留念,我翻拍後放到 [jserv的相簿]。《多型與虛擬》是我學習 C++ Programming 的第一本書,也是因為侯老師對於 MFC 尋幽訪勝的探討並重新實做 MFC-lite,激發我投入 Java VM 的研究,而葉博士的譯著《物件導向設計模式》更是陪伴我度過漫長的兵役生涯的精神兼技術食糧,至於 Qing 老大的書,我的確有買,只可惜太重了 (presentation 要帶 notebook,又在背包放了葉博士的大作,所以...),只好拿出筆記本來簽名,但是小時候在程式設計樂園看到 Qing 老大發表的 post,獲益良多,就很希望有日可親眼見到廬山真面目,如今終於有機會了。

[按:本次擔任 JavaTwo 講師,真是「撈翻了」,又可以聽到這麼多精彩的演講,還遇到技術領域的偶像!]
由 jserv 發表於 10:25 AM | 迴響 (0)

為學之道

早上起來看 Slava Pestov 的 blog [James Gosling doesn't understand sin/cos?],如果只從字面來看,這是說 Java 之父 [James Gosling] 不懂 sin(x) 與 cos(x) 嗎?這故事的開始是 James Gosling 問及為何 sin(x) 與 cos(x) 函數的週期是 2*PI 呢?而且為何不能以角度取代徑度呢?這種懷疑的出發點顯然不是為了數學,而是從一個架構設計師的角度,就 sin(x) 與 cos(x) 兩函數的輸入域與輸出域來說,都必須使用 primitive type 最大的型態來表示,在轉化數學問題到實際的程式碼,是否可能兼顧便利性與資料儲存的效能?

我相信 James Gosling 絕對懂這些數學原理,而且絕對是這方面的高手,但我認同他的懷疑,有時候我們必須從不同的觀點來看待既有的事實。而 Slava 在 blog 就是從此出發,他擔憂如果程式設計師只有懷疑與假設,並沒有廣泛的求證,那麼,或許以後開根號的函式實做輸出型態或許是 int。Rob 在評論解釋道:
    Well, David, you are missing one of Slava's key points: people who do not perform calculus for fun over lunch write bad code, those who were the apple of their calc teacher's eyes are coding poets. In fact, a hilarious metrics study was done recently showing that mathematicians and scientists write appallingly bad code. But Slava doesn't like metrics, which is somewhat bizarre, given that he professes his love for math.
後面的評論就更有意思了,所謂的 "Good code" 到底是如何?成功的專案是否都有文質俱佳的程式碼呢?

而讀到這裡,讓我想起昨天閱讀 [s88's blog] 的一篇 [16th VLSI/CAD conference],我對 VLSI 一無所知,但是劉教授的 Neuroelectronics 領域的確很吸引我,並且我對建構的過程有更大的興致,s88 提到:
    劉教授除了解釋專業上的問題外,也說了很多做研究上的重點:
    • 先定義大問題,小問題就會浮現。
    • 不要把自己框住,以劉教授為例,他的主要研究領域是晶片設計,但是,為了研究視網膜晶片,他必須和醫學院的醫生合作,他自己也成了半個眼科醫師,這一點讓我有新的體悟。
    • 不恥下問、不恥下問、不恥下問,劉教授至少說了三次以上的『不恥下問』,他認為,既然不要把自己框住,就必須與他人合作,可是,如何放下自己的身段,讓他人與你合作的愉快,是一件重要的事!
我大概是從高中三年級開始,自修 Computer Science 的部份知識,如之前 blog [Realtime Kernel] 所提及,當時已經很明確的設計目標,至少要設計一個 kernel 出來。必須承認的是,大學教育給我最大的收穫並不是 computer science,而是人格的震撼,但這過程中,我有幸可以接觸到當時一流的人物,比方說成大電機博士班的 unixer 學長。

適度的懷疑與假設是必要的,而問題在於求證的過程,我們該如何「不恥下問」的放下身段投入去作?這絕對是相當值得去思考的議題。在 s88 的 blog 文後,提到「研究生的為學之道」,基本上這對我來說,是很遙遠的名詞,作為一個中輟生,光 paid work 可能就弄得昏天暗地,更別說進修了。不過,清大電資學院院長吳誠文教授提到幾個重點,倒是可以看看:
  • 大學教育與研究所教育最大的不同,就是研究生必須去開創新的知識,有別於大學生,只是知識的消費者。
  • 閱讀可以增加思想的深度以及廣度。
  • 碩士生的研究目標:
      survey -> study -> verification -> justification -> presentation presentation is the most important thing!
  • 敬業是做任何事成功的要素!
我沒有受過完整的「高等教育」,大概也難以理解箇中的真諦,但與其作為一個知識的消費者,我喜歡開拓自己的見識,用雙手把一些想法實現出來,或許這就是驅使我成長的動力。至於說「碩士生的研究目標」,程序似乎在我高中時代就體驗過了,當然,那時候做的東西只是小玩具,但後來才慢慢能理解 "presentation is the most important thing!" 這句話的寓意。

在 2004 年以前,我還是孤芳自賞的躲在電腦前面鑽研自己的計畫與領域,雖然有透過 IRC 與 mailing-list 來跟國外的開發者交流,但基本上還是很封閉的,頂多是之前在學校參加比賽做了幾場簡報,但範圍還是很小。而從 2004 年中開始,陸續整理自己的心得,寫了幾篇短文,並且做了 Presentation,一開始,我並不是有高度教育熱誠的人,面對台下來自不同背景的聽眾,總覺得不知如何進行,不過後來從 F/OSS 技術的推廣,以及對於特定領域的經驗分享後,就慢慢比較有感覺,也獲得不少 feedback 與指教,這些對於我釐清觀念與確立目標,很有幫助,也因此,在 [2005 下半年計畫] 提到,我還是會繼續作公開的分享,看看能否激發出更多有趣的效應。

有時候信箱會收到一些朋友的來信,問及「XXX 技術該如何學習?」、「要如何學習 Linux 程式設計?」「如何作 VM 一類的基礎建設?」、... 等等,我想為學之道就正如前面所述及的,自己去體驗還是最重要的。
由 jserv 發表於 08:05 AM | 迴響 (1)

August 22, 2005

Hula 展示

之前的 blog [不虎爛的 Hula],提到 Novell 正在資助許多開發者進行一個 Web-based Office/Enterprise 級的解決方案 -- [Hula],稍早 [Roy Chen] 也在 [HKLUG] 報導過 [Novell 展開開源群組軟件專案 - Hula]。而 Nat Friedman 在 blog [Hula Web Interface] 展示了最新 Hula 的進展,可以連結以下的 Macromedia Flash 動畫觀看:

看完展示後,覺得現在 Web-based 的技術已經進步到這種程度了,頗神奇阿 (好吧,孤陋寡聞),而且可用性應該是非常高了。

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

Realtime Kernel

今天開始研讀 Realtime Linux 實做的技術,首先我閱讀一篇訪談 [A comparison of real-time Linux approaches]。這篇文章介紹很多以 Linux Kernel 為基礎的 Realtime 途徑,相當明確,可惜是對應的實做介紹付之闕如,所以我就繼續找資料了。

想起書桌上有一本經典著作《即時多工核心程式設計》:

這是交大電控的胡竹生教授與尹燕陶的大作,我在高中三年級的時候開始拜讀,書中的 TauOS 實做給我很大的助益,我得以在 MS-DOS 上體驗 Object-based Realtime Kernel 的實做,並從中培養作業系統的理論基礎,爾後我開發 Venux Kernel 與 JK (Just the Kernel),都受這本大作的影響。還在一中宿舍的我,常常拾起這本大作,思索箇中的奧妙,宿舍沒有電腦,更沒有網際網路,所以我用傳統書信,寫給胡教授詢問一些細節,沒想到還收到回信,真是好感動...

屈指一算,高中三年級拜讀的兩本書 -- [《多型與虛擬》] 與這本大作,至今對我影響甚大,否則也不會如 blog 所及 [我為何選擇工程技術,而非其他行業?],更別說能有些微的成果了。

嗯,繼續來研究 Realtime Kernel。
由 jserv 發表於 08:04 PM | 迴響 (0)

在 Action Dual PC Modem 上體驗 uClinux

對很多人來說,Embedded Systems 似乎很遙遠,但事實上我們身邊充斥了一堆這樣的裝置與應用,在 [uCdot] 上有一篇文章 [Action Dual PC modem support in uClinux],作為具備網路能力的 [uClinux] 展示,再好不過了,而且可以用美金 $60 體驗這種「親手打造」的快感。

[Actiontec DPCM stuff ] 相當詳細的從硬體規格探討 (兩個 Ethernet port、內建 56k modem、2 MB flash、8 MB RAM,以及 168 MHz ARM9 CPU),Johann Hanne 帶領我們逐步建構 GPL'd firmware,並提供必要的 kernel patch、boot loader,以及 userland programs 等等。

附帶一提,網頁右上方的圖片實在太棒了:

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

我為何選擇工程技術,而非其他行業?

昨天工作時,抽空拜讀 [電子工程專輯],在 2005.5.1-15 出刊這期的末頁有篇 Frank Burge 的短文 [讓孩子的夢想起飛],讓此際的我相當感動,部份節錄如下:
    擁抱本身說明了一切,老師永遠是我們心中的超級明星。能夠贏得這樣擁抱的職業很少。你還記得上次擁抱律師、股票經紀人或水電工人是什麼時候?

    幾週以前,在葡萄酒鄉召開的會議上,播放了一部介紹六位工程師精彩人生的兩分鐘紀錄片。每位工程師都談到了自己為何最終會選擇工程技術,而非其他行業。他們都表示,自己對於事物的工作原理以及創造事物的原動力抱有濃厚的興趣。一位工程師放棄了自己在醫療領域的研究,最終成為一名非常成功的工程師。另一位博士在電腦系統領域取得了成功,使癌症研究人員執行模擬的時間由一年降低至一天。這或許不能贏得那種熱情的擁抱,但當世界知名的癌症研究專家也由衷發出讚嘆時,這種成就感自然不言而喻。六位工程師都同意,正是因為自己的工作深刻地影響著許多人,帶給他們極大的成就感。是的,技術領域的創新人也是我們心中的超級明星。
雖然我還不認為我已經具備工程師的條件,但是真實的身份總是掛個高級工程師或專案經理的頭銜,基於名分不實的羞愧,所以我基本上只自稱為工讀生。儘管如此,雖然還不是合格的工程師,日子總是要過,工作與研發還是要作,而且甚至會走的更艱辛些。

現在工作的經驗是相當有趣,對於我這個沒有涉獵過相關知識的人來說,是很大的挑戰,在此之前,我沒有碰過任何一個 codec,甚至沒有認真的學過微積分、線性代數,以及工程數學,任何一條方程式或推論對我來說,都是無可言喻的黑盒子。

目前已經稍微有進展,讀這篇短文的時候,我正在作若干 benchmarking,隨著數字的起伏,我的心情也在擺動,老實說,我也很想問問自己:
    「我為何選擇工程技術,而非其他行業?」
我很容易被簡單的幾個字所感動,很難在紙上闡述我昨天的感動,但是由衷的希望自己能成功,能夠在這個領域提出一些建樹。或許是基於類似的理由,所以我願意花時間從事 Free/Open Source Software 發展,儘管至今的貢獻非常有限,但正如該文結尾所說:
    「六位工程師都同意,正是因為自己的工作深刻地影響著許多人,帶給他們極大的成就感。是的,技術領域的創新人也是我們心中的超級明星。」
我不是明星,但我願意作個好的螺絲釘。

自勉之!

群 於台北內湖住所,July 6, 2005
由 jserv 發表於 07:44 AM | 迴響 (1)

No man is an island

John Donne 的作品〈Meditation XVII〉[1] 有句相當經典的名句:
    "No man is an island."
這裡的 "man" 有時也寫作 "one",下午看了一篇賞析[2],John Donne 著名的冥想過程,我們可以引述其精髓之處:
    "All mankind is of one author, and is one volume; when one man dies, one chapter is not torn out of the book, but translated into a better language; and every chapter must be so translated...As therefore the bell that rings to a sermon, calls not upon the preacher only, but upon the congregation to come: so this bell calls us all: but how much more me, who am brought so near the door by this sickness....No man is an island, entire of itself...any man's death diminishes me, because I am involved in mankind; and therefore never send to know for whom the bell tolls; it tolls for thee."
我試著作中文翻譯:
    「每個人都是生命詩章的作者,都有自己的份量;當人死去,原本的詩章並不會被移出,相反地,是轉譯成更好的表達語言;而且每個章節都會歷經這樣的轉化歷程... 是此,如此的訓示並非只來自傳教士的叮嚀,也令人歡欣:然而,對我這樣如此迫近病魔的人來說,能有多少時日... 沒有人是一座孤島,作為自己生命的全部... 任何人的死去讓我更萎靡,因為我涉入人類的生活,也因此,別問哀鐘為誰而鳴,鐘聲為你而鳴。」
很生硬的想闡述作者的意思,不過顯然僅能斷章取義。John Donne 是十六世紀的神學家兼詩人,這一段顯示出人的死亡與超自然力量的神秘感情,從中產生感悟與思考新 面向。該詩被海明威的《戰地鐘聲》所引用,作為一個讀者,也早已融入情境,面對種種戰局的未知數,深怕生命的哀鐘孤鳴之際。

李敖大師則翻譯了部份段落,也就是我上述忽略之處,引述如下:
    沒有人是孤島
    譯者:李敖

    沒有人能自全,
    沒有人是孤島,
    每人都是大陸的一片,
    要為本土應卯。

    那便是一塊土地,
    那便是一方海角,
    那便是一座莊園,
    不論是你的、還是朋友的,
    一旦海水沖走,
    歐洲就要變小。

    任何人的死亡,
    都是我的減少,
    作為人類的一員,
    我與生靈共老。

    喪鐘在為誰敲,
    我本茫然不曉,
    不為幽明永隔,
    它正為你哀悼。
這部份的原文是:
    "No man is an island, entire of itself,
    every man is a piece of the continent, a part of the main,
    if a clod be washed away by the sea,
    Europe is the less, as well as if a promontory were,
    any man's death diminisheds me, because I am involved in mankind,
    and therefore never send to know for whom the bell tolls,
    it tolls for thee."
當然大師的翻譯絕對比我好許多,而只是因為紀錄到一半,才想起李敖大師曾在獄中作此創作,但我已經粗略的翻譯過,推敲字義的紀錄對我還是有所價值的。

[商業周刊] 2005.6.27 出刊的第 918 期的 p.88 起,五頁的篇幅做了「走出孤島」的系列報導,孤島化的台灣社會,人與人彼此疏離,套句晚晴婦女協會總幹事許文青的說法:
    「在虛擬的網路,當你說出不幸的遭遇,好多人會同情你,轉寄一大堆文章給你,但這些都無濟於事,這時,真正需要的,是一雙拉你出去的手 ,陪你到外面走走,好好吃頓飯,那才是改變的開始。」
從內湖的小山踏青結束後,我就一直思考許幹事的這席話,再三的訴說:
    "No man is an island."
這是我當下處境最好的寫照,而我要如何走出象牙塔?與其等哀鐘,是不是有更積極的作為?

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

[1] 原文可參考 [Meditation XVII]
[2] 事實上這是印第安那州立大學的一門學程,可參考 [John Donne -- Meditation XVII: No man is an island...]
由 jserv 發表於 07:28 AM | 迴響 (0)

小丑的宿命

七月 27 與 28 日,參加 [ESC-Taiwan] 舉辦的第五屆嵌入式系統研討會暨展覽會,議程結束時,從國際會議中心走回捷運站的路上,看著台北市政府與許多雄偉的建築物,也包含 101 大樓,或許我曾經對這些工藝極致的美感到讚嘆,但是此際的我,只想到尼采的一首詩 <致歌德>:


    所謂不朽
    只是你營造的假象
    至於上帝,令人迷疑
    也只是詩人所說的謊...

    世界之輪,轉動不停
    飛掠過一個又一個的目的;
    恕者視之為宿命,
    癡人稱其為 -- 遊戲...

    世界遊戲主宰天地,
    摻揉所有存在與幻象;
    永恆的癡迷
    將我們捲入這繽紛萬象...

而,歌德的《浮士德》這麼寫到:


    Alles Verganglich
    lst nur ein Gleichnis

於是,我癱坐在路旁公園的鐵椅上,面對世間種種虛無的幻象,只得喃喃的念著這幾句,是的,我們以遊戲的參與者的姿態涉入這個世界,早已知悉世界流變的殘酷真相,卻絲毫不厭倦、不減熱情,仍以成為箇中的悲劇英雄為標的,某種程度來說,我們給予這些裝瘋賣傻、故作癡愚的英雄予以高度評價,或許,這就是身為小丑的宿命。

Narr,這是詩人的面具。

群 於台北住所,July 28, 2005

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

Excelsior

十九世紀的美國詩人 Longfellow 在瑞士遊覽時,寫下相當有名的作品 〈Excelsior〉[1]:
    Henry Wadsworth Longfellow - Excelsior
    
    The shades of night were falling fast,
    As through an Alpine village passed   
    A youth, who bore, 'mid snow and ice,
    A banner with the strange device,    
    Excelsior!                       
    
    His brow was sad; his eye beneath,
    Flashed like a falchion from its sheath,
    And like a silver clarion rung          
    The accents of that unknown tongue,
    Excelsior!                         
    
    In happy homes he saw the light
    Of household fires gleam warm and bright;
    Above, the spectral glaciers shone,      
    And from his lips escaped a groan, 
    Excelsior!                        
    
    "Try not the Pass!" the old man said:
    "Dark lowers the tempest overhead,   
    The roaring torrent is deep and wide!
    And loud that clarion voice replied, 
    Excelsior!                          
    
    "Oh stay," the maiden said, "and rest
    Thy weary head upon this breast!"    
    A tear stood in his bright blue eye,
    But still he answered, with a sigh, 
    Excelsior!                         
    
    "Beware the pine-tree's withered branch!
    Beware the awful avalanche!"            
    This was the peasant's last Good-night,
    A voice replied, far up the height,    
    Excelsior!                         
    
    At break of day, as heavenward
    The pious monks of Saint Bernard
    Uttered the oft-repeated prayer,
    A voice cried through the startled air,
    Excelsior!                             
    
    A traveller, by the faithful hound,
    Half-buried in the snow was found, 
    Still grasping in his hand of ice 
    That banner with the strange device,
    Excelsior!                          
    
    There in the twilight cold and gray,
    Lifeless, but beautiful, he lay,    
    And from the sky, serene and far,
    A voice fell, like a falling star,
    Excelsior! 
    
"Excelsior" 對應中文的用語,最適合的翻譯大概就是「超越巔峰」,每一段的結尾都用此來強調。對詩人來說,征服山嶽的攀爬是既明顯又紮實的比喻。試看這個青年一路上,不畏險阻,並掙脫愛情、人間溫暖,以及安逸的享受,沒有這外界的束縛,攀登的過程少去許多累贅。更明確來說,在這個青年人的心中,思緒與原始的慾望早已獲得焠煉,此際,一心一意只有攀登高峰,就與嚴苛的天候環境搏鬥著...

最後,青年人死在雪地,皚皚的白雪充當最佳的棺木,青年手上緊握著的紙條,成為最明顯的墓誌銘:
    Excelsior
這墓碑如是說。

在人生路途中,孤獨的 Excelsior,何需他人相伴?

群 於台北內湖住所,July 29, 2005

[1] 原文以及 Longfellow 其他作品,可以參考 [Henry Wadsworth Longfellow - Excelsior] 與 [American Poems]。
由 jserv 發表於 06:53 AM | 迴響 (0)

August 21, 2005

在 Linux kernel 外應用 GIT,兼談分散式版本控制系統

如果要探討版本控制系統,Linux kernel 是非常特別的案例,拜網際網路所賜,獲得快速的發展,每天都有數十個 patch 被提交,而且有難以計數的學術與業界的研究計畫以 Linux kernel 為主軸,不用幾天,這些 patch 修改的幅度就大得驚人,所以許多工具相繼被提出以降低工作量。

之前在 [兩個大姑寫的〈Hacking the Linux 2.6 kernel〉] 一文提到廣為使用的 [cogitod] 工具,可管理為數眾多的 patch(set)。而原本 Linus 推薦使用的 BitKeeper 因為授權的議題,鬧得不愉快,所以 Linus 就自己搞一個,在 KernelTrap 上的專文 [Linux: Git Homepage] 介紹到 Git 這個新的 BitKeeper killer 已經有獨立的 [專案網頁],以及其概略的發展背景:
    "GIT falls into the category of distributed source code management tools, similar to Arch or Darcs (or, in the commercial world, BitKeeper). Every GIT working directory is a full-fledged repository with full revision tracking capabilities, not dependent on network access to a central server."
稍後,KernelTrap 又有一篇新文章 [Linux: Using Git For More Than The Kernel],既然 git 已經逐漸勝任 Linux kernel 這種嚴苛且特別的 VCS 需求,是不是有機會應用到其他專案去呢?後面的評論中,erikharrison 提到:
    SVN versus Git

    Subversion is in my mind the best of the classic centralized version control systems.

    Bitkeeper is the best of the new model of distributed version control systems.

    Git is a fast userspace, versioning, content addressable file system, which can be used to implement many of the things that Bitkeeper does.

    Linus really has a different philosophy of version control than that of the last 20 years. BK is very close to his vision, but not quite there. The centralized model, to Linus's mind (and I think he's right) is fundamentally broken, and SVN's on disk formats are pitifully slow for a project of the kernel's size. As such, the facts that
    • Git is not a complete version control tool
    • Git is relatively featureless
    • Git has very little in terms of a supporting toolset
    don't matter to Linus. Git meets his needs better.
實際的應用方式可以參考 XMMS2 hackers 的說法:
    We already use it.
    Comment posted by tru, August 16, 2005 - 05:12

    XMMS2 developement has been done in GIT for more then 3 months now. We are very happy about it and it works really well since we came from the free version of bk before.

    Our gitweb is here: http://git.xmms.se/
同時其他評論也相當精彩,Linux Kernel 配合高度分散式版本控制系統似乎是很值得探討的議題。
由 jserv 發表於 06:05 PM | 迴響 (0)

開放的數位攝影影像技術

昨天在 #debian-zh 中,pnt 問我有沒有玩 DC (Digital Camera),我在 blog [攝影練習] 提過今年才開始接觸,發現 [SONY T33 數位相機] 挺適合我這種腦袋跟裡面的 circuit 一樣死板的人使用,所以 [jserv 的相簿] 好不容易擠出幾張圖片。

但是,真正的問題不在硬體本身,事實上 Digital Photography 本身就是大學問,若再考慮到商業考量的話,要透過 F/OSS 實做完整的支援,困難度相當高。在 GNOME 開發者大會 -- [GUADEC] ,[Hubert Figuière] 連續兩年為我們探討這個主題,可以參閱 [Digital Photography in GNOME environment] 與 [Digital Photography in GNOME],除了要面對種種封閉的格式,同時整合上更是難題,不過現在已經有很不錯的突破,比方說 dcraw 與 f-Spot 軟體的出現。

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

更新簡報:綜觀 X Window System 與新發展

之前在 blog [演講:綜觀 X Window System 與新發展] 提到我在八月27日會應 SA@Taipei ([Study-Area] 台北服務處) 之邀作這個主題的分享。因為之前的對象不是社群的朋友,所以規劃的大綱看起來比較生硬些,而我剛剛調整了內容,加入一個新項目: [桌面系統整合],預計有以下議題:
  • IPC (Inter-Process Communications)
    • Clipboard
    • DCop
    • D-Bus
  • Framework
  • Graphic backends
  • Office technologies
同時,我也打算提供幾份紙本印刷的 slides 給 [報名的朋友] (依據某個神秘的 F''(x) function 來決定),上面會有我的簽名 + [GnuPG] fingerprint,希望多多利用。

正如之前說的,為了確保介紹的是最新的技術,所以簡報是當天凌晨起床打的,所以這段時間歡迎提出建議與指教,相關的討論可以參考 [酷!學園論壇],謝謝!如果順利的話,今年十月份在台中還會分享一次。
由 jserv 發表於 10:28 AM | 迴響 (1)

August 20, 2005

FreeDesktop 眾多專案 commit log 的 RSS

之前的 blog [神奇的數字] 顯示我訂閱的 RSS 數量後,一定會有人很好奇,這數字是怎麼來的呢?基本上,我把我有興趣的專案,比方說 Linux kernel、Mozilla、GNU Classpath、GCC、FreeDesktop、OpenOffice、... 等等的 RSS (developers' blog、CVS/Subversion commit log,或者是 news archive) 都訂閱,如果累積幾天沒閱讀的話,就會衝到這個數字 :(

在 Xorg mailing-list 上,Ely Levy 回覆 [commit list dead?] 時提到 FreeDesktop 眾多專案的 commit log:


這樣就可以透過 RSS Reader 觀看最新的發展動態了,如果跟我一樣沒事作的話,還可以把其他專案也一併訂閱,就算不參與開發,光看到這些 log 就熱血起來了 :-)

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

簡報:自由軟體授權分析

之前的 blog [自由軟體授權分析] 提到我在今年五、六月份的時候曾經做了一份簡報 (五月初稿,六月介紹),是介紹自由軟體授權與 Case study 的,凌晨醒來準備開始撰寫新版本,趁我還沒改壞之前,先放出六月份的簡報: 剛剛已經寫了一部分新的題材,除了談軟體授權的議題外,會延伸之前提到的 [熱血之餘談軟體授權]、[且看軟體專利毒害],以及 [自由軟體授權與 Sun Microsystems] 等議題,這些都是 "Trap",我們要如何避免陷阱 (應該逃離陷阱並且也不該設下重重圈套),以及如何從既有的模式找出潛在的授權危機,我想這是相當重要的。

此外,進一步的閱讀可以參考: 準備簡報的時候,只跟一位法務人員交換過意見,並未深入探索,這是很大的遺憾,有時間的話,應該多找些資料。
由 jserv 發表於 07:45 AM | 迴響 (1)

Qt 4.0.1 釋出

剛剛閱讀 KDE.News 發現這則新聞 [Trolltech Releases Qt 4.0.1],引述新聞稿訊息:
    Among the over 450 bug fixes and optimizations are numerous improvements to raster engine, X11 engine and QPainterPath, significantly speeding a range of drawing processes and introduction of top-level window transparency on X11.
這次的 Eye-candy 是 "top-level window transparency on X11",並且有許多 bug-fixing 與最佳化,看起來真棒 (雖然我已開始用 snapshot build 了),而稍早在 blog [GNU Classpath / Qt4 / Kaffe] 提過一些展示,剛剛則 commit 到 Kaffe.org 的網頁 [Screen Shots - Kaffe's Qt AWT backend] 上,不過寫 blog 的時候才發現放錯圖,算了,等 Qt4 AWT backend 改得更好的時候再更新吧。

Qt rules!
由 jserv 發表於 06:46 AM | 迴響 (0)

August 19, 2005

2005 下半年計畫

即將邁入九月份,這裡稍微紀錄我個人在今年下半年的計畫與規劃。

公開分享的主題: 此外,希望還有機會延續之前 blog [再談「自由創投」] 所提到的概念,用更具體的方式來落實,讓 [夢幻軟體計畫] 能有更多朋友參與,同時我也會試著去找 sponsor。

至於我自己個人的規劃,很榮幸在今年十月與十一月份,獲得 [華寶通訊股份有限公司] 的經濟資助,所以這段時間我可以 Full-time 作 Free / Open Source Softwares (以下簡稱 F/OSS) 的發展,所以我會利用這難得的機會把之前 blog 提到的 [最近的研究方向] 完成到一定的程度,更明確的來說,我要完成以下項目的雛型:
  • Kaffe 與 GCJ 的聯姻 -- 以 GCJ 為主體的 Kaffe-based FDO (Feedback-Directed Optimization)
  • Embedded Graphics Integrated Toolkit based on F/OSS
  • GCC 4 Tree-SSA optimization with Vectorization
  • Gecko 與 KHTML 的 Hacking
再來,希望自己能利用這段時間唸點書籍,想把電子學與數位邏輯電路重新學過 (說來慚愧,雖然以前曾經註冊成為成功大學資訊系的學生,可是這些學科從來沒有用心去唸,甚至連課本都丟了),今年花了一段時間在做 codec,對這些基本的知識完全沒概念,只能囫圇吞棗的的研習,效果非常糟糕。最後,希望能夠出門踏青、認識新朋友,或者找尋人生的出路。

That's all. 祝我下半年順利!
由 jserv 發表於 02:29 PM | 迴響 (1)

Free Java Runtimes 簡報上線

昨天的 JavaTwo 演講主題 [Free Java Runtimes] 終於落幕,而 [簡報也上線] 了 (PDF 格式),有興趣的朋友可以參考,並請多指教。

我第一次參與 JavaTwo 盛會,也是第一次在這樣大型的會議發表,老實說挺緊張的,錯誤百出。演講前幾分鐘突然有個靈感,自作聰明用 Cairo 寫一個 On-screen clock (based on fdclock),放在簡報的左下角,這樣就可以提醒自己時間,出發點不錯,而且我也在短暫的時間 coding 完,但是忘記 debug... 開始演講後,總覺得時間有點奇怪,後來才發現秒針放錯位置... Orz

就這樣,耽誤很多與會者寶貴的時間,整個 session 延後好久才結束,出來遇到 moli 學長,真不知道該說什麼 :(

不過還是有一些有耐心的朋友聽完並且提供指教,這裡一併感謝。喔,還遇到以前唸成大資訊系的學弟妹,差點都認不得了。雖然這是很冷門的 session,但還有不少朋友參與,讓我覺得很開心,希望 Free Java Runtimes 能夠對各位有幫助,更希望能有更多的學術研究或工業應用是使用這些成果。

這是我第一次用 [OpenOffice] 準備大型演講的 slides,這 97 頁 (PDF 版本是 91 頁) 讓我用上 48 小時來準備,其中有 16 小時是卡在 GDB 上,因為我對於版面覺得不滿意,拿 source code 來改,不料一直 crash,debugging 的過程中花了很多時間。

最後,要感謝 moli 學長的邀請,雖然我表現得很糟糕,但是如果沒有 moli 學長的鼓勵與背書,就沒有這個機會,希望自己能夠再加強。

由 jserv 發表於 11:54 AM | 迴響 (3)

August 16, 2005

GNU Classpath / Qt4 / Kaffe

昨天在 Ubuntu Breezy 上把 Qt4 與 Kaffe cvs head 給 build 起來,主要是測試 Dalibor Topic 最近的 commit [Merged in Qt4 peers from Classpath and added build machinery],這是 GNU Classpath hacker -- Sven de Marothy 的最新力作,Qt4-based AWT peer 實做,同時我也會在今年的 [JavaTwo / Free Java Runtimes] 議程作介紹,如果時間充裕的話。

因為 Breezy 收錄的 Freetype 是 cvs repository 的版本,API 已經更動了,所以我在編譯的過程中遇到一些問題,動手做了[Qt 4.0.1-snapshot-20050814 配合 FreeType 的 API 更動修正] 與 [Qt 4.0.1-snapshot-20050814 的 ctype 引入編譯錯誤修正] 這兩個 patch,現在看起來就可以動了。

不過很快我又發現 GNU Classpath 上的 AWT EventHandler似乎出問題了,Sven 在 mailing-list 回覆: [Merged in Qt4 peers from Classpath and added build machinery]。

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

Shorthand Aided Rapid Keyboarding (SHARK)

在 mobile handsets/devices 中,輸入一直是高難度的議題,有許多方法相繼提出,其中 IBM alphaWorks 提供了 [Shorthand-Aided Rapid Keyboarding] 的解決方案,簡稱 SHARK,以下引述網頁介紹:
    Shorthand Aided Rapid Keyboarding (SHARK) is an advanced pen-based text input method for mobile devices. It combines novel pattern recognition technology with a stylus keyboard. A new user may trace the letters on the keyboard to enter a word. Over time one may remember some or parts of the patterns and speed up the text writing.
該頁面同時提供一份 [動態展示],我摘錄其中幾個概念性的畫面作為說明:

當我們在拼寫 "word" 這個字的時候,在縮小型的鍵盤大致是依據上圖的順序,注意到 keyboard layout,這是 IBM 研究人員針對個別字母出現頻率作調整的新排列,並且儘可能縮短字母間的距離,剛剛的 "word" 的移動量就可以清楚的從 w --> o --> r --> d 去表現。

上圖是實際使用的情況,當 Pen-based Input Devices 接受輸入時,其 stroke 在 SHARK 的呈現方式就是如上,看動畫可以更明暸。最後,是整個 SHARK 的 Block Diagram:

詳細的設計可以參閱論文 [Shorthand Writing on Stylus Keyboard]。
由 jserv 發表於 03:26 PM | 迴響 (0)

August 15, 2005

這張相片...

上週六 [DebianBirthdayParty2005] 相當成功的落幕,此次與會的朋友人數又創新高,有許多新朋友加入,連久違的蕭永慶前輩都前來指教,晚一點我會寫一篇聚會紀錄。

剛剛看 [Debian Birthday Party 2005] 討論 thread 中 WalkingIce 拍攝的 [聚會照片] 中,瞥見 [我的照片],差點暈倒... 什麼跟什麼阿?!

我只是稍微介紹 "jserv" 的念法,結果...
由 jserv 發表於 11:45 PM | 迴響 (4)

Micromonitor 簡介

服務於 Lucent 的 [Ed Sutter] 是在 Embedded Systems 與 Firmware 領域響叮噹的大人物,他的大作 [Embedded Systems Firmware Demystified] 一直是這個領域的經典著作。在 2000 年底,Lucent 同意 Ed Sutter 將他多年處理 firmware 與 boot loader 的通用工具 [MicroMonitor (uMon)] 以 [Lucent Public License] 釋出,可參見新聞稿 [Lucent releases device boot software as open source]。這本專書就是詳盡的介紹 Firmware 相關技術背景,並且指導如何使用並移植 MicroMonitor。

此外,在 LinuxDevices.com 上 Ed Sutter 最近發表一篇文章 [Introducing Micromonitor -- an open source boot loader/monitor],介紹到 1.0 Release 新的里程碑中,種種新的設計,除了傳統 boot loader 的基本功能,uMon 還有以下特徵:
  • an extensible flash file system (TFS)
  • the ability to create on-board ASCII files
  • file-based scripts with conditional branching similar to BASIC
  • script-driven startup option
  • command line history and editing
  • UDP and RS232 based command entry
  • versatile configuration management using files
  • symbols and shell variables
  • symbolic display of variables, stack trace, runtime profiling and memory-based runtime trace
  • a gdb server for application loads and post-mortem analysis
  • network host supporting ICMP and DHCP/BOOTP as a startup option
  • TFTP client/server for network file transfer, Xmodem for serial file transfer
  • syslog client
  • zlib-based decompression
  • password-protected user levels
  • large API to hook the application to facilities provided by monitor
不過如果要入門,可以先跳到 [MicroMonitor's typical usage model] 這節,對於使用過 [u-Boot] 的朋友應該就很熟悉,而我比較有興趣的是 uMon hook API,總之,MicroMonitor 1.0 真令人驚豔。
由 jserv 發表於 10:16 AM | 迴響 (2)

August 14, 2005

神奇的數字

自從今年迷上閱讀 Blog 後,就很喜歡收集 RSS/Atom feed。我所使用的 RSS Reader 是 [Liferea],雖然 chihchun 這位前繁體中文翻譯者都改用其他軟體了,不過我還是覺得比較習慣這套,而且至少我大概知道要怎麼修改這個軟體。

剛剛回到家,打開電腦發現這個神秘的訊息:


這個... Liferea 告訴我:「202302808 個未讀項目」?!

累積這麼多 entries 未讀,哎呀,可是我卻又一直訂閱新的 :(

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

August 12, 2005

全文索引引擎Lucene簡介

剛剛閱讀車東的大作 [在應用中加入全文檢索功能 ——基於Java的全文索引引擎Lucene簡介],涵蓋以下議題:
  • 基於Java的全文索引引擎Lucene簡介:關於作者和Lucene的歷史
  • 全文檢索的實現:Luene全文索引和數據庫索引的比較
  • 中文切分詞機制簡介:基於詞庫和自動切分詞算法的比較
  • 具體的安裝和使用簡介:系統結構介紹和演示
  • Hacking Lucene:簡化的查詢分析器,刪除的實現,定製的排序,應用接口的擴展
  • 從Lucene我們還可以學到什麼
相當詳細的介紹 [Lucene] 這個 Apache Foundation 下的專案計畫,同時也可以在這個 search engine 看到許多獨特的設計,比方說針對傳統 B-tree 結構的改進,再者,[關於亞洲語言的的切分詞問題(Word Segment)] 這個議題也是非常重要,作者也提到這個部份還是有改進的空間,後面的部份就是作者的 hacking,很值得一看。
由 jserv 發表於 12:46 AM | 迴響 (2)

August 11, 2005

李果正談 Serif 與 Sans Serif 字型

剛剛拜讀李果正前輩的 blog [serif vs sans serif],釐清很多觀念,其中有個重點:


    serif 和 sans serif 的一般比較

    • serif 的字體較易辨識,也因此易讀性較高。反之 sans serif 則較醒目,但在走文閱讀的情況下,sans serif 容易造成字母辨識的困擾,常會有來回重讀及上下行錯亂的情形

    • serif 強調了字母筆畫的開始及結束,因此較易前後連續性的辨識

    • serif 強調一個 word,而非單一的字母,反之 sans serif 則較強調個別字母

    • 在很小字的場合,通常 sans serif 會較 serif 字體較為清晰


再者,中文字型也有類似的分類,果正前輩提醒了我們:

    在中文直排的情況,比較不容易顯現 serif/sans serif 之間的差異性,但是在目前中文橫排相當的普遍的情形下,以上所述及的易讀性、醒目性也是適用於中文。

    很常看到中文出版書籍、雜誌,內文使用了不易閱讀,但卻很醒目的黑體或圓體,這對讀者來說,在長期閱讀之下很容易就引起眼睛不舒服,似乎是應該儘量避免才是。

最後的參考資料提到 [cwtex],剛剛發現網站更新時間是 "2005-08-10",不曉得是否意味著新版要推出了呢?真期待。

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

August 10, 2005

再談「自由創投」

今年五月份,我在 blog 提到 [Free Angel -- 自由創投] 這個想法,就是希望建立一個平台,讓更多有新投入自由軟體開發的朋友,能更快更有效的建立專案,並且永續經營與維護。

不消說,現在的 Free/Open Source Software Projects (以下簡稱 F/OSS) 都採取企業經營的方式,無論是 KDE、GNOME,或者 Linux Kernel 都是這方面的典範,很多書籍提到如同無政府主義者的 Hacker 行為,事實上只是一小部份,絕大多數都是比照企業經營的理念去耕耘。有趣的是,當我們走出辦公室,走出一定的時薪福利時,開會不需要預約會議室,隨時可以在 IRC 暢所欲言,「工作」沒有時差和地域限制,在方向確立後,就著手發展,各種想法即便是非主流的,也可以自立分支,進行發展,或許哪一天成熟後,就可能整合或成為新的 codebase,在 F/OSS 的世界中,相當常見,但是,相對的,人事成本降低了,討論與腦力激盪增加了,而且這些努力都可以延續下去,不會因為政策而消逝,透過 CVS 或 Subversion,隨時可以追溯到歷史的軌跡...

不過,有一個協助 bootstraping (這裡借用作業系統的術語,意思就是強調專案建立時,百廢待舉,即便有了實做,沒有開放的發展環境與 community,還是不算 F/OSS 的) 的「創投」就相當重要了。我必須承認,能夠投入 F/OSS 發展的時間,對我而言,相當有限,頂多就只是睡前一兩個小時的 hacking,或者睡不著起床 coding 片刻,或者週休二日不想出門踏青時,縮在家裡創作等等的短暫時間,但這些都沒關係,現在的環境已經相當便利,很多專案都提供 version control / mailing-list / issue-tracking 的機制,就算時間不是很充裕,多少還是能夠貢獻一點。

今天上班利用一點空檔閱讀 [電子工程專輯] 的 2005-06-16 -> 2005-06-30 這期,在第68頁 [電子工程人物] 介紹到「華裔光纖教父在矽谷經濟起落中開啟創業新視野」,在前言提到:


    矽谷是所有創業者的天堂,矽谷的興衰起落寫滿了創業者一頁頁的血淚教訓,然而也持續地為矽谷注入一股新的生命。素有「矽谷華裔光纖教父」之稱的 Opnext 公司資深副總裁龔行憲,在走過逾三十年的產業經驗後,分享了他個人在矽谷經濟大起大落的創投心路歷程以及從中學到的教訓。

光看這一段,有點吸引我,所以花了時間繼續閱讀下去。1938 年,Hewkett 與 Packard 在 1938 年成立 HP 公司,並將強調自由創新的「HP 精神」帶入矽谷形成其產業文化,後繼文化的延續更是精彩,作為矽谷文化的見證人,龔行憲解釋道:


    「所謂的矽谷創業精神,便是要有承擔風險的意願,接受並了解失敗,並從中學習更多的經驗。因此,創新的想法與技術也常常讓勇於冒險、不怕失敗的矽谷創業者在創業時得到了適時的回饋。」

同樣的,我們回頭看軟體專案,也是如此,並不是有了 "Just For Fun" 的態度就可以讓專案持續發展下去,那只是最基本的素養罷了 (無論作任何事情,都應該要保有幾份樂趣),我們當然知道,不是每個專案都會成為成功的計畫,有可能半途夭折,也可能被其他專案取代,但這些都不是問題,真正的問題是你願不願意去作,證明自我、將想法落實,才是最重要的,也就是矽谷創業的精神:「勇於冒險、不怕失敗」 :-)

有一些朋友寫信告訴我,他想要作 XXX 技術,將 YYY 的概念引入,整合成 ZZZ,這非常好,但一直問我會不會很複雜,也擔心做出來的專案沒有價值,通常我只會回覆:


    Just Do it!

F/OSS 跟其他軟體計畫不同的地方在於,其價值並不是用程式碼的 C/P 值去計算的,相反地,F/OSS 很多時候是出自 concept-proven 的動機,也可能只是為了解決某個問題,最後衍生為一個完整的專案,就算最後被證明不是非常成功的專案,但是作為另一個選擇,何嘗不好?或許箇中優秀的實做,還可以整合到主流軟體的設計中,只要後者也是 F/OSS 的話,Why not?

總之,希望這個「自由創投」的想法可以協助更多的朋友,讓更多的專案得以現身,也讓我們有更多選擇。

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

Tim Berners-Lee 談「可讀寫的網路」

搞技術的人多少會有偶像崇拜的情況,這在我身上特別明顯。早上閱讀 BBC News 的 [ Berners-Lee on the read/write web ] 這個新聞,讓我全身湧起難以言喻的興奮感,遂在此記錄。BBC News 的採訪 [Tim Berners-Lee] 並不是什麼新鮮事,其實整篇也沒有特別的見解,過去 Tim Berners-Lee 已經提過了,只是今天連貫過去種種想法,並且對 blog 發展,提出他對於「可讀寫網路」(Read/Write Web) 的觀點。

過去 W3C 就發展了一套名為 Amaya 的計畫,稍早的 blog [W3C Amaya 新發展] 大略提過其特性,除了這樣在 Web client 下手的途徑,Tim Berners-Lee 也早已提出過 Wiki 的想法,現在應用相當廣泛,而在開啟網路出版的新紀元濫觴的 Blog 現身後,過去這些撲朔迷離的概念終於得以廣泛的實現。

對了,synic 發表在 cyborg 的一篇心得感想 [Synic的《一千零一網》讀後感想] 也很值得一讀,大略描繪出最早 CERN 與後來 W3C 創立的文化背景與理念。
由 jserv 發表於 02:02 PM | 迴響 (0)

August 09, 2005

Arne 的台灣地區通俗語言之輸入法

Arne Götje 雖然來自德國,但對中國文化的熱愛,絕對不輸給任何一個土生土長的台灣人,稍早在 blog [2005 年摩托學園/Debian User 聚會] 提到 Arne 分享 CJKUnifont 的進度,讓在場與會的朋友都一致讚嘆,實在是太偉大了。已經完成幾個里程碑後,Arne 又繼續處理 Unicode 4.0 CJK 表意文字區域的閩南及客家語文符號,並且在 Debian@Taiwan 的 [WishList2005 / 夢幻軟體計畫] 做了一個提案「考慮到台灣地區通俗語言之輸入法」,該提案簡介如下: [Minnan IM (台式閩南話輸入法)] 與 [Hakka IM (台式客家話輸入法)] 現在已經是 FreeDesktop.org 的子計畫,並且獲得 Yang Qing-Chu (陽青矗) 先生的《台華雙語辭典》,這是一個以注音為詞鍵,對應到台客語辭典的大型表格,楊先生打算以 GNU GPL 捐出,這是相當好的消息,但是相關的輸入法與平台整合工作需要投入更多的心力去作。

Arne 勇敢的接下這個工作,AndrewLee 也協助處理授權以及表格的議題,當然也需要更多的朋友協助,簡單的閩南話與客家話我會說一些,或許我可以協助處理軟體架構上的議題。
由 jserv 發表於 11:42 AM | 迴響 (1)

兩個大姑寫的〈Hacking the Linux 2.6 kernel〉

我很欣賞思緒清楚的女性,特別是從事軟硬體系統開發,前女友也是屬於這樣的類型。之前還有參與 [KDE Project] 開發時,通常只會看 [KDE Women] 網站上的文件,因為我覺得文筆構思細膩多了,可以彌補某些 hackers 的「特質」(比方說文件語焉未詳,這在 KDE 裡面很少見,但還是有)。

對岸的朋友喜歡稱呼高手為「大俠」,那我自己稱呼這些女性高手為「大姑」,IBM 的網站上有一篇由兩位「大姑」撰寫的文章 [Hacking the Linux 2.6 kernel, Part 2: Making your first hack],由 Lina Mårtensson 和 Val Henson 共同撰寫,Val Henson 在 Linux Kernel 是赫赫有名的大人物,雖然不是最核心的開發者,但 PowerPC kernel tree 就是由這位大姑維護的,也是少數的女性 kernel hacker。

這篇文章難度不高,首先介紹 kernel tree 的目錄架構,以及大略的 booting 流程,當然是用他們最熟悉的 PowerPC 架構作介紹,並且很細心的介紹 system call 與 kernel 的實現機制,待建立觀念後,作者就引導我們建構一個 LKM (Linux Kernel Module)。第四頁的 [Writing a module that uses interrupts] 這一節可以多留心,善用 irq 的處理,我們可以做出許多經典的操作,接著介紹如何提交 patch,並介紹 Linux kernel hackers (這裡不用 "Developers" 一詞,因為基於對 kernel tree 種種奇妙發展的敬畏) 廣為使用的 [cogitod] 工具,說明如何管理為數眾多的 patch(set),可參考第五頁的 [The alternative to diff and patch: Cogito]。

總之,這是一篇淺顯易懂的好文章。

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

August 08, 2005

新酷音釋出新版 libchewing-0.2.7 與 scim-chewing-0.2.1

上一次的釋出 [新酷音釋出新版 libchewing 與 scim-chewing] 在今年二二八紀念日,而新版本則是紀念八八父親節,詳情可以參閱 mailing-list 上的 [ANN: libchewing 0.2.7 & SCIM-chewing 0.2.1]。

同時,[新酷音] 的網站也更新了,在 [Screenshots] 可以看到越來越多種新酷音的樣貌,真是令人高興。

總之,希望未來有更大的突破!
由 jserv 發表於 10:27 PM | 迴響 (2)

演講:綜觀 X Window System 與新發展

本月份除了要去 [JavaTwo 2005] 分享一個「非主流」的題目外,月底還有另一場的演講,主題是「綜觀 X Window System 與新發展」,詳情已經由 Eric Shei 張貼於討論區,請參閱 [酷!學園台北服務處 八月份主題-「綜觀 X Window System 與新發展」 ]。

以下引述部份內容:

去年我在 Debian@Taiwan 舉辦的 [IRC Conference] 已經介紹過「FreeDesktop.org 與 X.org 嶄新發展概況」,不過這次更全面,並且會介紹最新的技術 (slides 打算當天凌晨開始打,確保是 latest information),歡迎指教,也希望能夠作技術交流,最好也能夠跟 [jserv's lab] 合作,如果有意引入這些技術到嵌入式系統的話 :-)

這只是一個分享,當然有太多技術我沒辦法掌握了,但也歡迎各式相關問題提出,或許能找出 hacking 的盲點與激發更多想法,謝謝!

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

KHTML 的 CSS3 支援度

Free/Open Source Softwares Community 的力量真是驚人,在 KDE.News 稍早介紹過 [ Next Generation KDE Technologies Ported to WebCore] 提到 KDE Developers 與 Apple [WebKit/Webcore 開發團隊] 協同開發出未來的瀏覽器技術,不僅 Apple Safari 獲得大幅度改進,KDE Konqueror 的 [KHTML] 也在標準相容度與可用性項目中,有頗大的成長。

W3C 的 [CSS WG (Cascading Style Sheets Working Group)] 已經完成許多 Draft 與 profiles 的制定,CSS3 不僅是 CSS Level 1 / Level 2 的擴充,更意味著以 XML 為主體的 Extensionale Stylesheet Language。同時,W3C 的野心相當大,我們也看到類似 [CSS TV Profile 1.0] 這樣針對 TV devices 的規格,在 Overview 一節我們可以看到:


    The CSS TV Profile specifies a conformance profile for TV devices, identifying a minimum set of properties, values, selectors, and cascading rules. The resulting CSS TV Profile includes the vast majority of CSS1, portions of CSS2 and CSS3 Module: Color. The CSS TV Profile is a proper superset of the CSS Mobile Profile, with the use of the 'tv' media type instead of the 'handheld' media type.

是此,如何銜接 W3C 的規範就變成當今的重要議題,KDE.News 的新聞報導 [KDE Commit Digest for August 5, 2005] 的評論中 ([Gea-Suan Lin] 長輩再三提醒我們,評論或討論遠比新聞內文重要得多),有幾個項目相當有趣:


    CSS 3 multiple background images
    by Jim on Saturday 06/Aug/2005, @13:24
    From one of the check-ins, it looks like Konqueror now has CSS 3 multiple background images courtesy of Safari. Read more here.
    A pretty cool test page here.

所以就目前來說,W3C 的 CSS3 multiple background images 支援已經在 KHTML 實做出來,正所謂「一圖勝千文」,先看看下圖:

引述 Morty 的介紹:

    Here's screenshot of the window at two different sizes. When you resize it and make it smaller the outer pictures slides under the central one, and they move away when making the window bigger. All wery smoothly, with only a little bit of flicker on fast resizing.

我們也可以看見 W3C WG 提出的 public-review 與 feedback request -- [Help The CSS Working Group With Backgrounds and Borders] 已經在這兩方人馬的協同開發下,獲得驗證,這是個相當好的模式。

KDE rules!

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

熱血之餘談軟體授權

前面幾篇 blog 提到最近許多熱血的計畫,讓人對台灣本土的自由軟體發展還是存有高度的信心,不過,在此同時,軟體的授權方式也需要適度的探討。

基本上,軟體授權是一種契約,稍早在 blog [自由軟體授權分析] 提到我在今年六月份作過一份這樣的簡報,估計這個月底會將 slides 公開,這一個多月以來,我又拜讀許多這方面的討論,其中比較吸引我的項目,大概就是在 [Eclipse.org] 的 Bugzilla [#80980],其標題為 "Eclipse Platform source organization incompatible with spirit of Common Public License"。我們都知道,Eclipse 是 IBM 以 CPL 授權捐出來的重量級開發平台環境,以 Java 作為主要的建構語言,稍早的 blog [Eclipse 引導開發平台的統一],我們也可以發現,這儼然就是新一代的標準。

但問題是,依據 IBM CPL 授權的 Eclipse 在語言層面與運作機制上,是否會與軟體授權方式牴觸呢?這個 Bug#80980 就是探討其潛在的因素。在看整個議題之前,其實爭議之處就在於 "Derived Work" 的定義,當初 GNU C Library (glibc) 就是因為 GNU GPL 在 Runtime linkage 的議題存有一些爭議,才由核心開發人員另行制定 GNU LGPL,明確的規範 dynamic link 的適用性。而 Java 這個 dynamic language 更是有如此的考量,所以 [GNU Classpath] 才會採用 "GNU GPL with exceptions" 的方式授權,這部份可以再閱讀 [The LGPL and Java]。

所以,就我的看法 (當然跟 Kaffe.org 無關),在沒有辦法澄清 Dynamic linkage 與 IBM CPL 的適用性的前提下,事實上我們已經陷入「定義」的鬥爭,是此,我樂見 Bug#80980 的出現,也希望 Eclipse.org 能夠明確的予以規範。

說到這裡,我要澄清一下,去年接受 [iThome] 的專訪 [開放Java原始碼是成就Java,還是毀了Java?] 中,書面的敘述提到:
    參與Java開放源碼專案kaffe計畫的黃敬群認為:「Java不適合採用GPL,還有一個很重要的原因,是Java 本身是動態語言。」GPL 指出,所有的衍生軟體,以及使用該軟體作為根基的新軟體,都必須依循GPL。而Java所有東西都是物件,物件都可以動態產生,因此,GPL 中關於「linking」的限制就變得令人混淆了。因此開放原始碼基於不同的需求,會衍生不同的授權。開放後仍需中立的單位維持Java的相容性。
基本上我覺得書面紀錄還算正確,但問題是,我在之前強調的是「Java『未必』適合 GPL」而非「Java『不』適合 GPL」,正是上述議題的考量。當然啦,不是每個專案都能做到盡善盡美,以我參與的 Kaffe.org 來說,從 1997 年到現在,就是以 GNU GPL 發行,同時也會有上述的質疑,但是問題是,作為歷史最悠久的 Free Java Implementation,Kaffe.org 擁有為數甚多的 developers & contributors,有的甚至已經不在人世,根本不可能每個人都簽署 Copyright Assignment (因為授權移轉),這是一個遺憾。
由 jserv 發表於 02:36 AM | 迴響 (0)

PCMan X 的新發展 (5)

剛剛無聊又來 hacking [PCMan X pure GTK+ 2],把之前的 Popup-notifier 改得美觀些,並且針對所謂的 〉__〈 (哭臉形狀) 造成 GtkLabel 的誤判行為作一個修正。

寫 ChangeLog 的同時,我想到一個月前才 blog 過一篇 [PCMan X 的新發展 (4)],這一個月間,又有不少新變化。舉例來說,FreeType 字型專家 olv (Chia I Wu) 加入開發團隊,貢獻相當多的修正,現在 PCManX 無論是全形、半形字元選擇與顯示,都相當正常且美觀,真是厲害 :-)

再者,另一個新開發者 [copyleft] 的加入,也讓 PCManX 變得更有趣了,他發展了一個名為 Nancy 的 bot (自動回覆水球的機器人程式),現在已經整合到 Subversion repository 中,除了 configuration 還要調整外,現在已經堪用了,咱們看看運作的畫面:(click to enlarge)

這就是兩個 Nancy 互相「打情罵俏」的畫面,相當有意思。

Kanru 最近雖然熱血的開發 OVIME,但之前也貢獻了 PCManX 的 Python script 支援,透過 eliza 模組,也可以做出類似「自動回覆」的功能,但是可以作更多自訂化的操作,這些成果也已經整合到 Subversion repository 中,在 configure script 有選項可以 enable 上述的 Nancy bot 與 Python script 支援。

PCManX 最新的穩定版本是 0.2.6,已經整合 Firefox/Mozilla plugin 支援,並儘可能使用同一份 codebase,不過陸續有熱心的朋友反應一些編譯上與操作上的問題,我想這些是可以解決的,不過我想先把 Model-View-Control 的切割動作完成。

之前花了一點時間實驗 Gtk+ 的 theme support,應用在 Popup notifier,運作的畫面如下:

重點在右下角,這部份我還沒有 commit,不過等驗證完畢後,是可以獨立為 Gtk+ Widget,這樣就提供其他應用程式使用。

總之,開放的發展真是美妙,幾乎每天都有驚喜,偉大的 Free/Open Source Softwares!

由 jserv 發表於 12:09 AM | 迴響 (3)

August 06, 2005

中文簡繁轉換的複雜性

中文繁簡體轉換的議題,原本在我的觀點來說,應該是很多現成的軟體元件可以應用,而在查閱了一些資料後才發現,問題遠比想像中的複雜。稍早的 blog [漢字走向全球化的挑戰] 與 [繁簡轉換的議題] 有提到過去的一些發現,而我也是在認識 jie 之後,才開始正視這個議題的,同時,我也在今年的 Debian@Taiwan 社群計畫的 [WishList2005 / 夢幻軟體計畫] 提交了一個提案 [TSCC],主要就是著眼二岸三地辭語對照與轉換,規範繁簡體中文用語轉換系統的基礎框架,昨天利用晚上的時間實做了一部分。

但是我總是發現困難重重,不僅難以擴充,更不知道該如何整合現有的中文輸出機制,而剛剛查閱 CJK.org 後,發現一篇論文 [The Pitfalls and Complexities of Chinese to Chinese Conversion] ,我將原本的中文版 [轉換成 PDF 文件]。不難發現,即便使用 Unicode 後,簡體與繁體中文可以並行使用,但衍生的問題才要開始。Unicode 的 CJK 表意文字區域規範了多數的 glyph,而不少應用程式,比方說 [OpenVanilla] 與 [SCIM] 著手提供了表格式的轉換,但還是只能針對單一 Unicode 漢字,但就實用的角度來說,至少我們還需要類似 [同文堂] 的詞語導向的轉換設計。

在這篇論文裡頭我們可以看到序言提到:
    In 1996, the CJK Dictionary Institute (CJKI) launched a project to investigate these issues in-depth, and to build a comprehensive SC↔TC database (now at three million SC and TC entries) whose goal is to enable conversion software to achieve near 100% accuracy.
這樣的資料庫已經衝到上萬個詞條,就目前開放的實做來說,「新同文堂」(URL實在太分歧了,以至於我不知道該列出哪個) 還不到兩千條。就算今天我們能夠聚集網路上熱心朋友的貢獻,將對照詞彙表的數量累積到同樣的等級,就效率來說,是否能夠迎接拔山倒海的轉換資料量呢?我很好奇。

為了務實,我打算先將上述的議題擱置,改來寫 [gaim] 的一個 plugin,作為一個 testbed 來驗證 TSCC,初期已經有最簡單的表格式轉換,可以處理 in-coming/out-going messages 的轉換,稍後我會放到公開的 svn repository。
由 jserv 發表於 08:52 PM | 迴響 (2)

August 05, 2005

台灣區 Debian 十二週年慶祝活動

偉大的 [Debian 計畫] 即將十二歲了,台灣區的 Debian 社群將舉辦慶祝活動,詳情可以參閱 wiki page [DebianBirthdayParty2005],這裡摘錄聚會資訊:


    時間:8 月 13 日 (星期六) 13:30 - 17:00
    地點:台大迴廊咖啡
    -* 地址:北市羅斯福路四段1號
    -* 電話:(02)8369-5656
    -* 網址:http://www.alucafe.com/

歡迎有興趣的朋友參與,同時幾位台灣的 Gentoo 與 Ubuntu 社群朋友也會出席,大夥兒出來喝茶聊天吧!對了,要記得拿紀念 T-shirt :-)

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

新酷音進度報告4

最近收到不少朋友的關心,究竟 [新酷音計畫] 的近況到底如何呢?上一篇 [新酷音進度報告3] 之後,就沒什麼新消息,這倒也是真的,我最近碰的東西比較低階點,昨天 svn commit 時才發現有四個月沒有動作了 :(

不過,繼 [新酷音發佈新版 RC] 後,預定在下週一 (Aug 8) 發佈新的釋出版本: libchewing 0.2.7 與 scim-chewing 0.2.1,到時候也要請一些朋友幫忙,趕在 [Mandriva] 新版本 freeze 前,用力的 push 進去。

現在 libchewing 建立 [Win32 branch],由熱血的 kanru 領導開發,他已經成功的與 [OpenVanilla] 團隊 co-work,之前的 blog [Kanru Chen 的 OVIME 發展進度] 有提到他的進展,而新酷音也成功整合了,正如 kanru 的 blog [IME 進度(5)] 提到的項目,咱們來欣賞一下:


同時,OpenVanilla/Win32 也可以切換輸入法,所以現在的完成度已經越來越好了。

關於 SCIM/Chewing,就如 blog [SCIM 與新酷音的發展近況] 所提到的,配合 SCIM 1.4.0 運作得很順暢,而且還支援繁簡體轉換,這對常常掛 #debian-zh 的我來說,很好用 :)

最後,還是一句話:「希望有更多朋友投入新酷音發展」,無論是 language model、使用者介面,或者功能性改進,都是很值得做的。而我也希望能夠如之前 blog 提到的 [Free Angel -- 自由創投],我們可以透過網際網路,以協同開發的模式,將許多好的想法,予以施行,並累積成果,建立一個又一個成功的 Free & Open Source 專案。同時,我們也看到 Linux 或 *BSD Desktop 環境的支援度已經越來越好了,這裡要向默默付出的前輩們致敬!

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

August 04, 2005

Qt/KDE 程式設計網路資源

剛剛在摩托學園看到 DragonFly 發表的 [QT/KDE 程式設計網路資源] 一文,介紹到 [The Code Skipper] 這個網站,裡面有不少 KDE/Qt 的技術文章,像是 Aaron J. Seigo (全職 KDE 開發者) 撰寫的技巧心得提示,不過比較可惜的是,沒有 Qt/Embedded 與 Qtopia 方面的文章,所以要去 [TheQtopian] 找找。
由 jserv 發表於 11:36 AM | 迴響 (0)

August 03, 2005

Xorg 6.9 and 7.0 Release Candidate Zero

X.org 發佈令人振奮的消息了,請參閱 [ANNOUNCE - Xorg 6.9 and 7.0 Release Candidate Zero],引述 ajax 的聲明:
    We're pleased to announce the availability of the zeroth release candidate(s) of the next Xorg release(s). Both the monolithic 6.9 tree and the modular 7.0 tree have been tagged.
而我稍早在 blog [Xorg 邁入 7.0 新紀元] 提過,現在主要的計畫都依據行程規劃,屏息以待的就是處理若干 pending bugs 了,衝!
由 jserv 發表於 03:36 AM | 迴響 (1)

August 02, 2005

快速更換 Win32 的元件變成 XP Style

雖然我是個 Linux 愛用者,不過平常上班的時候還是用 MS-Windows XP,因為某些專業的軟體一定要在上面跑,可能也是因為這些緣故,我對 XP 的視覺呈現不是特別在意,只知道每次 simulation 的速度實在慢到不可思議,只好在一旁的 Linux box 上面作 coding,沒想到都寫出好幾個 test cases 了,回頭看 XP 的畫面,還是僵在那邊 (!)。

我一直有個疑惑,有些應用程式,比方說 [TightVNC],在 Windows XP 下的視覺呈現總是有點不一致,而剛剛閱讀 [Gary's Note] 的這篇 [讓你的AP上的元件變成XP的Style] 後,才發現這個有趣的技巧,趕緊套用。

咱們先看看原本的 TightVNC Viewer:

而經過這樣的處理後 (就是放一個 vncviewer.exe.manifest 檔,很簡單) 的畫面:

後者的 window control 已經變成 XP Style,真有趣 :-)
由 jserv 發表於 04:44 PM | 迴響 (1)

Linux - 原力與你同在

剛剛閱讀 WindRiver 的一份簡報 [Debugging the Linux Kernel with KGDB: Tips and Tactics](PDF 格式,作者:Jason Wessel),除了介紹 KGDB 與 WindRiver 的 Workbench 整合開發環境的支援度之外,slides 第75頁真是有意思,我摘錄畫面如下:

讓我們再度朗誦這句:


    Repeat the former steps

    And may the source be with you always

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

PrincedProject : 創造免費又自由的波斯王子遊戲

[PrincedProject] 這個計畫的宗旨就是建立一系列的軟體,讓經典的波斯王子遊戲能有新的 Free Software 實做,不僅遊戲引擎本身,連同關卡的編輯器都是。這個計畫已經發展一段時間了,成熟度也夠,以下是在 GPE 上的運作畫面:


是不是有喚起小時候的記憶呢? :-)

由 jserv 發表於 07:25 AM | 迴響 (1)

August 01, 2005

e17 與 UI

UI (User Interface) 一直是大學問,剛剛閱讀 [技客魂] 時,被其視覺呈現所感動,整體版面布局相當專業,爾後瞥見 [體驗下一代的桌面環境 e17],Reach 分享了 [Enlightenment] 第17版 (發展中,所有程式碼都在 cvs repository 中,module 名稱為 e17,故稱) 的使用經驗。有一段時間,我曾經是 Enlightenment 的愛用者 (高中時代玩 Debian 的記憶),不過現在的我只碰 Enlightenment for Embedded (參考 [展示影片]),這回見到 e17 真是有高度驚艷的感受 :-)

而在另外一篇 [企鵝腳下的尼祿大帝] 中,Reach 在結語這麼寫道:
    界面是軟體的生命,你能想像呂副總統代言植物の優然後大喊不要再對我打分數的廣告畫面嗎?
真是恰到好處的比喻阿。
由 jserv 發表於 03:02 PM | 迴響 (3)