Fred's blog

很開心，這次十二月的『 Hackathon Taiwan 』相當多人參與，百人的報到數讓所有工作人員都感到興奮。最重要的，多虧了活動夥伴的遊戲設計，這次讓很多隻身而來的人，化解尷尬、相互認識並熱絡起來，最後順利組成隊伍，這算是種格外特別的創舉，過去很少有黑客松能做到這樣的地步。 有趣的是，這次活動找來了重量級的神秘講師 Jeremy Lu （對，就是那位最近紅極一時的 React.js 講者）開課，讓聽眾大飽耳福，絕對不枉來這一趟。有很多人也衝著 Qt 的課程而來，學習 QML 這樣先進的 UI 技術，這次的 QML 遊戲開發課程，相信讓很多人也開心地學會很多技術。 小弟在第二天的結尾，也給了篇一小時的分享『Koa 正在等一個人』，其內容在探討並帶領上手 Koa 這個下一代的網站框架、ECMAScript 6 Generator，以及 Node.js 和 io.js 的最新動態。（事實上是把最近將要出的書，擷取片段內容出來分享） 後記 對於我而言，活動內容再豐富，都比不上找到了好隊友可以一起創作。這次活動，得到了一個硬體工程師加入我們的團隊，所以可以開始進行硬體設計及控制等工作，而且大家相約了下次一起再來。下次，我們將會開始進行各種智慧家電的控制，以及 IoT 的相關應用。看來，我們只差一個設計師的加入了！如果你有興趣，快來加入我們！:-D 下次黑客松活動預計將於 2015 年 1/31、2/1（六、日）兩天，無論你是軟體開發者、硬體開發者、設計師還是學生，都歡迎來參加！而且，一樣會有神秘講師！

這陣子，最怕的就是有人問：『書什麼時候要發行？』，參加社群聚會或活動時，有人會問我，平常周圍朋友也會問我，工作上隊友和客戶都會問我，只有一些親人根本不知道不知道我在寫書，所以不會問我。如果你問我，寫書這件事上，你最怕的是什麼？我會跟你說，出版社截稿日期的死線（Deadline）並不是最可怕的，最可怕的是，它是一種詛咒，讓周圍人都會特別關心你的一種魔法。而這個關心的壓力，讓人喘不過氣來。 還好，書總算從初稿、校稿到排版完成，直到出版社編輯傳來最後的封面設計，才讓人鬆了一口氣。可以告訴大家，書總算要真正出來了！ 事實上，國內 Node.js 的書其實並不多，其中幾乎多為翻譯書，或是從簡體直接翻成繁體中文的書。這讓這幾年一直在到處推廣 Node.js 的我，相當困擾。每當有人問起 Node.js 有什麼書可以看時，我總是無法推薦出很多本給大家參考。所以，當出版社的編輯跟我說，希望寫一本 Node.js 的中文書時，我其實相當開心。 還記得當時接下這個任務後，我便開始思考和回想，在推廣和使用 Node.js 時，所遭遇到的困難是什麼？我能否藉這本書來幫助讀者排除這些困難？甚至給讀者一個更大的視野，一個 Node.js 可以發揮在各種領域的可能性。 此外，網路時代來臨後，有太多的新資料都可以從網路上取得，這本書要提供什麼內容，更是需要被探討的問題。尤其是 Node.js 這樣版本號快速上升的新技術，可能書還沒寫完，內容就已經過時。在種種思索下，期望本書的定位，將帶給大家的不是絕對的技術新知，而是一本學習 Node.js 的參考書和技術指南，讓想入門的讀者可以學會怎麼使用 Node.js，讓已經懂的人可以知道 Node.js 還能做些什麼不一樣的事，更進一步知道從哪裡去得到更多 Node.js 的新知。如果這本書在幾年後，仍有六成的資料值得參考，那就算完美達成我賦予它的任務了。 從引領初學者的角度來看，並參考了一些市上的 Node.js 書籍，也從過去教育訓練和推廣的場合發現一個現象。Node.js 不是什麼很難的新東西，如果有人已經很熟悉 JavaScript 語言，而且能寫的很好，Node.js 根本是小菜一碟。所以，多半不得其門而入的人，是對 JavaScript 不這麼熟悉，或是想使用 Node.js 技術進行第一次接觸程式開發的人。只不過，...

