歷史悠久的 FSF Award 開始提名了，FSF 從 1998 年就開始有這個獎項，反觀國內的風風雨雨，是否有可以參考學習的地方呢？Google 的 Project Hosting 吸引了眾多的目光，而 Linux-To-Go 則希望吸引到不太一樣的開發者，它能成為嵌入式系統中的 SourceForge 嗎？

Candyz 介紹了在 Fedora 上建立套件的好工具，替下次的心得分享打頭陣，Fedora 玩家一定要看！Project Hosting 對於自由軟體開發者來說，能集中軟體專案，降低管理門檻，但是苦工總是要有人做，自由軟體鑄造場的 marr、lcamel、aguo 為我們介紹了開發 forge 的各種技術挑戰。

名家評論部分，我們邀到自由軟體鑄造場法政組的冬梅姐來為最近發表的 GPL3d2 做評論，對於 GPL 的改變與未來好奇嗎？你一定不能錯過！

這期的土虱報報新推出了一個專欄，專門介紹近來本土自由軟體社群的工作成果，如果讀者自己寫了自由軟體，也歡迎告知編輯，土虱報報樂於報導台灣自由軟體的進展。而這期預定要登出的 OpenDarwin 內幕以及 Java 開放原始碼的新聞與評論很可惜要延期刊登。

徵稿！隨著暑假進入尾聲，編輯與記者們也都要開始忙碌起來，但我們會繼續進最大的努力提供高品質的土虱報報，如果你有什麼有趣的新聞，或是有文章欲與其他讀者分享，歡迎來信 editor[at]tossug.org。

shrink this item

在我國的父親節這一天，自由軟體基金會與 GNU 計畫公開徵求「2006 自由軟體貢獻獎」的提名。此一年度獎項，是為了表揚透過依循軟體自由精神的作為，而對於自由軟體的進步與發展有重要貢獻的人士。

受獎者僅限於個人，而非某一公司、組織或團隊；之前的得獎者不得被提名，但仍然鼓勵再次提名曾經被提名者。評審委員會將從合乎資格的被提名者中，選出貢獻最大的人士。

之前的受獎人和得獎原因列出如下：

• 2005	Andrew Tridgell	for his work as originator and developer of the Samba project.	公告
  2004	Theo de Raadt	for his work on OpenSSH, his leadership of OpenBSD, his selfless commitment to Free Software and his advancement of network security.	公告
  2003	Alan Cox	for his work advocating the importance of software freedom, his outspoken opposition to the USA's DMCA (and other technology control measures) and his development work on the kernel named Linux.	公告
  2002	Lawrence Lessig	for promoting understanding of the political dimension of free software, including the idea that code is law.	公告
  2001	Guido van Rossum	for inventing and implementing as Free Software the Python programming language.	公告
  2000	Brian Paul	for his ground-breaking work on the Mesa 3D Graphics Library.	公告
  1999	Miguel de Icaza	for his excellent work on the GNOME project.	公告
  1998	Larry Wall	for his many contributions to the advancement of freely distributed software, most notably Perl, a robust scripting language for sophisticated text manipulation and system management.	公告

有意提名者請於 2006 年 10 月 31 日（一）之前，將它寄到 [email protected]，提交名單請符合下列格式：

• 被提名者的姓名請放置於信件的主旨欄。
• 信件內容請包含被提名者的工作成果說明（少於 40 列），以及為何您認為它對於軟體自由有特別的重要性。
• 請於信件內容中指出，何處可以取得您的提名所依據之資料（例如：軟體、手冊或著作）。

消息來源：FSF, 1998 - 2004, 2005 - 2006.

shrink this item

最近開放原始碼的專案主機代管（project hosting）似乎又變成一個熱門話題，這當然和 google 的 hosting 服務起跑有點關係。不過，在這之前，有一個專案主機代管的網站 Linux-To-Go 已經悄悄地在 7 月 13 日公開，但這個站的焦點不是一般硬體上的開放原始碼軟體，而是嵌入式裝置上的 Linux，目前 Linux-To-Go 正在公開邀請個人、企業或專案加入。

