目次


ディストリビューションの作成: 第2回

Enoch発Gentoo行き (「若干の"つまずき"と"いさかい"」経由)

Comments

Enochへの第一歩

前回の記事で、私はStampede開発チーム時代に私が体験したすべてと、私がチームを辞めた理由 (低次元な政略を好み、プロジェクトを管理したがる「変人」から逃れるためです) をお話ししました。お節介好きで自分では何も行わない傍観者から横槍を入れられた私は、このような不愉快極まりない環境でStampedeの開発を続けるよりは、自分で独自のLinuxディストリビューションを組み立てたほうが、いっそスッキリするのではないか思いました。幸いなことに、私はStampedeでの、いくつかのパッケージの保守、初期化スクリプトの設計、およびslpv6 (次世代パッケージ管理プロジェクト) の指揮などの (重要と言って差し支えない) 仕事から、かなりの経験を積んでいました。

私が開発を始めたEnochというコードネームのディストリビューションは、パッケージの作成およびアップグレード・プロセスが完全に自動化されるはずであったため、ものすごい速さで出荷できそうでした。これは主として、メンバーが私一人のチームであり、繰返し作業を毎回自分でやる時間的な余裕がなかったことに起因していたことは事実です。それに私は、完結したディストリビューションを (RedHatなどの他のパッケージを下敷きにするのではなく) 一から作ることを考えていたので、生計のための仕事も一切止め、かき集められるだけの時間をかき集める必要が ありました。

Enochシステムの基本部分が立ち上がった後に、私はirc.openprojects.netに戻り、#enochという、独自のチャネルを開始しました。やがてそこから、10人ほどの開発者を集めてチームを作りました。最初のころは、私たちは皆IRC(Internet Relay Chat)に夢中になり、空き時間にディストリビューションの開発を行っていました。協力し合ってディストリビューションの開発に取り組み、バグのたたき出しと修正をしているなかで、Enochは日に日に機能が充実し、それなりの様相を示すようになってきました。

最初の障壁

ある日、Enochはついに壁に突き当たりました。Xfree86、glib、およびgtk+ を追加した後で、私はxmms (X11/gtk+ ベースのMP3/CDプレーヤー・アプリケーション) を動かすことにしました。音楽でお祝いをしても良いころだと思ったのです。しかしxmmsをインストールした後でスタートしようとしたのですが、Xがロックされてしまいました。最初私は、常識外れな値 ("-O6 -mpentiumpro") をコンパイラーの最適化値に指定したためにxmmsがロックされたのかと思いました。私が最初に考えた、標準的な最適化でxmmsをコンパイルする方法では、問題は解決しませんでした。そこで、コンパイル指定以外の点について調べ始めました。問題の原因を探し出そうとして、開発に当てている時間を丸一週間使った頃、OmegadanというEnochユーザーからe-mailを受け取りました。彼もxmmsのロック・アップを経験していたのです。

私たちは、しばらくの間メールをやり取りし、何時間かテストを行った末に、問題がPOSIXスレッドに関連しているという結論に達しました。どういうわけか、pthread_mutex_trylock() コールが仕様通りの戻り方をしていなかったのです。ディストリビューションの作成者にとって、こうしたバグは、出会いたくないタイプのものでした。私は、開発者たちが完全なソースをリリースするものと期待していたせいで、バグのあるソースをまともに作動させることよりも、Linuxの経験を広げることに専念していたのです。もちろん、すぐに私は、それが非現実的な期待であって、そうした問題が常に起こるものだということを知りました。

あとで分かったことですが、問題の原因はxmmsやgtk+ やglibではなかったのです。また、Xfree86 3.3.5がスレッド・セーフになっていなくて、ロック・アップしていたことが原因でもありませんでした。驚いたことに、LinuxのPOSIXスレッド実装自体、つまりGNU Cライブラリー (glibc) バージョン2.1.2の一部にバグがあったのです。Linuxのこのような重要な部分にこれほど大きなバグがあったと知ったときには、ショックを受けました。(それに、私たちがEnochで使用していたのは、プレリリースでもCVS版でもなく、リリース版のglibcだったのです)。

