NewsInsight

先週の人気記事ランキング

【Top10】さらばDLL地獄、純関数型OS「NixOS」

2009/02/17

　先週の＠IT NewsInsightのアクセスランキングの第1位は「2009年はトレンドを追うな――小飼弾氏が講演」だった。未曾有の経済不振の渦中にあっては、目先のトレンドを追うよりも、じっくり腰を落ち着けて“確立された知恵”を学ぼうという主張には、多くの技術者がうなづいたかもしれない。

NewsInsight Weekly Top 10 （2009年2月9日～2月15日） 1位 「2009年はトレンドを追うな」――小飼弾氏が講演 2位 Linuxに勝てなかったPlan 9 3位 不況で解雇された従業員が重要データの脅威に、マカフィー 4位 求人数はJava、年収はC#がトップ――ワークポートが調査 5位 未来の言語は「APL」？ Rubyのまつもと氏が講演 6位 新興市場で輝きを放つRuby 7位 ライブドア、開発者向けソースコード公開サイト「EDGE src」をオープン 8位 低コスト機器でPC並のGUIを実現、三菱が新技術 9位 UTMによる統合セキュリティは「日本車と同じ」 10位 Oracle Exadata、国内初出荷先はNTTデータ

　2位となった記事、「Linuxに勝てなかったPlan 9」は、十分に良い既存技術を、新規の技術で置き換えることは、たとえそれがより洗練されていたとしても難しいということを指摘したものだった。すでに広く普及していて使われているLinuxを置き換えるほどには、Plan 9がもたらすメリットは十分に大きくなかった。

　この言及に対して、その名もずばり「Plan9日記」を公開しているoraccha氏から貴重なご指摘をいただいた。該当段落を引用すると、

また、研究OSってそんなもんだよという思いもある。Linuxという下位レイヤを維持するために、日々膨大な人的／知的リソースが投入されているわけだけど、Plan9のような少数精鋭による思考実験も、新しい進化のためには必要だ。その成果が新しい燃料として、実用OS（Linux）に投下されると。

という指摘だ。新しいアイデアを実際に動く実装で試すために研究OSというのは必要で、それは実用OSと分けて考えたほうがいいのではないかということだと思う。そう考えると、Plan 9は失敗というより、むしろ、数多くの論文にネタを提供し、しかもLinuxやBSD系UNIXにアイデアが取り込まれた成功事例ということもできるかもしれない。

　ただ、それにしても相対的に言えば、基盤技術の研究開発の重心は上位レイヤへと動いている気がする。Plan 9開発チームにいたロブ・パイクやケン・トンプソンが、すでに現在、グーグルに移籍しているのは象徴的だ。ロブ・パイクは、グーグル社内でMapReduceを利用する際に使う言語「Sawzal」で論文を書いたりもしている。分散OSよりも、クラウド上の分散コンピューティングを研究することのほうが市場的な意味も大きいだろう。

　いずれにしても、この視点でいえば、インターネットとNGNを対比させるのは間違いだった。NGNは実験の場などではなく、実用を目指したものだからだ。

NixOSは2009年のPlan 9か？

　oraccha氏は、「2009年のPlan9」がいろいろ出てくるのを期待すると書いているが、実験的試みという意味では同感だ。最近、私は2つのOSが気になっている。これらを研究OSと呼ぶべきかどうか分からないが、とても実用レベルで普及しそうには思えないもので、少なくとも研究目的の実装という感があることは間違いない。

　1つは「Zero Install」だ。LinuxやMac OS Xなどを対象にしているので、これはOSというよりもアプリケーションのインストール・配布システムと呼ぶべきかもしれない。現在、Zero Installは、これらのOSが共通に抱える課題を解決することを目指している。Zero Installは、その名が示すとおり、アプリケーションのインストールという概念自体をひっくり返したようなシステムだ。例えばシステム管理権限（root）がなくても、一般ユーザーはアプリケーションを導入できる。また、初回起動時にネットワークからバイナリパッケージを持ってくるが、それはローカルのストレージから読み込むのと本質的に変わらない。Zero Installでは、このほか中央集権的なアプリケーション配布レポジトリを排して、誰でも自分のWebサイトでアプリケーションを公開できる仕組みもある。ほかのユーザーがこのアプリケーションを利用するにはURLを引数にしてコマンドを叩くか、それに相当するメニューをクリックする。ソフトウェアは必ず電子署名が施されている。ほかにも、アプリケーションの自動アップデートや、コンフリクトが起こらない設計、事前に安全確認ができるサンドボクシング、同一アプリケーションの複数バージョンの共存、など目が覚めるような機能が盛りだくさんだ（各種パッケージング方式の機能比較リスト）。

　メジャーなLinuxディストリビューションで、Zero Installを採用したものはないが、部分的にでも、そのアイデアを取り入れてくれればと思うことがある。既存のパッケージシステムと共存する形で入れることも可能かもしれない。

