Plan 9 from Bell Labs

rioをGUIとして使ったPlan 9画面
開発者	ベル研究所
OSの系統	Unixの後継
開発状況	Current
ソースモデル	フリーソフトウェア/オープンソース
最新安定版	Fourth Edition / 2015年1月10日 (9年前) (2015-01-10)[1]
プラットフォーム	x86, MIPS, DEC Alpha, SPARC, PowerPC, ARM
カーネル種別	ハイブリッド
既定のUI	rio / rc
ライセンス	Lucent Public License（英語版） 2021: MIT[2][3] 2014: GPL-2.0-only[4] 2002: LPL-1.02[5] 2000: Plan 9 OSL[6][7][8][9]
ウェブサイト	https://9p.io/plan9/
テンプレートを表示

Plan 9 from Bell Labs（通称 Plan 9）は、主に研究用に使われている分散オペレーティングシステム。ベル研究所の Computing Sciences Research Center で1980年代中ごろから2002年まで、UNIXの研究上の後継として開発された。Plan 9 は、ネットワークやユーザインタフェースまで含めたあらゆるシステムインタフェースを、個別のインタフェースではなくファイルシステムを通して統一的に表現することを特徴とする。Plan 9 は9Pプロトコルを使い、ユーザーにワークステーション毎に独立した作業環境を提供することを目指している。

Plan 9 は、UNIXの流れを汲むオペレーティングシステム (OS) の一種であり、開発に当たってUNIXの設計の問題点を改善することを念頭に置かれている^[10]。

Plan 9の"9"には、UNIX version 8の次の版という意味もあると言われている（UNIX version 9と10も作られているが）。

また、フルネームをPlan9 from Bell Labsだとしているが、これはエド・ウッドの史上最低の映画と評されたSF映画 Plan 9 from Outer Space から来ている^[11]。また、プロジェクトのマスコットキャラクターGlendaの名も、同じくエド・ウッド作品グレンとグレンダにちなむ。初期の（つまり間に合わせの）ウインドウシステムの8½は（9に足りてない、という意味もあるが）フェデリコ・フェリーニの名画「8 1/2」に掛けており、ハッカー流ジョークの側面でもUNIXの後継であることをうかがわせる。

Plan 9はベル研究所内の主な研究用プラットフォームとしてUNIXを代替し、システムの使用とプログラミングについての本来のUNIXのモデル、特に分散マルチユーザー環境にいくつかの変更を加えることの研究対象ともなった。1980年代中ごろに始まった当初、Plan 9はベル研究所内部のプロジェクトだった。

Plan 9はベル研究所の Computing Science Research Center のメンバーが開発した。そのグループはUNIXやC言語を開発したグループと同一である。当初チームはロブ・パイクやケン・トンプソンらが率い、Computing Techniques Research Department のリーダーとしてデニス・リッチーが支援した。開発には、ブライアン・カーニハン、ビャーネ・ストロヴストルップらも貢献している^[12]。

1992年、大学向けに初めてリリースした。1995年、一般向けの商用OSとしてリリースした。1990年代末、ベル研究所を引き継いだルーセント・テクノロジーは、このプロジェクトの商業化を断念。2000年、オープンソースライセンスで非商用リリースを行った。2002年、新たにフリーソフトウェアライセンスで非商用リリースを行った。

ベル研究所の研究員やマサチューセッツ工科大学などの Plan 9ユーザーコミュニティが、ISOイメージの形で頻繁なマイナーリリースを継続している^[13]。その開発はいまだにベル研究所がホスティングしている。開発ソースツリーは9PプロトコルかHTTPプロトコルでアクセスでき、インストールしたものを最新に保つのに使われている^[14]。OS本体をISOイメージとしている以外に、アプリケーションやツールのリポジトリもベル研究所がホスティングしている。

UNIXの問題点とは、1つのコンピュータを多くの利用者が共有することを前提に作られており、多くのコンピュータを多くの利用者が共有することは考えられていないことである。その結果、利用者が特定のコンピュータを占有することになり、それらのコンピュータは雑然と管理運営されることになる。

