メインマシンである T41 は Windows XP と TurboLinux 10F の Dual Boot 構成で使用していました。もっとも、Windows を起動するのは、どうしても Windows でしか動作しないアプリケーションを使う場合くらいで、通常の作業はほとんどが TurboLinux 上でまかなえていました。メインの環境を切り替えるときには、いろいろと困難もありましたが、その経験の蓄積のたまものか、今ではほとんど問題を生じることもなく、ある程度は快適に使えるようになりました。
歯切れの悪い書き方をしたことには、きちんと理由があります。TurboLinux 10F を使っていて、いくつかの改善しがたい不満がありました。
1. は本当につらいものがありました。自宅で無線 LAN を利用しているのですが、出先で使おうとすうると、ハングアップしたかのように、非常にレスポンスが悪くなります。最初は、なぜそうなるのかわかりませんでしたが、しばらく使用していると、ネットワークを無効にしている場合には、そのような状態が発生しないことに気づきました。
ふと思い、有線 LAN を有効にして、LAN ケーブルを接続していない状態にしてみたところ、同じ状況を再現することに成功してしまいました。これは、かなりのダメージとなりました。なにせ、出先で立ち上げるたびに、terminal から、ifdown コマンドを打って、ネットワークデバイスを無効化しなければならないわけですが、その Terminal が開くまでにも、かなりの時間がかかってしまう状態なので、本来の作業を行う前に、シャットダウンが必要になってしまうことも、少なくありませんでした。
やむを得ず、デフォルトをネットワーク無効にしておき、起動後に手動でネットワークを有効にする、という方法をとっていました。しかし、うっかりネットワークを有効にする前に、ブラウザを開いたり、メーラーを立ち上げたり、という操作を行って、「なんでつながらない〜〜〜(*_*)」と困惑することもしばしばありました（苦笑）。
すべてのディストリビューションで同じ症状が発生しているのであれば、やむを得ないとも考えられるのですが、他のマシンに入れていた Vine Linux では発生しないことから、TurboLinux 10F 固有の問題と考えました。なぜなのか、原因は今でもつかめていません。
2.についてですが、GTK2.0 の未サポートは、ある意味やむを得ないと思います。TurboLinux は、KDE を主体としているため、GTK1.0 のサポートがあるだけでも、十分と考えているのかもしれません。しかし、世の中に GTK2.0 を求めるアプリケーションが多くなってくると、GTK1.0 ではいろいろと障害が生じてきます。これにちては、TL10S が GTK2.0 をサポートしていることから、FTP サーバーより SRC.RPM を入手し、rebuild したパッケージを導入して、GTK2.0 Ready な環境を構築して対応していました。このことにより、TurboUpdate を実行する際に、GTK の更新をはずさなければならない、という運用上の留意点が発生しました。
ディストリビュータとすれば、GTK のような主要コンポーネントを入れ替えることは、ディストリビューションのメジャーバージョンアップで行うということなのでしょうが、ユーザーとしては、それを待っているわけにはいきませんでした。
3. のハイバネーションのサポートは、Note PC で使っていると、致命的です。ただ、OS としてはサポートしていたようで、後ほど、自作のスクリプトにて、ハイバネーションは可能になりました。ただ、Vine Linux などがディストリビューションとしてハイバネーションをサポートしていたのに比較すると、見劣りすることも事実でした。ハイバネーションをサポートしていない理由の一つに、KDE 3.1.5 であることも影響しているのではないか、と感じたほどです。
4. の KDE 3.1.5 どまりは、実際のところ、前述したハイバネーションのサポートがない理由の一つ、と考えてしまっていたのが大きな部分でした。機能として、KDE 3.1.5 で足りないものがあったというよりも、セキュリティフィックスがなされないままになっている、ということに、大きな不安を感じていました。GTK 同様に、TL11 用のパッケージを FTP サイトから見つけてはいたのですが、依存関係が複雑になっており、そうそう簡単に入れ替えすることもできない状態でした。どちらかというと、KDE をすっかり０から構築することに匹敵するような状態であるため、インストールの順番や make の順番なども、重要になってくるものと思われるので、少々手に余る内容だなあ、と感じていました。
5. Gnome のサポート外、というのは、KDE を主体としている TurboLinux にとっては、必然ともいえるものでした。ただ、常用アプリである Firefox と Sylpheed という２大 GTK アプリケーションを使う上では、なかなか障害になりました。どのような障害かというと、Gnome-control-center で設定したフォント設定が、OS 起動後に反映されず、手動で Gnome-contorol-center を起動する必要がある、というものでした。konqerer と KMail にすれば、このような問題もなくなるのでしょうが、先に使ってしまったため、今から別のものにするという選択肢は、現実解にはなりませんでした。
とはいえ、TurboLinux FUJI が登場したことから、TurboLinux 10F の更新は難しくなっているので、FUJI にいくか、他のディストリビューションに移るか、頭の痛い問題となりました。しかし、TurboLinux 10F を選択した最大のメリットである PowerDVD のサポートは FUJI では遅れていることから、FUJI を選択する意味は非常に薄い、という判断となり、ディストリビューションの変更を選択する結果となりました。
世にはいろいろなディストリビューションがありますが、この選択は、実のところ非常に簡単でした。TurboLinux 以外で使用頻度の高いディストリビューションは、Vine Linux でしたので、kernel 2.6 を搭載した Vine Linux 4.1 を選択することになったのは、非常に自然な流れでした。ただ、本来望んでいた Vine Linux 4.1CR の入手ができずに、Vine Linux 4.1 FTP 版を使うこととなりました。
Vine Linux 4.1 を選択する時に、不安がなかったわけではありません。Turbo Linux 10F を選択したメリットは下記のものがありました。
1. については、ATOK for Linux を別に入手していたので、OS 側で持っていない場合でも、あまり問題にはなりませんでした。SCIM + Anthy という組み合わせも、結構実用的に使えるのですが、やはりメインでは ATOK を使いたい、という思いがありました。
2. については、4.1CR を求めた最大の理由ではありました。ただ、4.0 から IPA フォントも搭載されるようになり、以前のようにフォント関係が気に入らない、ということはなくなっていました。それでも、実際のセッティングには、数日を要したほどなので、やはり、ここは好みの部分が非常に大きい用に感じています。
3. については、かなり大きな問題でした。Turbo Linux 以外で、商用の DVD デコーダソフトは市場には登場せず、他のディストリビューションを選択することは、PowerDVD との決別に他なりませんでした。ただ、xine や MPlayer といったオンラインツールなどで、DVD 閲覧が可能になってきている話を多く耳にしたことから、このあたりは何とかなるだろう、という結構あっさりした考えでいました。正直 Linux 上で DVD 閲覧を行う機会は激減していたので、最悪の場合には、Dual Boot の Windows からみればいいだろう、という気持ちもありました。
ということで、機は熟していた、のですね（笑）。
Vine Linux 4.1 のインストールといっても、特別なことは、何もありません。ThinkPad は、比較的素直にインストールできるマシンのため、CD Boot さえできれば、後はすいすいとインストールが進みます。とはいっても、何も考えないでインストールするのは、ちょっと問題ですね。
最大の問題にして、最初の問題ともいえるものが、これです。Windows と異なり、Linux では、Root（ルート：根）から始まる単一のツリーにすべてのデバイスがぶら下がります。Windows では、ドライブ単位にツリーが構成されるのですが、Linux ではこのツリーが単一のものである、というところが異なります。それでは、パーティションはどのように使われるのでしょうか？
Linux においては、パーティションをツリーのどこに接続するか、ということをユーザーが設定することができます。ツリーに接続することを mount（マウント）と呼びますが、この mount をすることで、各パーティションを mount したディレクトリ（これをマウントポイントと呼びます。）名でアクセスすることができます。
パーティションを分割するメリットはなにでしょうか？これは使い方によって異なるのですが、ディレクトリ毎に使用容量を制限したい、ということにつきるといえます。これは、実際には使ってみないと感覚をつかみにくいところですが、ある程度使用していると、一度は経験したことがあると思います。
過去にやってしまったミスとしては、ログファイルの容量増加によって、パーティションの空き容量が枯渇してしまい、OS を起動不能としてしまった、ということがあります。これは、Linux に限った話ではなく、Windows でもありえる話です。C ドライブの空き容量が 100MB を切って、OS が不安定になった経験がある人も少なくないと思います。（もっとも、Windows が不安定になるのは、メモリなどの要因もありますが．．．．．）
バックアップを考える場合にも、パーティションを分けておくメリットはあります。フルバックアップを行う場合には、パーティション単位にバックアップを行うことになりますが、単一のパーティションとしていると、バックアップに必要な容量が大きくなり、作業に時間を要することになります。反面、どのパーティションのバックアップなのか、をきちんと把握していないと、リストア（復元）する場合に、とんでもないことになってしますので、このあたりは注意が必要です。
以前は、ブートローダである LILO が、大容量 HDD を使用している場合に、kernel を読み込めなくなる、という制限がありました。このため、起動用のファイルがたくさん収納されている /boot も分割しておくことが望ましい状況がありました。しかし、LILO のバージョンアップにより、この制限も解消され、好みの問題ということになっています（笑）。
いろいろと悩んだ結果、選択した結果は、次のとおりとなりました。
/vm という見慣れないマウントポイントがあるのは、VMware Server の仮想マシン用の専用区画を設けているためです。最近の OS は肥大化しているため、ディスクの使用容量がかなり大きく、システムの安定稼働に影響を与えるおそれがあるため、専用区画としています。/var には、多めの割り当てとしています。これは。/var には、ログはもちろんですが、apt のキャッシュフォルダ（apt-get install などでダウンロードしたファイル群）もあるため、容量を多めにしています。
このほかに、Windows XP 用に１区画を確保していますので、全体としては、５区画となっています。120GB の容量も、動画さえ扱わなければ、結構十分な容量といえます。ちょっと大判振る舞いになっているような気も、市内ではありませんが（笑）
インストールプロセスはもちろんですが、起動時のランレベルをどうするか、ということも、重要な問題です。先に述べたとおり、TurboLinux 10F... においては、物理的なネットワーク接続ができていない状態で、ネットワークデバイスが有効になっている場合に、ウインドウのレスポンスが大幅に悪化する、という問題がありました。このため、一時的には、ランレベル３の CUI 起動を使用していました（その後、ネットワークを手動で有効にして、ランレベル５の起動に戻しました）。本質的には、X なしでは使用環境とならない、軟弱者ですので、ランレベル５が望ましいこととなります。他のマシンで、ランレベル５で特に問題なく使用できていたので、あっさりとグラフィカルログインを選択しました。
悩み始めると、結構はまりやすいところではあります。まあ、悩むかどうかは、本人次第ではありますが（笑）。基本的には、サーバーしてのインストールかクライアントとしてのインストールか、によって決定できます。サーバーとして使用する場合は、基本コンポーネントのみとして、必要なパッケージを個別にインストールすべきですが、クライアントの場合は、すべてをインストールしてもそう問題にはなりません。ただ、あまりたくさんのパッケージを導入してしまうと、全体的な動作が緩慢になることもありますので、そのあたりは微妙です。
今回は、フルパッケージを選択しています。最大の理由は、導入するマシンが Note PC であり、常にネットワークが利用できるわけではない、ということにつきます。必要になってからインストールするといっても、常に CD-R を持ち歩くわけにはいきませんので、用意されているパッケージは一括して導入しています。
Vine Linux は 3.x のあたりから、必要最低限の開発環境以外のパッケージを CD-ROM 収録からはずしています。これは、CD-ROM 容量に収まらなくなってきているためです。今回の場合、PacketiX の make など、開発環境は必須なので、関連パッケージを次のコマンドで導入しています。
# apt-get script install-devel.lua
基本的には、Vine Linux 謹製のパッケージを使用していますが、一部のパッケージは配布元のオリジナルパッケージを使っているものもあります。
早速、ATOK for Linux を導入しました。基本的に、専用ユーティリティが用意されていますので、インストールに問題はないかと思いきや、そのままではセットアップが完了しません。 gtk.immodules というファイルがありますが、ATOK のセットアップは、このファイルが /etc/tk-2.0 にあるものとして動作しようとするのですが、Vine Linux 4.1 では /etc/gtk-2.0/i386 に移動しているため、『ファイルが見つからない』エラーが発生してしまいます。そこで、ATOK のセットアップが想定している場所に、ソフトウェアリンクを作成します。
# ln -s /etc/gtk-2.0/i386/gtk.immodules /etc/gtk-2.0
この後に、ATOK for Linux の CD-ROM をドライブに挿入し、セットアップを実行することになります。インストールした場合に、特に指定をしていなければ、GNOME で起動してきていますので、automount により、CD-ROM ドライブをセットすると、自動的に mount されます。ここで、ちょっとだけとまどったことがあります。かつては、一般的なマウントポイントは、/mnt だったのですが、kernel 2.6 の途中から、/media に変わっていました。このことで、セットアップコマンドをたたいた時に、Fiel not found のメッセージを表示させてしまいました。
インストールに関する手順そのものは、添付のインストールガイドのとおりで、問題なく行えます。ATOK 本体以外にも、いくつかのパッケージを導入する必要があるようで、直接 ATOK 本体を rpm -ivh にてインストールしただけでは使用できませんでした。
インストール後、使用する一般ユーザーでログインし、setime コマンドで、atok を指定することで、標準として使用する IM に ATOK が利用できるようになります。
$ setime atokx2
atokx と atok では、atok の方が新しいパッケージなので、注意してください。
これで ATOK for Linux が利用可能になりますが、ちょっとだけ不具合があります。それは、環境設定のユーティリティが動作しないということです。何が悪いのか、しばらくわからなかったのですが、JUSTSYSTEM からアップデートがでていることを、先ほど（苦笑）知りました。JUSTSYSTEM のドキュメントの通り行ったところ、環境設定が正しく起動するようになりました。
VL ゴシックの標準搭載により、かなりフォント環境が改善された Vine Linux 4.1 ですが、明朝体を好む私には、ちょっと嫌な感じです。そこで、明朝体フォントを含むフォントセットとして IPA フォントを導入します。Vine Linux には IPA フォントが用意されているので、apt でインストールができます。
# apt-get install TrueType-ipafont
インストールした IPA 明朝フォントをデスクトップのフォントとして使うためには、GNOME Control Center でフォントの設定を行うことが必要となります。GNOME Control Center を起動し、『デスクトップの設定』→『フォントの設定』で、それぞれ使うフォントを設定します。下記が我が家の設定です。
アプリケーション IPAPMincho 9 ドキュメント IPAMincho 9 デスクトップ IPAPMincho 9 ウインドウのタイトル IPAPMincho Bold 9 固定幅のフォント IPAMincho 9
IPA フォントが導入されたことで、FTP 版でも Windows に匹敵するデスクトップ環境となりました。
Vine Linux を GNOME で使用すると、デフォルトのメーラーは Sylpheed が入ってきます。ただ、2.4 系が登場していたので、配布元 のパッケージを rebuild したものを導入しています。Sylpheed は tarball による配布ですが、spec ファイルが同梱されているので、rpm -tb で rpm ファイルを作成することが可能となっています。
$ rpm -tb sylpheed-2.4.0beta7.ta.gz
一般ユーザーで rpm ファイルが構築されていますので、root になり、rpm -Uvh にて、パッケージを更新しました。
# rpm -Uvh /home/hoge/rpm/RPMS/i386/sylpheed-2.4.0beta7-1.i386.rpm (hoge にはログイン時のユーザー名が入ります）
Linux 用の Flash プラグインは長らく 7 止まりでしたが、Adobe より version 9 が登場しました。Web 上で version 8 を要求するページが数多く、Linux からの閲覧が制限されていたものが、改善の兆しの第一歩になりました。
Adobe のサイトから、rpm ファイルを入手し、rpm -ivh でインストールすることで、Flash 9 for Linux が導入され、Bon Echo からも認識されます。インストール後に、Flash 8 以上を要求するサイトで、正しく表示されることを確認します。
# rpm -ivh flash-plugin-9.0.31.0-release.i386.rpm
xine は、Linux 用のマルチメディアプレイヤーの一つです。Vine Liunx 4.1 では totem-xine というパッケージが用意されていますが、これを導入しただけでは、市販の DVD Video を再生することはできません。これは、市販の DVD Video に CSS という暗号化処理がかけられているためで、これを復号化しないと、映像情報にはなりません。これには、libdvdcss というパッケージを導入する必要があります。
libdvdcss は、http://download.videolan.org/pub/libdvdcss/ から入手します。最新は 1.2.9 (2005/07/11)です。libdvdcss-1.2.9-1.src.rpm を入手し、Rebuild します。libdvdcss-1.2.9-1.i386.rpm パッケージを使わない理由は、パッケージ作成環境の差により、依存関係が障害となるおそれがあるためです。Vine Linux 4.1 では、libdvdcss-1.2.9-1.src.rpm はそのままで Rebuild できます。
$ rpm --rebuild libdvdcss-1.2.9-1.src.rpm
これで市販 DVD が再生されるはずだったのですが、Totem-xine を起動したときには、DVD Video がなぜか mount できませんでした。これでは本末転倒なので、本家の xine を導入することにしました。
Vine Linux には、xine パッケージがなかったので、何とかして、パッケージを入手する必要がありました。xine の一時配布元には、tarball ばかりでしたが、幸い、シノバーさんの Web サイトにおいて、xine の導入方法が述べられていたので、その内容を参考に、xine を導入することにしました。xine-ui パッケージも、公式サイトでは tarball しかないのですが、シノバーさんの web サイトで、xine-ui-0.99.4.nosrc.rpm が配布されているため、公式の tarball から、xine-ui の rpm を作成することができます。 配布されている xine-ui-0.99.4.tar.gz を ~/rpm/RPMS/SOURCES/ にコピーして、rpm -rebuild コマンドを実行すると、xine-ui-0.99.4.tar.gz と xine-ui-0.99.4.nosrc.rpm から、xine-ui-0.99.4.i386.rpm が生成されます。
$ cp xine-ui-0.99.4.nosrc.rpm rpm/SOURCES/ $ rpm --rebuild xine-ui-0.99.4.nosrc.rpm $ ls rpm/RPMS/i386/xine-ui-0.99.4-0.6.i386.rpm rpm/RPMS/i386/xine-ui-0.99.4-0.6.i386.rpm
生成された xine-ui を rpm -ivh で導入します。なお、rpm -ivh を使用するには、root 権限が必要となります。
# rpm -ivh /home/hoge/rpm/RPMS/i386/xine-ui-0.99.4-0.6.i386.rpm
gnome 端末上で、xine と入力すると、xine を起動させることができます。xine を導入したところ、無事、市販 DVD Video の再生ができるようになりました。なお、xine 導入後、なぜか Totem-xine においても、DVD Video の閲覧が可能となり、xine を導入すべきだったのかどうか、疑問が残ります。まあ、動けばよし！ということにしています。
シノバーさんの Web サイトにて、Windows で使われている codec の Linux 対応版があることを知り、さっそく、導入しました。このおかげで、多くの資産のある DivX ファイルおよび WMV ファイルが、Linux 上で再生できるようになりました。これは非常に快適で、マルチメディア系は Linux ではつらい、と考えていた私には、目から鱗状態でした。サブマシンの T21 (P3/850MHz) でも、さくさくと表示ができ、GHz 未満マシンの新たな活用法が見つかりました。GHz 未満のマシンは、安価に入手ができるので、S-Out 付きの ThinkPad を入手して、実家の Link Player もどきとして使うのも、良い手だな、と感じています。この目的のために、ワイヤレスキーボード＆マウスを入手していたりするので、後は、肝心のマシンを入手するだけ、となっています。（笑）
お遊び半分、というところですが、実は真面目な用途もあったりします（笑）。VMware はちょっと変わったインストールとなります。配布されている rpm は完全な make 済みバイナリではなく、中間ファイルとなっており、インストール後に、vmware-config.pl という PERL スクリプトにより、設定がなされ、実行形式の make がなされます。これは、VMware が kernel と密接に連携して行動する必要があるため、コンパイル済みバイナリでは、無数にあるディストリビューションへの対応が難しいため、と思われます。この make 中には、kernel source も参照するのですが、kernel のバージョンと kernel source のバージョン表記が異なる TurboLinux への対応には手こずったようで、VMware の中のとあるファイルには、Turbo Linux への恨み言が書いてあったりします。反面、これが原因で、TurboLinux 10 において、最新 kernel を導入していると、vmware-config.pl スクリプトが誤認してしまい、ツール類の make に失敗するということが発生します。
開発環境をすべて導入しているため、単に vmeare-config.pl を実行するだけで、make はすいすいすすみました。Pentium-M の高速性を、久方ぶりに体感しました。
Vine Linux 4.1 はデフォルトが GNOME 環境となっています。しかし TurboLinux で KDE になれてしまっている身としては、Vine Linux でも KDE が使いたい、と考えていました。KDE のパッケージそのものは、Vine Linux のツリーに用意されているため、apt にて、簡単にインストールすることができます。
# apt-get install task-kde
後は、ネットワークのスループットに依存するだけの話（苦笑）で、しばらく待つと、KDE が無事起動してきました。実のところ、せっかく入れた KDE ですが、ほとんど使用していません（汗っ！！）というのも、主となるアプリケーションが Firefox と Sypheed という、GTK アプリケーションであるため、KDE 上から使う場合に、gnome-contorol-center を一度起動させないと、GTK のフォント設定がなされない、という状態に陥っているためです。以前、X21 上で、Vine Linux を使用していた時には、そういうことはなかったように思っていたのですが、T41 上の Vine Linux 4.1 では発生してしまうため、現在は GNOME をメインで使用しています。
唯一使っている Qt アプリケーション、と言い切って良い状態です（爆）。GTK にも、X-CD-Roast という CD Writing Soft は存在しているのですが、CD イメージの読み込み先を事前に設定した一カ所のみという状態のため、非常に使いにくく感じます。また、X-CD-Roast では、root では問題なく CD-R Writing が可能ですが、一般ユーザーではどうにも失敗する、ということがあり、原因究明にも疲れてしまったことから、k3b に切り替えることにしました。
幸い、KDE 環境を導入していたため、k3b の導入は比較的容易でした。それでも 10 個を超えるパッケージをネットワークから引き込むため、回線には優しくないと思います。
# apt-get k3b
k3b が導入できたので、さっそく CD image を焼き付けることにしました。起動した k3b は英語環境で起動してきたため、TurboLinux で使用していた時の経験を生かして、手探りで行ってみたのですが、やはりエラーが発生してしまいます。いよいよ八方ふさがりとなってしまったので、Vine Users ML に質問を投げてみたところ、xine でお世話になったシノバーさんからのコメントをいただくことができました。
いただいたコメントのうち、いくつか気になることがあったのですが、根本的な原因は、cdrecord コマンドのパーミションにありました。我が家の環境では、cdrecord コマンドのパーミッションは 711 -rwx--x--x root root となっており、root 以外では、Read 属性が落ちていたのです。これでは、いくら eXecute 属性がたっていても、肝心の実行ファイルを読み込みできないわけですから、実行のしようがありません。早速、パーミッションを 755 -rwx-r-xr-x としたところ、これまでの失敗がうそのように、すいすいと書き込みができるようになりました。しかし、CD image を特定のディレクトリからしかできない X-CD-Roast は、私の感覚にはなじまないため、今も愛用は k3b となっています。
なお、k3b を日本語化する方法は、意外なところにありました。それは、日本語化対応ファイルが別にあった、ということでした。apt-cache search コマンドで、k3b を検索してみたところ、k3b-i18n というパッケージが見つかりました。そこで、このパッケージを導入したところ、無事、日本語環境で k3b が起動してきました。
Last Update is 2007/04/14. CopyRights Tazoe Kazuya 2007.