Jserv's blog

Qt 4.5 將允許增列 LGPL 2.1 條款發行

過去，Trolltech 的 Qt 一直是 dual-licensing 與 GPL 商業模式獲利的典範，而自從去年被 Nokia 收購後，進行許多調整，比方說 [Qtopia 再度更名為 "Qt Extended"]，而其商業模式也轉變中。過去以 GPL/QPL 發佈的 Qt，若僅取用函式庫的部份，因為 GPL 模式使然，建構於上的應用程式，往往「隱含」為 GNU GPL 授權，除非獲得官方許可或是軟體採用明確的隔離設計。但現在，這些限制即將解除，Nokia 即日宣佈，預定於 2009 年三月發佈的 Qt 4.5 版開始，將以 GNU LGPL 2.1 授權發佈其 Qt，詳情可參閱聲明稿 [LGPL License Option Added to Qt ]，重點是這段：

The move to LGPL licensing will provide open source and commercial developers with more permissive licensing than GPL and so increase flexibility for developers. In addition, Qt source code repositories will be made publicly available and will encourage contributions from desktop and embedded developer communities. With these changes, developers will be able to actively drive the evolution of the Qt framework.

向 LGPL 的轉移的舉動，將對開放原始碼軟體與衍生的商業應用，更加友善且具備彈性，鼓勵更多來自桌面和嵌入式開發人員社區的貢獻。相關的討論可見 KDE.NEWS [Qt Everywhere: 4.5 To Be Relicensed As LGPL]。

同時，Qt Software 的副總裁 Sebastian Nyström 在 blog [Nokia to license Qt under LGPL] 提及 Nokia 後續的開放動作，引述如下：

• Employing more Qt developers
• Opening our source code repository
• Reducing the overhead needed to make a submission, including no longer requiring copyright assignments.
• Launching a new web infrastructure to support contributions later this year.

看來的確一系列是令人振奮的訊息，至於為何採用 LGPL 2.1 版呢？他表示：

As a first step we have selected LGPL version 2.1 as this is the version of the LGPL that best fits our purposes and we are most comfortable with at this point in time. We will continue to evaluate the adoption, use and legal interpretation of LGPL version 3 by the community and may use this version of the LGPL for future releases.

開放 Qt repository (部份像是 QtWebKit 與 Qt Labs 的專案，已開放存取其 git / svn repository) 並採取更廣泛社群開發的模式，可說是 Nokia 在 Mobile/Embedded Linux 平台建立標準化所深耕的宣示，樂見其成。

libsslwrap : 通透地對網路傳輸加上 SSL 保護

最近研究網路傳輸的機制時，想到 Kenichi Kourai 教授在 2001 年設計過一個相當精巧的函式庫 [libsslwrap]，可通透地 (transparently) 對 TCP/IP 網路傳輸過程中，加上 SSL 安全連線的保護，更重要的是，不需要對原本的網路應用程式作原始程式碼修改、重新編譯等處理。libsslwrap 運用 UNIX/ELF 執行檔的動態連結機制，透過設定 LD_PRELOAD 環境變數，預先載入 libsslwrap 提供的函式庫，將原本的 connect, accept, write, read, send, recv 等系統呼叫，予以攔截轉包到支援 SSL 的實做，如此一來，即可達到通透處理的目標。

實務上，仍有一些限制，詳情可參閱原始程式套件中的 "README" 檔案，不過就一般的操作，應已足夠。本文將以 telnet 連線為例，說明 libsslwrap 的使用。首先，當然是編譯 libsslwrap，不過，要注意的是，原本的程式無法在 gcc-4.3 下編譯，所以筆者準備一個修正 [libsslwrap-gcc43-build.patch]，編譯的環境應該要有 OpenSSL 的開發套件，比方說 Debian/Ubuntu 的 libssl-dev 套件。為了方便後續的說明，給定筆者偏好的 PREFIX：

make PREFIX=/tmp/libsslwrap
make install

建構過程，程式會提醒您建立 SSL certification 資訊，依序填入即可。

既然要探討 telnet 連線，我們就該準備必要的套件，像是 telnet 與 telnetd，很容易地安裝：

# apt-get install telnet telnetd

透過 Wireshark 可視覺化地觀察網路封包的傳輸狀況，因為筆者的實做環境都在本地端 (localhost)，所以僅觀察 lo interface，如下圖所示：

在 "lo" 那一列按下 "Start" 按鈕，即可監控本地端的網路封包。telnetd (telnet daemon) 可透過 inetd 執行，假設系統啟動時已有 telnetd 服務，那麼我們直接透過 telnet 連線：

# telnet localhost

參考的終端機執行畫面如下：

telnet localhost
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Ubuntu jaunty (development branch)

後面就是要求登入的訊息，這裡忽略。上面的訊息中，"Ubuntu jaunty" 也就是筆者使用的環境 Ubuntu 9.04 的開發版本，代號為 "jaunty"。因為是明碼傳輸，所以我們可在 Wireshark 觀察往返的網路封包內容，如下圖所示：