UNIXの当初の環境では、どの端末からコンピュータを使っても同じ環境を再現できた。Plan 9では、それをネットワーク上に繋がった分散処理環境上で実現する。

また、UNIXの開発がローカルなファイルシステムをどう表現するかということをテーマとして始まったのに対して、Plan 9は、ローカルであれリモートであれ、リソースというものにどうアクセスするかということを課題とする研究として始まった。

したがって、UNIXの設計当初になかったネットワークの利用を前提とし、端末、CPUサーバ、ファイルサーバ、認証サーバを分けることでセキュリティの向上を狙う。また、ファイルサーバは毎日のスナップショットを保存し、ユーザーレベルでのバックアップ作業をほぼ不要なものとした。

当初はMOジュークボックスなどの利用を考えており、ハードディスクはMOジュークボックスのキャッシュという考え方だった。最近ではハードディスクの大容量化と低廉化が進んでいるため、MOジュークボックスの代わりにハードディスクを使えるようになりつつある。

UNIX以前、多くのオペレーティングシステムはそれぞれのデバイスにアクセスするのに、それぞれ異なる機構を用意していた。例えば、ディスクドライブにアクセスするAPIは、シリアルポートでデータ送受信をするためのAPIとは全く異なるし、プリンターにデータを送信するAPIとも全く異なっていた。

UNIXはそのような差異をなくそうとし、全ての入出力をファイル操作でモデル化しようとした。そのため、全デバイスドライバが制御手段として read および write 操作に対応する必要に迫られた。こうすることで、mvやcpなどのユーティリティで、実装の詳細を気にすることなくデバイスからデバイスにデータを転送することができるようになった。しかし、UNIXでは多くの重要な概念（例えば、プロセス状態の制御など）はファイルにきれいにマッピングされなかった。ソケットや X Window System といった新たな機能が追加されたとき、それらはファイルシステムの外に存在するようになった。新たなハードウェア機能（ソフトウェアがCDのイジェクトを制御するなど）も、ioctlシステムコールなどのハードウェア固有制御機構を使うようになった。

Plan 9研究プロジェクトは、ファイル中心の見方への回帰を目標とし、それ以外の手法を排除した（その一部は、外のUnixへ与えた影響が限定的であった、ベル研版UNIXのバージョン8, 9, 10から引き継がれたものである）。Plan 9のプログラムから見れば、ネットワークやユーザインタフェースのリソース（ウィンドウなど）も含めたあらゆるリソースが階層型ファイルシステムの一部となっており、それ以外の特別なインタフェースは使わない^[13]。

Plan 9は単一のマシンにインストールして、自立したシステムとして使うこともできる。しかし、OSの個々の機能コンポーネントをそれぞれ別のハードウェアプラットフォームに配置することもできる。模範的な配置では、RioというGUIを動作させた軽量な端末をユーザーが使い、ネットワーク経由でCPUサーバに接続して、そちらで計算量の多いプロセスを実行し、さらに別のマシンに用意した永続的データストレージをファイルサーバとして使う。最近のデスクトップコンピュータでは、複数の仮想機械を動作させて、この環境を1台のマシン上に再現することができる。

Plan 9設計者はマイクロカーネルと似たような目標を掲げていたが、実際のアーキテクチャや実現方法は異なる。Plan 9の設計目標は次の項目を含む。

ファイルとしてのリソース

全てのリソースを階層型ファイルシステム内のファイルとして表現する。

名前空間

アプリケーションから見て、ネットワークは単一で一貫した名前空間であり、それも階層型ファイルシステムとして表現される。しかし、実体はローカルまたはリモートに分離されたリソース群である。各プロセスの名前空間はそれぞれ独立に構築でき、ユーザーは異なる複数の名前空間のアプリケーション群を同時に扱える。

標準通信プロトコル

9Pという標準プロトコルを使い、ローカルやリモートの区別なく、あらゆるリソースにアクセスする。

