Software Cinema

( 修改一下發表時間以及Title 進行實驗 )

根據 Computer World 的一篇報導 : Researchers look to cloud computing to fight malware, 密西根大學的幾位學者 ( Jon Oberheide, Evan Cooke, and Farnam Jahanian ) 嘗試利用不同的 AntiVirus Softwares 利用 Cloud Computing 概念結合來防範 malware, 所打著的算盤當然是截長補短, 讓 virus 或是 malware 需要克服更多的難關. 這跟趨勢最近在講的 Cloud Computing 應用 ( 前幾期的財訊在訪問趨勢某人時有提到比較多, 不過內容同樣不甚具體 ), 應該是不同的方向.

這項計畫稱為 CloudAV ( 應該是 Cloud AntiVirus 之意吧 ? ), 相關網站在這, 同時有電子論文可以抓取. ( 以下圖片均取用自 [1] ) 基本上可疑的 File 會傳送到 ClondAV 所提供的 Network Service 作檢驗, 這跟早期的網路掃毒類似.

看起來最終的決定是採用類似 Voting 的機制, 透過許多 AntiVirus 的結果, 決定是否該 File 是有問題的.

我在去年修 Embedded Middleware 作 Final Project 時有提過類似但不相同的想法 ( 我要集合的不是 AntiVirus Softwares ), 最終是卡在系統本身的 Security 問題, 以及 Privacy 問題. 針對 Privacy 問題, 在 [1] 中 Section 3.1 花了一小段說明, 但是也不算正面回答, 只是透過把 CloudAV 的應用環境作限制, 來降低 Privacy 的影響.

除了 Privacy 之外, 對於 CloudAV 是否能成功, 我還有另一個商業上的疑慮, 雖然 Paper [1] 內有談論了實驗本身所使用的 Software 的 License 問題, 但是在商業應用上不知道是否防毒軟體大廠會同意這樣的使用方式, 或是願意加入這樣的服務團體. 這裡就牽涉到商業利益的問題, 也可能給防毒效益不好的公司帶來更大的壓力.

不過, 往好的方面想, CloudAV 可以克服以往我們幾乎無法在一套系統內裝設兩套防毒軟體的效能問題, 以及 Mobile Device 不方便把資源用來跑 AntiVirus Software 的問題, 同時又能帶來更好更可靠的服務, 只要防毒軟體大廠願意進行類似的合作, 那麼就良性競爭以及防毒技術的進步來說應該是正面的. 這樣的 AntiVirus Cloud 似乎也跟我之前認為 Cloud Computing 會帶來軟體產業的二次分工相關.


References

[1] Jon Oberheide, Evan Cooke, and Farnam Jahanian, "CloudAV: N-Version Antivirus in the Network Cloud," Proc. of the 17th USENIX Security Symposium, July 2008

過去兩三個禮拜 Adeona 忽然變成了一個熱門關鍵字 :p

原因是 Adeona 這個 Open Source Project, 號稱是第一個可以對於你的 Laptop Notebook 進行 Tracking 的 Open Source Software, 對於追回失竊的 Notebook 來說特別有用.

其基本的概念是在 Notebook 上安裝一個 Client Software, 每當 Notebook 連接上網路時, 會自動將該 Notebook 的位置 ( IP 以及相對存取周遭網路設備的位置 ) 進行 AES 加密後, 利用 OpenDHT 技術存到特定的 Server 上, 該加密過後的位置資料只有原始擁有者可以開啟, 如此一來 Notebook 的擁有者就可以對於 Notebook 的位置進行追蹤, 並確保自己的隱私.

關於 Privacy 部份, 事實上 Adeona 作的考量更多, 包含無法簡單透過 Location Update 去鎖定特定的 Device 等等, 務求達成 Anonymous, Unlinkable Updates, 詳細內容請見 Adeona 的發表 Paper , 在講述 System Goal 的部份有列舉說明.

我之所以覺得 Adeona 很恐怖是因為, 同樣的概念幾乎可以用在任何可以運作 Software 的地方(或東西). 甚至我可以說, 一般 Notebook 並非 Adeona 最好的利用環境. 理由是一般 Notebook 或是 Laptop 的系統都很容易被重新安裝或是修改. 重新安裝會使得 Adeona 失去作用, 而修改則可能使得竊賊進一步利用 Adeona 對於追蹤進行欺騙.

反倒是其他的高價物品, 利用 Adeona 的可能性以及有效性極高. 例如在無線環境下的汽機車, 高單價的 Mobile Device, 重要的文件盒保險箱等等 ( 不用再害怕忘在公車或是計程車上摟 ). 可以簡單把 Adeona 作成一個具無線網路功能的訊息送出嵌入式設備, 讓使用者自行安裝在要追蹤的物品上. 這種嵌入式系統就可以避免掉上述的問題, 只要不被從保護物品上拆除就好. ( 使用者可以裝在很隱密, 或是無法拆除的地方 ). 從這個角度來看, 其實跟 RFID 又有點像, 但是安全性以及範圍又比 RFID 大很多.

而除了這些可能之外, 最恐怖的是, Adeona 也可能被裝在 Software 或是 Data 身上, 讓我們可以對於 Software 或是 Data 的 Distribution 作追蹤, 例如公司內重要的電子文件管理, 怎樣確保每一份被複製的重要文件, 沒有在允許以外的地方被開啟.

這樣一想, Adeona 的概念幾乎可以用在任何地方, 這能不恐怖嗎, 光用想的我雞皮疙瘩就起來了 = =

上學期修課跟學弟合作的一個期末計畫是建立一個巴士系統的 Embedded Middleware. 目前這東西也慢慢延伸變成學弟的 Master Research. 在整個 Vision 中, 有一部分就是關連到即時地蒐集巴士系統中 Customer 相關的資訊, 以及整理分析這些資訊, 產生出足以作為決策支援的資訊 ( Structured Information ).

類似的東西已經開始有人用 GPS 得到的資料做出 Prototype 來摟.

6/22 的 NY Times 報導了此一 Prototype : Predicting Where You’ll Go and What You’ll Like , 由 Sense Networks 這家公司開發 ( 我覺得他們名字取得不錯 ) . 基本概念是利用 GPS 得到 Location Data 以及 Movement Data, 然後透過適當的 Mining Algorithm 分析, 就可能得到關於行為模式的猜測結論. 在文章中期時也提到, 可以用來被追蹤 (Track) 的東西很多, 不見得只有 Location 可以用來追蹤猜測人們的行為. ( 以下圖片引用自 Sense Network Media Center 公開資料, 上面還有 Vedio 可以下載 )


Realtime Data Mining 技術本身其實不是困難點, 困難的是怎樣讓整個 Process 可以真正應用到商業行為中使用. 期間需要考量的, 整合各種軟硬體設施, 同時城市無線網路的基礎也不可或缺. 另外就是使用者願意曝露自身資料的意願.

不過從過去的成功經驗來看, 其實這個世界的人們對於自身的資料隱私其實不是真的那麼在意 -- 只要有利可圖的話.

Sense Network 做出了很合理且聰明的決定, 他們不是一廂情願的向使用者買 Data 或是期望使用者會自動主動提供資料. 而是利用提供給使用者相關服務來換取資料 ( 原文為 : Sense decided to trade services for data. ) 而 Sense Network 自然可以從操作廣告以及服務之間得到適當的利益. 從 Google 以來, 這似乎已經是 Web 2.0 唯一具有足夠商業成功案例的模式了.

