目次


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

Gentoo Linuxディストリビューションの誕生

Comments

Linuxとわたし

Linux愛好家にはそれぞれ、Linuxが単なる名前を知っているだけの域を脱し、これまで見たこともないほどすばらしく、強力で、興味をそそるものとしてベールを脱ぐときがあります。わたしがそれに気付いたのは、ニューメキシコ州立大学でシステム管理者として勤務していたときです。NTサーバーは快調に稼動し、時間的に余裕ができたので、Pentium 166サーバー・マシンにDebianをセットアップし、徹底的に勉強しました。これが、わたしが夢中になったきっかけです。

まず、Linuxの基本的な事柄、つまり、動かし方、バックアップのとり方、Sambaを実行させる方法などを徹底的に学習しました。次にqmailとApacheをセットアップし、pythonプログラミングとshellプログラミングを学習しました。わたしが作成したのは、部署用イントラネットです。Linuxを自宅にインストールし、別 のディストリビューションを試し始めました。最後にたどりついたのが、Stampede Linuxです。どのように勉強を進めるのかはお分かりでしょう。最初はLinuxの基本を把握するのに苦労しますが、しっかりと理解すれば、Linuxをカスタマイズし、触れながら学習することができます。Linuxはすべてオープンであるので、Linuxの理解を伸ばしながら、Linuxの特徴を引き出すテクノロジーやツールを見つけ出すことができます。

Linuxは可能性を秘めている

Linuxは、わたしがこれまでに体験したこともないものを与えてくれました。このそうした不思議なものを一言で言うとしたら、それは可能性でしょう。Linuxは、事態を変化させ、改善し、本来の姿に戻し、そして打開する可能性を持っています。新しいカーネル・バージョンにアップグレードするたびに、Linuxはわたしの目の前で改善され、ほとんど毎日姿を変えていることが分かりました。そして、わたしも一応参加しました。Linuxの変身作業に加わったというわけです。楽しかったです。

もしわたしのような状況で、Linuxやオープン・ソースに触れることがなかったのなら、RedmondやCupertinoにある大企業に目を向けて、いつかは期待どおりに正確に動作する新世代のオペレーティング・システムを期待していたでしょう。しかし、その夢が実現することはありませんでした。そして、待っている最中に、Linuxが現れたのです。粗削りの点はたくさんありますが、次のすばらしいオペレーティング・システムの登場を待ちながら、わたちたちのようなコンピューター狂が自分たちの手で改良できるものを与えてくれました。そして、ある日、Linuxこそ 次のすばらしいオペレーティング・システムであることに気付いたのです。その間ずっとニコニコしながら、わたしたちは改良を続けました。

Linuxは人のようなものだ

次にわたしが学習したことは、Linuxは人のようなものだということです。新鮮な考えではありませんか。Linuxは単なるソース・コードの塊ではありません。コミュニティーなのです。わたしたちは、このコミュニティーに頼って、質問の答えを手に入れましたが、時間と知識をかけて他のLinuxユーザーに手を貸しだしたとき、またわたしたちも、コミュニティーの一員になります。

IRC (インターネット・リレー・チャット) は、Linuxユーザーが集い、非常に多くの時間を費やすことができるすばらしい場所です。irc.openprojects.netの #stampedeチャネルが、わたしのたまり場でした。そこで、Linuxの質問をしたのです。また、他のユーザーを最初に助けたのもこのチャネルでした。#stampedeでは、Linuxをインストールしたばかりの新規ユーザーを助ける、経験豊富なLinuxユーザーを必死に求めていました。IRCではよくあることですが、経験豊富なStampedeユーザーの多くは、新規ユーザー(しかも他人) の質問に答える熱意に欠けていました。しかし、新規ユーザーへの答えを自分が本当に知っていることの興奮がつのり、手を差し伸べたいという心の動きを 止めることができなくなりました。そして、それが、わたしがStampedeにかかわり始めたきっかけです。わたしは単に質問に答えることが好きな男だったのです。もちろん、完全な利他主義ではありませんでした。なぜなら、わたし自身も、さらに経験豊富なユーザー (当然Stampedeデベロッパーそのものも含まれます) が提供してくれたLinuxの知識でさらに理解を深めることができたからです。