『 Stem OS 』是一個 JavaScript 作業系統，內建 Node.js 和許多 JavaScript 的系統 APIs。如果你有在筆者的開發動態，就會發現 Stem OS 是我們 Mandice 團隊目前的開發重點和產品，我們一直期望能讓懂 JavaScript 的人，都可以來開發系統程式、嵌入式系統，此外，也想運用 JavaScript 語言的流行度，讓嵌入式系統開發門檻降低，使其更為簡單、快速。如果你家中有看似沒用的舊電腦，在安裝 Stem OS 之後，便可以立即用 JavaScript 自行寫一些應用程式，賦予這舊電腦全新的用途。還記得，在今年的 OSDC 活動上，小弟上台給了一場 lightening Talk，即是探討如何將舊電腦改造成一個無紙化傳真機，而改造的時間只需要 5 分鐘，包括安裝 Stem OS 和寫幾行 JavaScript 程式。有興趣的人可以參閱當時的投影片『 JSDC 2013 簡報釋出！NPK 與 JavaScript OS (Stem) 登場！ 』。 JavaScript 語言的好處就是用它寫的程式無需編譯，效能也不俗，這意味著，當你在開發 PC 平台之外的嵌入式裝置（如：ARM），你不必再忍受跨平台編譯（cross-compile）的痛苦，可以很快速開發你的應用。此外 Stem OS 已經將系統和硬體的支援都已經為你處理好，也提供許多低階的系統 APIs，且一開機就是跑你的專屬程式，你可以專心的打造自己的嵌入式應用，完全不用再煩腦和花大量時間在系統整合和移植的開發上。 既然 Stem OS 已經將許多系統功能包裝成 APIs，讓 JavaScript 可以透過這些介面從 UI 控制到硬體，代表我們實際上做了很多這方面的準備工作，本文將要提到的 jsdx-disk，便是其中之一。 jsdx-disk 顧名思義是一個控制硬碟的系統 APIs，你可以用他掛載（Mount）、切割磁區（Partition）和格式化（Format）硬碟。更進一步，你可以用他監控系統上的儲存裝置，以及取得這些儲存裝置的硬體資訊，更進一步處理熱插拔（Hotplug）的行為。在 Stem OS 中，我們以 JavaScript 寫了一支常註程式（Daemon），監控熱插拔隨身碟，自動掛載（Automount）的機制，而這功能就是運用了 js...

當你得到 Cubieboard 後，首先要做的就是學習如何啟動你的作業系統。Cubieboard 可以支援 SD Card 啟動，這通常也是最容易入門的 Embedded System 開機方法。你只要準備一張 Micro SD Card，切割出分割區，然後把 Bootloader 和作業系統放進去即可。 安裝 u-boot Cubieboard 使用的是 u-boot 做為 bootloader，你必須先下載 Source Code 然後 Compile： git clone https://github.com/linux-sunxi/u-boot-sunxi.git make Cubieboard CROSS_COMPILE=arm-linux-gnueabihf- 如果你的系統 toolchain 都已經安裝完成，且都沒有問題，u-boot 會順利編譯通過，然後你會在 u-boot 的目錄裡得到兩個檔案： spl/sunxi-spl.bin u-boot.bin 有了這兩個檔案，安裝 u-boot 就不是什麼問題，只需要使用 dd 指令來把 bootloader 寫入 SD Card： dd if=spl/sunxi-spl.bin of=/dev/sdb bs=1024 seek=8 dd if=u-boot.bin of=/dev/sdb bs=1024 seek=32 註：/dev/sdb 是 SD Card 的裝置路徑，請依照你系統上的實際狀況，填入正確路徑。 後記 有趣的是，很久沒有玩開發板了，自從兩年多前開始陸續投入各廠商的專案後，所碰到的 ARM Board，清一色都是客製化的產品樣板。而幫大廠商做產品，和自己玩開發板相當不一樣，同樣是驅動程式有問題，要做的是打電話罵人；如果會當機，快打電話罵人；如果缺任何東西，打電話罵人就對了！所以，在客戶的專案中，做最多的總是證明硬體廠商的問題，讓硬體廠商們心甘情願幫你把問題排除。雖然還是要熟悉 Debug 的技巧，但多半不用自己煩惱『該怎麼辦』，只需要下指導棋。因此，自己也慢慢養成很多惰性，除非是真的沒人可以幫你，才肯親自出手跳下去從底層到應用程式，深入修正問題。 但是，玩開發板可不是這麼一回事。有問題？你自己搞定吧。搞不定？問 Google 大神吧。還是不行？慢慢看...

