Fred's blog

之前『 OpenMoko Neo FreeRunner 解放軍起死回生 』提過要如何才能讓 rootfs 復活，但自從換了新的 rootfs 上去之後，開機時 kernel 總是跑一連串的訊息如下： Empty flash at 0x05d6e39c ends at 0x05d6e800 Empty flash at 0x05d76134 ends at 0x05d76800 Empty flash at 0x05d791e4 ends at 0x05d79800 ... 此訊息將持續一段不短的時間，真惱人呀！雖然並不影響整體的運作，但實在很花開機的時間。很顯然的， 被寫入 NAND 的 rootfs，有一個不短的空白區域，卻沒有正常的結尾標注，使 kernel 要一直抓到 flash 的終點為止。 不過有辦法避免這問題，只要用『sumtool』工具重新處理 rootfs 即可： sumtool --eraseblock=0x20000 --no-cleanmarkers --littleendian --pad -i rootfs.jffs2 -o newrootfs.jffs2 再將 rootfs 再一次放到 Neo 裡面去然後啟動，問題一掃而空。 :)

國內 Open Source 社群推行多年，但權力鬥爭的狀況似乎不曾間斷過，本該是最了解『開放』、『自由』、『貢獻』的人，反而更陷入其中。 人與人的接觸和相遇，本來就是因為彼此需要，因為沒有人是完美的，沒有人是可以孤獨生活的。可惜在這資本主義當道的冷漠時代，人與人之間似乎只剩下名利與權力的鬥爭，不知不覺中『彼此需要』已經被無限擴大解釋成『彼此利用』。當什麼事都要以『利』為本當出發點時，互相猜忌便會營運而生，社會進步就會逐漸被人的私心所阻礙。 不可否認，人的私欲永無止境，無可根除也無法丟棄，更重要的是，人如果沒有了私欲，其實也無法活下去。事實上私欲沒有不好，一切是價值觀的問題，『利』的定義才是問題所在。 最近二十年來『Open Source』展露頭角，其本質就是以『彼此需要』為出發點，有能力的人貢獻，有需要的人使用，如果使用者沒有技術可貢獻，還是可以任何形式回報。在這遊戲規則下，你可以任意使用其成果做任何事，當然若是需要，你也可以拿去買賣、賺錢。 說到 Open Source，一般人大概都會被『常見』的 General Public License 所誤導。或許 GPL 被人們廣泛用來確保 Source Code 不被任何人所獨佔，且相當成功的令成果得以延續傳承。但是，以『彼此需要』的觀點來說，GPL 這類『以毒攻毒』的授權手段雖有其一定保護原始碼的效力，但未免與 Open Source 的出發點背道而馳。當然除了 GPL 之外，許多 Open Source License 也是類似的存在。不過 GPL 和各 License 細節就不在我們討論的議題之內了，這種基本教義派的爭論吵三天三夜也不會有結果。要了解 Open Source 還是得從他的源起概念著手。 比較值得注意的是，過程中『Community』逐漸被發展出來，其概念就是由『彼此需要』進一步衍伸成為『互信、互補、互利』。在 Community 中，沒有所謂的『老大』，每個人除了各取所需外，也貢獻自己所能付出的，更重要的是，每個人都可以有自己的意見、自己的想法並進行交流。但是在國內， Open Source Community 被少數在位人士所把持，也有許多不肖單位以『Open Source』的名義到處招搖撞騙，而且廠商強力介入以扮演『老大』，也令原本 Community 活動應有的內容變了質。 歐洲的 Com...