関与する

オープン・ソース・プロジェクトにかかわる方法を聞かれた場合には、基本的なLinuxの質問に答えることであっても、自分が役に立つ居場所を見つけることだ、と言っています。他人の役に立ちたいという真摯な希求こそが、Linuxコミュニティーに入る偉大なチケットなのです。なぜなら、この気持ちこそ、オープン・ソース開発すべての真髄だからです。(勿論Linuxもそうです) 少なくとも、そうあるべきです。

途中、自分よりも知識がある人に必ず出会うことがあります。そのとき新規ユーザーがあなたから学習するのとまったく同じように、あなたも彼らから学習するのです。また、経験が豊富になれば、新しい方法で助けるチャンスも巡ってくるはずです。おそらく、これから出会うプロジェクト・デベロッパーの中には、何かを提案してきたり、また助けを求めてくる人もいるでしょう。開発チームの一員として招かれることもあるかもしれません。人助けをして、人々に見過ごされるようなことはありません。多くのユーザーを手伝っていれば、コミュニティーで確実に注目される存在となるでしょう。このような関り合いが、Stampedeとわたしの間で起こっていました。

次第にわたしはStampede開発にのめり込むようになり、あっという間に、正式なStampedeデベロッパーになりました。スキー狂 (StampedeのボスであるMatt Wood) のおかげで、わたしは、Stampede初期の.slpパッケージ・フォーマットの新しいバージョンに取り組み始めました。当時、.slpパッケージ・フォーマットは、パッケージの作者、コンテンツの説明、およびパッケージ作成者などに関する情報が収められた固定長のフッターが端にある、.tar.bz2アーカイブから成り立っていました。このアプローチには2つの大きな問題がありました。フィールドは固定長で、フッターは実際にはそれほど大きくないということと、フォーマットに拡張性がないということでした (将来的に .slpフォーマットに別のフィールドを追加する余裕がありませんでした)。明らかに、これは大きなオーバーホールを必要としていました。

シニアStampedeデベロッパーたちと一緒に作業しながら、わたしは、この問題の対処案を作成しました。そして、Pythonでプロトタイプ・ツールのコーディングを始めました。新しいフォーマット (コード名slpv6) は、AmigaのIFFファイル・フォーマットにいくらか似ていました。この新世代の .slpフォーマットでは、232 フィールド、232 フィールド・カテゴリー、そして最大フィールド・データ長232 バイトが可能となりました。フォーマットは、拡張性が優れていただけでなく、プレーン・テキストよりもコンパクトで、解析が簡単でした。このフォーマットでテキスト・データとバイナリー・データの両方を格納できるため、将来的な可能性も広がりました。アイデアは、この次世代の動的ヘッダーをアーカイブ・ファイルの端に付けることで、Stampedeユーザーが今後も使用できると同時に、標準のUNIXアーカイブ・フォーマットとの互換性を維持する新世代の .slpフォーマットを作るというものでした。

不快な思いをさせる可能性がある人

slpv6開発は問題なく進行し、シニア・デベロッパーはわたしの進歩に満足していました。しかし、残念ながら、レベルの低い2人のStampedeデベロッパーが、slpv6プロジェクトを支配したがっていました。彼らの道とわたしの道は異なっており、彼らは、新しいslpv6システムを侮辱することに時間の大半を費やしていました。わたしは、熱い開発討論に何時間もかけて、彼らの攻撃から自分の案を守ろうとしましたが、何の解決にもなりませんでした。結局、彼らはただ議論好きなだけで、思ったとおりにならないと満足しない、ということがはっきりとしてきました。幸いにも、わたしのプロジェクトはシニアStampede開発者の承認を取りました。しかし、彼らはわたしに議論を浴びせかけるようになり、おかげでStampede開発は非常に不快なものになってしまいました。残念なことです。