因為嵌入式系統的商機，類似的網站通常是由業者聯盟所架設的。相反的，Linux-To-Go 是由社群管理的網站，由德國的 kernel concepts GbR 公司贊助維護網站所需費用。Linux-To-Go 上目前登記的專案包括 OpenEmbedded（開發環境）、EFL++（C++ 語言的 Enlightenment Foundation Libraries）、Gomunicator（用 gtk-2.0 的語音電話程式）、Prismstumbler（無線網路掃描程式）、Thumbpad（keypad 輸入工具）、Ångström（Linux distro）等等，不過登記為開發者的人還不多，釋出的程式也有限。

架站者之一的 Florian Boor 對 Linux-To-Go 的描述是這樣的：

• Linux-To-Go 的基本想法是要為開放原始碼軟體創造一個透明獨立的開發平台，並讓所有對開放原始碼行動裝置有興趣的使用者、開發者或任何人能容易地交換資訊。

  目前我們提供網站代管、通信論壇、新聞、planet、wiki 和三套原始碼管理系統 CVS、Subversion 和 Monotone，專案管理的部分則大多使用 GForge。 我們邀請所有和開放原始碼行動裝置有關的專案來加入我們，也歡迎有意提供平台協助的個人或企業。

shrink this item

一、簡介

Mock 是一套在 Fedora 上用來 Chroot Build 的 Tools，目前所有 Fedora Extras 裡的套件，都是經由 Mock Build System 產生出來的。Mock 可以 Build Fedora Core 1 (FC1) 到 Fedora Core 5、FC6(development)、RH7.3、RH9、RHEL3、RHEL4 等等平台的套件，理論上，只要是 Fedora/RedHat 系列的，且有支援 yum 應該都可以適用的，而我也成功的用 mock 來 build Scientific Linux 4.3 的套件。

二、安裝

在 Fedora Extras 中就有 mock 的套件，所以只要直接安裝即可:

sudo yum install mock

三、設定

所有的設定檔都在 /etc/mock 目錄底下，所以需要稍微修改一下。例如我想在我的 i386 機器上 build FC5 的套件，所以要修改 /etc/mock/fedora-5-i386-core.cfg 這個設定檔，主要是改裡面的 Yum Repository 路徑，改指到國內比較快的 Server 上。例如我都改成用 CLE 上的 Yum Repository:

 [core]
 name=core
 baseurl=ftp://cle.linux.org.tw/pub/fedora/core/5/i386/
 
 [updates-released]
 name=updates
 baseurl=ftp://cle.linux.org.tw/pub/fedora/core/updates/5/i386/
 
 [groups]
 name=groups
 baseurl=http://buildsys.fedoraproject.org/buildgroups/5/i386/
 
 [extras]
 name=extras
 baseurl=ftp://cle.linux.org.tw/pub/fedora/extras/5/i386/

四、設定可以執行 mock 的使用者

編輯 /etc/groups 把想要讓其能執行 mock 的使用者加到 mock 這個 group 裡，例如:

mock:x:106:candyz,linux,build

五、執行

1.語法:

 mock   [-r  CHROOT]  [--no-clean]  [--arch=ARCH]  [--debug]  [--result-dir=RESULTDIR] [--statedir=STATEDIR] [--uniqueext=UNIQUEEXT]  [command]
       filename

2.參數:

• -r CHROOT
  • 用 -r 來指定設定檔，如 -r fedora-5-i386-core.cfg
  --no-clean
  • 在 build 套件之前不要 clean chroot (可以節省時間，不用每次都要重新下載安裝)
  --arch=ARCH
  • 指定要 build 的平台
  --debug
  • 輸出除錯訊息
  --resultdir=RESULTDIR
  • 指定存放 RPMs 及 build logs 的路徑
  --help
  • 顯示求助訊息
  --version
  • 顯示 mock 的版本

3. command:

• init
  • 初始化一個 chroot 的環境（install packages, setup devices, etc.）。
• clean
  • 清除整個 chroot tree
• rebuild
  • 若沒有指定 command 則預設會使用 rebuild

4.範例:

mock -r fedora-5-i386-core.cfg --no-clean ~/rpmbuild/SRPMS/gcin-1.2.2-8.src.rpm

5.注意事項:

因為 chroot 環境所有的檔案都是放在 /var/lib/mock 目錄底下，因此，你的 /var/lib/mock 目錄空間要夠大，不然可是會爆掉的。或是修改一下設定檔，把 /var/lib/mock 換到空間比較大的目錄去。

若還想 build FC4 FC3 的套件，同樣的，修改完 fedora-4-i386-core.cfg fedora-3.i386-core.cfg 等設定檔即可，然後再執行 mock 指令，如:

