OpenLab Taipei 的朋友之約,在共玩二號分享了一份非常久之前的活動,在 2006 年底到 2007 年初的 PORTA2030 工作坊經驗。試著借用 rainfrog 的評論文字,知道無論如何大約二、三十分鐘的時間,大約無法涵蓋所有的可能角度。因此,此次只能從軟體開發者的角度進行探討,想了解此次工作坊中軟體開發與設計的經驗,以及所謂「跨領域」的合作經驗。

本來跨領域這塊的探討,想丟給當初負責主要溝通的 macpaul 來談,沒想到他居然再趕來演講的路上出了車禍。因此我只好就我所知的部份進行分享。演講錄影應該很快可以在 Youtube 上看到。 演講一開始我便澄清自己並不是數位藝術家,認真要談數位藝術或裝置藝術的經驗,大概就是之前作過手機自動販賣機的整合。本段分享是從軟體開發者的角度出發,分析這場所謂的數位藝術或行動藝術的參與。

我必須承認,現在看來,這是一個幼稚且不成熟的展出。從一無所知展覽的形式與支持方式開始,到中途才驚覺其實自己是被展示的物件。用心搭建了一座只有軟體開發者看得懂的巴別塔 (費心翻譯打造的 trac 專案管理系統),註定了軟體開發與服裝設計兩組人馬的溝通隔閡,缺乏跨界溝通的經驗與技巧,兩方持續成平行線前進直到結束。若當初能有更成熟的引導溝通方式,或許最後會呈現出不同的作品。不過這整件事還是為自己累積了相當的經驗,無論是技術上或是心智上的進展。

演講結束後,又跟李駿聊了一番,談到藝術創作者與軟體開發者的差異性。他說 – 創作者的出發點可能只是一個小小的 LED 開關切換,逐漸的發想到各種可能的情境,是由上而下的正三角形。而軟體工程師的思維可能是先發想龐大的可能性,而逐漸收斂成一個規格明確的目的,是由上而下的倒三角形。我倒是認為就新軟體的發展與創新,軟體開發者或所謂 hacker 跟藝術家是一樣的熱於嘗試的,沒有太大差異,差別在於軟體開發者習慣追求一個可以預測的需求目標,而藝術創作者追尋的是模糊的感官經驗。

這種思考習慣,完全會會影響創作的方向與欣賞的態度。就像阿怪所厭惡的「藝術家」,我也一直到現在都無法領會眾多其實只是燈泡開關的裝置意義何在,倒是對以諷刺為出發點得行動藝術或與文化議題掛勾的藝術形式相當喜愛。

就像當初 pingooo 提了洪水的故事情境,PORA2030 的假想情境有一部分是基於發生災難的狀態,在災難發生,通訊系統全毀時的應對措施。雖然說在這種危及的時候,傳統常使用短波業餘無線電無線對講機來通信,但由於技術的問題,速度與可用性無法因應災區臨時需要傳送數位資訊的需求,若可以臨時搭建一個 IP 網路系統那麼災區就可以更容易的與救災中心交換資訊。事實上,有其他人也想過類似的狀態,如美國的安全專家 W. David Stephenson 就建議可以採用 CUWiN 社群的 Mesh Network 開機光碟。(影片: 21st century disaster tips you won’t hear from officials)

當時的想法是除了透過臨時搭設的 IP 網路系統,除了便利救災人員與總部交換資訊外,若救災人員上攜帶具無線網路功能的行動裝置,也可以透過行動裝置傳送個人資料如經緯度、語音、文字、圖片訊息到指揮團隊。pingooo 當時的意見是可以搭配 Sahana 使用,讓臨時網路可以與介接。

我在演講的結束時,加上了幾張簡報,提到了最近幾位朋友為了 88 水災發起的 Sahana 翻譯推廣,以及志工的徵求狀態。希望這件事情不會再到下次災難發生時才又再被提起。

Updated: 2009/09/01 演講錄影已經上線

Rex's presentation on OpenWRT case studies 這是連續第三年上台在 COSCUP 分享 OpenWRT 相關的經驗,前兩年談得是基本的使用、或是稍微進階一點修改韌體給一兩百人的研討會使用,稍微還帶到一點技術。

今年的分享,試著想要切合研討會的「Open source friendly hardware platform」的連續議程的主題,切成兩部份,一部分是 OpenWRT 偏商業應用與分析,分析過去一年來在網通市場的生態系統中,不同層面的廠商各用了甚麽樣的策略與方法去應用 OpenWRT 這套開源的系統,並且對業務與市場可以有甚麽樣的幫助。第二部份,則請在網通代工廠工作的 macpaul ,分享從網通廠工程師的角度,以 OpenWRT 做開發的實務整合經驗與效能結果。