　もう1つ、最近私が気になっている実験的OSは“純関数型”を標榜する「NixOS」だ。これもLinux上に構築したシステムで、本来の意味でのOSとは違うのだが、ユーザーが利用するシステムが抱えている課題を解決しようとしているという意味ではOSと呼んでもいいと思う。NixOSの公式ページには純関数型ディストリビューションと書いてある。

　容易に想像できる通り（？）、関数型ディストリビューションのNixOSでは、多くの操作が破壊的ではない……、のだという。設定ファイルの変更はNixエクスプレッションというものを使って行い、これは既存の設定ファイルを上書きするものではない。Nixエクスプレッションを連ねていくことで設定ファイルを生成し、そのシンボリックリンクだけを/etcの下に置いておくという。だからNixエクスプレションの組み合わせを変えるだけで、任意のバージョンにロールバックできるし、ちょっとした変更テストの操作も確実に行える。これは起動関連の設定情報に関しても同様だ。

　WindowsでもLinuxでもライブラリのバージョンの衝突や非互換によって、多くの不具合が起こる。WindowsではDLL地獄と呼ばれている。ある特定バージョンのDLL（共有ライブラリ）を想定したアプリケーションが、他のアプリケーションのインストール時に行われる当該DLLのバージョンアップ（上書き）によって動作が不安定になり得る。

　Linuxではバージョンの違うライブラリのファイル名には番号が付いていることが多いため多少はマシだが、それでも困ることが多い。Debian GNU/LinuxやUbuntuはパッケージ間の依存関係を考慮してくれるので、ほとんどの場合、インストールもアンインストールもクリーンに行える。しかし、2つのアプリケーションが、あるライブラリの異なる2つのバージョンを要求している場合など、本質的に解決が難しい問題もある。

ガベージ・コレクタも備えたパッケージ管理システム

　NixOSのパッケージ管理システムでは、こうしたパッケージ間依存に付随して起こる問題を、一気に、エレガントに解決しているように私には見える。パッケージをインストールすると実体は「/nix/store」の下に入る。このとき、サブディレクトリ名には、そのパッケージやソフトウェア、ライブラリの名前、バージョン番号だけではなく、依存関係の情報を含むハッシュ値が含まれる。バージョンの違いだけであっても、異なるパッケージは異なるディレクトリに入る。つまり、バージョンの異なるアプリケーションやライブラリの共存が可能で、パッケージのロールバックも依存関係の矛盾や衝突の心配なく行えるというわけだ。ライブラリなどのパッケージを削除しても、すぐには実体が消えずにシステムに残る。本当にハードディスク上から消えるのは、ほかのパッケージから参照されていないことを“ガベージ・コレクタ”が確認してからだ。ガベージ・コレクタは概念上の存在やシステム内部の奥深くにあるものではなく「nix-collect-garbage」というコマンドだ。

　例えば、Firefoxのバージョン2系と3系、あるいはGIMPの2.4系と2.6系などを共存させるためには、これまで何らかの工夫が必要だったが、こうしたものを、矛盾やムダを省いた形で共存できる。異バージョン間で共通して参照しているパッケージがあれば、それはシステム上でも1つ。逆に異バージョン間で同一ライブラリを使っているものの、依存しているライブラリのバージョンが違っていれば、それは異なるディレクトリに収まっている。Firefox 2だけを削除してFirefox 3を残すと、Firefox 2だけが使っていたライブラリはいずれガベージ・コレクタに回収される。実行形式に付けるリンク名はどうしても衝突するかもしれないが、それは比較的小さな問題だろう。

　実用になるかどうかは別として、NixOSは面白い。パッケージ管理システムやOS全体に対して、関数型プログラミング言語の概念を適用すると、こうもスッキリ多くの課題が解決するのかとうなってしまう。パッケージ管理が抱えている依存地獄という問題は、名前が指し示している実体がどこかで誰かに変更されてしまう可能性を排除できないから起こるわけで、いったん名前を付けたら、その名前が必ずバイナリレベルで同じ実体を指すようにしましょう、ということだと思う。

　ずいぶん長々と書いてしまったが、2002年頃にPlan 9にワクワクしたように、2009年のいま、私はZero InstallやNixOSにワクワクしてしまう。そのエッセンスだけでもメジャーなLinuxディストリビューションに取り込まれればと思う。こうした意味では、私も2009年のPlan 9をもっとたくさん見てみたいと願う1人だ。そして最後にもう1度同じ論点に戻ると、そうした新しい試みの多くは、カーネル空間で動く何かではないと私には思えるのだが、どうだろうか。Amoeba、Spring、GNU/Hurd、Plan 9といろいろあったが、分散OSの研究・開発というパーティーは終わってしまった。今はLinuxベースのクラウド上で連日、にぎやかなパーティーが開かれているように思う。