就如『 OpenMoko 』網站上的口號『Free Your Phone』，其目標不但是軟體，甚至是硬體的設計也都是開放公開的。就因為如此，一度掀起許多社群和媒體的囑目。 但是到底要『如何解放你的手機』，這議題就有很大的討論空間了，通常可以在『 OpenMoko Wiki 』找到許多 Developer 所需的 document 和開發工具。在仔細閱讀後發現各資料其實相當完整，對於籌組『解放軍』來說是綽綽有餘呀。 因為最近取得了 OpenMoko 的 Neo FreeRunner，所以整天都在把玩它，不過身為破壞狂的我，才短短幾個小時 rootfs 就被我玩壞了，馬上就要到 Wiki 報到求救，尋找 re-flashing NAND 以回復 rootfs 的方法 。:( 閱讀過許多文件後，發現 Flashing NAND 非常簡單，只要幾個步驟就可以還給我一個新的系統。 首先，『同時』按住『Power Button』和『AUX Button』三到四秒， Neo 就會開機並顯示 U-boot Menu。 這時候就可以使用 USB Cable 連接電腦，並使用『 dfu-util 』去 re-flashing 新的 rootfs ： ./dfu-util -a rootfs -R -D OpenMoko-openmoko-devel-image-glibc-ipk-P1-Snapshot-20080131-fic-gta01.rootfs.jffs2 然後會有 flashing information： dfu-util - (C) 2007 by OpenMoko Inc. This program is Free Software and has ABSOLUTELY NO WARRANTY Opening USB Device 0x0000:0x0000... Claiming USB DFU Runtime Interface... Determining device status: state = appIDLE, status = 0 Device really in Runtime Mode, send DFU detach request... Resetting USB... Opening USB Device... Found Runtime: ...

Open Source Developer Conference Taiwan，這 Conference 到目前為止堪稱台灣最大的 Open Source 開發者聚會。這兩天『宅男日』，眾阿宅出動聚集，女生實在是珍貴的少數！敢來的女生，向她們致敬！ 那這大拜拜活動人山人海，『我』在哪？其實我很好認，全場唯一穿『短褲』走來走去且偶爾拿 EeePC 出來的就是我(現場照片就沒有了，反正我不好看 :P)。除了第一天有進去坐幾場演講聊 IRC 外，第二天就只聽了一場 Jserv 的『許我們一個 Keroro 的桌面』，而其他時間就在外面 coding 、 debug LXDE，或是打屁吃東西聊天，因為我對那些語言議題比較沒什麼興趣〔我也是慣C一族呀〕。 話說回來，『 Jserv 』的 Keroro Demo 果然和他事前預料的一樣，因為投影解析度和許多已知 BUG，造成一些意外，據說他事前已經瘋狂的修改〔到前一天晚上還在 Coding :P〕，但還是沒完全搞定，不過能看到許多青蛙在上面跳動，倒是挺有趣的。不過所謂內行人看門道，除了 Clutter Toolkits 之外，其中最重要的當然是在 DRI2 for EeePC graphic chip ， Jserv 已經處理好了！讓我好想看看 DRI2 的詳細 Source code 呀。 為了宣傳一下我們正在努力的『 羽量級桌面環境 』，在第二天最後 Lightning Talk ， Andrew 就上台用 EeePC 表演了一下 LXDE，展現 OO.o 在 EeePC+LXDE 上的啟動速度（可惜的是他沒表演多重連開 OO.o，不然真的會嚇死人），希望能帶給大家驚奇，吸引多一些 Developer 或 Tester 加入 LXDE Project〔以後要隨身準備 Lightning Talk 的稿件才對〕。當然在這邊再寫一下 Project 網址： http://lxde.sf.net/ 這次 OSDC 美中不足的部份，就是第一天議程，實在看不出那裡有 Open Source Developer？又或是說了一大堆後，只要談到是否要 Release 出來時，就東閃西閃。讓大家花大半天的時間聽非 Open Source Developer 相關之議題，實在不太是這次活動應該要有的內容呀，也難怪許多人第一天都沒出現。還好，第二...

這是一個常見又惱人的問題 - Memory Leak 記憶體洩漏。常見的情況是軟體用一段時間後，記憶體使用量肥大，在許多功能複雜的軟體之中，不免會看到這類的情形。不過我們不能完全怪罪軟體設計者〔雖然他們還是佔很重要的因素〕，對程式開發者來說，要達成完全 Leak-free ，幾乎是不可能的事，因為除了自己寫的程式之外，各種 system call 都有可能造成 memory leak 的發生〔如 pango〕。 不過話說回來，system 裡各種 library 所造成的 memory leak 畢竟還是少量，軟體開發者所造成的問題佔著大多數，一個真實的例子：從 Firefox 每次 release 就一直在修正 memory leak 就可以發現修也修不完。 來探討 memory leak 的形成原因，顧名思義就是漏水，記憶體外漏產生了無法控制的記憶體區塊。舉個簡單的例子： void func() { char *p; p = (char *)malloc(12); p = (char *)malloc(10); free(p); } 此例的程式碼會出現 12 bytes 的 memory leak，因為第一次 malloc 取得的記憶體區塊未被釋放。換句話說，在第二次 malloc 之後，我們已經失去前一次記憶體區塊的位址了，該區塊對我們來說，已經是再也無法控制的記憶體區塊〔因為不知道位址〕，但他仍然會在程式結束前活在那。如此一來，要是我們重複呼叫此 function ，每次都會造成 12 bytes 的浪費。 當然，這是明顯可以看出 memory leak 存在的例子，有很多情況是很難發現問題的，尤其是在結構複雜的程式中。 有一個情況是這樣，在 Gtk+ 程式的設計中，常會臨時建立一個 structure 傳給 Widget event 的 callback function，程式碼大致如下： s = malloc(struct cb_s); g_signal_connect(G_OBJECT(menu_item), "activate", G_CALLBACK(cb_func), s); 和傳統的程式不同，我們不能在 g_signal_connect 之後就用 g_free() 去釋放 s，因為在 menu_item 這 ...

身為單純學生，悠遊自在，定目標爬終點，享受於學習、研究、玩樂之間。平日節省花用，特定時刻倒也過得去。閒暇之餘，投身於自由軟體，貢獻微薄心力，何處無不快哉。 感念人生多美好，卻總在厄運呼嘯後幻滅。天不可測，遭逢巨變，何處而去又何處而行？如今，家不是家，學生不是學生，許多缺口急於當刻解決，餓一餐吃一頓已非解決之道，待明日晨陽更是不可為之。一切尚未平定，家中緊接而來更多開銷，房租、生活皆是問題，我如何能再單純學生？又該如何處理這非普通學生所能應對的情境？ 噫！無奈家事從何而談？見友人當下，無法開口。只想稍稍訴苦，也難覓人選。胸口難受，鬱悶難耐！ 自問還能如何？維尋求機會，步步解決，或可突破困境。悲能力有限，固有滿腔熱血，卻無處可去，尚無頭緒。當下事態自慌，伯樂、引路人在何方？也只能盡人事聽天命。 因深知己非千里馬，所以力求百里行。慶幸自幼時便對資訊科技廣範涉獵至今，隨父出入過商場世面，總也學得幾招處事之應對，還望老天能賞臉，留條路予天涯淪落人。

講到自動控制一定會提到『 8x51 系列』的應用，這系列的晶片在近二十幾年來已經被廣泛開發到爛掉，無處不見其縱影呀，從燈號控制、定時裝置到各種自動化的家電、工業產品，都可以找到它的存在。因此，凡是講到要學習自動控制的應用與設計，『 8x51 系列』可說是必學的項目。 這學期因為專題教授強烈的『口頭勸說』和為了順便湊畢業學分，就跑去選修了『 8x51 微處理機』的課程，重溫了以前零星的經驗。話說這堂課有多次實作的作業，過程中玩弄電路板和程式非常有意思。不過課程免不了從最簡單的 LED 跑馬燈開始教，雖然乏味但也是一個惡搞經驗的開始〔尤其是不依照老師要求時 :D〕。 這是第一次作業的電路示意圖〔圖的標示和真實腳位不一樣，請參考 8x51 的腳位定義資料。〕： 作業目標是讓 LED 燈號從第一個燈開始，每 0.2 秒變一次燈號，向左旋轉三圈後，再往右反方向旋轉三圈，如此以重覆動作跑下去。程式設計流程大致上是： 程式是用 ASM 寫的，原始程式碼和詳細註解如下： MOV R0, #24 ; 設定切換 LED 次數：跑三圈共23次 ; 因為包括起始燈號，所以要設定成 n+1 次 MOV A, #11111110B ; 以 bit 為單位，設 1 代表該腳位會輸出 5V 電壓 ; 設 0 則腳位輸出 0V 電壓，會讓 LED 有電位差而亮燈 ; 這裡設最右邊第一顆 LED 燈泡為起始燈 RUNL: MOV P0, A ; 使用 A 的設定值來設定 P0 ，以控制 LED CALL SLEEP ; 呼叫 SLEEP 副程式，暫停 0.2 秒 RL A ; 將燈泡設定值向左平移 DJNZ R0, RUNL ; R0=R0-1 ; 然後判斷 R0是否為 0 ...

3G、3.5G 這半年多來炒的沸沸揚揚，令誰都想去辦個門號一探究竟。不過，談各家電信業者的 3G 服務品質已經沒什麼意思，來 Hacking 一下 3G 網卡的裝置訊息似乎會有趣得多 :)。目前，各家業者的 3G 門號，都是搭配『 Huawei 』的網卡，尤其以『 E220 HSDPA USB Modem 』最為普遍，其小巧又乾淨的外型相當討喜，因此就選擇拿它來開刀。 如何在 Linux 上安裝 E220 就不多說了，任何人都能在 Google 找到不少文獻，比較值得注意的是，安裝過程中會出現三個令人迷惑的 device file〔ttyUSB0、ttyUSB1、ttyUSB2〕。經搜尋過網路上的資料和實地測試後，已經大概知道這三個 Device file 的用途： ttyUSB0: 被當成一般 modem 通道使用，處理 3G 網路撥接用 ttyUSB1: 回傳相關的裝置和連線訊息 ttyUSB2: 放驅動程式的儲存裝置〔不確定〕。 如果你有將網卡裝起來，通常可以使用 pppd 透過 ttyUSB0 連線到 3G 網路，我想這部份就不用再多做解釋了。倒是 ttyUSB1 的部份比較特殊，會回傳一堆奇奇怪怪的 messages 〔可以使用 cat /dev/ttyUSB1 看到內容〕，而這些 messages code 又各是代表什麼意思，就相當令人好奇，當然，這也是這次 Hacking 的目的。 :D 經過一番測試後，整理了一些 ttyUSB1 回傳的狀況。 不論網路是否有連線，每固定一段時間就會回傳： ^BOOT:82907211,0,0,0,6 不過目前為止，還不了解此訊息的內容是什麼意思，有可能是裝置編號或是 firmware 的版本。 撥號連線後，就開始會回傳一些不一樣的訊息： 目前的網路模式： ^MODE:5,5 ^MODE:5,4 其中 5 是代表 HSDPA ， 4 是代表 WCDMA。而其他的 3、2、1 應該分別是 EDGE、GPRS、GSM，不過，大台北地區的 3G 基地臺相當完整，我還沒機會碰到有 3G 以下的模式，所以無法確定。 連線訊號強度： ^RSSI:8 其中的數字 8 即代表訊號的強弱，理論上 10 應該是最強，而 0則代表沒訊號〔目前還沒機會測試到〕。 然後有資料傳輸的相關資訊和統計〔每兩秒鐘更新一次〕： ^DSFLOWRPT...

