為什麼Plan9在生產環境沒有實際的應用，是因為應用程序匱乏的原因么？

01-27

按理說現在的大規模集群的應用場景很適合Plan9的概念吧，但目前來看現在它還局限在實驗室里。

今天剛好看到一篇譯文，貼到這裡和大家一同參考吧：

概述

Plan-9是一個很棒的、很先進的，而且完全是全新實現的Unix系統，它的目的就是要最終解決Unix最初的諾言：一切皆為文件。你聽說過這套系統嗎？沒有？那好，下面就是為什麼。

我十分確信你不知道Plan-9是什麼東西，並且很有可能你還是第一次聽說這個名字。

Plan-9是一款神奇的新版Unix，幾乎是由70年代當初開發Unix系統的同一個團隊開發的。它的確是一款非常酷的操作系統。它跟Unix非常相似，但它不是Unix，它糾正了Unix系統里很多不一致的、古怪的、至今仍然存在的特性。

Unix在當初立項時有個這樣的許諾：系統里任何的東西都是『文件』——根據某些文件的定義。例如，sockets，也許稱作網路連接更合適，它們就不是文件，進程也不是文件。

在Plan-9中，所有的這些問題都解決了！先進的9P虛擬文件系統協議最終讓所有東西都成為了文件。目錄變成了「命名空間」，資源被映射成了文件。多麼神奇！現在，你可以通過對/proc目錄(現在應該成其為一個命名空間)里的一個文件使用「cat」命令來查看進程的情況。同樣，打開一個網路連接的方式變成了打開/net/tcp目錄里的一個文件，這就是它。」iotcl」系統調用在這個系統里完全被根除了，因為基於操作系統上的現代文件形式中的這種怪胎已經不再需要了。

那麼，為什麼你從來沒有聽說過這樣一款神奇的操作系統呢？

你從來沒有聽說過它的原因是，它並不是一款成功的操作系統。這怎麼可能呢？是這樣的，是因為Plan-9實際上沒有解決任何問題。在Unix世界裡，從來沒有人抱怨說Unix沒有兌現當初關於文件抽象的諾言。

在隨後的日子裡，Plan-9里的/proc文件系統概念被人移植到到了Solaris等很多其他商業版Unix系統里(Linux也採用了它)。 Plan-9里另外一個非常著名的首創——UTF-8——被迅速的被眾多其它操作系統採用，不僅僅是Unix家族。在所有的操作系統里，即使存在一些由於各種原因沒有採用UTF-8的，它們也開發出來將UTF-8和本地編碼轉換的程序庫。

Plan-9的對於網路通信的特殊的處理方式需要在這裡特別的說明一下。雖然用基於命名空間/文件系統的方式來代替專用API來處理網路操作，聽起來很吸引人，但是整個Unix世界，不僅所有人都已經接受了使用伯克利Socket API做為標準方式來進行網路編程，甚至Windows平台也實現了幾乎相同的API里簡化各種網路應用向Windows上移植——雖然存在一些小問題。

更重要的是，Plan-9發明的這種與眾不同的網路編程編程方式在誕生之日就註定了毫無用處。因為在當時，大部分做網路編程的人都已經轉向了更高的網路抽象層。RPC和Corba已經誕生，所有的需要跟遠程伺服器通信的應用全都轉向了它們。程序員為了跟遠程服務通信時需要打開sockets的機會越來越少，所有的他們都已經習慣了使用Berkeley API。(旁註：曾經有一個POSIX模擬層，叫做APE「ANSI/POSIX Environment」，試圖將Plan-9上的某些功能映射到POSIX對應的功能上。這個模擬層一直都沒實現，因為一些應用——例如X11——的遷移過於複雜，不可能完成。「維持它正確運行的工作量太過巨大」——維基百科)。)

