Ottawa Linux Symposium 2008総括

 今年のOttawa Linux Symposium(OLS)の3日目には、多くのセッションが開催された。なかでも目を引いたのは、Ubuntuの創設者にして宇宙旅行者であるMark Shuttleworth氏の基調講演だ。氏は、シンクロニシティ(共時性)について議論を始めるようLinuxコミュニティ全体に呼びかけた。”シンクロニシティ”とは、主要なソフトウェアのリリース時期を同期させることを指す、Shuttleworth氏独特の言い回しだ。同コンファレンスは、終盤の愉快なセッションと統計情報の発表をもって土曜日に閉幕した。

 Shuttleworth氏は、OLSの伝統にのっとって、2007年度の基調講演者James Bottomley氏の紹介を受けて登壇した。Bottomley氏は、Shuttleworth氏の過去数年間のLinuxカーネル関連メーリングリストへの投稿数をグラフで示し、そこにある3年間の空白について、1年目は5億ドルを手に入れ、2年目は「地球にいなかった」、3年目はUbuntu Linuxディストリビューションを立ち上げるために多忙だった、と説明した。

 Shuttleworth氏の講演のタイトルは「The Joy of Syncronicity(シンクロニシティの喜び)」。いかにしてLinuxのマーケットを万人向けに成長させ、ソフトウェア開発の無駄を減らすかについて氏のビジョンが語られた。世界は変化している、私たちも変わらなければならない、と彼はいう。

 Shuttleworth氏の見解では、開発を後押しする3大要素は歩調(Cadence)、コラボレーション(Collaboration)、顧客(Customers)でなければならない。

 ”歩調”は、プロジェクトのリリースが実施されるペースを意味する。リリースは定期的であり、次のリリースがいつになるか予測が可能であり、そのサイクルはカレンダーに厳密に従う必要がある。たとえば、Ubuntuは6か月のリリースサイクルを目標とし、メジャーリリースは2年に1回とされている。GNOMEも、初期は苦労したが、現在は同様のペースでリリースされている。KDEも検討を始めたところである。

 Shuttleworth氏にとって、シンクロニシティとは、顧客の利益のために複数のプロジェクトの歩調がコラボレートされることに他ならない。Linuxカーネル、gcc、KDE、GNOMEは、他に先んじて、共同でリリースされるLinuxディストリビューションにおいて常に同じバージョンになるべきであり、これがコードの無駄を減らし、Linuxのマーケットを万人向けに成長させるのに役立つ。

 要点は単純だ。Shuttleworth氏のビジョンでは、すべてのディストリビューションで主要なソフトウェアのバージョンは同一になるが、それ以外の個性が消えることはなく、各ディストリビューションの独自性が提供され、今日と同じぐらい生き生きとしたディストリビューションの多様性が保たれる。リリース時期が予想可能なことは、関係者すべてに恩恵をもたらす。カーネル開発者は、どのバージョンのカーネルがいつどのディストリビューションで使用されるか正確にわかるので、開発を進めやすくなる。同じことは、オープンソースコミュニティのあらゆる側面に当てはまる。

 Shuttleworth氏は、このような予測可能でマーケットフレンドリなセットアップが、すべてのディストリビューションとマーケットにとってLinuxマーケット全体を成長させると期待している。

