NewsInsight

[Analysis]

Linuxに勝てなかったPlan 9

2009/02/09

　2002年頃、とある雑誌でPlan 9の記事を6ページほど作ったことがある。冷静に考えると、とても流行するようには思えなかったのだが、私にはPlan 9はまぶしく輝いて見えた。それは紛れもなく未来のUNIXだったし、日々コンピュータやネットワークを利用する環境として、ぜひとも使いたいと思えるような機能が多くあった。

　「Plan 9」（プラン・ナイン）はUNIXが生まれたベル研究所で、次世代UNIXとして開発されていた分散OSだ。UNIXやC言語を生み出したケン・トンプソン、デニス・リッチー、ロブ・パイクらのチームが、当時UNIXが抱えていた限界を打ち破るために、ネットワークやGUIを最初からUNIXの設計思想に基づいて取り入れた先進的なOSだった。それは、未来のUNIXとなるはずだった。

　UNIXの大きな特徴として、デバイスをファイルにマッピングして抽象化するというものがある。各I/Oポートへの入出力はファイルの読み書きとして行える。Linuxではマウスの入力であれば、「/dev/mouse」を通常のファイルのようにreadするだけでよい。プリンタへの出力も「/dev/lp」へのwriteと、ファイルと同じ扱いだ。

　ところが、時代とともにネットワークやグラフィックスが付け加わると、こうした初期設計時の抽象化から漏れるAPIが増えた。そうして漏れつつあった各種リソースを、再びUNIX的なファイルシステムのツリーにマップし、抽象度と統一性の高いインターフェイスを用意したのがPlan 9だった。ファイルとして扱えるのは一般に想像するようなハードウェアデバイスだけではなく、あらゆるリソースが対象となった。GUIで扱うウィンドウやネットワーク上のコンピュータ、CPU、稼働中のプロセスなどもディレクトリツリーにマップされていた。TCP/IPなどのネットワーク関連の操作も「/net」というディレクトリを使って行うなど徹底していた。

　こうした特徴から当時、Plan 9はUNIXよりもUNIX的だという紹介のされ方をしていたし、Plan 9をおもしろがるUNIXユーザーは少なくなかったと思う。Plan 9にはほかにもメモリやハードディスク、光ディスクまでを統一的に扱うことで容量設計やバックアップ、バージョン管理の問題をなくした「WORM」や「dumpfs」と呼ばれる仕組みや、ネットワークドライブのマウント時の名前空間の問題を解決する仕組みなど、多くの新しいアイデアに満ちていた。

Plan 9はなぜ失敗したのか？

　UNIXを生んだドリームチームが、再び同じ思想を持って作り直した現代的なUNIX、それがPlan 9だ。Plan 9は未来のUNIXとなるはずだった。しかし実際には、2002年4月にリリース4を出して以来、開発はストップしている。

　Plan 9はなぜ失敗したのか？

　この問いに対して2003年の時点で、エリック・S・レイモンド氏が1つの回答を与えている（リンク）。そして、この回答には、何度もかみしめるべき教訓が潜んでいると思うのだ（レイモンド氏はESRの略称で知られるOSSムーブメントの立役者の1人。OSSの開発モデルを分析した論文、「伽藍とバザール」の執筆者としても知られる。念のため）。

　マーケティングに熱心でなかったからとか、さまざまな理由付けが可能だが、Plan 9が普及しなかった理由は結局のところ、旧来のUNIXを置き換えるほどには先進的ではなかったからだ、というのがレイモンド氏の答えだ。

　Plan 9に比べれば、確かにUNIXはきしみ音が聞こえてガタピシいうし、明らかにさび付いたところもあるのだが、そのポジションを維持するために必要な仕事はちゃんとこなせていた、という。このPlan 9とUNIXの事例から、野心的なシステム設計者に対してレイモンド氏が引き出す教訓は「より良いソリューションに対する最も危険な敵というのは、十分に良い既存のコードベースなのだ（the most dangerous enemy of a better solution is an existing codebase that is just good enough.）」というものだ。

漸進的な進化を果たしたLinux