それでは、私たちはどのようにして問題箇所を突き止めたのでしょうか? 実際には私たちはバグ・フィックスを考え出すことはできませんでしたが、あるとき、glibc開発者メーリング・リストで、同じ問題を経験している人から送られたe-mailをいくつか偶然に見つけました。それに答えたglibc開発者が、そのスレッドの問題を解決するパッチをポストしていました。しかし私は、なぜ (同じようにglibc 2.1.2を使用していた) RedHat 6がこの問題に悩まされなかったのか、興味をそそられました。そのパッチがポストされるよりもかなり前から、RedHat 6が利用可能になっていたからです。その秘密を探るために、私はRedHatのglibc SRPM (ソースRPM) をダウンロードし、パッチを調べてみました。

RedHatには、pthread_mutex_trylock() の問題を解決するための自前のglibcパッチが用意されていました。明らかに、彼らも同じ問題を経験し、独自にカスタム・フィックスを作成していたのです。彼らがこのパッチをglibc開発者たちにアップストリーム送信しなかったために、他の人々がそれを共用することができなかったとしたら、残念なことです。しかし、もしかするとRedHatがパッチをアップストリーム送信したにもかかわらず、何かの理由でglibc開発者たちがそれを受け入れなかったという可能性もあります。あるいは、スレッド・バグはコンパイラーとbinutilsバージョンの特定の組み合わせによって誘発されるものであって、(RedHatのSRPMにはスレッド・パッチが確かに存在しているものの) RedHatがそのような事態に立ち至ることはなかった、とも考えられます。実際に何があったのかは、決して分からないと思います。しかし、RedHatのSRPMで、元の開発者に反映され得ない形の、プライベートなバグ・フィックスやパッチがたくさん行われていることを知りました。ここでしばらく、このことについて苦言を呈したいと思います。

苦言

Linuxディストリビューションを作り上げるときには、自分の作ったバグ・フィックスを元の開発者にアップストリーム送信することがきわめて重要です。これはディストリビューション作成者がLinuxに貢献するための1つと考えます(他にもたくさんありますが)。ディストリビューション作成者は、さまざまなプログラムをすべて一体となって機能させようとしているはずです。統合の過程で、フィックスをアップストリーム送信して、他のユーザーやディストリビューションがその恩恵に浴することができるようにすべきです。バグ・フィックスを独り占めしたのでは、誰の助けにもなりません。多くの人たちに同じ問題を何度もフィックスさせ、時間をむだにさせるだけです。このようなやり方は、オープン・ソースの倫理に反することであり、Linux開発の進歩を妨げます。こうした態度こそ、私たち皆にとって「バグ」なのだと言うべきでしょう。

残念ながら、ディストリビューションの中には(ahem)、自分たちの仕事をコミュニティーと共有することに他のディストリビューション (Debian) ほど得意でないもの (RedHat) があります。

コンパイラーを巡るドラマ

私たちがglibcのスレッドの問題をフィックスしようとしていたときに、私はUlrich Drepper (glibc開発に熱心に取り組んでいるCygnusの開発メンバーの一人) にe-mailを送りました。私は、自分たちがPOSIXスレッドの問題を抱えていること、また、Enochがパフォーマンス最適化のためにpgccを使用していることを書きました。すると彼は、このような返事を送ってくれました (原文のままではありません)。「CodeFusion製品に組み込まれている私たちのコンパイラーには、pgccで生成される実行可能ファイルよりもはるかに高速な実行可能ファイルを生成する、すばらしいx86バックエンドが備わっています。」 もちろん私は、Cygnusのメンバーが作った謎の「ターボ付き」コンパイラーをテストしてみようという気になりました。