オープンソース開発への学生の貢献を持続させるには

 この日の早い時間に、Seneca Collegeの学生Chris Tyler氏の興味深い講演に参加した。Tyler氏のテーマは、オープンソースのテクノロジと開発に関わることで学生を教育するカリキュラムである。

 自主的にオープンソースのソフトウェアとコミュニティに関わる学生は大勢いるが、これは授業とは無関係の活動である。Tyler氏によると、Seneca Collegeはオープンソース開発をカリキュラムに直接組み込むことに取り組んでいる。同校の科目制度では、協力者を募集しているオープンソースプロジェクトのリストが最上級生に渡され、クラスのプロジェクトとして貢献するものをそこから選ぶようになっている。

 これまでのところ、ほとんどの活動はMozillaプロジェクトに集中している。Tyler氏が1つ指摘したのは、学生は大きなプロジェクトに慣れていないことだ。数千行ないし数万行のコードなら学生も実感できて、全体を理解できる。しかし、Mozillaのような100万~1,000万行もある大きなプロジェクトに取り組み始めると、1人の人間が全体を把握するにはコードが多すぎるのである。

 これは一方で、教員の手にも余るということだ。授業を指導する教員は、学術環境に通じ(教授なら当然だが)、なおかつオープンソースコミュニティにも活発に参加していることが不可欠である。オープンソースコミュニティがどういうものか本質的に理解していない教員が、プロジェクトを成功に導けるだろうか。そのため、他の教育機関から同校のカリキュラムの使用が打診されたことがあるが、Tyler氏らはプロジェクト成功の鍵はカリキュラムの内容ではなく教員とオープンソースコミュニティの緊密な連携だと助言したという。

 オープンソースプロジェクトと一般の科目には決定的な違いがある。一般の科目では、学生がプロジェクトの設計から実装まですべてのコーディングを担当する。オープンソースプロジェクトの場合、大きなプロジェクトの一部として既に存在するコードを使用できるが、それは20年前のコードのこともある。

 オープンソースは明らかにすべての学生に向くわけではなく、一部の学生はこのような方法でグループプロジェクトに携わることに満足しないと認めつつも、Tyler氏は成功例は失敗例よりもはるかに多いという。多くの実例を挙げたが、その1つはそれまでドキュメント化されていなかったAPIのドキュメントを作成するという大仕事だった。このテーマに関しては、成績をどう評価するかが争点となった。活動はオープンソースプロジェクトへの貢献であると評価され、学生の目的は達成されたと認められた。つまり、成功を収めたプロジェクトはコードを作成するプロジェクトとは限らないのである。

 Tyler氏がもう1つの例として挙げたのは、アニメーション形式のPNG(Portable Network Graphics)実装を開発した学生である(彼はこのファイル形式を”apng”と名付けた)。apngは、PNGプロジェクトによる同じタスクの実装であるMNGよりも扱いやすいため、Firefox、Opera、次いでMicrosoft Internet Explorerでサポートされた。ただし、本家のPNGグループには拒絶された。

 科目で求められるのは、実在するオープンソースプロジェクトに実際の貢献を新規の普通の貢献者として提供することだ。原則として、開発者と学生が逐次の対話を、できればどこかの時点で実際に顔を合わせて行う必要がある。たとえば、Mozillaの開発者とはirc.mozilla.orgの#senecaチャンネルを使って連絡を取り合っている。

 Tyler氏によると、科目はオープンソースの哲学とうまく折り合いをつけている。科目の要綱はwikiに投稿され、プロジェクトはこの要綱に従って進行し、学習成果は開発者ブログアグリゲータを通じて提出される(学生は各自のブログで進捗状況を申告する)。このシステムは、プロジェクトの他のメンバーが科目とプロジェクトの情報を正確に把握するうえでも有効だ。

 このプロジェクトの詳細は、Tyler氏の個人ブログで知ることができる。

平和と愛とロケット

 Bdale Garbee氏の講演は簡単に触れておく価値がある。オープンソースとオープンハードウェアを利用して、模型ロケット用の便利なテレメトリシステムを作るというものだ。Garbee氏は、模型ロケットというホビーについてかいつまんで説明してから、現在使用できる高度計と加速度計には、簡単にハッキングできないという欠点があると語った。Garbee氏のホビーは、いまやオープンソースプロジェクトの範疇に含まれる別のホビーへと姿を変えつつある。

