試著在剛裝好的 Ubuntu 上亂打一些指令時,發現在 CLI 介面,Ubuntu 會聰明的提醒你忘了裝甚麼軟體套件。

user@user-laptop:~$ proxychains
The program 'proxychains' is currently not installed.  
You can install it by typing:
sudo apt-get install proxychains
-bash: proxychains: command not found

稍微玩了一下,發現是 command-not-found 這個神奇法術。軟體套件包含 /usr/lib/command-not-found 、是一個用 Python 刻的指令稿,此軟體會查詢預先建成的指令/軟體名稱資料庫,只要餵給它指令名稱,他可以迅速的提示如何安裝含有該指令的軟體套件。由於資料庫是 gdbm,且大小只有 2.3M (command-not-found-data 0.2.17ubuntu1),因此查詢的速度相當快,使用者不太感覺到差異。

要使用此功能,尚必須在 bash 中定義一個 command_not_found_handle 函式,在查無指令時自動執行 command-not-found. Ubuntu 已經將這段程式建於 /etc/bash.bashrc.

不過目前使用的套件資料庫是預建的,因此不會依照你所使用的 apt sources 自動更新資料庫。若是可以整合 apt-file 與 dlocate 兩個的功能,應該可以提供較有彈性的功能吧。

Debian 的軟體套件原始碼通常包含幾個檔案,分別是 dsc, diff.gz 與 orig.tar.gz.