說到 Graphical User Interfaces〔以下簡稱 GUI〕，就不能不提到『 Apple Inc 』的貢獻，其產品的推出確實一直為我們帶來很大的想像空間，尤其是『 Apple Mac 』推出之後，炫麗的 Dock 特效一度造成風潮，可以不難發現新一代的 GUI 早就已經開始悄悄萌芽。或許『特效』這個關鍵字會讓你想到一些知名的 3D Desktop Technology〔如：Compiz 和 Window Vista Aero〕，但在這邊我們並不會去探討它們，不過未來的 GUI 還是脫離不了 3D Technology 的範疇。 電腦 3D 技術發展至今，最近在基礎層面的應用也被許多人所關注，尤以 Mobile Device 上的動態更令人感興趣，像是 Apple iPhone 內廣為人知的特效就是一個例子。現在要介紹的一個 Open Source Project -『 Clutter Toolkit 』，就運用 OpenGL 技術提供一個效果十足的 GUI。 以下是從 Clutter Toolkit 官方網站摘錄的一段簡介： Clutter is an open source software library for creating fast, visually rich and animated graphical user interfaces. Clutter uses OpenGL (and optionally OpenGL ES for use on Mobile and embedded platforms) for rendering but with an API which hides the underlying GL complexity from the developer. The Clutter API is intended to be easy to use, efficient and flexible. Clutter Toolkit 提供一個快速且有豐富動畫特效的 GUI Library，讓程式人員可以很輕易的使用 Clutter API 去開發出一系列好用且具有科技質感的使用介面。若是更進一步結合觸控螢幕當 Input，操作易用性將大大提升，能讓使用者能有非常特別的操作感受。從官方『 Clutter Bl...