　LinuxやBSD系UNIXには、Plan 9由来の機能がいくつか取り込まれている。稼働中のプロセスをモニタしたり操作するための「/proc」と呼ばれるファイルシステムは、Plan 9のものだし、Linuxでスレッドを生成するシステムコール「clone」は、レイモンド氏によればPlan 9の「rfork」をモデルにしているという。

　すべてをファイルのように扱うという意味でいえば、LinuxのFUSE（Filesystems in Userspace）もPlan 9の影響下にある。Plan 9ではFTPクライアントを提供する代わりに、ftpfsというファイルシステムを実装し、そのことによって通常のファイル操作と同等のコマンドやツールを使えるようにする。現在、FUSEを使ったファイルシステムには、ftpfsはもちろん、flickrfsやBloggerFS、TracFSなどさまざまな実装がある。

　今やOSばかりかインターネット全体にも利用範囲を広げた感があるUTF-8も、Plan 9のために考案されたエンコーディングだという。

Plan 9に似た機能が現実のサービスとして登場

　私がPlan 9を日常的に使う環境にしたいと思った理由のほとんどは、dumpfsとWORMファイルシステムの存在があるからだった。dumpfsは毎日朝5時など決まった時間にスナップショットを取り、ファイルを差分で管理する仕組みだ。「/dump/2009/01/15/usr/ken/foo.txt」などと日付を指定すれば、任意の日付のバージョンでファイルが取り出せる。一方、WORMファイルシステムは、文字通りWORM（Write once, read many）の光メディアとハードディスクを組み合わせたシステムだ。システムで扱う情報のうち頻繁にアクセスされるものはハードディスクに置き、そうでないものは、逐次、マガジン式の光ディスクに蓄積させていくというものだ。つまり、dumpfsとWORMにより、ユーザーはハードディスクの容量を気にしてファイルを消す必要もないし、うっかり消してしまっても問題はないし、バックアップを取る必要もない。アプリケーションでバージョン管理をする必要もない。

　先日、これと似た仕組みはZumoDriveで実現してしまったのだなと思った（参考記事：“すべてクラウド”も間近!? 「ZumoDrive」を使ってみた）。マガジン式の光ディスクの代わりにクラウド上のハードディスクを使うという違いはあるが、実現できることは、Plan 9におけるdumpfsとWORMファイルシステムを組み合わせたシステムとほとんど同じだ。

新しいことは上位レイヤで実現すればいい

　既存技術が十分に良かったから、というレイモンド氏の理由付けは、その通りだと思う。もう少し正確に言えば、十分に良かったというのは「まだ進化や機能追加に耐えるほど十分に良かった」という意味だろう。UNIXやユーザー環境がPlan 9的なものを取り入れて進化していけたからこそPlan 9は不要だった。「UNIX→ Plan 9」のような非連続的でコストの高いジャンプをする代わりに、UNIXは漸進的に進化してきたし、まだ進化しつつもある。同じようなことはXHTMLとHTML 5の関係にもいえるだろう。約束された未来だったはずのXHTMLへの移行は起こらず、HTMLが進化する形となった。

　進化は、実績を積んだ古い技術の「上」に積層するように起こっているようにも見える。

　例えば、Plan 9のようなファイルシステムによる抽象化は強力だが、もう少し上のレイヤを考えれば、プログラミング言語による抽象化が同じことをしつつあるとも考えられる。Rubyのように抽象度の高い言語を使えば、Linux上であってもネットワークやファイルといった違いをあまり気にせずにプログラミングができる。あるいは多くのWebアプリケーションではファイルの読み書きがHTTPのGETやPOSTに置き換わっている。計算リソース、ネットワークリソースが爆発的に増加している現在、かつてOSやミドルウェアが抽象化すべきだったことも、アプリケーションレベルでインターネットを介して行われているように見える。

　地層にたとえて言えば、OS（カーネル）は古層として扱い、その上に降り積もるユーザー空間アプリケーションという新しい層で、さまざまな機能を付けて進化していけばいい。いつまで経っても古層に降りていく必然性は消えはしないが、かといって古層を取り払ってやり直したり、何か別物で置き換えようというのは、あまりに効率が悪い。クラウドコンピューティングは、ぴかぴかの分散OSを使う代わりに、LinuxというモノリシックなOSを基本ピースとして、その上に構築された分散コンピューティング環境だ。