4日目

 私のOttawa Linux Symposiumの4日目にして最終日は、D. Hugh Redelmeier氏の講演「Red Hat Linux 5.1 vs. CentOS 5.1: Ten Years of Change(Red Hat Linux 5.1対CentOS 5.1: 変化の10年)」による楽しい追憶の旅で始まった。Redelmeier氏は、1998年6月にリリースされたRed Hat Linux 5.1を取り上げ、これを同じコンピュータ上でCentOS 5.1と比較した。こちらは昨年末にリリースされたフリーバージョンのRed Hat Enterprise Linux 5.1である。彼がこの2つを選んだのは、時間の開き、素性の連続性、バージョン番号がたまたま同じ、という理由からだ。比較には、デュアルブート構成の1999製Compaq Deskpro EN SFXデスクトップマシンが使用された。メモリは初期の64MBから320MBに増設され、出荷時の6.4GBハードディスクは120GBハードディスクに換装済みだ。

 20才近くも年が離れた2つのLinuxディストリビューションを同じハードウェアにインストールする作業は「ちょっとした手品」だった、とRedelmeier氏は振り返る。たとえば、Red Hat 5.1はハードディスクのジオメトリをCHS(シリンダ/ヘッド/セクター)形式でしか認識しない。「CHSを覚えてますか、皆さん?」当時の標準ブートローダーLILOは、シリンダ1024以内にインストールする必要があった。120GBのハードディスクの場合、これは/bootがディスクの先頭8.5GBに現れるということだ。これを別としても、Red Hat 5.1では/bootを独立したパーティションとする概念がまだ導入されていなかった(5.2で導入された)ため、rootパーティションをディスクの先頭8.5GBに作成する必要があった。古いAT BIOSの名残である。

 他に彼を驚かしたのは、CentOS 5.1とRed Hat 5.1でスワップパーティションを共有できないことだ。Red Hat 5.1は、ブート時にmkswapを実行しないと、CentOSのスワップパーティションを読み取れない(mkswapは通常のブート手順に含まれない)。また、Red Hat 5.1のスワップパーティションは最大サイズが127MBしかない。このバージョンはメモリ16MBのマシンにインストールされることもあったため、当時は127MBでも潤沢だと考えられたのだ。

 使用したコンピュータには光学ドライブがないため、CentOS 5.1をインストールするにはPXEブートを使う必要があった。CentOSにはyumアップデートもインストールする必要があるが、このコンピュータでは非常に実行が遅かった。

 観察の結果わかったことの1つは、GRUBが全般的にLILOよりも優れていることだ。LILOブートエラーのため”LILILILILI…”が表示される愉快な体験を久しぶりに味わったという。

 Redelmeier氏は、1975年以来Unixをさまざまな形で利用してきた。その経験から、Red Hat 5.1のUnix環境は「なかなか手堅い」と感じたという。だが「若干の愚かな点」もあって、「たとえばカラー’ls’」などを今見ると、FVWM(Red Hat 5.1のウィンドウマネージャ)はいかにも古臭い。やはり古いソフトウェアであるxtermは、今もほとんど同じものだが、Red Hat 5.1では事情が違う。現在のxtermはtermcapを使えるように若干の改良が加えられている。そのため、Red Hat 5.1のxtermをリモートから、たとえばSun OSなどから使おうとしても、うまくいかない。

 Red Hat 5.1にはSSHが含まれていない。当時、SSHはまだssh.fiからダウンロードする必要があったのだ。Redelmeier氏は、マシンにログインするためにrloginとKerberosを使用した。OpenSSHの実行にはopenSSLのほかにRed Hat 5.1に含まれているものより新しいバージョンのZlibが必要だが、これをバックポートするのは気が進まなかった。Redelmeier氏は、新しいソフトウェアをこういった古いマシンで使用するときに「バックポートがバックポートを呼ぶ」可能性があると警告した。

 セキュリティも初期状態のRed Hat 5.1ではお粗末だが、これについては未確認の要因が多く関わってくる。

 新旧のディストリビューションを比較する過程でもう1つ学んだのは、”bitrot”(読み取り不良)の問題だ。パッケージに同梱されていた、プレスされたオリジナルCDは問題なく読み取れたが、CDケースに接着されていたアップデート用のCD-Rはもう使えなかった。読み取り不良を避けるには、大事なデータの保守を欠かさないことだと彼は忠告した。

