第26回　64ビット化への遠い道程［その4］

9月も下旬になってくると、日中の日射しはまだまだ厳しいものの、朝晩は肌寒いくらいの気温になってきました。夜もずいぶん長くなり、CPUの発熱を気にする必要もなく、じっくりと大規模なソフトウェアのビルドに取り組める季節になりました。

ふと気づくと、去年の晩秋に開始したPlamo Linuxの64ビット化の作業も、そろそろ1年近くかかっていることになります。さすがにこれ以上ずるずると開発版のまま続けていくのもマズいので、そろそろ一段落を付けるための作業に取りかかりました。

64ビット版Plamoの現状

本連載でも何度か紹介したように、Plamo Linuxの次のバージョンでは、メジャー番号を5.0に更新して、x86とx86_64の2つのアーキテクチャに対応する予定ですが、現状ではx86_64版の開発を先行して進めており、まず64ビット用のx86_64版をリリースしてから、32ビット用のx86版に注力する、という流れになりそうです。以下では、このPlamo-5.0のx86_64版（Plamo64）の現状について、前回紹介した後に追加された機能を中心に紹介してみることにします。

BtrFS対応

Linux用の次世代ファイルシステムとして期待の高い、BtrFSに対応しました。

BtrFSはLinux用に新しく開発されたファイルシステムで、二分木（B-tree）構造を積極的に採用した斬新な設計になっています。

二分木構造を採用したLinux用のファイルシステムとしては、カーネル2.4の時代に広く利用されていたReiserFSがあります。ReiserFSは、そのパフォーマンスのよさから、一時はLinux用のデフォルトファイルシステムの地位をExt2/3 FSと争う勢いでしたが、中心的な開発者だったHans Reiser氏の奇矯な言動が災いして、新しいコードがなかなかカーネルのソースコードへ採用されず、次第にユーザが少なくなり、開発が停滞してしまいました。

BtrFSの中心的な開発者であるChris Mason氏は、現在はOracleに所属していますが、かってSuSEに所属していた際にReiserFSの開発にも参加していました。彼は、ReiserFSから二分木構造のファイルシステムに関するさまざまなアイデアを得、さらにそれを業務環境で使う規模にまで拡張できるようにBtrFSを設計したそうです。

BtrFSの特色のひとつは、ファイルシステム内にサブボリュームと呼ばれる管理単位を作り、このサブボリューム単位でスナップショットが瞬時に取れることです。

サブボリュームは、ファイルシステム上ではディレクトリのように見えますが、専用のコマンド（btrfs subvolume snapshot ..）を使えば、その内容を瞬時に別のサブボリュームにコピーすることが可能です。

こういう仕組みにすることで、BtrFSではスナップショットを任意の個数作ることができ、スナップショットの中身を書き替えることも可能になっています。

BtrFSでは、この「サブボリューム」という概念が全面的に採用されており、マウント時に"subvol=..."というオプションを指定することで、サブボリュームを1つのパーティションのようにマウントすることもできます。

従来は、1つのHDD上に安定版の環境と開発版の環境を同居させるような場合、それぞれの環境ごとにあらかじめ適切な容量のパーティションを切って、パーティションごとにファイルシステムを分離してやる必要がありました。一方、BtrFSのサブボリューム機能を使えば、1つの大きなファイルシステム上に必要な数だけサブボリュームを作って、サブボリュームごとに異なる環境をインストールすることが可能になります。

HDD上にあらかじめパーティションを用意する場合、事前の見積りが甘くて、あるパーティションでは容量が足りないのに、別のパーティションでは余っている、といったことがよく起きます。一方、BtrFSでサブボリュームをパーティションのように使えば、サブボリューム全体でファイルシステムの容量内に収まればよくなるので、サブボリュームごとの容量の過不足を心配する必要が無くなります。

BtrFSのこの機能を利用するためには、インストール時にあらかじめサブボリュームを作り、そのサブボリュームをルートファイルシステムとしてマウントしてやる必要があります。そのため、Plamo64ではインストーラを修正して、BtrFSを選んだ場合は、常にサブボリュームを作った上でマウントすることにしました。

また、BtrFSではサブボリューム内に任意の数のサブボリュームを作ることも可能なので、/homeや/varのように内容がしばしば更新される部分を、インストール時にあらかじめサブボリュームとして用意しておけば、スナップショット機能を用いて、それらの部分ごとのバックアップを簡単に取ることができます。Plamo64では、そのようなニーズにも対応してみました。

BtrFSはこのように便利なファイルシステムではあるものの、現時点ではliloやgrub2といったブートローダが対応しきれていないので、BtrFSをルートファイルシステムにする場合は、カーネルの置き場所である/bootはBtrFS以外のファイルシステムを用意する必要があります。

grub2対応

Linux用の代表的なブートローダのうち、liloには当初から対応していましたが、grubも新しいシリーズ（grub2）を使えるようにしました。

grub2は、以前のgrub（grub legacyと呼ばれています）を全面的に書き直したバージョンで、内部構造やコマンド等も異なっています。そのためインストーラ側のスクリプトも全面的に書き直すことになりました。もっとも、grub2ではインストールに必要なコマンド類があらかじめ用意されているので、インストーラ側のスクリプトでは、インストールに必要な環境を整えて、コマンドを実行するだけで済みました。