我的簡報可於下載,macpaul 的部份可於觀看。全程演講之錄影也已經上線。有任何問題,歡迎與我聯絡,或留言於此。更歡迎在網通產業的前輩給予指教,特別是國內網通廠或 SoC 晶片廠對 OpenWRT 的態度與看法。

This is my third time to share my experience on OpenWRT project at COSCUP. The last two year I have shared the basic usage and software framework of OpenWRT, and also my experience to customize the OpenWRT firmware for open source conferences for allowing more then 100 people get connected with wifi in single room.

This year, I like to line up with the track ‘Open source friendly hardware’. So with another speaker Macpaul, we split the talk into two parts. The first part is presented by me, talked about how the industry use OpenWRT in their products, and how OpenWRT can do in the ecosystem. I tried to analysis how the strategies work on the business and marketing. The second part is presented by mapcual, as a OEM vendor engineer, macpaul shared his experience on day-on-day router firmware development, and the performance of the OpenWRT software stack.

At the beginning of this conference,  we were thinking about invite the core developers of OpenWRT project. But due to the limit of the event funding, the team can not afforded the ticket and hotel for trip of speaker. Hope, next year we will have opportunity to invite the core developers from the other country.

Photo is taken by Jim Grisanzio, The best photo of my talk I can find on Internet. Thanks! Jim.

本週末即是一年一度的開源人年會,記得去年陸續辦過 OSDC, Blog BoF, COSCUP2008 文化與科技國際博覽會 (Culture Mondo Network) 等。有時成功、偶爾失敗,但是大多失敗的問題都是頻寬不足,像是 Blog BoF 第一次只用 8M/640K Hinet ADSL 寬頻,碰到大流量的 Y!Live 視訊就被衝爆了,雖然 Y!Live 已經收掉了,但是現在 High-definition video 的視訊串流網站也已經變得相當普及,萬一演講太無趣,大家都上線看 Youtube *誤* 那也很有機會爆掉。

記得 2008 文化與科技國際博覽會,在展場與主會議廳各拉一條中華 10M 光纖,使用上倒是沒有甚麽大問題,倒是因為 WiFi 的流量限制較嚴格,某些聽眾想即時上傳視訊影片到外部網站,造成了一些問題。剩下的一般網路瀏覽、Skype、讓 im.tv 做即時視訊轉播,又再現場同時開兩台播出都沒有大問題。(當然也可能是因為這個博覽會的聽眾比較不需要即時網路)

今年四月的時候,又當了一次 OSDC 的義工。今年 OSDC 的是使用台灣微軟的會議室七樓會議室 (對,參加開放原始碼軟體研討會,卻在小便斗上看到微軟的催眠文宣貼紙,的確有點奇特的趣味),這次雖提早去了一次場勘,但是礙於政策或麻煩等種種問題,微軟只能提供分別於內部網路外的一條 2M/256K 的中華電信 ADSL 線路,對於我們所提供會有大量的使用者上網的需求,相關人員露出了納悶與不解的神情,直說其實大部分微軟的聽眾都自備 3G 搞定啊,為何需要額外架設無線網路。且若要使用現成無線網路,尚需要額外申請大量帳號。於是,就在半脫半就的狀況下用了 2M/256K 的線路提供大約兩百餘聽眾的會場網路。

下場當然不會太好看。頭一天是 Tutorial, 因為人數不多,因此網路頻寬的流量使用率還好。但是驚爆一個問題,原來接進會議室的上游是一台 D-Link 的 DI-704P 寬頻路由器 (直接接到神秘的內部網路孔去,只好透過 nmap/telnet/mac address 辨識),這台機器只要超過 1K connection sessions 就自爆,剩下的連線都死光,很有可能是因為還接了其他網路或設備,造成可容納數下降,無法察知。

於是當日結束後,請微軟的網管協助,希望直接將 DI-704P 的 WAN 網路線直接插到該孔,如此我們就可以用自己的設備自行撥 ADSL 的 PPPoE 出去。很妙的是,沒有人知道這台神秘的 D-Link DI-704P 接到哪裡去,找不到機器、也找不到線。於是第一天下午結束後,在 gslin, XDite, slzzp 及其他大神的建議下,趕快生了一台有雙網路卡的小電腦出來,裝上 Debian、OpenVPN、shorewall,從微軟的中華電信 ADSL 開 tunnel 到台灣大學,繞過該死的 D-Link DI-704P。這也是為甚麽大家從微軟上網,出去的 IP 卻是台灣大學。這樣算是解決了 DI-704P 自爆的問題。感謝 gslin, XDite, slzzp 及其他朋友當日空著肚子陪我測試最後效果。