我們的團隊，最近取得了『 Cubieboard 』這開發板的代理權，負責台灣、香港等地的銷售和市場發展。這是很令人興奮的，因為我們好久沒有辦法全心全意開發自己想開發的東西、研究自己想研究的技術、打樣、以及對客戶驗證自己的想法，現在，終於可以名正言順的投入，利用這通用平台做一些不一樣的事情。 開發板顧名思義就是可以讓你開發的硬體、讓你用軟體控制的裝置，如果你有任何想法，都可以在上面做實驗，或是 DIY 打造出外面買不到的裝置，甚至做出產品原型。如果你有興趣，無論是個人和公司團體，歡迎與我們聯絡﹝frankie@mandice.com﹞。

最近比較忙，一直拖到現在，才有點時間上傳我在今年 JSDC 的簡報。這次，給的講題是『我編譯故我在：誰說 Node.js 程式不能編成 Binary』，主要探討怎麼使用 NPK 打包你寫的 Node.js 程式，以及把 JavaScript 程式碼編譯成二進位(Binary)檔，甚至是進一步的加密設計。NPK 雖然還只是初版，目前支援了三種博君一笑的封裝等級：卸妝(Remove mock-up)、媽媽不認識(Mom doesn't recognize)、爸爸不認識(Dad doesn't recognize)，有興趣了解這三種等級不同的人，可以參考我的簡報： 當然，參加這種活動需要的是熱血，不在 Lightening Talk 閃電秀登場一下怎麼可以呢？於是當天毫不考慮的搶了一個名額，用短短的五分鐘介紹 Mandice 團隊最近在做的 JavaScript OS - 『 Stem 』。在 Stem 的平台之下，無論你是否為嵌入式系統或作業系統的高手，只需要懂 JavaScript 和純粹的 Web 相關技術，你就可以開發自己的嵌入式應用，或讓你的舊電腦或開發板有全新的用途。 後記 大家都知道，做外包工作，一向很難累積東西，唯一能累積的，就是設計工具以加速自己做案子的速度。因此，Stem OS 就是我們經歷過許多的案子後，自己設計的平台，讓我們可以盡可能完全用 JavaScript 快速開發嵌入式系統，然後結合硬體開發設計各式應用。在 Stem 裡，只需要懂 JavaScript 和 Web 相關技術，就能勝任開發工作，實現你心中的 Idea。如果說 3D Printer 是可以讓你快速打造模型實體，那 Stem OS，就是能將你心中的 Idea，化為空硬體的靈魂，Idea 的 3D Printer。 這對創業者、創新者和非資訊產業的公司來說，都是一個可以快速切入設計產品和自家工具的機會，不妨嘗試看看。:-) 如果有任何需求，無論是顧問、教育訓練還是合作開發，都歡迎與我們 Mandice 聯絡，或來信到 fred@mandice.com。

OSDC.TW 2013 順利在中央研究院國際會議廳閉幕，但一如往年，失落感接踵而來。為了這次的 Talk，可說是花了不少工夫，除了研究 Webkit 的內部實作，以及 V8 JavaScript Engine 之外，最後也發表了一個新的 JavaScript 作業系統『 Stem 』，一個可以完全用 JavaScript 和 Web 技術去開發應用程式的嵌入式作業系統。Stem 落實了用 JavaScript 語言開發嵌入式系統的理想，並簡化嵌入式應用開發，讓人人都能輕鬆躍過以往嵌入式系統開發的艱澀門檻。 這邊釋出當天的簡報檔，有興趣者可自行參閱： 此外，對 Stem 有興趣的人，可以拜訪專案網站： http://stem.mandice.org/ 也可以在 IRC 上交流： 英文頻道：irc.freenode.net #stemos 中文頻道：irc.freenode.net #stemos-zh 註：目前 Stem 已釋出 x86 版本的安裝鏡像檔，近期內將會釋出 ARM 的版本，敬請期待。有興趣參與開發者，歡迎來信一同交流。

經過一年多的孕釀，我們的團隊【Mandice】已有萬全的準備，在此正式對外宣布提供 Node.js on Embedded System 的專業技術服務，歡迎立即來信洽詢。 嵌入式系統開發生態已經改變，今天的 Node.js 已為嵌入式系統帶來全新的面貌，其高效開發的優勢，以及不俗的效能和數不清的現成模組，讓嵌入式系統的產品開發周期以及技術門嵌大大降低。導入使用 Node. js 能讓產品設計者，更能專注於創新和使用者體驗，因應這時代的快速發展。 我們的團隊在這一年間，已經深耕各類 Node.js 相關技術，更結合團隊過去的系統技術和產品經驗，提供了整套的系統軟體平台以及顧問服務給許多合作夥伴和大廠，讓其開始以 Node.js 開發自家產品。至今，已有一些面世或即將面世的產品，使用了 Node.js 的技術開發嵌入式系統，甚至已經著手準備第二代產品，成效相當不錯。 若您也想趕上這班列車，歡迎與我們聯繫，我們將提供您最好的服務。 有意請來信至電子郵件信箱，我們會立即與您聯繫: fred@mandice.com

