読者です 読者をやめる 読者になる 読者になる

ブースト会議

すごかった。刺激的。

VIVERも見劣りしている場合ではない。どんどん作らねばー


分散ディスク共有関係でいろいろなアイディアをいただく。
しかし、やっぱり分散共有したい。

ネットワークブート時に、ディスクイメージはRAMに全部展開するべきではないかというご意見をいただく。
まずはtoramオプションの実装が必要。


何はともあれ、プラグインシステムを作る。
これの作り方次第が、ネットワークブートをサポートするだけのシステムになるのか、ネットワークシステムの基盤システムとなるのかの分かれ目となる。


どこまでをディストリビューションに依存し、どこまでをプラグインにするのかが難しい。


実行ファイルはどちらか。
共有ライブラリは?
設定ファイルだけ書き換える?設定ファイルの場所はディストリビューション依存?
プラグインにするべきサービスと、ディストリビューションが提供するサービスの境界は?
ネットワークの起動はプラグインで行う?VIVER本体が行う?プラグインシステムが行う?
NICが2枚以上ある場合の対処は?
Zeroconfはプラグインシステムに統合?プラグインで提供?
プラグインシステムAPIで提供する機能は?どの言語のバインディングを作る?sh/C++/Ruby/Python/…
プラグインのメタデータの書式は?
依存と適用順順制御は分ける?統合する?
○○プラグインより後でないといけない、という適用順制御は必要か?
循環した依存や適用順制御はどうする?


ディストリビューション間の差異を吸収する必要があることの解決策として、専用ディストリビューションを開発するか、特定ディストリビューションだけにターゲットを絞るという方法は、いつでも存在する。
専用ディストリビューションを作るというのは、確かにおもしろいが、あまりに手間がかかる。作成よりむしろメンテナンスに手間がかかる。1人ではできない。


中庸策として、様々なディストリビューションの共通部分だけを取り出した小さいディストリビューションを開発する、と言う方法を今思いついた。
どんなディストリビューションを使うにしても必要になるものとプラグインシステムだけディストリビューションで、ユーザーはyumやaptやyastを別途インストールして、自分で拡張していく。
拡張を支援するツールがあっても良いかもしれない。「これはVIVERベースシステムです。このシステムをFedoraにしたいですか?SUSEにしたいですか?Debianにしたいですか?」「Fedoraですね。ではrpmとyumをインストールしておくので、後はご自由に」


RedHatでは「basesystem」とか「networksystem」というような名前のRPMパッケージが存在したはず。これをインストールすると、そのシステムはRedHatになる。これを「rpmでインストールされていることして」おけば、rpmから見ればそのシステムは「RedHatである」ことになる。
Debianではどうなっているのか知らないが、そのようなパッケージはおそらく存在する。これを「dpkgでインストールされていることにして」おけば、dpkgから見ればそのシステムは「Debianである」ことになる。
一方で、glibcやinit、rc.sysinitは自分でコンパイルしてインストールしておく。
これでRedHatでもDebianでもある(RedHat的拡張もDebian的拡張もできる)ディストリビューションが完成する。これが発想の始点。


プラグインシステムはこのベースシステムのみを前提とすることができ、それ以外のものが必要な場合は、自身に含むか、依存関係としてメタデータに記述しなければならない。


うむ。これはうまくいきそうだ。
でも、ベースシステムの開発はおそらく非常に難しい。
rpmやdpkgにあるパッケージがインストールされているかのよう見せかけることは、別に難しくない。
難しいのはglibcやinit、特にrc.sysinitをどのディストリビューションにも互換性があるように作成すること。
あらゆるディストリビューションを調べ上げ、そのどれにも互換性を持たせるというのは、簡単ではない。



rc.sysinitか…これはベースシステムに存在しなくても良いか。どのディストリビューションにするかを決定したところで、FedoraならFedoraのrc.sysinitをダウンロードして入れれば良い。
そもそもどのディストリビューションにも互換性があるrc.sysinitなんて不可能か。


でもネットワークの起動はやらせたくないな。やらせたら破綻する。
現状は小手先のシェルスクリプトで起動スクリプトを削除して対応しているけど、この作業自体がディストリビューション依存だし、網羅的でもない。でもこうやって対処していく以上どうしようもない気もする。




いや、特殊プラグイン「CORE」を作るのはどうか。必ず一番最初に適用されるプラグインで、glibcのインストール(同じバージョンがインストールされていれば無視)や、ディストリビューションにネットワークを起動させないようにする処理と、ネットワークを起動する処理を行う。
他のプラグインは「CORE」のみを前提とすることができ、他のものが必要な場合は、自分自身に含むか、依存関係に書いておく。


ディストリビューションには「依存することができない」ようにするのも良いかもしれない。つまりバイナリや共有ライブラリまですべてプラグインで提供する。
…いやいや…それは現実的じゃないな…
「設定を行うプラグイン」なんてのは存在するだろうし。X11を設定するプラグインなどなど。
DHCP Serverを設定するプラグインくらいなら、ISC DHCP Serverはそんなに大きいものではないから、プラグインに含めても良いけど、xorgなんてプラグインに入れ始めたら大変だ。xorgを入れると言うことは、フォントとxfsも入れることになる。
ディストリビューションの存在意義が無くなっているんじゃないか?ディストリビューションを自分で作っていないか?


でもたとえば「フェイルオーバーされたApacheを起動するプラグイン」なんてものはどうするか。Apacheの設定ファイルのデフォルト設定はディストリビューションごとに大きく異なる。どの拡張ライブラリが入っているかも、ディストリビューションに依存する。
全部依存関係に書けば良いのか?



X11はネットワークプログラムじゃないけど(むむ…微妙だ)、Apacheはネットワークプログラムだから、X11ディストリビューションにバイナリを入れて、Apacheはプラグインに入れる。
うーむ…。


X11Apacheは既にディストリビューションがカバーするアプリケーションになっているけど、DHCPはそうでもない。だからX11Apacheディストリビューションに任せて、DHCPはバイナリもプラグインに入れる。
うーむ…。


X11Apacheはデカイからディストリビューションに入れて、DHCPは小さいからプラグインに入れる。
うーむ…。


全部ディストリビューションだ!依存関係に出しておいてユーザーに入れさせろっ!ディストリビューション間の差異はユーザーにフォローしてもらうしかないだろー
うーむ…