mock -r fedora-4-i386-core.cfg --no-clean ~/rpmbuild/SRPMS/gcin-1.2.2-8.src.rpm
mock -r fedora-3-i386-core.cfg --no-clean ~/rpmbuild/SRPMS/gcin-1.2.2-8.src.rpm

六、結語

之前我都是一台電腦同時裝好幾個版本的 Linux，如 FC5 FC4 FC3 RHEL4 等等，要打包套件時再 chroot 過去打包，或是有時候得 reboot 進其他的系統去打包。

而在我用了 mock build system 之後，打包套件變的輕鬆許多。現在，我只要下個指令，mock 就會從 FC3 - FC6(development) 及 RHEL4 幫我把所有平台的套件都打包好，實在太方便了，也省下很多的硬碟空間。

七、參考文件:

http://fedoraproject.org/wiki/Projects/Mock

shrink this item

世上已存在不少自由軟體專案開發網站，除了 SourceForge.net、Tigris.org、GForge.org、Savannah 之外，Google 也推出類似的服務，並廣泛引起注目。不過，本文並不打算把焦點放在各網站的比較上，而是嘗試介紹這類網站的技術共通處，以及分享自己的經驗歷程。

讓我們姑且先以 forge 這字眼，來代表所有提供這類服務的網站。接著，看看 forge 有哪些主要的技術挑戰? 從小處來看，我們挑了兩個整合議題來談：「帳號身份及權限」與「搜尋引擎」；從大處來看，我們將介紹採用開發框架時，要留意的議題。

整合帳號身份及權限

專案開發網站以使用者及專案為起始，再配合「事務追蹤」「郵遞論壇」「討論區」「版本管理」等功能，交互關連出複雜的身份及權限對應關係。從 open source 世界，我們可以找到許多個別軟體提供這些功能，但它們也自成一格，使用各別的帳號權限表，帳號整合必須優先處理。

以最簡化的情境來當例子，一個專案在建立之際，會先有一位專案管理員，而管理員可以邀請新成員，在新成員加入後，就可以利用事務追蹤工具，來新增工作事項，並由管理員分派工作給合適的成員，而成員可以加入郵遞論壇，以電子信件與其他使用者進行討論。

在上述的例子，具備「管理員」身份的使用者，必須擁有「會員管理」功能權限，以便設定成員的功能狀態，並能夠方便執行「邀請新成員」動作；而郵遞論壇的管理政策，也常與使用者身份有關，例如，是否允許「非成員」加入討論，討論區是否採「審核制」等；關於版本管理，也要決定哪些成員具備 commit 權限。

這些功能，進一步還可能有著不同的工作流程 (workflow)。舉例來說，如果 post 的內容可以先存成草稿 (draft) 狀態，經作者提交 (submit) 給管理員確認 (review) 後發佈 (publish)，或是退回 (reject) 再改。因此，除了不同狀態 (status) 的設定，工作流程也包含動作 (action) 的設定，這些都需要緊密配合帳號身份及權限。

搜尋引擎

上述各項功能所產生的資料記錄，或多或少，都希望能結合搜尋引擎的服務，產生更具價值的資訊，例如找出「最新建立的 10 個專案」，「最近加入專案的 5 位成員」，「最常被使用的關鍵字詞」，如果所有的資料記錄都是「完整公開」，或是沒有專屬於某個專案或某位成員的話，那麼直接交給 Google 協助搜尋，倒也省事，偏偏事與願違，一個身份及權限複雜的網站，很容易牽涉專屬資料或處於未公開階段的文件，此時，採用自家專用的搜尋引擎，便成為必要的需求。

另外，對大型網站而言，索引 (index) 的建立方式，也考驗著網站開發者在系統效能及資訊即時度之間的取捨智慧，常見的索引類型包括「Date (Range) Index」「Field Index」「Keyword Index」「Path Index」「Text Index」等，中文資料衍生出斷詞的議題，然後再配合適當的 metadata 資料，以及排序方式，由搜尋結果的頁面呈現給使用者，當資料量過大時，還需要處理分批顯示的問題。

整合框架的考量

概括地看，forge 所處理的，就是「異質系統整合」議題。儘管可以站在 open source 的巨人肩膀上，但實務經驗告訴我們，爬上巨人肩膀絕不是輕鬆差事，而且我們會擔心爬錯肩膀，爬上爬下的成本必須納入考量，這也突顯選擇整合框架 (framework) 的重要性。