但是 Sense Network 是否能夠獲得足夠久的成功卻還很難說, 相當仰賴於他們的商業操作手段. 使用者的 Location 資料並非是會有長久價值的資料, 其 Lifecycle 可能只有短短的數個小時, 因此 Sense Network 不可能像是某些 Blog Supplier 一樣透過累積大量的懶惰使用者讓自己不倒, 而就算是在 使用者 <-> 手持裝置 <-> 位置及其他資料 <-> 可得服務 的 Cycle 中, Sense Network 也不是居在任何不可取代的位置. 因此一切都還很難說.

唯一能肯定的是 Realtime Mining 相關應用的這個趨勢應該確實會發生.

又是一個 Physical / Virtual World 融合的例子. MIT 的 Quickies 計畫把 Post-it 數位化, 主要利用 RFID, AI, OCR 辨識, Context-Awareness & Knowledge Reasoning 等等技術. 在特殊的撰寫紙條 ( Sticky Notes ) 上裝有 RFID, 因此可以進行追蹤管理, 同時利用 Digital Pen 在撰寫紙條寫字, 可以自動把內容擷取到 PC 上, 透過 OCR 進行內容辨認, 最後利用 Knowledge Reasoning 以及 AI 決定 PC 會相對應自動採取哪些動作.


在 Project 網頁上也寫了 :

The project explores how the use of RFID, Artificial Intelligence and ink recognition technologies can make it possible to create intelligent sticky notes that can be searched, located, can send reminders and messages, and more broadly, can help us to seamlessly connect our physical and digital worlds.

個人認為重點在於最後的一句話. 從這句可以看出 Quickies 的 Power 在於自動把現實生活中的物件, "拷貝" 進 PC 的虛擬世界中的能力.

Quickies 的 Data Flow 架構設計可以參考下圖 ( 以下各圖均取自 [1] )


整個流程包含 :

1. Sticky Notes 透過 Digital Pen 以及 RFID 將資訊輸入到系統中, 先以原始資料存在,
   
2. 而後再利用手寫辨識 ( Handwriting Recognition ) 轉換成為電腦可辨識文字訊息,
   
3. 之後在螢幕上以便條紙的形式把訊息 Show 出來,
   
4. 同時透過 Context-Awareness 系統以及 Commonsense Inference Engine ( 我的專長之一 :P ) 推論出相關的 Knowledge, 以及之後可能需要啟動的相關軟體服務,
5. 最後透過一個 Mediator 把相關資料傳給所有負責進行服務的軟硬體.
   

其實在過程中用到的技術都已經是被開發出來的, 並沒有甚麼十分創新的技術在裡面, 但是整合起來的結果卻是一項十分便利的準科技產品. 同時 User Interface 也很漂亮, 我之前用過的 Post-it Software 都很醜, 不管是 Windows 上或是 Linux 上得, 光是這個 User Interface 其實就足以獨立變成一個很吸引人的 Desktop Software 了.


其實我覺得除了 Post-it 本身的使用方式, 以及利用 RFID 對物品作追蹤管理之外, MIT 的 Quickies 還有一個可能十分強大的應用 : 作為 Smart Home 的命令輸入器. 過去 Smart Home 的命令輸入還是以遙控器類型的為主, 語音辨識會有口語差異大, 各語言辨識轉譯, 以及因為生病等因素導致腔調改變的問題. 而 MIT Quickies 其實可以作為一個短期內 ( 可能是四五年左右 ) 可以接受的過渡性產品. 大部分語言的手寫辨識其實已經有一定的辨識完成度, 因此技術挑戰比語音辨識來的小. 只要會寫字, 甚至會畫圖, 就可以控制 Smart Home 了.

另外值得一提的是, 這個計畫可能有台灣人參與過一部分的作業. 在 Paper [1] 的感謝欄中, 提到了一位 Dawsen Hwang :

Acknowledgements
We thank Professor Hiroshi Ishii and Professor Henry Lieberman for their valuable feedback and comments. We would also like to thank Dawsen Hwang of NTU and the fellow MIT Media Lab members who have contributed ideas and time to this research.

很用力的透過 Google 查了一下, 應該是台大電機 108 級 ( 還是 109 級? ) 的黃道生 ( Dawsen Hwang ), 不過不知道怎樣跟 MIT 搭上關係, 可能是交換學生, 或是畢業後到 MIT 繼續攻讀學位了吧. 不管怎樣從 Google 到的資料可以看出也是強者一名就是了.


References

[1]Pranav Mistry and Pattie Maes, "Quickies: Intelligent Sticky Notes," Proceedings of 4th International Conference on Intelligent Environments (IE08). Seattle, USA. 2008

我必須承認, 儘管之前略聞 OLPC 帶來的爭議, 在今天看到這篇 One Laptop Per Child Foundation No Longer a Disruptive Force 之前, 我沒有好好想過 OLPC 本身可能的負面影響.

Walter Bender : I would challenge that as being the critical dependency. I think doing it was critical, because it’s not real until you do it. We’ve demonstrated that this can be done. We’ve gotten the world to be interested in doing it. Now we have to let more people participate in the doing and not try to control it and own it.

在此篇文章中訪問了 Walter Bender, 前 OLPC 軟體與內容管理主要決策者, 提到他所離開 OLPC 開發的一些主要原因, 包含與其他人對於 OLPC 未來方向的意見不合, 以及他的擔憂. 不過這當然是一方之詞, 姑且聽聽即可. 重要的是在這篇文章說提到許多 OLPC 可能帶來的強迫性文化衝擊, 特別是在文章的後半段.

如果以造成的影響來計量, OLPC 硬體本身鄉對於軟體以及內容來說其實是很小的. 然而誰會是軟體以及內容的主要供應商 ? 此供應商將有機會直接面對世界的未來 -- 小孩子們. 你說內容可以透過成立公正的第三方教育審核進行檢驗, 但是有些東西是你無法塞檢的. 比方說 Operating System & Desktop System. 這就好比我們提供給小孩子的文化基礎教育, 有些東西一旦根深, 就很難拔除.

OLPC 究竟會帶來自由, 還是帶走自由 ? 這將是需要被深思的問題.

在癮科技看到的秤重湯匙, 理所當然是一個 Embedded System. 不過不知道它如何解決清洗的問題. 其他像是 Wearable Devices, 或是內建播放器的衣服之類的, 也是會面臨怎樣清洗的問題....... 不過這跟 Software 關係就不大了....... 吧 ?


倒是, 要不要也作個碗, 上面會顯示碗內東西的預估熱量, 營養成份表呢 ? 像是國內外都有學者在研發的電子餐盤之類的, 可以比較準確的控制自己的飲食. 然後廚房裡的東西大大小小都給他 Embedded System 一下, 以後什麼東西都沒辦法偷吃了, 電影裡胖女孩晚上偷偷下樓吃火腿的橋段也將不復存在了 = =

未來我們的生活跟文化會怎樣真是難以想像阿. 最近的日劇潘朵拉, 男主角在發明了完全抗癌藥物後, 他的老師第一個就跟他說, 東西不是發明了就急著詔告世人, 要想想他對於整個世界未來的影響, 跟這是一模一樣的阿.

剛剛在 癮科技 看到這篇新聞介紹 : Vodafone將推出Otello圖片搜尋服務 , 簡短介紹 Otello 的服務以及使用方式. 覺得相當有趣的是, 在 Otello 的使用情境 ( usage scenario ) 下, 我們只需要利用既有的各種可進行數位攝影的 device 就能夠進行相關資訊的搜尋, 間接的把搜尋引擎 ( search engine ) 嵌入 ( embed ) 在 device 上變為一種 "service" 的概念, 而不是一個 "software" 或是 "website".