このような人たちを避けることはできませんでした。なぜなら、レベルの高いデベロッパーとチャットするためには #stampedeを利用しなければならなかったからです。わたしがチャネルに登場するたびに、彼らは闘争的になり、わたしの作業を妨げようとしていました。彼らは、開発ミーティング (実際には、シニア・デベロッパーの前でわたしの仕事を侮辱するチャンスを得るためだけのもの) を求めるような、悪質なテクニックを利用しました。また、投票を呼びかけ、Stampedeを支配しようともしました。もちろん、彼らが投票を呼びかけたのは、彼らに同意する人が大勢いると確信していたからに過ぎません。このようなことが起こっている間も、わたしはslpv6の開発を続けました。言うまでもなく、シニア・デベロッパーはわたしの仕事を愛してくれていましたし、わたしが続けることを望んでいました (彼らの支援がなければ、わたしは開発を続けられなかったでしょう)。

変人を理解する

この2人の男は、「変人」と呼びたいデベロッパーの部類に属します。しかし、彼らはわたしの開発の仕事を非常に不快なものにしましたが、わたしは、彼らに対処しなければならないことから、多くのことを学びました。ここで、変人デベロッパーについて解説したいと思います。変人になる資質、変人の手口、そして皆さんのような開発プロジェクト・リーダーが、あまり労力をかけずに変人に立ち向かい、そしてできるなら変人を更正させる方法を総合的な観点から説明します。

精神的なダメージを防ぐには、1つの前提条件、つまりバックボーンが必要です。丁寧だが確固とした方法で変人に立ち向かうことができない場合は、望みはありません。変人の目的は、自分たちに力があると感じるように、あなたのプロジェクトをできる限り支配することです。変人は、さまざまなテクニックを用いてこれを起こそうとします。まず、プロジェクト、あるいはプロジェクトの仕事をしているデベロッパーを、不当に批判したり、ひどい文句を言ったりし始めます。次に、建設的なソリューションの提供を止めます。また、プロジェクト・マネージャーの役に昇進しない限り、そのほかの方法でプロジェクトに嫌がらせをします。彼らの目的は、自分たちにできる限り大きな権力が与えられていることをあなたに見せつけて、彼らしか、もみにもまれた変人の目でしか分からない問題を解決することなのです。

批判や文句が功をなさないと、デベロッパー・ミーティングを要求します。これは、開発チームを仲間割れさせるチャンスなのです。十分な数の賛成者が得られると思った場合には、(勝つと分かっている) 投票を要求します。投票に勝てなかったり、却下されたりした場合には、再びデベロッパー・チームを分裂させようと、翌週に別 のデベロッパー・ミーティングを請求します。このプロセスを際限なく繰り返します。

デベロッパー・ミーティングのアプローチがうまくいかないと、変人は革新派になります。この役割を利用することで、威圧的で不当な上層部の意思決定プロセスを何かもっと民主的なもの (つまり、簡単に操作できるもの) に変えようとして、合理化 (つまり、破壊) を試みます。これには、デベロッパーの大多数が望むことなら何でもしなければならない、ということをあなたに見せつけることが含まれます。変人はこれが大好きです。なぜなら、あなたはデベロッパー・ミーティングの投票を無効にすることができないからです。これを許してしまったら、基本的にLexusのキーを変人に渡してしまうようなものです。権力を失ってしまいます。

生産性の高いデベロッパーに嫌がらせをしたり、酷使したりするというアプローチもあります。そして、プロジェクトの権力構造を精力的に改編しようとしながら、チーム全体を混乱状態にさせます。彼らの努力が最終的に報われなかった場合には、できる限り多くの離脱者を再び呼び集めて、プロジェクトをかき回そうとします。

変人をうまくあしらう

こうした人たちはかなり簡単に見分けることができます。コードを作成していない人 (またはそのつもりがない人) です。その代わりに、もっと大切なことを話すのに時間を費やします。お分かりのように、管理問題です。あなたがプロジェクト・リーダーであるなら、彼らに対処するのはかなり簡単でしょう。コードを生成していない限り、彼らの提案を考慮するつもりはないことを伝えればよいのです。あるいは、(建設的な) 批判を行うチャンスを与える前に、現在のプロジェクト・マネージャーに従うことを含め、現在のプロジェクトを建設的に支援するように強要します。すばらしいコードを作成したり、もっと役に立つことをし始めたら、最高でしょう。もし従わない場合には、出て行くように言いましょう。彼らは (あなたが長いこと無視していれば) プロジェクトを離れるか、あるいは協力するようになって、コードを作成し始めて、普通 はもっと好意的になるでしょう。

