玩式草子─ソフトウェアとたわむれる日々

第97回そろそろ出しますPlamo-7.0

新年度が始まり、早やひと月近くが経過しました。新しい職場や学校など、環境が大きく変った方々も、多少は落ちついてきたころでしょうか。

身辺多忙等の理由で昨秋から半年近く休載していた本連載も、新年度を機に再開することになりましたので、従前通りのご愛読のほど、よろしくお願い申しあげます。

さて、連載再開の最初に取りあげるべき話題はやはり、現在、開発が最終段階に入っているPlamo Linuxの新しいバージョン(Plamo Linux 7.0)でしょう。

図1 新しく採用したLXDE環境
図1 新しく採用したLXDE環境

Plamo Linux 7.0について

Plamo Linux 7.0(Plamo-7.0)は、2017年2月に公開したPlamo-6.2以来の新リリースで、2015年に公開したPlamo-6.0以来、3年ぶりのメジャー・バージョンアップになります。

今回、Plamo-7.0の開発で目指したのは過去のしがらみからの決別です。

ご存知のように、Plamo Linuxは最古参のディストリビューションのひとつであるSlackware Linuxの日本語化を目指して始めたプロジェクトです。Plamo Linuxの開発を始めた当時は、ソフトウェアの多言語化も未熟で、そのままでは日本語を扱えないソフトウェアが多数ありました。そこで、日本語化が必要なソフトウェアはあらかじめ日本語化パッチをあてたバージョンに入れ替えると共に、インストーラも日本語化して、インストール直後から日本語環境を簡単に利用できることを目指したのがPlamo Linuxの始まりです。

当初こそSlackware Linuxのバージョンアップに追従していたものの、ユーザーの協力で日本語対応されたパッケージが集まってくるに伴ない、Slackware Linuxから分岐した独自のディストリビューションとして開発することになったのが前世紀の末ごろ、かれこれ20年ほど昔のことになります。

この20年ほどの間にLinuxを中心としたOSS環境は驚くほどの進化を遂げました。この連載でも何度か取りあげたLinuxカーネル発展の歴史は言わずもがな、ユーザー領域についてもGTKやQtといったGUIツールキットをベースに、GNOMEやKDEといった統合デスクトップ環境が開発されると共に、それらを支える文字コードやフォントも整備が進みました。

もちろんPlamo Linuxでも統合デスクトップ環境を取り入れたり、マルチメディア関連の機能を充実させたりしてきたものの、ベースとなる部分には20年前に標準だった仕様が残っており、屋上屋を架すような複雑な状態になっていました。

そのためPlamo-7.0では、それら過去のしがらみ的な部分をばっさりと整理して、現代の標準的なLinux環境に準じたスタイルに装いを改めることにしました。個々の詳細については本連載で随時紹介してゆく予定ですが、今回はイントロダクション的に大きな変更箇所を簡単に紹介してみます。

起動処理の正式なSysVinit化