不過 2M 的水管根本不夠大家用阿,上線的人數大約是 40-60 人,完完全全不夠分。於是只好開始

  • (在微軟會議室)擋掉頻寬吃最兇的 Windows Updates Services
  • 擋掉 Debian/Ubuntu mirror site. (造成一些人在外面想測試、安裝新軟體,卻完全連不上)
  • 最後一天下午,已經沒法子了。只好把 transparent proxy 設起來,除了講者之外,其他人輪流斷 Web Access,會看到小水管不夠用的畫面)

很苦。另外也碰到一個問題,就是現場其實有一台 SMC SMCWBR14S-N2,是微軟拿來開放給聽眾使用,因為我已帶了自己的設備,於是打算將他拿來給講者專用。由於原始的設定都是出廠預設值,於是改了密碼、訊號名稱,以及加密方式從 WPA 改為 WEP (為了擔心有講者拿了太舊得電腦連不上),但是在第三天早上劉燈與 David Heinemeier Hansson 做 Video conference 時,將所有的自有 AP 都拔掉,剩下 SMC 這台。但是網路卻很巧妙的每次等劉燈問完一個問題、回答到一半的時候,就斷線了,連續試了幾次,每次都要再補充說明一次,大家都有點失去耐心了。這個問題因演講進行中一直沒有機會辨識跟解決,無法察知是 SMC 的問題、抑或又是 D-Link DI-704P 的異常。(SMCWBR14S-N2 乃直接接到 DI-704P 上)

一些下次可以注意的細節

  • 應該要監視流量與使用頻率,這牽涉到網路佈署的 topology 。不過若能收集這些資訊,對未來改善研討會的網路環境會很有幫助。
  • 要有心跳 (heartbeat) 監視系統,更好是超過時間未收到心跳,則發簡訊通知。
  • 若使用現場網路設備,更改掉預設設定還是必要得。預設密碼、UPnP 等都要更改、關掉為佳。開源研討會,特別有高手會動手動腳、玩刀弄槍的 😉 。當然、無必要的話,就不要用沒測過的設備來玩。
  • 講者若需要使用視訊、網路電話,無論如何再怎麼機車都要麻煩講者與大會提早測試一遍。

今年 2009 開源人年會將再次租用台灣大學應力所與台大電機博理館,今年籌備團隊特別注意台大的網路是否又會拿週末的時間來進行維護,除了上網看電算中心公告,也請教了內線消息,所幸到目前為止都還沒有這樣的網路、電力的維護安排。今年 COSCUP 人數光聽眾就高達 550 人,希望今年乖乖大神保佑,不要出事阿。

(這篇文章因為事隔數月,可能人名或事項過程有所差異,若有誤記請指教並請見諒)

D-Link DI-707P

如果你也常常使用 Thunderbird / Icedove 作為電子郵件書寫工具,並時常需要與外國朋友聯絡,大概也會碰到跟我一樣的問題。就是回信的時候,在信件引言開頭所寫得誰誰誰在何時何刻寫了甚麽,你若使用中文語系環境,這些日期跟提醒文字都會變成中文。

跟同語系的朋友聯絡倒是沒有問題,問題在於非中文語系對他們而言,這些無法顯示的字眼實在非常困擾,而且也略顯不禮貌。最好是能夠改成英文系顯示。這項需求的設定已經被收錄在 mozillaZine 與 ThunderBird 的技巧說明網站。

調整的方式非常容易,你可以在 user.js 中加入以下設定,就可以客製化回信時所使用的引言標頭。

// http://www.mozilla.org/support/thunderbird/tips#beh_replyheader
// http://kb.mozillazine.org/Reply_header_settings

user_pref("mailnews.reply_header_locale", "en-US");

// Change the reply header
// 0 - No Reply-Text
// 1 - "[Author] wrote:"
// 2 - "On [date] [author] wrote:"
// 3 - User-defined reply header. Use the prefs below in conjunction with this:
user_pref("mailnews.reply_header_type", 3);

// If you set 3 for the pref above then you may set the following prefs.
user_pref("mailnews.reply_header_authorwrote", "%s wrote");
user_pref("mailnews.reply_header_ondate", "on %s");
user_pref("mailnews.reply_header_separator", " ");
user_pref("mailnews.reply_header_colon", ":");
// The end result will be [authorwrote][separator][ondate][colon]

其中,mailnews.reply_header_locale 可用於設定你要使用的日期格式。若你發現更改 reply_header_locale 了之後,日期沒有變成應該要出現的英文日期,反而是亂碼的中文的話。你大概是碰到跟 Ubuntu 上的 #157638 一樣的問題,意即你的系統缺乏了相對應的語系資料 (locale data),請確認你的系統中生成了如 en_US 等語系資料檔案。如不確定,可於系統上執行 “sudo dpkg-reconfigure locales” 來進行設定。

