cahier lukhnos

Update: 正式發布工作已經完成，取得及安裝方式，請參考OV wiki上的0.7.2版本發布說明。

Update: 若您是行列輸入法的使用者，又在 2006/6/21 至 2006/6/25 之間曾安裝過 0.7.2 正式版，請參考這個說明，並至這裡下載修正檔案，就可以解決Caps Lock的問題了。

我們開始針對 OpenVanilla 0.7.2 for OS X 版本做小型的發布。0.7.2 正式版與 beta 版相比，新增及改進的項目主要有幾個：

• 修正 0.7.2 beta 一直以來的幾個大問題：Num lock key 造成 OV 失靈、長期開機後會完全失效、需要靠刪除某個神奇的 .plist 檔才能修復再起不能的 OV 等難解的麻煩。
• 增加一個解除安裝程式，可以把舊版或會造成衝突的版本清除掉。
• 先前所有 patch 都整合了進來，包括針對詞彙管理工具等模組的修正。
• 簡易／速成輸入法配合 Windows 習慣，改為九個選字鍵。

進一步的說明，請參考OpenVanilla Wiki 。

lukhnos :: Jun.21.2006 :: tekhnologia 技術或者藝術 :: 7 Comments »

在星期六（2006-06-16）的北京BeiMac聚會利用了十分鐘的時間，用lightening talk的方式，簡單介紹了一下OpenVanilla。當天的投影片可以在這裡下載。

lukhnos :: Jun.19.2006 :: tekhnologia 技術或者藝術 :: Comments Off

顯然Adium和gaim使用的是同一套OTR (off-the-record) 模組。只要gaim也裝了同樣的模組──Adium一裝起來就是已經有的了──就可以彼此說悄悄話了。Linux/FreeBSD 的使用者請尋找以下三套套件：libotr, gaim-otr, gaim-encryption。

Now it’s clear that Adium and gaim use the same off-the-record (OTR) library, and can talk to each other with no problem. Great for people who need a little more privacy. Whether this otr library (libotr) is strong enough remains to be tested. It’s better than nothing (MSN and other instant messenger protocols are in clear). Still, a false sense of security is no security, and is actually worse. So use it with discretion (in every sense of that word).

For Adium users, OTR module already comes with it.

For gaim users and Linux/FreeBSD savvy, look for the following packages: libotr, gaim-otr, gaim-encryption.

lukhnos :: Jun.04.2006 :: tekhnologia 技術或者藝術 :: 1 Comment »

前一次提到，透過兩次ssh -L，我們便可以抵達一次ssh -L無法抵達的地方。這種串接有一個相當實用的地方，就是建立一個透明的虛擬安全通道（transparent virtual secure tunnel）。好比說，我們原來想與server1建立一個secure tunnel，可是因為某些原因，我們無法抵達server1（或者我們不信任通往server1的線路），這時候我們可以透過server2，建立一個通往server1的SSH port的-L forwarder。既然ssh -L會在client（我方，也就是localhost）這端開啟某一個port，那麼我們只要把原本欲連往server1的ssh，轉向對著localhost的那個port開去，就可以（藉由走server2這條路）通到server1了。

例如，原本是希望ssh server1的。我們希望經由server2建立一個virtual secure tunnel：

ssh -L 8888:server1:22 server2

此時，我方（localhost）的8888，等於變成了直通server1的port 22的管道。

於是，ssh server1就可以改寫成：

ssh -p 8888 localhost

一個應用的範例是，假設我們僅有一台可供ssh -R的機器（稀有資源），而我們無法直接建立通往該機器的secure tunnel，此時我們可以透過另一台機器，建立這個secure tunnel，再將我們希望通往該機器的通路，建築在這個secure tunnel上。如以下圖示（click to enlarge）：

lukhnos :: Jun.02.2006 :: tekhnologia 技術或者藝術 :: 5 Comments »

前一篇〈SSH頭腦體操〉裡，我介紹了SSH的兩種用法：-L與-R 。有時候，一次地轉發，還無法讓我們抵達目的地。這個時候就得多串一次了（click to enlarge）：

為了解釋方便，我把server1畫成兩個節點。簡言之，第一行是在資料出發點的client上開一個port。資料丟到那個port後，就會透過secure tunnel發給server1。第一行指令同時也讓server1做站內轉發，把server1從secure tunnel收來的資料，轉到同一台機器的另一個port上。此時第二行就會發揮作用，把在server1指定port的資料，經secure tunnel發至server2，再由server2轉發至目的地的指定port上。

lukhnos :: May.28.2006 :: tekhnologia 技術或者藝術 :: 4 Comments »

Update: 允許ssh server直接bind client端的風險在於，一旦有人去「踹」server的port，所有被踹的力道都會原封不動地經由secure tunnel打回client門口，因此在把server端的sshd_config給拆封前，最好還是確定會用你機器的人，知道自己在幹什麼。