Plan-9的一個最主要的問題出在ATT和Unix幕後的這群人身上，儘管他們都是才華橫溢的科學家和程序員，但他們不懂得如何去開發商業軟體，而ATT也從來沒打算進入軟體業。這些，我承認聽起來有些大不敬，但事實就是這樣。他們使用軟體，他們喜歡開發內部軟體來運行他們的高端網路設備，但是他們卻從來不去開發要賣給別人的軟體，而且跟Sun，IBM，微軟等商業公司不一樣，這從來不是他們的資金的主要來源。這就意味著他們不需要有外部世界需要什麼樣的軟體的意識。舉個例子，Sun公司就需要這樣的意識，所以他們開發出了RPC。他們認識到人們在進行網路編程時很痛苦，他們看到了創建一個網路抽象層的商業機會：「嗨，大夥們，SunOS有一個很酷的東西，讓我們能夠不直接跟sockets打交道就可以開發出網路應用！你絕對應該使用SunOS」。

還有，在Plan-9中，很多「好的老的東西」被刪除了，大量的跟其它Unix不兼容的東西被加入了系統。這幾乎打消了眾多公司試圖將他們的應用遷移到Plan-9的念頭。如果你不知道這樣一個新系統是否能夠獲得成功，那為什麼要耗費了大量的工作把自己的應用遷移到這個新平台上呢？這就是典型的雞生蛋蛋生雞問題：一個操作系統的價值就在於上面有大量應用可運行，無它。如果一個系統很新，你要做的是必須發展一個能夠支持各種應用的生態系統，通過它們讓這個系統變得有價值。只有兩條路能做到這樣。第一個就是讓這個系統跟目前現存的系統保持最大的兼容，也就是Unix， POSIX 和 Motif 這些系統。第二個就是創建自己的生態系統，以此來提升新系統的價值，微軟Windows和Office辦公系統軟體就是典型例子。

我們應該從Plan-9的歷史教訓中總結出一些經驗嗎？

當然，我們至少可以獲得下面這些：

首先是，不要試圖去修改那些沒有壞或你認為不夠好的東西，如果要修，只去修改出問題的部分，不要去修改看起來很笨——但事實上是在按要求工作的東西。例如，UTF-8是個非常棒的創意，你需要它，但你可以用程序庫或子系統實現它，這樣其它系統也能使用它，而不是去基於這個編碼開發出一套全新的操作系統。
第二個是，在開發一個你的系統前，先去搞清楚它是否有市場，或者人們是否需要這個東西。例如，/net/tcp文件系統絕對是一個精彩的純學術課題，如果是早幾年，它一定能完勝Berkeley sockets，但不應該是在直接使用Socket的人群已經沒剩幾個的時候。
第三，要麼完全的獨立自主，要麼跟現有的系統保持最大兼容。但Plan-9卻處在它完全不應該的位置：中間。這套系統既不跟現有的所有Unix系統兼容，同時也不提供其它Unix系統中都有的、必要的工具。沒有高級文本編輯器、表格軟體、CAD程序和伺服器軟體。它就是一個神奇的空盒子，卻沒有提供任何方法讓人們容易的把東西放進去。

這些看起來都是一些非常高層的東西，並不是特別跟程序員的日常開發相關。看起來是這樣，但事實遠非如此。現如今，你可以很容易的開創自己的事業，開始向用戶提供某種的服務。然而，你的服務是一個有價值的產品？還是變成了另外一個Plan-9傳奇？這並不是很容易判斷的事。例如，你的打算開發一個報表系統，來展現監控數據或其它任何可視的狀態，如果你沒有提供用它將這些報表導入到Excel的功能，那你在寫第一行代碼前就輸了。如果你打算開發一個新的Web社交應用，而你沒有提供使用Fackbook、Twitter或LinkedIn登錄的方式，那你在搭建WEB伺服器前就輸了。如果你web服務中信息的導出方式沒有採用RSS或ATOM，而是採用了一種全新的格式，猜會怎麼樣？你在吸引到第一個用戶前就輸了。但是，比著一切更重要的是：你的產品真正的解決了一個現實存在的問題嗎？

文章來自：Plan-9效應：為什麼東西不壞就不要去修它

請問怎麼樣安裝和使用？

概念體系與其他系統相差太遠，有學習門檻。

官網說它是一個試驗性系統。

不知道與現有網路介面是否兼容，plan9似乎沒有socket介面。

看一個plan9的ppt，其中舉了一個網路通信的例子，unix下用tcp socket通信要好長一段代碼，在plan9中就兩三行，佩服的不行。我覺得這個系統值得研究一下，就像當年最早投入到linux kernel研究的那些人一樣。說不定幾年後在linux陣營之外還有一個plan9陣營。^-)