最近はSysVinitよりも高速な起動処理を可能にするsystemdを採用するディストリビューションも多く、すでに周回遅れの感がありますが(苦笑⁠⁠、Plamo-7.0では起動時の処理を正式なSysVinit形式に変更しました。

もちろん、Plamo Linuxでも最初期から起動処理にはsysvinitパッケージを採用してはいたものの、お手本にしたSlackware LinuxがsysvinitでSunOSの起動処理をエミュレートするという仕様になっていたのに従って、rc.Sでシングルユーザー用の初期化処理、rc.Mでマルチユーザー用の初期化処理、rc.localでホストごとの初期化処理を行う、というスタイルを採用していました。

起動処理にrc.S/rc.M/rc.localを使うのは古いBSD UNIXに由来し、Solaris以前のSunOSが採用していた形式で、80年代にUNIXを学んだ人間には慣れ親しんだスタイルでした。しかしながら、SunOSも歴史の彼方に去った現在では、敢えてそのスタイルに固執する必然性もないため、/etc/rc.d/init.d/以下に収めた起動処理スクリプトへのシンボリックリンクをrc0.dからrc6.dまでのランレベルに応じたディレクトリに収める、という標準的なSysVinitの仕様に変更しました。

同じSysVinit形式といっても、起動処理用スクリプトはディストリビューションごとにさまざまです。どのスタイルがいいかなぁ、と検討した結果、LFS(Linux From Scratch)プロジェクトのスクリプトを採用することにしました。

このスクリプトでは処理の成功、失敗が色分けで表示されてわかりやすくなると共に、起動処理を並列化できるようになった結果、電源ONからログイン可能になるまでの時間がずいぶん短縮できました。

図2 Plamo-7.0の起動画面
図2 Plamo-7.0の起動画面

文字コードのデフォルトをUTF-8に

Plamo Linuxでは日本語を表示するための文字コードにEUC-JP(ja_JP.eucJP)を用いてきました。EUC-JPはExtend Unix Code for JaPaneseという名前が示すように、UNIX用に考案された日本語の表示方式で、1980年代からUNIXワークステーションで広く利用されてきました。

EUC-JPは日本語1文字を2バイトで表すと共に、最初のビットが立っているか否かでASCIIコードと区別できるように工夫されており、英語にしか対応していないソフトウェアでも、比較的簡単な改造で日本語メッセージを表示することができました。

Plamo Linuxはそれら日本語化されたソフトウェアを積極的に採用し、AfterStep ClassicやQvwmといった日本語に対応したウィンドウマネージャを使って、X Window System上で自由に日本語を使える環境を他に先駆けて提供していました。

しかしながら、インターネットが普及して世界中で同じソフトウェアが使われるようになるにつれ、英語と日本語にしか対応できない日本語化はむしろ不便で、はじめから世界各地の言語に対応した多言語化が求められるようになりました。そこで採用されたのが、存在する全ての文字を整理しようというUnicodeの規格と、それを効率よく表現するためのUTF-8という符号化方式です。

元々、Unicode/UTF-8は多言語化に対応したソフトウェアの内部表現形式として利用されていましたが、次第に画面表示やファイルシステムに保存する際のファイル名にも使われるようになり、新しく開発されたソフトウェアではたいていUTF-8がデフォルトの文字コードになっています。

そのような状況を鑑み、Plamo-7.0ではデフォルトの文字コードをUTF-8(ja_JP.UTF-8)に変更しました。もっとも、glibcのロケールデータを追加するなど、UTF-8を使うための環境整備は以前から進めており、普通に使っている範囲ではほとんど違いには気づかないと思います。

しかしながら、EUC-JPを前提にした古い「日本語化」ソフトウェアはUTF-8環境では正しく動かないため、この機会にまとめて削除することにしました。具体的にはPlamo-6.2の03_xclassicsカテゴリに入っていた、afterstep classicやqvwm、tgif, emiclock等のソフトウェアは、Plamo-7.0では採用されていません。

ビットマップフォントの廃止

元々X Window Systemでは、画面に表示する文字はドットで構成されたビットマップフォントを前提にしていました。しかし、ビットマップフォントは拡大/縮小するとギザギザが目立って見苦しくなるので、Sunの開発したNeWSのような後発のウィンドウシステムでは、拡大/縮小してもアラが目立たないベクターフォント(TrueTypeフォント)を使うようになりました。

この仕組みはfreetypeと呼ばれるフォントエンジンを用いてXにも輸入され、最近のX用のソフトウェアはほぼ全てfontconfigとfreetype経由でTrueTypeフォントを使うようになっています。

白黒のドットから構成されるビットマップフォントに比べて、ベジェ曲線で曲り方を指定するTrueTypeフォントは作成が面倒なものの、FontForgeといった作成ツールが開発されたり、情報処理推進機構(IPA)が開発してフリーで公開したIPAフォントやGoogle/Adobeが開発したNotoフォントなど、高品質でフリーな日本語TrueTypeフォントも整備されてきたので、Plamo-7.0ではビットマップフォントを廃し,TrueTypeフォントのみを使うようにしました。

図3 Notoフォントの表示例
図3 Notoフォントの表示例

この結果、TrueTypeフォントに対応していないソフトウェアは動作しなくなるものの、それらはUTF-8環境では動作しない、前述のX用の古いソフトウェアと重複するようです。

とりあえず64ビット版のみ

最近のx86系CPUはたいていx86_64アーキテクチャを採用した64ビット版になっており、わざわざ32ビット版の開発環境を用意するのも面倒なので、Plamo-7.0ではx86_64版のみを開発しています。そのため、ライブラリを32ビット版と住みわける必要が無くなり、Plamo-6.xで採用していた/lib64や/usr/lib64等のライブラリ名を廃し、/libや/usr/libに戻しました。

もっとも「x86_64にしか対応しない」というのは単純にメンテナのリソース不足というレベルの問題なので、将来的にはPlamo-6.xのように32ビット版やARM版のPlamo-7.xが公開されるかも知れません。

ビルドスクリプトの標準化

Plamo Linuxのパッケージを作成するためのスクリプトは、"PlamoBuild.foobar-x.y.z"というファイル名のシェルスクリプトで、/usr/share/docs/foobar-x.y.z/ディレクトリに収められています。

Plamo-6.xまでは、それぞれのメンテナが自分好みのスタイルでビルドスクリプトを作っていたものの、メンテナ以外の一般ユーザーがビルドスクリプトをチェックする際には、ある程度スクリプトのスタイルを統一した方が分かりやすいだろうと考え、Plamo-7.0では汎用的な処理を外部に括りだすことでビルドスクリプトを単純化、標準化することにしました。

このあたりの詳細も改めて本連載で紹介する予定ですが、Plamo-7.0の環境では展開済みのソースコードに対してmake_PlamoBuild.pyを実行すれば、そのコードに応じたビルドスクリプトが作成でき、たいていの場合、そのままバイナリパッケージを作ることができます。

このように作成したバイナリパッケージはPlamo Linuxのパッケージ管理ツールであるinstallpkg/removepkg/updatepkgで簡単にインストール/アンインストールできるので、DVDイメージ等には含まれていないパッケージをユーザーが自由に追加して、Plamo Linuxを自分用にカスタマイズすることも簡単になったと思っています。こうして作成した「自分用パッケージ」を提供いただくことで、メンテナの裾野が広がることを現在のメンテナ一同、期待しています(苦笑⁠⁠。


今回は簡単な概要紹介でしたが、Plamo-7.0は/usr/lib64を廃したことなどに伴い、全てのパッケージをビルドし直した全く新しいPlamo Linuxです。しかしながら、Plamo Linuxの特徴である見通しのよさやイジり易さは従来同様、あるいは古い設定を整理した分、よりわかりやすくなったと思っています。

「変らないために、変り続ける」というのは使い古された言葉なものの、ディストリビューションの世界にも通用する名言でしょう。

おすすめ記事

記事・ニュース一覧