這樣的使用方式無疑地是更符合以及簡化我們的使用習慣. 原本我們就希望看到的東西到進行搜尋之間可以是無縫地進行, 而不是還要把圖片存下, 然後上傳到某個圖片搜尋引擎再進行搜尋, 這樣分開使用不同的 services 實在是太麻煩了.

而很容易聯想到的, Otello 現在支援圖片的搜尋, 未來如果結合光學辨識技術 ( OCR ), 要能夠直接把看到的文字用來搜尋應該也不會是甚麼難事. Seeing is Searching, it's cool !!

今天看到某家電動刮鬍刀公司的廣告, 加上手上正在改一篇 Biosignal database 的 paper, 再加上好歹我也算有在作 context-aware 主題, 忽然想到以後是否會有廠商嘗試在電動刮鬍刀上加上完全無關的 biosignal detection device ?

像是這樣 : ( 自 PCHome 購物借用一下德國百靈的商品樣品圖片 )


在括鬍刀片附近, 接觸到下巴臉皮的部份, 可以設置偵測皮膚狀況的 sensor, 在再下方一點可以設置嘴巴氣味的 sensor. 手握的部份, 拇指接觸的部份可以裝設 pulse meter, 側邊可以設置 body temperature meter. 以上這些都跟電動刮鬍刀本身的功能無關, 但是透過電動刮鬍刀本身的 hardware interface, 轉化成為其他 biosignal detection devices 的 interface, 進而把這些 biosignal detection devices "嵌入" ( embed ) 在電動刮鬍刀上.

或許電動刮鬍刀本身不是一個理想的 "母體", 同樣的概念也可以用在其他的日常電氣用品上, 進而讓我們可以在最小的 user interface intrusion 之下, 享受 embedded system 帶來的嶄新服務.

剛剛看到一份寫法有趣的投影片 " MIS 進化論, 綠化你的工作 ", 作者是 KnightFeng (馮正青), 主題在提倡全綠化系統. 詳細內容在投影片中寫的很清楚了, 在此不多說. 此處所謂的全綠化系統很顯然的是只全由 portable components 所組成的系統.


正如投影片中所舉出的已綠化軟體實例, 有大量的常用軟體事實上都可以找到綠化的版本. 然而應用程式與系統環境作綠化切割只是第一步, 我認為比較困難的部份是再把 data 的部份切割出來, 以及整體軟硬體系統的支援. 綠色軟體除了一般認為的體積小, 佔用系統資源少, 以及不需要在系統環境中留下拖慢系統速度的無用資訊之外, 如果會與系統中的 data 有很強的相依關係, 在我看來仍舊跟以前一樣, 是不能夠在不喜歡它的時候, 很爽快地進行 " 分手 ".

另外整體軟硬體系統的支援也是帶起流行的重要因素之一. 目前的環境中, 大部分人還是習慣使用自己的一台 PC, 或是 Notebook, 上面再安裝各種軟體. 這種情況下其實綠色軟體能發揮的優點有限. 但是全綠色系統的好處在於整個系統組成的 Flexibility, 以及我們對於軟體進行選擇的 Freedom. 這方面相關的進展我認為包含投影片中提到的 OLPC, 以及前一陣子有 announcement 的 BUG Labs. 特別是 BUG Labs, 可以想見上面的軟體其實都應該在某個程度上符合綠色軟體的定義.

不曉得到那時候, 過去在 Software Engineering 前期鮮少受到重視的 Portability properties, 會不會變成一個 "Embedded (must-have) Property".

上禮拜到台北參加嵌入式軟體聯盟 (ESW) 成果發表會議, 順便回家幾天, 第一次用新的捷運電子硬幣, 覺得很新奇, 之前都只有用悠遊卡, 很久沒有用自動售票機. 在捷運上無聊, 邊玩著電子硬幣, 邊想東想西, 想到了一個可能的 cheating 方式 :

基本上台北捷運的票 (或是電子硬幣) 在購買時是沒有起點終點的分別的, 換句話說電子硬幣代表的只是一種代用貨幣, 每個電子硬幣有獨特 ID 作為辨識, 但是沒有使用者身份辨識的功能.

於是假設以下的情況 (如下圖), 現在有 A, B, C, D 四站在同一條路線上, A 站到 B 站需要 20 元, A 站到 C 站需要 25 元, 而 D 站到 C 站需要 20 元, D 站到 B 站需要 25 元. 現在有某甲要從 A 站到 C 站, 某乙要從 D 站到 B 站, 他們各自需要花 25 元, 捷運公司總收入為 50 元.
是否他們可以花更少的錢到達他們的目的地呢 ?

考慮以下的策略

1. 甲在 A 站花 20 元買電子硬幣 EC-01 , 乙在 B 站花 20 元買電子硬幣 EC-02 ( EC-01 以及 EC-02 為電子硬幣 ID )
   
2. 甲坐到 B 站先下車, 乙同樣坐到 B 站下車
3. 甲乙交換電子硬幣, 此後甲持有 EC-02, 乙持有 EC-01
4. 乙直接在 B 站使用 EC-01 出站
5. 甲繼續坐到 C 站使用 EC-02 出站

這樣的結果就變成甲乙各自只需要花 20 元, 而捷運公司的總收入變為 40 元. 很顯然地, 這對於捷運公司來說是一個 security threat, 它的收益因為這樣的策略而受到了損失.

當然要對付這樣的問題, 台北捷運可以在電子硬幣上加上起點終點站的資訊, 但是這樣一來在自動售票, 以及出入站的補票程序就會複雜許多, 想當然而就會導致 usability 以及 performance 的降低, 對於乘客流動量大的部份大站來說, 這是個無法承受的問題.

因此我想捷運公司當初在規劃時 MRT 系統時, 在這部份應該是假設不會有人為了省這一點錢很麻煩的作這種事, 畢竟要找到兩個人以上作這種配合也不容易, 況且全線價差也不超過 30 元, 在時間計算上怎樣也不划算, 所以就允許此 security threat 存在, 這是在與 usability 以及 performance 權衡下的結果. 當然, 最終還是為了整個系統營運的利益考量, 允許這個 security threat 的存在對於系統利益在台北捷運的 context 下才是最好的選擇.

相對來說, 如果今天不是發生在乘客流動量如此大的地方, 就很可能會採用含有起點終點資訊的電子硬幣. 此時對於 usability 以及 performance 的衝擊就會小許多.

最近在寫 Embedded Middleware Design 課程的 final project, 有一部分 client 的程式要在 Mobile Devices 上運作, 直接拿實驗室有的 Nokia N95 來嘗試. 如果可以的話當然希望可以用 Python 開發, 嘗試上比較快. 整理一些找到的資源在這篇中.

Nokia N95 應該算是對於開發環境支援度蠻高的智慧型手機吧 (沒辦法, 實驗室沒有 OpenMoko), 至少他有 Python 的支援.

Nokia N95 程式開發相關特徵 :

• Symbian 作業系統 S60 V3.1
• 支援 A2DP 藍芽、紅外線、WiFi、UPnP 連接
• 內建 GPS 模組

N95 上也有類似 Wii 的 Motion Sensing 功能, 在網路上可以找到有人把 N95 當成遙控車的操縱器的影片, 藉由旋轉以及移動 N95 來控制遙控車的移動. 同時在 N95 上有一個吞食蛇的遊戲可以透過轉動手機來玩, 不過我沒有找到操控 Motion Sensing 更多詳細的資料, 就先略過.