上圖的下方視窗中，可見到 "Ubuntu jaunty" 的字樣出現於 Telnet Data，當然啦，繼續等待的話，還能見到登入的帳號與密碼內文，對於其他的網路傳輸協定，如 FTP，也有類似的情況，網路封包的內容一目了然。若系統無法更動為 SSH 或 SFTP (FTP over SSH) 的話，libsslwrap 就能派上用場。
咱們回頭看 libsslwrap。編譯 libsslwrap 後，應該可在 src/ 目錄見到 libsslwrap.so 這個動態函式庫被建立，並且在 make install 後，/tmp/libsslwrap/bin/ 目錄下多了一個名為 sslwrap 的 script，其內容相當單純，就是在執行程式前，透過 LD_PRELOAD 環境變數的設定，預先載入 libsslwrap.so。為了作比較，筆者在稍候即將啟動的 telnetd，要求透過不同的 port (預設 port number 為 22)，比方說 port 10023，這可透過 "-debug" 參數達成，也就是說，我們可以這樣啟動 telnet daemon：

# /tmp/libsslwrap/bin/sslwrap /usr/sbin/in.telnetd -debug 10023

當此行指令被執行後，終端機會輸出一個簡短的訊息："preload"，表示 libsslwrap.so 已成功將原本的 connect, accept, write, read, send, recv 等系統呼叫，予以攔截轉包到支援 SSL 的實做，一旦筆者嘗試連線，即可見其端倪。當然，既然 server 端透過 sslwrap 去執行，client 端也要，所以連線指令如下：

# /tmp/libsslwrap/bin/sslwrap telnet localhost 10023

表示欲透過 telnet 連線到 localhost 的 port 10023，此時，Wireshark 的封包就大異於之前純粹的 telnet 連線狀況，參考的輸出如下圖：

這過程包含了 SSL 的 cert 與通訊，以及 (轉包的) telnet 資料傳輸等動作，而封包內容也不再是人眼可識別的明碼了。這表示，libsslwrap 通透地對網路傳輸加上 SSL 保護，不失為一個解決方案。

OSDC.TW 2009 徵稿

一年一度的 [OSDC.tw] (Open Source Developers' Conference Taiwan) 研討會即將於四月份舉辦，最近密集徵稿中，詳情可參考 [官方網站的訊息]。日期訂於四月 18 與 19 兩日，舉辦的地點依然在台北，屆時也會有多元的議程。

稍早 hcchien 兄特別提醒這件事，這幾天終於有時間處理 (之前疑似被外星人綁架，所以...)，思考了投稿的議題，暫時規劃在系統層面與編譯技術。我們可見 compiler 技術的影響無所不在，無論是程式語言範疇、Web 應用程式，甚至是 OpenGL/3D，都潛藏著與 compiler 密不可分的關聯。乍看很難想像其關聯性，但回頭看看 JSP/Servlet 的運作，或者 OpenGL ARB 的 GLSL，或者當紅炸子雞 Google Android 平台，不難理解何以前述關鍵項目依賴著編譯技術，實在是解決工程問題所需的背景。

隨著開放源碼的蓬勃發展，Compiler Toolkit 也獲得空前的成功，並且當今的運算型態已變得多元，無論是虛擬化技術、VM、JIT (Just-In-Time) compiler，或者 Binary translator 等等，都是吾人耳熟能詳且為建構當今資訊建設的基礎技術。也因此，希望藉由這次的機會，分享小弟過去幾年的開發經驗，希望能和與會的朋友們一同成長。OSDC.tw 徵稿的截止日為 2009/1/31，請不要忘記了 :-)

CuRT - 精簡易懂的 RTOS - 釋出

貫徹「每年練習寫一個作業系統」的小目標，小弟今年準備小小的即時作業系統，作為 2009 年的見面禮，取名為 CuRT，全名是 "Compat Unicellular Real-Time operating system"，目標定於簡潔易懂，算是在 COSCUP 2007 發表的 [Jamei RTOS] 的精簡版本，以 Revised BSD license 釋出，原始程式碼在此：[curt-src-v1.tar.bz2]。

感謝 [WalkingIce] 為 CuRT 貢獻了美麗大方的 logo：

依據他的說法是：「因為短短的程式碼給了我很『輕』的感覺，所以在背景加上了一根羽毛」。以下是 CuRT 的特徵：

• Preemptive Multi-threading
• Priority-base Round-Robin Scheduling
• Simple Threading
• Semaphore Support
• IPC: mailbox, message queue

支援 ARM 的硬體平台，編譯之後，作業系統加上範例程式碼僅有十幾 kb 的空間。同時，希望藉由這個具體而微的 RTOS，能否協助有心探索系統程式設計者理解 ARM 整個架構進而可掌握其精神，也是 CuRT 的設計背景。

今年的規劃來看，會舉辦至少一場針對 ARM microarchitecture 為主題的的免費教育訓練，探討如何從零到有設計完整的作業系統、如何進行必要的系統初始化、如何動手理解 ARM 的種種關鍵設計，而 CuRT 就是其中的教材。請多指教，謝謝！