最糟的情況,你可以透過環境參數的設定,更改 LC_TIME 為 en_US 或 C,這樣日期字串就會自動轉為英文語系。LC_TIME 的設定方法適用於大部分軟體。

這是一則 tip.

上一篇文章中所說的 Hamster – 時間追蹤工具,只能在 Linux 上使用。再追 Hamster 的一個休眠問題時,無意中看到另外一個網站 RescueTime 所提供的服務。

有別於 Hamster,RescueTime 的設計是追蹤使用者當下使用的軟體,並紀錄使用期間。在網站上註冊帳號後,透過下載與執行一個客戶端軟體,RescueTime 可以追蹤你正在使用的軟體、閱覽的網站。然後你可對該行 為(使用軟體或閱覽網站) 進行標注,例如說只要我切換到 Word,便是在工作,若在瀏覽器切換到 Plurk.com 便是打混聊天。RescueTime 網站本身也提供了相當豐富的報名與追蹤系統,甚至可以自行定義預期目標,未能到達目標則寄出通知,相當有警示功能。

官方版軟體只支援 Microsoft Windows 與 MacOS。但是在 Ubuntu, Debian 上,Elliot Murphy 等人已實做出開源版本 – RescueTime Linux Uploader,這個版本會將你使用的中的視窗名稱等傳到 RescueTime 網站上,Firefox / Epiphany 的外掛模組也正在開發中。

不過對我而言,既使正在使用 Terminal 編譯程式或 Evolution 回覆信件,很多時候是作不同的專案,我不希望計時軟體只記為單一事項,因為有時用電子郵件寫報告也要花上半小時,全都統計在「撰寫郵件」類別,實在沒什麼道理。雖然 RescueTime 可以紀錄到切換應用軟體的時間,但實務上還是 Hamster 比較接近需求。

若你希望可以治療對執行力傷害最大的飆網注意力渙散症 (Internet Attention Deficit Disorder),可試著用 LeechBlockMeeTimer 來觀察與自我克制吧。

欲鍊神功並先自宮。別上網看我的網誌了,快工作吧 :p

References

最近開始參與一些產品、軟體開發計畫,也接手一些顧問服務。為了有效監控自己的工作時間跟確實計價,一直再找相關的時間追蹤工具。在 Gnome/GTK+ 環境下有 GTimLog, Gtimer 等,但總覺的他們的介面不夠便利。通常都必須拾起滑鼠,點選特定的 Task 後才能開始紀錄。這樣實在本末倒置,因為原始的期待是利用計時軟體監督自己的工作時間,提高工作效率。但是這些工具的使用卻造成每次切換工作都浪費幾秒,實在很不方便。而且紀錄的資料缺乏圖表、匯出功能,後續的整理也相當花費時間。

最近開始改用了 Gnome 2.24 中開始內建的 Hamster,完全符合我的需求。

hamster-menu

幾個特色

  • 工時可分為工作項目 (Tasks) 與分類 (Category)
  • 可用快速鍵切換工作項目 (軟體翻譯為 活動, activities)
  • 切換活動項目的輸入欄位可以自動完成! (可只打頭幾個字母就可列出可用項目與類別, 當然使用英文輸入效率較高)
  • 可為每項計時寫入備忘錄。(未來可以查詢該時段的實際工作內容,備忘錄亦有快速輸入法)。
  • 可依據電腦之閒置狀態自動停止計時。
  • 當下活動每進行特定時間,可自動提醒是否要切換。
  • 活動概覽中有漂亮的圖表列出「日」、「週」、「月」的工時紀錄,也會依照分類列出,以及每日的工作時間
圖檔來源來自 / Screenshots are from http://live.gnome.org/ProjectHamster

透過這個工具,可以追蹤分析自己每日進行工作切換的頻率,以及每件事項的花費時間。固定審閱可有效提高自己的工作效率。

你若使用 Debian Sid/Unstable, 會發現最近一版 (2.26.2) 開始,Hamster 無法偵測到電腦閒置,導致系統閒置時仍不停的紀錄時間。經查,是因為 Hamster 透過 Gnome-Screen Saver 查詢系統閒置時間,但是 Gome ScreenSaver 最近更改了 idle time 的偵測方式,改由 Gnome SessionManager 來監視閒置時間,Gome ScreenSaver 自己也不紀錄閒置時間了。

相關的問題與 patch 已經回報到 Debian BTSGnome Bugzilla.