Plan 9では、ファイルも画面^{[要曖昧さ回避]}もユーザーもコンピュータも、それぞれに固有のパス名が対応している。それらは全て既存のUNIXの手法で操作されるが、それに加えて任意のオブジェクトにパス名としての名前をつけることができる（World Wide WebのURIシステムに似ている）。UNIXでは、例えばプリンターなどの機器は /dev 配下の名前で表されるが、ネットワーク経由のプリンターはそのように表されることはなく、直接接続しているプリンターだけである。Plan 9ではプリンターはファイルとして仮想化され、ネットワーク上のあらゆるプリンターに任意のワークステーションから同じ方法でアクセスできる。

また Plan 9では、実世界では同一のオブジェクトにユーザーごとに異なる名前を付けることができる。各ユーザーは各種オブジェクトを自分の名前空間に集め、個人的環境を生成できる。UNIXでは類似の概念として、別のユーザーからコピーされることでユーザーが特権を得るというコンセプトがあるが、Plan 9 ではそれを全てのオブジェクトに拡張している。ユーザーは容易に自分自身の「クローン」を生成することができ、それに変更を加え、それらが作成されたリソースに影響を与えることなく削除できる。

UNIXでは、「リンク」やファイルシステムの「マウント」といった考え方で各種リソース群からファイルシステムを構築できる。それらを利用すると、元々のディレクトリは見えなくなる。例えば、"net" というディレクトリに新たなファイルシステムをマウントすると、元々の "net" ディレクトリ配下の内容にはアクセスできなくなる。

Plan 9は「unionディレクトリ」という考え方を導入した。これは、異なる媒体やネットワークにまたがるリソース群をまとめたディレクトリであり、他のディレクトリと透過的に連結することができる。例えば、他のコンピュータの /bin ディレクトリを手元のコンピュータの同名のディレクトリと連結し、ローカルとリモートのアプリケーションに透過的にアクセスできるようにすることができる。同様に、/dev に外部のデバイスやリソースをまとめると、全くコードを追加することなくネットワーク経由でデバイスを共有できる。

LinuxディストリビューションのLive CDの多くは、この機能の限定版である union mount という機能を実装しているものが増えている。

/proc ディレクトリには動作中プロセスの一覧があり、それぞれの状態を示している。いわゆる「プロセスファイルシステム（procfs）」と呼ばれるもので、標準化はされておらず詳細は異なるが、Linuxその他多くのUnixでも採用されている。プロセスは名前付きのオブジェクト（infoファイルやcontrolファイルのあるサブディレクトリ）として /proc 配下にあり、他のカーネルリソースと共に動的I/Oチャネルもあり、ユーザーはそれにコマンドを送ったり、データを読み取ったりできる。ユーザーは一部のシステムコールを使ったプログラムをコンパイルしてカーネルとやり取りする必要はなく、ls や cat といったコマンドでプロセスを検索し、操作することができる。

他のマシンの /proc ディレクトリは他の特殊なファイルシステムと同様、ユーザーの名前空間にマウントでき、ローカルにあるかのようにそれを使うことができる。これにより、複数のマシンから成る分散コンピューティング環境ができる。ユーザーの机上にある端末、データを格納してあるファイルサーバ、高速CPUや認証やゲートウェイなどのその他サーバ群などがあり、それら全てがユーザーが見慣れたディレクトリ階層を使っている。ユーザーはファイルサーバやサーバで動作中のアプリケーションやネットワーク上のプリンターなどを集め、端末上の個人的名前空間にそれらをまとめることができる。

Plan 9は多数の通信プロトコルやデバイスドライバのインタフェースとしてのシステムコールを持たない。例えば、/net はTCP/IP全体のAPIの役割を担っており、スクリプトやコマンドで操作可能で、制御ファイルに書き込むことでコネクションを読み書きできる。/net/tcp や /net/udp といったサブディレクトリはそれぞれのプロトコルへのインタフェースとして使うことができる。例えば、NATを実装する場合、公開IPアドレスを持つ境界線上のマシンの /net をマウントし、内部ネットワークで Plan 9 の9Pプロトコルを使い、プライベートIPアドレスの内部ネットワークから当該マシンへと接続する。VPNを実装する場合は、インターネット上でセキュアな9Pプロトコルを使い、リモートのゲートウェイの /net ディレクトリをマウントすればよい。