さっそくCygnus Codefusion 1.0のデモ版を取り寄せてテストしてみたところ、Omegadanと私は、このコンパイラーがUlrichの言っていた以上のものであることを知って、びっくりしました。このx86バックエンドは、(bzip2などの) いくつかのCPUバウンドな実行可能ファイルのパフォーマンスを、90%近くも向上させたのです! コンパイラーを交換しただけで、すべてのアプリケーションの実用上のパフォーマンスが、少なくとも10%は向上したようでした。さらに、Enochのブート速度が30 - 40%速くなりました。パフォーマンス向上は、gccからpgccに切り替えたときと比較にならないほど顕著なものでした。自分たちでそれを体験した後で、私たちはもちろんこのコンパイラーをEnochで使いたくなりました。幸いソースがCodeFusion CDに入っていて、GPLのもとでリリースされていたため、このコンパイラーの使用は全面的に許されていました (あるいは、そうであるものと解釈しました)。

不可解なことの始まり

私は、Cygnusのマーケティング・マネージャーにe-mailを送り、私たちの意向を伝えました。「結構ですよ。やってみてください。私たちのコンパイラーを使っていただけて感謝します」という答えを期待してのことです。ところが、返ってきた返事によると、Cygnusコンパイラーを使用することは (技術的には) 許されるものの、コンパイラー・ソースをEnochで使用したりEnochに組み込んだりはしないようにとのことでした。私は、それならなぜソースをGPLの条件下でリリースしたのかと尋ねました。私の想像では、もし彼らがGPLの条件下でリースしないという選択が可能であったならば、そうした筈です。しかし、彼らのコンパイラーが (GPLのもとでリリースされている) egcsから派生したものであるため、選択の余地がなかったのでしょう。

これは、GPLのソフトウェア・ライセンス体系は、オープン・ソースのソフトウェアをもとに、所有権付き製品を作ることを企業に禁じていることを示す好例です。いろいろな事情から判断すると、Cygnusは、私たちが彼らのコンパイラーを使用してしまうと、彼らの製品の売り上げが落ちるのではないかと恐れていたようです。しかしこれは、おかしなことです。なぜなら、彼らのマーケティング資料のどこにも (またInfoWorld レビューにも)、CodeFusionに組み込まれている新しいコンパイラーのことは触れられていないからです。CodeFusionはコンパイラーとしてではなく、もっぱら「開発用IDE」製品として売り込まれていたのです。

私は彼らの被害妄想を静めようとして、CodeFusionの支持を表明し、また、私たちのWebサイトに CodeFusionの販売支援のためにリンクを張って推奨することを提案しました。私は、個人的には「ターボ付き」Enochが彼らの製品の売り上げに悪影響を与えるとは思っていませんでした。CodeFusionはIDEとしてマーケティングされていたからです。しかし、それでも彼らを喜ばせようとしました。CodeFusionのIDEコンポーネントは商業製品であり、私たちには、それをEnochで配布する意図 (あるいは権利) はありませんでした。

私が自分の (気前の良い?) 提案をCygnusにe-mailで送ると、また意外な返事が返ってきました。彼らは、私たちのすべての「マーケティング資料」(これには、私たちのWebサイトのコンテンツも当然含まれます) についての承認権を求めたのです。これも驚きでした。Cygnusのマーケティング・チームは、LinuxコミュニティーやGPLがどのように機能しているのかをまったく理解していなかったようなので、Cygnusとは二度と連絡を取らないことに決めました。その間に、私たちは私用の「ターボ付き」バージョンと公的な「非ターボ」バージョンのEnochを作り、最終的な決定は後に延ばしていました。

