編程珠璣番外篇-K. Plan 9 的故事（修訂版）
這樣的例子在歷史中屢見不鮮。Jobs 和 Apple 分手後開創的 NeXT 公司的操作系統和硬件設備，創新點很多，市場反響卻不大。而 NeXT 系統在軟件和硬件設計上的創新，以及工業設計的思想，最終成爲了現在 iOS 系統、Mac 系統軟硬件設計的基石。同樣是 Apple, 當年出品的 Hypercard 軟件，首創了超文本格式和交互式頁面。雖然 HyperCard 的這些創新在當時並不顯得太出衆，最終被蘋果終止開發。但到了 Internet 出現之後，Tim Berners-Lee 受到這種“超文本 (hypertext)”格式的啓發，將這些思想平移到聯網的計算機上，由此出現了萬維網。Ward Cunningham 更是受這一張一張的“數字卡片”受到，發展出了世界上第一個 wiki 系統 WikiWikiWeb。所有的這些例子，都說明了一項當時未必得到大多數人認可的創新可能會在意想不到的地方鳳凰重生。 本節我們介紹的 Plan 9 操作系統，也是這樣的一個例子。
FTPFS 虛擬文件系統
大部分讀者應該都用過 FTP 在兩臺機器之間傳送文件。FTP 是一種簡單成熟的傳輸協議。試想現在我們需要修改一個 FTP 服務器上的文件，我們無法直接用本機上的編輯器打開這個遠程的文件編輯，而需要先下載這個文件，修改後再上傳。這種編輯遠程文件的方法顯然比編輯本機的文件麻煩多了。 我們退後一步仔細想一下這個不方便，會發現，文件是同樣的一個文件，只是因爲文件不在本地，我們需要藉助於 FTP 協議訪問，所以我們就不能直接編輯它了（事實上有些功能強大的編輯器如 VIM 仍然可以編輯，但普通的編輯器則不能）。在一切都是文件的假設下，我們可以不加區別的訪問軟盤，硬盤和閃存盤上的文件，但這裏，因爲中間多了一個網絡協議，這種“一切都是文件”的方便特性就消失了。 因爲這個需求很常見，很多 FTP 客戶端，如 Windows 下的 LeapFTP, Mac 下的 Cyberduck，都做了一個貼心的功能，在你想要編輯遠程文件的時候，自動將其下載成一個臨時文件，等你修改結束後又自動上傳。但是這依賴於 FTP 客戶端，並不是每個客戶端都提供了這類支持。
FTPFS 就是針對上面提出的這種不方便而出現的一種技術。通過利用一個叫做 FUSE (Filesystem in Userspace) 的技術，FTPFS 允許用戶將遠程的 FTP 文件系統掛載到本地的文件系統上，使得用戶可以像操作本地文件一樣操作遠程文件1，包括查看，編輯，刪除和重命名等等。而實際網絡傳輸協議的細節，則對用戶隱藏了。實際上，FUSE 技術可以用來實現很多“虛擬”的文件系統，而不僅限於將 FTP 文件系統掛載到本地文件系統上這一種。比如，使用 HTTP 協議的文件系統，SSH 服務器上的文件，Flicker 上的圖片，維基百科上的文章，都可以通過 FUSE，抽象成一種虛擬的掛載在本地文件系統上的文件系統。這些虛擬的文件系統，隱藏了協議的細節，將各種不同類型的協議支持下的資源抽象成一個文件系統，也可以掛載到本地的文件系統上。
虛擬文件系統能把資源無差別的抽象成文件系統。這種做法消除了網絡協議的不同造成的訪問障礙，方便了用戶對各種不同資源的訪問。這種 “消除協議差異，一切資源都是文件”的思想，實際上來源於 Plan 9。毫不令人驚訝的是，在 Plan 9 中，乾脆就沒有 FTP 這個命令，所有對 FTP 的操作都是採用掛載 ftpfs 掛載文件系統的方式實現的。
一切都是文件（這次是真的）
上面我們提到了虛擬文件系統可以把資源無差別地抽象成一個文件系統，而這個思想是來源於 Plan 9 操作系統的。且慢，早在 UNIX Programming Environment 中， Brian W. Kernighan 就提出了 “UNIX 中，一切都是文件” 的設計哲學。事實上，UNIX 中的確很多對象是文件：進程是文件，設備是文件，命名管道也是文件。但是，也有很多不是文件，尤其是由其他非 Bell 實驗室加入 UNIX 的組件。舉例來說，計算機網絡設備和服務不是文件（UNIX 的網絡支持部分最先由 UC Berkerly 開發），圖形界面中的對象也不是文件（UNIX 的圖形界面支持最初由 MIT 的 X 工作組開發）。“一切都是文件” 這個口號因爲 UNIX 的發展和新模塊的加入而不再貼切。
UNIX 出現的時候，支持的設備都很簡單，都可以抽象成文件交由內核統一管理，由內核提供 read/write 等系統調用訪問設備。隨着硬件的發展，一些新的硬件需要有超越系統調用範圍的控制方式（例如我們可以控制光盤驅動器彈出托盤，而這個操作在傳統磁盤驅動器上是不存在，也不能簡單的抽象爲 read/write 甚至 unmount 操作），或者爲效率着想，需要用戶空間程序直接和設備通信（如網卡，高速硬盤）。因爲這些需求，和爲未來擴展性考慮，Bell 實驗室在 UNIX 第七版中，也不得不引入 ioctl 等具有無窮擴展性的系統調用機制，配合設備驅動程序，支持對設備的控制。這些做法，繞開了原先統一的 read/write 設備訪問方式。也就是說，設備再也不能簡單地抽象爲文件了。
隨着 UNIX 發展而失卻的“一切都是文件”的純粹哲學，正是 Plan 9 想要恢復的。在 Plan 9 中，通過實現一個叫做 9P 的文件協議，用戶可以自由的把任何資源或服務抽象成本地的一個“虛擬的”文件或者目錄，而對這些文件的操作，會通過 9P 協議，自動映射到對原來資源或者服務的操作。 這樣，訪問資源的各種細節就被隱藏了。在對付那些需要 ioctl 或者其他控制機制的設備或者應用程序時，Plan 9 提倡將程序的控制部分抽象成一個支持 read/write 的 ctl 文件，而非使用專門的 ioctl 系統調用。這樣，其他程序就可以通過讀寫 ctl 文件與被控制的程序通信。從對資源和對控制的抽象不難看出來，Plan 9 把 UNIX 中“一切都是文件”的思想做了進一步的昇華。在 Plan 9 裏面，真的是一切都是文件了──設備是文件，窗口管理器是文件，Email 程序是文件（實際上所有程序都是文件），網絡是文件（實際上所有服務包括 DNS 都是文件），等等。
Plan 9 的創新
要說 Plan 9 的特性，就不能不先介紹一下它的幾個創造者。和 UNIX 一樣， Plan 9也是從 Bell 實驗室計算機科學研究中心開發的。其項目主要負責人是 Rob Pike （現在在 Google 工作，負責 Go 編程語言），當時在 Bell 實驗室的很多人，包括 UNIX 的兩位創始人，Ken Thompson 和 Dennis Ritchie ，以及 Brain Kernighan、Doug Mcllroy （UNIX 管道的提出者）都參與了這個項目的開發。從某種意義上來說，Plan 9 有點充當 UNIX 繼承人的味道。事實上 Rob Pike 最初，也的確是想構建一個更加“現代的 UNIX”。除了堅持 UNIX 中已經成功了的“一切都是文件”，“KISS”等原則外，Plan 9 在原有 UNIX 的設計理念上做了新突破，其中最值得一提的，就是“分佈式操作系統” 的理念。
Plan 9 這個分佈式操作系統的出現和當時計算機發展的趨勢是密不可分的。我們都知道， UNIX 是一種分時操作系統，用戶分享機器資源。UNIX 操作系統則負責在各任務（或者說進程）之間調度。因此，UNIX 是一箇中心化的操作系統。CPU、內存、IO 以及所有的任務的調度都是集中被 UNIX 管理的。上世紀 80 年代中期，更加便宜的微型計算機開始普及。這些微型計算機各自有着磁盤、CPU、內存和 IO 設備。Plan 9 的指導思想，就是把微機組織起來，方便的實現資源共享。
Plan 9 裏，能共享的資源包括文件系統、圖形界面、IO 設備、以及 CPU 和內存等計算資源。這些資源之間千差萬別，我們固然可以針對每種資源設計一個協議，如文件分享用 NFS，圖形界面用 X 協議，打印機用 CUPS 協議等等，不過這種做法在 Plan 9 的設計者看來是不夠優雅的。他們採用的，是在上文我們已經提到過的“一切都是文件”的方法[cite:Plan 9, a distributed system]。我們可以用兩個很有啓發性的例子來說明。
例一、替換 CPU
假想一下我們有一臺日常使用但性能不佳的筆記本，和一臺不在本地但性能強勁的服務器。 我們當然能夠使用遠程計算機的強勁的 CPU 運行一些計算量特大的程序。這不是什麼難事，因爲幾乎所有操作系統都支持登陸到遠程的機器。然而，麻煩的是，如果在遠程運行程序需要讀寫本地的文件，或者訪問掛載在本地筆記本上的打印機，揚聲器麥克風之類設備，我們除了在本地和遠程之間把文件傳來傳去之外，並沒有什麼好方法。特別的，如果我們想借用另一臺計算機上強勁的 CPU 做音頻和視頻解碼，來播放一個放在本機光盤驅動器裏的電影文件的話，我們是不可能指望遠程計算機既能讀本地的光驅，又能把音頻投遞到本機的揚聲器上的。
Plan 9 中，有一個簡單的 cpu 命令，能夠讓用戶自然地使用一個其他機器上的 CPU 運行程序，且仍然能夠訪問本地的所有文件和設備。也就是說，我們可以用遠程計算機上強勁的 CPU 做圖像處理，媒體解碼等任務，並且可以直接把聲音播放到本地的揚聲器。cpu 命令給人的感覺，是除了給機器換個了 cpu 外，其他一切都和原來一樣。這個看似 “神奇” 的功能，其實在 Plan 9 裏實現起來一點都不復雜： cpu 指令首先連接服務器上，然後將本地的所有資源和文件系統，包括窗口管理器，光盤驅動器，揚聲器等設備（別忘了他們都是文件），一股腦兒掛載到服務器上，成爲服務器上的資源。這樣，在服務器上運行的程序，就可以“自然地”使用本地的鍵盤鼠標和顯示器完成交互，還可以訪問你本地的顯示器揚聲器等設備。
cpu 命令真的就是名副其實的換掉了本地計算機的 cpu （其實還有內存）而保留其他一切設備。Plan 9 的這個 cpu 命令，帶有強烈的分佈式操作系統的特徵，而我們平時接觸的操作系統都不是分佈式操作系統，因此 cpu 這個命令至今在現代主流操作系統上沒有完全等價物。
例二、進程間控制和通信
進程間通信可以提高使用計算機的效率（詳細請參見 Page XX：開發人員爲何應該使用 Mac OS X）。UNIX 下的管道就是一個經典的進程間通信的例子。在圖形界面程序和集成化的程序出現後， 應用程序不斷的把多種功能集成到一起，進程間通信反而變得相對困難了。比如說，即使有個給漢字加拼音的程序，除了來回複製粘貼，我們還是不能方便地從文字編輯程序中選取一段自動加上拼音。而 UNIX 下的編輯器可以藉助管道很簡單完成這樣的操作。這個問題的本質困難，用操作系統的眼光來看，在於進程這個對象，沒有在運行時暴露出應有的通信和控制接口。
Plan 9 的一切都是文件的思想從一個新的角度，解決了程序間的數據共享問題。Plan 9 倡導應用程序在運行時都把自己的內部狀態抽象成一個文件系統。舉例來說，一個郵件客戶端程序不光支持圖形界面下查看郵件，用戶還能夠直接通過
cat /mail/fs/inbox/1/subject
cat /mail/fs/inbox/1/body
來查看收件箱（inbox）中第一封郵件的主題和內容。這種設計，使得應用程序不再成爲進程間通信的障礙，從而拷貝粘貼也變得沒有必要。比如說，我們可以直接把草稿箱裏郵件的內容通過管道送給其他拼寫檢查器。郵件客戶端提供的拼寫檢查器再差也沒關係了。這種把應用程序中的對象暴露出來的想法，和 Mac OS X 中的應用程序暴露一個Applescript 字典的設計思想異曲同工。
同樣的道理，Plan 9 也從一切都是文件的思想出發，解決了了程序控制問題。 Plan 9 鼓勵每個應用程序和設備在抽象成文件的時候，都暴露出一個抽象的 ctl 文件。這樣，其他應用程序可以通過向 ctl 文件寫命令的方式，運行時控制應用程序。舉例來說，Plan 9 的窗口管理器 Rio，提供了 ctl 文件，我們可以通過讀取和寫入 ctl 文件，實現一些 Rio 本身不支持的如平鋪所有窗口的操作。同樣，通過對郵件程序的 ctl 操作，我們可以實現郵件的發送和接受的控制等等。Mac OS X 下的 Applescript 也可以完成類似的功能。遺憾的是，除了 Plan 9 和 Mac OS X，其他操作系統對這類進程間控制和通信的支持都不夠完整。
實踐者指南
對 Plan 9 感興趣，想要更多瞭解 Plan 9 的讀者，可以到 http://plan9.bell-labs.com/plan9/ 下載 Live CD， 並在多臺聯網的機器或虛擬機中安裝該系統。喜歡 Plan 9 裏的一些命令，而不想折騰系統的讀者，可以到 http://swtch.com/plan9port/ 下載可以在 Linux，Mac OS X 等主流操作系統上運行的 Plan 9 的移植程序。Rob Pike 的網站 cat-v.org 有最完整的 Plan 9 的資料，以及對 UNIX 設計哲學的反思。