![[logo]](/data/tikilogo.gif)
Plan9 Plan9"Not only is UNIX dead, it's starting to smell really bad." -- RobPike circa 1991
名前の由来はB級SF映画だとか．どんな映画か知ってます?
#comment
Mon Apr 23 14:16:43 2007 戯 処理コスト度外視するなら、直感的には既存の大抵のバージョン管理ツールは、そのまま移植＋過去版参照はcheckoutコマンドをラップして…で出来そうな気がしますよね。／／スナップショットを定時(だけ)じゃなく任意のタイミングで作らせること出来るんでしょうか？出来るなら簡易なcheckin代わりに使えると思う。
Sun Apr 22 17:26:11 2007 りょうせい dumpfsを使っていれば、自動的に/n/dump/日付/以下にスナップショットが取られます。"bind -b /n/dump/2007/0422 /"とスナップショットをルートディレクトリにbindすれば、そのプロセスの名前空間がスナップショット時のものに変わります。これは強力ですよね(まさにタイムマシーン)。明示的にスナップショットを取るタイミングを指定したい、一日単位だと粒度が荒すぎる、タグ付けしたいとかなるとバージョン管理ツール(ファイルシステム)の出番なんでしょうか。
Plan9開発者が特定のツールを使っているかは知りません。最近は、Mercurialを動かそうとしている人がいたようですが。
Sun Apr 22 13:16:30 2007 戯 Plan9で動くバージョン管理?ツールはやっぱり過去バージョンもファイルとして見れるんでしょうか？
／／
そうなら過去版も普通のgrepライクなツールで検索できますよね。
Tue May 16 11:28:43 2006 IWP9 2006
Sat Apr 29 15:12:50 2006 りょうせい Interview with Russ Cox (USENIX ;login 1997-12)
Sun Mar 5 23:11:20 2006 りょうせい TIP9UG/20060305
Thu Nov 17 01:45:04 2005 TIP9UG/20051112
Tue Nov 15 19:27:00 2005 りょうせい Drawterm のアカウントもらったけど，acme の使い方覚えないとなぁ．
Sun Sep 18 01:25:48 2005 りょうせい Why Plan 9 is not dead yet And What we can learn from it
Fri Apr 8 06:36:58 2005 りょうせい jail? みたいな仕組みと組み合わせればよいのか．> v9fs
Sun Mar 27 19:28:56 2005 りょうせい plan 9 kernel history
Mon Nov 22 22:58:05 2004 りょうせい V9FS 9P2000 file system support for Unix/Linux/*BSD だって．Unix には名前空間がないから，その辺をどう扱うのか難しいところだな．
Wed Sep 15 12:54:03 2004 りょうせい と言うか，まだ nCUBE って存在していたのね．n4 ってのは VoD やストリーミングのような動画配信に特化したしているみたい．
Wed Sep 15 12:48:14 2004 りょうせい nCUBE 3 でも Plan9 が動くらしい．avg's Profile
って以前(1998年ごろ)メモに書いたけど，役割を特化させるというのは情報家電みたいなモバイル，ユビキタスコンピューティング環境や，大規模トランザクションを処理しなきゃいけない電子商取引サーバ(i-modeのサーバでもいいや)を考えると，そうなるのが自然かなと思えるようにもなってきた．Plan9がどの程度のターゲットを相手にしているのか論文読み直さなきゃわからないけど．
「大型汎用うんぬん」ってのも眉唾だなぁ．ただし，Plan9のクライアントサーバ構成 (次に示す)が妥当だとは思わない． もっと違うスケーラビリティを持たせられるアーキテクチャが考えられると思うんだけど．
この辺をもう少し考えてみよう．元々 UNIX は TSS をターゲットとしたシンプルな OS として設計，開発された．その後，ネットワークや WIMP インタフェースなどの技術革新が進み，WS 用 OS として使われるようになっていった． そこで，UNIX の原点(simplicity, clarity, generality)に立ち帰り，現代のテクノロジーを反映して，再実装したのが Plan9 と言える．ここでキーになるのが，すべてはファイルという抽象化の徹底，9P プロトコルによるネットワーク透化性，プロセスごとの名前空間である．Plan9 自体は TSS のような集中から WS，さらに分散した運用が可能である．
逆にネットワーク(ソケット)インタフェースにファイルインタフェースを引き寄せるアプローチはないものか．Pipe も含めて．
すべての資源は階層構造のファイルシステムで表現され(三つの例外：プロセス生成，ネットワークアドレス，共有メモリ)，ユーザ，プロセスごとにネームスコープを持つ．
コンパイル時にネームスコープやプロセスごとの属性はわからない． ファイルへのアクセスはすべてネームサーバを介し，プロセスごとのネームスコープでファイルサーバへ要求が飛ぶ．
link を廃止し，bind により動的にファイルツリーを生成する(ファイルサーバだけは静的なツリーを持っているが，ユーザから見えるツリーは login 時に動的に生成される)．
ネットワーク共有
% import gw_host /net
% import remotehost /proc % ps; acid
思いのほか，そのような時期は早く到来するのかも?
最近の Plan9 では Venti というアーカイブストレージサーバが話題になっているらしい．従来の Plan9 では，ネットワークファイルサーバにもなる標準ファイルシステム fs とローカルファイルサーバの簡易ファイルシステム kfs から構成されていた．今後は，venti + fossil という形になるようだ．