Jserv's blog: March 2006 彙整

健素糖與物件導向設計

又是奇怪的標題。

下午散步返家後，閱讀了 Etude 的文章，覺得很有意思，引用如下：

http://db.apache.org/derby/

Derby 實作是很好的 design pattern 練習。

這讓我想起小時候吃的健素糖，外觀很類似M＆M巧克力，Object-Oriented 就像糖衣，可以適度包裝軟體，所以，對我這個不明究理的人來說，含入口中的健素糖與M＆M巧克力都給我一種幸福的甜蜜滋味，不過呢，過一段時間後，富含酵素的健素糖就產生很特別的味道。蔡學鏞在 [Obsessive-Object-Orientation Obliquity] 一文提到的 OOO 就是濫用物件導向的一種「病症」，健素糖本來就是一系列酵素的萃取物，而糖果似乎都該是甜的，為了 OO 而 OO、為了糖果而加糖，的確是有問題的行徑，雖然適度操作可帶來正面的成效。

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

〈PORTING UNIX TO THE 386〉十五週年

作業系統「考古迷」的 ghost 兄分享了 [PORTING UNIX TO THE 386: A PRACTICAL APPROACH] 的資訊，引述網頁介紹：

Would it be popular?
Would it be stable?
Would it develop into something?

[William Jolitz] 與 [Lynne Jolitz] 是 [386BSD] 的作者，十五年前將 4BSD 移植到 i386 (16MHz 386 PC) 的相關文件可參考 [Porting_UNIX_to_the_386_Series()]。此外，Rachel Chalmers 撰寫的文章 [The unknown hackers] ，這裡的 "unknown" 意有所指地就是對比 Linux kernel 的高知名度，而我們當然不能忘記這個事實：

Linus Torvalds himself name-checked their O.S. "If 386BSD had been available when I started on Linux," he said, "Linux would probably never have happened." (19)八零年代末期，銜接九零年代時，發生一系列重大變化，大型系統的式微與個人電腦的蓬勃發展，都可在字裡行間感受到，對了，結語很有意思：

If the glory of being Torvalds evaded them, the Jolitzes certainly helped prepare the way. 除了參考之前 blog [UNIX 家族簡介] 外，Michael G. Brown 撰寫的短文 [The Role of BSD in the Development of Unix ] 也很值得參考 (最好也對照圖表)。

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

B#：作為嵌入式系統的輕量級程式語言