另外 Nokia 也提供 Nokia S60 SDK, 包含在 Symbian S60 上開發程式用的相關函式庫以及模擬器, 但是模擬器僅支援 C++, 對於 Java 需要額外的 J2ME SDK 安裝, 同時模擬器對於 Python for S60 目前並無支援.

Python for S60 是一個由 Nokia 主導, 以 Open Source 形式發展的計畫, 目的在於 Symbian S60 上提供 Python 的執行環境. 在一些 packages 上, 特別是 UI 部分, Python for S60 有自己的實作, 並無法採用一般環境下的 Python packages.

其他相關的網路資源略為整理如下 :

• PyS60 SDK
• To install PyS60 SDK, you will need Py2exe
• Look carefully, there is also a well-written SDK API document for download
• To get PyS60 to work, the S60 3rd Edition SDK for Symbian OS for C++ is pre-required
• To install PyS60 3rd Ed SDK for C++, you need Perl at least version 5.6.1

• PyS60 Code Snippets
• You can learn some skills and get some examples from here

• Nokia Open Source Wiki
• Python for S60
• PyS60 Applications
• PyS60 Documentation

• Ensymble
• Some people believe that Ensymble is a better choice than using Py2SIS alone
• Ensymble can support Py2SIS by using command :
  
• $ python ensymble.py ps2sis target-file.py

• Book : Mobile Python (真想買)
  
• Mobile Python official site
• 網頁內有一些 example codes, 沒錢買書應該也可以抓下來試試看.
  

不過如果可以直接在手機上 run Python for Linux 其實開發上會更容易吧, 只是 performance 問題是否影響很大就不得而知.

不過我的嘗試以失敗告終, 因為不知道為什麼, 使用 Python for S60 撰寫的程式在 N95 實機執行時居然無論輸出的是中文還是英文都會變成方塊字, 左試右試也解決不了, 鑑於時間壓力下只好在 prototyping 時先採用 J2ME 進行開發, Python 就只好看看之後是不是能克服這個技術問題了.

前幾天寫了關於 BUG Labs 的一些觀察, 剛好這兩天因為 Lab meeting 的緣故看了一篇文章, 是 Dirk Riehle 的 "The Economic Motivation of Open Source Software : Stakeholder Perspectives" [1]. 在文章的前半段, 作者用了兩張圖來解釋 open source 對於 software company 獲利的影響.

第一張圖 ( referred and re-drawed from [1] ) 如下, 橫軸是潛在的願意購買 customer 數目, 縱軸是 customer 需要付出的價錢. 一個完整的 product 是由 hardware, software, 以及 services 所構成, 而非單只有其中一者. Customer 的需求被 modeling 成為一條曲線 ( 雖然圖上是一條直線, 不過這只是示意圖 ). 當 open source 被引入 software 那個區塊時, 由於對於整體 product 來說, 軟體的研發製作成本降低了, 因此在維持原售價的情況下, software company 可以從每個 customer 身上獲得的利潤就會增加.

而假使 software company 的利潤完全來自於 service, 而不包含販賣 hardware 以及 software 時可能獲得的利潤, 這時整個 hardware 以及 software 的兩個部份對於 product 就是完全的成本而已. 那麼扣掉 service cost, 剩下的就是 software company 可以獲得的 service profit.

當然 service profit 會根據最後的 service 定價而定, 假設 service 最低價要高於所有的成本, 那們我們就可以在成本與 customer 需求曲線之間括出一塊可以獲利的區域, 在下圖左中以灰色區域標示. 當 open source 取代原本的 software 區塊後, 可以想見的, 因為成本降低, 因此可獲利區域也就隨之增大. 同時藉由價格的調降, 負擔得起該 service 售價的 customer 將會變多, 亦即相對市場就可以變大. 這是下圖右的說明.

在 [1] 中並未討論到 hardware 的問題. 而如果我們考量 BUG Labs 的願景, 以及所謂 open source hardware 的想法, 很有可能我們可以基於 open source software 之上, 把成本再一次地降低, 使得更多的人可以負擔起一樣的 service.

下圖左是只有 open source software 的樣子, 下圖右把 hardware 部份用 BUG Labs 取代, 由於硬體部份不再需要一個整體性的產品, 而是可以讓 customer 根據自己的需要選購適用的硬體, 電子製造商將沒有辦法將電子產品的硬體規格掌握在手中, 因此我認為這部份的成本可以降低. ( 事實上也可能帶動 open source software 部份的成本再度降低, 因為 open source software/hardware 的整合會在 project 中完成, 不需要採用者額外進行, 但這裡先不考量這一點 )

很顯然的, 所帶出的結果就是 service profit 的可調整空間再度變大, 同時有意願購買, 也有能力購買的潛在 customer 市場也變得越大. 對於 customer 來說, 將可以用更加便宜 (或者該說是更加有彈性) 的購買方案, 來獲得需要的 service.
同時在這樣的市場中, Long Tail 的效應可能會更加明顯, 因為新的 service 未必一定要搭配新的 hardware, 在目前的市場中受限於電子製造商, 使得我們要換 service 好像就一定要買新的 device, 手機就是一個很明顯的例子 (如果我可以把現在手機的 300 萬畫素攝影模組移到新手機, 我就不用買新手機的 600 萬畫素模組, 我只需要 300 萬畫素的就夠用了 ).

References

[1] Dirk Riehle, "The Economic Motivation of Open Source Software : Stakeholder Perspectives," IEEE Software, pp.25-32, April 2007

在說到 BUG Labs 之前, 先看看這張圖 (取用自 BUG Labs 公開可用圖庫) :


這張圖是什麼 ? 看起來有點像一些小積木疊在一起, 然後用線連著, 然後每堆好像長的不太一樣. 每堆中好像都有一個比較特殊的, 邊邊帶有灰色矩形的積木存在. 其他就不一定. 這是什麼 ?

身為 software scientist (it this term exist) 以及 hacker, 我們看到一個喜歡 software 時往往會首先想到兩件事, 第一是 : 這東西怎樣運作的, 第二個是 : 我要怎樣把他改成可以跟我手邊的其他 software 合作. 一般的使用者不會這樣想是因為, 一般使用者難以認識到內部的運作, 從而即便想了第二個問題, 也沒辦法用自己的能力讓想法實現.

而 BUG Labs, 就是想要讓這樣的事情變成可能.

BUG Labs 採用 Lego 積木的想法, 把 computer 拆解成數個方塊, 每一個方塊上具有一個或是數個 services, 例如 GPS 應用, 數位攝影機, Webcam, LCD 小螢幕, 或是鍵盤. 同時 BUG Labs 提供一塊小小的 motherboard, 讓你可以自由地把這些方塊插上去.

BUG Labs 的 product 網頁上給了一個例子 :

For example, with BUG, you can easily assemble and program a GPS + digital camera device that automatically publishes geo-tagged photos as a web service. Integrating with an online photo-sharing service like Flickr is only a few more lines of code away, and now you have your own real-time, connected traffic-enabled mobile Webcam!

這樣的想法並非全新, 至少在 software 領域, component-based software development (CBSD) 的發展已久, 即便是後來的 service computing 也預計會朝同樣的路走下去. 而在實際的產品上, 我記得已經有教育性的產品是透過 USB port 標準, 可以把不同的 software 事先安裝在 USB 上, 然後孩子用的主機不需要進行軟體安裝, 而是透過主機上數十個 USB port, 匯入不同的 softwares 共同運作. 但是相對來說 performance 就不適合一般使用.

