RedhatLinuxをインストールして数ヶ月放置しておくと、新しくダウンロードしてきたアプリ（RPM）が必要とするモジュールと、自分のマシンに入っているモジュールのバージョンが合わなくなる。

例えば、PHPで後から必要なモジュールを追加しようと思って、追加のRPMをWebから拾ってこようとすると、すでに自分が持っているPHPと対応するバージョンのRPMがなかったりする。
仕方ないので新しいPHPのRPMを拾ってきたら、すでにそれは自分のRedhatにはインストールできなくなっている。

もっともタチが悪いのがLinuxのコアモジュールであるlibcのバージョンアップが必要になることだ。これがあわないとまず正常に動くことは期待できない。

オレが入れたいのはlibcなんかじゃなくて、PHPなんだ！

新しいアプリの場合、そのアプリが依存する他のモジュールまでバージョンがあわなくなって、再帰的に入れなおさなくてはいけないRPMが増えていったりするからタチが悪い。

ここにたどり着くまでに、インストールをしようと行動を始めてから、すでに1時間以上経っている。

ダウンロードしているRPMが、たんだん目的から遠ざかっている自分に気がつき、

「Windowsでこんなことにはならない・・・」

と思わず口にする。

結局、ソースコードからコンパイルするのが一番簡単である。何故なら、今、存在するOSを前提にコンパイルするので、基本的にバージョンの不整合がでない。本気で、そのプログラムが新しいlibcなどを必要としなければ、ちゃんと動くし、本気で新しいバージョンを必要とするアプリに出会うことは稀である。

基本的なモジュール構成だけディストリビューションに従って、自分がメインで使うアプリはソースコードからコンパイルして管理するのが一番良い。当然、そういうオペレーションの知識がLinuxに必要だといえる。

こうなってしまうのは、えふしんの知識不足もあることだろう。しかし、それは認めた上で、結局のところ、それ以上の知識がないと、使えないという紛れもない事実である。結局、一つのアプリのインストールに一日かかったりする。

昔、Debianを使ったがブラックボックスであることと、依存関係のループが起きて、ワケがわからなくなったこと、最後は、よくわからない状態で、Perlまでアンインストールされてしまい、メチャメチャにされた経験から、これもまた知識が必要だということが良くわかった。

この辺、適当に扱っても、それなりに動くWindowsはスゴイと感じるところ。出張先でOSが壊れ始めた時なんかに、この曖昧さは助かるんだよね。一番、重要なのは何か？ってハナシ。

Debianの場合はマニュアルの車に乗ってオーバーレブかましてエンジンを壊したのと同じことなんだろうが、僕が欲しいのは、安全に運転ができるオートマ車だ。OSなんて意識しないでアプリケーションを使えることが重要だ。

この辺をWindowsが意識することはほとんどない。特に、Win2000以降は非常に安全だ。この辺は、Microsoftなど一社企業が、OSを管理するからこその統一性と考えるべきか。
サーバーのように一度運用を始めたら、めったにバージョンアップは考えないような環境でのLinuxの運用はベストである。特に仕事の時間で、こういう目にあうのはさほど問題にならない。仕事だから。

でも、個人で使うデスクトップのように、休日に「アプリケーション」を使いたいときには、今のままではちょっと煩雑すぎる。たまにチャレンジして、返り討ちにあって、数週間放置して、気が向いたらまたチャレンジというループを繰り替えている今日この頃。

この辺、Lindowsはどのように解決しているのか？いや、そもそも、ここは解決できてるのか？非常に興味あるところである。自動でlibcをバージョンアップするぐらいの管理はされているのだろうか？当然、それに起因するトラブルを皆嫌うだろう。しかし、これを乗り越えないと、一般に普及しうるOSにはなれない。

FedoraCoreをVaioSRX3にインストールし、無線LANを動かすためのカーネルの再構築で、モジュールのコンパイルエラーが出て先に進まなくなった状況で、途方に暮れ、はや20時間という状態での疲れた書き込み。