ただし、現状のgrub2は“⁠grub2⁠”とは称しているものの、GNUのFTPサイトで公開されているソースコードのバージョンは1.99になっており、まだ「ベータ版」的な位置付けのようです。加えて、このバージョンでもBtrFS上のサブボリュームをルートファイルシステムにした場合を正しく認識してくれず、BtrFSと組み合わせて使うためには最新の開発版を使う必要がありました。

加えて、現在採用しているgrub2では、起動に必要なコードをHDDの先頭領域であるMBRには書き込めるものの、パーティションの先頭領域に書き込もうとするとエラーになるという問題が見つかっており、安心して使うにはもうしばらく待った方がいいかも知れません。

KDE-4.7.1

KDE環境を4.4.5から最新の4.7.1に追従してみました。その際にはQt-4.7.1をはじめ、KDE-4.7.1が必要としている各種パッケージもバージョンアップしました。

KDE-4.7.1はデフォルトの壁紙が変更されて見た目の印象こそずいぶん違いますが、設定方法や操作体系などは以前のバージョンを踏襲しつつ、細かな部分に改良が加えられ、デスクトップ環境としてさらに洗練されてきた印象を受けます。

一方、KDEを構成するソフトウェア群はさらに増加して、4.4.5では72だった関連パッケージ数が、4.7.1では112にまで増加しています。そのためHDDの使用量も増えると共に、パッケージ間の相互依存関係等も複雑になっていて、「⁠とりあえず動く」レベルでは動作しているものの、細部の調整にはもうしばらく時間がかかりそうです。

LibreOffice-3.4.3

ワープロや表計算ソフトを統合したオフィス環境を、OpenOffice.orgからLibreOfficeに変更しました。

OpenOffice.orgはさまざまな変遷を経てきたソフトウェアです。元々はStarOfficeという名でドイツのStarDivisionという企業が開発していた商用ソフトウェアでしたが、Sun Microsystems社が会社ごと買収して商用版のStarOfficeとオープンソース版のOpenOffice.orgを公開し、OSS版はソースコードを公開してボランティアの開発者を募りました。

その後、Oracle社がSun Microsystems社を買収し、OpenOffice.orgの開発を引き継ぎましたが、度重なる開発元の移動と開発方針の変更に辟易したボランティアの開発者たちは、特定の企業の影響を排するために"The Document Foundation"という独自の組織を設立し、その組織を中心としてOpenOffice.orgのフォーク版を開発し、それをLibreOfficeという名称で公開しました。

一方、Oracleも主要な開発者が抜けてしまったOpenOffice.orgプロジェクトには魅力を感じなくなったのか、"OpenOffice.org"という名称とソースコードをApache Software Foundationに寄贈して、現在ではOpenOffice.orgの開発元はApache Software Foundationになっているようです。

そのような開発元の変遷はともかく、一般ユーザレベルで見る限り、起動時の画面や各種アイコン等が変わった以外の目に見える変更はなく、従来通りのsofficeやscalcといったコマンドからオフィス環境を起動でき、当然のことながらOpenOffice.orgで作成したファイルも問題なく利用できます。

Oracleが手放したことで、将来的にはOpenOffice.orgとLibreOfficeが再度マージされる可能性も高そうですが、その際もせいぜい名称が変わるぐらいで機能や互換性に問題が生じることは無いでしょう。

Plamo64の反省

例によって例のごとくですが、今回のPlamo64の開発作業も当初の目論みからはずいぶん外れてしまいました。

当初は、64ビットCPUという新しいアーキテクチャ用に既存の32ビット用のパッケージを棚卸しし、必要最小限のパッケージを64ビット化した程度でリリースして、各種環境は最初のバージョンのリリース後に追い追い整えていくつもりでした。

しかし、思ったよりも基本パッケージの64ビット化がスムーズに進み、64ビットな環境の動作が簡単にできてしまったので、つい欲を出してあれもこれもと手を広げてしまった結果リリースがずるずると遅れ、いつの間にか初期にビルドしたパッケージには新バージョンが出ていて、それを追いかけているうちにまた別のパッケージに新バージョンが……、という悪循環に落ち込んでしまいました（苦笑）

その結果、手元ではずいぶん以前から64ビット環境を常用しているものの、公式なリリースができないままずるずると開発を続けてしまい、“⁠release early, release often⁠”というOSSの基本原則に反することになってしまいました。そのため、Plamo Linuxのコミュニティも停滞気味になり、ここ1年ほどの間にメーリングリストの流量等もずいぶん少なくなってしまったように感じます。

64ビット化にあたっては、ビルドスクリプトの調整等の細かな議論が必要だったため、メンテナ内のやりとりが多くなりがちでしたが、結果として進行状況が外部には見えづらくなって、「⁠興味ある人なら誰でも開発に参加できる」というOSSの本来のあり方からやや逸脱していたような気がします。

本稿でも紹介したように、Plamo64にはもうしばらく調整期間が必要そうですが、自己満足にならない程度に切りあげて、広く試してもらえるようにするつもりなので、興味ある方はぜひテストにご協力ください。