しかし数か月後に彼らはCodeFusion x86バックエンドをgcc 2.95.2に組み込んだのです。こうして、CodeFusion CDに含まれている「秘密のGPLコンパイラー」のことを知っている人だけでなく、誰もがすばらしいバックエンドの恩恵を得られるようになったのです。そこで私たちは、CodeFusionコンパイラーではなくgccを使用していくことに決めました。gcc 2.95.2は安定性に優れているだけでなく、Cygnusとのイザコザを避けるためにも役立ちました。当時すでにCygnusはRedHatによって、途方もない金額で買収されていました。(注: gcc 2.95.2に組み込まれた新しいx86バックエンドのおかげで、新しいLinuxディストリビューションは、私たちが経験した、すばらしい高速ブートを実現できたのです。これにより、FreeBSD 4.0も3.3.6に比べてブート速度が向上しました。違いにお気付きでしたか?)

自説を説く

いろいろな経験をしたおかげで、私は営利目的のオープン・ソース企業についてたくさん学びました。営利目的のオープン・ソース企業自体は、決して悪いものではありません。また、所有権を主張できるクローズド・ソースのソフトウェアの作成を望むのなら、そうしたところで道義的に問題な点はありません。しかし、オープン・ソース企業が、GPLを支持しないとか、あるいはその他の手段で、自分たち以外のオープン・ソース社会を転覆させたり、協調を拒んだりすることは、どう考えても理解しがたいことです。この点は、企業にとって当然必要な、実践的な常識です。

オープン・ソース企業は、アイデアやコードの自由な交換が自分たちの利益の元であることを認識すべきです。標準的なGPL慣行などに反した行動を取ることにより、彼らは自分たちの成功や成長に欠かせない環境を損なっているのです。オープン・ソースという土壌からあなたの企業が芽生えたのであれば、その土壌を健全に保つのは理にかなったことです。

短期的な経済利益のために、少なくともある程度の情報を秘密にしておきたいという気になることは、理解できます。先進的なコードや特別な技法は、望ましい競争上の優位をもたらしますので、売り上げや利益の増加につながる可能性があります。しかし、ある製品の唯一の提供者となることを目指すのであれば、その製品はオープン・ソースでなく商業製品にするべきです。オープン・ソースは、あるソフトウェアに含まれる特定の成果物に対して排他的アクセスを認めるものではありません。このことが、オープン・ソースが意味することなのです。

Enochに戻って

さて、私の考えを述べるのはこのくらいにして、話の先を続けることにします。

Enochが洗練されてきたので、私たちは名前を変更すべきであると考えました。こうして、"Gentoo Linux" が誕生しました。この頃には、私たちはすでにEnoch (現在のGentoo) のバージョンをいくつかリリースしていて、Gentoo Linuxバージョン1.0の完成を急いでいました。また、この前後に私は、自分の古いCeleron 300ボックス (450Mhzにオーバークロックし、安定していました) を新品のAbit BP6 (市場に登場したてのデュアルCeleronボード) にアップグレードしようとしていました。私は古いボックスを売ってデュアルCeleron 366システムを組み立てました。プロセッサーを500Mhzクラスにオーバークロックした後で、私は意気揚揚としていました。しかし私は、自分の新しいマシンがあまり安定していないことに気付きました。

もちろん、まず手を付けたことは、2x366Mhzに戻すことでした。しかし、今度はもっと奇妙な問題に遭遇したのです。マシンのCPUが働いている間は、マシンがロックすることはありませんでした。しかし、夜間マシンをアイドル状態にしておくと、システムが完全にロックしてしまうことが結構あったのです。そう、アイドルのバグだったのです。少し調べてみると、他にも同じマザーボードで同じ問題を経験しているLinuxユーザーを何人か見つけました。BP6に載っていたチップ (PCIコントローラーでしょうか?) がおかしいか、またはスペックどおりに作動していないようで、それがLinuxのアイドル時のロックの原因となっていたのです。

私は少なからず動揺しました。そして、それ以上PCパーツを注文する余裕がなかったので、Gentoo開発は事実上中断しました。私はますますLinuxに悲観的になり、FreeBSDに切り替えることにしました。そう、FreeBSDです。それで、このインストールはようやく終わるはずです -- 第3回でお会いしましょう。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Linux
ArticleID=228091
ArticleTitle=ディストリビューションの作成: 第2回
publish-date=12012000