而 BUG Labs 應該是在非教育領域, 第一個把這樣的概念具體化成為一般消費用商品, 並公開展示的公司. 歐, 我沒有提到更棒的是, 他們希望是採用 open source software / hardware 的概念來推廣.

在每一個方塊內當然會有相對的 software 可以提供 service, 同時也可能有必要的 operating system 在裡面. 不同的方塊之間基本上透過 OSGi 進行 communication. ( 但由於 OSGi 的 license 問題, 使得 BUG Labs 無法直接使用 OSGi 的 source, 否則對於他們的 open source 計畫會造成阻礙, 於是他們重寫了 OSGi 的 implementation [1]) 然而使用者並不需要了解這些, 使用者只需要把他們想要的某項 application, 所需要的方塊都插到 motherboard 上就好了.

需要知道這些的是 service developer, 可能是 open source community 的人, 也可能是 commercial company 的人. 透過 BUG Labs 提供的 motherboard 作為 platform, 開發者同樣是專注在本來他想提供的 service 就好, 其他的部分是從 BUG Labs community 內可以找到的其他方塊來提供. 這也是上面第一張圖所代表的意義之一.

然而看著上面第二第三張圖, 還是會有個疑問, 看起來只有四個槽, 如果需要安裝比較多的方塊, 怎麼辦呢 ? 我想這應該可以回到第一張圖, 誰說 motherboard 上不能再接 motherboard ? 或者我可以在不同的 motherboard 之間透過 wireless 連接溝通, 一樣可以應付需要更多方塊的情況.

然而 BUG Labs 是否能夠成功仍然有很大的疑慮, 我想他們選擇 open source community 作為主要合作對象應該也是希望可以解決一些關鍵問題. 提供以及制定 motherboard 倒不是問題, 而是這樣的使用方式基本上相對於目前主流電子產品來說有別. 目前主流電子產品製造權是掌控在電子製造商手裡的, 而且軟硬體都是. 看看如果你想改造 iPod, 會遇到哪些完全是非技術性的限制. 而 BUG Labs 的產品完全是顛覆 (disturb) 目前的產品線. 在 BUG Labs 的 vision 下, 消費者才是最終決定手上的 product 長什麼樣子的人 (軟硬體都是), 而非目前的電子製造商.

但顯然地, 這需要大量的軟硬體開發支援, 特別是 software 部分. 如果可以替換的 software service 太少, 則 BUG Labs 的 motherboards 是完全沒有意義的. 透過 open source community 的生產力以及創造力, 能夠幫助 BUG Labs 把他們的 motherboard 之可能性發揮到最大. 同時究竟消費者會希望 BUG Labs 的產品以什麼樣貌展現, 也正在進行調查中 [1].

在通往成功的路上, BUG Labs 還有很長一段要走. 但是以我們小小工程師的角度來說, 身為 BUG Labs 的一份子, 手上握著足以顛覆世界的想法以及產品, 真的是作夢也會笑阿 :)

References

[1] David Cohn@DigiDave, "Evolving from Larvae To Bug Lab: The Rise of Open Source Hardware," URL : http://www.digidave.org/adventures_in_freelancing/2007/11/evolving-from-l.html

記得在五年前吧, 當時台北捷運剛剛落成不久, 恰好搭上城市無線網路以及寬頻資訊的夢想起飛, 於是在台北捷運內以及台北火車站就出現了兩個後來被證明沒什用的東西 [1]. 一個是捷運生活站, 一個是無線上網桌.

無線上網桌的立意是認為許多現代(當時)台北市民是帶著 Notebook 到處走的, 特別是上班族, 在捷運站內已經有提供無線網路的情況下, 當然會希望手上有 Notebook 的市民如需要收收信件之類的可以利用無線網路. 但是 Notebook 沒有乾淨平坦的地方可以放置, 在使用上是非常不便的. 當時我覺得立意還不錯, 只是看到設立的點少之又少, 不免覺得奇怪, 如果真的評估有此需要, 如此少的設點不會造成供不應求嗎 ?

當然後來的情況證明我錯了, 也顯示出事前的評估, 相關單位應該沒有認真作過調查, 只是提出個看起來覺得不錯, 但是實際上卻沒人要用的方案 (找了許久終於找到有人用的照片了: 看這篇文章). 捷運生活站也是一樣, 我還沒有看過有人用過 ^^b

現在好啦, 就在大家邊用各種 Mobile PC 邊抱怨畫面太小, 操作介面太小, 接鍵盤很不方便, 可攜帶曲捲式的軟鍵盤很難按...blahblah...終於 ! 首先, 我們有了這個 : (圖片來自於 forwarding email, 很抱歉我查了很久查不到出處)



上面的是日本公司的產品, 但是記得幾年前看到的最初 prototype 是印度公司首先做出來的.

然後呢, 我們又有了這個 ( pictures are referred from here [2] ) :


好吧, 雖然說我連他怎樣投射出影像來的都看不清楚, 但是我承認我還真想要這兩個東西...我相信應該很多人也會想要.

如果在不久的將來, 可能是一年內, 這些東西成功量產, 商品化了, 似乎人手一台的可能性也頗高. 這樣我們是不是也要針對這些應用建造公共設施呢 ? 畢竟投影的鍵盤也是需要略為平坦乾淨的平面阿, 畫面的投影也不是隨片找個花花的牆就可以, 如果我們再考慮到 privacy 呢 ? 會不會以後在捷運站看到把平常沒在用的臨時投票所拿出來擺在那裡給大家用, 有點像是公共廁所的公共電腦室 ^^b. 而...會有人用嗎 ?

而這些應用的另一個有趣的觀點是, 似乎電腦的硬體部分逐漸真正的 "embed" 到城市的硬體設施裡了, 而不再是大家需要隨身帶著走的東西. 以後我們待在身上的是屬於自己的 software, 以及 private data, 但是 hardware 卻是利用公共設施來作為 software 的載體, 大部分的 hardware 我們都可以不用再買了. 考慮到產業界會有的轉變, 這是個近在咫呎, 非常有意思的未來.

選擇 software 這條路, 的確是蘊藏著無限的可能 :)


References

[1] 慕容理深, "道具、玩具、證據," URL : http://blog.roodo.com/elysii/archives/3577609.html
[2] Long Tran, "Projection Mobile Phones," URL : http://www.yankodesign.com/index.php/2007/10/16/projection-mobile-phones/

最近EeePC 的在台灣上市導致了蠻有趣的現象, 雖然 ASUS 宣傳是以給年長者跟小孩為主, 但是台灣購買的顧客群卻以年輕人及上班族居多, 這是在看完了整個 Mobile01 [3] 相關討論, 以及 Ptt, 其他討論網站後得到的結論. 然而這只是一個現象, 究竟 ASUS 對於 EeePC 的定位是怎樣看待, 這只是一個過度期的產品, 或是未來幾年 ASUS 會持續支援推廣的產品呢 ? 特別是, 從我們作 software 的眼光來看, EeePC 又是怎樣的東西 ?

1. Hardware Perspective

下表是 ASUS 公開的 Eee PC specification, 分為四種, 但是差別只在硬碟容量跟 Webcam.

另外在 CPU 的 frequency 上, 為了 battery 使用時間可以延長, 以及機體散熱考量, ASUS 在機器出廠前把 frequency 限制在 630 Mhz (70 倍頻), 而且目前的 BIOS 版本無法調整回 900 Mhz (100 倍頻). 以 hardware 的角度來說, 我認為是 downgrade PC.