想把 Apache、Subversion、Mailing List、Tracker 整合起來? 談一下 OpenFoundry 的經驗吧。以前，我們利用 Request Tracker (RT) 這套 Perl 軟體，作為整個系統的主架構，將開發平台上的使用者對應到 RT 的使用者，將專案對應到 RT 的 Queue (表單)，並將使用者/專案關連到系統內部實作用的 Ticket (申請單) 上。這種對應關係，讓開發者可以對使用者與專案新增 Custom Field (自訂欄位)，且不用修改程式碼，同時也可以利用 RT 系統對 Ticket 物件所提供的功能，重複使用其新增/編輯/搜尋等程式碼。

上述的對應機制雖然提供了相當大的彈性，但是也因此承擔了許多包袱。Ticket / Custom Field 的設計，在對物件操作時，常對資料庫產生過多的 SQL 指令，且原 RT 的設計具有較嚴密的權限控管機制，在我們開放存取的站台上，也增加了許多不必要的檢查。這些問題在單一物件操作時較不明顯，但隨著網站的使用者與專案數日益增多，每一個操作都會將此問題放大。 當專案與使用者的大量成長後，系統將無法負荷。

Data, Logic and Presentation: 三者的適度封裝

我們發現，如果網站在設計時，沒有對專案/成員等概念進行封裝，且實作細節被散到展現層 (Presentation Layer) 的各處，就會導致修改展現層的頁面時，仍需瞭解專案的實作細節。這種情況，一方面會造成網站不易更新，另一方面也造成潛在新模組貢獻者的卻步，因為他們需要瞭解過多細節。

「資料」的備份及維護，必須和網站程式「邏輯」，以及外觀「呈現」，相互獨立，最好能納入測試個案 (Test Case) 的規畫，以免陷入以下的窘境：

1. 不知道有哪些程式/網頁依賴舊的實作細節，所以也不知道改成新的實作方式後，原先的功能是否仍能正常運作。
2. 就算知道新的方式可行，也有數百個地方需要做修改，形成如霰彈式修改 (Shotgun Surgery) 的問題。

小結

以上，我們簡介了 forge 主要的技術挑戰，不管是採用「教堂式」或「市集式」開發模式，大抵都脫離不了這些議題。而在 OpenFoundry 的未來開發上，讓它能主動走入既有的開發社群，是我們努力的方向。

歸功於 open source 的快速演化生態，新的技術與工具不斷竄起，例如 CSS、RSS、AJAX、Social Software 等，這些技術工具同時帶來契機與挑戰，讓我們思索如何讓網站系統能夠與時並進，並利用好的開發架構，方便社群開發力量投入協助，更快速地納入受歡迎的服務功能，同時間，把這些開發經驗分享給更多朋友，也是我們樂於回饋社群的小貢獻。

shrink this item

運作超過十五年的 GPL2（GNU General Public License version 2）終於在今年開始第三版的改版程序，這應該是暨一九八九年 GPL 問世以來自由/開放源碼界的一樁超級大事。

為什麼要改版呢？因為 GPL 的在運作上發生許多問題吧！是嗎？回首過往，由各界對於 GPL 的運用可以發現，只要相關當事人者願意，看似僵化的 GPL 在運作上可以有著極大的彈性空間，截至目前為止，雖然有幾起與 GPL 相關的法律爭訟案件，但若與 GPL2 運作十五年的歲月相較下，這樣的案件數量並不多。數量少，僅代表浮出檯面的問題不多，潛藏的問題與疑慮仍然不少，這些問題與疑慮的原因部份可以歸咎於 GPL2 本身文字的模糊不清，此外社會制度變遷與科技進步，也造成 GPL2 的內容與社會制度以及科技現況有所落差，因此 GPL 的著作權人 FSF（Free Software Foundation，自由軟體基金會）展開了這次的改版。

想要處理的議題很多很廣，最後焦點仍然落在原本就熱門的 DRM 與專利議題上。不過 Torvalds 與 HP 分別對 GPL3（GNU General Public License version 3）關於 DRM 與專利的內容不表贊同，再加上 GPL3 草案第二版的修改方向僅著重於原有內容文字表達的清晰化與具體化，對於上述的爭議內容 FSF 並沒有因為外界的爭論而改變原有態度，因此對於 DRM 與專利的討論與爭執還會持續熱絡下去。

