| エンタープライズ：レビュー | 2003/11/22 08:19:00 更新 |
レビュー：Red Hatからオープンソースに回帰した「Fedora Core 1」 (2/2)
CPUクロックのスロットリングも見てみよう。
|
# insmod p4-clockmod
Using /lib/modules/2.4.22-1.2115.nptl/kernel/arch/i386/kernel/p4-clockmod.o # cat /proc/cpufreq minimum CPU frequency - maximum CPU frequency - policy CPU 0 212989 kHz ( 12 %) - 1703917 kHz (100 %) - performance |
上記のように、対応するCPUやチップセットのモジュール組み込みで可能になる。この例ではCPUクロックを12（213MHz）〜100％（1701MHz）の間で可変することになる。リリースノートに記載されているCPUは、Pentium4、Centrino、K6、K7などだ。この機能もモジュールで組み込み、ブートオプションであらかじめ指定できる。また、これとは別に「ラップトップモード」も組み込まれた。アイドル時にハードディスクの電源を切るなどしてバッテリーを節約する機能だ。APMモードはノートパソコンへのインストール時に自動で組み込まれる。
しかし、ACPIへの対応はまだ問題が残っているというのが実情のようだ。リリースノートに「early stage development」と明記されたように、マザーボードやチップセットの違いで正常に動作しないことも少なくなかった。ACPIの安定した動作は、カーネル2.6採用予定の次期バージョンに期待した方がよいだろう。
システムコードUTF-8への変更は各ソフトの対応状況が関わってくる
そして日本語や中国語など、マルチバイトを扱う言語文字コードはUTF-8（Unicode）が標準設定となっている。そのため対応が不完全なターミナル「Kterm」などの標準設定では表示、及びメニューがコード化けを起こしている（gnometerminalやKonsoleでは正しく表示される）。ほかにも不完全な面が際だつ場合には従来までのEUCに変更することを強いられるだろう。
日本語入力システムとして従来までのATOK Xをインストールした場合、動作させるまで多少のコツが必要となるが、市販のRed Hat Linux 9に付属するWnn7はそのままでインストールすることができ、動作をした。
このようにFedora Core 1では、目立たない部分でのパッケージの入れ替えが見られる。これはRed Hat Enterprise Linuxでの厳選したパッケージ体系と一致する一方、新たな風を取り入れている証かもしれない。CD換算3枚のセットアップを行ったフルインストール時には、5Gバイト以上のディスク容量を要する。このパッケージ数が、Fedora Core 1のひとつの「カギ」でもある。
アップデートマネージャにはaptとyumを採用
Red Hatは、これまでup2dateコマンドやRed Hat Networkサービスを介したパッケージ提供をしてきた。しかし、それがオープンソースすべてのツールではないことは明らかだ。例えばRPMアーカイブとしても知られる「freshmeat」（http://freshmeat.net/）には、ひとつのカテゴリに数百〜数千の開発プロジェクトがある。これをディストリビューションが収録パッケージとして検証していくのは現実的ではない。それに、パッケージ間の依存関係確認も立ちはだかる。しかしFedora Core 1は、この「困難なパッケージ管理」への挑戦も担う。
また、大きな点としてFedora CoreではDebian/GNU Linuxのパッケージ管理「apt」と、Linux@Dukeのパッケージ管理「yum」をサポートした。yumはRPMベースに別のアプローチを行ったパッケージマネージャだが、aptのdebパッケージはRPMパッケージとは異質のものだ。Red Hat Linux本来のRPM（rpmやup2dateコマンド利用）、apt、yum。これらをマージすることで、ユーザーが必要とするパッケージ取得と管理を容易にする目論見だ。aptそのものは標準インストールパッケージとしては含まれないが、「Fedora Project」のHowToとしてRPMパッケージと利用方法が記載されている。
この3種のパッケージマネージャをFedora Coreは混載し、「与えられるだけ」だったRed Hat Linuxのパッケージハンドリングを改革したといえる。
とりわけaptの存在は大きいだろう。一方、Red Hat Linuxのパッケージ種別分類は、aptに比較すればかなりあいまいであり、ユーザーから見た規模も小さい。Red Hatが用意してきた実際のパッケージ数は決して少なくないが、管理画面でユーザーに見せるパッケージは意識的に減らす傾向にある。逆に、本来のDebian aptは非常に多彩であり、Red Hatが提供していないパッケージも数多く含まれる。それだけに膨大なパッケージが表示され、その目的や用途を把握できなければ混乱するのも事実だ。Fedora Coreは、この両者のバランスを取ろうとしている。aptはup2dateよりも詳細で、しかもaptよりも分かりやすいパッケージ管理だ。コンソールでも機能するが「Synaptic」というGUIフロントエンドも用意される。
標準のaptはFedora Coreツリー内を参照し、「現時点での」パッケージ数はさほど多くない。up2dateも標準では従来のRed Hat Linux本来のヘッダを参照しにいってしまいエラーを表示するが、参照先をFedora Core本来のものへ変更すればチャンネルとして取得できる。
Fedora Coreの「枠」を越えてより多くのパッケージを望むならば、参照ターゲットを広げ、巨大なリポジトリを得ることも可能だ。ただし、Fedora Core外のソースは「自分でビルドする」ことが前提である。
ここでユーザーはふるいにかけられる。そのいちばんの理由は、この「Fedora Core 1」というディストリビューションが、現時点では「Stable」（安定版）ではないことだ。
Red Hat Linux 9をフルアップデートした段階のgccバージョンは3.2.2-5だが、Fedora Core 1が採用したgccは「3.3.2-1」である。そしてロードされるモジュール類の「VM Mapping」は、セキュリティを高めるために「Exec-shield」という呼ばれる機能でランダマイズされた。これに対処できないとビルドは最適化されないか、動作しない場合もある。今までのRed Hat Linuxと同じつもりでソースをビルドしたり、カーネルに手を加えようとすると失敗するケースが多いのだ。筆者が試したところ、ビルドし直したパッケージがセグメントエラーを返すことも多かった。
X上メニュー内にはRed Hat Linux 9から引き継がれた「アプリケーションの追加と削除」（redhat-package-configのGUIフロントエンド）も残ってはいるものの、インストール完了後は機能しないといった状態だ。つまり、インストールした後はaptやyum前提でメンテナンスしていくしかないことを意味する（up2dateコマンドの今後は未定になっている）。
現Fedora Projectの役割は、これまでRed Hat Linuxをより安定させることだった。だからこそカーネルや既存のパッケージにも着手し、今までの方法では上手くビルドできない（「できなくなってしまった」という方が正確かもしれない）。これをユーザーが自力で解決できるかどうかでFedora Coreへの評価が異なってくるだろう。そう、ソースがある程度読み解ける層であればFedora Coreの性格を歓迎するかもしれない。世界中の膨大なパッケージソースを、今までのRed Hat Linuxよりもずっと簡単に取得できるのだから。
一方で、ビギナーにとってのFedora Coreはどうか。名称が「Red Hat LinuxからFedora Coreに変わっただけ」と割り切れるならば、それほど心配する必要はない。今後、Fedroraコミュニティの中で依存関係と安定性を充分に検証されたパッケージが少しずつ提供されていくだろう。あくまでも体感的な目安だが、同一環境にインストールしたRed Hat Linux 9よりもFedora Core 1は動作の軽快感がある。Fedora Core 1がチューニングされているという成果のひとつだろう。だが、Fedoraが目指すもうひとつのメリットを享受するのは難しい。
オープンソースに回帰したディストリビューション
もし「扱いやすさ」や「平易な自由度」を優先したいなら、筆者はビギナーに現段階での「Fedora Core 1」をおすすめしない。しかし、「教材」としては格好であると思う。おとなしく扱う限り従順だが、本来の能力を引き出そうとすればじゃじゃ馬に豹変するからだ。ビギナーがLinuxの参考書を片手にFedora Core 1を手なずけるのは少々酷であるとも思う。だが、挑戦するだけの価値もあるだろう。aptが加わったことで、Fedora Coreは「Red Hat Linux＋Debian GNU/Linuxではないのか？」という声も聞こえる。現実的な視点からすればそういえるかもしれない。
しかし、筆者からすれば「オープンソース」本来の思想を想起する、すべてのユーザーが自由に利用できる公開されたプログラム。それは本来、UNIX系OSで共有できるはずだったものだ。しかし、簡便に扱うためにコンパイル済みのバイナリパッケージマネージメントが主流となり、ディストリビューション、果てはバージョンの間にさえ「垣根」ができてしまった。Fedora Coreはこの「垣根」を越え、再びオープンソースのディストリビューションを再構築しようとしているともいえる。
オープンソースは直接の利益を生みにくい。しかし、開発資金がなければ発展も遅延するのも事実なのだ。Red Hatの今後のパブリックなエディション（Red Hat Enterprise Linux）は、12〜18カ月のスパンでゆっくりと進み、Red Hat QA、ISV/HIVパートナーの元で検証されたパッケージを厳選する。そして最低5年間はサポートされる予定だ。対するFedora Coreは、4〜6カ月のリリースサイクルで更新され、サポートも次期リリース後2〜3カ月で打ち切られる。大規模なサーバシステムが半年のサイクルで更新され、サポートも3カ月しかないとなったら、アップデートサービスに期待するシステム管理者は頭を悩ますだろう。Red HatとFedora Coreの関係は、はっきりと区別されたのだ。
Fedora ProjectのFAQにはこんな一文がある。
「Can I redistribute The Fedora Project?」
「Yes,and we strongly encourage you do so.」
利益を生み出すRed Hatのスポンサーを受けたFedora Core開発は、かつてよりも急速に進んでいくだろう。
関連記事
Red Hatの年間契約、9割が更新Red Hatが無償版Linux開発を中止、企業版に専念関連リンク
Fedora ProjectRed HatレッドハットLinux チャンネル[渡辺裕一，ITmedia]