C語言本身沒什麼困難，只要好好弄懂指標與記憶體位置之間的關係，大體上『應該』就算會 C 語言了。真正令人感到怯步的部份，反倒是藏身其中的各種演算法、資料結構和作業系統機制問題，要經過長年累月的 coding 才能盡數體會。 相信許多人都曾經歷過自己硬幹『串列』的美好時光，造這種基本的資料結構似乎也成為了寫 C 的樂趣之一。但是，你可曾想過哪一天寫 C Program 時，再也不需要自製串列結構、再也不用使用 select() /poll 去操作 I/O、再也不用怕處理 String 遺漏許多安全細節、再也… ，一切『原始』的結構和機制，如果都不用再自己去刻劃，這樣的輕鬆的一刻到來，會是多麼愉快呀！『Glib』的出現，使所有夢想得以成真，讓 C Program 的開發更容易、更簡潔有效率且更穩定安全，如果說 Glib 是 libc 的加強補完計畫也不為過！〔雖然少了很多 coding 的樂趣 :( 〕 Glib 的眾多包裝之中，『I/O 處理事件化』是一個很特別部份，我們可以等待 I/O 的回應而不需要再用到 select() + loop。只要用『 g_io_channel 』設定好 I/O watch 後，讓 Glib 自己觸發 R/W 的事件 handler 就可以了，就如同 gtk 中觸發各種事件一樣的簡單。 基本 I/O 事件的 handler 宣告和設計： static gboolean gio_in (GIOChannel *gio, GIOCondition condition, gpointer data) { GIOStatus ret; GError *err = NULL; gchar *msg; gsize len; /* 若 IO HUP，直接返回 */ if (condition & G_IO_HUP) return FALSE; /* 讀取 IO 的資料 */ ret = g_io_channel_read_line (gio, &msg, &len, NULL, &err); if (ret == G_IO_STATUS_ERROR) g_error ("Error reading: %s\...

之前多次提到的 『 LXDE 羽量級桌面環境 』最近進展神速，除了 pcmanfm 的許多 bug 被修正之外，也添了不少新功能，其中最重要的就是 desktop-icon。這新的 desktop-icon 將提供桌面圖示功能，屬於 pcmanfm 的 branches 之一，目前已經成熟達到可用階段，即將被併回原本 pcmanfm 的主結構中。 在 session manager 的部份，lxsession 已經被重新設計過，現在可支援常見的關機、休眠、儲存執行狀態等功能，提供作業環境的許多必要管理機制。 而 LXPanel 裡的新網路監控外掛『 netstat 』也進入了實用測試階段，除了有線的網路裝置狀態之外，在無線網路的部份提供了更完整的支援，如 AP Scanning 等。如果沒有什麼意外，在下一版 release 就會預設使用此 plugin。 以下是 netstat plugin screenshot，不難由 screenshot 中可以猜到， netstat plugin 將是以取代 NetworkManager 為目標而設計，因為尚缺部份功能，目前仍在持續開發中： Wireless Information Encrypted AP Cable Detect AP Scanning 另外，由於 LXDE Project 近日得到了 ASUS EeePC 等捐贈，我們有更多機會在 EeePC 上測試 LXDE，所以將會針對 EeePC 此類 Mobile Device 做更多一系列的開發。 歡迎大家的參與， LXDE 將會持續努力向前走，提供使用者一個『飛快』的桌面環境！ 後記 好睏。都不太清楚自己在寫什麼了，只憑著興奮的情緒硬撐開眼睛在亂寫！

為了弄出一些空硬碟，我整理一些舊資料想燒出來，無意間發現過去的一些有趣想法〔笑〕。這是我高中時期的一個構想，原本是針對思考現今程式邏輯的不足，所提出的另一種邏輯原型。當時純粹只是為了解決線性邏輯的單方向性，所以僅僅在解決新模型的結構問題。過程以簡單的幾何方式來緒述初步架構，並未思考到實際的應用，當然也缺少許多實際的數學推導。但是由於長期接觸資料庫的應用和系統的規劃，後來在高三時的一些空閒時間，有嘗試運用和簡化該模型使用在資料庫處裡的系統上，雖有些初步成果，但也還不到實用階段。 簡單來說，對邏輯要就是 off(false) 不然就是 on(true)，這是 0 與 1 的基本概念。但進一步的邏輯是線性的， 0 與 1 決定了兩條向前走的路，如果每碰到一個 0 與 1 的判斷算是一個 Node ，那每個 Node 連起來最終會形成一條直線，且這條直線上有一個 Node 會是我們要的答案，至於是哪一個呢？就是由程式設計師決定了。線性邏輯已經被全世界的數學家、哲學家、科學家和 Hacker 發揮到淋離盡緻，它的確可以稱為今日的科技之母，當然，Multi-dimensional Logic Computing Model 也是架構在這上面。 只不過線性邏輯總是無法處理意外(exception) 的狀況，解決兩個選擇以外的組合，需要靠更多的 Node 去解決。我們必需先用人腦判斷是否有意外發生，再去針對意外設計 Node 解決，這也是為什麼當今 Artificial Intelligence 遲遲無重大突破的原因。雖然出現很多模糊理論、基因演算法、神經網路理論，但也不過是想辦法將 exception 當成訓練因子，歸納收斂成一個運算的方向，再用固定形式去求出答案。 在這種狀況下，線性邏輯顯然不夠用。從幾何的角度切入，一直線可以有無盡的 Node；從數學方程式來看，若是等號兩邊相等，一條線最終的 Node 必等於第一個 Node。從此假設可以發現，邏輯線被繞成一個圈，但是在應用面來說，這個圈沒有答案、沒有意義。為了解決這問題，於是想到種方法，若使用兩條邏輯線，必會產生兩個互相交集的點，這也代表答案將可能出現在這兩個點上面〔也就是停住有解答〕。 現在假設邏輯線可能很多且不論是否有交集：若每條線相同長度，無窮的圓周線將有可能變成一個球體狀，但事實上不同的邏輯不可能同樣長，這造成了形狀...