ベル研究所のプラン9

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

ベル研究所のプラン9
ベルblack.jpgからの計画9のグレンダバニーマスコット
ルネ・フレンチが描いたプラン9のマスコット、グレンダ[1]
プラン9第4版rioインタラクションscreenshot.png
rio、BellLabsのPlan9のデフォルトのユーザーインターフェイス
デベロッパーPlan 9 Foundation、ベル研究所の後継
で書かれているANSICの方言
動作状態現在[2] [3]
ソースモデルオープンソース
初回リリース1992 ; 30年前(大学)/  (1992 1995 ; 27年前(一般市民) (1995
最終リリース第4版/ 2015年1月10日; 7年前[4] (2015-01-10
リポジトリ9p .io / sources / plan9 / sys / src / [5]
マーケティングターゲットオペレーティングシステムの研究、ネットワーク環境、汎用用途
で利用可能英語
プラットフォームx86 / Vx32x86-64MIPSDEC AlphaSPARCPowerPCARM
カーネルタイプモノリシック[6]
に影響を受けたリサーチUnixケンブリッジ分散コンピューティングシステム[7]
デフォルトの
ユーザーインターフェイス
リオ/ rc
ライセンス2021:MIT [8] [9]
2014:GPL-2.0のみ[10]
2002:LPL-1.02 [11]
2000:プラン9 OSL [12] [13] [14] [15]
成功インフェルノ
その他の派生物とフォーク
公式ウェブサイトp9f .org

BellLabsのPlan9は、分散オペレーティングシステムであり、1980年代半ばにBellLabsのComputingScience Research Center(CSRC)で作成され、1960年代後半に最初にそこで開発されたUNIXの概念に基づいています。2000年以降、Plan9は無料でオープンソースです。最終的な公式リリースは2015年初頭でした。

Plan 9では、UNIXのすべてがファイルメタファーであり、広範なネットワーク中心のファイルシステムを介して拡張され、 UNIXのようなオペレーティングシステムの中心にあるカーソルアドレス端末ベースのI / Oが、ウィンドウシステムグラフィカルユーザーに置き換えられています。 Plan 9シェルであるrcはテキストベースですが 、カーソルアドレス指定のないインターフェイス。

BellLabsのPlan9という名前は、 OuterSpaceのEdWood1959カルトSFZ 映画 Plan9 参照しています。[16](プロジェクトのマスコット、「Glenda、the Plan 9 Bunny」の名前は、おそらくWoodの映画GlenまたはGlendaを指しています。)このシステムは、オペレーティングシステムの研究者や愛好家によって引き続き使用および開発されています。[17] [18]

歴史

Plan9インストールのスクリーンショット

BellLabsのPlan9は、1980年代後半から[18] 、 UnixCプログラミング言語を最初に開発したのと同じグループであるBellLabsのコンピューティングサイエンス研究センターのメンバーによって最初に開発されました[19] Plan 9チームは当初、Rob PikeKen Thompson、Dave Presotto、Phil Winterbottomが主導し、コンピューティング技術研究部門の責任者であるDennisRitchieの支援を受けました。長年にわたり、Brian KernighanTom DuffDoug McIlroyBjarne Stroustrupなど、多くの著名な開発者がプロ​​ジェクトに貢献してきました。ブルースエリス[20]

Plan 9は、オペレーティングシステム研究のためのベル研究所の主要なプラットフォームとしてUnixに取って代わりました。特に分散マルチユーザー環境でのシステムの使用とプログラミングを容易にする、元のUnixモデルへのいくつかの変更について検討しました。数年間の開発と社内使用の後、ベル研究所は1992年にオペレーティングシステムを大学に出荷しました。3年後、プラン9は、書籍出版社のHarcourt Braceを介してAT&Tによって商業パーティーで利用できるようになりました。ソースライセンスの価格は350ドルで、AT&Tはコンピュータ市場全体ではなく組み込みシステム市場をターゲットにしていました。Ritchieは、他のオペレーティングシステムがどのように確立されたかを考えると、開発者は「大幅な置き換え」を行うことを期待していなかったとコメントしました。[21]

1996年の初めまでに、Plan 9プロジェクトは、 Sun MicrosystemsJavaプラットフォームのライバルとなることを目的として、 AT&TによってInfernoを支持して「後回しにされた」ものでした[22] 1990年代後半、ベル研究所の新しい所有者であるLucent Technologiesは、プロジェクトの商用サポートを終了し、2000年には、3番目のリリースがオープンソースライセンスの下で配布されました。新しいフリーソフトウェアライセンスの下での4番目のリリースは2002年に発生しました。[23]

現在および以前のベル研究所の担当者を含むユーザーおよび開発コミュニティは、ISOイメージの形式でマイナーな毎日のリリースを作成しましたベル研究所が開発を主催しました。[24]開発ソースツリーは9PおよびHTTPプロトコルを介してアクセス可能であり、既存のインストールを更新するために使用されます。[25] ISOに含まれるOSの公式コンポーネントに加えて、ベル研究所は外部で開発されたアプリケーションとツールのリポジトリもホストしています。[26]

ベル研究所が近年後のプロジェクトに移行したため、公式のPlan9システムの開発は中止されました2021年3月23日、ベル研究所からPlan 9 Foundationに著作権が譲渡された後、開発が再開されました。[9] [27] [28]システムの非公式な開発は、9frontフォークでも継続されており、アクティブな貢献者が毎月のビルドと新しい機能を提供しています。これまでのところ、9frontフォークは、システムWi-Fiドライバー、オーディオドライバー、USBサポート、組み込みのゲームエミュレーター、およびその他の機能を提供してきました。[29]他の最近のPlan9に着想を得たオペレーティングシステムには、Harvey OS [30]とJehanneOSが含まれます。[31]

日にち リリース コメント
1992 プラン9第1版 ベル研究所から大学にリリース
1995年 プラン9第2版 非営利目的でベル研究所からリリースされた[32]
2000 プラン9第3版 ブラジル オープンソースライセンスの下でLucentTechnologiesによってリリースされました
2002年 プラン9第4版 新しい無料ソフトウェアライセンスの下でLucentTechnologiesによってリリースされました

デザインコンセプト

BellLabsのPlan9は、クエーカー教徒のようなものです。「内なる光」へのストレスが特徴で、生活のシンプルさ、特にスピーチの明瞭さで知られています。クエーカー教徒のように、計画9は改宗しません。

—Sape J. Mullender、Pierre G. Jansen
リアルタイムオペレーティングシステムでのリアルタイム[33]

Plan 9は分散オペレーティングシステムであり、地理的に離れた異種のコンピュータのネットワークを単一のシステムとして機能させるように設計されています。[34]典型的なPlan9のインストールでは、ユーザーはウィンドウシステムrioを実行している端末で作業し、計算集約型のプロセスを処理するCPUサーバーにアクセスします。永続的なデータストレージは、ファイルサーバーおよびアーカイブストレージとして機能する追加のネットワークホストによって提供されます。[35]

その設計者は、次のように述べています。

システムの基盤は、プロセスごとの名前空間と単純なメッセージ指向のファイルシステムプロトコルという2つのアイデアに基づいて構築されています。

— パイク[36]

最初のアイデア(プロセスごとの名前空間)は、ほとんどのオペレーティングシステムとは異なり、プロセス(実行中のプログラム)はそれぞれ、他のオペレーティングシステムがファイルシステムと呼ぶものに対応する名前空間の独自のビューを持っていることを意味します。単一のパス名は、プロセスごとに異なるリソースを参照する場合があります。このセットアップの潜在的な複雑さは、共通リソースの従来の場所のセットによって制御されます。[37] [38]

2番目のアイデア(メッセージ指向のファイルシステム)は、プロセスが他のプロセスの名前空間に表示される仮想ファイルを提供することにより、他のプロセスにサービスを提供できることを意味します。このようなファイルに対するクライアントプロセスの入出力は、2つのプロセス間のプロセス間通信になります。このように、Plan 9は、コンピューティングリソースへのアクセスの中心点としてファイルシステムのUnixの概念を一般化します。Unixのデバイスファイルの考え方を引き継いで、周辺機器(マウス、リムーバブルメディアなど)へのアクセスとマウントの可能性を提供します物理的に異なるファイルシステム上にあるファイルシステムを階層的な名前空間に追加しますが、標準化されたプロトコルを話すサーバープログラムへの接続をマウントし、そのサービスを名前空間の一部として扱う可能性を追加します。

たとえば、8½と呼ばれる元のウィンドウシステムは、これらの可能性を次のように利用していました。Plan 9は、3つの疑似ファイルを使用して端末のユーザーインターフェイスを表します。マウスは、プログラムで読み取ってマウスの動きとボタンのクリックの通知を受け取ることができます。短所は、テキストの入出力を実行するために使用できます。bitblt、グラフィックス操作を実行する書き込み(bit blitを参照)。ウィンドウシステムはこれらのデバイスを多重化します。プログラムを実行するための新しいウィンドウを作成するとき、最初に、mouseconsbitbltが含まれる新しい名前空間を設定します。はそれ自体に接続されており、それ自体がアクセスできる実際のデバイスファイルを非表示にします。したがって、ウィンドウシステムは、プログラムからすべての入力コマンドと出力コマンドを受け取り、実際の画面デバイスに出力を送信し、現在フォーカスされているプログラムにキーボードとマウスの入力を与えることにより、これらを適切に処理します。[35]プログラムは、オペレーティングシステムのデバイスドライバと直接通信しているのか、ウィンドウシステムと通信しているのかを知る必要はありません。これらの特殊ファイルが一種の入力を提供し、期待する種類のメッセージを受け入れるように、名前空間が設定されていることを前提とするだけです。

Plan 9の分散操作は、プロセスごとの名前空間にも依存しているため、クライアントプロセスとサーバープロセスは、今概説した方法でマシン間で通信できます。たとえば、cpuコマンドは、計算サーバーでリモートセッションを開始します。このコマンドは、ユーザーの端末のデバイス( mouseconsbitblt )を含むローカル名前空間の一部をサーバーにエクスポートします。これにより、リモートプログラムは、端末のマウス、キーボード、およびディスプレイを使用して、リモートログインの効果を組み合わせて入出力を実行できます。および共有ネットワークファイルシステム。[35] [36]

9Pプロトコル

他のプログラムにファイルとしてのサービスを提供したいすべてのプログラムは、9Pと呼ばれる統一されたプロトコルを話します。他のシステムと比較して、これによりカスタムプログラミングインターフェイスの数が減ります。9Pは、サーバーとクライアント間で配信されるメッセージを提供する、一般的な、中程度に依存しない、バイト指向のプロトコルです。[39]プロトコルは、ユーザーインターフェイスとネットワークの両方を含む、プロセス、プログラム、およびデータを参照および通信するために使用されます。[40]第4版のリリースに伴い、9P2000に変更され、名前が変更されました。[23]

他のほとんどのオペレーティングシステムとは異なり、Plan 9は、デバイスにアクセスするための特別なアプリケーションプログラミングインターフェイスバークレーソケットXリソースioctlシステムコールなど)を提供していません。[39]代わりに、Plan 9デバイスドライバーは、制御インターフェイスをファイルシステムとして実装しているため、通常のファイル入出力操作の読み取りおよび書き込みによってハードウェアにアクセスできますしたがって、ネットワーク全体でデバイスを共有するには、対応するディレクトリツリーをターゲットマシンにマウントします。[16]

ユニオンディレクトリと名前空間

プラン9では、ユーザーは1つの場所にあるさまざまなディレクトリツリーからファイル(名前と呼ばれる)を収集できます。結果のユニオンディレクトリは、基になるディレクトリの連結として動作します(連結の順序を制御できます)。構成ディレクトリに同じ名前のファイルが含まれている場合、ユニオンディレクトリ(lsまたはlc)のリストは単に重複した名前を報告します。[41]単一パス名の解決はトップダウンで実行されます。ディレクトリtopbottomuに結合され、topが最初の場合、u / nametop / nameを示します。存在する場合、bottom / nameは存在し、top / nameが存在しない場合のみ、ファイルは存在しません。サブディレクトリの再帰的な結合は実行されないため、top / subdirが存在する場合、unionを介してbottom / subdir内のファイルにアクセスすることはできません。[42]

ユニオンディレクトリは、 bindコマンド を使用して作成できます。

; バインド/ arm / bin / bin
; bind -a / acme / bin / arm / bin
; bind -b / usr / alice / bin / bin

上記の例では、/ arm / binは/ binにマウントされ/ arm / binの内容が/ binの以前の内容を置き換えます。Acmebinディレクトリは/ binの後にユニオンマウントされ、Aliceの個人のbinディレクトリは前にユニオンマウントされます。ファイルが/ binから要求されると、最初に/ usr / alice / binで検索され、次に/ arm / binで検索され、最後に/ acme / bin / armで検索されます。

したがって、個別のプロセス名前空間は通常、シェル内の検索パスの概念を置き換えます。パス環境変数( )は、 rcシェル(主にPlan 9で使用されるシェル$path)にまだ存在します。ただし、rcのパス環境変数には従来はandディレクトリしか含まれておらず、変数を変更することはお勧めしません。代わりに、複数のディレクトリを1つにまとめてコマンドを追加する必要があります[43] [35] Plan 9とは異なり、Unixシェルのパス環境変数は、実行可能ファイルをコマンドとして追加する必要がある追加のディレクトリを含むように設定する必要があります。 /bin./bin

さらに、カーネルはプロセスごとに個別のマウントテーブルを保持できるため[33]、各プロセスに独自のファイルシステム名前空間を提供できます。プロセスの名前空間は独立して構築でき、ユーザーは異種の名前空間を持つプログラムと同時に作業できます。[36]名前空間は、 chrootに似た、より安全な方法で分離された環境を作成するために使用できます。[39]

Plan 9のユニオンディレクトリアーキテクチャは、 4.4BSDおよびLinux ユニオンファイルシステムの実装に影響を与えましたが[41]、BSDユニオンマウント機能の開発者は、プラン9のディレクトリの非再帰的なマージを「汎用使用には制限が大きすぎる」と感じました。[42]

特別な仮想ファイルシステム

/ proc

/ proc内のディレクトリ(ls、lc)コマンド[44]のリストコンテンツを使用したプロセスのリスト

Plan 9は、プロセス管理専用のシステムコールを使用する代わりに、 / procファイルシステムを提供します。プロセスは、通常のファイルIOシステムコールで操作できる情報と制御ファイルを含むディレクトリとして表示されます。[7]

ファイルシステムアプローチにより、Plan9プロセスをlscatなどの単純なファイル管理ツールで管理できます。ただし、プロセスをファイルとしてコピーおよび移動することはできません。[7]

/ net

Plan 9には、ネットワークスタックまたはネットワークハードウェアにアクセスするための特別なシステムコールやioctlはありません。代わりに、/ netファイルシステムが使用されます。ネットワーク接続は、制御ファイルへの制御メッセージの読み取りと書き込みによって制御されます。/ net / tcp/ net / udpなどのサブディレクトリは、それぞれのプロトコルへのインターフェイスとして使用されます。[7]

Unicode

文字エンコードの管理の複雑さを軽減するために、Plan9はシステム全体でUnicodeを使用します。最初のUnicode実装はISO / IEC 10646-1:1993でした。Ken ThompsonはUTF-8を発明し、これはPlan9でネイティブエンコーディングになりましたシステム全体が1992年に一般的な使用に変換されまし Unixパイプを使用した多言語文字列データのチェーン複数のプロセス間。すべてのカルチャおよびリージョンの文字を含む単一のUTF-8エンコーディングを使用すると、コードセットを切り替える必要がなくなります。[46]

デザインコンセプトの組み合わせ

プラン9の設計コンセプトは、それ自体は興味深いものですが、組み合わせると最も役立つはずでした。たとえば、ネットワークアドレス変換(NAT)サーバーを実装するために、ユニオンディレクトリを作成し、ルーター/ netディレクトリツリーを独自の/ netでオーバーレイすることができます。同様に、仮想プライベートネットワーク(VPN)は、パブリックインターネット上で保護された9Pを使用して、リモートゲートウェイから/ net階層をユニオンディレクトリにオーバーレイすることで実装できます。/ net階層とフィルターを備えたユニオンディレクトリを使用して、信頼できないアプリケーションをサンドボックス化したり、ファイアウォールを実装したりできます。[39]同様に、分散コンピューティングネットワークは、リモートホストからの/ proc階層のユニオンディレクトリで構成できます。これにより、リモートホストがローカルであるかのように対話できます。

これらの機能を一緒に使用すると、既存の階層型ネームシステムを再利用することで、複雑な分散コンピューティング環境を構築できます。[7]

プラン9のソフトウェア

システム設計の利点として、Plan 9のほとんどのタスクは、lscatgrepcp、およびrmユーティリティをrcシェル(デフォルトのPlan 9シェル)と組み合わせて使用​​することで実行できます。

Factotumは、プラン9の認証およびキー管理サーバーです。他のプログラムに代わって認証を処理し、秘密キーと実装の詳細の両方をFactotumだけが知る必要があるようにします。[47]

グラフィカルプログラム

acmeとrcを実行するプラン9

Unixとは異なり、Plan9はグラフィックスを念頭に置いて設計されました。[40]起動後、Plan 9ターミナルはrioウィンドウシステムを実行します。このシステムでは、ユーザーはrcを表示する新しいウィンドウを作成できます[48]このシェルから呼び出されたグラフィカルプログラムは、ウィンドウ内でそれを置き換えます。

配管工は、システム全体のハイパーリンクを可能にする プロセス間通信メカニズムを提供します。

サムアクメはプラン9のテキストエディタです。[49]

ストレージシステム

Plan 9は、Kfs、Paq、Cwfs、FAT、およびFossilファイルシステムをサポートします。最後のものは、ベル研究所でPlan 9専用に設計されており、スナップショットストレージ機能を提供します。ハードドライブで直接使用することも、Venti、アーカイブファイルシステム、永続的なデータストレージシステムでバックアップすることもできます。

ソフトウェア開発

Plan 9の配布パッケージには、特別なコンパイラバリアントとプログラミング言語が含まれており、 Plan 9に固有のウィンドウユーザーインターフェイスシステムとともに、カスタマイズされたライブラリのセットを提供します。 [50]システムの大部分はC( ANSI)の方言で書かれています。いくつかの拡張機能と他のいくつかの機能が省略されたC )。この言語のコンパイラは、移植性を念頭に置いてカスタムビルドされました。彼らの作者によると、彼らは「迅速にコンパイルし、ゆっくりとロードし、中品質のオブジェクトコードを生成する」とのことです。[51]

Alefと呼ばれる並行プログラミング言語は最初の2つのエディションで利用可能でしたが、メンテナンス上の理由で廃止され、C用のスレッドライブラリに置き換えられました。 [52] [53]

Unix互換性

Plan 9はUnixの概念をさらに発展させることになっていますが、既存のUnixソフトウェアとの互換性はプロジェクトの目標ではありませんでした。Plan 9の多くのコマンドラインユーティリティは、対応するUnixの名前を共有していますが、動作が異なります。[44]

Plan 9はPOSIXアプリケーションをサポートでき、ANSI CおよびPOSIXに近いインターフェイスを実装するANSI / POSIX環境(APE)を介して、いくつかの一般的な拡張機能を備えたバークレーソケットインターフェイスをエミュレートできます(ネイティブのPlan 9 Cインターフェイスはどちらの標準にも準拠していません)。また、POSIX互換のシェルも含まれています。APEの作成者は、X Window System(X11)をPlan 9に移植するために使用したと主張していますが、「適切にサポートするのは大変な作業であるため」、X11は出荷されていません。[54]一部のLinuxバイナリは、「linuxemu」(Linuxエミュレータ)アプリケーションを使用して使用できます。ただし、まだ作業中です。[55]逆に、vx32仮想マシンでは、わずかに変更されたPlan 9カーネルをLinuxのユーザープロセスとして実行し、変更されていないPlan9プログラムをサポートできます。[56]

レセプション

最新のオペレーティングシステムとの比較

1991年、Plan 9の設計者は、システムのサイズを他の90年代初頭のオペレーティングシステムと比較し、最小(「あまり役に立たないが」)バージョンのソースコードがMach のサイズの5分の1未満であることを示しました。デバイスドライバーのないマイクロカーネル(メトリックに応じて、プラン9の5899または4622行のコードと25530行)。完全なカーネルは18000行のコードで構成されていました。[35] (2006年のカウントによると、カーネルは約150,000行でしたが、これはLinuxの480万以上と比較されました。[39]

オペレーティングシステムの研究コミュニティ内、および商用のUnixの世界では、分散コンピューティングとリモートファイルシステムアクセスを実現するための他の試みが、プラン9の設計作業と同時に行われました。これらには、SunMicrosystemsで開発されたネットワークファイルシステムと関連するvnodeアーキテクチャ、およびUCBerkeleyのSpriteOSなどのUnixモデルからのより根本的な逸脱が含まれていましたSpriteの開発者であるBrentWelchは、SunOS vnodeアーキテクチャは、既存のUNIXドメインソケットを持っていたとしても、リモートデバイスアクセスとリモートプロセス間通信をクリーンにサポートしないという点で、Plan9の機能と比較して制限されていると指摘します。(これは「基本的にユーザーレベルのサーバーに名前を付けるために使用できます」)vnodeアーキテクチャーと統合されています。[37]

「すべてがファイルである」という批判の1つである、Plan 9のテキストメッセージによるコミュニケーションの設計では、Sunのオブジェクト指向オペレーティングシステムであるSpringの型付きインターフェイスと比較した場合のこのパラダイムの制限が指摘されています。

プラン9は、すべてがファイルのように見えるように制約します。ほとんどの場合、実際のインターフェイスタイプは、ファイル記述子への書き込みとファイル記述子からの読み取りが必要なメッセージのプロトコルで構成されます。これを指定して文書化することは困難であり、実行時のファイルエラーを除いて、自動タイプチェックをまったく禁止します。(...)[A]プロセスの暗黙的なルートコンテキストに関連するパス名は、サービスに名前を付ける唯一の方法です。オブジェクトに名前をバインドするには、新しい名前と同じコンテキストで、オブジェクトに既存の名前を付ける必要があります。そのため、インターフェイス参照はプロセス間で渡すことはできず、ネットワーク間で渡すことはできません。代わりに、通信は、エラーが発生しやすく、拡張性のない規則に依存する必要があります。

— ロスコー; オリジナルの強調。[57]

プラン9、スプライト、および3番目の最新の分散型リサーチオペレーティングシステムであるAmoebaを後で遡及的に比較すると、次のことがわかりました。

[AmoebaとSprite]が構築する環境はOS内で緊密に結合されているため、外部サービスとの通信が困難になります。このようなシステムは、UNIXモデルからの根本的な逸脱に悩まされており、既存のソフトウェアのプラットフォームへの移植性も妨げています(...)。開発者の不足、サポートされるハードウェアの範囲が非常に狭いこと、およびプラン9と比較しても小さいことも、これらのシステムの採用を大幅に遅らせています(...)。振り返ってみると、Plan 9は、当時から開発者を引き付け、今日まで存続するのに十分な期間、商用プロジェクトで使用された唯一の研究用分散OSでした。

—  Mirtchovski、Simmonds、およびMinnich [58]

影響

wmii Xウィンドウマネージャー、Plan9プロジェクトのテキストエディターであるacmeに触発されました。[59]

Plan 9は、Unixの不可欠な概念(すべてのシステムインターフェイスをファイルのセットとして表すことができる)が、最新の分散システムで正常に実装できることを示しました。[48] UnicodeのUTF-8文字エンコードなど、Plan 9の一部の機能は、他のオペレーティングシステムに実装されています。LinuxなどのUnixライクなオペレーティングシステムは、リモートファイルにアクセスするためのPlan 9のプロトコルである9Pを実装し、 Plan9のプロセス作成メカニズムであるrforkの機能を採用しています。[60]さらに、ユーザースペースからのプラン9、samおよびacmeエディターを含むPlan 9のアプリケーションとツールのいくつかは、UnixおよびLinuxシステムに移植されており、ある程度の人気を博しています。いくつかのプロジェクトは、Linuxカーネルを取り巻くGNUオペレーティングシステムプログラムをPlan9オペレーティングシステムプログラムに置き換えることを目指しています。[61] [62] 9wm ウィンドウマネージャーは、 Plan9の古いウィンドウシステムであるに触発されました。[63] wmiiもプラン9の影響を強く受けています。 [59] コンピュータサイエンスの研究では、プラン9はグリッドコンピューティングプラットフォーム[64] [58]として、またミドルウェアのないユビキタスコンピューティング[65] 商取引では、プラン9がCoraidストレージシステムの基礎になっています。ただし、Plan 9は人気がUnixに近づいたことはなく、主に調査ツールでした。

[私は] Plan 9が失敗したように見えます。それは、Unixで、その祖先を置き換えるのに十分な説得力のある改善ができなかったからです。Plan 9と比較すると、Unixのきしみや音がし、明らかなさびの斑点がありますが、その位置を維持するのに十分なほどうまく機能します。ここには、野心的なシステムアーキテクトのための教訓があります。より良いソリューションの最も危険な敵は、十分に優れた既存のコードベースです。

Plan 9の採用率が低い原因となったその他の要因には、商用バックアップの欠如、エンドユーザーアプリケーションの数の少なさ、デバイスドライバーの欠如などがあります。[48] [49]

プラン9の提案者と開発者は、採用を妨げる問題が解決され、分散システム、開発環境、研究プラットフォームとしての当初の目標が達成され、中程度ではあるが人気が高まっていると主張しています。[要出典] Infernoは、そのホストされた機能を通じて、Plan9テクノロジーを異種コンピューティンググリッドのホストされた部分として他のシステムに導入するための手段となっています。[66] [67] [68]

9atomや9frontなど、いくつかのプロジェクトがPlan9の拡張に取り組んでいます。これらのフォークは、Upas電子メールシステムの改良バージョン、Goコンパイラ、Mercurialバージョン管理システムのサポート(および現在はgit実装)、その他のプログラムを含む、追加のハードウェアドライバーとソフトウェアでPlan9を補強します。[18] [69] Plan9RaspberryPiシングルボードコンピューターに移植されました。[70] [71] Harveyプロジェクトは、 GitHubなどの最新の開発ツールを活用するために、カスタムPlan 9CコンパイラをGCCに置き換えようとしています。 カバレッジ、および開発をスピードアップします。[72]

デリバティブとフォーク

InfernoはPlan9の子孫であり、特にデバイスとStyx / 9P2000プロトコルを中心に、カーネル内の多くの設計概念とソースコードを共有しています。Infernoは、プラン9とベル研究所のUnixの遺産とUnix哲学を共有しています。Infernoのコマンドラインツールの多くは、 Limboに変換されたPlan9ツールでした

  • 9atom [73]は、386 PAEカーネル、amd64 cpuおよびターミナルカーネル、nupas、追加のPCハードウェアサポート、ILおよびKenのfsを追加して、Plan9ディストリビューションを拡張します。
  • 9front [74]は、Plan 9のフォークです。これは、ベル研究所内の献身的な開発リソースの不足を是正するために開始され、さまざまな修正と改善を蓄積してきました。
  • 9legacy [75]は代替ディストリビューションです。これには、現在のPlan9ディストリビューションに基づくパッチのセットが含まれています。
  • Akaros [76]は、メニーコアアーキテクチャと大規模SMPシステム向けに設計されています。
  • Harvey OS [77]は、Plan9コードをgccおよびclangで動作させるための取り組みです。
  • JehanneOS [78]は、Plan 9から派生した実験的なOSです。そのユーザーランドとモジュールは主に9frontから派生し、ビルドシステムはHarvey OSから派生し、カーネルはPlan9-9k64ビットPlan9カーネルのフォークです。
  • NIX [79]は、マルチコアシステムとクラウドコンピューティングを目的としたPlan9のフォークです。
  • node9 [80]は、Plan9 / Infernoのスクリプト派生物であり、Limboプログラミング言語とDIS仮想マシンをLua言語とLuaJit仮想マシンに置き換えます。また、InfernoのプラットフォームごとにホストされるI / OをNode.jsの libuvイベントとI / Oに置き換えて、一貫性のあるクロスプラットフォームホスティングを実現します。これは、プロセスごとの名前空間と汎用クラウド要素から分散OSを構築して、任意のサイズの単一システムイメージを構築できることを示す概念実証です。
  • プランB [81]は、利用可能なリソースのセットがさまざまな時点で異なる分散環境で機能するように設計されています。

ライセンス

2002年4月の第4版のリリース以降、[23] BellLabsのPlan9の完全なソースコードは、 Open Source Initiative(OSI)によってオープンソースライセンスと見なされているLucent Public License1.02の下で無料で入手できます。 )、Free Software Foundationによる無料ソフトウェアライセンスであり、 Debian FreeSoftwareGuidelinesに合格しています[39]

2014年2月、カリフォルニア大学バークレー校は、現在のPlan 9著作権所有者であるAlcatel-Lucentから、以前はGPL-2.0のみでLucent PublicLicenseバージョン1.02によって管理されていたすべてのPlan9ソフトウェアをリリースすることを承認されました[82]

2021年3月23日、プラン9の所有権がベル研究所からプラン9財団に譲渡され[83]、以前のすべてのリリースがMITライセンスに再ライセンスされました。[9]

も参照してください

参考文献

  1. ^ Lucent Technologies(2006)。「グレンダ、プラン9バニー」2008年12月2日取得
  2. ^ 「Plan9Foundation:アクティビティ」plan9foundation.org 2021年3月23日取得
  3. ^ 「9legacy」9legacy.org 2021年3月23日取得
  4. ^ "plan9checksums"ベル研究所。2017年6月1日にオリジナルからアーカイブされました2019年7月25日取得2015年1月10日土曜日04:04:55EST ... plan9.iso.bz2
  5. ^ 「GPLv2ソースコード」
  6. ^ クロフォード、ダイアン(1999)。"フォーラム"。ACMの通信Association for Computing Machinery(ACM)。42(8):11–15。土井10.1145 /310930.310939ISSN0001-0782_ 
  7. ^ a b c d e Pike、R .; Presotto、D。; ドーワード、S。; Flandrena、B。; トンプソン、K。; Trickey、H。; Winterbottom、P。「ベル研究所からの計画9」ベル研究所LucentTechnologies 2016年2月26日取得
  8. ^ 「プラン9ライセンス」p9f.org2021年6月14日にオリジナルからアーカイブされました2021年6月14日取得
  9. ^ 「Plan9License」akaros.cs.berkeley.edu2014年2月13日にオリジナルからアーカイブされました2021年6月14日取得カリフォルニア大学バークレー校は、アルカテル・ルーセントによって、GNU General Public Licenseバージョン2の下で、以前はLucent PublicLicenseバージョン1.02によって管理されていたすべてのPlan9ソフトウェアをリリースすることを承認されました。
  10. ^ 「Lucentパブリックライセンスバージョン1.02」plan9.bell-labs.com2003年10月3日にオリジナルからアーカイブされました2021年6月14日取得
  11. ^ 「Plan9オープンソースライセンス-バージョン1.4-09 / 10/02」plan9.bell-labs.com2002年12月18日にオリジナルからアーカイブされました2021年6月14日取得
  12. ^ 「Plan9オープンソースライセンス-バージョン1.2-10 / 29/00」plan9.bell-labs.com2000年12月6日にオリジナルからアーカイブされました2021年6月14日取得
  13. ^ 「Plan9オープンソースライセンス-バージョン1.1-09 / 20/00」plan9.bell-labs.com2000年10月26日にオリジナルからアーカイブされました2021年6月14日取得
  14. ^ 「Plan9オープンソースライセンス契約」plan9.bell-labs.com2000年8月16日にオリジナルからアーカイブされました2021年6月14日取得
  15. ^ a b c Raymond、Eric S.(2003-09-17)。「プラン9:未来はどうだったか」UNIXプログラミングの芸術アディソン-ウェスリーISBN 0-13-142901-92007年5月7日取得
  16. ^ ロバートソン、ジェームズ(2011-07-16)。「プラン9フォーク、9フロントとして継続」OSNews2011年12月31日取得
  17. ^ a b c "9atom" 2011年11月11日取得
  18. ^ 「UNIXシステムの発明者からBellLabsのPlan9が登場」(プレスリリース)。ルーセントテクノロジーズ。1995-07-18。2006-02-09にオリジナルからアーカイブされました。
  19. ^ マキロイ、ダグ(1995年3月)。「序文」ベル研究所(第2版)。LucentTechnologies 2016年2月26日取得
  20. ^ Lee、Yvonne L.(1995年7月24日)。「AT&Tベル研究所は組み込みシステム用のPlan 9OSを出荷しています」InfoWorld
  21. ^ ポンティン、ジェイソン(1996年2月19日)。「AT&TはJavaの競合他社の計画を明らかにしている」InfoWorldp。3.3。
  22. ^ a b c Loli-Queru、ユージニア(2002-04-29)。「ベル研究所がPlan9の新バージョンをリリース」OSNews2011年12月31日取得
  23. ^ 「貢献する方法」ベル研究所LucentTechnologies 2011年11月30日取得
  24. ^ 「最新の状態に保つ」ベル研究所LucentTechnologies 2019年7月24日取得
  25. ^ 「プラン9—追加ソフトウェア」2009 2016年3月6日取得
  26. ^ マーカス・ウェルドン(2021年3月23日)。「サイバースペースのベル研究所からのプラン9!」ベル研究所2021年3月23日取得
  27. ^ シャーウッド、サイモン。「ベル研究所は、影響力のある「Plan9」OSの著作権を新しい財団に譲渡します」レジスター2021-03-24を取得{{cite web}}:CS1 maint:url-status(link
  28. ^ 「FQA1--9frontの紹介」fqa.9front.org 2018年2月15日取得
  29. ^ 「ハーベイOS」harvey-os.org 2018年2月15日取得
  30. ^ 「Jehanne」jehanne.io 2018年2月15日取得
  31. ^ 「一般向けの最初のリリースの発表」9人のファン。1995-07-16。2008年7月6日にオリジナルからアーカイブされました
  32. ^ a b Mullender、Sape J。; Jansen、Pierre G.(2004-02-26)。「実際のオペレーティングシステムでのリアルタイム」ハーバートでは、アンドリューJ。; スペルク・ジョーンズ、カレン(編)。コンピュータシステム:理論、技術、およびアプリケーション:ロジャーニーダムへの賛辞シュプリンガーサイエンス+ビジネスメディアp。211. ISBN 978-0-387-20170-22011年12月24日取得
  33. ^ ハンコック、ブライアン(2003)。「Unixの再発明:Plan9オペレーティングシステムの紹介」。Library HiTechMCBUP。21(4):471–76。土井10.1108 / 07378830310509772
  34. ^ a b c d e Presotto、Dave; パイク、ロブ; トンプソン、ケン; トリッキー、ハワード。プラン9、分散システムProc。1991年春のEurOpenカンファレンス。CiteSeerX10.1.1.41.9192_ 
  35. ^ a b c パイク、R。; Presotto、D。; トンプソン、K。; Trickey、H。; Winterbottom、P。「プラン9での名前空間の使用」ベル研究所2016年2月26日取得
  36. ^ a b ウェルチ、ブレント(1994)。「3つの分散ファイルシステムアーキテクチャの比較:Vnode、Sprite、およびPlan9」。コンピューティングシステム7(2):175–199。CiteSeerX10.1.1.46.2817_ 
  37. ^ namespace(4)  –  Plan 9プログラマーマニュアル、第1巻
  38. ^ a b c d e f Pereira、Uriel M.(2006)。UnixスピリットセットFree:Bell Labs (AVIのPlan9FOSDEM 2011年12月2日取得レイサマリー(PDF) {{cite AV media}}Citeは非推奨のパラメーターを使用します|lay-url=help
  39. ^ a b Minnich、Ron(2005)。「なぜプラン9はまだ死んでいないのか、そしてそれから何を学ぶことができるのか」(PDF)ロスアラモス国立研究所2016-02-25にオリジナル(PDF)からアーカイブされました2016年2月26日取得
  40. ^ a b ヴァレリー、オーロラ(2009-03-25)。「ユニオンファイルシステム:実装、パートI」LWN.net2011年12月5日取得
  41. ^ a b Pendry、Jan-Simon; McKusick、マーシャルカーク(1995)。4.4BSD-LiteのユニオンマウントProc。冬のUSENIX会議
  42. ^ ダフ、トム。「18」。Rc —プラン9シェルプラン9、第4版PDF);
  43. ^ a b "UNIXからPlan9へのコマンド変換"ベル研究所LucentTechnologies 2011年12月2日取得
  44. ^ パイク、ロブ(2003-04-30)。「UTF-8の歴史」2006年4月27日取得
  45. ^ ケン・ランディ(1999年1月)。CJKV情報処理オライリーメディアp。 466ISBN 978-1-56592-224-22011年12月23日取得
  46. ^ コックス、R。; Grosse、E。; パイク、R。; Presotto、D。; Quinlan、S。「プラン9のセキュリティ」ベル研究所LucentTechnologies 2016年2月26日取得
  47. ^ a b c ハドソン、アンドリュー(2006-07-19)。「Plan9オペレーティングシステムの調査」OSNews2011年12月31日取得
  48. ^ a b "ラスコックスへのインタビュー"セットアップこれを使用します。2011-04-09 2012年1月1日取得
  49. ^ ディクソン、ロッド(2004)。オープンソースソフトウェア法アーテックハウスp。213. ISBN 978-1-58053-719-32011年12月25日取得
  50. ^ トンプソン、ケン(1992年2月)。「新しいCコンパイラ」(PDF)オーストラリアUNIXシステムユーザーグループニュースレターケンジントンオーストラリアAUUG13(1):31–41。ISSN1035-7521 _ 2011年12月25日取得  
  51. ^ パイク、ロブ。「リオ:並行ウィンドウシステムの設計」(PDF)2013年3月8日取得
  52. ^ thread(2)  –  Plan 9プログラマーマニュアル、第1巻
  53. ^ トリッキー、ハワード。「APE– ANSI / POSIX環境」ベル研究所LucentTechnologies 2016年2月26日取得
  54. ^ 「Linuxエミュレーション」ベル研究所LucentTechnologies 2016年2月26日取得
  55. ^ フォード、ブライアン; コックス、ラス(2008)。Vx32:x86での軽量のユーザーレベルのサンドボックスUSENIX AnnualTech会議 pp。293–306。CiteSeerX10.1.1.212.9353_ 
  56. ^ ロスコー、ティモシー(1995)。マルチサービスオペレーティングシステムの構造(PDF)(Ph.D。)ケンブリッジ大学。pp。22–23。
  57. ^ a b Mirtchovski、Andrey; シモンズ、ロブ; ミンニッチ、ロン(2004)。プラン9—グリッドコンピューティングへの統合アプローチProc。18番目の国際並列および分散処理の症状。IEEE。CiteSeerX10.1.1.97.122_ 
  58. ^ a b "ウィンドウマネージャーが改善されました2"suckless.org2011年12月31日にオリジナルからアーカイブされまし2012年1月2日取得[wmii]は9pファイルシステムインターフェイスを備えており、クラシックおよびタイリング(acmeのような)ウィンドウ管理をサポートしています。
  59. ^ Torvalds、Linus(1999)。「Linuxエッジ」オープンソース:オープンソース革命からの声オライリー。ISBN 1-56592-582-3
  60. ^ 「Glendix:プラン9の美しさをLinuxにもたらす」2011年12月1日取得
  61. ^ 「Gentooからの計画9:計画9はGentooに会います」GentooLinux2012年12月20日にオリジナルからアーカイブされました2011年12月1日取得
  62. ^ 「9wmウィンドウマネージャー」9wm 2012年1月2日取得9wmはXウィンドウマネージャーであり、Xによって課せられた制約の範囲内で可能な限りPlan9ウィンドウマネージャー8-1 / 2をエミュレートしようとします。
  63. ^ 「9grid」ベル研究所LucentTechnologies2006年3月14日にオリジナルからアーカイブされました2006年3月28日取得
  64. ^ Ballesteros、Francisco J。; グアルディオラ、ゴルカ; ソリアーノ、エンリケ; Leal Algara、Katia(2005)。従来のシステムは、普及しているアプリケーションに適しています。ケーススタディ:ベル研究所のプラン9がユビキタスになります。IEEE Intl'Conf。パーベイシブコンピューティングとコミュニケーションについて。CiteSeerX10.1.1.109.8131_ 
  65. ^ 「VitaNuovaはEvotecOAIにインフェルノグリッドを供給します」(PDF)(プレスリリース)。ヴィータヌオーヴァ2004-05-18 2006年3月28日取得
  66. ^ 「ラトガーズ大学図書館はInfernoデータグリッドをインストールします」(PDF)(プレスリリース)。ヴィータヌオーヴァ2004-05-12 2006年3月28日取得
  67. ^ 「ヨーク大学生物学部はVitaNuovaのInfernoデータグリッドをインストールします」(PDF)(プレスリリース)。ヴィータヌオーヴァ2004-05-04 2006年3月28日取得
  68. ^ 「9FRONT.ORGTHEPLANFELLOFF」2021-10-14を取得
  69. ^ ヘイワード、デビッド(2013-05-09)。「RaspberryPiオペレーティングシステム:5つのレビューと評価」TechRadar2013年6月7日にオリジナルからアーカイブされました2014年4月20日取得
  70. ^ 「RaspberryPiにPlan9をインストールする方法」eLinux 2014年11月16日取得
  71. ^ ジュラド、アルバロ; フェルナンデス、ラファエル; デュコロンビエ、デビッド; ミンニッチ、ロン; Nyrhinen、Aki; フローレン、ジョン。ハーベイ(PDF)USENIX ATCBOFセッション。
  72. ^ 「9atom」
  73. ^ 「9FRONT.ORGTHEPLANFELLOFF」
  74. ^ 「9legacy」
  75. ^ 「アカロス」
  76. ^ 「ハーベイOS」
  77. ^ 「JehanneOS」
  78. ^ 「NIX」2020年11月21日。
  79. ^ "node9"GitHub2022年1月14日。
  80. ^ 「プランB」2020年11月26日。
  81. ^ Sharwood、Simon(2014-02-14)。「プラン9はルーセントライセンススペースから移動します」TheRegister2014年4月20日取得
  82. ^ 「Plan9Foundation」plan9foundation.org 2021-10-13を取得

外部リンク