既然會成立新創公司，總有些自己的想法，也期望做一些和其他人不一樣的事，對我們而言，改變世界事小，留下長久價值更重要。也許你有點印象，筆者今年度到處給予的 Talk，多半都是與 Node.js 相關，也透漏許多正在執行的計劃。因此，有些人可能聽過筆者提及『JSDX Framework』，這是『 Mandice 』的長期計劃，也是將 JavaScript 落實在系統、桌面和嵌入式裝置的解決方案。 由於 JSDX 是一個開放原始碼專案，市場上也已經有一些產品和公司專案導入使用，但因為合約的關係，我不能透漏太多細節，所以本文將只討論些許技術細節。說到這，也許你還是沒什麼概念，但若是真要舉出最直接與其相關的專案，就是今年 8 月，於 COSCUP 一場議程中所公開的『JUICE Desktop Environment』（簡報檔詳見舊文： 【COSCUP 2012】閉幕！簡報釋出！ ），完全以 JavaScript 實作的 3D 桌面環境。 JSDX 包括許多元件，從 GUI Toolkit（使用者界面）、Multimedia Player（多媒體播放）、Network Manager（網路管理）到 Sound Manager（聲音管理）等，提供了各類系統控制或硬體相關的 APIs。程式開發者只需要會 JavaScript 語言，就可以使用這些 JSDX 所提供的 APIs ，開發各類應用程式或系統程式。 回應本文標題，JSDX 如果可以拿來開發桌面環境，當然也有電源管理相關的 APIs 可使用。所以在這邊我們要討論的元件是『 jsdx-power 』，你可以在 github 上取的他的 Source Code，亦或是直接透過 npm 安裝。 npm install jsdx-power 這邊簡單示範如何使用 JavaScript 透過『jsdx-power』命令作業系統休眠： var Power = require('jsdx-power'); var power = new Power; power.init(function() { power.suspend(); }); 後記 JUICE DE 的 juice-panel 電量顯示，就是使用了 jsdx-power，有興趣的人可以參考其 Source Code。

感謝各位捧場，上周六在『 OSDC.TW 2012 』所分享的『Let's Enjoy Node.js - All Development in JavaScript』，旨在介紹『 Node.js 』這新興的 Open Source 專案，我們可以預見，其將帶來軟體業相當重大的變革，並為 JavaScript 程式語言開拓了嶄新的局面。目前簡報檔釋出，歡迎各界取用和參閱。 自 2009 年 Node.js 公開發表以來，備受世界各地開發者囑目，在 2011 年 12 月更一度榮登 github 關注排行的第一位，超越了 Ruby on rails。Node.js 的出現意味著 JavaScript 語言從前端應用走進了 Server 的殿堂，除了效能表現不俗之外，使用其開發應用也相當迅速，未來 Web 開發者可以完全使用 JavaScript 語言打造網站服務，甚至是可大規模括展的雲端應用，堪稱 Web 開發者的夢想。 值得一提的是，Node.js 其實不僅限於 Web 應用，甚至可以用於各類系統程式開發，比較廣為人知的例子是 HP WebOS（前身是 Palm WebOS）。其採用了 Node.js ，做為系統服務的開發途徑之一。此外，Node.js 有模組化的設計，讓開發人員可以輕易使用各類其他語言(C/C++/Python... etc)為其擴充功能，彈性相當高，更讓 Node.js 不受限於任何開發領域。