一向覺得讀ssh的manual page有如在做智力測驗，不過在某惡勢力暴力團長輩（which is not a very appropriate metaphor）的指點下，算是終於打通了任督二脈（which is）。

ssh -L 的用法是，把想要對外發出的資料，透過secure tunnel先發到server端，再由server轉發（forward）到指定機器的指定port上（click to enlarge）：

ssh -R 則是反過來，讓server端聽一個port，然後把聽來的資料，透過secure tunnel傳回ssh client，再由ssh client轉發到指定機器的指定的port上。因此，範例中 ssh -R 第一個三明治參數裡的 localhost，是從 ssh client 這邊來看的，是指 blah.org 而不是 server.org（click to enarlge）：

但是，sshd預設值是不允許sshd這樣bind的。sshd_config裡有這麼一行：

#GatewayPorts no

雖然註解了起來，預設值其實就是關著的。把它打開，才能夠使用 ssh -R。Be sure to know what you’re doing though. :)

lukhnos :: May.26.2006 :: tekhnologia 技術或者藝術 :: 4 Comments »

上一篇〈Chat log: 新的社會應用要怎麼誕生〉是早上和一位朋友聊天時談到的。

一定程度上，聊天聊出了個一直很想說的事。

商業雜誌上看到的 xx 2.0 (click to enlarge)：

事實上，我覺得Lawrence Lessig提過的「可互通性」（interoperability，中譯），以及因為interoperability所造就的、讓smart mobs成為可能的「自我培力的平台」（SEP; self-empowering platform，我自己掰的），才是宏旨所在。而促成SEP成為可能的，則是RSS等等技術的推動 (click to enlarge)：

改變其實不是發生在表象的熱鬧。要提供什麼服務，顯然不只是「架一個站」或者是閉起門來搞點東西這麼簡單的事。但是這件事情要說服主事者，ie. 技術──所謂會造成本質改變的技術，以及造成改變的技術本質──不（只）是技客小朋友玩的東西，卻不容易。

lukhnos :: May.12.2006 :: tekhnologia 技術或者藝術 :: 2 Comments »

星期六參加了於竹北舉行的HappyDesigner聚會。主辦者hlb挑了一個不錯的主題：投影片製作。一般商業活動經常需要投影片不說，如今的學術與社群活動也經常需要投影片輔助。原本是單人表演「站起來喜劇」（stand-up comedy），也便成了一筆一機（一台筆記型電腦、一台投影機）式的說唱藝術。

近來流行所謂的「高橋流投影片製作法」（Takahashi method; 高橋メゾッド），雖然高橋自述是因為「沒有PowerPoint、不會畫圖」而發明的窮則變，其實該法有著相當厚實的心理學基礎（人對於突如其來的訊息容易無意識地接受），以及源自《新世紀福音戰士》的實踐歷史。因此Jedi在活動開頭先放映一段《新》已解釋這種avant lettre的高橋流，是相當妥當的。

gugod放映的是先前於OSDC.tw 2006 《善事利器》一節的前半部投影片，說明了Takahashi流的源頭與現在於開放原始碼社群中的影響。

這次參與活動的每個人都自己製作了投影片，工具從傳統的PowerPoint、Keynote到高橋自己發明的XUL檔案、Flash、Perl寫的投影片工具、UNIX shell指令、HyperCard (!)、甚至是Windows檔案夾裡附的「圖片預覽功能」配上「小畫家」都有…… 所以，投影片人人能做，工具隨手可得，形式有了方向，內容五花八門，所以真正的功力跟挑戰還是在於如何講得好，讓大家笑聲不斷啦──亦即投影片最終還是要回到表演與表現，show-and-tell的技藝磨練上。

當天的另一個主題，或者說，另一個「練習製作投影片的理由」，是請大家一起分享自己的工作，尤其gugod, momizi跟大家分享了作為自由工作者（freelancer）的甘苦談，正好一個人談的是coding、一個人談的是文字工作。

我跟hlb提過，既然現在暫時不再從事專職翻譯的工作，或許我會把過去一年來的工作心得也整理起來，提供想投入翻譯工作（不管是哪一種類型、全職或「怕探」）的朋友參考也未可知。昨天簡單開了個頭，投影片放到了這裡。這個版本是會後根據當時現場的feedback再做過修改的。

期待這樣子大家都參與、大家都是講者的活動方式，會繼續辦下去。:)

lukhnos :: May.07.2006 :: tekhnologia 技術或者藝術 :: 4 Comments »

說完一場。

因為一些原因，我人無法出現在台北，透過Skype和不怎麼穩定的線路，聲音據說偶爾還是斷斷續續的。聽說那場到了30+人左右。以後如果還要像這樣子以遠端方式出場，一定會準備更多器材的。或許還會考慮買一套錄製軟體，把操作過程錄成短片也未可知。

在後來Q&A的時候，有朋友問到開發OpenVanilla的感想。那天其實沒有任何準備會被問到這樣的問題，回答得有點亂七八糟。簡言之，我認為OpenVanilla完全是驚喜，我自己從中的收獲自不消說，也很樂見這個計劃有它自己的生命，能夠繁衍下去。

