發表文章

目前顯示的是 4月, 2008的文章

Openmoko - 惱人的 Empty flash 問題

之前『 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 Tech Summit Taiwan 2008

國內 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 Neo FreeRunner 解放軍起死回生

圖片
就如『 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:

OSDC.tw 2008!

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 相關之議題,實在不太是這次活動應該要有的內容呀,也難怪許多人第一天都沒出現。還好,第二

活用 g_object_weak_ref 避免 memory leak

這是一個常見又惱人的問題 - 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 這

家.巨變

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