Loading article…
 宇宙服を着たプラン9のマスコット、グレンダ。ルネ・フレンチが描いたもの[1] [2] | |
 rio、ベル研究所の Plan 9 のデフォルトのユーザー インターフェイス | |
| 開発者 | ベル研究所の後継となるプラン9財団 |
|---|---|
| 書かれた | ANSI Cの方言 |
| 作業状態 | 現在[3] [4] |
| ソースモデル | オープンソース |
| 初回リリース | 1992年（大学）/ 1995年（一般大衆） |
| 最終リリース | 第4版 / 2015年1月10日[5] |
| リポジトリ | 9p.io/sources/plan9/sys [6] |
| マーケティングターゲット | オペレーティングシステムの研究、ネットワーク環境、汎用 |
| 利用可能 | 英語 |
| プラットフォーム | x86 / Vx32、x86-64、MIPS、DEC Alpha、SPARC、PowerPC、ARM |
| カーネルタイプ | モノリシック[7] |
| 影響を受けた | リサーチUnix、ケンブリッジ分散コンピューティングシステム[8] |
| デフォルトの ユーザーインターフェース | リオ/ rc |
| ライセンス | 2021: MIT [9] [10] 2014: GPL-2.0のみ[11] 2002: LPL-1.02 [12] 2000: Plan 9 OSL [13] [14] [15] [16] |
| 後継者 | インフェルノ その他の派生およびフォーク |
| 公式サイト | 翻訳元 |
ベル研究所の Plan 9 は、 1980 年代半ばにベル研究所のコンピューティング サイエンス リサーチ センター (CSRC) で開発され、1960 年代後半に初めて開発されたUNIXコンセプトに基づいて構築された分散オペレーティング システムです。2000 年以降、Plan 9 は無料かつオープン ソースとなっています。最終的な公式リリースは 2015 年初頭に行われました。
Plan 9 では、UNIX の「すべてがファイルである」というメタファーが、普及したネットワーク中心のファイルシステムによって拡張され、UNIX のようなオペレーティング システムの中心にあるカーソル アドレス指定のターミナルベースのI/Oは、カーソル アドレス指定のないウィンドウ システムとグラフィカル ユーザー インターフェイスに置き換えられました。ただし、Plan 9シェルであるrc はテキストベースです。
ベル研究所のプラン9という名前は、エド・ウッド監督の1957年のカルト SFZ映画『宇宙からの計画9』に由来している。[17]このシステムは、オペレーティングシステムの研究者や愛好家によって現在も使用され、開発されている。[18] [19]
歴史
ベル研究所の Plan 9 は、もともと1980 年代後半に、ベル研究所のコンピューティング サイエンス リサーチ センターのメンバーによって開発が始まりました。このグループは、もともとUnixとC プログラミング言語を開発したグループと同じです。[20] Plan 9 チームは、当初Rob Pike、Ken Thompson、Dave Presotto、Phil Winterbottomによって率いられ、コンピューティング技術研究部門の責任者であるDennis Ritchieのサポートを受けていました。長年にわたり、Brian Kernighan、Tom Duff、Doug McIlroy、Bjarne Stroustrup、Bruce Ellis など、多くの著名な開発者がこのプロジェクトに貢献してきました。[21]
Plan 9 は、ベル研究所のオペレーティングシステム研究の主要プラットフォームとして Unix に取って代わった。[22]このプラットフォームは、分散型マルチユーザー環境で特にシステムの使用とプログラミングを容易にする、オリジナルの Unix モデルに対するいくつかの変更を検討した。数年間の開発と内部使用の後、ベル研究所は 1992 年にこのオペレーティングシステムを大学に出荷した。3 年後、Plan 9 は書籍出版社のHarcourt Braceを通じて AT&T によって商業的に利用可能になった。ソース ライセンスの価格は 350 ドルで、AT&T はコンピュータ市場全体ではなく組み込みシステム市場をターゲットにしていた。リッチーは、他のオペレーティングシステムが定着していることを考えると、開発者は「大きな置き換え」は期待していなかったとコメントした。[23]
1996年初頭までに、Plan 9プロジェクトはAT&Tによって「棚上げ」され、代わりにサン・マイクロシステムズのJavaプラットフォームのライバルとなる予定だったInfernoが採用された。[24] 1990年代後半、ベル研究所の新しい所有者であるルーセント・テクノロジーズはプロジェクトの商用サポートを中止し、2000年には3番目のリリースがオープンソース・ライセンスの下で配布された。[25] 2002年には新しいフリーソフトウェア・ライセンスの下で4番目のリリースが行われた。 [26] 2015年初頭、Plan 9の最終的な公式リリースが行われた。[25]
ベル研究所の現職および元職員を含むユーザーおよび開発コミュニティは、 ISOイメージの形で毎日マイナーリリースを作成しました。ベル研究所が開発をホストしました。[27]開発ソースツリーは9PおよびHTTPプロトコルを介してアクセスでき、既存のインストールを更新するために使用されます。[28] ISOに含まれるOSの公式コンポーネントに加えて、ベル研究所は外部で開発されたアプリケーションとツールのリポジトリもホストしています。[29]
ベル研究所が近年後のプロジェクトに移行したため、公式の Plan 9 システムの開発は停止していました。2021 年 3 月 23 日、著作権がベル研究所からPlan 9 Foundation に移管された後、開発が再開されました。[10] [30] [31]システムの非公式な開発は 9front フォークでも継続されており、アクティブな貢献者が毎月ビルドと新機能を提供しています。これまでに、9front フォークはシステムにWi-Fiドライバー、オーディオ ドライバー、USBサポート、組み込みのゲーム エミュレーターなどの機能を提供してきました。[32] [33]最近の Plan 9 に触発されたその他のオペレーティング システムには、Harvey OS [34]と Jehanne OS があります。[35]
デザインコンセプト
ベル研究所のプラン 9 はクエーカー教徒に似ています。つまり、「内なる光」を重視し、生活の簡素さ、特に言葉の平易さで知られています。クエーカー教徒と同様に、プラン 9 は布教活動を行いません。
—Sape J. Mullender、Pierre G. Jansen.
実オペレーティングシステムにおけるリアルタイム[37]
実オペレーティングシステムにおけるリアルタイム[37]
Plan 9は分散オペレーティングシステムであり、異機種や地理的に離れたコンピュータのネットワークを単一のシステムとして機能させるように設計されています。[38]典型的なPlan 9のインストールでは、ユーザーはウィンドウシステムrioを実行している端末で作業し、計算集約型のプロセスを処理するCPUサーバーにアクセスします。永続的なデータストレージは、ファイルサーバーやアーカイブストレージとして機能する追加のネットワークホストによって提供されます。[39]
デザイナーはこう述べている。
システムの基盤は、プロセスごとの名前空間とシンプルなメッセージ指向のファイルシステムプロトコルという 2 つのアイデアに基づいています。
— パイクら[40]
最初のアイデア（プロセスごとの名前空間）は、ほとんどのオペレーティングシステムとは異なり、プロセス（実行中のプログラム）がそれぞれ独自の名前空間のビューを持っていることを意味します。これは、他のオペレーティングシステムがファイルシステムと呼ぶものに対応しています。単一のパス名が、異なるプロセスの異なるリソースを参照する場合があります。この設定の潜在的な複雑さは、共通リソースの従来の場所のセットによって制御されます。[41] [42]
2 番目のアイデア (メッセージ指向のファイルシステム) は、プロセスが他のプロセスの名前空間に表示される仮想ファイルを提供することで、他のプロセスにサービスを提供できることを意味します。クライアントプロセスのそのようなファイルへの入出力は、 2 つのプロセス間のプロセス間通信になります。このようにして、Plan 9 は、コンピューティング リソースへのアクセスの中心点として、ファイルシステムという Unix の概念を一般化します。周辺デバイス (マウス、リムーバブル メディアなど)へのアクセスと、物理的に異なるファイルシステムに存在するファイルシステムを階層的な名前空間にマウントする可能性を提供するという Unix のデバイス ファイルの概念を引き継ぎますが、標準化されたプロトコルを話し、そのサービスを名前空間の一部として扱うサーバー プログラムへの接続をマウントする可能性も追加します。
例えば、8½ と呼ばれるオリジナルのウィンドウ システムは、これらの可能性を次のように活用していました。 Plan 9 は、ターミナル上のユーザー インターフェイスを 3 つの疑似ファイルで表します。mouse は、プログラムが読み取ってマウスの動きやボタンのクリックの通知を受け取ることができます。cons は、テキストの入出力を実行するために使用できます。bitblt は、これに書き込むことでグラフィックス操作を実行します ( bit blitを参照)。 ウィンドウ システムはこれらのデバイスを多重化します。つまり、プログラムを実行するための新しいウィンドウを作成する場合、最初にmouse、cons、bitbltが自分自身に接続された新しい名前空間を設定し、ウィンドウ システムがアクセスできる実際のデバイス ファイルを非表示にします。このようにして、ウィンドウ システムはプログラムからすべての入出力コマンドを受け取り、実際の画面デバイスに出力を送信し、現在フォーカスされているプログラムにキーボードとマウスの入力を与えることで、これらを適切に処理します。[39]プログラムは、オペレーティング システムのデバイス ドライバーと直接通信しているのか、ウィンドウ システムと通信しているのかを知る必要はありません。これらの特殊なファイルが期待する種類の入力を提供し、期待する種類のメッセージを受け入れるように名前空間が設定されていると想定するだけで済みます。
Plan 9 の分散操作はプロセスごとの名前空間にも依存しており、クライアントとサーバーのプロセスが上記の方法でマシン間で通信できるようにします。たとえば、cpuコマンドは計算サーバー上でリモート セッションを開始します。このコマンドは、ユーザーの端末のデバイス ( mouse、cons、bitblt ) を含むローカル名前空間の一部をサーバーにエクスポートします。これにより、リモート プログラムは端末のマウス、キーボード、ディスプレイを使用して入出力を実行でき、リモート ログインと共有ネットワーク ファイルシステムの効果を組み合わせます。[39] [40]
9Pプロトコル
他のプログラムにファイルとしてのサービスを提供したいすべてのプログラムは、9Pと呼ばれる統一プロトコルを話します。他のシステムと比較して、これによりカスタムプログラミングインターフェイスの数が減ります。9Pは、サーバーとクライアント間で配信されるメッセージを提供する、汎用的でメディアに依存しないバイト指向のプロトコルです。 [43]このプロトコルは、ユーザーインターフェイスとネットワークの両方を含むプロセス、プログラム、およびデータを参照および通信するために使用されます。[44]第4版のリリースで、修正され、9P2000に名前が変更されました。[26]
他のほとんどのオペレーティングシステムとは異なり、Plan 9はデバイスにアクセスするための特別なアプリケーションプログラミングインターフェイス（ Berkeleyソケット、Xリソース、ioctlシステムコールなど）を提供していません。 [43]代わりに、Plan 9デバイスドライバーは制御インターフェイスをファイルシステムとして実装し、通常のファイル入出力操作の読み取りと書き込みでハードウェアにアクセスできるようにします。その結果、ネットワーク経由でデバイスを共有するには、対応するディレクトリツリーをターゲットマシンにマウントします。[17]
ユニオンディレクトリと名前空間
Plan 9 では、異なるディレクトリツリーからファイル ( namesと呼ばれる) を 1 つの場所に集めることができます。結果として得られるユニオンディレクトリは、基になるディレクトリの連結として動作します (連結の順序は制御できます)。構成ディレクトリに同じ名前のファイルが含まれている場合、ユニオンディレクトリの一覧 ( lsまたはlc ) は、単に重複した名前を報告します。[45]単一のパス名の解決はトップダウンで実行されます。つまり、ディレクトリtopとbottom が、 top を先頭にしてuにユニオンされた場合、u/name は、 top/nameが存在する場合はそれを示し、 bottom/nameが存在し、top /name が存在しない場合はそれのみを示し、どちらも存在しない場合はファイルを示しません。サブディレクトリの再帰的なユニオンは実行されないため、 top/subdirが存在する場合、 bottom/subdir内のファイルはユニオンを介してアクセスできません。[46]
ユニオン ディレクトリは、一連のbindコマンドを使用して作成できます。
/arm/bin をバインド /bin バインド -a /acme/bin/arm /bin バインド -b /usr/alice/bin /bin
上記の例では、/arm/binが/binにマウントされ、 /arm/binの内容が/binの以前の内容を置き換えます。Acmeのbinディレクトリは/bin の後にユニオンマウントされ、Alice の個人用binディレクトリは前にユニオンマウントされます。 /binからファイルが要求されると、最初に/usr/alice/binで検索され、次に/arm/binで検索され、最後に/acme/bin/armで検索されます。
このように、別々のプロセス名前空間は、通常、シェルの検索パスの概念を置き換えます。 パス環境変数 ( $path)は、 rcシェル (Plan 9 で主に使用されるシェル) にまだ存在します。ただし、rc のパス環境変数には、慣例的におよび ディレクトリ/binのみが含まれており.、変数を変更することは推奨されません。代わりに、追加のコマンドを追加するには、複数のディレクトリを 1 つの としてバインドする必要があります/bin。[47] [39] Plan 9 とは異なり、Unix シェルのパス環境変数は、実行可能ファイルをコマンドとして追加する必要がある追加のディレクトリを含むように設定する必要があります。
さらに、カーネルはプロセスごとに別々のマウントテーブルを保持できるため、[37]各プロセスに独自のファイルシステム名前空間を提供できます。プロセスの名前空間は独立して構築でき、ユーザーは異なる名前空間を持つプログラムを同時に操作できます。[40]名前空間を使用すると、 chrootに似た隔離された環境をより安全な方法で作成できます。[43]
Plan 9のユニオンディレクトリアーキテクチャは、 4.4BSDとLinuxの ユニオンファイルシステム実装に影響を与えたが[45]、 BSDユニオンマウント機能の開発者は、Plan 9のディレクトリの非再帰的なマージが「一般的な用途には制限が多すぎる」と感じた。[46]
特別な仮想ファイルシステム
/proc
.png/500px-Plan_9_from_Bell_Labs_(process_management).png)
Plan 9では、プロセス管理専用のシステムコールの代わりに、 /procファイルシステムを提供しています。各プロセスは、通常のファイルIOシステムコールで操作できる情報ファイルと制御ファイルを含むディレクトリとして表示されます。[8]
ファイルシステムアプローチでは、Plan 9のプロセスをlsやcatなどの簡単なファイル管理ツールで管理できますが、プロセスをファイルとしてコピーしたり移動したりすることはできません。[8]
/ネット
Plan 9 には、ネットワーク スタックやネットワーク ハードウェアにアクセスするための特別なシステム コールやioctl はありません。代わりに、 / netファイル システムが使用されています。ネットワーク接続は、制御ファイルへの制御メッセージの読み取りと書き込みによって制御されます。/net/tcpや/net/udpなどのサブディレクトリは、それぞれのプロトコルへのインターフェイスとして使用されます。[8]
ユニコード
文字エンコーディングの管理の複雑さを軽減するため、Plan 9ではシステム全体でUnicode を使用しています。最初の Unicode 実装はISO/IEC 10646-1:1993でした。Ken Thompson が発明した UTF-8 は Plan 9 のネイティブエンコーディングになりました。システム全体が 1992 年に一般使用に移行しました。[49] UTF-8 は従来のヌル終端文字列との下位互換性を維持しており、より信頼性の高い情報処理と、複数のプロセス間でUnix パイプを使用して多言語文字列データを連鎖させることができます。すべての文化と地域の文字で単一の UTF-8 エンコーディングを使用すると、コードセットを切り替える必要がなくなります。[50]
デザインコンセプトを組み合わせる
Plan 9 の設計コンセプトは、それ自体でも興味深いものですが、組み合わせることで最も有用になるはずでした。たとえば、ネットワーク アドレス変換(NAT) サーバーを実装するには、ルーターの/netディレクトリ ツリーを独自の/netでオーバーレイして、ユニオン ディレクトリを作成できます。同様に、パブリックインターネット上のセキュリティ保護された 9P を使用して、リモートゲートウェイからの/ net階層をユニオン ディレクトリにオーバーレイすることで、仮想プライベート ネットワーク (VPN) を実装できます。/net 階層とフィルターを含むユニオン ディレクトリは、信頼できないアプリケーションをサンドボックス化したり、ファイアウォールを実装したりするために使用できます。[43]同様に、分散コンピューティング ネットワークは、リモート ホストからの/proc階層のユニオン ディレクトリで構成でき、これにより、ローカルであるかのように対話できます。
これらの機能を組み合わせて使用すると、既存の階層型名前システムを再利用して複雑な分散コンピューティング環境を構築することができます。[8]
Plan 9 用ソフトウェア
システム設計の利点として、Plan 9 のほとんどのタスクは、 ls、cat、grep、cp、rmユーティリティをrc シェル(デフォルトの Plan 9 シェル) と組み合わせて使用することで実行できます。
FactotumはPlan9の認証および鍵管理サーバーです。他のプログラムに代わって認証を処理するため、秘密鍵と実装の詳細はFactotumのみが知っていればよいことになります。[51]
グラフィカルプログラム
.png/500px-Plan_9_from_Bell_Labs_(with_acme).png)
Unixとは異なり、Plan 9はグラフィックスを念頭に置いて設計されました。[44]起動後、Plan 9ターミナルはrioウィンドウシステムを実行し、ユーザーはrcを表示する新しいウィンドウを作成できます。[52]このシェルから呼び出されたグラフィカルプログラムは、そのウィンドウでシェルを置き換えます。
プランバーは、システム全体のハイパーリンクを可能にするプロセス間通信メカニズムを提供します。
SamとacmeはPlan 9のテキストエディタです。[53]
ストレージシステム
Plan 9 は、Kfs、Paq、Cwfs、FAT、Fossilファイル システムをサポートしています。最後の Fossil は、Bell Labs で Plan 9 専用に設計され、スナップショット ストレージ機能を提供します。ハード ドライブで直接使用することも、アーカイブ ファイル システムおよび永続的なデータ ストレージ システムであるVentiでバックアップすることもできます。
ソフトウェア開発
Plan 9 の配布パッケージには、特別なコンパイラ バリアントとプログラミング言語が含まれており、Plan 9 に固有のウィンドウユーザー インターフェイスシステムとともに、カスタマイズされたライブラリ セットが提供されます。 [54]システムの大部分は C 方言 (一部の拡張機能と他の機能が省略されたANSI C ) で記述されています。この言語のコンパイラは移植性を考慮してカスタム構築されており、その作者によると、「コンパイルは高速で、読み込みは遅く、中程度の品質のオブジェクト コードを生成します」。[55]
Alefと呼ばれる並行プログラミング言語は最初の2つのエディションで利用可能でしたが、メンテナンス上の理由から廃止され、Cのスレッドライブラリに置き換えられました。 [56] [57]
Unix 互換性
Plan 9はUnixのコンセプトをさらに発展させたものになるはずだったが、既存のUnixソフトウェアとの互換性はプロジェクトの目標ではなかった。Plan 9の多くのコマンドラインユーティリティはUnixのものと名前が同じだが、動作は異なる。[48]
Plan 9 はPOSIXアプリケーションをサポートし、 ANSI CおよびPOSIXに近いインターフェイスを実装するANSI/POSIX 環境(APE)を介してBerkeley ソケット インターフェイスをエミュレートできます(ネイティブ Plan 9 C インターフェイスはどちらの標準にも準拠していません)。また、POSIX 互換シェルも含まれています。APE の作者は、X Window System (X11) を Plan 9 に移植するために APE を使用したと主張していますが、X11 は「適切にサポートするのは大仕事すぎる」ため出荷していません。[58]一部の Linux バイナリは、「linuxemu」(Linux エミュレータ) アプリケーションの助けを借りて使用できますが、まだ開発中です。[59]逆に、Vx32仮想マシンでは、わずかに変更された Plan 9 カーネルを Linux のユーザー プロセスとして実行でき、変更されていない Plan 9 プログラムをサポートします。[60]
受付
現代のオペレーティングシステムとの比較
1991年、Plan 9の設計者は、そのシステムを90年代初期の他のオペレーティングシステムとサイズの面で比較し、最小限の（「動作するが、あまり役に立たない」）バージョンのソースコードは、デバイスドライバのないMach マイクロカーネルの5分の1以下であることを示した（Plan 9のコードは、測定基準に応じて5899行または4622行、Plan 9は25530行）。完全なカーネルは18000行のコードで構成されていた。 [39] （2006年の計算によると、当時のカーネルは約15万行だったが、これはLinuxの480万行以上と比較されたものである。[43]）
オペレーティングシステム研究コミュニティ内、および商用 Unix の世界では、分散コンピューティングとリモートファイルシステムアクセスを実現する他の試みが Plan 9 の設計作業と並行して行われました。これには、Sun Microsystemsで開発されたネットワークファイルシステムと関連するvnodeアーキテクチャ、および Unix モデルからのより急進的な逸脱であるUC BerkeleyのSprite OSが含まれます。Sprite 開発者の Brent Welch は、SunOS vnode アーキテクチャは Plan 9 の機能と比較して制限があり、リモートデバイスアクセスとリモートプロセス間通信をきれいにサポートしていないと指摘しています。ただし、既存のUNIX ドメインソケット(「基本的にユーザーレベルのサーバーに名前を付けるために使用できます」) が vnode アーキテクチャに統合されていれば、サポートできたはずです。[41]
Plan 9 の「すべてがファイル」というテキスト メッセージによる通信設計に対する批判の 1 つは、Sun のオブジェクト指向オペレーティング システムである Spring の型付きインターフェイスと比較したこのパラダイムの限界を指摘しました。
Plan 9 では、すべてがファイルに見えるように制限されています。ほとんどの場合、実際のインターフェース タイプは、ファイル ディスクリプタに書き込まれ、ファイル ディスクリプタから読み取られるメッセージのプロトコルで構成されます。これは指定およびドキュメント化が難しく、実行時のファイル エラーを除いて、自動タイプ チェックがまったく行われません。(...) [A] プロセスの暗黙のルート コンテキストに相対的なパス名は、サービスに名前を付ける唯一の方法です。オブジェクトに名前をバインドするには、新しい名前と同じコンテキストで、オブジェクトの既存の名前を指定する必要があります。そのため、インターフェース参照はプロセス間で渡すことはできず、ネットワーク間で渡すことはなおさらできません。代わりに、通信は規則に頼らなければなりませんが、これはエラーが発生しやすく、拡張性がありません。
— ロスコー、強調は原文のまま。[61]
その後、Plan 9、Sprite、そして3番目の同時代の分散研究用オペレーティングシステムであるAmoebaを遡及的に比較したところ、
それら [Amoeba と Sprite] が構築する環境は OS 内で密に結合されているため、外部サービスとの通信が困難です。このようなシステムは UNIX モデルからの根本的な逸脱に悩まされており、既存のソフトウェアをプラットフォームに移植することも困難です (...)。開発者の不足、サポートされるハードウェアの範囲が非常に狭いこと、Plan 9 と比べてもユーザー ベースが小さいことも、これらのシステムの採用を著しく遅らせています (...)。振り返ってみると、Plan 9 は、開発者を引き付け、今日まで存続するのに十分な期間、商用プロジェクトで使用された当時の唯一の研究用分散 OS でした。
— ミルチョフスキー、シモンズ、ミンニッヒ[62]
インパクト
Plan 9 は、Unix の不可欠な概念、つまりすべてのシステム インターフェイスをファイルのセットとして表現できるという概念が、現代の分散システムにうまく実装できることを実証しました。[52] Unicode の UTF-8 文字エンコーディングなど、Plan 9 の一部の機能は、他のオペレーティング システムで実装されています。Linux などの Unix 系オペレーティング システムは、Plan 9 のリモート ファイル アクセス プロトコルである 9P2000 を実装し、Plan 9 のプロセス作成メカニズムであるrforkの機能を採用しています。 [64]さらに、Plan 9 from User Spaceでは、sam エディターや acme エディターなど、Plan 9 のアプリケーションとツールのいくつかが Unix および Linux システムに移植され、ある程度の人気を獲得しています。いくつかのプロジェクトでは、 Linux カーネル周辺のGNUオペレーティング システム プログラムを Plan 9 オペレーティング システム プログラムに置き換えようとしています。[65] [66] 9wmウィンドウ マネージャーは、Plan 9 の古いウィンドウ システムである8½に触発されました。 [67] wmiiもPlan 9の影響を強く受けています。[63]コンピュータサイエンスの研究では、Plan 9はグリッドコンピューティングプラットフォーム として使用され、 [68] [62]ミドルウェアなしのユビキタスコンピューティングの研究手段としても使用されています。[69]商用では、Plan 9はCoraidストレージシステムの 基盤となっています。しかし、Plan 9の人気はUnixに匹敵することはなく、主に研究ツールとして使用されてきました。
Plan 9 が失敗したのは、単に Unix の改良点としてその先祖に取って代わるほどの説得力に欠けていたためだと思われます。Plan 9 と比較すると、Unix はきしんだりガタガタしたり、明らかに錆びたりしていますが、その地位を維持するのに十分な仕事をこなしています。野心的なシステム設計者にとって、ここには教訓があります。より良いソリューションの最も危険な敵は、そこそこ良い既存のコードベースです。
— エリック・S・レイモンド[17]
Plan 9の採用が低かった他の要因としては、商用バックアップの不足、エンドユーザーアプリケーションの数の少なさ、デバイスドライバーの不足などが挙げられます。[52] [53]
Plan 9の支持者と開発者は、その採用を妨げていた問題が解決され、分散システム、開発環境、研究プラットフォームとしての当初の目標は達成され、人気は中程度だが高まっていると主張している。[要出典] Infernoは、そのホスト機能を通じて、異機種コンピューティンググリッドのホスト部分としてPlan 9の技術を他のシステムに導入するための手段となっている。[70] [71] [72]
9atomや9frontなど、いくつかのプロジェクトがPlan 9の拡張に取り組んでいます。これらのフォークは、Upas電子メールシステムの改良版、Goコンパイラ、Mercurialバージョン管理システムのサポート（現在はgit実装も）、およびその他のプログラムを含む追加のハードウェアドライバーとソフトウェアでPlan 9を拡張します。 [19] [73] Plan 9はRaspberry Piシングルボードコンピューターに移植されました。 [74] [75] Harveyプロジェクトは、 GitHubやCoverityなどの最新の開発ツールを活用して開発をスピードアップするために、カスタムPlan 9 CコンパイラをGCCに置き換えようとしています。[76]
Windows 10バージョン1903以降、Windows Subsystem for LinuxはPlan 9 Filesystem Protocolをサーバーとして実装し、ホストWindowsオペレーティングシステムはクライアントとして機能します。[77]
派生商品とフォーク
- Inferno はPlan 9 の後継であり、特にデバイスと Styx/9P2000 プロトコルに関する多くの設計概念やカーネルのソース コードを共有しています。Inferno は、ベル研究所の Unix の伝統とUnix 哲学をPlan 9 と共有しています。Inferno のコマンド ライン ツールの多くは、Limboに翻訳された Plan 9 ツールでした。
- 9atom [78]は、386 PAEカーネル、amd64 CPUおよびターミナルカーネル、nupas、追加のPCハードウェアサポート、IL、Kenのfsを追加してPlan 9ディストリビューションを強化します。 [79] [80]
- 9front [81]はPlan 9のフォークです。ベル研究所内の専用開発リソースの不足を補うために開始され、さまざまな修正と改善が積み重ねられてきました。
- 9legacy [82]は代替ディストリビューションであり、現在のPlan 9ディストリビューションに基づいたパッチのセットが含まれています。
- Akaros [83]は、多数のコアを持つアーキテクチャと大規模なSMPシステム向けに設計されています。
- Harvey OS [84]は、Plan 9のコードをgccとclangで動作させるための取り組みです。
- JehanneOS [85]はPlan9から派生した実験的なOSである。そのユーザーランドとモジュールは主に9frontから派生し、ビルドシステムはHarvey OSから派生しており、カーネルはPlan9-9k 64ビットPlan9カーネルのフォークである。
- NIX [86] [より良い情報源が必要]は、マルチコアシステムとクラウドコンピューティングを目的とした Plan9 のフォークです。
- node9 [87]は Plan9/Inferno のスクリプト化された派生版で、Limboプログラミング言語と DIS 仮想マシンをLua言語と LuaJit 仮想マシンに置き換えたものです。また、一貫性のあるクロスプラットフォーム ホスティングを実現するために、Inferno のプラットフォームごとにホストされる I/O を Node.js の libuv イベントと I/O に置き換えています。これは、分散 OS をプロセスごとの名前空間と汎用クラウド要素から構築して、任意のサイズの単一システム イメージを構築できることを示す概念実証です。
- Plan B [88]は、利用可能なリソースのセットが時間によって異なる分散環境で動作するように設計されました。もともと Plan 9 カーネルの第 3 版に基づいていましたが、Plan B は現在の Plan 9 システムで実行できるようにユーザー空間に移動されました。[89] [90] [91]
ライセンス
2002年4月の第4版のリリース以降、[26]ベル研究所のPlan 9の完全なソースコードは、Lucent Public License 1.02の下で無料で入手可能となっている。これは、 Open Source Initiative (OSI)によってオープンソースライセンスとみなされ、 Free Software Foundationによってフリーソフトウェアライセンスとされ、Debianフリーソフトウェアガイドラインにも準拠している。[43]
2014年2月、カリフォルニア大学バークレー校は、現在のPlan 9の著作権保有者であるアルカテル・ルーセントから、これまでLucent Public Licenseバージョン1.02で管理されていたすべてのPlan 9ソフトウェアをGPL-2.0のみでリリースすることを許可されました。[92]
2021年3月23日、Plan 9の所有権はベル研究所からPlan 9財団に移管され、[93]以前のリリースはすべてMITライセンスに再ライセンスされました。[10]
参照
.svg/500px-Free_and_open-source_software_logo_(2009).svg.png){kind=logo}
参考文献
- ^ 「ベル研究所のプラン9」。
- ^ ルーセントテクノロジーズ(2006). 「Glenda, the Plan 9 Bunny」2008年12月2日閲覧。
- ^ 「Plan 9 Foundation: 活動」. plan9foundation.org . 2021年3月23日閲覧。
- ^ “9legacy”. 9legacy.org . 2021年3月23日閲覧。
- ^ "plan9checksums". Bell Labs. 2017-06-01 にオリジナルからアーカイブ。2019-07-25に取得。2015
年 1 月 10 日土曜日 04:04:55 EST ... plan9.iso.bz2
- ^ 「GPLv2 ソースコード」。
- ^ Crawford, Diane (1999). 「フォーラム」. Communications of the ACM . 42 (8). Association for Computing Machinery (ACM): 11–15. doi :10.1145/310930.310939. ISSN 0001-0782. S2CID 263897745.
- ^ abcde Pike, R. ; Presotto, D.; Dorward, S.; Flandrena, B.; Thompson, K. ; Trickey, H.; Winterbottom, P. 「ベル研究所のプラン9」。ベル研究所。ルーセントテクノロジーズ。 2016年2月26日閲覧。
- ^ “Plan 9 License”. p9f.org . 2021年6月14日時点のオリジナルよりアーカイブ。2021年6月14日閲覧。
- ^ abc Sorace, Anthony. 「Plan 9のPlan 9財団への譲渡」. marc.info . 2021年4月13日時点のオリジナルよりアーカイブ。 2020年4月14日閲覧。
- ^ “Plan9License”. akaros.cs.berkeley.edu . 2014年2月13日時点のオリジナルよりアーカイブ。2021年6月14日閲覧。
カリフォルニア大学バークレー校は、アルカテル・ルーセント社から、これまでルーセント・パブリック・ライセンス・バージョン1.02によって管理されていたすべてのPlan 9ソフトウェアをGNU一般公衆利用許諾書バージョン2の下で公開することを許可されました。
- ^ 「Lucent Public License Version 1.02」。plan9.bell-labs.com。2003年10月3日時点のオリジナルよりアーカイブ。2021年6月14日閲覧。
- ^ 「Plan 9 Open Source License - バージョン 1.4 - 09/10/02」. plan9.bell-labs.com . 2002年12月18日時点のオリジナルよりアーカイブ。2021年6月14日閲覧。
- ^ 「Plan 9 Open Source License - バージョン 1.2 - 10/29/00」. plan9.bell-labs.com . 2000年12月6日時点のオリジナルよりアーカイブ。2021年6月14日閲覧。
- ^ 「Plan 9 Open Source License - Version 1.1 - 09/20/00」. plan9.bell-labs.com . 2000年10月26日時点のオリジナルよりアーカイブ。2021年6月14日閲覧。
- ^ 「Plan 9 オープンソースライセンス契約」。plan9.bell-labs.com。2000年8月16日時点のオリジナルよりアーカイブ。2021年6月14日閲覧。
- ^ abc Raymond, Eric S. (2003-09-17). 「Plan 9: The Way the Future Was」. The Art of UNIX Programming . Addison-Wesley . ISBN 0-13-142901-9. 2007年5月7日閲覧。
- ^ Robertson, James (2011-07-16). 「Plan 9 がフォークされ、9front として継続」. OSNews . 2011-12-31閲覧。
- ^ abc "9atom". 2013年7月26日時点のオリジナルよりアーカイブ。2011年11月11日閲覧。
- ^ 「UNIX システムの発明者から、ベル研究所の Plan 9 が登場」(プレス リリース)。Lucent Technologies。1995 年 7 月 18 日。2006 年 2 月 9 日時点のオリジナルよりアーカイブ。
- ^ McIlroy, Doug (1995 年 3 月). 「序文」. Bell Labs (第 2 版). Lucent Technologies . 2016 年 2 月 26 日閲覧。
- ^ Proven, Liam (2022-03-29). 「非Cオペレーティングシステムの奇妙な世界」www.theregister.com . 2022年9月1日閲覧。
- ^ Lee, Yvonne L. (1995 年 7 月 24 日). 「AT&T Bell Labs が組み込みシステム向け Plan 9 OS を出荷」. InfoWorld .
- ^ Pontin, Jason (1996 年 2 月 19 日)。「AT&T が Java 競合の計画を発表」InfoWorld、3 ページ。
- ^ ab 「ベル研究所：完全ガイド — 歴史、製品、設立など」History-Computer 2021-11-14 . 2022-09-01閲覧。
- ^ abc Loli-Queru, Eugenia (2002-04-29). 「Bell Labs が Plan 9 の新バージョンをリリース」. OSNews . 2011-12-31閲覧。
- ^ 「貢献方法」。ベル研究所。ルーセントテクノロジーズ。2011年11月30日閲覧。
- ^ 「Staying up to date」.ベル研究所. ルーセントテクノロジーズ. 2019年7月24日閲覧。
- ^ 「Plan 9 — 追加ソフトウェア」 2009年. 2016年3月6日閲覧。
- ^ Weldon, Marcus (2021年3月23日). 「ベル研究所のサイバースペースにおけるプラン9！」Nokia Bell Labs . 2021年3月23日閲覧。
- ^ シャーウッド、サイモン。「ベル研究所が影響力のある『プラン9』OSの著作権を新財団に譲渡」。The Register 。 2021年3月24日閲覧。
- ^ 「FQA 1 - 9front の紹介」fqa.9front.org . 2018年2月15日閲覧。
- ^ Proven, Liam. 「Plan 9フォーク9frontの新バージョンがリリースされました」。The Register。2022年11月5日閲覧。
- ^ 「Harvey OS」. harvey-os.org . 2018年2月15日閲覧。
- ^ 「ジャンヌ」. jehanne.h--k.it/ 。2023-01-08に取得。
- ^ 「一般向け初公開のお知らせ」。9人のファン。1995年7月16日。2008年7月6日時点のオリジナルよりアーカイブ。
- ^ ab Mullender, Sape J.; Jansen, Pierre G. (2004-02-26). 「Real Time in a Real Operating System」. Herbert, Andrew J.; Spärck Jones, Karen (編)。「コンピュータ システム: 理論、テクノロジ、アプリケーション: Roger Needham へのトリビュート」 . Springer Science+Business Media . p. 211. ISBN 978-0-387-20170-2. 2011年12月24日閲覧。
- ^ Hancock, Brian (2003). 「Unix の再発明: Plan 9 オペレーティング システムの紹介」Library Hi Tech . 21 (4). MCB UP: 471–76. doi :10.1108/07378830310509772.
- ^ abcde Presotto, Dave; Pike, Rob ; Thompson, Ken ; Trickey, Howard. Plan 9、分散システム。Proc. Spring 1991 EurOpen Conference。CiteSeerX 10.1.1.41.9192。
- ^ abc Pike, R. ; Presotto, D.; Thompson, K. ; Trickey, H.; Winterbottom, P. 「Plan 9 での名前空間の使用」。ベル研究所。2016 年 2 月 26 日閲覧。
- ^ ab Welch, Brent (1994). 「3つの分散ファイルシステムアーキテクチャの比較: Vnode、Sprite、Plan 9」.コンピューティングシステム. 7 (2): 175–199. CiteSeerX 10.1.1.46.2817 .
- ^ – Plan 9 プログラマーズマニュアル、第 1 巻
- ^ abcdef Pereira, Uriel M. (2006). The Unix Spirit set Free: Plan 9 from Bell Labs ( AVI ) . FOSDEM . 2011-12-02閲覧。
- Uriel. 「Unix スピリットの解放: Bell Labs の Plan 9」(PDF)。Bell Labs 。 2007-11-28 にオリジナル(PDF)からアーカイブ。2007-11-14に取得。
- ^ ab Minnich, Ron (2005). 「なぜ Plan 9 はまだ終わっていないのか、そしてそこから何を学べるのか」(PDF)。ロスアラモス国立研究所。2016年 2 月 25 日のオリジナル(PDF)からアーカイブ。2016年 2 月 26 日閲覧。
- ^ ab Valerie, Aurora (2009-03-25). 「Union ファイル システム: 実装、パート I」. LWN.net . 2011-12-05に閲覧。
- ^ ab Pendry, Jan-Simon; McKusick, Marshall Kirk (1995). Union Mounts in 4.4BSD-Lite. Proc. Winter USENIX Conf.
- ^ ダフ、トム。「18」。Rc — プラン9シェル。
{{cite book}}:|work=無視されました (ヘルプ) (PDF); - ^ ab 「UNIX から Plan 9 へのコマンド変換」。ベル研究所。ルーセント テクノロジーズ。2011 年 12 月 2 日閲覧。
- ^ Pike, Rob (2003-04-30). 「UTF-8 の歴史」 . 2006-04-27閲覧。
- ^ ケン、ルンデ (1999 年 1 月)。CJKV 情報処理。オライリーメディア。 p. 466.ISBN 978-1-56592-224-2. 2011年12月23日閲覧。
- ^ Cox, R.; Grosse, E.; Pike, R .; Presotto, D.; Quinlan, S. 「Plan 9 のセキュリティ」。ベル研究所。ルーセント テクノロジーズ。2016年 2 月 26 日閲覧。
- ^ abc Hudson, Andrew (2006-07-19). 「Plan 9 オペレーティング システムの調査」. OSNews . 2011-12-31閲覧。
- ^ ab 「ラス・コックスとのインタビュー」。The Setup。これを使用します。2011-04-09。2011-12-28にオリジナルからアーカイブ。2012-01-01に取得。
- ^ ディクソン、ロッド (2004)。オープンソースソフトウェア法。Artech House。p . 213。ISBN 978-1-58053-719-3. 2011年12月25日閲覧。
- ^ Thompson, Ken (1992 年 2 月). 「新しい C コンパイラ」(PDF) .オーストラリア UNIX システム ユーザー グループ ニュースレター. 13 (1). Kensington , AU : AUUG : 31–41. ISSN 1035-7521 . 2011 年 12 月 25 日閲覧。
- ^ Pike, Rob. 「Rio: 並行ウィンドウシステムの設計」(PDF) 。2013 年3 月 8 日閲覧。
- ^ – Plan 9 プログラマーズマニュアル、第 1 巻
- ^ Trickey, Howard. 「APE – ANSI/POSIX 環境」。ベル研究所。ルーセント テクノロジーズ。2016年 2 月 26 日閲覧。
- ^ 「Linux エミュレーション」。ベル研究所。ルーセントテクノロジーズ。2016年 2 月 26 日閲覧。
- ^ Ford, Bryan; Cox, Russ (2008). Vx32: x86 上の軽量なユーザーレベルサンドボックス。USENIX Annual Tech. Conf. pp. 293–306. CiteSeerX 10.1.1.212.9353。
- ^ Roscoe, Timothy (1995). マルチサービスオペレーティングシステムの構造(PDF) (Ph.D.). ケンブリッジ大学. pp. 22–23.
- ^ ab Mirtchovski, Andrey; Simmonds, Rob; Minnich, Ron (2004). Plan 9—グリッドコンピューティングへの統合アプローチ。Proc. 18th Int'l Parallel and Distributed Processing Symp. IEEE. CiteSeerX 10.1.1.97.122 .
- ^ ab "window manager improved 2". suckless.org . 2011-12-31 にオリジナルからアーカイブ。2012-01-02に取得。
[wmii] は 9p ファイルシステム インターフェースを持ち、クラシックおよびタイル (acme のような) ウィンドウ管理をサポートします。
- ^ Torvalds, Linus (1999)。「Linux のエッジ」。オープン ソース:オープン ソース革命からの声。O'Reilly。ISBN 1-56592-582-3。
- ^ 「Glendix: Plan 9 の美しさを Linux にもたらす」2011 年 12 月 1 日閲覧。
- ^ 「Plan 9 From Gentoo: Plan 9 Meets Gentoo」Gentoo Linux。 2012 年 12 月 20 日時点のオリジナルよりアーカイブ。2011 年 12 月 1 日閲覧。
- ^ 「9wm ウィンドウ マネージャー」。9wm。2012年 1 月 2 日取得
。9wm は、X によって課せられた制約の範囲内で、可能な限り Plan 9 ウィンドウ マネージャー 8-1/2 をエミュレートしようとする X ウィンドウ マネージャーです
。 - ^ "9grid". Bell Labs . Lucent Technologies . 2006-03-14時点のオリジナルよりアーカイブ。2006-03-28閲覧。
- ^ Ballesteros, Francisco J.; Guardiola, Gorka; Soriano, Enrique; Leal Algara, Katia (2005).従来のシステムは、パーベイシブ アプリケーションでも問題なく機能します。ケース スタディ: Bell Labs の Plan 9 が普及。IEEE Intl' Conf. on Pervasive Computing and Communications。CiteSeerX 10.1.1.109.8131。
- ^ “Vita Nuova が Evotec OAI に Inferno Grid を供給” (PDF) (プレスリリース)。ヴィータ・ヌオーヴァ。 2004-05-18 。2006 年 3 月 28 日に取得。
- ^ 「ラトガース大学図書館が Inferno Data Grid を導入」(PDF) (プレス リリース)。Vita Nuova。2004年 5 月 12 日。2006年 3 月 28 日閲覧。
- ^ 「ヨーク大学生物学部が Vita Nuova の Inferno Data Grid を導入」(PDF) (プレス リリース)。Vita Nuova。2004年 5 月 4 日。2006年 3 月 28 日閲覧。
- ^ 「9FRONT.ORG 計画は失敗に終わった」。2021年10月14日閲覧。
- ^ Hayward, David (2013-05-09). 「Raspberry Pi オペレーティングシステム: 5 つのレビューと評価」TechRadar。 2013 年 6 月 7 日時点のオリジナルよりアーカイブ。 2014 年 4 月 20 日閲覧。
- ^ 「Raspberry Pi に Plan 9 をインストールする方法」 eLinux . 2014 年 11 月 16日閲覧。
- ^ フラド、アルバロ;フェルナンデス、ラファエル。デュ・コロンビエ、デイヴィッド。ミニッチ、ロン。ニリネン、アキ。フローレン、ジョン。ハーベイ(PDF)。 USENIX ATC BOF セッション。
- ^ 「Windows 10 バージョン 1903 の WSL の新機能」。開発者向け Windows コマンド ライン ツール。2019 年 2 月 16 日。
- ^ “9atom”. 2020年11月11日時点のオリジナルよりアーカイブ。
{{cite web}}: CS1 メンテナンス: 不適切 URL (リンク) - ^ “9atom”. quanstro.net . 2018年6月9日時点のオリジナルよりアーカイブ。2023年6月15日閲覧。
- ^ “9atom”. ArchiveOS . 2022年5月3日. 2023年6月15日閲覧。
- ^ 「9FRONT.ORG 計画は失敗に終わった」9front.org。
- ^ "9legacy". www.9legacy.org .
- ^ 「Akaros」. akaros.org .
- ^ 「Harvey OS」. harvey-os.org .
- ^ “JehanneOS”. 2021年11月17日。
- ^ 「NIX」. 2020年11月21日.
- ^ “node9”. GitHub . 2022年1月14日.
- ^ 「プランB」。2020年11月26日。
- ^ 「ダウンロード」。Plan 9 wiki . 9p.io . 2023年6月15日閲覧。
- ^ バレステロス、フランシスコ J.ムクイズ、ゴルカ・グアルディオラ。アルガラ、カティア・レアル。ソリアーノ、エンリケ。デ・ラス・ヘラス・キロス、ペドロ。カストロ、エヴァ M.レオナルド、アンドレス。セルジオ、アレバロ（2004年2月）。 「プラン B: ネットワーク化されたリソース用のボックス」。ブラジルコンピュータ協会のジャーナル。10 (1): 33-44。土井：10.1007/BF03192352。S2CID 6766935。
- ^ Ballesteros, FJ; Soriano, E.; Leal, K.; Guardiola, G. (2006). 「Plan B: ユビキタス コンピューティング環境向けオペレーティング システム」第 4 回 IEEE 国際パーベイシブ コンピューティングおよび通信会議 (PERCOM'06) pp. 126–135. doi :10.1109/PERCOM.2006.43. ISBN 0-7695-2518-0. S2CID 1730651 . 2023年6月15日閲覧。
- ^ Sharwood, Simon (2014-02-14). 「Plan 9 が Lucent ライセンス領域から撤退」TheRegister . 2014-04-20閲覧。
- ^ 「Plan9 Foundation」. plan9foundation.org . 2021年10月13日閲覧。
外部リンク
ウィキメディア・コモンズには、ベル研究所のプラン9に関連するメディアがあります。
- 9p.io: plan9.bell-labs.com にあるオリジナルの公式 Plan 9 Web サイトのアーカイブミラー。2021-05-24 にWayback Machineにアーカイブされました。
- 9fans: Plan 9 ユーザーと開発者向けの半公式メーリング リスト
- プラン9財団