和我比較熟的人，最近應該都知道，目前我專注於 JavaScript 和 Google V8 engine 的相關研究上，甚至決定從今年開始，公司營運以及技術團隊的方向，是企圖提供『最專業的 Node.js 和 JavaScript 相關服務』。（所以，如果您有需要，請聯絡我們 :-) ）我非常清楚知道，有些人聽到 JavaScript 就歡天喜地，而有些人則不將他當一回事。更有多到數不清的技術人員，熟悉並使用 JavaScript 非常多年，聽到我說要提供『最專業的 JavaScript 相關服務』，會不屑一顧甚至以為我在瘋言瘋語。不過，如果你願意聽，接下來我會說明這是怎麼樣的瘋狂服務。 我不能阻止你對 JavaScript 有預設立場，因為這是無奈的歷史包袱，但請暫時放下過去成見，聽我靡靡道來。 我所遭遇的矛盾 過去，絕大多數人都只將 JavaScript 視為 Web 開發的一環，在大家的印象和認知中，JavaScript 充其量只是一個在瀏覽器中控制著 HTML DOM 的腳本語言。雖然近年來出現了 Node.js，過去微軟也支援使用者使用 JavaScript 撰寫 ASP 和系統腳本程式，但也不改這樣的看法：『JavaScript 是身處於末端的語言，與網頁、網站密不可分的東西』。所以，對許多硬底子的企業和研發人員來說，JavaScript 象徵了 Web/HTML 與不彰的效能，一種幻想的存在；而對很多 Web 開發者和前端工程師來說，JavaScript 卻是一種當今資訊產業的萬靈丹。如此天差地遠的矛盾，一直存在於這個產業界。 曾經當過 Web 開發者一段不少的時間，我承認也理解，使用 Web 技術來實作各類使用者界面(User Interface)和資料庫應用，非常容易和快速，不用考慮到太多的事。這一切要歸功於 JavaScript 和 HTML 的合作無間。所以，不時能聽到一些 Web 開發者，嘲笑作業系統程式開發者和嵌入式裝置的技術人員的辛苦，認為許多功能和特效，使用 Web 技術一下就達成了。 由於我過去也是『慣C』一族，做過很多包羅萬象的硬碰硬開發，小從一般電腦到嵌入式裝置、桌面系統到手機平版，大到各類特殊需求的系統研發，都有所涉獵。所以，對於系統資源和效能，一直有著莫明...

這是創業者的心聲，我們永遠為了為數不多的錢，拼老命和客戶周旋。在客戶面前包到好包到腳，扛的責任何其多，回來後又當業務又當 PM 還要當 R&D，最後還得當會計，數不盡的心酸誰知道。沒辦法，對我們來說，現金流（CashFlow）比什麼都還重要，能不能挺過這個月或下個月，維持周轉才是首要任務，為此，任何苦我們也得吃下。 筆者做了幾年的 Outsourcing，雖然不是當初創業的核心目標，但為了養家活口，接案卻成了主要業務。不過，筆者確實也因接案而活了下來並壯大團隊，能夠有機會持續朝理想發展。接案的過程中，風風雨雨自然不在話下，但慶幸受到前輩和朋友間的提攜，近來也總算是開始有個根基，剛好穩住腳。 接案就是這樣，有一頓沒一頓，如果要穩定收入，案子的價與量就必需相應提高，這是所有以接案當食糧的創業者，所都要經歷的過程。但是，往往在提升價和量後，案子開始會吃掉團隊的全部時間，漸漸失去當初創業的核心目標。然後，進入了『招人力』後『招案子』再『招更多人力』後『招更多案子』的惡性輪迴中，最終你會想：『辛苦到快暴斃，工時責任換算下來，賺得比去上班來得少，那我何必創業？』。如果你有同感，不用灰心，因為現在有無數的創業團隊和創業者， 也都正面對著同樣問題，甚至面臨崩潰。 有鑑於此，筆者尋思，何不與大家分享自己的經營成果，讓大家各自都能得到更多時間經營自己的核心目標？創業者、SOHO族和個人接案者所需要的源源不絕的食糧，不必各自重新發展重新耕耘，只需要從筆者這接手過去即可。由於舊有團隊原本已經有業務和PM的佈署，大家也可專注於技術性的工作，並提供如自來水般的技術供應即可。 對筆者來說，自己的核心技術團隊得以鬆口氣， 能慢慢以階段性放下養活自己的短期目標，有更多時間朝自己原本創業的核心目標前進。另一方面，也能給予其他創業者、SOHO族和個人接案者穩定的收入支持，不必重蹈覆徹筆者同樣的道路。如此雙贏的局面，樂見其成。 所以，如果你們是有技術的創業者或創業團隊，SOHO族或個人接案者，趕緊來報到吧！ 後記 無論你是專精或有經驗於哪一領域（Web、Linux、Android System（Integration/Porting）、Android App、iOS App 或 Embedded System... etc），都歡迎來信，最少先交個朋友也是不錯的。:-)