跳脫這些爭論來觀察，GPL3 草案內容呈現出了不同以往傳統授權條款的風格：文字的簡單化與去區域化（denationalization）。

一般授權條款文字都是充滿法律專有名詞或是複雜的條文層次邏輯，不過因為自由/開放源碼軟體自由散布的特性，閱讀這些條款的人大多為一般使用者，為了讓這些使用者也可以輕易了解授權內容，GPL3 除了增加了一些詞語定義外，並將許多艱澀難懂的抽象用語拿掉，改以具體的情境描述。以第十一條專利條款為例，草案第一版的用語為一般專利授權制式用語，不易為一般人所理解，所以草案第二版將該條大部份文字重寫，改為被授權人必須承諾不對任何一位後續收受者提出專利侵權控告。這種直接陳述被授權人應有作為的簡單文字風格，對於沒有法律基礎概念的使用者來說是相當容易了解的。

此外，同樣基於不限制散布地域的特性，GPL 會受到不同區域法律制度的挑戰，這些不同的法律制度有各自的法律用語，又或者即使是同一個詞語，但不同法律制度對之有不同的詮釋內涵。舉自由/開放源碼領域中常討論的 GPL 是否為契約的爭議為例，這是源自於美國法律制度下所產生的問題，因為到目前為止還沒有一套判斷的規則與標準，可以來檢視像 GPL 這類的授權條款是否為美國契約法中的契約，因此在美國有此爭論。不過這對於德國人來說卻似乎一點也不是問題，因為德國法院在相關判決中並未經過長篇大論的辨證，就直接明確表態 GPL 是一種授權契約，而在此判決文出現之前，相關德國法學資料也並未針對這個問題大肆討論。

由此可知，同樣一個問題透過不同法律制度來評斷，就會有不同的結果，同樣一個詞語概念在不同法律制度下也會有不同的解讀。為了儘量減少不同法律制度不同解讀所帶來的 GPL3 內容解讀混淆，FSF 致力於 GPL3 內容的去區域化，除了陳述文字儘量有彈性外，也更換了一些詞語，這些更換後的詞語不見得是一般日常生活的常用辭彙，也不見得是法律用語，之所以採用這些詞語就是因為它們所代表的的概念並沒有太過於特定，只要在 GPL3 中加入該詞語的定義，未來運用時直接參考 GPL3 本身的定義即可，如此即可減少不同法律制度有不同解釋所帶來的混淆現象。典型的例子是 GPL3 草案第一版採用的 “propagate” 與 “propagation”，這兩個詞語是用來描述「依照各國著作權法規定，必須取得著作權人許可才可以實施的所有行為」，“propagate” 與 “propagation” 本身並沒有強烈的法律意涵，只要直接套用 GPL3 所規定的定義，就可以避免不同法律制度對同一個詞自有一套解釋的問題。此外草案第二版將承襲自 GPL2 的 “distribute” 剔除，而改以 “convey” 替代，因為經過討論後，“distribute” 在某些國家有特定的法律內涵，與 GPL 預設不同，這樣的差異可能造成 GPL 未來在這些國家運用上的問題，因此 FSF 在草案第二版以沒有特定法律內涵的 “convey” 來代替。

GPL3 草案所嘗試的文字簡單化以及去區域化原則，在一般授權條款是少見的，因為一般授權條款不是被授權人特定，就是這些不特定被授權人生活在同一個法律制度管轄區域中，因此少有像 GPL 必須面對眾多不同法律制度的情況。這樣特殊的背景除了讓 GPL3 在內容上務求面面俱到外，它的草擬程序也因此與眾不同。

一般而言，在被授權人特定的情況下，只要雙方的意思一致，授權條款的內容就可以確定出爐；在被授權人不特定的情況下，只要不違反法令規定，授權人可以自由決定授權內容，不需要考慮被授權人的意思。在自由/開放源碼軟體，雖然授權對象不特定，但因為授權目的並非是為授權人一己之私，因此 FSF 相當注重被授權人的利益，再加上自由散布的特性，自由／開放源碼軟體被授權人分佈層面廣泛，授權條款必須接受不同法律制度的檢驗，因此收集各方意見，了解未來可能遭遇到的法律制度內容與困境，就成為 GPL3 草擬過程中相當重要的一環。FSF 為此採取與自由／開放源碼軟體開發模式類似的方法來收集資訊與各方意見：將草案內容透過網路公開，每一位參與者均可以閱讀草案，發表評論，並且貢獻所知的相關訊息。這些貢獻到網路上的評論與訊息，就是 FSF 修改 GPL3 草案的參考方向。