Linuxミラーサイトの問題

 kernel.orgミラーの管理者John Hawley氏は、午後の講演で「ミラーリング管理者が声を限りに訴えたい問題」について発言した。

 Hawley氏の主張はこうだ。ミラーリングを必要とするさまざまなディストリビューションのために、すべてのミラーサイトが5.5テラバイトのストレージを提供できるわけではない。1テラバイトしか用意できないミラーサイトもある。にもかかわらず、多くのディストリビューションは数百ギガバイトのアーカイブをミラーに放置している。こういったアーカイブを残すかどうかの選択権をミラーリング管理者に与えてほしい。FedoraとMandrivaだけでミラーストレージの半分が埋め尽くされるのに、2分の1テラバイトしかないDebianがアーカイブの後始末に応じても焼け石に水だ。他のディストリビューションがミラーのフットプリント削減に取り組まなければ、いずれミラーリングは不可能になるだろう。

 ミラーサイトではディスクキャッシュが大きな制約となっている。ディスク入出力は、どのミラー処理においても最大の要素だ。2000人のユーザがディストリビューションを同時にダウンロードする場合、サーバが送信データをキャッシュできなければ、ミラーサイトはパフォーマンスを維持できない。キャッシュが満杯になると、ディスク入出力が増え、ディスクのスラッシングが始まり、負荷が上昇し、最後はHTTPデーモンを再起動しない限りほとんど制御を取り戻せない状態に陥る。

 処理セットをできるだけ小さくして欲しい、とHawley氏は要望する。氏のサーバはメモリが24GBあるが、最近のディストリビューションには50GBに達するものさえある。ディストリビューション全体を配信するには、その一部をどこかの時点でディスクから読み取らなければならない、ということだ。メモリには半分しか入らない。複数のリリースが同時に追加されると、たちまちミラーサイトはパフォーマンスを維持できなくなる。

 Hawley氏が希望するのは、リリースが集中しないようにディストリビューション間でスケジュールを調整することだ。「マークはああ言いましたがね、悪い考えですよ!」と、Mark Shuttleworth氏の基調講演に異を唱えた。そして、一例として去年Fedora、openSUSE、CentOSのリリースが3日間に集中したときに、ミラーサイトが泥沼にはまったことを挙げた。そうなると「我々は水に沈んだ死体ですよ」と彼は表現した。お願いだから、リリースが他のディストリビューションと同じ週に重ならないよう、チーム間で調整して欲しい、と彼は懇願した。

 さらに、ディストリビューションはミラーサイトの運用者をリリース計画の輪に加える必要があると強い口調で提案した。ひどいときには、あるディストリビューションが新しいバージョンをリリースしたことが、ミラーサイトのトラフィックが突発的に増えたことで初めてわかることさえある。リリースを準備しているときは、明確にその事実を記した電子メールを何度かミラー管理者に送信して通知して欲しい。

 Hawley氏はさらに次のように論を進めた。BitTorrentを好む管理者が多いとは聞いたことがない。ユーザは、ピース単位で処理されることからBitTorrentがベストだと思っている。要望があるためディストリビューションやミラーリング管理者は応じているが、BitTorrentの短所についてユーザに周知するべきだ。