你將為自家的產品，選用什麼樣的作業系統？我想，這年頭，不外乎是 Android。但是，可能不是最佳選擇。 我想大多數人都會同意，由於智慧型行動裝置的掘起，Google Android 在業界大放異彩，使用 Linux 作業系統核心的 Android，實現了許多華麗的UI，也讓眾多廠商取得入門門票，有機會與 Apple iOS 一爭長短。許多人都相信，未來是 Android 的天下，除了手機要用 Android，電視要 Android，救人一命的醫療器材也要用 Android，所謂的 Android anywhere 是終極目標。 不過，經過這幾年下來，許多人發現這不過是我們資訊科技業一廂情願，有太多的領域是難以使用 Android，如工控市場等，無論是以穩定、價格、移植維護成本考量的因素，都可能是無法使用 Android 的重點。因此，如今要選擇作業系統解決方案，又變成一個需要思考的難題。 筆者擔任顧問時，每當面對客戶躊著於這個問題時，我總問他們幾個大問題： 你們的產品用途是否單一且單純？是否要有讓使用者自行上網安裝其他第三方軟體的擴充性？ 你們的產品是否為消費行電子產品？是否需要高可用行和高穩定性？ 你們的軟體需要有華麗特效的 UI 嗎？你們現在擁有的人員有哪些開發 UI 程式的經驗？ 有網路的需求嗎？如果有，需要哪些需求？Ethernet、Wifi、3G？ 計劃中的產品硬體規格？ 有多少規模的人可以參與開發？ 很明顯的，對於手機和行動裝置業者是這樣的答案：（他們都會選用 Android） 用途不單一，需要讓使用者任意自行上網安裝軟體。 是功能複雜的消費性電子產品，所以客戶多多少少能接受偶爾當機 UI 需要有華麗的特效。開發人員都熟悉並使用 Java 的經驗。 有所有網路的需求。 擁有一定等級以上或是當前最頂級的 ARM 處理器。 最少數十個，多半是上百人甚至上千人的研發人員。 如果你是『非手機』和『非行動裝置』業者，你的產品可能不完全具備這些條件。建議您，一旦有任何一點不具備，請慎重考慮是否使用 Android 還是有機會選擇其他的解決方案。 而當前的解決方案主要常見有三種： Android Linux + Qt Framework Linux + Own Application 限於篇幅，太細節的評估無法一...

最近接了一個小案子，主要是協助客戶將 Qt 應用程式從舊板子移植到新的硬體上，由於硬體是 Third-party 做，當然所有的驅動程式也是由別人處理，我們並不經手，只和硬體廠商密切合作。 這次我們碰到了一些 Keyboard 問題，一開始是 Linux driver 缺少 input_sync() 的操作，導致 Qt 無法正確辯別按鍵的『壓放』。接著碰到個更棘手的問題，就是 Qt 送到應用程式的 Key 事件（Event）有很大機率會送錯。這將導致按鍵所觸發的結果，有很大的機會我們無法預期。檢查過 evdev event 和其發出來的 keycode，我們確定了 Linux Driver 是正確的，判斷應該是 Qt 的問題。 經過一番檢查後，發現是因為 Qt-Embedded 預設使用 TTY Driver(qkbdtty) 去驅動鍵盤，大部份情況下不太會有問題，但因為我們走的是標準的 Linux evdev (/dev/input/eventX)，如果很快速或多重觸發鍵盤按鍵，就有可能讓 Qt 的 TTY Driver 取樣和解析出錯誤的 Event 值。最快的解決辦法就是捨棄 Qt TTY Driver，然後改用 Qt  LinuxInput Driver(qkbdlinuxinput)。 不過 qkbdlinuxinput 並不處理 VT，這是與 qkbdtty 最大的差異，此舉會造成板子上的 Console 不正常切換，Debug 用的 Console 會因此壞掉。筆者在此對 QWS Keyboard Driver 做了些修改，讓 tty driver 使用 linuxinput driver 的方式去解析 keyboard event，並保留 VT 的處理機制。 Patch 檔案連結如下： http://fred-opensource.googlecode.com/git/patches/qkbdtty_qws.patch