閱讀 [DeepObjectKnowledge, Inc.] 首席科學家 Michel de Champlain 與加拿大 Trent University 助理教授 Brian G. Patrick 刊載於 Embedded.com 的文章 [B# - A programming language for small footprint embedded systems applications: Part 1] 得知他們最近針對嵌入式系統應用，而設計出新的物件導向、應用導向程式語言 -- B#。

專長於物件導向分析訓練的 [DeepObjectKnowledge, Inc.] 已經提供許多 C# 相關的顧問服務，而許多嵌入式系統，比方說 Feature phone、MCP，或者是中低階應用來說，會期望能延伸熟悉的 C 語言，並以物件導向設計來規劃系統架構，但是 C++ 這種 meta-language 的負擔實在太沈重了，更別說難以掌握的 C++ ABI。C# 是個很成功的語言，取鏡於 Java 成功的經驗，雖然個別技術並非劃時代的創新，但是提供整體性的解決方案，而且以「簡單」與「物件」作為核心思考方式，B# 並非 C# 的簡化，其語言規範還考慮到絕大多數 ISO/IEC standard 的硬體架構的應用，提供了 Device Registers 與 Interrupt Handlers 等語法上的支援，這些如果要在 C 語言層面實現的話，就得像 Linux kernel 一般依賴 GNU Extensions，並佐以一系列的 macro 與 programming manner。

所以，B# 的提出就是希望一勞永逸地 (至少有限度的) 解決這種問題，設計 Device driver 不免會有 HAL (Hardware Abstract Layer)，無論哪個作業系統，基本上都會採用 Object-based 的思維 (記得二十年前，用 COBOL 設計的某作業系統也是引入 object 的概念來處理 transaction 與 storage)。以 C 語言實做的系統來說，比方說 Linux 或 WinCE，都會有一堆相似的 header，規範 primitive type 與對應到 hardware platform 的 primitives，雖然 C99 針對這個議題，引入了新的 header 來包裝，不過顯然還是不足以簡化 device driver 設計的難度與加強系統的可維護性，這篇文章舉了一個再清楚不過的例子：

所以這裡的 ioreg 即可「所見即所得」地對應到 hardware register，並且可加諸特定屬性作操控，在後續的文章還會提到更詳細的內容。[DeepObjectKnowledge, Inc.] 官方網頁也提及 B# 相關訓練資訊，可作參考。

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

Kernel Driver 2.4 -> 2.6.x

Linux kernel 就跟少女一般，迷人又善變，所以 device driver 常常需要修改，很多時候只是為了配合 kernel API。[API changes in the 2.6 kernel series] 是篇很不錯的文章，整理了 2.6.x 最近幾個 minor release 的 API changes，可以放到 bookmark，供日後參考，另外，老文章 [Porting device drivers to the 2.6 kernel] 也很有參考價值。

由 jserv 發表於 01:33 AM | 迴響 (1)

加強版 radeontool

感謝 Benjamin Herrenschmidt 前輩指點，改良版的 [radeontool] 已經弄好了，可從 [這裡取得 tarball、patch，以及 Debian package]。現在新增兩個選項，程式使用方式如下：

radeontool 
usage: radeontool [options] [command]
         --debug            - show a little debug info
         --skip=1           - use the second radeon card
         dac [on|off]       - power down the external
                                    video outputs (on)
         light [on|off]     - power down the backlight (off)
         stretch [on|off|vert|horiz|auto|manual]
                                 - stretching for resolution mismatch 
         regs                 - show a listing of some 
                                   random registers
         regmatch  - show registers
                                   matching wildcard 
                                   pattern
         regset   - set registers 
                                   matching 
                                   wildcard pattern

比方說，我們現在想看看 LVDS controller 相關的 register，就這樣操作：

radeontool regmatch "LVDS*"
LVDS_GEN_CNTL (02d0)	0x00000000
LVDS_PLL_CNTL (02d4)	0x00000000

相關的名詞解釋有很多版本，不過就我的認知來說，先從 CRTC (CRT Controllers) 來看會比較簡單。CRTC 規範了尺寸、offset、video mode 的基本 timing，而跟 Framebuffer (我是說硬體與 driver 層面的) 相較，使用者所見的螢幕，就是透過 CRTC 所指向的 Video RAM。回到剛剛舉的 LVDS，指的就是透過 CRTC 提供 LVDS 數位訊號輸出，通常就是控制 laptop flat panel。

radeontool 對有心 trace ATI Radeon driver (xf86-video-ati CVS repository 的 ati-1-0-branch) ，是很便利的工具，歡迎討論，謝謝指教。

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

體驗物件導向程式設計

剛剛瞥見 [OOP Concept explained: Polymorphism] 一文，用「限制級」的術語 (我警告過了) 解釋物件導向程式設計的精髓 Polymorphism，可以試著「體驗」看看，可惜我覺得最後的例子有點粗糙，「那個動作」應該可以更多元些，不過用「這個」當例子，總比典型的 Dog 或 Cat 作「叫」的動作生動些。

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

蒼涼的霧，惆悵的霧

starryalley 的 blog [醒來在清晨大霧中]，他在瀰漫大霧的台南，拍攝成功大學資訊工程系系館的畫面：

透過 starryalley 精湛的攝影作品，一場大霧尾隨於淺白的浮光之後，悄悄地瀰漫了整個資訊系館，與其說是霧，我寧可認為那是薄紗，強勁而刺骨的晨風，拂拭著大地上的重重帷幕，好似飄逸的精靈來回穿梭，薄紗掩蔽這自然的奧秘。獨自佇立於這蕭颯之景前，我不是詩人，無法寫出動人的詩句，但陶淵明的《己酉歲九月九日》所描繪的悲涼感受，卻穿越時空，恆亙於我心：

　　靡靡秋已夕，淒淒風露交。
　　蔓草不復榮，園木空自凋。

雖然時節不同，但文字所渲染的那股蒼涼的氣氛，暮秋無處不悲涼，這也讓風露襲身時，格外寒涼，「淒淒」狀之更顯大自然之嚴酷，此情此景，怎不叫人感染深沈的痛楚呢？於是脫口而出即是李清照《聲聲慢》的詞句：

「冷冷清清，淒淒慘慘慼慼」委婉淒戚、孤獨，以及無比愁悶持續盤據心扉，而在《武陵春》的「物是人非事事休，欲語淚先流」，更是讓我在感嘆季節變化之際，在霧氣構成的薄紗遮蔽下，資訊系館對我而言是如此的遙遠：霧是飄渺的，讓過客迷失方向；霧是惆悵的，讓行人紛紛蹙眉；霧是帶有回憶的，讓人身陷緬懷如夢似幻的深淵。幾年前在霧中的揮手別離，熟悉的場所只得在夢中相見，霜露在臉龐劃下短暫的證明，拖著沉重的身體，我得趕在始曉前離開這塊無歸屬的土地...

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

人的一生可能燃燒也可能腐朽，我不能腐朽，我願意燃燒起來！

標題這席話，語出俄國知名劇作家 Nikolai Alexeevich Ostrovsky (1904-1936)，其《鋼鐵是怎樣煉成的》一書在 1934 年出版發行，為無產階級革命的鉅作，尤其是書中主人翁在家鄉烈士墓前的一段獨白更是絕響：

「人最寶貴的東西是生命。這生命，人只能得到一次。人的一生應當這樣度過：當他回憶往事的時候，他不至於因為虛度年華而悔恨，也不至於因為過去的碌碌無為而羞愧；在臨死的時候，他能夠說：我的整個生命和全部精力，都已經獻給了世界上最壯麗的事業 —— 為人類的解放而鬥爭。」我無意為意識形態的共產革命宣傳 (試問：人類的歷史中，存在過真正的共產主義國家或政黨嗎？)，我本人也並非任何國家的共產黨員，但拜讀 Ostrovsky 充滿熱情的文字，總可讓我激發滿腔熱血。誠然，我正在腐敗，無論內在抑或外在，可恥至極，此刻，我只能持續地燃燒自己，唯有如此，才得以作為我的罪贖，燃燒吧！

由 jserv 發表於 08:34 PM | 迴響 (4)

Xrender benchmark

Zack Rusin 撰寫一個可提供 Xrender extension 顯示效能分析的 benchmakr 程式，發展中的版本可透過 git 取得：

git clone \
  http://people.freedesktop.org/~zack/code/xrenderbenchmark.git

經過繁複的測試後，會得到類似以下的輸出：

主要就是看 Xrender 基本的 operation 對於 Plain、Plain with Alpha、Transformation，以及 Transformation/Bilinear filter 的正交性測試。測試中的畫面如下：

FAQ 提到：

Q: What's going on there?
Q: What's missing?

Xrender 的效能對許多 toolkit 與 font rendering 來說，是最重要的指標，而 Zack Rusin 目前也在從事相關的基礎研究。

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

ZTerm : 以 Java 撰寫的 VT100 Telnet/SSH 終端機

[ZTerm] 一開始是個專為 BBS 設計的連線軟體，以 Java 撰寫，模擬 VT100 終端機，支援 Telnet 與 SSH2，提供分頁 (Tab) 功能，其他 BBS 軟體常見的彩色複製、貼上也有提供，而為了邪惡的 Big5 日文假字，也在內部實做了轉換表格，依據其 source code 的 [LICENSE] 顯示，應該是以 GNU GPLv2 發行，不過網頁沒有很清楚的寫出來。

剛剛用 Kaffe 搭配 GNU Classpath 0.9x (cvs)，執行畫面如下：

這是 GNU Look-n-Feel，比較麻煩的是，該軟體對於字型處理，做了些針對 Sun JDK 的 workaround，而且描繪的部份也不是很有效率，所以必須作點 tuning，不過我現在還只追到 VT100.java 的部份，需要花時間處理 (在 GNU Classpath 的實做與 ZTerm 的 font renderer)。

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

初等概念

* 以下內容純屬個人經驗，不與任何公司有直接關聯 *

標題的「初等」取自數學的「初等代數」，也就是說 C/C++ 中處於「奠基」的「基本」，至於這些項目是否「基本」，實在見仁見智。在我看來，C Programming Language 本來就是用來寫作業系統，所以相關的基礎知識也要有一定的理解，至少也需要對硬體有認知，這樣才有機會徹底理解 C 語言，而 C++ 就更不說了，不僅 ISO C++ spec 複雜難懂，又得遷就於 C++ compiler 許多不合標準但陳窠已久的特性，又得將其 OOPL 的理念貫徹於專案開發，這使得沒有對特定 domain knowledge 有足夠掌握者，難以透過 C++ 將其發揮得淋漓盡致。孫文先生說過「知難行易」，我想每個 Programmer 在這些艱辛的歷程中，還是得抱持無比的樂觀，才能逐步累積成果。

因為專案需求，我需要對語言層面與 compiler implementation 有一定程度的掌握，過程中吃了很多苦，記得之前只是對 C++ 應用程式的某些奇特的 machine code 感到好奇，結果一路從 GCC frontend 追到 RTL backend optimizations，釐清 instruction scheduling 的細節，最後才發現 GCC 多少做了一些 tradeoff，這些「苦工」又非作不可，畢竟「只有痛苦能把深度帶給我們」。

從我「出道」以來，給了應試者 N 次面試，老實說，每次壓力都很大，我一直到了今年才好了些 (終於有部份應徵國防訓儲者年紀略小)。之前我都是面試學歷比我高一大截、年紀比我大的應試者 (將心比心：倘若我是三十歲的中年男子，千里迢迢來到某企業應試，可是發現竟然是一個貌似高中生的小夥子很嚴苛的出題，還不時被質詢：「到底有沒有學過或深入接觸過 XXX ！？」時，該做何感想)，而台灣的 IT 環境儘管口口聲聲說重視教育訓練，但是實際的成效還是很有限，更別說 training 到底對導入專案開發有無可具體的突破，也因此，只好排除些「有潛力但缺乏概念」的求職者。

說來說去，我還只是一個工讀生罷了，社會經驗也不足，只是有時候被抓去「協助過濾未來的同事」，但就我個人的觀點，只要 Resume 有提到，我就得去「驗證」，而最常遇到的情況就是應徵 Device driver 或韌體工程師，並在 Resume 提到已有 C/C++ 基礎，然而內部實在沒有足夠的資源可作充分的訓練與技術培養，所以只好考些基本概念，像是 const T*、T *const，及 T const* 的差異、volatile object、C 的 register 對最佳化產生的衝擊、_init 的實做、某段 code snip 在 c89 與 c99 中的行為差異、GCC 的 GNU extensions、... 等等。或許我們會懷疑：又不是要去實做 C/C++ compiler，有必要對語言層面作如此的認知嗎？的確，倘若今天只是要作演算法的驗證，其實很多細節根本不必釐清，就如同在大學院校中 programming 課程的經驗一般，但就 device driver 這個項目，程式語言是跟硬體打交道的途徑，任何未知或者混沌不明的情況 (如在 c99 釐清，但在 c89 還是沒有界定的議題)，都可能在整個系統醞釀出致命的危機。

有許多領域我沒資格置喙，但就效能提昇與軟體最佳化的觀點來說，不僅要如 Delphi 神殿前的神諭所言："Know Thyself."，徹底瞭解自己的技術水準、團隊合作、理性，及 Programmer 應有堅忍不拔的精神，評估可投入的整體資源並作設定預期目標外，前述的「基本概念」更是另一項關鍵。最近除了忙專案進度外，也安排了一些面試，跟形形色色的應試者訪談是很特別的經驗，要完全客觀、公正，是很困難的，所以我只好著重在技術的項目，根據不同的背景與項目，還得提出不同的問題與設想可能的情境。

為什麼要把一個面試搞得如此複雜？我說不上來，我完全沒有任何刁難的意思，但倘若一次面談的結果，可有助於知悉自我的技術，無論是他人的肯定或者他人針對不足的提醒，我想都是很正面的。我記得曾去某公司應試，或許是因為我當時既無文憑又無經驗，主考官給了一系列高挑戰性的題目，甚至要我當場寫 MD5 的實做，其餘的技術問題我已經忘記了，但如今想想，當時如果沒有受到這些刺激，說不定那些盲點將讓我面對未來的挑戰時，無法有足夠的基礎來克服。很幸運地，後來對方公司給我工作機會，為此我還與當時的主考官聊了許多，或多或少影響了我日後作類似工作時的心態。

我陸續將心得記錄下來，不過實在太零星，還不足以發表。Embedded.com 有許多優秀的文章，其中不少針對前述的「基本概念」做了不錯的闡述，比方說以下幾篇：

這些都是從具體的案例，並且基於嵌入式系統所需特定目的，先是發現問題，繼而改善並作進一步的探究，相當精彩，希望未來有機會，也可採取此引導的方式，無論是跟應試者，還是作內部訓練時。

話說回來，自己又是幾斤兩？蘇格拉底說的好：「我唯一所知的，是我一無所知」，只有不斷進修與思考，才能讓我們看清更多事實，而我一直到現在，才發現儘管已經有幾年 programming 經驗，也在 IT 產業從事過相關設計，但這幾年的經驗用一句話來說就是「只有三個月的程式設計經驗，只不過重複了 N 次」，汗顏、汗顏！

由 jserv 發表於 02:51 AM | 迴響 (2)

interactive QProcess 處理

前天去面試新人時，出了一個跟 Qt 的 QProcess 與 POSIX dup(2) 相關的考題，雖然很期待應試者可明確說出 interactive file I/O in Qt 的處理機制，甚至可指出 dup(2) 的 Linux-specific 特性，不過這個簡單的問題應該就可看出大致的思維與經驗了。很巧，剛剛恰好瞥見 [Starting interactive processes with QProcess]，正是面試考題的解答，而且做了包裝，或許這已是 common sense to Qt Programmer，不過還是很有參考價值。

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

嵌入式 BSD 廠商看待 GNU GPL

GNU GPLv3 的制定程序引來許多討論，而我這幾個月也因緣際會，與一些法律背景的人士做了交流，不過還是不免有「閉門造車」的遺憾。[Wasabi] 是一家專門提供 NetBSD 為基礎的嵌入式系統服務廠商，日前在 [Sarbanes-Oxley Act (SOX)] 提出 GPL violation risk 的法務疑慮，隨後 FSF 的法律發言人 Eben Moglen 也做出回應，相關的報導可參考：

無論是 whitepaper 或是後續的回應，都有些值得思考的觀點，先記錄下來備忘。

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

探討 Web Design 可用性

LinuxDevices.com 刊載了一篇報導 [Online video tackles design for usability]，介紹 Ziff Davis Media 執行編輯 (well，我實在不清楚這個職稱該怎麼翻譯) Mike Elgan 與 Microsoft 的 Web design 大師 -- Jakob Nielsen 博士的對話，相當引人入勝。新聞稿的簡介為：

錄影檔可 [在此取得] (WMV9 格式)，我在台大做了 [一份 mirror] (格式同上)，使用 Linux 的朋友可參考之前的 blog [讓 MPlayer 支援原生WMV9] 來作播放。

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

Konqueror 4 新體驗

ibc 將一系列 KDE 4 中關鍵應用程式 Konqueror 的特徵提案整理為 [Konqueror for a New Experience - Explain]，網頁中還有個以 JavaScript 打造的展示，可給予相當真實的感受，同時，文字說明的部份，闡述了重要的設計理念，這些也會貫徹於 KDE 4 種種設計中。

KDE rules！

由 jserv 發表於 01:43 AM | 迴響 (1)

思往事，惜流芳

晚上閱讀 [前事不忘，後世之師] 一文，引用「藍點：一家本土Linux企業的跌宕浮沉」的報導，心情也不自覺得沈重了，也讓我聯想歐陽修的詞〈訴衷情〉：

清晨簾幕卷輕霜，呵手試梅粧。
都緣自有離恨，故畫作遠山長。
思往事，惜流芳，易成傷。
擬歌先斂，欲笑還顰，最斷人腸！

回首這幾年，自己短暫的人生，不也跌宕浮沉嗎？在台灣可與藍點比擬的案例，大概就是網虎 (Conventive Inc.)，細節我不想提，只是時間點與發展方向有很大的重疊，Embedded Linux 是相當含糊、不具體的說法，Linux 本來就沒有涵蓋完整的作業系統，不管是做什麼產品，儘管 Linux kernel 本身的品質逐漸改善，但所面臨到的議題還是接近：作消費性電子產品，就是要有美觀大方且有效率的圖形系統、就是要注意能源管理、就是要提供足夠的功能，以及整體成本的優勢，所以無論用什麼途徑克服，都涉及相當程度的技術議題。然而，非技術的項目或許更是挑戰，就我所見，這兩家公司都歷經這些蛻變的過程。

1998 年 Netscape 成立 Mozilla.org 並釋出 Mozilla 原始程式碼，這讓我對 Linux 商業化產生興趣，而 Eric Raymon 將這個「文藝復興」(source code 的再解放) 的運動「正名」為 "Open Source"，也搭上網路泡沫化的熱潮，在產業激發出許多瘋狂且具震撼力的概念... 就這樣，我一路觀察了七年，如今「思往事，惜流芳」之際，不免「易成傷」，扎實地做事很重要，而我也相信，過去產業的「Linux 概念股」也投入很大的資源，以極大的努力去克服技術性與市場定位的難題，然，今日又是如何？

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

《十日談》與法律

雖然說從小就被迫接觸許多法律知識，但真正花時間涉獵，反倒是因為在花蓮空軍服役時，涉嫌觸及陸海空軍刑法所規範的犯罪行為 (細節就不提，人總是會犯錯)，自己的前程可能毀於一旦，茫然的我不知如何是好，只得故作鎮定地借了《陸海空軍刑法》閱讀，試圖釐清連帶的責任。後來很幸運地「脫逃」，也順利平安退伍 (當然多少仍因此事受到處分，不過我很高興，自己能在短短的一年多軍旅生涯，經歷這麼多變化)，但接下來的生活似乎與法律有很大程度的關聯性，最常碰到的就是軟體的授權與法律責任，特別是自由軟體與 "copyleft" 相關的。傍晚在 IRC 上才跟朋友討論到這個議題，又拜讀 [擺盪在兩個端點的Florence以及OSS] 一文有感，稍作紀錄。

之前因公事跟任職於中研院的 [Florence] 作了討論，我在往返的信件提到：

看到 "Florence"，讓我想到薄伽丘的《十日談》，我對於法律的認知，就好比《十日談》中描述人性軟弱、無助與焦慮一般，這議題在資訊產業缺乏充分的教育與工具使用、隨處可及的智慧財產權「陷阱」... 當時沒寫完，因為稍後就被抓去開會，今晚利用空檔補上。終其一生，文藝復興時期的薄伽丘著作豐富，長、中、短篇小說與詩集都遠近馳名，而對後世影響最大的，要算《十日談》，該小說集創作於 1348 到 1358 年間，背景是 1348 年的佛羅倫斯。當時歐洲流行黑死病，傳染迅速，以至於死屍遍地，居民莫不爭相遷移外地，而其中避居於佛羅倫斯郊外別墅的三個男人與七名女子就成為小說家筆下的主人翁：他們為了排遣遺世獨立的孤寂，相約每人每日都要分享一則故事，歷經十日，共有一百則故事，這也是小說名稱的由來。這種第三人稱的敘事方式，重新闡述了當時義大利生活的型態，也多少摻雜了薄伽丘自身的人文主義，書評不需要我多說，想必多數的朋友應該都對此名著相當熟悉。書中種種露骨的文字，卻相當真實地刻劃封建貴族的荒唐墮落與殘忍無道、市井小民又是何等軟弱、無助，與焦慮，而幾百年後的我，面對軟體與加諸其上的法律條文規範，又豈能不焦慮呢？[Florence] 回信道：

其實對於法律人來說，「法律」也是一個充滿陷阱的危險叢林... 軍旅生涯中，強迫自己研讀《陸海空軍刑法》，對現在有很大的幫助，我不時會參考 [中央法規]，也才讓我深深體驗，原來我們周遭有這麼多法規，任何小舉動都可能觸及法律責任。就算只當個長時間安身於辦公室的小小工程師，除了收信、看新聞、開會，就只剩下 coding 了，這麼單純的工作背後，看起來沒什麼風險 (過勞死除外)，但真正的危機往往難以衡量。首先，是專利議題，一個關鍵專利足以讓 SiS 這樣具規模的電子產業，延遲出貨，造成巨大的財務損失，其訴訟官司更在台灣電子產業成為經典案例，製程、模具、半導體設計，與機構設計如此，充滿種種不確定性的軟體建設更是令人迷惘。以 Speech coding 來說，無論是國外或國內，都有一系列描述「基本方法」的專利限制，比演算法更含糊、影響更廣泛，或許哪天想到一個很棒的方法，用力去實做，花了好幾天 coding，還對於自己的方法沾沾自喜，等要出貨時，才發現早已有一系列的專利卡在那邊，到時候，是誰的問題呢？或許，我們會說：「我才沒有那個聰明才智，不會發明新東西，只拿現成的軟體來改，總行了吧？」而這，才是另一個大問題的開端。

以前唸書時，不同學科總有經典著作，比方說 Operating System 就有「恐龍書」，而 OpenGL 就有「紅皮書」，裡面的程式碼範例也被視為 public domain，亦即，只要是讀者，無論用什麼方式去「融會貫通」，那些 sample code 應用到讀者的專案，就是讀者的創作，以讀者的角度來說：「我買這些經典書籍，就是要學習到技術，這些 source code 對我有很大的助益，而我也依據這些基礎完成了軟體專案」，的確合情合理。不過，Richard Stallman 建立了 "copyleft" 的概念，並非對 "copyright" 或著作權作顛覆行動，而是提供一個邏輯上的規範，也就是基於軟體分享、軟體自由通行、軟體自由修改，以及讓軟體得以被賦予新的價值等概念，也透過這個概念，起草 GNU GPL 的軟體「契約」。全面性來說，這是一個很好的模式，然而，這種「附帶回饋責任」性的條款，也跟許多自(19)八零年代就蓬勃發展的軟硬體產業造成衝擊。以嵌入式系統來說，以前的工程師無論是什麼背景，可能開工沒多久，就得要自己寫 Monitor / Kernel / RTOS，硬體也是自己設計的，甚至還得負責整體的機構配線等，因為就是有那個需要。然而，處於分工與強調標準化的今日，這種現象已難以復見 (不過我有一位日本的朋友還在作這樣的工作，持續二十餘年)，人人琅琅上口的就是 "solution"，這個 "solution" 一詞很妙，跟 "answer" 不同，"solution" 似乎就是漫漫長夜的明燈，指引我們到出路，也因此，很多工程人員不問 "question"，也不想搞清楚 "question" 具體內容，就只關心 "solution"，"schedule" 芒刺在背，不得不用力推進。

隨著軟體的成長，以及 free / open source software 透過網際網路的累積與交互發展作用，各種經典的軟體都出現了，不僅有 bootloader、kernel、 C Library、Device driver、GUI system、Network stack、... 等傳統認知的軟體範疇，現在連 SPARC 工作站的 CPU core 也釋出其硬體 VHDL 原始設計，這裡不打算作深入介紹，反正在 Google 上隨便找都是一堆，bookmark 永遠整理不完。這些的確是很吸引人的 "solution"，不僅容易取得 (不需簽署 NDA 或繁複的法律程序)，更是 royalty-free，簡單來說，就是「免錢」，然而，真是如此？現在 IT 產業的法律規範越來越多，記得我以前在光寶科技 (LiteOn) 服務時，第一天就得捧著厚厚一本的員工契約，一條又一條地檢視並同意，那份厚重的文件對員工所需肩負的責任，給了詳細的說明，這之中，資訊保密就是相當重要的。可以想見其他 IT 產業也差不多，如果專案中引用了 "copyleft" 發行的軟體元件，會有什麼影響呢？各種 software license 應該都有提到其適用對象，並且使用上的限制，與擔保的範疇，再來會提到像是專利互惠條款一類的附加規範。以我們熟悉的 GNU GPLv2 來說，想像成「病毒」就很容易理解：「歡迎使用，但重新散佈或修改也請分享 source code」，然而，GNU GPLv2 只是一種契約，試想一個情境：一個小小工程師，為了要解決技術上的問題，在 Google 上找到某某計畫已經有了很大的突破，於是加入原本的軟體設計中，這也讓開發時程得以獲得控制，但是，原本的軟體設計也因此被「感染」，成為不折不扣的 GPL'd software，工程師總是單純的，於是依據這個「GNU GPL 契約」，也將修改的部份分享出來，這是美事一樁，不過，進公司第一天就簽署的「員工保密契約」又該怎麼辦？後者的效力當然遠大於 GNU GPL，而且不謹慎處理的話，還可能因此丟掉飯碗，離職原因才不是「捍衛 GNU GPL」這種神聖的迫害性闡述，而是「涉嫌洩漏業務機密」一類的惡名。

之前發表 [再談自由軟體授權] 與 [簡報：自由軟體授權分析] 等系列的 blog entry，其實我本人是沒什麼高度意願想在這個議題著墨，但總會收到信件、電話，或者是法務人員親自來訪，所以只好稍作整理，交流指教是很歡迎，不過我心中的疑惑是：

這種問題，該問法律專家，怎麼跑來問我這個差點被軍法審判的人？ (按：儘管如此，我今年有規劃更新 slides，並且涵蓋如何對 GPL'd 軟體元件作模組化區隔，以及整理相關案例，希望我手頭的專案能早點結束) 雖然僅可能讓自己白天跟晚上的工作內容不相關，比方說白天改善 speech codec 的效能，晚上設計 virtual machine，假日再來作雜項的技術顧問，不過這樣實在很難兼顧，最重要的是，潛在的法律問題是很麻煩的。我習慣用 Linux 作軟體開發，就算 target 上面是 WinCE，我也可以用 Debian 上的 toolchain 來作 prototype，但很多 routines 其實怎樣寫都會差不多，不知不覺白天在公司的創作，就會出現於晚上，或者給其他家公司的顧問工作中，我該如何釐清？該如何跟老闆與客戶澄清呢？我花了很多時間作這些非技術的溝通，有時候只好如之前的 blog [為何要醉 coding] 一般，回家趕快用酒精麻痺自己，買醉後，我才得以忘記這些「包袱」，現實的問題太多、太多了，其實我自己就深受軟體授權、軟體專利，以及相關的法律條文所困，又怎能協助其他人呢？ *笑*

如果《十日談》有機會改版，請把我這個無聊男子的憂鬱、恐懼，以及茫然的故事寫進去。

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

Open Source：如何在創新與風險間平衡

早上在閱讀 Susana Schwartz 撰寫的 [Open Source: Balancing Innovation and Risk] 一文，雖然是 2004 年十月份寫的文章，但仍有參考價值，對岸的 [CoreUp Designs] (錢浙濱博士與他的團隊) 提供了一份簡體中文翻譯 [開放源代碼：創新與風險的平衡]。

引用錢博士的摘要：

從電信運營商／服務提供商(carriers/SP)的角度，包括系統的可靠性、可用性以及運行維護等；
從設備製造商(vendors)的角度，包括嵌入式開發，局端服務器和運維設施等。

而文中 "Demystifying Open Source" 一節提到的現象的確相當切合當今所面臨的種種挑戰，以 [UNIBILL] 來說，該公司涵蓋多項大型電信帳單交易系統的規格與相關服務，這一系列的軟硬體建設相當龐大，當時負責 [UNIBILL] 銷售和市場的高級副總裁 David Guggenheim 對 open source 如此表示：

呼應文章主題的「創新」就是，使用開放原始碼解決方案能克服計費和客服部門兩個常見的問題：一是不同客戶間的區別，另一則是推向市場的時間太長，產品特徵路線圖必須在廠家和客戶之間同步。

那「風險」即是，客戶的 IT 部門必須遵循一套原則保持與Unibill 的產品路線同步。

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

UNIX 家族簡介

UNIX 家族總是帶有神秘而且獨特的文化，Peter Seebach 寫了一篇文章 [Standards and specs: Not by UNIX alone - A maze of twisty little standards, all alike]，提供簡單明暸的介紹，很值得一看，而且他相當風趣地在作者簡介的欄位填上：

Peter Seebach is not POSIX compliant, but runs most UNIX applications. He types "make" a lot. 此外，UNIX 家族到底有多少成員、又到底有什麼繼承關係呢？可以看 [UNIX history (preview)]，觀看該網頁時，請記得將 web browser 的 scrollbar 用力右捲。中文介紹可參考 [UNIX家族及類UNIX系統]，以計畫導向作介紹。對了，日本人也很喜歡 UNIX，不過他們似乎想到其他地方去了，請參考 [http://www.unix.co.jp/]，好美的 UNIX Program 阿，讚嘆！

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

透過 Intel Pentium4 SSE2 指令集對 MPEG-2 Video 作最佳化 (1)

最近在工作中又複習了 MPEG-2 Video coding 與內部實做，並針對特定硬體平台作效能提昇，寫完技術報告時，心情輕鬆許多，很想大喊："I did it, I did it!"。在工作之餘，我也對 open source codec 產生興趣，恰好對 MPEG-2 實做與效能衝擊的部份有足夠的認知，所以我試著以 Intel Pentium4 SSE2 指令集，來對 MPEG-2 Video coding 作最佳化。

簡單來說，MPEG-2 decoding 有兩大效能瓶頸，一個是 Inverse DCT (idct)，另一個是 MC (Motion Compensation)，在我的 hacking 中，已經初步有了不錯的突破。我挑選 MPlayer 作為 codebase，並且改善了 MC 的效能，可 [在此取得 patch] (GPL)，同時我也改善了 libmpeg2 多餘的 cpu detection 處理。以下是實測數據：
(1) Baseline (使用 MPlayer 原本的 mmxext MC)：

MPEG-PS file format detected.
VIDEO:  MPEG2  720x480  (aspect 2)  29.970 fps  2376.0 kbps (297.0 kbyte/s)

BENCHMARKs: VC:  10.785s VO:   3.092s A:   0.595s Sys:  20.772s =   35.244s
BENCHMARK%: VC: 30.6027% VO:  8.7722% A:  1.6879% Sys: 58.9372% = 100.0000%

 time   seconds   seconds    calls  ms/call  ms/call  name
 15.58     12.83    12.83  3013243     0.00     0.00  mmxext_idct
 14.70     24.94    12.11   515616     0.02     0.02  MC_put_xy_16_mmxext
 12.40     35.15    10.21    56139     0.18     0.18  fast_memcpy
  6.69     40.66     5.51  1826892     0.00     0.00  slice_intra_DCT
  6.34     45.88     5.22  1500758     0.00     0.00  MC_put_o_8_mmxext
  5.44     50.36     4.48  1758006     0.00     0.00  get_non_intra_block
  3.95     53.61     3.25    30480     0.11     2.16  mpeg2_slice
  3.28     56.31     2.70  1069690     0.00     0.03  motion_fr_frame_420
  3.21     58.95     2.64   112816     0.02     0.02  MC_avg_xy_16_mmxext
  3.14     61.54     2.59  1826892     0.00     0.01  mpeg2_idct_copy_mmxext

(2) SSE2-optimized-MC (我剛剛的 hacking)：

MPEG-PS file format detected.
VIDEO:  MPEG2  720x480  (aspect 2)  29.970 fps  2376.0 kbps (297.0 kbyte/s)

BENCHMARKs: VC:  10.712s VO:   5.277s A:   0.598s Sys:  17.861s =   34.448s
BENCHMARK%: VC: 31.0958% VO: 15.3193% A:  1.7352% Sys: 51.8497% = 100.0000%

  %   cumulative   self              self     total
 time   seconds   seconds    calls  ms/call  ms/call  name
 16.32     13.24    13.24  3013243     0.00     0.00  mmxext_idct
 12.43     23.33    10.09    56139     0.18     0.18  fast_memcpy
 10.67     31.99     8.66   515616     0.02     0.02  MC_put_xy_16_sse2
  7.16     37.80     5.81  1826892     0.00     0.00  slice_intra_DCT
  6.85     43.36     5.56  1500758     0.00     0.00  MC_put_o_8_sse2
  5.73     48.01     4.65  1758006     0.00     0.00  get_non_intra_block
  4.97     52.04     4.03    30480     0.13     2.10  mpeg2_slice
  3.27     54.69     2.65  1069690     0.00     0.03  motion_fr_frame_420
  3.24     57.32     2.63   205987     0.01     0.01  MC_put_x_16_sse2
  3.11     59.84     2.52  1826892     0.00     0.01  mpeg2_idct_copy_mmxext
  2.93     62.22     2.38   112816     0.02     0.02  MC_avg_xy_16_sse2

「數字會說話」，可以發現 MC_xxx 的 motion compensation 運算速度獲得提昇，於是整體的 benchmark 比值也提高，對於播放中的 MPEG-2 影片來說，系統的 idle time 增加，這也意味著對能源的使用可更經濟。

有 Pentium4 或相容機種的朋友，歡迎測試這個 patch。稍後我會試著探討以 SSE2 指令集改善 MPlayer 的 MPEG-2 IDCT 運算。 (按：這是怎麼一回事：我的正職工作就在作 codec，下班後，還是在改善 codec 效能，永遠忙不完)

由 jserv 發表於 12:34 AM | 迴響 (4)

明哲保身之程式設計

接連讀完兩篇不同主題的 blog：[做好本職工作，不管閒事，學會保護自己 ] 與 [辦公室錦囊：明哲保身篇] 後，雖然沒有直接關係，但由第一篇文章的牽引 (可別看標題無聊，裡面可是寫物件導向的概念)，再來看後者，覺得很有趣。太積極或太消極，都不是好事，保持中庸之道也要避免淪落於死腦筋。對一個 Application server 而言，其需要管理的物件相當多，而且還得全盤掌握其狀況，有必要時，還需要套用不同的政策，這跟辦公室或者企業內部管理，實在神似。

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

ChangeLog 的寫法

ChangeLog 對於版本控制相當重要，特別是 free / open source projects，因為很可能所有的開發者都在不同時區、使用不同語言，連用 IRC 碰面的機會都很少，除了不定時的討論外，就要看這些 log 了。之前的 blog [新酷音輸入法在 OXIM 的支持] 提到 [新酷音計畫] 獲得 OXIM 的採納，並且是預設輸入法，剛剛 cvs update 後，發現這個有趣的 ChangeLog：

2006-3-6  Firefly 
        * src/modules/chewing/chewing.c :
          新酷音從 0.2.6 開始支援漢語拼音，這下我不用太累(淚)。
          開始著手修改新酷音支援漢語拼音(新酷音版本至少 >= 0.2.6)。

        * src/include/module.h src/modules/bimsphone/bimsphone.c
          src/modules/gen-inp/gen-inp.c src/modules/unicode/unicode.c :
          移除不再需要的變數。好像還有一堆東西要移除，哇勒！改程式真累 :-P

我的習慣是僅可能用英文書寫 ChangeLog，除非一定要用中文表達，這是為了其他 distributor/packager 的便利 ([新酷音計畫] 的 SuSE 套件一直是德國開發者所打包)，不過，FireFly 上面的 log，的確是「不用母語，無法表達」阿，經典！

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

公車電視化

剛剛瞥見 [公車輓歌部落格：公車電視化，人權正退化]，其鮮明的 logo：

北上工作初期，撘過一段時間的公車，也領教過 BeeTV 上反覆播放的訊號，之所以說「訊號」一詞，因為我現在鮮少搭乘公車或捷運，似乎沒資格評論。

因為案子需要，我設計過類似的系統，還好沒有承接這個案子，以前撘公車的時候，我沒有很認真的觀看，只是很期待系統 reset 或 crush，或許這是工程師的樂趣：看別人設計的系統當機，然後鼓掌叫好，再來事後諸葛地說應該要如何如何。我觀察到 BeeTV 播放的系統是 Linux-based，2.4 kernel、Wireless Extension version 17，並透過 X Window System 作顯示 (我還有種衝動，想拿儀器來測量 RF 訊號)，正如之前的 blog [技術本身與道德無關；它沒有是非對錯] 所說，這個組合的確可正常運作，儘管當機的頻率似乎高了些 (兩年前的觀察)，但是呢，「道德問題」卻很明顯被加諸於這個電子裝置中...

等等，那我的看法到底如何？我懶得理會，乾脆每天騎淑女車代步，什麼鳥都看不到 *笑*

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

GNU Classpath 0.90 釋出

令人振奮的消息，[GNU Classpath] 又邁入新紀元，原本是兩個月新的 release timeline，現在改由功能導向，也就是與 Sun JDK 或者其他 Core API 相容度來認定版本號，這個新政策反映於新的 release 0.90。這是一個相當重要的版本，有非常多改進，詳情可參考 [ANN: GNU Classpath 0.90 "A La Mort Subite" released]。

相容性測試的部份：

This release passes 43856 out of 44429 Mauve core library tests. GNU Classpath rules! 一整晚沒睡，就是在等待 0.90 Release :-)

由 jserv 發表於 04:26 AM | 迴響 (1)

葉公好龍：談 Mobile TV

漢代劉向《新序、雜事之五》述及：

葉公子高好龍，鉤以寫龍，鑿以寫龍，屋室雕文以寫龍。於是天龍聞而下之，窺頭於牖，施尾於堂。葉公見之，棄而還走，失其魂魄，五色無主。是葉公非好龍也，好夫似龍而非龍者也。

用白話文來說就是，某個名為葉子高的人，喜好吹噓對龍的熱愛，不僅在衣帶鉤上刻畫著龍紋，臥室凡是雕刻花紋的地方也全雕刻著龍的象徵。天上的真龍耳聞這位公子對龍是如此投入，於是作試探性的動作：真龍將頭伸進窗戶裡探望、拖曳於廳堂，而公子見狀，驚恐萬分、回頭就跑。真龍感到莫名其妙，於是失望而返。這則有趣的寓言在說什麼呢？很簡單，葉公並非真的喜歡龍，只不過是形式上、口頭上喜歡罷了。

剛剛 coding 疲倦時，瞥見 Embedded.com 兩則新聞評論 [Divining the IPTV shift] 與 [Mobile TV: promising, but disappointing] (作者：Craig Mathias)，讓我想起這則「葉公好龍」的典故。Mobile TV 或 IPTV 到底會不會成功呢？而我是否會在幾年後，目睹這些技術的衰亡或更替，感傷地寫另一篇類似 [推播、推敲] 的文章呢？我不知道，而且就算作斷言也無意義，IT 產業與整個媒體的動向太快、太虛幻了。

剛剛引的文章第二篇有頗多值得深省之處，一開頭就指出：

There's a core problem with mobile TV--apart from the additional expense for the service and required subscriber units, the grainy images, the slow frame rates, the glut of commercials and the variable nature of the radio channel. The problem is that buyers are accustomed to the two benefits bestowed by cable TV: range of programming and video-on-demand. Without them, mobile TV will fail. 雖然是老生常談了，不過這也是不爭的事實。在 Google 上以「Mobile TV 未來」當關鍵字，可找到太多正面的資料，好似我們的數位生活就如同量子力學的能階變化，只要有這些技術、產品以及整體的數位建設問世，我們就可徹底擺脫當下娛樂的體驗方式一般。不經意就可以找到一些，如 SPTI 的 [服務模式在Mobile TV的重要性] 與 3C 情報的 [3.5G、4G、行動電視新技術大解盤！] 一類的報導，「數字會說話」，引用學者專家的數據與資料，總有高度說服力吧？不過，果真如此？

Craig Mathias 寫道：

業者、學者，以及消費者將希望寄託在美麗的 3G 或 "4G" (最好再來個「三雞」)，但是，我們面臨的難題真的解決了嗎？抑或，這就是我們期待的方式？我們看到，電子消費市場與新聞媒體充斥著這類愛好「龍」的一切：無論何時、何地、何人，只要打著 "Mobile TV" 的名號，都可引來巨大迴響，因為「大家都愛龍、都沈迷其中」。

反應一向慢半拍的我，有個疑惑：我們真的愛「龍」嗎？還是其實我們只是形式上、喜愛沈浸在追逐虛幻的過程呢？倘若來日，當我們真看到「真龍」，又該如何回應？我還是不懂。

按：本篇 blog 僅代表個人立場。

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

美力與軟體

之前的 blog [喝完臉紅紅]，提過我在 [Blog on Blog] 瞥見可愛的 Qoo 圖示：

而我剛剛也在 [ 阿孝札記::公民新聞的十件大事] 瞥見可愛的球蠟創作：

讓我衷心企盼，這些可愛的圖示可以挪作 [新酷音計畫] 使用，幻想這個情境：腦海依稀閃過某個成語，可是根本不知如何下筆，只知道大概的發音方式，依序輸入注音符號後，[新酷音引擎] 就幫您找到合適的成語或用詞了，這時候可愛的 Qoo 寶寶 (或「酷音寶寶」？) 就會說聲：

「酷～～」商業周刊第 903 期的專欄 [美力時代] 提到隨著文化層次的進步，「美」與我們更加密切，對許多消費性電子更是如此，蔣勳用很簡單但深刻的一句話表示「美力」的泉源：「美的本質就是創造力」。剛剛在刀槍 Blue 的 blog [Apple Ideas] 瞥見想像中的 iPhone (說不定 Apple 真的有這類產品的開發？) 圖像：

對我這個雖然服務於手機 ODM 產業、卻鮮少使用手機的人來說，這個 ID 設計讓我乍看就有購買的衝動，感覺很奇妙。昨天讀 chihchun 的大作 [Linux Mobile Phone]，他提到 Linux 作為 mobile phone 的基礎，雖然困難重重，倒也不少機會，最重要的是，的確有不少開發者已經克服許多根本上的議題，像是以 Intel PXA27x 為硬體平台的 SmartPhone，基本的 BSP 議題大概都解決了，也能運作 GPE 或 OPIE 一類 open source handheld MMI framework，也能透過一些 hack 來下 AT command 打 GSM，初步的成果如下圖：(只是眾多計畫中的一種)

應該也是有機會可修改成公眾可用的程度，開放系統的優點就是有高度的自主性，允許源源不絕的創意在這平台上實踐並體驗，激盪出更高層次的「美力」 *笑*

所以，Let's hacking...

由 jserv 發表於 12:29 AM | 迴響 (2)

一百年前的平反：談 Alfred Dreyfus 案

百年前 (1906)，前法國上尉 Alfred Dreyfus 被控洩密的罪行獲得平反，不過這位軍官並未因此鬆一口氣，因為接踵而至的法西斯主義才正要在歐陸刮起一陣颶風。

1894 年，服務於法國參謀部的 Alfred Dreyfus 上尉被指控為德國從事間諜工作，隨即受到偵訊並受審判，引來長達十二年之久的法國輿論與暴力鬥爭，支持與反對者的衝突成為國際注目的焦點，為何一個「間諜」(最後證明是莫須有) 會造成當時如此大的迴響呢？Alfred Dreyfus 上尉是當時法國參謀部中，唯一的猶太人，於是乎，他淪為代罪羔羊，而非對法國效忠的軍官。

當時德法境內瀰漫著極端保守主義者 (The Ultraconservatives) 的思潮，並採取以法國 Hoseph Gobineau 伯爵 (1816-1882) 所著的《論人類種族的不平等》的意識形態論點，該書被稱為「種族主義的聖經」，重要的論述是：

「種族優劣是社會興衰﹑文化高低的決定因素。黑種和黃種是低級種族。白種，特別是雅利安種族，是高級種族﹐其中日耳曼人最高貴﹐而日耳曼貴族又保留了更多的純潔性﹐是一切高度文明的創造者。」這一類不符合科學的命題反覆在書中出現，就今日的角度來說，如同 Hoseph Gobineau 妄想將社會達爾文主義與種族主義論點結合，依侍達爾文進化論中「物競天擇」的學說，貿然移植於人類社會與文化歷史中，不僅不人道，更是高度不智。在納粹帝國、希特勒專政的年代，法西斯主義者更是將種族主義轉化為最高指導原則，於是給予掠奪他國領土資源的惡行，無比崇高的合法性，納粹更提出「種族衛生學」，強制消滅低級種族的生存機能，並進行大規模屠殺。

「一個人之所以是偉大的、高貴的，和有德性的，不是靠他的行動，而是靠他的血統」 Hoseph Gobineau 在《論人類種族的不平等》給予這個完全不合理的結論，任何理性的文明人都可反駁，但他在書中極力證明「種族是歷史領域唯一的統治者，並且血統和遺傳的純良，是保持一切偉大的文明和一切高貴種族的必要手段，同時，一個人出生的道德確定性來自上天的恩賜，而非人力所能左右。」等觀點卻激發更多喪心病狂的極端保守主義者，群起效尤。稍後，Edouard Drumont (1844-1917) 發表《猶太人的法國》，更是惡名昭彰，竟然也引來許多德國境內高知識份子的認同，這些人的共通點就是愛國、愛民族並且緬懷過去的光榮。

作為代罪羔羊的 Alfred Dreyfus，無奈的接受這一切，還得被極端保守主義者訴諸種種陰謀，以及標上「反基督化」的標籤，當然，持相反論點、反對種族迫害的社會人士也大力抵制極端保守主義者。小說家 Émile Zola 在 1898 年一月發表著名的《J'accuse》(中文意思即「我控訴」，英法對照版本可參考 [Chameleon Translations] 提供的翻譯)，要求該迫害案的重審。

而稍後在二月底 Émile Zola 為此被拘禁。Alfred Dreyfus 案在 1898 年獲得重審，並被赦免，但紛爭四起，一直要到 1906 年才被平反，這十二年中，多少人的青春與前程毀於一旦？多少標榜進步的工業化社會暴露自身的人性缺失？多少人失去理智而成為極端保守主義者？面對這些問題，儘管當時的資料未明確記載，不過這所種下的政治態度「孽種」卻在日後萌芽並席捲近代史，一直到今日，這種「不文明的文明」還持續存在著，怎不叫人唏噓？

Alfred Dreyfus 在一百年前獲得平反，表面上是反猶太主義的挫敗，但實際上，更是加深極端保守主義者的仇恨，留下不定時炸彈。上個世紀，人類歷經兩次世界大戰、強權的冷戰、區域性的種族屠殺、文化的衰退、... 下筆之際，又不禁沾染 [沉淪的液體] 一文中的感傷、無力，以及質疑人性的一切。

參考資料：德文版 Wikipedia [Alfred Dreyfus] 與 [Émile Zola]。

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

dlopen 的 _init 與 _fini

閱讀 LinuxJournal 的文章 [Dynamic Class Loading for C++ on Linux]，我注意到其中的描述：

According to the dlopen man page, if your library exports a function called _init, this function will be executed when the library is opened. This may seem to be the ideal place to register our maker, but currently the mechanism is broken on Linux systems. The problem is a conflict with a standard linker object file, crt.o, which exports a function called _init. man page 也提到：

對 security 而言，這方面有頗多可著墨處，可參考 [GNU And Its Role In Exploitation by Phactorial]，回到正題，LinuxJournal 上那篇文章參考了 Jim Beveridge 提出的 "self-registering objects" 技巧，不過如果能善用 _init 與 _fini 的特性，其實可以更簡潔。

_init 與 _fini 的建議替代方案：首先是要載入的 shared object，程式碼如下：

#include <stdio.h>
#include <stdlib.h>

/* GCC __attribute__ */
void __attribute__((constructor)) Double_init()
{
        printf("_init invoked!\n");
}

void __attribute__((destructor)) Double_fini()
{
        printf("_fini invoked!\n");
}

/* Customized routines here */
int Double(int arg)
{
        return (arg + arg);
}

再來是主體程式：

#include <stdio.h>
#include <stdlib.h>
#include <dlfcn.h>

int main(int argc, char **argv)
{
        void *handle;
        int (*func)(int);
        const char *error;

        /* shared object (1) */
        handle = dlopen ("./shared.so", RTLD_NOW);
        if (! handle) {
                fputs(dlerror(), stderr); exit(1);
        }
        func = dlsym(handle, "Double");
        if ((error = dlerror()) != NULL)  {
                fputs(error, stderr); exit(1);
        }
        printf ("invoking Double(2) => %d\n", (*func)(2));
        dlclose(handle);
}

這過程中，記憶體的布局變化如下：

此外，另一篇文章 [Cross platform dynamic library initialization in C++] 也很值得參考，不過 macro 與 variable 的命名怎麼有點像 MFC style 呢？最終的 deployment，最好也能符合 LSB 規範 (Debian package 也有類似的要求)，可參考 [Developing LSB-certified applications] 一文。

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

PowerWise™ Interface (PWI) 2.0

美國國家半導體 (National Semiconductor，NS) 與 ARM 共同宣佈，PowerWise Interface 2.0 標準已正式制定完畢，相關新聞稿可參考 [PWI Standard]。PWI 2.0 規範可 [在此取得] (PDF format)，其概念示意下圖：

PWI 簡單來說，是種 2-wire 的 serial bus，可將 SoC 與 PMIC 連接。能源的耗損包含 active 與 static 兩方面，透過 PMIC，可使用 DVS、AVS、DBB、或 DTS，以及 ABB 或 ATS 等技巧，來達到進階能源管理。

從上圖 (簡化模型) 可以發現：一個 SoC 伴隨一個 PWI master、一個 PMIC 伴隨一個 PWI slave，以及 2-wire PWI 連結 PWI master 與 slave。PMIC 提供電壓給 SoC，而 votage level 則由 PMIC 決定，並可透過從 PWI master 到 PWI slave 之間的指令傳遞完成調整。這個架構可以擴充為，兩個獨立的 SoC 伴隨兩個 PWI master，允許最多到 16 個 PWI slaves。

新聞稿也提到：

NS及ARM將於2006年第二季推出符合PWI 2.0介面標準的內建式功率控制器，這項專利技術可支援ARM的智慧型能源管理員(Intelligent Energy Manager)技術，後者內含ARM Artisan Physical IP、AMBA 3 AXI互連線路以及IEM軟/硬體。NS並將於2006年下半年推出多款符合PWI 2.0介面標準的外置電源管理IC。

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

探討 Linux Mobile Phone 發展

chihchun 寫了一篇大作 [ Linux Mobile Phone]，這萬餘字的文章對產業與 Linux 社群提出的想法和解決方案，做了很詳細的分析，推薦閱讀！

不過，我想大家都很清楚，誰才是真正的行家了，所以「以後別問我 Linux Phone 相關的問題」，把問題轉交給 chihchun，他應該可以給予更好的答覆，謝謝 :P

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

IBM eLite Core 的參考文獻

為了避免「中年危機」，除了每週強迫自己算數學外，今年還開始學硬體，有個一技之長總是比較安心。之前學 ASIC 感到很大挫折，在 Google 找了些資料，意外發現 IBM 有個 eLite Core 的研究計畫，並且相關的研究文獻也有上線，可參考 [Publications] 與 [Presentations]。在這個領域，我連門外漢都稱不上，不過裡面倒是有些 paper 很吸引我，比方說我前天讀的 [A New Look at Exploiting Data Parallelism in Embedded Systems] (PDF format)，其 slides 也 [可取得] (MS-PowerPoint format)。讀這些論文很有挫折感，不過至少讓我知道，原來 SIMD 演化為 SIMpD (Single Instruction Multiple Packed Data) paradigms 與 SIMdD (Single Instruction Multiple Disjoint Data)，該論文也針對 VLIW 提出改良，並以 eLiteDSP 具體的成果驗證研究團隊的想法，光從論文提到的 FIR 的例子就可發現...

每次讀到這些論文，總覺得自己連個白痴都不如，一張 slide 可以讓我反覆找資料並思考好久 *sigh*

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

懷念的滋味：勝利早點

就如 DarkKiller 在 blog [Xuite Blog 的 RSS…] 所提及：

因為 Bloglines 上發現一堆 Xuite 的 RSS 讀取記錄被重設了… (一堆 unread entries…) 在 liferea RSS client 也發現好多unread entries，而我也意外發現 champ 學長寫的 blog [關於勝利早點]，給我好多感觸。我想，每個唸過成功大學、特別是住過勝利校區宿舍的人，應該都忘不了勝利早點吧。

高三以前，我根本沒考慮過成功大學，或許是因為周遭的那些優秀同學，整天掛在嘴邊的都是「台清交」，不然就是「台大醫科」或「台大電機」一類高標準，不過升高三的暑假，參加成功大學航太系主辦的「高中實驗火箭設計大賽」時： (click to enlarge)

我竟然愛上這美麗的校園，還有便捷的交通，這與「遙遠」的交大恰好相反，記得以前溜去交大計中玩電腦的時候，都是從苗栗搭火車到新竹火車站，然後徒步到交大校區，往往要一兩個小時，而成功大學的校區就在台南火車站後站，真方便，而且附近吃喝玩樂的地方還不少，作為「由你玩四年」，一點也不為過。

因為某些複雜的因素，儘管成績可考上在我志願中所涵蓋的慈濟醫科、台大化工、台大數學、清大原子科學、交大多個工學院科系、...，最後我選擇了成功大學。也必須承認，我念大學，基本上只圖一個「學生」的身份，從入學第一學期開始，幾乎完全與學校脫節，只在意自己的計畫與那些瘋狂的規劃。

[我的首頁] 列出來的計畫，那些技能，可以說是在短暫的大學生涯中，逐漸培養出來的 (其實以前還作過一些計畫，不過現在一概不提)，有時候想想，自己當時的行徑，已經無法用「瘋狂」來形容了：連續三天沒睡，只為了 trace 某個 RTOS；連續一學期不去上課、只待在住所 coding，就為了自己的計畫；早也 hacking、晚也 hacking，連入夢都保持 hacking，也因此，那段時期，我是個夜貓子。

成大附近有很多販賣宵夜的店面，其中不少還開 24 小時，「勝利早點」在這些店面中，相當有特色，老闆對人的方式就如 champ 學長提到，非常親切。我也記得，有一次連續近兩天沒睡、沒進食的我，用著僅剩的體力，搭乘計程車 (是的，那時候初嘗接 case 獲得暴利的滋味，連走路不到十五分鐘的路程都要搭 Texi，如今想來，真是可恥至極)，老闆看著我紅腫的眼睛，以及快被榨乾的軀體，殷情問候說：

「唸書唸得好辛苦，來，招待你用...」我忘記到底當時被招待吃什麼了，不過那句話讓我頗汗顏，如此拼命，其實只是為了作專案，根本不是唸書，但這樣讓我檢討了好一段時間，隔天趕快去買 textbook (因為擺明只是來混大學的，所以上課連書也沒買)，那學期，是我大學生涯唯一 all pass 的一次。

離開成大已經四年多，至今還是很懷念校舍的一切，還有陪伴我度過無數個體驗「燃燒生命」日日夜夜的餐館、小吃店，或者攤販，當然也包含勝利早點，令人懷念的滋味...

如果，有一天，我能夠再回到大學，回到我熟悉的成功大學，好好的唸書、好好的作學問，大快朵頤勝利早點所提供美妙滋味的食材... 唉，「選擇了，就不要後悔」，如今，我只希望，能大大方方的走入成功大學校園，而不是心懷歉意與怨懟，這只是一個中輟生的回憶，了無新意。

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

我是 hacker，不是「駭客」

剛剛看 [第一屆駭客才藝大賽]，裡面所羅列「駭客」的定義，實在讓我有點難接受。

以下內容純屬虛構，如有雷同，純屬巧合。

「名列台灣電腦十大高手之一」當然可說是 hacker，但是「曾經使用過破解版軟體」呢？小時候玩紅白機的時候，那些 ROM 都是台灣人改過的，所以我從小就註定是「駭客」了？豈不跟國小課本裡面舉某些名人「自幼看到魚群溯流而上，就立志要作大事」一般？那麼，「會自己架設部落格，或是會改css」呢？從高中到現在，我親手寫過了幾個 web browser，也曾參與過相關的專案開發，不過，我的確不會自己架設 blog，現在這個 blog 也是 blog.linux.org.tw 提供的；我讀過 CSS 1/2/3 以及 W3C Recommendation，也寫過 test case，不過我寫不出像樣的 CSS，所以，就這點來說，我不夠格 :P

「看過《駭客任務》n遍」勾起我的傷心處，在我開始 fine tune MPEG-4 codec 的 performance 前，我沒看過《駭客任務》，不過在無數次的測試時，我「被迫」反覆盯著《駭客任務》無數 video frames，只為了確保品質與效能，這算「看過」嗎？我不知道，我只知道《駭客任務》對我來說，是沈重的。

好吧，或許我跟台灣的社會有點脫節了，原來「駭客」的定義是這樣，這讓我想到，《共產黨宣言》的共同起草人馬克思臨終前，曾說過這麼一句話：

「我從來不是馬克思主義者」於是，我是 hacker (老外給我的稱呼)，不是「駭客」。

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

Tensilica 六款新的 RISC core

在業界執 SoC Design 牛耳的[Tensilica]，最近又發表六款新的 RISC core，新聞稿可參考 [Tensilica Diamond Standard系列新型處理器核心問世]，這系列 configurable processor 帶來頗大的衝擊。Tensilica 總裁 Chris Rowen 表示：

「configurable processor 可為特定應用而量身訂製，有些甚至可取代 ASIC 及 SoC 中 hand-coded 的 RTL 設計，將成為 SoC 的主流。」更技術性的介紹可參考 LinuxDevices.com 的新聞 ["Post-RISC-style" processor targets mobile Linux devices]，網頁的資料提到：

這幾款以 Tensilica Diamond Standard 232L 的系統架構圖來看：

這完整的設計，更是對 ARM 產生一定的衝擊，新聞稿中還提到與 ARM926EJ-S 的比較，這場 SoC 領域的技術競賽趨於白熱。

2004 年年底，ARM 提出 [son of Thumb at uCs, ASSPs, SoCs]，針對 DSP 的廣泛應用與 Realtime OS capacity，也引入 Thumb-2 instruction set architecture (ISA)，代表設計就是 Cortex-M3，其架構圖如下：

reference board 在今年會出現，這兩種不同設計理念的硬體架構，一個強調高度彈性、一個以既有指令集相容的優勢，卻不約而同對於 Linux 有高度的支援 (ARM 有不少全職的 kernel / GNU toolchain developer，Tensilica 也有相當程度的涉入開發)，未來會如何呢？拭目以待。

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

eCos 簡介

Peter Seebach 寫了一篇關於 eCos 的文章 [An introduction to eCos]，很適合初學者參考，可惜我上個世紀末就開始學 eCos 了。不過我這裡引出來的用意是，因為寫書需要，想來模仿類似的寫法，寫書還得用力揣摩讀者的背景與可能的疑點，比寫情書還難阿 :(

說到 eCos，不能不讀 Anthony J. Massa 的經典著作《Embedded Software Development with eCos》，LinuxDevices.com 對於本書做了簡介 [Introducing 'Embedded Software Development with eCos']。喔，對了，如果沒有意外的話，Kaffe 下個 major release 會有 native eCos support。

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

顏貌的繪製

之前的 blog [#&%&$^(^*$$] 提到以前跟小貓交往時，我相當欣賞她的天份，無論是美學、文史哲，乃至於工程科學等領域，都有高度的造詣，或許如此，我對素描產生了興趣，開始欣賞畫冊，凝視並試著體驗。我沒有如 [PCMan] 的天份，但我還是試著創作，從這幾個月開始，端詳女性的面貌，只是用鉛筆線條與碳粉勾勒，陸續做了 [隨手畫 - jie]、[隨手畫 - Purple]，與 [隨手畫 - Ally]，似乎稍有進步 (希望不至於傷了讀者的眼睛)，而昨天跟 BBNS 兄請教，他給了一些提示：

至於 BBNS 提到的參考資料，如下：

我白天的工作，很大部份跟 multimedia codec 有關，看到色調，很自然就想到 YUV color space，其中 Y 代表明亮度 (Luminance)、U 代表色調 (Hue)， V 代表飽和度 (Saturation)，人類的視覺較重視彩度，而較忽略明亮度，這也導致轉換灰階時，相關係數的微妙變化。看了這幾篇 tutorials，好像又有些啟發，有機會再試試。

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

弱肉強食？

在「軟體」的概念逐漸產生時，Bell Lab 的年輕的科學家 H, Douglas McIlroy、Victor Vysottsky，以及 Robert T. Morris 就想到是否可模仿生物的行為，執行於硬體之上呢？所以就有「磁蕊大戰」 (core war) 的實驗：兩方各寫一套程式，輸入同一部電腦，這兩套程式在電腦的記憶系統內相互追殺，或設下關卡、或暫停作修理被對方破壞的指令、或受困時將作自行複製、... 經過幾番「廝殺」，總是會有輸贏，又因它們都在電腦的記憶磁蕊中遊走，於是有此大名。

Robert T. Morris 的兒子 Robert T. Morris Jr. 更是出名，他寫了簡單但具強烈威脅的程式，癱瘓 Arpanet，而在 PC 平台上，也由伊朗的兄弟撰寫 (C) Brian 開啟「電腦病毒」的濫觴，後來的故事大家都知道，這裡就省略了。剛剛讀 [綠林] 這篇 blog，大為驚訝，我寧可相信這不是事實，但倘若這一切如 Maxthon 的公告所言，是因為某公司某個心懷不軌的程式設計，導致系統崩潰...

這齣「弱肉強食」的戲碼還真生動阿。

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

Jlo : 小型 x86 boot loader

我大概有兩年沒有接觸 x86 低階的領域，剛剛讀 Checko's blog [small linux bootloader - x86, hd]，介紹到 [Jlo - Jeff's Loader] 這個短小精悍的 x86 boot loader，Checko 的 blog 已經有詳細的中文介紹，這裡就不贅述了。

最後的釋出版本是 0.1.2，時間是 Dec 27, 2002，編譯除了網頁列出的項目，還需要 i386-uclibc toolchain，稍微弄了一下，竟然沒辦法讓 qemu boot，不曉得是怎麼一回事 :(

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

企鵝 Linux 電腦

LinuxDevices.com 的新聞 [Tux-shaped computer runs Linux] 提到一則非常有趣的新聞，位於義大利的 [ACME Systems] 做了一個非常可愛的 SBC (single-board computer)，售價 30 歐元、6.7 吋高度的 "Tux Case" (Acme Fox)，顧名思義就是企鵝外型的 SBC，支援 2.4/2.6 Linux kernel，外觀如下： (click to enlarge)

其組成是由六塊塑膠材質： (click to enlarge)

這玩意可不是華而不實，有足夠的 connectivity，咱們欣賞這隻企鵝的「屁股」：

I/O connectors 示意圖如下： (click to enlarge)

有一個 10/100 Ethernet 與兩個 USB，看來可以作些有趣的應用。

由 jserv 發表於 08:58 AM | 迴響 (1)

新酷音輸入法在 OXIM 的支持

感謝 FireFly 前輩不眠不休的努力 (仔細看看他發表文章與程式碼更動的時間，早中晚都有涵蓋耶)，現在 OXIM 已經支援 [新酷音輸入法]，詳情可參考新聞稿 [OpenDesktop計畫消息 : OXIM 1.0.1 輸入法釋出，支援新酷音與全字庫]，現在 [新酷音計畫] 又多了一個成功案例。

引用 oxim 的 ChangeLog：

2006-3-1  Firefly 
        * etc/oxim.conf.in :
          預設使用新酷音輸入法。
          改用新的全字庫輸入法參考檔。
...
2006-2-28 Firefly 
        * src/include/IC.h src/include/module.h
          src/include/oximtool.h
          src/lib/ucs4toutf8.c src/lib/wchs_to_mbs.c
          src/lib/im_comm/ascii_wb.c 
          src/lib/im_comm/charcode.c
          src/modules/bimsphone/bimsphone.c
          src/modules/bimsphone/bimsphone.h
          src/modules/bimsphone/bimspinyin.c
          src/modules/chewing/chewing.c 
          src/modules/gen-inp/gen-inp.c
          src/modules/gen-inp/gen-inp.h 
          src/modules/unicode/unicode.c
          src/util/oxim2tab/gencin.c 
          src/util/oxim2tab/gencin.h
          src/util/oxim2tab/oxim2tab.c 
          src/util/oxim2tab/syscin.c
          src/xim/gui_preedit.c src/xim/oxim_main.c 
          src/xim/xim.c
          src/xim/xim_IC.c :
          因「新酷音」輸入法使用與 OXIM 同名結構 wch_t，但長度不同，
          幾經思考，決定修正 OXIM，將 WCH_SIZE 改名為 UCH_SIZE，
          wct_t 改名為 uch_t，同時修正相關程式。

至於 API 與內部核心翻修的 libchewing 0.3.x 也期望會在近期內釋出，到時候要連同修改的 IM server/bridge 還真不少，不過，看到 [新酷音計畫] 的成果可被這麼多專案採用，頗感欣慰 :-)

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

Cortus 的 compact 32-bit RISC

Embedded.com 的新聞 [French startup offers compact 32-bit RISC] 介紹 [Cortus] 公司最新的 processor 產品 [APS32]。在新聞稿提到：

詳情可參考 [APS2 的 Datasheet] (PDF 格式)，這個貫徹 "Simple is Beauty" 理念的 processor 包含 register file 只有 7k gates，可達 250 MIPS，並且僅有 18uW/MHz 的低耗電量，同時也提供了 GNU Toolchain，此外 APS2 還做了 [cryptographic co-processor] (PDF 格式)，值得關注。

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

OSDC 2006 議程出爐

hcchien 在 #dot 告知，[OSDC (Open Source Developers' Conference] 2006 的議題已出爐，可參考 [OSDC::schedule]，真期待 :-)

我的 topic 是「從 Web Browser 與 3D 技術發展看未來桌面系統的挑戰」，而我的提案內容如下：

議程大綱則是：(暫定)

Internet 帶來的全球化「抹平」作用
淺談 Web Browser 設計與技術衝擊
在自由軟體系統架構下的 3D 解決方案
以 Web 為主體思考的桌面系統
大融合： Web + 3D + Desktop = ?
實驗性的技術與自由軟體為基礎的設計
展示

我會談談過去設計 [kBrowser] 的經驗，這些技術細節與非技術考量 (要不是因為開發 browser，我也不會去接觸中東語文，也不會去涉獵 bidi) 不見得比設計一個作業系統還簡單，同時也會參考 Mozilla、Konqueror (khtml)，以及 WebCore 等世界一流的 free / open source 實做，並以近來 3D Desktop/Living World 的突破為基礎，思考如何整合這些技術，提昇我們的使用體驗，當然，Just For Fun。

歡迎提供新點子，或預先討論指教，謝謝！

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

Jserv's blog

March 25, 2006