Fred's blog

在 Debian 5.0 Lenny Release 後，出現了一個新的名詞『armel』，可以在許多 ARM toolchain packages 身上看到，而 armel 顧名思義就是針對 ARM Architecture 的實作，但與古老的『arm』最大不同在於『armel』的移植是新的 ARM EABI ，對一些新的 ARM processor 特性有著更好的實作改進和支援，像是更動 Floating point、Stack alignment 等部份。 此外，因為 armel 參照著新的 EABI Spec 去更良好支援一些新 ARM processor 的特性，對於選用 CPU 也有些考量和建議。尤其是 Thumb interworking 的 16-bits Thumb/32-bits ARM instructions 混用機制，就因為只有 ARMv4t 以上的處理器才有這樣的特性，所以就建議最少要使用 ARMv4t 以上的 Processor，也因為這樣， Debian 的 armel toochain 的 GCC 預設會編譯出目標為 armv4t 的程式。 順帶一提，『 emdebian (Emedded Debian) 』一個 Debian Linux 的 Embedded 版本計劃，因為以 Debian 5.0 Lenney 為基礎，因此也有了『armel』這新的支援。 更多新的 ARM EABI 細節和說明，可以在 Debian 的官方 Wiki 上找到解答： http://wiki.debian.org/ArmEabiPort

我可以組裝我的桌上電腦，我要他快可以裝上 N-Core 的 CPU，我要順暢可以插上 N-GB 的 RAM，我要好的影像多媒體效果就換上高檔的 GPU，我總可以裝一台心滿意足的電腦，只要我願意。看看手上，雖然有各種 MID、Smart Phone，每家廠商也出了一堆外表漂亮的裝置，但都不是我想要的規格、我想要的系統。 是否有一天我也可以自己組裝一台手機呢？去光華商場挑選 ARM 板、GSM Module、WIFI Module、Touchscreen、機殼，我也可以組裝一台自己的光華牌手機呀！和光華牌比起來，山寨牌算什麼？