2009年におけるPlan 9

　レイモンド氏によるPlan 9の議論を知ったのは実はつい最近なのだが、この議論が私の脳裏に焼き付いたのは、いま現在も「2009年のPlan 9」ともいうべき“ベターソリューション”や“未来の技術”が世に溢れているように思われるからだ。

　典型例はNGNだ。すでにあるオープンなネットワーク上のTCP/IP通信（インターネット）は十分に良く、代替技術が要るようには思えない。データ通信と音声や動画の融合など、とっくに実現されているし、QoS制御にしても専用のアーキテクチャを用意するほどインターネットは悪くない。むしろP2PやCDN、分散キャッシュの研究・開発をすべきではないか。SkypeもFacebookもYouTubeも数億人にスケールさせることができていて、十分に良いサービスを提供している。セキュリティにしても、もしまだ何か追加技術が必要であるとしても、それはもはや上位レイヤで解決すべき問題であって、わざわざ既存技術・インフラと違うものを持ってくるべき理由はない。

　Windows Vistaへの移行が進まなかったのも、Windows XPが十分に良かったからとも言えるだろう。人々が求めた新しい“ユーザー体験”は、主にWebサービスの形でもたらされた。

　PC自体が「十分に良い」コンピュータの例だ。1980年代辺りまでパーソナル・コンピュータはマニアのおもちゃでしかなかったが、いまやPCを構成するのと同じパーツからなるサーバが、やはりマニアのおもちゃといわれたようなLinuxを使ってインターネットを作り出している。個々に見ると信頼性や性能が足りない局面はあっても、クラスタリングで十分な性能を確保できている。

ノウハウや開発の蓄積に打ち勝つほどの違いはあるか？

　「古層」という言葉は聞こえが悪いが、その実績とノウハウの蓄積も無視できない。レシプロエンジンを置き換えるはずだったロータリーエンジンは、理論上は優れていたものの、レシプロエンジンの長年の開発の蓄積の前にはついにそれを置き換えるほどのアドバンテージを持ち得なかった。実績やノウハウの蓄積まで含めたときに、NGNが、すでに存在するインターネットを超えるほどのアドバンテージを持ち得るとは考えづらい。

　JavaScriptに関しても、似たような議論がある。2009年1月28日付けのブログで、米MITのソフトウェア・デザイン・グループ、リサーチフェローのジョナサン・エドワーズ（Jonathan Edwards）氏は皮肉たっぷりにJavaScriptを「欠陥言語」だとやりこめている（リンク）。「JavaScriptは十分に良い。MS-DOSが十分に良かったというのとまったく同じ意味において、十分に良い」。エドワーズ氏に言わせれば、JavaScriptはMS-DOS同様に雑なクイックハックの結果として、本質的なところで欠陥を抱えている。しかも、互換性の問題から直しようがないところもMS-DOSに似ているのだという。JavaScriptは「大量のプログラマを使って何とかかんとか動くようなゴミソフトウェアを生産するぐらいには十分良い。そして、それは金儲けするには十分だ」と手厳しい。

　MITのフェローに反論する身の程知らずを承知で言うのだが、私にはエドワーズ氏の皮肉は不当に思える。ベースとなる技術が理想と遠いからといって、それが粗末なアプリケーションしか生み出さないという道理にはならない。MS-DOSやWindows 95というクイックハックの結果、PCはビジネスの世界で市民権を得るほどのアプリケーションを獲得した（同時に多くの書きかけの文書がクラッシュで失われもしたが）。Webのフロントエンドを語るのに、2009年の今になってJavaScript以外のものを持ち出そうとか、あるいはその欠点をあげつらうのはPlan 9の教訓に反している。十分に良いものは、おそらく置き換えられないし、また置き換えるほどの理由はない。すでに優れたWebサービスはほとんどすべて、フロントエンドはJavaScriptで書かれている。JavaScriptを漸進的に進化させ、それをベースに何を作るかを考えたほうが生産的だ。

　もちろん、Plan 9の教訓が当てはまることばかりではないだろう。しかし、「未来の技術」とか「ベターソリューション」の多くは、現行技術やコモディティ化した一般技術を置き換えるほどに良くはない、という一般論には妥当性があるかもしれない。