Plan 9

出典: Wikipedio


Template:Infobox OS

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

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

目次

名称の由来

Plan 9の"9"には、UNIX version 8の次の版の意味があると言われている。なお、UNIX 8はベル研究所のチームよって開発された最後のUNIXである。

また、Plan9 from Bell Labsという文句でリリースをしているが、これはエド・ウッドB級SF映画 Plan 9 from Outer Space に因んでいる<ref>Template:Cite web</ref>。また、プロジェクトのマスコットキャラクターGlendaの名も同じくエド・ウッド作品グレンとグレンダに因む。初期の(つまり間に合わせの)ウインドウシステムはフェデリコ・フェリーニの名画「8 1/2」の名を冠するなど、ハッカー流ジョークの側面でもUNIXの後継であることを伺わせる。

歴史

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

Plan 9 はベル研究所の Computing Science Research Center のメンバーが開発した。そのグループはUNIXC言語を開発したグループと同一である。当初チームはロブ・パイクケン・トンプソンらが率い、Computing Techniques Research Department のリーダーとしてデニス・リッチーが支援した。開発には、ブライアン・カーニハンビャーネ・ストロヴストルップらも貢献している<ref name="Developers">Template:Cite web</ref>。

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

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

概要

UNIXとの違い

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

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

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

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

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

全てのリソースはファイルである

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

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

Plan 9 研究プロジェクトは、ファイル中心の見方への回帰を目標とし、それ以外の手法を排除した。Plan 9 のプログラムから見れば、ネットワークやユーザインタフェースのリソース(ウィンドウなど)も含めたあらゆるリソースが階層型ファイルシステムの一部となっており、それ以外の特別なインタフェースは使わない<ref name="Availability">Template:Cite web</ref>。

分散アーキテクチャ

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

設計

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

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

ファイルシステム、ファイル、名前

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

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

Union ディレクトリ

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

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

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

/proc

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

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

/net

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 ディレクトリを見せることで、ネットワークアクセスを制限することができる。

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

類似の機構としてBSD系の mount_portal[1] コマンドがあるが、そちらは /net ではなく /p をマウントポイントとし、/tcp 部分だけに対応している。

ネットワークと分散コンピューティング

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

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

Unicode

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

実装

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

IBMスーパーコンピュータ Blue Gene にも移植されている<ref name="BGPlan9">Plan9 BG Presentation</ref>。

影響

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 に対しては、「オペレーティングシステム研究での興味深い論文を生成するためのデバイスとして主に機能している」という批判もある<ref name="ESRPlan9" />。エリック・レイモンドは著書 The Art of Unix Programming で、Plan 9 が広まらない背景について、次のように考察している。

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

Plan 9 をオペレーティングシステム設計における "Worse is better" 派の典型と見なす立場からは、Unix一般と同様の批判がなされている。例えば、「磨き上げ」が相対的に足りないという批判や<ref>Template:Cite web</ref>、商用ソフトウェアとしては相対的に完成度が低いという批判<ref>Template:Cite web</ref>がよく見られる。

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

ライセンス

GNUプロジェクトはPlan 9のライセンス<ref>Lucent Public License</ref>をフリーソフトウェアライセンスだとは認めていなかったが、2003年6月にそのライセンスに変更が加えられ、GPLとは整合性を持たないながらも、フリーソフトウェアと認められるようになった<ref>Various Licenses and Comments about Them - GNU Project - Free Software Foundation (FSF)</ref>。OSIオープンソースライセンスと認めており、Debianフリーソフトウェアガイドラインには合格している。全ソースコードがそのライセンスで無料で入手可能である。

関連項目

  • acme - プログラマ用ユーザインタフェース
  • 9P - ファイルシステム・プロトコル
  • Inferno - Plan 9 から派生した分散OS

脚注・出典

Template:Reflist

外部リンク

ベル研究所

レクチャー

他のネイティブ版と仮想版

ネイティブ
  • Plan 9 - Vita Nuova Holdings による製品版
仮想

その他

Template:Unix-likecs:Plan 9 from Bell Labs de:Plan 9 (Betriebssystem) en:Plan 9 from Bell Labs eo:Plano 9 es:Plan 9 from Bell Labs fr:Plan 9 from Bell Labs gl:Plan 9 he:Plan 9 from Bell Labs hu:Plan 9 from Bell Labs ko:플랜 9 (운영체제) lt:Plan 9 nl:Plan 9 no:Plan 9 pl:Plan 9 pt:Plan 9 from Bell Labs ru:Plan 9 simple:Plan 9 from Bell Labs sv:Plan 9 th:Plan 9 uk:Plan 9 zh:貝爾實驗室九號計畫

個人用ツール