回到Cocoa的話，我比較好奇的，則是Apple未來的roadmap。另一方面，即使Windows Vista遲遲不出對產業界有傷害（雖然出貨了也還是個難題，不過那是另一件事了），不可否認極大多數的desktop應用程式還是在Windows上開發的，然後也有另一個極大數是web應用程式。所以另一個好奇的事情是，做為OS X的開發者，到底活不活得下來？我先前有聽說過，在台灣，最可能為OS X做的開發，是驅動程式──曾經有人問我認不認識熟IOKit的人；也有很多作硬體的廠商是從pre-OS X時代就有用Metroworks開發驅動程式的需要，這些主要都是為了國外市場的需要。然而我也好奇，除了Adobe、MS的Mac BU一定很賺錢不用去問外，像是Omni Group（OmniGraffle和OmniOutliner），或是Ranchero (NetNewsWire)、Bare Bones (BBEdit) 這些公司等，做為OS X的軟體開發者，究竟有沒有利基？或是，Mac上的共享軟體或捐款軟體，他們的使用者是否有比起其他平台同類型軟體的使用者，更願意付費？也就是說，一般我們在意的是市佔率，但很少去問不同市佔率是否也代表了不同的使用者組成、使用者行為及業界結構，薄利多銷和「三年不開張，開張吃三年」是兩種不同的走向，又好比高級車消費者或許比較會買原廠零件（這並不代表用Mac跟開高級車是同一回事）。這些問題，雖然不是Cocoa技術本身的議題，但或許一樣重要。

最感謝的當然是幫我們作示範的yllan (blueapple)了。同時也要謝謝各位聽眾的支持。我那時坐在一間辦公室裡，星期六的下午沒有其他人。看不到、聽不到觀眾的反應（原真倒是不時用Skype傳來訊息，多少減緩了這樣的尷尬）。如果你有去聽那一場講題，而你有些想法（尤其是批評）的話，歡迎留言，督促我能在未來對講題的presentation，做得更好。:)

lukhnos :: Apr.16.2006 :: tekhnologia 技術或者藝術 :: Comments Off

（update：關於rich client的譯名，b6s建議可以譯成「瑞氣千條客戶端」。至於為什麼是瑞氣千條呢？請看布袋戲……）

相信很多朋友都聽說了OSDC.tw 2006的事。我想這將是2006年台灣最重要的開發者社群聚會之一。lukhnos做為OpenVanilla的開發者，也受邀提供一個講題。

這次我提供的講題是「Cocoa：即沖即溶Mac OS X程式設計指南」。Cocoa是Mac OS X的兩套官方API之一，其實就是NeXTSTEP的API（不用懷疑啦，所有Cocoa的舊類別名，都以NS開頭），是以Objective-C寫成的。也因為NeXTSTEP/Mac OS X的關係，而使Objective-C這個語言在眾多物件導向語言間獨樹一格──或者說，才得以在諸強者之間勉強爭到一席之地。這一次的講題，我將針對Cocoa及Objective-C做簡單的概述。希望在Mac OS X上進行原生應用程式（native application）開發的人，目前仍有學習Objective-C的必要。

附帶一提：我們是可以用Java來寫Cocoa原生應用程式──Xcode會幫你把框架生好，介面可以用Interface Builder來拉，裡面的程式再填上Java便成。但是一來Java版的Cocoa介面用起來沒有Objective-C好用，Apple對於繼續發展Java版的Cocoa又似乎很猶豫…… 至於Java的AWT/Swing呢，雖然可以靠「貼皮」（skin）的方式來模擬OS X的長相，但是偶爾還是有些地方皮沒貼好，會露出Sun或X-Window式的三夾板（最佳範例是NeoOffice/J）…… 其他語言的Cocoa接口也有一樣的問題。

在示範操作上，這次講題將直接示範用Xcode配合Interface Builder寫程式。不過，如果還示範如何寫「溫度換算程式」就太遜了。我們將配合WebKit套件，開發一套極簡單的「多樣態客戶端」（rich client）──配合Web後台存取資料，而以原生GUI作為表現層的應用程式。利用WebKit的JavaScript支援，我們甚至可以讓JavaScript寫的程式，倒過來呼叫原生的Objective-C程式碼（註：Apple的開發文件有遺漏細節，照著手冊的範例，程式是不會動的，確實的解法請參考下面的範例程式）。

由於4月8日當天我人不在台北，我會用voice over Skype的方式講解。示範部份則是由Blueapple出手。他用Cocoa寫程式的經驗，要比我豐富多了。:)

如果等不及了，目前的講題投影片（草稿，非常草的草稿）放在這裡。至於範例程式則放在這裡。範例的後台在這裡。

lukhnos :: Mar.29.2006 :: tekhnologia 技術或者藝術 :: Comments Off