2.User Interface Perspective

從 software user interface 的角度來說, 我倒認為是 upgrade mobile device.(以下圖片取自 ASUS EeePC 官方網站說明)

EeePC 的 software user interface 設計跟既有的 hand-held PC 以及 mobile device 比較接近, 是以 Task-Orientation 以及 Workspace 的概念去設計. 其目的就在於讓使用者以較為直覺的方式直接使用 software 的 service 完成 task. 而 EeePC 本身的 hardware 條件使得同樣的設計在 usability 上會更好.

然而以最近的新聞表示 ASUS 也將與 Microsoft 合作提供搭配Microsoft Windows 的 EeePC 版本, 這就應該只是單純的商業運作考量. 但換個角度來說, 也顯示出 EeePC 與 UMPC, OLPC [4][5] 之間在 flexibility 之間的差異. 然而, 無論如何這些東西都還稱不上是創造了一個新的 usage paradigm [6] 就是了.


3.Utilization Perspective

ASUS 自身對於 EeePC 的宣傳標語是, Easy to Learn (易學)、Easy to Play (易玩)、Easy to Work (易攜帶), 換句話說他們希望 Customer 看到這些標語時, 是去跟手上已經有的 Desktop PC 或是 Notebook 作比較, 而 Customer 手上的這些 PCs 則是 Hard to Learn、Hard to Play、Hard to Work. 從這個角度來說, 是以 Customer 的 Utilization 作為根據推出產品.

而再以 User Interface Design 來說, EeePC 雖然採用 Debian 系列的 Linux (嚴格來說是 Xandros Linux), 但是並非直接採用 Desktop Linux 版本, 而是刻意作了不少修改, 使得在 User Interface 呈現上是以 Task-Orientation 的方式, 切割成為數個 Workspace, 明確地讓使用者意識到隨著使用的目的而切換 Workspace.顯然有別於 Desktop Linux 或是 Microsoft Windows Desktop 版本的做法. 從這個角度看也是著眼大部分 EeePC 的目標 Customer, 其所會利用 EeePC 所進行的工作, 並不需要 Desktop 環境才能進行, 透過規劃好的 Workspace, 反而更能有效率. (不過看起很多人拿到 EeePC 的第一件事就是把他灌回 Windows XP, 究竟是真的 ASUS 原先設計的 interface 不好使用, 或是中 Windows 毒太深, 或是害怕接受新事物呢 ? )


4. Software Perspective

接續上面的說法, 我認為 EeePC 是在 補上失落的環節 , 在 Desktop PC 獲得巨大成功, 並且快速朝著更高效能的道路上發展時, Palm Pilot 的成功帶起了 hand-held PC 的相關開發, 乃至於後來的 PDA, Smart Phone, 近期的 iPhone 等等, 在 Desktop PC 到這些 Mobile Device 之間, 我們經歷了極為快速的一次跳躍. 而這兩邊卻又朝著各自的方向在發展.

當許多檢討的聲音出現, 討論這些 mobile device 的能力限制, 以及 desktop PC 的 power 缺乏有效的利用之同時, UMPC 以及 OLPC 嘗試回頭去補這兩者之間的落差. UMPC 在我看來是以強化 hand-held PC 的方式去補, 而 OLPC 則是以限定應用領域 (Education) 的方式去補. 而 ASUS 的 EeePC, 則是選擇了以弱化 Desktop PC 以及 Notebook 的方式去補. 這三者會有不同的考量以及限制.

如下圖所示, 拜 Web Application 風潮所致, 許多傳統上需要在 Desktop PC 上執行的 softwares [1][2], 例如 Office Suite, GIS software, Multimedia/Image/Graphic Processing software 等等, 都開始可以以較少的運算能力需求或是資源需求來滿足, 只要能夠有 Web browser, 或是能夠裝上 client 端軟體就行. 然而這些軟體還是有其他需要被滿足的需求, 例如 Office Suite 還是需要 keyboard 才方便作輸入 (手寫的便利性以及速度還不算成熟), 而 GIS 在過小的螢幕上使用及觀看也極為不便. 而因應這樣的需求, Notebook 固然可以滿足, 但是 Notebook 仍然是太過於 powerful 了, 同時在體積跟重量上也比較不便. 而 EeePC 從 software 觀點來看, 卻正好補足了這一塊.

EeePC 的選擇使得她有機會針對不同的使用者族群, 利用不同的 software combination 去滿足, 我想這可能是 UMPC 以及 OLPC 所作不到的.

References

[1] Stan Schroeder, "Big WebOS roundup - 10 online operating systems reviewed," Dec. 2006, URL : http://franticindustries.com/2006/12/21/big-webos-roundup-10-online-operating-systems-reviewed/
[2] 異塵行者, "覽器萬能，應用程式在線服務（Web Application）的年度彙整," Feb. 2007, URL : http://playpcesor.blogspot.com/2007/02/web-application.html
[3] Mobile01, URL : http://www.mobile01.com/
[4] One Laptop Per Children (OLPC), URL : http://laptop.org/
[5] Telka S. Perry, "The Laptop Crusade,"IEEE Spectrum, vol44, no.4, pp.28-33, April 2007
[6] T. Selker, "New Paradigms for Using Computers," Communications of the ACM, vol.39, no.8, pp.60-69, August 1996

我對於 Jini 的 capabilities 以及 architecture 之認識主要依靠閱讀 Jini Architecture Specification [1] 以及Jim Waldo (Sun 資深工程師, Jini 的主要發明者之一) 在 1999 年發表於 Communications of the ACM 上的一篇文章 [2].

The Goal of Jini

引用 Jim Waldo 在 [2] 文章一開始的一段話 :

The Jini™ architecture exemplifies a new approach to computing systems—making the network the central connecting tissue. By replacing the notion of peripherals and applications with that of network-available services and clients that use those services, the Jini system breaks down the conventional view of what a computer is, while including new classes of devices in a unified architecture.

可以看出Jini 的理想是跳脫目前的電腦架構, 而在目前的基礎之上, 建構一個以 Service 為單位, 基於 Network, 只存在 Services 與 Clients (Users) 的世界.

The Reality of Jini

然而 Jini 以開放的 Specification 來看並未真正完全具備實現理想世界的完整能力. Jini 的主要能力仍是以 Service Lookup 為主, 也提供 Service Registration 以及 Leasing 的特性. 其中 Leasing 機制可以視為一種極為簡單的 Service Negotiation. 另外一個令 Jini 與目前既有的 Service Middleware 極為不同的特點是, Jini 有 Mobile Code (Code Mobility) 的概念. 此概念為跳脫傳統在 Service 與 Client 是只有單純的 Data 傳送的方式, 而把 Code 也視為 Data 進行傳送. 這樣一來 Services 之間的 coupling 將更低, 同時更能更應付一個快速變化的網路環境 (Changing Network). 此特殊的能力事實上是建構在 Java 本身統一利用 JVM 執行程式, 以及 Java 的 Security 特性上. Jini 的真正意函在於 Jini Specification, 而利用 Java 作為實現只是一種選擇, 然而其他語言是否能夠實現 Jini Specification 就不一定了.

在所查到的相關資料中, 大多將 Jini 的 limitations 歸因於下列幾點

1. Network-Centric [3]
1. need a central server [3][5]
2. TCP/IP based [5]
2. Architecture Base
1. based on conventional distributed system [3]
3. Java-based [4]
1. JVM limitation [3][5]
2. Java RMI limitation [3][5]
   