.dsc 是一個文字檔,包含軟體的基本資訊、如版本、維護者資訊與原始碼檔名與驗證碼 (checksums) 資訊 。.diff.gz 是壓縮過後的差異檔,由於軟體套件都必須針對不同的套件系統進行調整,以便符合套件系統的規矩。而 Debian 的方式是保留由上游所發行的原始碼壓縮檔,也就是 .orig.tar.gz 檔案,並將所有的修改另外儲存於 .diff.gz 檔,包含 Debian 包裝軟體時特有的 debian/* 檔案。

於是,對於使用者/原開發者而言,可以清楚的分辨哪些碼是被 Debian 軟體套件維護者所修改,在除錯或維護上都可以比較清楚的區分。若想了解 Debian 包裝軟體的細節不妨參考我的 Debianziation HOWTO

至於所有原生套件與非原生的套件的差別,則在於是否有 .diff 檔案。若你所包裝的軟體原始碼中本來就含有所有 Debian 所需要的 debian/rules, debian/* 檔案,你在產生 .deb 安裝檔時,套件包裝軟體就不會/無法生成差異檔,而只會生成 .tar.gz 檔案。

通常包裝成原生軟體套件 (Native Package) 的狀況是維護者手誤所造成,大約是忘記將原始檔名改成正確的 .orig.tar.gz 名稱。但有些時候,是軟體套件維護者刻意製成。但是除非該套件是針對 Debian 所開發,不可能被移植到其他套件系統上,否則不應該包裝成原生套件。

有些開發者原本就使用 Debian 作為開發平台,偶爾為了方便也會直接在發行的壓縮檔案中置入 debian/* 檔案。但是這是不應該的,Debian Mentors FAQ 裡面有稍加解釋,事實上在原始檔壓縮檔中放入 debian/* 檔案,很容易造成誤解與困擾,特別是需要追蹤修改紀錄的狀況。另外還有如下的原因

  1. 其他套件系統沒有理由想要、需要 Debian 的特定東西。
  2. 所有為 Debian 所作的的修改,都會造成一次版本提交。結果莫名的影響其他套件系統都需要更新升級。
  3. 不只是 Debian 使用 debian/,其他延伸套件系統可能也需要修改其中檔案才能運作。否則要則他們必須修改原本的原始碼壓縮檔,或者以一個 patch 來修正你的 debian/ 檔案。
  4. 當有安全問題或其他因素需要作 NMUs 時,這個 debian 目錄會造成其他人難以維護追蹤的困擾。

與 Debian Developer 討論之得。

自從去年在馬德里弄丟我的 X60 (1706-A78)後,就一直想透過 ThinkCare 找回我的電腦。畢竟尚有一年半的保固,且系統用了 TPM,竊賊大有可能跑回 ThinkCare 維修以解開密碼保護。

今日又在上線註冊了另外一台 Thinkpad X60,順道查一下是否有任何管道可以查詢維修紀錄。無意中發現 Lenovo 全面保障計畫,基本上它是一個針對特定機種的延伸保障計畫,此方案保障了

  • 液體潑瀉按鍵盤
  • 產品意外被跌撞
  • 電擊導致貨品線路損毀
  • 液晶螢幕意外損毀

等四項新買電腦最不想卻可能發生的倒楣事,保障時間是一年。一年內,萬一發生以上事項,只需要負擔最高 NTD 8500 (未稅) 的成本。

台灣的條款是不包含竊盜的。倒是我發現香港的 Lenovo「全面保障計劃」承保範圍居然是包含首年於香港被竊或遺失保障!(不含在香港境外發生的盜竊 / 遺失) 而且最高只需要負擔 HK$ 2000 的費用,真是令人羨慕的待遇阿!

根據 xdite 的心得感想,要辦好網路社群為主的會議,有三個主要重點

「正妹工作人員要多,即使少也不能傷眼,最好是有拍回去讓人炫耀的水準」
「網路品質要好,即使很慢也要不能一直狂斷,有線網路是最佳選擇」
「點心要好吃,不好吃也要讓人人吃到飽,最好是茶點時間超級長」

網路一直都是網路社群研討會籌辦者的痛苦,這些參與者本來就是隨時掛網的傢伙,要是參加了激發想像力的會議,卻沒有辦法馬上把資料上傳到網路上或跟網友討論,立即就會見到整個會場充滿焦慮惱怒的氣氛,這時就不用期待會議會有甚麼迴響了。

偏偏大部分的會議場所,基礎環境都不夠完備,缺電缺網路是正常不過的事情。網路的佈建若是要拉線到每個座位上,光是佈線的費用就大約比場租還貴,更何況還得籌備 Switch/Routers 等網路設備。

所以通常是以無線網路作為基礎,然而臨時要借來一堆無線網路基地台也不是一件容易的事情阿,因此都得到處請託。借到設備後也得顧慮佈建的方式,除了基本的 Site Survey 了解場地的大小與障礙物外,以便判斷該將 Access Point 部屬在什麼地方,以及選用適當的天線。最好還要準備 Spectrum Analyzer 等工具,以便決定如何分派有限的通訊頻道。若缺乏了這些工具,想臨時辦好無線網路這件事情並沒有那麼容易阿。

先前幾次經驗,若是透過場地現有的無線網路,要嘛就是被基地台擋了大部分服務 (ports),只允許網頁(Port 80, 443)等流量,否則就是需要帳號密碼,於是乎大家搶著用有限的帳號上線,手腳慢的傢伙只好眼睜睜看著鄰居上網,自己卻只能乖乖離線聽演講。至於自備基地台這件事情,也時常發生取用了家用型基地台 (因為預算的問題),結果沒多久就爆炸 (因為記憶體不足或太多 connection sessions).

FON 先前贊助提供幾個研討會像是 HIT, Wikimania, 中國網誌年會 基地台,據說也是瞬間就被打爆了,形象大傷。可能是佈建的方式 (無法判別該如何使用不同的頻道) 或 Fonera 本身設計的瑕疵 (先前有軔體穩定度與強迫使用歐洲的名稱伺服器的問題)。

這次答應 OSDC.TW 作網路志工,決定採取不同的策略,就是把借來的一打 Fonera 全部重燒成 OpenWrt 為基礎的客製化軔體,並做了以下設定

  • 做了 Management console, 包含設定多一個 IP Address,可以用有線網路接入基地台作設定。並放了 X-Wrt,以便萬一出了問題,可以臨時以網頁改設定為 WDS/Mesh Network. 當然也得放 dropbear (ssh) 作為後備措施。事實是,本次幾乎都是用 ssh 作遠端監視、管理維護。
  • 將 net.ipv4.tcp_fin_timeout, net.ipv4.tcp_keepalive_time, net.ipv4.netfilter.ip_conntrack_tcp_timeout_established 等 kernel parameters 都設到極小,以降低系統紀錄 TCP Sessions 時間。並調高 net.ipv4.netfilter.ip_conntrack_max 數倍以上,如此可以容納更多人同時上網存取。
  • 做了 QoS,將 ssh/web 優先值調高,而且調高 ACK/SYN ,降低其他所有 Port 的優先值。所以理論上 IRC/Internet surfing 不會 lag,即使流量極高, ssh / telnet 也會有比較快的連線反應。(只要 802.11 layer protocol 沒有問題,頻譜沒有被干擾)

本次 OSDC 會議其實只用到五台 Access Points (FON Fonera),參加人數大約 240-250 人,出席人數大約都是一百餘人,同時無線上網人數大約是 60-80 人,會議期間連線沒有甚麼大問題,只有以下兩個問題

  1. OpenWrt trunk 的 atheros hal binary 有相容性問題,所以 Intel® PRO/Wireless 2100 網路卡 無法連線,既使更新了驅動程式與關閉 PSP。受害的苦主有 mhsin、pofeng 等人。不過該 hal 是 property software,沒有跟 Atheros 簽署 NDA 拿不到程式碼,因此也無從修起。即使社群做的 OpenHal/ath5k 也尚未到達堪用的程度。因此還需努力想辦法解決才行。
  2. 場地電源負載過高,跳電造成基地台停止運作。 *默* 這完全在預期之外,不過連線都轉移到剩下還有電源的基地台上。線上查了一下紀錄,每台 AP 上 associated 了大約 40 餘台 STA,但系統 loading average 尚未超過 1, 且尚有記憶體。除了角落的朋友收訊變糟外,並未造成太大的影響。

以上,是本次無線網路服務檢討報告。:-)

方才把 jabber.debian.org.tw 升級到幾個小時前才釋出的 Openfire 3.5.0,jabber.debian.org.tw 是 2005 開始就架設的 XMPP/Jabber IM Server,原本是純粹測試當年正流行的即時通訊 (Instant message)技術,實驗一下 XMPP 與其他 VoIP/IM 協定整合的方式,順道也當作社群的的溝通工具之一。

升級非常容易,祇需下載包裝好的 .deb (debian package) 檔案,直接安裝,程式會自動處理升級的相關事宜。根據 Changelog,這次更新不算有極大的創新。不過值得注意的是 Jive Software 也將要把原本是商業產品的 Openfire enterprise 開放原碼了!

這跟 Jive Software 最近的發展有關,近日 Jive 也同時釋出了一個新產品 ClearSpace,ClearSpace 是協同工作的平台系統,有點類似 Microsoft 的 SharePoint,除了新的產品線外,Jive 也購買了線上行事曆公司 Jotlet。這種種的新策略代表 Jive 將從 IM 市場走向企業協同工作平台市場,於是乎就把非核心的產品線丟給開放原碼社群來玩囉。

其實我最想玩的 Plugin Asterisk-IM Openfire Plugin,或許可以跟現在用 Asterisk 作後端的客服系統作完整整合,嘿∼