January 26, 2008
「快快樂樂學 GNU Debugger」簡報上線
今天應 [酷！學園] 的邀請，前往台南，給予主題為 [快快樂樂學 GNU Debugger (gdb)] 的演講，感謝雨蒼、鳥哥、崑山科大，以及各位撥空前來指教的朋友們，簡報已上線，可參考 [HappyGDB-PartI-2008-01-26.pdf] 以及對應的範例程式碼 [gdb-samples-2008-01-26.tar.bz2]。經過初步的重整，本議程預計拆成三個部份：- Part I - 概念與初體驗
- Part II - 實務與應用探討
- Part III - GDB 技巧與整合性技術
- Debug 類型
- Linux 的工具集合
- 系統提供之偵錯機制
- GDB 初體驗
以上，請多指教，謝謝！後續的議程規劃，也在商議中。
January 23, 2008
「Linux 為基礎的嵌入式與即時多工系統」簡報上線
上週應某單位之邀，給予一份關於 Linux 為基礎的嵌入式 與即時系統的演講，不過因為該單位的性質，所以主要的重心還是擺在 soft/hard Real-time Linux，大綱如下：- 嵌入式平台的思維
- 解決方案探討分析
- Linux 遇上即時系統 :How and Why?
January 22, 2008
SunPinYin 引擎改以 CDDL / LGPL 2.1 雙重授權
去年提過的 [開放原始碼的 SunPinYin 引擎]，是個基於統計語言模型 (statistical language model, SLM) 的智能拼音引擎，當時的授權以 Sun CDDL (Common Development and Distribution License) 發行，現在正式改以 CDDL / LGPL 2.1 雙重授權方式，詳情可見 Yong Sun 兄的 blog [We announced the dual-licensing of SunPinyin in CDDL and LGPLv2.1] 與 OpenSolaris 官方聲明 [Sun is releasing SunPinyin's source code under a dual-licensing scheme of CDDL and LGPLv2.1]雖然 Sun Microsystems 有心貢獻此等高品質的程式碼到開發社群，但採用 CDDL 卻讓許多整合應用或實務面遇到了許多困難。比方說，lexicall 兄已經著手研究分析 Sun PinYin 引擎整合到 [新酷音輸入法] 的可能性，但首先面對的問題就是，授權條款的不相容，而且依據現在的架構設計，是沒得解決的。然而，現在終於有轉機了，Sun 對此採取雙重授權，所以，倘若要整合 SunPinyin 引擎的話，libchewing 仍可保持 LGPL 授權，這的確是非常鼓舞人心的訊息。
另外，SunPinyin 也被移植到 BeOS/Haiku 作業系統下，詳情可參考 [SunPinyin running on BeOS!]，所以現在除了 IIIMF 與 SCIM 輸入法框架的支援外，還多了 [BeOS/Haiku 的 Input Method Framework]，而且看來可用性都算不錯。
January 21, 2008
「開放源碼的第五項修煉：淺談社群經營與商業應用」簡報上線
上週應某單位的邀約，給予一份關於經營自由軟體社群並作商業應用的演講，議程簡介如下：-
管理學大師彼得．聖吉的代表作《第五項修煉》，被譽為廿一世紀的管理聖經，許多美國知名的企業都非常推崇書中的學習型組織概念，而對更加虛無飄渺的自由軟體
/ 開放源碼社群來說，如何經營並拓廣商業應用，已是刻不容緩的議題。本議程以「第五項修煉」的核心價值分析現有自由軟體專案，並以自身經驗歸納其藝術與實務面。
- 自由軟體 / 開放源碼本質：處於虛幻與現實的緩衝帶的社群
- 經營：管理與完全放任的一線之隔
- 君子愛財取之有道：商業化途徑
January 20, 2008
深入理解 Linux 2.6 的 initramfs 機制 (上)
日前結束一個消費性電子產品的開發工作，稍有心得，試著整理採取 Linux kernel 2.6 initramfs 機制以加速系統開發的經驗，同時也談論對 fast-booting 設計的重要性，順便解決某些像是「kinit/klibc 為何被提出？」等疑難雜症。進入主題前，先看看所謂的 booting。相傳在十八世紀，德國 Baron Münchhausen 男爵常誇大吹噓自己的英勇事蹟，其中一項是「拉著自己的頭髮，將自己從受陷的沼澤中提起」，此事後來收錄於德國《吹牛大王歷險記》，則改寫為「用拔靴帶把自己從海中拉起來」，這裡的「拔靴帶」(bootstrap) 指的是長統靴靴筒頂端後方的小環帶，是用以輔助穿長統靴。這種有違物理原理的誇大動作，卻讓不同領域的人們獲得靈感，Robert A. Heinlein 發表於 1941 年的短文〈By His Bootstraps〉收錄典故並給予多種延伸想法；滑鼠發明人 Doug Engelbart 博士甚至在 1989 年以此命名其研究機構「Bootstrap 學院」，並擔任該院主任。在商業上，bootstrapping 則被引申為一種創業模式，也就是初期投入少量的啟動資本，然後在創業過程中主要依靠從客戶得來的銷售收入，形成一個良好的正現金流。在電腦資訊領域，因為開機過程是環環相扣，先透過簡單的程式讀入記憶體，執行後又載入更多磁區、程式碼來執行，直到作業系統完全載入為止，所以開機過程也被稱為 bootstrapping，簡稱 "boot"。
自 1991 年 Linux 問世以來，資訊技術的應用有了極大的轉變，筆者之前的文章 [探索 Linux bootloader 的佳作] 與 [kboot 初探與模擬驗證] 約略提及光是開機本身的設計來說，就有多種衝擊與需求，隨著 Linux 走出個人電腦領域，在嵌入式系統應用上，更是五花八門。本文所探討的 initramfs，衍生自 Linux kernel 的 initrd，理解其設計需求是先行的準備。initrd 字面上的意思就是 "boot loader initialized RAM disk"，換言之，這是一塊特殊的 RAM disk，在載入 Linux kernel 前，由 boot loader 予以初始化，具體動作就是從特定的儲存裝置中載入 initrd 到 RAM 中 (由啟動參數 "initrd=" 指定 image 的實體或邏輯位置)，隨後 linux kernel 被載入並執行時，會優先處理置放 initrd 的記憶體空間，而這個空間基本上也有檔案系統，通常會包含 init 等程式，故可用以掛入某些特別的驅動程式，比方說 SCSI，完成階段性目標後，kernel 會將真正的 root file system 掛載，並執行 /sbin/init 程式。
話說回來，我們為何需要此等迂迴的開機途徑呢？原因是，root file system (由啟動參數 "root=" 所指定，以下簡稱 rootfs) 所在的儲存裝置很可能極難尋找，比方說 SCSI 裝置就需要複雜且耗時的程序，若用 RAID 系統更是需要看配置情況而定，同樣的問題也發生在 USB storage 上，因為 kernel 得花上更長的等待與配置時間，或說遠端掛載 rootfs，不僅得處理網路裝置的問題，甚至還得考慮相關的伺服器認證、通訊往返時間等議題。更重要的是，我們可在 initrd 放置某些特別的程式，一來作為掛載 rootfs 作準備，比方說硬體初始化、解密、解壓縮等等，二來提示使用者或系統管理員目前的狀態，這對於消費性電子產品來說，有很大的意義。整體來說，如果能增加開機的彈性 (比方說配合簡單的 shell script 即可達成 USB/SCSI 初始化動作，若透過 kernel code 實做，恐怕上百千行是免不掉的)，又能適度降低 kernel image 本身的設計複雜度與空間使用量，採取 initrd 是很不錯的方式，所以幾乎各大 Linux distribution 都有提供 initrd，以解決在不同硬體、不同裝置上開機的技術議題，也能確保一片 CD-ROM/DVD 可裝入多種個人電腦系統，也可支援 [bootsplash] 一類顯示開機動畫的程式。
具體來說，initrd 提供了「兩階段開機」程序。首先，一切都還是在 kernel mode，由 kernel 完成與硬體相關的初始化工作，接著，在適當的時機點，當 kernel 讀取並掛載 initrd 所在記憶體空間的檔案系統後，kernel 首次從 kernel space 切入 user space，以執行存放於 RAM disk 中的 init 程式，當然，這需要完整的執行環境 (比方說 C runtime 或必要的 program loader 等)，另外，也得確定 rootfs 可被 kernel 所找到並正確掛載。待第一階段的 initrd 步入尾聲後，再回到 kernel mode，initrd 所在的記憶體空間也會適度被釋放 (依據組態而定)，這才進入第二階段，也就是執行真正的 rootfs 中的 init 程式。在 Linux kernel 2.4 中，initrd 大致的處理流程如下：(方括號表示主要的執行單元)
- [boot loader] Boot loader 依據預先設定的條件，將 kernel 與 initrd 這兩個 image 載入到 RAM
- [boot loader -> kernel] 完成必要的動作後，準備將執行權交給 Linux kernel
- [kernel] 進行一系列初始化動作，initrd 所在的記憶體被 kernel 對應為 /dev/initrd 裝置設備，透過 kernel 內部的 decompressor (gzip 解壓縮) 解開該內容並複製到 /dev/ram0 裝置設備上
- [kernel] Linux 以 R/W (可讀寫) 模式將 /dev/ram0 掛載為暫時性的 rootfs
- [kernel-space -> user-space] kernel 準備執行 /dev/ram0 上的 /linuxrc 程式，並切換執行流程
- [user space] /linuxrc 與相關的程式處理特定的操作，比方說準備掛載 rootfs 等
- [user-space -> kernel-space] /linuxrc 執行即將完畢，執行權轉交給 kernel
- [kernel] Linux 掛載真正的 rootfs 並執行 /sbin/init 程式
- [user space] 依據 Linux distribution 規範的流程，執行各式系統與應用程式
Linux Kernel 的發展文化就是願意捨棄既有實做，大膽採用新的途徑 (在符合國際規格的前提下)，Linux 2.6 的 initramfs 之所以提出，就是要修正 initrd 的種種技術問題。問題在哪呢？首先，回顧剛剛探討的流程，initrd RAM disk 對 kernel 來說，本身是個真實的 block device，為了建構存放其中的檔案 (最起碼要有 /linuxrc)，通常我們需要 ext2 一類的檔案系統 (建議)。所以，就建構如此的 initrd image 來看，通常會透過 mkfs.ext2 與 losetup (功能："set up and control loop devices") 等工具建立 loopback device 並編修，所以自然需面對以下問題：
- initrd 必須綁定某個檔案系統實做，如 ext2，可是多數的情況下，我們根本不需要在此階段擁有完整的實做
- /dev/initrd block device 建構時即有空間限制，維護繁瑣
- 運作於 initrd 階段，檔案操作實際上是不斷將 /dev/initrd (對應於某段記憶體) 對應到可存取檔案系統的記憶位址，做了不必要的資源消耗
-
Another reason ramdisks are semi-obsolete is that the introduction of
loopback devices offered a more flexible and convenient way to create
synthetic block devices, now from files instead of from chunks of memory.
回到 initrd ramdisk，事實上，原本的設計甚至更加浪費記憶體，因為 Linux 在設計上就會盡可能將讀入/寫入自 block device 的檔案或目錄予以 cache，所以，Linux 會自 ramdisk 中複製資料到 page cache 與 dentry cache，如此往返，徒增資源使用的浪費，這一切問題的根源就是將 initrd 以 block device 來操作的本質使然。Linus Torvalds 為此提出一個想法：
-
能否將這些 cache 被掛載為檔案系統呢？就在 cache 中保持這些檔案，但不清除這些，直到實際上被刪去或者系統重啟。
| initrd | initramfs | |
|---|---|---|
| Image | 壓縮過的檔案系統 (如 ext2 + gzip) | 封裝過的檔案 (cpio + gzip) |
| 實做途徑 | block device (RAM disk) | tmpfs |
| 首先執行的程式 | /linuxrc | /init |
| 掛載 rootfs 方式 |
將欲載入的 rootfs 掛載於某個目錄，再 pivot_root 切換 rootfs | 使用 switch_root |
前面的段落已說明這兩者對於記憶體存取與檔案操作的落差，同時也提及實做途徑，接下來的重點是這兩者如何看待真正的 rootfs。如同前述所及，Linux kernel 2.4 中，initrd 可被視為起始參數 "root=" 的先前處理機制，透過一系列的程序，協助 kernel 找到最終的 rootfs，並一舉掛載進系統，不過，過去的設計其實做了一個假設：「真正的 rootfs 所在的裝置是 block device，同時 initrd 絕非是真正的 rootfs」，這也是為何要讓 kernel 在第一次準備切入 user-space 時，是執行 /linuxrc，而非 /init 或 /sbin/init，因為後者的 PID 恆為 1 且不可被 kill (終止)，但前者因為只是過度的存在，隨時仍可被 kill。
而在 Linux 2.6 引入 initramfs 的設計後，上述彆扭的假設與處理方式就不復存在，不再區隔「真正」的 rootfs 是如何「存在」，也就是一開機，kernel 就執行位於 initramfs 中的 /init，作為 PID=1 的 init process，僅以 switch_root 作 rootfs 的重新定位罷了 (選擇性)。正因為這樣的特性，核心開發者也將 initramfs 的行為稱為 [Early User Space]，Jeff Garzik 於 2002 年十一月發表於 lkml 的文章 [initramfs merge, part 1 of N] 提到他的願景：
-
The Future.
Early userspace is going to be merged in a series of evolutionary changes, following what I call "The Al Viro model." NO KERNEL BEHAVIOR SHOULD CHANGE. [that's for the lkml listeners, not you
基於 initramfs / Early userspace 的想法，核心開發者又思考為何不將過去難以有效維護但又非得存在不可的程式碼，比方說 do_mount 這一類用以實做掛載特定裝置或邏輯儲存設備的功能，全面轉交給 user-space 的程式去執行呢？這樣 kernel 可專心提昇功能或者效能的改進。為此，以 H. Peter Anvin 為首的核心開發者引入 [klibc] 與 kinit，前者 (至少目標上) 是最小的 C library 實做，用來支持後者所需 (定位與 [dietlibc] 或 [uclibc] 一類精巧但通用性的 libc 實做不同)，而 kinit 就是將前述原本在核心實做的程式 (很難偵錯且分析的 kernel code) 拉出到 user-space 中，他於 2006 年六月提交的 patch [kinit: replacement for in-kernel do_mount, ipconfig, nfsroot] 就展現了將不同的檔案系統 (cramfs, ext2, ext3, jfs, lvm2, minixfs, reiserfs, romfs, xfs, ...) 予以掛載 (即 user-space 的 do_mount)、ipconfig (bootp, dhcp)、nfsmount 等等，整合到 kinit 程式中一併處理，kernel image 可因此大幅縮減。
大致理解 initramfs 的原理與定位後，我們就可以探討實做與相關的細節。筆者的測試環境是 IBM/lenovo X60 筆記型電腦 (Intel Centrino Duo 1.83GHz) 加上 Ubuntu Linux 7.10，進行下述實做過程之前，請先自 [kernel.org] 取得 stable kernel，本文採用 "linux-2.6.22.5"，所需的套件有：
- build-essential
- qemu
- ruby
$ cd /home/jserv/initramfs-workspace $ tar jxvf $HOME/sources/linux-2.6.22.5.tar.bz2 $ mkdir -p hello-initramfs首先設立的目標是，可印出 "Hello World" 的 kernel + initramfs，並透過 qemu 進行模擬驗證。首先，建立一個 init.c，具備簡單的實做：
$ cd hello-initramfs
$ cat init.c
#include <stdio.h>
int main()
{
printf("Hello World!\n");
sleep(99999);
return 0;
}
$ gcc -static -o init init.c
$ mkdir -p dev
$ sudo mknod dev/console c 5 1
建議先試著執行 "./init" 看看是否正確運作，程式碼中的 "sleep(99999)" 只是讓觀察更容易，避免畫面一閃而逝。剛剛的 "Hello World" 程式就是我們預期的 Early userspace，因為執行時期需要 tty (terminal)，所以剛剛也一併建立 /dev/console 的 character device。現在我們可以來準備建構 kernel 了：$ cd /home/jserv/initramfs-workspace/linux-2.6.22.5 $ make menuconfig要注意的是，需將 "General setup" 的子項目 "Initial RAM filesystem and RAM disk (initramfs/initrd) suppot" 打開，並在下方提示 "INITRAMFS_SOURCE" 的畫面輸入我們期望的 initramfs 的來源目錄，也就是 "/home/jserv/initramfs-workspace/hello-initramfs"，參考的配置畫面如下：
也可以參考筆者的組態檔 [.config]，當然之後就是建構核心：
$ make bzImage ... LD arch/i386/boot/compressed/vmlinux OBJCOPY arch/i386/boot/vmlinux.bin HOSTCC arch/i386/boot/tools/build BUILD arch/i386/boot/bzImage Kernel: arch/i386/boot/bzImage is ready建構成功，透過 qemu 來模擬測試：
$ qemu -kernel arch/i386/boot/bzImage -hda /dev/zero參考的執行畫面如下：
scripts/kconfig/conf -s arch/i386/Kconfig CHK include/linux/version.h CHK include/linux/utsrelease.h CC arch/i386/kernel/asm-offsets.s GEN include/asm-i386/asm-offsets.h ... CC init/initramfs.o CC init/calibrate.o LD init/built-in.o HOSTCC usr/gen_init_cpio GEN usr/initramfs_data.cpio.gz AS usr/initramfs_data.o ...我們可注意到 "GEN usr/initramfs_data.cpio.gz" 這行，勢必 kernel 2.6 中隱含了某種機制，執行看看之前產生的工具程式：
$ usr/gen_init_cpio Usage: usr/gen_init_cpio <cpio_list> <cpio_list> is a file containing newline separated entries that describe the files to be included in the initramfs archive: ...這裡提到的 "archive" 就是透過 [cpio] 工具產生的封裝檔案，在 RedHat .rpm 或 Debian .deb 均有採用此工具。不過 Linux kernel 則提供一個整合性的工具，可一次處理目錄與檔案的封裝，依據之前的流程試試看手動建立 cpio + gzip：
$ cd /home/jserv/initramfs-workspace
$ sudo cp -af hello-initramfs hello2-initramfs
$ cd hello2-initramfs
$ cat init.c
#include <stdio.h>
int main()
{
printf("Yat Another Hello World!\n");
sleep(999999);
return 0;
}
$ gcc -static -o init init.c
$ cat desc_initramfs
dir /dev 0755 0 0
nod /dev/console 0600 0 0 c 5 1
file /init /home/jserv/initramfs-workspace/hello2-initramfs/init 0755 0 0
$ ../linux-2.6.22.5/usr/gen_init_cpio desc_initramfs > my_initramfs.cpio
$ gzip my_initramfs.cpio
"desc_initramfs" 是我們自己寫的描述檔，格式大抵就如上面展示，usr/gen_init_cpio 這個工具則會建構對應的 dir + device node + file 的封裝，最後我們以 gzip 壓縮起來，於是可得到 "my_initramfs.cpio.gz" 這個新的 initramfs image。同樣的，我們可用 qemu 測試驗證，這次改由 qemu 模擬 boot loader 指定 initramfs image 的模式，操作如下：$ cd /home/jserv/initramfs-workspace/linux-2.6.22.5 qemu -kernel arch/i386/boot/bzImage -initrd ../hello2-initramfs/my_initramfs.cpio.gz -hda /dev/zero這次應該就會在 qemu 模擬的輸出畫面最下方看到 "Yat Another Hello World!" 的字樣。
只有 "Hello World" 一類的程式只能作切入點，還不能實際作點事情，從零到有建構 rootfs 也得花上一點功夫，還好，Ubuntu/Debian 已經提供靜態連結的 [BusyBox]，安裝方式很簡單：
$ sudo apt-get install busybox-static隨後，系統會安裝 /bin/busybox 的執行檔，觀察一下：
$ file /bin/busybox /bin/busybox: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.8, statically linked, stripped咱們就以此為基礎，建立一個小而美的 initramfs + kernel image：
$ cd /home/jserv/initramfs-workspace
$ mkdir -p busybox-initramfs/bin
$ mkdir -p busybox-initramfs/proc
$ cd busybox-initramfs/bin
$ cp /bin/busybox .
$ ./busybox --help | ruby -e 'STDIN.read.split(/functions:$/m)[1].split(/,/).each{|i|`ln -s busybox #{i.strip}` unless i=~/busybox/}'
$ cd ..
$ echo -e '#!/bin/busybox sh\nmount -t proc proc /proc\nexec busybox sh\n' > init ; chmod +x init
$ find . | cpio -o -H newc | gzip > ../busybox.initramfs.cpio.gz
可看到 $HOME/initramfs-workspace 就輸出了名為 busybox.initramfs.cpio.gz 的 initramfs image，可仿造上一個範例，透過 qemu 模擬：$ cd /home/jserv/initramfs-workspace/linux-2.6.22.5 qemu -kernel arch/i386/boot/bzImage -initrd ../busybox.initramfs.cpio.gz -hda /dev/zero參考的執行畫面如下：
後續的篇幅，我們會探討實務上如何應用，如 Ubuntu 的 software suspend/resume image 與 fast-booting 整合，以及 kernel 的實做細節。
January 15, 2008
以 GtkWave 作視覺化分析
評量一個 RTOS 的效能有很多方式，其中有個重點是分析 latency。依據系統性質的不同，我們會探討 interrupt、context switching、critical section 等等事件的具體運作細節，設計良好的 RTOS 應要提供特定的機制，允許作遠端的紀錄與分析，我們可借助 gdb remote debugging 既有的機制，將 commands/responses 序列作定性分析。當然，如能視覺化會是更好，可透過發展成熟的 [GTKWave] 軟體來協助。GTKWave 是個以 Gtk+ 撰寫的波形瀏覽追蹤工具，能自波形的傅立葉轉換來作分析與視覺化，並支持 Verilog VCD/EVCD 檔案格式，所以上述的 gdb commands/responses 只要能轉化為標準 Verilog VCD 格式，就可作為輸入並視覺化，以 Jamei RTOS i386 開發平台為例，結果如下：
對了，[GTKWave] 以 GNU GPL 授權發行。
一萬個重作的理由
最近又開始閉關作些有趣的專案，在確認經濟條件不虞匱乏後，應可安心作上一段時間。著眼於 [2008 年度計畫]，今年的範疇不再只是基於現有的 free software 作客製化與優化，也有基於對現有架構和設計理念的不滿，另起爐灶的新計畫，比方說，去年提及的 [Jamei RTOS] 就是一例，這幾個月做了大幅翻修，未來可望整合到 RT nanokernel 架構中。光是浮上檯面的 RTOS 就好幾十個，更別說那種名不見經傳的項目，至於為什麼要重作呢？在一群 NetBSD hacker 發起的 [PEACE] 計畫中，TAMURA Kent 在簡報提到，目標為在 NetBSD 建構執行 Win32 PE 執行檔的環境的 [PEACE] 專案，為何不直接採用知名的 [Wine] 呢？他用一句很妙的話回覆：
-
"Existing software don’t prevent us from developing new software for the same purpose."
- It is not bad to exist different implementations.
- JUST FOR FUN! We’re enjoying development.
January 09, 2008
演講：快快樂樂學 GNU Debugger (gdb)
應 [Study Area] 之邀，月底將在台南分享關於 GNU/Linux 與 toolchain 相關的議題，本次演講主題為「快快樂樂學 GNU Debugger (gdb)」，以下引述討論區訊息 [2008一月份 SA@Tainan 快快樂樂學 GNU Debugger (gdb)]：- 簡介：
-
兩年前，為了徹底理解 GNU/Linux 底層運作機制，拿最簡單的 "Hello World" 開刀，部份心得匯集為「深入淺出Hello World」，並於北中南等地分享，計有 Part I / II / III。後續的規劃則因為大量使用 gdb / kdb /kgdb 等重要工具，決定以獨立的議程作講解，期望使聽者得以透過 GNU Debugger (gdb)來加速系統開發與分析，讓這個臥在硬碟深處許久的強力程式，激發其威力。本議程捨棄過往教條式的介紹形式，延續「深入淺出 HelloWorld」系列的「作中學」途徑逐一探討使用情境與案例分析。
- 議程主題：
- Why - 為何我們該善用 Debugger？
- Who - 誰會因為熟悉 Debugger 而受益？
- What - 史上最強大的 Debugger -- gdb 與一系列系統軟體
- Where - 利用 Debugger 的場合
- How - 還用說嗎？來就對了
- 時間：1月26日14:00-17:00
- 地點：
- 參考資訊：
- 講師特別交代之注意事項：
- 本議程基於知識共享之原則，提供免費教育訓練，但僅限於 x86 硬體平台，若有 ARM 與 MIPS 平台需求者，請進一步聯繫講者
- 礙於講者個人規劃，暫無舉辦台北場次的打算，請見諒
- 事先提交問題，可優先解決與討論
- 歡迎招待當地名產，或廣結善緣
展望 2008
連續兩日未眠，debug 某個複雜的系統，終於體力透支而休息暫緩，醒來已是夜間。過了二十五歲，生理機能即往下坡，復以如此操勞，很明顯察覺五臟六腑集體罷工的無力感，無奈靈感湧上，又苦苦無予以實現，心有不甘。蹉跎歲月至今，竟然邁入 2008 年，心中甚是惶恐。四年前剛上來台北時，手頭有許多專案或產品設計就是著眼於 2008 年。令人欣慰的是，自己直接或間接投入的項目，有幾個正磨刀霍霍，將於今年在市場上現身，想到當年雇主與合作對象皆再三強調產品在 2008 年「卡位」的重要性，而現在正是驗證理念的時機，不過，這也讓我不得不認真思索下一步。想到的第一個大方向大概是離開台北，換言之，相當於改變生活環境與工作模式，為此，必須盡快將手頭的工作結案，該放下的，也得適時放下，之後會逐漸移往中南部。
第二個方向是進修，不過不是回學校唸書 (時機未到)，主要是硬體設計與電磁輻射相關的範疇，稍早設計機器人時即已面臨種種挑戰，今年應該更努力投入。第三是檢視現有的技術領域：
- RTOS / RT nanokernel
- Linux Desktop and Graphics
- NetBSD embedded and RT extension
- Virtualization / Dynamic Binary Optimization
- Platform-based Computing
- 「深入淺出 Hello World」系列演講：踏入 kernel 與 application 互動的美妙世界
- GNU Toolchain：不只是使用，更要藉此深入 hacking
- 視訊壓縮技術與 MPEG 系列標準，並討論專利對於自由軟體的衝擊
- GPL 與商業化應用