/net で union ディレクトリを使う例を示す。オブジェクト指向プログラミングにおける継承のように、（リモートの） /special に対して、別のローカルなディレクトリを連結（重ね合わせ）する。すると同じ名前の制御ファイルはあとから重ねた方で隠され、新たな制御ファイルは追加された状態になる。言ってみれば union ディレクトリは、元の2つの親を継承した子オブジェクトのようなものである。オリジナルの機能は部分的に変更されることがある。これを /net ファイルシステムで考えると、/net/udp サブディレクトリを更新または隠蔽すると、UDPインタフェースにローカルなフィルタープロセスをかませて制御または拡張でき、/net/tcp は元のまま、おそらくリモートマシン上で動作させておくといったことができる。名前空間はプロセス単位に設定可能なので、信頼できないアプリケーションに対して制限を加えた /net union ディレクトリを見せることで、ネットワークアクセスを制限することができる。

このような機構は、異なるシステム上で異なる言語で書かれたファイルシステムや「オブジェクト」を容易に連結でき、プログラマからはファイルシステムの名前付けやアクセス制御やセキュリティの大部分が透過的となる。

類似の機構として4.4BSDの portal^[15]がある。UDPは実装されていない、（慣習であって本質的な違いではないが）マウントポイントが /net ではなく /p である、といった点が違う。

Plan 9はUNIXをベースとしているが、通信を中核機能としたシステムを構築できることを示すために開発された。全てのシステムリソースには名前があり、ファイルのようにアクセスでき、動作中の各プログラムに対応して動的に分散システムのビューを定義できる。この手法は、ユーザーやアプリケーションに提示するデータを保持するサーバ群を通常ファイルの集まりのように見せることで、アプリケーション設計の汎用性とモジュール性を改善する。

Plan 9のネットワーク透過性サポートの鍵となる部分は、9Pというプロトコルである。9Pプロトコルとその実装は、名前付きのネットワークオブジェクト同士を結びつけ、ファイルのようなシステムインタフェースとして提示する。9Pは高速なバイト指向分散ファイルシステムであり（ブロック指向ではない）、リモートマシン上のNFSサーバが提示するオブジェクトだけでなく、任意のオブジェクトを仮想化できる。このプロトコルはプロセスやプログラムやデータと通信するのに使われ、ユーザインタフェースとネットワークの両方を含んでいる。第4版では 9P2000 に改称された。

Plan 9の内部コードはUTF-8となっている。このため、多言語の問題は基本的には発生しない。また、そもそもUTF-8自体、Plan 9の研究の過程でケン・トンプソンが考案したもので、1992年に全コードがUTF-8対応になった^[16]。なお、Plan 9 がサポートしているのは、Unicodeの基本多言語面だけである。

インストール可能な実行環境がx86向けに用意されている。また、MIPS、DEC Alpha、SPARC、PowerPC、ARMなどのアーキテクチャにも移植されている。システムは ISO/ANSI C の方言の一種で書かれている。いくつかのアプリケーションはAlefという独自の言語で元々は書かれていたが、後でシステムと同じC言語の方言で書き直されたものもある。POSIX対応アプリケーションを移植可能であり、ソケットは ANSI/POSIX Environment APE 経由でエミュレートできる。最近では、Plan 9上でLinux用バイナリを実行できる linuxemu というアプリケーションも開発中である。

IBMのスーパーコンピュータ Blue Gene にも移植されている^[17]。