這幾天手邊同時在做 ARM 和 MIPS Architecture 的工作，當然免不了一直重覆 cross-compile 的忙錄，這性感又危險的工作，常伴隨著無盡的 Error 和 Failed，讓人既有成就感又有挫折感，需要去一一排除萬難才能順利達成 Make 的任務。說著說著，又碰上了一個莫明奇妙的 bug： libtool: eval: line 964: syntax error near unexpected token `|' 這是在編譯 glib2.0-2.20.3（在 Debian Sid 上使用 apt-get source 抓下來的 sourcecode）時所遇上的錯誤，目標是要 cross-compile 給 mipsel 所使用（尚未實驗 arm 是否也有同樣問題），Debug 的過程也不多說，因為可直接使用 Tricky 的方法閃過這個錯誤： USE_ARCH=32 NM=nm CC="mipsel-linux-gnu-gcc ${BUILD32}" ./configure \ --with-gnu-ld \ --target=mipsel-linux \ --host=mipsel-linux \ CC=mipsel-linux-gnu-gcc \ --prefix=/usr

昨日一如往常更新了 Debian Sid 系統，重開機以後發現 Compiz 的效果變得穩定且快多了，再仔細檢查，原來 xorg-video-intel 升上了 2.8.0。還記得自從 Intel Driver 開始轉移到 DRI2 開始，所有的 3D Performance 和 Xorg 的穩定性都不是很好，不但資源吃的兇，且三天兩頭就會 Crash，但 2.8.0 這版本似乎已經把大部份問題解決。更重要的是，因為 DRI2 已經可以運作，不會再有 compiz 與 OpenGL 程式打架的問題，可以看到在開啟 Compiz 的情況下 glxgears 已經可以躲在其它 Window 的背後運作： 新版本的細節，可以查看 Release Note： http://lists.freedesktop.org/archives/xorg/2009-July/046534.html 這裡列了 Xorg Intel Driver 2.8.0 的重要新特性： Remove XAA/EXA/DRI1 and NoAccel, and only support UXA/DRI2 now (requiring xserver 1.6). - 移除所有舊的加速機制（XAA/EXA/DRI1 and NoAccel），只留下支援 UXA/DRI2 VLD support added into XvMC for Mpeg2, which decreases CPU usage when playing video. - 加入 VLD(Variable Length Decoding) 到 XvMC，減少播放影片時的 CPU 使用量 然後修正了不少嚴重的 Bugs： Fix broken front-buffer rendering https://bugs.freedesktop.org/show_bug.cgi?id=19174 Fix disabling of XvMC disabled https://bugs.freedesktop.org/show_bug.cgi?id=20790 Fix broken VT switch on some machines https://bugs.freedesktop.org/show_bug.cgi?id=19578 Improve p...

今年『 COSCUP 2009 開源人年會 』的報名就在 7/16 日早上 11 點整鳴槍起跑，短短 30 分鐘內就湧入了上百人報名，之後更創下記錄，不算少的 550 張參加門票，卻只花了『四小時七分三十九秒』搶空！相較於去年 7 天報滿 400 人，今年的截止速度恐怖的嚇人，超乎往年的常理。也因為如此，許多熟面孔的社群朋友，通通沒搶到票，一一叫苦連天。 為了回饋長期參與社群的朋友，大會決定釋出事先保留的名額，開放第二階段的報名。報名時間將在『7/23 21:30』再次起跑，之前沒搶到名額的朋友們，不要再錯過這次的機會了！你沒有報到名嗎？磨拳擦掌準備搶票吧！ 後記 如果您報名後才發現當日有事不克參加，麻煩請在 7/23 21:30 前上報名網站取消報名，將名額留給想要參加的朋友。

電腦科技發展至今，就屬資料的處理、建檔和搜尋貢獻於人類最大，隨處可見 database 應用範疇，且各種 SQL Server 早就犯濫成災，不管大小事都要建置一個 database 去處理。但是，很多時候其實用不到龐大的 database server，如：個人用通訊錄或在 Embedded System 上的程式應用，因為並沒有這麼多的資料量需要被處理，因此若架設個 server 也未免小題大作，不但浪費系統資源，也拖慢程式的效能，此時一個小型又輕量的 database solution 就正是我們所需要。 目前已經有許多小型的 database 解決方案如：dbm、Berkeley DB、Sqlite，更早以前還有 Microsoft Office 系列中的 Access。開發者可以依照需求選擇適合的方案使用，但對於熟悉 SQL 的人來說，能支援大部份 SQL92 標準的 Sqlite ，還是最受親睞。Sqlite 就因為有 SQL 的特性，又兼具輕巧，常被拿去使用於 Embedded system 和當成各種軟體的資料處理機制，例如眾所皆知的 Firefox ，其 backend 就是 Sqlite。 使用 C 語言開發 Sqlite 的程式非常容易，短短數行就可以完成： #include <stdio.h> #include <sqlite3.h> static char *createsql = "CREATE TABLE Contact(" "ID INTEGER PRIMARY KEY," "Name VARCHAR(10)," "PhoneNumber VARCHAR(10));"; static char *insertsql = "INSERT INTO Contact VALUES(NULL, 'Fred', '09990123456');"; static char *querysql = "SELECT * FROM Contact;"; void main(void) { ...

從小，人們被捧在手掌心上，在父母和親人眼裡總是最聰明、最優秀，自己不知不覺也有了這樣的自我認同。上學後，團體生活開始挑戰了自己的認同感，為了保護『最優秀』三個字，使人在許多『最優秀』孩童的競爭中，努力贏取眾人的認同。到了聯合考試，聯合的比賽又再次挑起戰爭，掀起所有同年孩子的『榜首』競爭，人們依然為了這稱號向上攀爬，即使攀得滿身血淋淋，狼狽不堪。最後，我們又進入了橫跨數十年又不分敵我的『社會之戰』，比上比下也要證明『能力第一』、證明『自己最重視的一切』，保護『自己重視的各種事物』。 贏得外界的喝采，是自我證明的方法，一旦與眾人有所共鳴，自己也會對自己更有所認同。但是，往往外界假相蒙敝了自己的眼睛，外界的喝采並不是完完全全因為你的能力，而是另有加分管道，在不是單靠唸書得分的社會上尤為明顯。極其悲哀，許多人的人生數十年來都在一直重覆這個漏洞百出的實驗，千年下來仍然如此。 不單只有含著金湯匙的人，人人都是某種程度上的公子（王子），可以搖旗吶喊率眾人出師。若是丟掉『公子』兩個字，自己到底值多少價值？恐怕多數人從來沒想過或真正證明過這問題，因為割袍斷義、大義滅親不是每個人都能做得出來。 若是在測量自己的器量，懂得天下比想像的大後，再回去當公子，或許未來才有機會懂得當一個真正的明君，服天下之眾，不然，永遠只是歷史的丑角，在此勵己之。

前些日子在『 Linux 下的網路連線整合 』曾提到 Linux 網路機制的實作情況，若要做大整合，PPP (Point-to-Point Protocol)是首要考量的目標之一，因此這兩天就花了一點時間，透過現有 user-space 的 pppd 實作 PPP 的狀態提取，初步得到了些成果。 由於 PPP 存在的架構特殊，深入了解 pppd 的原理是必要的，如此才能完整處理資訊。不過，PPP 所牽涉的範疇比較廣，不少相關機制交錯於 kernel-space/user-space 之間，還好實作在 kernel-space 的機制，我們都可以統一透過 ioctl 去操作（如：Network Interface），並無太大困難。可是， PPP 實作於 user-space 的另一半機制，就沒有一定的 syscall 可以保證達成全部操作。 為何 PPP 有 kernel-space/user-space 的設計，要從瞭解 PPP 是什麼東西開始。正確來說，PPP 只是一種通訊協定，讓兩端通訊點能夠在此通訊協定上，建立 TCP/IP 等網路連線，它與硬體絲毫不相干，硬體裝置對它來說只是種傳輸資料的媒介。而一般人會誤以為 PPP 也處理 Modem 的 AT Command，是因為在過去語音通訊的年代，PPP 總是被拿來做在舊式撥號連線的通訊協定，大部份相關應用都是搭配 AT Command 使用。 也因為 PPP 本身很單純，在 kernel-space 的設計，只負責資料壓縮、解壓縮、轉換以及 Network interface 的建立和對應，而真正在與 Modem 溝通的，則是透過 user-space 的 pppd 這支程式。pppd 透過開啟 /dev/tty* ，並使用 AT Command 和 Modem 交換資料，取得通訊後再將通訊資料傳回 kernel-space 實作做解壓縮、轉換等處理，最後以 virtual network interface（ppp0, ppp1...） 的形式出現。 整個流程之中，其實 PPP 的 kernel-space 實作並不曉得資料是從哪個裝置進來，也不經手網路設定，除資料處理和 interface 對應的操作外，全都由 user-space 的 pppd 負責， pppd 的工作包括記錄 ppp0 與 /dev/tt...

大多數工程師整天埋頭苦幹，也許早就遺忘了眼前的各種高科技裝置在被發明前，所帶來的夢想有多麼令人嚮往，面對眼前的繁瑣雜事，只剩下無奈和痛苦。常在電影裡看到人類對未來科技的憧景，好像天方夜譚一般，尋思，若扣除某些尚未被創造的科技，我們能夠達到夢想中的幾成呢？ 我也想發展像夢一般的 User Interface 呀！:-)

比較有聯絡的朋友們，大概都知道我最近正在忙著開發 LXNM（Lightweight Network Manager），這也是為什麼現在一直研究行動通訊的東西，前些日子發表的『 GSM/GPRS/HSDPA Modem 總是告訴我你在哪裡 』就大致記錄了個研究開頭。 原則上，LXNM 的設計是可以輕易 cross-platform，但因為開發環境上仍然使用 Linux ，所以還是以『 Linux 上可以動』做為第一階段的主要開發目標。而過程中發現，Linux 下所有的網路連線都是統一透過 Network Interface 去做管理，如常見到的 eth0、wlan0 等等。這對一般的網路卡（Enternet）和無線網路裝置（Wireless）來說，我們可以認定 Interface 所直接對應的就是硬體裝置，但是，數據機（Modem）卻是一種例外，並不算是一個 Network Interface。這令人胡塗，就硬體角度來看，他們應該都算是一種通訊用的裝置，但在 Linux 下是是如此不一致被處理。 若要使用 Modem 連上TCP/IP網路，則需要有撥號的階段，透過 PPP（Point-to-Point Protocol），然後建立一個 Virtual Network Interface，因為最終的可用網路連線（Connection）還是必需為 Network Interface 型態。可是這種虛擬的介面，並非直接對應到 Modem ，必需透過其對應的 PPP kernel driver 才能循線得知 interface 與 Modem 的關聯性，在這部份的實作有些困難。 然而，我們便可以將所有 Network Interface 視為可用的網路連線（Connection）了嗎？並不是這樣的，一個常見於家庭中的應用就可以打破了這定義 - ADSL。目前廣為一般家庭用的 ADSL 網路，多半都使用 PPPoE（Point-to-Point Protocol over Ethernet）做為連線的方法，這意味著我們還是得像 Modem 一樣撥號連線，只是一般 Modem 可能是透過 Serial port（如：/dev/modem、/dev/ttyUSB0），而 ADSL Modem 是透過 Ethernet Device（也就是某個 Network Interface，如...

最近發現大家都在用『 噗浪（Plurk） 』，小弟擋不住好奇心，就也來申請一個帳號用用。 :P Fred's Plurk 網址： http://www.plurk.com/FredC

通訊技術發展至今，仍無法完全擺脫古老規格的框架，凡舉常見的撥接、ADSL(with PPPoE)、手機、到近年來的 3G(HSDPA)，仍然使用著老掉牙的 AT 指令集當做通訊協定，更或者是說當今人類最先進的『數位通訊技術』根本是建構在老式交換機之上，只是換藥不換湯。而令人興奮的是，橫行市場十多年的神秘 GSM/GPRS/HSDPA Modem，只要在我們深入了解 AT 指令集後，就能揭開許多其不為人知的秘密。 也許你有支手機，但不可能也不需要為了研究而輕易拆解他，因為最容易取得的 GSM/GPRS/HSDPA Modem 實驗品可能就在身邊，就是手邊的 3G 網卡（HSDPA Modem）。承襲了手機留傳下來的 GSM/GPRS 等規格，其一整套的 AT 指令集，在 HSDPA Modem 裡都有被留傳下來，你可以驗證 SIM Card 是否被鎖、是否有新簡訊或瀏覽 SIM Card 的通訊錄等等，只要是手機上有的功能，在 HSDPA Modem 也都一應具全。 當然，你也可以透過 Modem 去搜尋和取得電信服務商的名稱，如下（請開兩個 Terminal 以方便操作，並假設 /dev/ttyUSB0 為 HSDPA Modem，該範例使用遠傳電信 3G 服務和 Huawei E220 網卡）： Terminal 1: cat /dev/ttyUSB0 Terminal 2: echo -e "AT+COPS?\r" > /dev/ttyUSB0 在 Terminal 1 的結果： AT+COPS? +COPS: 0,0,"Far EasTone", 2 OK 另一個例子更有趣，我們可以透過 AT 指令去取得『目前地區編號』和『已連上線的基地台之服務範圍編號』： Terminal 2: # 設 mode 為 2，使 Modem 接受和回傳基地台訊息 echo -e "AT+CREG=2\r" > /dev/ttyUSB0 # 取得目前資料 echo -e "AT+CREG?\r" > /dev/ttyUSB0 在 Terminal 1 的結果： AT+CREG=2 OK AT+CREG? +CREG: 2,1,2396,1A54AF9 其中『2396』為目前地區編號（...

很榮幸受邀，小弟將於八月15、16日所舉辦的『 COSCUP 2009 開源人年會 』給予一場議程，在這短短的時間內，會簡短說明 LXDE(Lightweight X11 Desktop Enviroment) 設計理念和目前、未來發展，以及如何善用 LXDE 的真正價值等相關議題。 為因應行動裝置當道的時代，羽量級操作環境和系統開始成為眾所矚目的焦點，不單硬體，今日的軟體也開始追求省電、省時、省資源，而且，載體也已經從電腦跨 足到PDA、MID、手機等裝置。過去瘋狂消費硬體能力的軟體設計，勢必不再能立足。反觀思考如何開發輕量的系統，就變成了當前最重要的課題之一。而長久以來，LXDE就在這輕量的課題上多有著墨，其除了可以是一個羽量級桌面環境外，更是一個羽量級軟體的集合，可以協助各個行動裝置快速佈署基本的輕量系統平台。

最近忙著開發新的 LXNM(Lightweight Network Manager)，但在開發的過程中碰到了一個 Critical Bug，該 Bug 會讓 LXNM Daemon Crashes。難過的是，已經費盡心思卻仍然找不出問題所在，以致浪費好多時間在 debug。最後多虧了 Paulliu 的協助，終於找出了程式中臭蟲，令人想不到的是，問題居然是出在 GList 的操作。 這問題出在於移除 GList 裡的 Node 之後，再讀取下一個 Node 時會 Crash，這有一個簡化後的錯誤範例： GList *node; for (node=mylist;node;node=g_list_next(node)) { mylist = g_list_delete_link(mylist, node); } 這樣表面看起來或許沒有錯誤，但以 Link-list 的基礎觀點來看，卻馬上可以發現到問題所在。該程式中，當迴圈進行到第二輪時，會因為 g_list_next() 無法取得下一個 Node 而死在那裡，因為供參考的 Node 已經在第一輪迴圈就被刪除，我們無法取得其 Node->next，當然就會發生錯誤。因此，需要稍微修改，以避免掉這樣的問題： GList *node; GList *next_node; for (node=mylist;node;node=next_node) { next_node = g_list_next(node); mylist = g_list_delete_link(mylist, node); } GLib 提供的 API 包裝，讓懶惰的我們可以很輕鬆的建立和操作 Link-list，當然難免就會不小心寫出像這樣有問題的 Code 來。因此，對程式開發者而言，就算 GLib 再方便好用，資料結構和各種演算法的理論還是無法完全拋棄。