如果單以 Jini architecture specification 的角度來討論, 唯一可能留下的應該只有 need a central server 以及 based on conventional distributed system 兩點. 其中需要 central server 此點會使得 Jini 在某些環境下比較難以實現, 例如 pure Ad Hoc 環境, 或是缺乏 central server 的 P2P 環境. 而 based on conventional distributed system 這點在 [3] 中則是認為會導致 Jini 需要 statically configured infrastructure 來完成 service discovery, 這跟 need a central server 是一樣的意思, 另外就是 Jini 將會需要一個足夠穩定的網路環境 (well-behaved computing environment) 以便進行 RMI 的運作, 滿足 transparency 以及 synchronization 的需求.

而餘下的 limitations 我認為其實跟 implementation 的選擇相關比較大. 比如說 TCP/IP 的依賴性問題, 在 Jini 原先的 implementation 中僅支援 TCP/IP, 但是根據 specification 可以進行適當的擴充, 以支援其他不同的 protocols, 在 [5] 有參與討論者說明自身的相關計畫經驗. 同樣的, 與 Java 相關的 limitations 可以藉由選擇不同的語言實現 Jini architecture specification 解決.

再者, 如果回到 Jini 原先的理想下, 那麼其實 Jini 還有著更多的 limitation, 包含在目前 service oriented 環境中要求的各種 service management 能力, 諸如 service broking, service negotiation, service mediation, service billing, service composition, service security... [6] 等等, Jini 都有許多尚未能滿足的部分.

The Rise and Fall of Jini

下圖說明了我認為 Jini 的 rise and fall. 但因為其中的許多部份沒有查到確切的年份資料, 因此我僅是簡單地照我的猜測及推想擺放相關方塊的位置.


首先是 Jini 的開始開發以及第一個版本的 release. 根據相關的文章可以看出 Jini 在當時引發的熱潮. 而這時有個意外的插曲, Sun 的 marketing 把 Jini 說小了, 沒有完整地呈現出 Jini 的理想, 或許這是為了單純的 marketing 考量, 此點在後來採訪 Jim Waldo 的文章中也有提及[7]. 我認為這點在某個程度上使得 Service-Oriented Computing 沒有更早獲得重視與劇烈發展.

而在 Jini 於市場上取得短暫的成功後, 怎樣維持接續的發展以及強化 Jini 的能力是最重要的事, 單純只有 service lookup 顯然是不夠的. 在這裡我想同時受到幾項因素影響 Jini 的發展. 首先是同一時間 Java 本身也在 J2SE 以及 J2EE 領域取得巨大的成功, 相關的應用及計畫大幅展開, 此段時間內想必 Sun 本身也是忙的不可開交. 對照同時間的 J2ME 發展, 幾乎呈現停擺狀態. 另外如上述說的 Service-Oriented Computing 的想法還不成熟, 許多 Jini 可以沿深加強的方向都還沒有較為成功的研究成果出現. 另外有一個我認為很重要的因素, 在於 Sun 在 Jini 最初 release 不久後開始緊縮 license, 以 Sun Community Source License (SCSL) 授權, 直到 2005 年才開始分別釋放部分程式碼改為 Open Technology License 以及 Apache License [9]. 我認為這無形中對於 Jini 在 Open Source Community 以及 Commercial Company 的發展進行了侷限, 許多基於 Jini 的可能性無從發展 [8], 進而影響後續對於 Jini 是否能夠制定一個 standard 以及 Jini 應用的 promotion.

而對於 Sun 以及Jini 來說, 最大的玩笑或許是 Web Services 的崛起. Web Services 使用 XML-based Remote Procedure Call (XML-based RPC), 相對於 Jini 的理想來說其實有點開倒車.然而在之後的兩年之間, Web Services 的熱潮完全掩蓋了 Jini 的光芒. [10] 的作者認為原因可能是 Web Service 相對的 simplicity. 我覺得應該反過來說, 是 Jini 還沒有達到應該有的 simplicity.

縱使如此, 不管怎麼說, Web Service 的熱潮也逐漸退了, 取而代之 Service-Oriented Computing以及 Middleware-based Software Engineering 看起來正要開始快速發展, 因此我想我同意 Jim Waldo 說的, 許多真正有用而強大的概念是需要時間成熟及驗證 [7], 過早斷定 Jini 已經不行了是不必要的, Jini 仍有大好的機會捲土重來.

References
[1] Jini Architecture Specification, URL : http://www.jini.org/wiki/Jini_Architecture_Specification
[2] Jim Waldo, “The Jini Architecture for Network-Centric Computing,” Communications of the ACM, vol.42, no.7, pp.76-82, July 1999
[3] Robert Grimm, Janet Davis, Eric Lemar, Adam Macbeth, Steven Swanson, Thomas,erson, Brian Bershad, Gaetano Borriello, Steven Gribble, and David Wetherall, "System Support for Pervasive Applications," ACM Transactions on Computer Systems, vol.22, no.4, pp.421-486, November 2004
[4] J. Allard, V. Chinta, S. Gundala, and G. G. Richard III, "Jini Meets UPnP: An Architecture for Jini/UPnP Interoperability," Proceedings of Symposium on Applications and the Internet, pp.268–275, 2003
[5] Limitations of Jini Technology, discussion thread at Jini mailing list, URL : http://osdir.com/ml/java.sun.jini/2004-10/msg00199.html
[6] Dan Jong Kim, Manish Agrawal, Bharat Jayaraman, and H. Raghav Rao, "A Comparison of B2B E-Service Solutions," Communications of the ACM, vol.46, no.12, pp.317-324, December 2003
[7] Janice J. Heiss, "Jini Network Technology Fulfilling its Promise: A Conversation with Jim Waldo," March 2004, URL : http://java.sun.com/developer/technicalArticles/Interviews/waldo_qa.html
[8] Eric S. Raymond, "Open letter to Sun: Let Java Go," 2004, URL : http://www.catb.org/~esr/writings/let-java-go.html
[9] Licensing of Sun's Jini Technology, at Sun official website, URL : http://www.sun.com/software/jini/licensing/
[10] Berco Beute, "Universal Plug 'n Play: Jini's ex-rival back from the dead?" 2004, URL : http://www.artima.com/weblogs/viewpost.jsp?thread=48801

Embedded System

在過去對於 embedded system 的認定或是說明 (在此我避免用 定義, definition 這 個辭, 因為嚴格來說我認為沒有被 well-accept 的定義), 大多是利用一些特徵來描述 embedded system, 例如功能專一性 (not general purpose), 資源有限 (limited resource), 可用記憶體有限 (memory constraints) 等等各種 hardware constraints, 另外就是具有 hardware / software co-design 的特徵(不過這屬於逐漸被拋棄的一個領域), 可以進行操作的介面通常都很小等等. 總之就是把 embedded system 跟許多 hand-held device 或是家電 IA 畫上等號. 最常見的就市直接跟桌上型 PC 作比較, 像是 PC 這種運算快, 記憶體多, 體積大, 多功能用途的電腦系統就不是 embedded system, 反之大概就是. 這種概述大概是過去十幾年來對於 embedded system 的共通印象. 而對於資訊相關的學生來說, 因為講到 embedded system 開發好像就是一定要在一塊裸板上燒 ROM, 或是利用封裝好的小型主機, 外接螢幕什麼的, 好像不是這樣開發的就跟 embedded system 無關似的. 而所謂的 embedded application 當然就是在這樣的環境下可以執行的 applications 摟.