Plan 9はUNIXの中核的概念——すなわち全てのシステムインタフェースをファイル群で表現するということ——が現代的分散システムとして実装でき、機能することを示した。Plan 9 の一部機能、例えばUTF-8は他のオペレーティングシステムにも実装された。LinuxなどのUnix系オペレーティングシステムは9P、Plan 9 のファイルシステムやシステムコール体系も部分的に実装した。また、Plan 9 のアプリケーションやツールを集めた Plan 9 from User Space はUnix系システムに移植され、ある程度の人気を得ている。Glendix は、Linuxカーネルの周囲のGNUのシステムプログラムを Plan 9 内のプログラムで置き換えようとするプロジェクト（あるいは、逆に Plan 9 のカーネルを Linux に置き換えるプロジェクト）である。

しかし、Plan 9はUNIXほどの人気を得ることはなく、研究用ツールという位置づけに終始した。Plan 9に対しては、「オペレーティングシステム研究での興味深い論文を生成するためのデバイスとして主に機能している」という批判もある^[18]。エリック・レイモンドは著書 The Art of Unix Programming で、Plan 9が広まらない背景について、次のように考察している。

Plan 9が失敗したのは単に、Unix がそれ以前のシステムを凌駕したほどPlan 9は注目に値する改良ではなかったからである。Plan 9に比べると Unix はガタピシ言って錆付いたところもあるが、与えられた仕事はちゃんとやっており、現在の位置に留まるだけの資格がある。野心的なシステムアーキテクトへの教訓がここにある。よりよいソリューションにとって最も危険な敵は、すでに存在する十分うまく動作するコードベースである。^[18]

Plan 9の支持者や開発者は、採用を妨げていた問題は既に解決され、当初の目標としていた分散システム、開発環境、研究用プラットフォームには十分な完成度であり、今後徐々に広まっていくだろうと主張している。Infernoは仮想機械上で動作するため、混在グリッド環境の一部として Plan 9 の技術をもたらす原動力になるとしている^{[19][20][21][22]}。

GNUプロジェクトはPlan 9のライセンス^[23]をフリーソフトウェアライセンスだとは認めていなかったが、2003年6月にそのライセンスに変更が加えられ、GPLとは整合性を持たないながらも、フリーソフトウェアと認められるようになった^[24]。OSIもオープンソースライセンスと認めており、Debianフリーソフトウェアガイドラインには合格している。全ソースコードがそのライセンスでフリーで入手可能である。

• Acme (テキストエディタ) - プログラマ用ユーザインタフェース
• 9P - ファイルシステム・プロトコル
• Inferno (オペレーティングシステム) - Plan 9 から派生した分散OS

ウィキメディア・コモンズには、Plan 9 from Bell Labsに関連するカテゴリがあります。

• Plan 9 from Bell Labs（公式サイト、英語）
  • イメージキャラクター「Glenda」（JPEG画像）
• その他の関連文書など（英語）
• README for 2nd Edition by Brian W. Kernighan
• Plan 9 projects in the GSoC
• Organizations using Plan 9 and Inferno Plan 9 や Inferno を使っている組織の不完全な一覧

• Slides - Video from FOSDEM 2006
• Plan 9 is not dead at FAST-OS 2005

ネイティブ

• Plan 9 - Vita Nuova Holdings による製品版

仮想

• Plan 9 - QEMU用イメージ
• Plan 9 - VMware Player 用
• Plan 9 - Vx32拡張環境用

• Plan9翻訳プロジェクト
• http://plan9.aichi-u.ac.jp/
• ベル研究所 Plan9の概要（ASCII24のニュース）
• http://p9c.cc.titech.ac.jp/plan9/
• 9fans, メーリングリスト
• Ninetimes Plan 9、Inferno、Unix といったベル研究所製OSに関するニュースサイト
• "Plan 9: The Way the Future Was" from The Art of Unix Programming by Eric S. Raymond
• Reinventing UNIX: An introduction to the Plan 9 operating system, by Hancock, B., Giarlo, M.J., & Triggs, J. A., published in Library Hi Tech, 21(4), 471-476.
• Introduction to OS abstractions using Plan 9 from Bell Labs, by Francisco J Ballesteros
• Plan B - Plan 9 を基盤とした研究用OS
  • Octopus - Plan B からの派生
• Glendix - Plan 9 のユーザー空間ツールをLinuxに移植したもの