最近手上有一些電子紙的案件，指定使用 Qt 做為圖型平台。與一般裝置不一樣的地方，電子紙的更新頻率很低，平均下來每秒頂多刷新一次，相對於 LCD Panel 的每秒 60 次起跳，實在低的可憐。對於專職繪圖的 Qt 而言，要如何壓低刷新的頻率和確認畫面繪圖完成，最後再推入 Display，便是一個重要的課題。 壓低更新頻率比較單純，透過修改 Framebuffer Driver 就可以達成。此外，也必須利用 setUpdatesEnabled() 和 update() 盡量避免 Qt 連續多次的繪圖需求，合併一次送入 framebuffer，這樣可以減少 Qt 來不及畫完和畫面閃爍的問題。 到此為止只是改善顯示效果和基礎的建置，真正要完成完美的一次推送，通常需要使用電子紙驅動程式所提供的額外 API，它同意我們自己決定何時將 Framebuffer 的資料推送到紙上。 至於何時該將畫面推送至電子紙上？這時需要針對 QApplication 做一些修改，監聽和自己創造一個新的事件： const QEvent::Type UpdateScreenEvent = (QEvent::Type)1234; bool Application::notify(QObject *obj, QEvent *e) {      if (e->type() == UpdateScreenEvent) {           if (updateScreen) {               EPaperDriverCtrl *ctrl = (EPaperDriverCtrl*)EPaperDriverCtrl;               ctrl->pushFBtoPanel();               updateScreen = false;  ...

已經過了近兩年，至今仍然沒有一台 PC 廠商做的平板電腦能勝過 iPad，精緻度估且不論，其速度與流暢度，相較之下只能堪稱工程機的程度。其實真正原因不在於這些廠商行銷廣告中的 CPU 『數量』，而是 Android 系統軟體本身處處存在了一些效能上的問題，重點是這些問題不是工程師所在意的，而且吃力又不一定討好，沒人會拿飯碗去賭。另一方面，Android UI 設計永遠就像工程師自我良好的作品，單獨看每一個元件都很漂亮，可是拼裝起來後感覺就是盤剩菜剩飯，就算換了 UI，也不過只是換了封面罷了，換湯不換藥。 Open Source Project 的開發，最困難的就是修改機制，在很多時候，我們只有能力挖肉，沒能力整骨，畢竟整個 Project 不是我們自己寫的。當然，也因此很多設計是無法加上去的，就算加上去也無法好用。就像現在廠商所提倡的軟硬體垂直整合，雖然我們已經有了硬體與軟體的溝通，但在應用軟體到軟體系統之間，其實更需要有好的垂直整合，否則出現斷層後，就像現在 Android 平板總是說不出的有問題。也難怪有人在罵大多數場商只是把 Open Source Software 隨便放到硬體上就拿出來賣，根本不用心。 我們何不來自己動手寫一個平板系統？ 運用現成的 Open Source Project 為基礎，以 iPad 為學習目標，重新打造一個平板用的作業系統。重要的是，品質要能出貨，又有好的擴充性和可用的底層機制，而不只是用套軟體拉一拉 UI 就完事。 Mandice Flat Project （  http://code.google.com/p/flat ） [ Flat Project ] 就是一個這樣的產物，目標是自己動手打造一個開放的平板環境。（目前已經釋出程式碼的子項目是 GrandPa（視窗管理器），是一個仿 iPad 視窗行為的 3D Window Manager。） Flat 的起源，[ Mandice ] 是這幾年間與不少大大小小廠商合作過案子，已有不少經驗和成果。所以在今年的 [ COSCUP 2011 ] 活動，筆者一時興起，便把過去案子所開發的各種元件抽出來再開發並陸續釋出，這就是 [ Flat Project ] 的由來，當然已經移除不應該公開的商業部份。 後記 順帶一提，今年...

對於檔案操作，坊間已經有太多 Hello World 程式示範過無數次，往往運用簡單的 lseek() 、read() 和 write() 已滿足大多數需求。但在 ARM 與 x86 架構之間，便有些微妙的差異，讓 Hello World 級的範例程式處處失效。的確，很少人真的動手寫一支程式去處理大型檔案，更少人會將這類程式移植跨平台使用。 若發現原本在 x86 上可正常使用 write()/pwrite() 等方式寫入資料，但交叉編譯（Cross-Compile）至 ARM 後，始終無法如預期讀寫資料，那意味著你可能掉進 offset 的陷阱了。 說起來這問題牽涉到 off_t 變數形態的記憶體使用長度，並可分為三個面向探討『Kernel』、『glibc』、『應用程式(Application)』。理論上 Runtime 時，三方對檔案操作的 offset 定義應該是要一樣，但事實上不然，只有在 x86 平台上比較統一。在 ARM 等這類平台，由於各家廠商在製作 BSP 各自定義，各程式和往往預設使用上不盡相同，更主要原因是因為多數應用程式都是從 x86 移殖過來，和 ARM 平台上 32-bit 的預設處理方式會格格不入。 在 x86 架構上（測試環境為 Debian Sid、 Intel Platform），通常 off_t 被定義為 unsigned long long （無號最長整數），總長度是為 8 Bytes（因長度等同 off64_t，下文將 64-bit 的 off_t 以 off64_t 稱之），在此環境下的 gcc+glibc 會自動使用 off64_t 形態做為 offset 處理參數，當然在編譯程式時也會自動使用相對應的處理函數，實作和定義可參考 unistd.h。 而在 ARM 的環境上，卻不一定如此，在某些平台和 BSP 中，off_t 預設就會被定為 32-bit 長度，會造成一些可能發生的問題。 一個例子，若是有寫過 FUSE(Filesystem in User Space) 程式，並移植到 ARM 的經驗，就有機會發現系統上 off_t 定義的大混亂。起因是 libfuse 使用 off64_t 與 kernel/Application 溝通，但若是系統編譯環境預設使用 off_t，我們寫的 filesyste...

近來忙於工作和協助新團隊的建立，付出於 Blog 上的時間也少了許多，不過，雖然在 Blog 上與自己對話的時間減少，但這些日子，卻自我反省甚多。 回想起過去的經歷，總讓一波波湧出來的『資訊新名詞』，將自己不停往岸上沖。這就是資訊業，三天一小變，五天一大變，稍不留神，已改朝換代而擱淺在岩岸上。但在這浪花四起的時代，總不曉得是被誰所欺負。有時欲求助卻會惹一身麻煩，每每都問自己，到底要忍到何時？知道被沖上岸者眾，人人都不甘心，卻也莫可奈何世代交替，也在擔心哪一天自己會被衝上岸。 經過風風雨雨，能體會許多外界不瞭解的心聲；隨『科技業』起舞多時，我們多少也有在第一線立足的經驗和能力。尋思，與其每天趕潮流拼出貨，日日廢寢忘食只為解決沒價值的人為遐疵，何不帶著最新的技術為沉睡多年的前輩們『重新開路』，開一條不孤單的路，開一條喚醒巨龍的路？ 為此，一個全新的台灣車庫團隊 [ Mandice ] 誕生，宗旨『做正確的事(Do the right thing)』，我們不盲目跟從，我們創造和領導新方向。 由於團隊的存活與堅顧理想是無法避免的考量，我們目前的經營三大方向為： 保本 以接案、顧問服務、銷售軟硬體和商業合作為主要訴求 創新 建立商業模式，開發有產業價值或有自身創意之產品 擴展 強健內部團隊技術發展和體制 我們計畫推出的服務項目： 各式軟硬體技術整合顧問服務，讓企業精準做正確決策  代理維護底層軟體系統平台，讓企業專注自身優勢發展  伺服器軟硬體建置支援，協助 IT 系統建設  快速供應完全免授權費的商業用 Linux 作業系統，今天下單明天出貨  量身訂做各式專門用途作業系統，使產品效能和品質兼具  協助將 Linux 系統導入自家產品設計，協助業者迎接資訊新世代 設計並生產自己的概念產品，創造新時代  此外，我們也將投入網路服務的發展和創新，期望在台灣重建網路泡沫化後，各界對網路失去的信心。 當前，如果您有以下需求，您就將會是我們的商業夥伴 想有劃時代資作為的老闆和企業  想將原本的應用轉移至更有機會的平台  需要隨機出貨的免授權作業系統  不想自己養大隊人馬貢奉底層系統  不想傷腦筋卻又必需追新東西的人 燒錢燒到失望...

承年初『 親手打造 HD 多媒體播放器 』所述，小弟有幸於今年 1/23（六）、1/24（日）、3/27（六）、3/28（日），在台中『靜宜大學應數系』開設嵌入式系統實作課程，課程宗旨欲藉由一步步的實作，揭露嵌入式系統開發細節。本課程嘗試避免提及過於深奧的理論和艱澀的名詞，以玩樂中學習並體驗嵌入式系統相關技術。除了實作外，也略微說明相關基礎知識，如：Compiler、 NEON intrinsics 等。 感謝各界參與，本課程已順利結束，有興趣者可自行下載上課簡報檔： http://people.linux.org.tw/~fred/slides/training/hdplayer.pdf

As you know, I've done Android Eclair porting for Devkit8000 in the past, which is based on Embinux. It's a experimental work for passing time, I have no time to maintain and fix bugs friends reported after that. However, I think it is not good because the result will be getting lost as time goes by. 0xdroid is another Android distribution which is different from Embinux, its developer  Jim Huang(jserv)  who has contacted me a few months ago, and he hope that I can try porting 0xdroid on the Devkit8000. Actually, I am glad to make 0xdroid takes over my work, it is the best result for me. Currently, I've done most works, 0xdroid can run on Devkit8000 with success. And also, My patches have been committed to 0xlab-devel mailing list. Because I have another platform SBC8100 which is also produced by Embest, I've done works on that as well. You can see my patches from 0xlab-devel mailing list, or you can visit my website to download it directly: http://people.lin...