今天瀏覽 developerWorks 時，看到了一篇文章《Emulation and computing history》介紹「The Computer History Simulation Project 」，簡稱SIMH。 我覺得 SIMH 很有趣。它是一套可以模擬其他計算機硬體架構的軟體，我們可以透過模擬器執行運作在其他計算機硬體架構的軟體。

我沒拍照。不過 my-hiend 網站有許多精彩照片，可自行觀賞: 2011年高雄國際Hi-End音響大展實況報導。 我在寫這篇記事時，也是一邊看那些照片，一邊回憶我的感想。

講座篇

我去聽了三場數位流講座，其中19日的兩場牽涉到數位技術方面的知識。

我手上有一台無硬碟式精簡電腦 (Atrust t100)，是廠商數年前給公司的工程樣機。 規格挺舊的(VIA Nano CPU)，但上面沒有任何風扇，也沒有硬碟，運作時很安靜。 所以我試著用它啟動 Ubuntu Studio ，接上我的 USB DAC (NuForce Icon Mobile)。

Make an Ubuntu Studio system on USB/SD disk.

日前我做了一項大量資料計算效能評測工作。 評測內容是多行程(multi-processing)與多線程模式(multi-threading)的效能差異。

根據程式內部的資料計算方式內容，從理論與個人經驗，我直覺預期這項評測的多行程模式的效能會比較高。 有趣的是，公司同事(或者說多數資訊人員)則是習慣性地認為多線程模式的效能比較高。

在 Unix 世界中，系統管理者普遍會用 shell script 撰寫簡單的管理工具。 為了強化易用性，簡化 shell script 的撰寫工作，就出現了專門負責提供圖形式互動元件的小工具， 可供我們在 shell script 中調用。 讓它們處理複雜的使用者輸入工作，同時也提高了 shell script 的使用親和力。

本文提供其中兩種工具的使用範例。

• 一、文字終端機環境: dialog。 非 Ubuntu 預裝項目。
• 二、GNOME桌面環境: zenity。 這是 GNOME Desktop 計劃下的一個小工具。為 Ubuntu 桌面版本預裝項目，Ubuntu 桌面版都會安裝此套件。

HTML5 規劃了一組支援本地文件(客戶端文件)讀取的函數介面，即 File API。 透過 File API ，我們可以直接在瀏覽器中讀取客戶端的文件，而不需要先將檔案回傳到伺服端暫存後再讓瀏覽器取回顯示。

本文將設計兩個文件閱讀工具示範 File API 的用法。 整個工作僅需在瀏覽器(客戶端)使用 JavaScript 即可達成，完全不需要任何資料上傳到伺服端的工作。

前往 IE6 Countdown ，一起為 IE6 送終。

癮科技: 微軟: 是朋友就不該讓朋友用 IE6

ZDNet: Microsoft: Friends don't let friends use Internet Explorer 6

我寫Web應用程式超過十年了，個人和 IE6 之間的關係可說是苦大仇深、誓不兩立。難得微軟發起了這麼一項有意義的活動，我不推一下就太對不起我自己了。

我去年在部落格上寫了一篇《歐盟和 Google 先後以政治手段解決了 IE6》。在文中有提到，國內阻礙 IE6 死亡的最大阻力其實就在政府機關。希望微軟出手後，能讓我們徹底擺脫 IE6 的陰影。

繼小紅點(TrackPoint)讓我玩上癮之後，我又對另一種不常見的指標設備 — 軌跡球 — 感到興趣了。 昨天終於弄了一個價格合宜的羅技木星軌跡球(Logitech Trackman Marble)來玩，台幣約在680元左右。

包裝中附有 Windows 與 MacOS 的驅動程式。在 Windows 上的使用方式不必多講了。 我來說說在 Ubuntu 10.04 上使用這隻軌跡球的經驗吧。

我從一位 Linux 程序員的角度來看 MeeGo, WebOS, Android 之間的差異。 這三套作業系統同樣基於 Linux 核心並支援 ARM 架構。 寫下這篇筆記，提供想要進入它們的軟體發展領域的程序員參考。 如有不同看法，歡迎討論。

前幾天在網拍上買了一隻 IBM Space Saver II 鍵盤。 雖然它似乎已經有10年歷史了，但功能仍然很正常，最重要的小紅點(TrackPoint)依然可以使用。 我現在把它放在公司使用，寫程式時雙手完全不必離開鍵盤，真的很方便。 滑鼠已經被我扔到一邊去了。

全照圖與 TrackPoint 特寫。

PHP 很早就已經支援 GNU gettext 的國際化模組。在線上手冊與網路上也可以找到許多相關的討論文章。 但是部份內容沒有完善地理解區碼的設定方式，以至於程序員在 LANG 和 setlocale() 的問題之中糾纏不休。

本文首先將說明區碼的設定問題，再示範 gettext 的使用方式。

Vala 作為 GNOME 開發環境下新興的開發語言，帶入了許多新的功能，其中亦包含國際化(i18n)的支援項目。 儘管 Vala 的線上教學文件沒有隻字片語提到 i18n/l10n，但事實上 Vala 已經將 GNU gettext 作為內建的語言功能，使用它實現 i18n/l10n 能力。 Vala 提供了名為 _ 的函數，只要我們的 vala 程式碼使用了 _() 函數，就會使用 GNU gettext 取得本地訊息。