BitTorrentはなぜ有害か

 元々は、複数のユーザが他人のダウンロード済みデータからダウンロードできるようにする、というのがBitTorrentの発想だった。これは、大規模なデータセットを持つがダウンロードの件数は少ないプロジェクトに適している。しかし、ボリュームが増えると、BitTorrentは「ばったり倒れて」しまう。クライアントはトラッカーに接続して次のセグメントの入手先を確認し、そこにあるもののチェックサムをチェックする必要がある。トラッカー自体が障害の発生ポイントとなり、ダウンロードのボトルネックとなる。BitTorrentにはミラーとダウンローダの概念がなく、すべてのユーザがその両方の役割を負う。これはまた、BitTorrentのいずれかのユーザが最大公約数になるということでもある。たとえば、大勢のダウンローダのなかに56Kダイヤルアップユーザが1人いた場合、このユーザのモデムから情報を得るために残りの全員が待たされてしまい、全員のダウンロード速度が大幅に低下する可能性がある。

 BitTorrentは、誰にとっても複雑である。ミラーサイトでBitTorrentを稼働するために手動のセットアップ作業が増える、ダウンロード速度も遅い、BitTorrent全体をまともに稼働することは大規模なミラーサイトでさえ厳しい。

 Hawley氏は、グラフを投影して、Fedora 8がリリースされた週の数値を示した。あらゆるソースにおけるBitTorrentによるFedora 8ダウンロードの総数は、kernel.orgミラーサイトからのBitTorrent経由ダウンロードの総数にほぼ匹敵した。Fedora 8関連のBitTorrentデータの実に25%がkernel.orgミラーサイトに由来するものだった。

 ミラーリング管理者がBitTorrentのセットアップを主に手動で行う必要があることも、問題点の1つである。BitTorrentには、既存のトレントを自動的に検出して登録する機能もなければ、既存のデータからトレントを簡易に作成する機能もない。これを別にしても、データをチャンクに分けて配信するその方式はサーバにディスクスラッシングを引き起こす。BitTorrentは気味が悪いほど盛んにディスクをシークするため、主にクライアント側で、ミラーサイトから直接ダウンロードする方式と比べて400倍もの負荷をディスクに与える。

 Webサーバーでは、sendfile()カーネル関数のみを使ってファイルを取り出し、送信する。BitTorrentの場合、ファイルは小さなチャンクに分割されるため、いちいちシークして配信する必要がある。BitTorrentが今後もミラーサイトをスラッシングし続けるようであれば、ミラーサイトはこの配信方式に参加しなくなるだろう、とHawley氏は警告した。

 Linuxディストリビューションのリリースをピアツーピアで配信する必要性は認めるが、BitTorrentはその解答ではない、とHawley氏は結論付けた。

まとめ

 Ottawa Linux Symposiumは、今年で記念すべき10年目を迎えた。主催者によると、今年の参加者は600名を数えた。米国の景気後退とOSCONとの開催期間の重複にもかかわらずである。OLSの伝統的な開催週にぶつけてきたのはOSCONのほうで、来年もこの週になる予定。基調講演者Mark Shuttleworth氏を含め、一部の参加者は両方のコンファレンスをかけ持ちすることになった。

 10年続けてOLSの会場となっていたOttawa Congress Centreは、老朽化のため、来年から3年間を費やして建て直される。そのため、OLSは「路頭に迷う」ことになり、来年はモントリオールのCentre Mont-Royalで開催される。日時は未定。

 Andrew Hutton氏と共にOLSの中心的な主催者であるCraig Ross氏は、伝統にのっとって、最終日の最後に閉会宣言を行い、統計を発表した。過去10年間の参加者は約5,000人、講演数は850、大使館からの電話23件、政府当局からの電話11件、閉会式中に噴水に入って寝てしまった参加者2人(そんなバカなと思うかもしれないが、会場ではアルコールがふるまわれていた)、空になったドリンクのボトル50,000本以上。

 もちろん、コンファレンス期間中に発行されたTシャツのサイズを写したスライド ─ 撮影者はYani Ioannou氏 ─ を映写する恒例行事もあった。これは、Linuxコミュニティが大きくなったという証拠なのだ。

Linux.com 原文