透過傳統方式，一群人關起門來自行收集訊息、討論草案、然後修改內容，這樣的方式並不是不可行，只是將草案公開出來，讓全球的社群參與者來參與討論，是更為縝密的方法。二百雙的眼睛，不如二萬雙、甚至二十萬、二百萬雙眼睛看得縝密透徹。

GPL3 草案的修改到目前為止已經超過半年，草案第三版預計在秋天公佈，不過如前所述，由第二版的修改來看，FSF 似乎並不會改變其既有的立場，僅會加強內容的清晰化與去區域化，但 Torvalds 與 HP 對於 GPL3 中 DRM 與專利規定並不表認同，這對於 GPL3 未來的應用是否順利帶來極大的不確定性。尤其 Linux 是重要且具指標性的自由／開放源碼軟體，身為 Linux 社群的領導者，Torvalds 曾公開表示，可能因此不希望 Linux 採用 GPL3 做為授權條款，雖然他並非 Linux 的唯一著作權人，無法獨自決定 Linux 的授權內容，不過因為其在社群的領導地位，Torvalds 的態度仍然具有相當的影響力。

另外一個筆者個人十分有興趣的思考點是：GPL3 這樣的草擬修改模式，是否會成為其他授權條款修改時仿效的方式？FSF 之所會採取社群模式來蒐集意見與資訊，再再都顯示出考慮到被授權人立場的心意，希望可以在堅守既有原則的範圍內制定出儘量適合各個層面被授權人的 GPL3 內容，這種立場並非是為了謀利，而是單純出自於希望 GPL3 的內容可以更好，希望未來各方可以順暢地運用 GPL3，因此 FSF 投注了相當多的心力來進行 GPL3 草案的修改。結果是否可以如 FSF 所預設？因為草案修改程序尚未結束，所以尚未可知。不過由 FSF 此次修改的動機與所投入的心力來看，很難找到一份授權條款的著作權人，可以同時具有類似的強烈動機以及能力來投注這樣龐大的心力在改版工作上。不過，關於這一點，仍是要等正式發佈 GPL3 的定稿後，才可以看到 GPL3 改版程序是否慢慢發酵。

在 GPL3 的內容上，FSF 仍然堅持其最初向左轉（copyleft）的自由理念，這從草案第二版的修改僅為第一版內容清晰化的現象可以看出來，FSF 並沒有因為各方的大量意見而迷失或者修改既定原則，這是 FSF 一貫的作風。而這樣大規模收集意見與資訊的程序也是一項創舉，未來是否會影響其他授權條款的修改，仍有帶觀察。期待二００六年秋天草案第三版的出爐。

延伸閱讀： 土虱報報第二期新聞 OSSF 法律園地

shrink this item

土虱大補湯是這一期新推出的專欄，報導本土自由軟體社群近來的工作成果，如軟體新版的釋出、軟體被主流 Linux 出版者收錄等等，本期報導對象是 chewing、pcmanfm 和 gcin。如果讀者自己寫了自由軟體，也歡迎告知編輯，土虱報報樂於報導台灣自由軟體的進展。

• 新酷音輸入法 Windows 版（Win32-chewing）0.3.3.2 版於 8 月 16 日釋出

  主要加入了方便輸入符號的設定介面，及修正非管理者權限的輸入問題，詳情見 http://chewing.csie.net/news.html#win32_chewing_0332 。

• PCManFM 0.2.4 版正式於 8 月 23 日被 Debian 收錄

  經過 Tetralet 及 Andrew Lee 的幫忙，pcmanfm 正式進入 Debian sid 了，Debian 是第一個正式收入 PCManFM 的 Distribution，由於 Debian 支援了高達 11 種平台（architectures）的 GNU/Linux 及 GNU/kfreebsd 和 GNU/Hurd ，使得這個小小的一步卻讓 PCManFM 已經可以在下列 13 平台中執行： alpha amd64 arm hppa hurd-i386 i386 ia64 kfreebsd-i386 mips mipsel powerpc s390 sparc。詳情見 http://packages.debian.org/unstable/utils/pcmanfm 。