但我並不認為時至今日, 對於 embedded system 的認知應該維持過去的想法. 重點在於 embedded 這個字. 引用 webster's dictionary, rosetta edition 對於 embedded 這字的說明為 :

1. Enclosed firmly in a surrounding mass

2. Inserted as an integral part of a surrounding whole

embedded system 也只是一種 computer system, 而因為他所具有的特徵使得我們特意冠上 embedded 這個字. 但是如果是因為各種 hardware constraints 而冠上 embedded, 對照 embedded 這字本身的意思, 不是很怪嗎 ? 因此我認為, 對於 embedded system, 應該從別的角度來詮釋.

既然我們說 computer system 的目的, 其實終究還是希望可以幫助人類的生活過的更好更輕鬆, 是整體社會文明的一種進步. 因此在此我把上述對於 embedded 釋意文字中的 surrounding mass 以及 surrounding whole 對比到 human life. 換句話說, 所謂 embedded system 事實上是指能夠 embed 到 human life 的 computer system.

在此認知下, 一般熟悉的 PC 自然就不被涵括在裡面. 的確, PC 在很多人的生活中都會出現, 很多人每天也一定會使用到 PC, 但是 PC 有很顯然地融入一般人的生活中嗎 ? 恐怕是沒有吧, 大多數常接觸的人要不就是 PC Gamer, 否則還是以工作接觸居多, 這種情況就變成是刻意去接觸利用, 而不是嵌入或是融入我 們的生活之中. 當然, 我必須承認, 這樣的認知與區隔並不是很嚴謹, 或許仔細想還是可以找到介於是與不是之間的例子. 比如說手機就是一個. 對於現代人來說, 手機或是其他通訊設備幾乎就是融入生活的一部分, 然而當我們說到多功能的智慧型手機, 或是所謂的 Smart Phone, UMPC 等等, 其所提供的服務, 似乎又不是那麼地融入我們的生活了. 這種情況我就認為他既是也不是摟, 換句話說就要看你所持的觀點而定.

我的認知可以下面的概念圖表示. 圖中的 application software 以及 embedded application software 指的僅是 software 部分, 而整體的運作還需要加上更底層的 hardware. embedded application software 在添加 hardware 部分後構成一個 embedded system. 而此 embedded system 所達成的服務應用則是 embedded application. 兩者的差異即在於 Unawareness of Users 的考量範圍. 在 embedded application 的情況中, 需要設法達成讓 users 感覺不到 embedded application software 的存在.


而我上述的認知跟過去對於 embedded system 的認知之間的關係如何呢 ? 我認為過去從 hardware constraints 的角度去區別 embedded system 與否其實也沒有錯, 因為要符合上述我的說法, 將會使得 embedded system 所處的環境面對較多的限制, 例如機體大小等等, 自然而然就會形成各種 hardware constraints. 但是這點在硬體開發技術以及製程逐漸進步, CPU 處理速度越來越快, 同體積的記憶體效能 (Performance) 越來越好的情況下, 過去與桌上型 PC 相比的 hardware constraints 只會隨著時間逐漸的消失, 因此再也不適合用來區別 embedded system 與否.

最後一點, 則是關於上文中不斷提到的 融入 . 這也是之所以沒辦法有嚴謹定義的原因. 所謂融入跟人本身, 以及人所處的環境 (context) 會有關係. 人本身包含了生活習慣, 而環境則包含了文化 (culture) 因素. 這些都是會逐漸演進的 (evolve). 換句話說, 對於 embedded system 與否的認定, 會隨著整個社會環境的逐漸電子化而有所改變. 而如果對於 pervasive computing 或是 ubiquitous computing 略為知曉的人, 可能又會覺得好像沒什麼不同. 這樣說吧, 我認為 embedded system 就是 pervasive computing 或說 ubiquitous computing 的基礎構件之一, 而後兩者所描繪的是 global vision.

Embedded Middleware

而在 embedded middleware applications 的部分呢, 我認為 embedded middleware 跟一般的 middleware 不同處在於 middleware 所要代替 applications 面對的對象, 擴展到了使用者. 已下面的概念圖表示我的想法.

在我的想法中, embedded middleware 除了與一般的 middleware 一樣會需要替 embedded application software 處理面對不同的 operating systems, network, 以及 resource management 等相關問題之外, 還存在於 user 與 embedded application software 之間, 而所負擔的責任即在於降低 developer 設計與實現 embedded application software 時, 需要考量到不同的 users 在不同 context 下的使用問題. 因而有別於一般的 middleware software, user interface (UI) 在 embedded middleware 領域中佔有較重要的份量及地位.

That's what I think about Wii Fit : A Possibly Successful Application of Wearable Devices.

Wearable devices, 或是更廣義的說, wearable computers, 的概念已經存在很久, 不過對這種起源的歷史討論我向來沒什興趣, 參考 Wikipedia [1] 就罷.

Anyway, wearable devices 過去在學界, 主要是分散在 pervasive/ubiquitous computing, smart home, medical devices, military 等應用中, 事實上也取得了相當的進展. 因為我的 thesis 跟 context-awareness 以及 smart home 有關, 當時(一年多以前)也 survey 了很多發表的成果, 在各種可以對人們作 profiling 的 devices 上其實都已經可以有 product 出來. 但是實際市場上就是沒有大公司率先推出. 那時我就在猜原因, 想來想去除了市場推廣因素也想不出其他的原因來.

沒想到在 "正當" 的用途之外, wearable devices 居然在 game 領域可望率先取得成功了 :p

當然我說的成功指的是能夠在市場快速地達成一定的佔有率, 而非只是能夠開發出產品而已. 在 Wii Fit 準備推出後, 這樣看來其實就很清楚了, Wii 其實只是探路的棋子, 任天堂 (Nintendo) 可能打算藉由 game 領域為出發點, 快速擴大市場佔有率, 然後由 game 反攻上述各種應用, 包含 smart home, medical 領域. 像是 Wii Fit 廣告中已經有的各種應用軟體, 事實上就是觀照你身體健康的目的. 當然目前許多批評者認為, 實際運動效果其實不大, 但承認吧, 多少該有的效果還是有的. 況且 Wii Fit 也沒叫你一整天玩他就好, 出外運動跟玩 Wii Fit 並非互斥的選項. (以下影片引用自 YouTube)




等 Wii Fit 的其他配件再推出來, 例如感應手腳動作, 甚至頭部動作的配件, 看起來就更像早期研究者對於 wearable devices 的想像了.

這樣一來, 嘿嘿, 其實空間更大的是 software. 基於 Wii Fit 可以蒐集的資訊, 建構於 Wii 平台上的 software 可能發生的應用太多了. 希望任天堂公司別像 Apple 一樣, 把 Wii 平台開放出來吧, 這對於 Wii 的未來以及市場銷售絕對是有利的阿. 但在這之前, security 的問題絕對是十分十分地重要.

相對於任天堂的策略, Sony 跟 Microsoft 就採相反的做法, 他們都太執著於那台主機本身, 希望 customer 先坐著接受主機, 再來接受延伸的應用. 如果 wearable devices 的市場就此開發出來, 人們的電腦使用習慣因而改變, 任天堂應該會在歷史上再添榮光 :)

不過, 就像我標題寫的, 這只是可能而已, 變因太多了 :p

References
[1] Wearable Computers at Wikipedia, http://en.wikipedia.org/wiki/Wearable_computer