但是現階段使用這個內建功能時，還有一個文件未記載的不完善之處必須解決。待我說來。

我這陣子上班時，會邊吃早餐邊看癮科技網站，那裡的科技新聞提供我不少樂子。在他們前陣子報導的 CES 2011 新聞中，我看到 Motorola Atrix 和 WebOS 揭示了一些有趣的想法。

關於 Motorola Atrix 的兩則新聞:

• Motorola Atrix 4G、HD 多媒體座充和筆電座動手玩
• Motorola Atrix 再次試玩

關於 WebOS 的兩則新聞:

• WebOS也玩大了，智慧手機、平板以外，小筆電也加入行列
• WebOS新框架Enyo是專為平板與"大手機"打造的

日前公司同事接觸了 CouchDB, MongoDB 這幾套標榜 NoSQL 的資料庫系統。還有江湖傳言道：「RDBMS 落伍了，以後要用 NoSQL 資料庫」。這就在公司內引起了一場討論，到底 RDBMS 是不是落伍了。就我個人觀點，CouchDB, MongoDB 確實很有用，但要說 RDBMS 落伍了，我卻不以為然。

就我所見，NoSQL 其實是資料庫使用觀念的復古運動、正確觀念的復興運動。

我今天看到《Android source code, Java, and copyright infringement: what's going on?》(中譯版)的新聞。心頭一驚，這還真是個大新聞。於是多花了些時間把相關的討論文章都看過。內容很多，但法律焦點其實只有一個，我稍候解釋。我先說我的結論吧。我的結論是：Google 錯了。

今天看了《Create offline Web applications on mobile devices with HTML5》，講授 HTML5 的離線儲存功能。由於它使用的是 W3C WebDatabase 功能，於是我又去看了該規範文件。結果看到規範文件的開頭用顯眼的黑底框寫著注意事項，宣告 WebDatabase 不再維護了。

停止理由是各家廠商目前在實作這個規格時，底層的實體儲存項目都是 Sqlite，走向一條死胡同。W3C 則是希望有多樣化且獨立的實現途徑。

雙授權模式(dual-licensing)軟體是指一套電腦軟體，它提供了兩種不同授權模式供使用者選擇。實際上，也有些軟體提供了三種甚至三種以上可選擇的授權模式。是以我們統稱為「多授權模式」(Multi-licensing)。在解釋時要特別注意一點，多授權模式係指提供多種授權內容讓使用者擇一使用，並非多種內容同時授權。故中文說明時，不宜使用「雙重授權模式」或「多重授權模式」，因其授權內容並未重合。

我先前寫了一篇《VirtualBox有多種授權區分，企業使用並未免費》，說明 VirtualBox 有多授權模式，提醒公司的IT人員注意。那篇文章中說明的資訊有些過時了。現在 VirtualBox 3 已經開始提供 GPL 授權證給使用者選擇，此授權模式版本的官方正方稱呼為 VirtualBox Open Source Edition (OSE)。只是現在對客戶說明時也比較麻煩。因為客戶有時並不能理解「 VirtualBox 不等於 VirtualBox OSE」。

每年年底，總是有人問我某某電腦產品要怎麼選之類的問題。今年被問到 LCD 的事。說到 LCD ，我就有種不吐不快的感覺。我在兩年前買第一台 LCD 時，就留下一篇文章抱怨台灣沒有平價好貨的 LCD。兩年後，這句話依然適用。

那些向我請教如何選擇 LCD 的親友，我心中的惡魔都在冷笑：「有差嗎？賣場裡的貨色都一樣爛，同規格的挑最便宜的最划算」。 當然啦，我這個人還是有良心的，不會這麼直接地用一句話打發對方。基本上，我還是有一張選購速查表。

當我在 Python 中結合 multiprocessing.Pipe、multiprocessing.Process 與 signal 模組進行傳統的多工行程設計時，我注意到被擱置的管道資料讀取方法(read)，在沒有取得資料的情形下就返回。使得父、子行程之間的互動過程不如預期。錯誤訊息顯示，讀取方法被系統中斷了(Interrupted system call)。read, signal, interrupted system call 這三個關鍵資訊，讓我直覺聯想到我碰到 EINTR 這個狀況了。當我在錯誤處理的流程中增加 errno 的判斷動作之後，我確認這就是 EINTR 狀況。

一位使用過 C 語言撰寫多工行程程式的程序員，對 EINTR 這件事絕不陌生。只是我未料想到會在 Python 之中再度碰到這位老朋友。對於這位老朋友，我們的招待原則請看《多工作業下的資料讀寫處理事項 - read()/write() 被 signal 中斷的處理 》。那篇處理事項中，提到 C 語言要準備兩招應付 EINTR 狀況。不過使用 Python 時則只需要第一招：如果錯誤是因為被 signal 中斷的話，就再讀一次，如果是其他原因導致的錯誤，則視為致命錯誤，應該中止程式繼續。