• PCManFM 0.3.1 Beta2 版於 8 月 27 日釋出

  PCManFM 在最近兩週內發行了三個版本，PCMan 真不愧為熱血開發者，這次他在新的版本內支援了 HAL ，因此可以自動偵測並 mount/umount/eject 外接儲存裝置（硬碟、USB 隨身碟、CD-ROM、DVD 等等）。詳情見 http://www.gnomefiles.org/version.php?soft_id=1263 。

• gcin 1.2.2 版於 8 月 28 日收錄於 Fedora Extras。

• gcin 1.2.3 版於 9 月 1 日釋出，1.2.3 的主要改進是：
  • 現在會自動複製一份單字的詞到使用者的詞庫。
  • 如果有單字的詞時，預選詞視窗不會出現的問題。

  • 詞音的資料格式有變動，使用次數統計由 8->32 bit，為避免造成相容的問題，gcin 現在使用的 db 是 ~/gcin/tsin32*。tsd2a 不變，gcin 的詞庫管理程式現在全部改成 tsa2d32, tsd2a32。gcin 會自動轉換，一般使用者不需要任何處理。

  • freebsd .gtab 相同 keys，順序會亂掉的問題。Thanks to LGJ for testing
  • 新增 command gcin-gb-toggle 程式，這樣就可以加在 hot keys 一類的程式切換簡/正體字。Thanks to caleb. 切換的 delay 縮短至 0.1 second.
  • 注音新增希臘字母 ㄡ(Ω,ω) ㄉ(δ,Δ) ㄇ(μ) ㄒ(θ) ㄙ(Σ,σ)。

  • gtab.list 新增 icon file name 的欄位，可以在 tray 顯示輸入法的 icon，icon file 可以放在 ~/.gcin or /usr/{local}/share/icons/gcin。目前缺各輸入法的 icons，詞音有一個測試的 icon，不怎麼好看。icon 的背景最好是透明的。【編按：已經有人做了 aqua 風格的 tray icons 了，但美美的 icon 永遠不嫌多，有美術能力的讀者還不趕快發揮一下？】

  • 如果使用簡體字輸出則無法用 ctrl-alt-r or g 重複字串的問題。
  • 內碼輸入法中按空白鍵關閉再按一次會切至內定輸入法的問題。
  • updated man page from caleb
  • 使用 pop-up 的視窗，右下角狀態視窗刪除，改成直接從 tray 顯示。

shrink this item

可以在你的 Linux 上跑的軟體成千上萬，要如何找到新套件？安裝了套件之後， 又如何升級或移除？如何滿足套件之間的相依性？你需要一個套件管理系統來幫你。 除了系統現有的套件管理系統（如 debian 的 apt 或 fedora 的 yum）之外， 有沒有其他套件管理系統更適合你的需要呢？

今年的第十三場心得分享，將由 Candyz 分享他鑽研套件管理系統的心得， 這是累積多年功力的結果，一次灌頂加持，你再不來就沒機會囉！

• 時間： 9/5 7:00pm - 9:00pm

• 地點： MixCoffee&Tea

• 講者： Candyz
• 講題： Linux 的套件管理系統 (Package Management System)
• 大綱：
  1. 套件管理系統簡介
     1. 什麼是套件管理系
     2. 為什麼需要套件管理系統
     3. 套件管理系統的功能
  2. Linux 的套件格式 (Package Format)
     1. Binary packages
     2. Source packages
     3. Recipe packages
     4. 套件格式之間的轉換
  3. 套件管理員 (Package Manager)
     1. 用 rpm 格式的 (Red Hat Package Manager/RPM Package Manager)
     2. 用 deb 格式的
     3. Slackware 用的 pkgtool
     4. Arch Linux 用的 pacman
     5. Gentoo Linux 用的 portage
     6. Gobo Linux 用的 recipe for
     7. Smart Package Manager
  4. 檔案庫 (Repository)
  5. 其他的套件管理系統
     1. klik
     2. Autopackage
     3. EPM
     4. Conary
     5. ZENworks Management Daemon (zmd)
     6. Checkinstall
  6. 實例
     1. Ubuntu 6.06 with APT (Synaptic)
     2. FC5 with YUM (Pirut Yumex)
     3. SuSE 10.1 with Smart (Smart Gui)

shrink this item