64bitシステムで32bit版ブラウザを使う
一番簡単な解決策は、32bit版のブラウザを「chroot jail」内部にインストールすることだ。chroot jailとは、ブラウザとその実行に必要なサポートライブラリ（この場合は、32bit版のプラグインとコーデック）だけを備えた最小構成の32bitシステムで、chrootコマンドなしではアクセスできないようにシステムのほかの部分から隔離された領域をいう。この32bit版ブラウザは、前述の64bit環境から起動でき、Webに接続してそのコンテンツを閲覧できる。しかし、chroot jailの外側にインストールされた、ローカルマシン上のリソースにはアクセスできない。
埋め込まれたメディアを普通に閲覧したり表示するのであれば、こうした環境でも問題なく動作する。ほとんどの場合は、プラグインやメディア・コーデックをこのブラウザの動作の範囲内で直接インストールすることもできる。使っているディストリビューションのパッケージ管理アプリケーションの32bit版をインストールし、ほとんど、あるいはまったく手をかけずに、すべてのアプリケーションを最新の状態に保つことさえできる。
欠点は、このブラウザを使い続けると、ヘルパー・アプリケーションや補助ツールがchroot jailにどんどんインストールされてしまうことだ。たとえば、通常、BitTorrentのダウンロードファイルは外部のアプリケーションによって処理されるとはいえ、それらの大部分は依然としてWeb上のリンクから取得される。そのため、お気に入りのBitTorrentクライアントを32bit版ブラウザからクリックして起動するには、chroot jail内部にBitTorrentクライアントの32bit版をインストールしなければならない。多くの人にとって、同じアプリケーションなのに複数のバージョンをインストールしなければならないのは面倒であり、洗練されたやり方とはいえない。
また、この方法は、32bit版と64bit版の両方のビルドが利用可能なディストリビューションでしか使えない。通常、そうしたディストリビューションを見つけるのは難しくはないのだが、念のために記しておく。
たいてい、ディストリビューションのユーザフォーラムやWiki、メーリングリストを探せば、chroot jailの詳しいセットアップ手順が見つかるだろう。具体的な例を挙げておくと、私は64bit版UbuntuでMozilla Firefoxの32bit版を使っているのだが、ubuntuforums.orgのこのスレッドにそのためのセットアップ手順がある。
ライブラリを利用する
まったく異なるアプローチとして、32bitの命令セット向けにコンパイルされ、/usr/libなど通常の（64bitの）システムライブラリではなく同等の（/usr/lib32のような）32bitライブラリにリンクされたブラウザをインストールする、という方法がある。バイナリライブラリが複数ある場合にどのような名前付けを行うかは、Filesystem Hierarchy Standardで指示されていないため、ディストリビューションごとに異なるが、たいていは、/usr/libは64bit版ライブラリ、/usr/lib32は32bit版ライブラリだと考えていいだろう。
このことから、この方法には大きな問題があることがわかる。ディストリビューションへの依存性が非常に高いのだ。この方法だと、ディストリビューションは、32bit版と64bit版の両方が用意されていなければならないほか、複数の共有ライブラリにも対応していなければならない。chroot jailの方法との違いは、複数の共有ライブラリに対応していれば、ディストリビューションの設定やインストールに煩わされずに済む、という点だ。ただし、複数の共有ライブラリに対応していない場合、手動でセットアップを行うことになるのだが、その厄介さはchroot jail手法のセットアップの比ではない。
さらに、このクロスライブラリ・システム用にコンパイルされたWebブラウザ、つまり、/user/lib32またはそれに相当するライブラリにリンクされたバイナリ、をうまく扱う必要がある。32bit版ディストリビューションで使えるように開発された、vanillaの32bit版バイナリは動作しないだろう。現在使っているディストリビューションでこうしたクロスライブラリ・パッケージが利用できれば、苦労をせずに済む。そうでない場合は、皆さんのご健闘を祈る。力になりたいのはやまやまだが、この記事で自作ライブラリのコンパイルについて解説するわけにはいかない。
別に、皆さんを落胆させようという意図はない。実は、いい知らせもある。私の非公式な調査によると、日々この問題に取り組んでいる64bit版Linuxのユーザは相当な数にのぼり、そのため、主要なディストリビューションのほとんどにはクロスライブラリ・パッケージが用意されているようだ。先ほどの私の環境を例にとると、64bit版Ubuntuには32bitとの互換性を保つために開発されたパッケージが含まれているし、Firefox最新版の公式リリースが出るたびに、自らの時間を削って32bit互換のFirefoxパッケージを最新版にアップデートしてくれる親切な人々もいる。
ラッパーを利用する
3つ目の方法は、おそらく先の2つほど知られていないだろうが、システム本来の64bit版ブラウザに32bit版のプラグインを読み込むというやり方だ。ほかにもあれば遠慮なく指摘してほしいのだが、この類の方法として唯一、私が知っているのは、MandrivaのGwenole Beauchesne氏が創設して開発を続けているnspluginwrapperという個人的なプロジェクトだ。Beauchesne氏は、まだすべてのソースコードを公開し終えていないが、読みやすくしたうえで公開するつもりだという。
このパッケージは、標準的な32bit版プラグインを64bit版のMozillaベースのブラウザに読み込む64bit版の「プロキシ」プラグインと、少数の設定ツールで構成されている。Beauchesne氏は互換性のあるものとして主要な商用プラグイン（Acrobat、RealPlayer、Flash）を挙げてているが、理論的には、Netscape Plugin Application Program Interface（NPAPI）に準拠したプラグインであればどんなものでも動作するはずだ。
なお、Beauchesne氏のWebページにあるインストール手順は、更新されていない記述が一部あるようで、説明の中にnspluginwrapperというコマンドラインツールが出てくるのだが、私がダウンロードしたパッケージではそういう名前のツールはインストールされなかった。幸い、このubuntuforums.orgスレッドの親切なユーザから正しい手順を教わり、疑問は解消された。Webページの手順書に書かれていた先ほどのコマンドラインツールは（nspluginwrapperではなく）npconfigだった。
もっと別の方法
もう1つ選択肢があることを忘れてはならない。あくまでも64bit版ブラウザにこだわり、64bit版のないプラグインやコーデックは何としても使わずに済ませる、というやり方だ。この場合、具体的な行動はいくつでも考えられる。たとえば、64bit版で閲覧できないコンテンツは見ないようにする、64bit版プラグインが登場するまではひたすら耐える、プラグインやコーデックの開発メーカーに直訴する、Gnashなど代わりになるフリーのビューアを信じて頼る、といった具合だ。
きちんと動作するフリーのプラグインが動作しない非フリーのプラグインに勝るのは自明だが、どちらをとるかは皆さんの考え方次第だ。
「自分の決めたやり方で見られないコンテンツなら、見なくても構わない」と大胆に言い切ってしまうのもいいだろう。しかし、大半の人々は、非オープンソースのブラウザのプラグインやマルチメディア・コーデックを扱わないわけにはいかないだろう。その点、AMD64アーキテクチャを利用している人々は幸運だ。少し工夫をすれば、それほど手間をかけずにi386プラグインを利用できる。そのうえ、複数の選択肢から好きな方法を選べるのだ。
今のところ、セットアップと設定が一番容易なのはchrootの手法だ。また、/lib32の手法を使えば、ハードディスク領域が少なくて済み、1つのプログラムにつき複数のバイナリを管理する必要もない。しかし、概念的に最も洗練されているのは、ラッパー・プラグインの手法だ。この手法は、安定性には欠けるが、うまく行き始めれば、AMD64ユーザだけでなく、その他のアーキテクチャでWebブラウジングをするユーザにとっても、すばらしい効果を発揮する可能性を秘めている。
原文