残念ながら、シニアStampedeデベロッパーは、変人のあしらい方を知りませんでした。言い換えれば、この2人の変人にわたし (そして他のユーザー) を徹底的に困らせることを許してしまったのです。シニア・デベロッパーは常にわたしの開発作業の味方でしたが、変人たちをなんとかしようという努力はほとんどしませんでした。そしてある日、わたしは2人の変人に我慢しなければならないことよりも、自分独自のディストリビューションを作成する方が簡単であると決意したのでした。Stampede開発を離れて、自分独自のディストリビューションを生成する計画を立て始めました。

2人のレベルの低いデベロッパーのためにプロジェクトを離れたことに少し後味の悪さを感じていますが、彼らをあしらえなかったという事実は、本当に、プロジェクトが重大な管理問題を抱えていたことを示していたのです。レベルの高いデベロッパーがStampede開発作業を楽しく、価値あるものにすることができなかった、そのつもりがなかったので、わたしはそこにいたくなかったのです。

再開する

辞めたら、ほっと大きなため息が出ました。やっと、平穏に、そして静かになりました。自分のディストリビューションをどのような感じにするか、そしてそれがLinuxディストリビューションにどのように貢献するか、ということを定義する時が来ました。Stampedeに魅力を感じた点の1つは、(実験用のPentium最適化pgccコンパイラーを使用したことによる) 生のパフォーマンスでした 。そのため、最初はパフォーマンスに焦点を当てることにしました。CPU使用率を最低限に抑えることに加え、サイズの膨張も最小限に抑えることを望みました。ディストリビューション (特に、人気の高い市販ディストリビューション) が多すぎると、デフォルトで非常に多くのデーモンが有効になり、xtermをオープンした後でRAMがほとんど残らなくなってしまいます。わたしは、ディストリビューションを小さく、取るに足らないものにしたかったので、実行環境のハードウェアのパフォーマンスを最大限にすることに焦点を当てました。全体論的アプローチを取り、あらゆる角度からパフォーマンス問題に取り組むことにしました。

しかし、たった1人で開発していたので、リソース不足という重大な問題が発生しました。現場から離れて自分だけでCalderaやRedHatに匹敵するものをいったいどうやって作成できたのでしょうか。答えは自動化です。時間の消費、面倒な繰り返しが最小限になるように、すべてを自動化するスクリプトを作成しなければなりませんでした。結局のところ、それこそコンピューターに一番適した仕事ではないでしょうか。

わたしは、必要とする類の自動化のための簡単なスクリプト作りがうまく行っていないことにすぐに気付きました。初めからLinuxディストリビューションを生成するための完全なシステムを設計する必要がありました。それにebuildシステムという仮の名前を付けて、作業に取り掛かりました。ebuildシステムは、ディストリビューションのバイナリーをすべて自動的に作成し、ソースのアンパック、パッチから、コンパイル、インストール、パッケージまで、あらゆることを自動化することができました。基本的なebuildプロトタイプを作動させた後は、Linuxディストリビューションの主要コンポーネント (gcc、glibc、binutils、util-linux、friendsなど) 用のebuildスクリプトの作成を始めました。初期化スクリプトを (わたしが前に設計したStampede初期化スクリプトに基づいて) 設計し直し、作成した新しい各パッケージをテストしてインストールしていくと、Stampede開発マシンは次第にわたし独自のシステムに形を変えてきました。

数ヶ月後、完全で、自己ホスト型Linuxディストリビューションが出来上がりました。それにEnochという名前を付け、満足で笑いがこぼれました。しかし、Enochはいったいどのようになり、Gentoo Linuxはどのように進化してきたのでしょうか。EnochがどのようにしてGentoo Linuxになったのかというお話と、わたしが直面した多くの新しい難題については、次回に紹介しましょう。


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


関連トピック

  • ディストリビューションの詳細については、Gentoo Linux Web site を参照してください。

コメント

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

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