BSDから見たLinux
NewsForge：LinuxカーネルとBSDには ─ もしあるとすれば ─ どのような類似点や相違点、シナジー効果がありますか?
Theo de Raadt：もう誰でも知っているはずですが、Linuxが単なるカーネルであるのに対して、OpenBSDは複雑なUnixシステムであり、カーネル、デバイス・ドライバ、ライブラリ、userland、開発環境、マニュアル、そして開発の継続に必要なすべてのツールが含まれています。つまり、機能の完全性という点だけでも、Linuxディストリビューションと同様に論じることはまったくできません。
したがって、システムに（セキュリティやその他の）変更を加える必要があるとわかった場合、userlandからライブラリ、そしてカーネルに至るまで一貫して変更を加え、システムに変更を強制できます。インタフェースの変更も思いどおりです。すばやく方向を転換できます。それまでの実行ファイルを壊す変更を加えることもありますが、それが必要であるなら、その決断を下せます。
これにより、すばやい前進を可能にする高い柔軟性が得られます。設計に誤りが見つかって、修正にはカーネルの変更だけでは済まない場合でも、修正を行えます。必要な変更は正しい場所に対して加えられます。問題を修正するため、不適切な場所に対してトリックを弄する必要はありません。
Christos Zoulas：開発の時期と方法が違いますから、その帰結として、2つのカーネルには多くの相違点があります。NetBSDソースの一部には30年を超える歴史があり、現在までに多くの改訂を重ねてきました。そのため、不要なゴミや複雑さが残っているサブシステム（シグナル伝達やネットワーク・バッファなど）もあり、これがコードをわかりにくく、変更しにくくしているため、開発に時間がかかります。ですが、それ以外のコードはずっと最近のもの（VMサブシステムやドライバAPIなど）であり、簡単に扱えます。と同時に、コードは安定しており（ほとんどのバグは取り除かれている）、明快かつ一貫して見えます。NetBSDではアーキテクチャ中立という方針が採用され、バスおよびI/Oの層が抽象化されていますが、これが明快で共有可能なデバイス・ドライバという形で結実しています。私がNetBSDカーネルに感じる主な不満は、以下の点です。
- マルチプロセッシングの問題：NetBSDはマルチプロセッシングをサポートし、スレッドのサポートがあるが、シングル・プロセスからのスレッドは複数のCPUを利用できない。カーネル内には一度に1つのプロセスしか存在できない。
- ジャーナル・ファイル・システムまたは巨大なファイル・システムのサポートがない。
- 使用可能なデバイス・ドライバが全般的に足りない。
Linuxのコードは、NetBSDよりもずっと新しく、絶えずリファクタリングが行われています。これには、（VMやFSなどの基本システム層において）コードが単純かつ読みやすく保たれるという好ましい副産物がありますが、安定性は犠牲になります。2.4.xはしり上がりに安定性が向上しましたが、2.6.xは一進一退を繰り返しました。私がLinuxカーネルに感じる主な不満は、以下の点です。
- メモリ不足解決機構（OOM killer）（メモリリーク？）
- ファイル・システムの安定性：Linuxにははるかに多くのファイル・システムがあり、力を入れているファイル・システムがディストリビューションごとに異なる（たいていは技術的な利点ではなく政治的な理由でそうされる）。ほとんどのディストリビューションは大きなファイル・システムをサポートし、ジャーナリングが実行される。残念なことに、一部のファイル・システムは安心して利用できるものではないのだが、一般のユーザが選択するときの判断材料となるような本当の意味での負荷テストが存在しない。
- 全般的なデバイス・ドライバの安定性。
NetBSDカーネルは、すべてのプラットフォームにおいて同じAPIを使用します。NetBSDのシステムコール#nは、すべてのプラットフォームで同じであり、同じ引数を受け取ります。Linuxカーネルは、各プラットフォームでネイティブのオペレーティングシステムを模倣しようとするので、システムコールは異なります。そのため、ヘッダー・ファイルはプラットフォームによって相当異なり、Linux/i386上でコンパイルできて動作するプログラムが、Linux/SPARC64上ではコンパイルおよび動作できるかどうかわからないということになります。
このインタビューでは、主にこの2つのカーネルに焦点が置かれている。NetBSDは、すべてのプラットフォームにおいて一貫性を持つ完全なオペレーティングシステム・ディストリビューションであるが、Linuxは、ディストリビューションが違えば同じプラットフォームであっても一貫性はない。
NF：BSDはLinuxカーネルよりも技術的に正しい、といまだに考える人がいます。以前、Linus Torvaldsは技術がすべてではないと発言しました。ご自分が手がけているBSDプロジェクトが、GNU/Linux（全般）の一部またはすべてより技術的に優れているとお考えですか?
Theo de Raadt：わかりません。Linuxを使ったことは一度もないので。
Christos Zoulas：NetBSDのコードの方が明快で、ドキュメントも充実しています。カーネル関数を含め、すべてのものにマニュアル・ページがあります。Linuxは、マニュアル・ページではなくFAQ、HOWTO、多種多様な形式で用意された散発的なドキュメントに頼っています。反面、NetBSDには、LinuxにあるACPI対応サスペンド/レジュームサポートや、アクセラレートグラフィックスドライバなどの機能が欠けています。
統合されたフロントを通じて、単一のCVSリポジトリからNetBSDに簡単にアクセスし、完全なシステムを最上部から構築できます。不特定の他人によってパッケージ化されたビルド済みのバイナリをつぎはぎし、試してみるのが常套手段となっているLinuxとは違います。また、別のNetBSDプラットフォームや、場合によってはLinuxやWindowsなどの他のOS上でNetBSDプラットフォームをビルドすることもできます。この方法を使うと、低速なプラットフォームに使用するバイナリを数日間ではなく数時間でビルドできます。
Linuxディストリビューションでは、あらかじめビルドされてインストールされた多数のバイナリが基本OSに含まれていますが、NetBSDでは、pkgsrcを利用し、必要に応じて追加のパッケージをビルドします。こういった事情からLinuxディストリビューションは太りすぎのように思えますが、最近はディスクの容量が大きいですから、大きな問題ではありません。気軽に利用するユーザにとっては、必要なものを持ってきて再ビルドしなければならないのは、余計な手間です。
システムプログラマにはNetBSDの方がよいでしょうが、前記の機能を必要とするエンド・ユーザにはLinuxの方がよいと思います。
思うにどちらのプロジェクトも、特にLinuxは、品質管理とテストに改善の余地があります。これまでの各Linux 2.6リリースでは、マイナーリリースのたびにそれまでのバグは修正されたものの、新しいバグも作り込まれています。NetBSDがこのような深刻な退行に悩まされたことはありません。おそらくその理由は、コードが大胆にリファクタリングされないからです。退行テストをLinuxに追加しようという真剣な努力は最近見られますが、NetBSDではしばらく前からこのテストが実施され、さらに追加され続けています。これと関係することですが、どちらのプロジェクトも負荷テストを増やすべきです。I/Oやファイル・システムのベンチマークを実行し、多数の後戻りテストを実施すれば、開発へ与えるメリットは非常に大きいでしょう。
NF：5年前にはBSDがGNU/Linuxより技術的に進んでいたとしても、今は同じ土俵に立っていないでしょうか?
Christos Zoulas：Linuxは、だいぶ、特に2.6で差を詰めてきました。かつて2.4では、Linuxカーネルには同じデバイス・ドライバに12のコピーがありました。サポートするアーキテクチャとバスの組み合わせごとに1つずつあったのです。今、ほとんどのドライバでコピーは1つです。2.4のI/Oパフォーマンス問題は、2.6で大幅に解消されました。Linuxが強化された背景にある最大の要因は、商用ベンダが基本カーネル機能（IBM）、ファイル・システム（SGIのXFS）、サードパーティ製ドライバをサポートするようになったことです。
NetBSD 2.0のスケジューラ・アクティベーション・ベースのpthreadsは、多くのことを約束し、マルチプロセッシングの問題が対処された暁にはパフォーマンスを大幅に強化するでしょう。どちらが優れたカーネルかは、一概に言えません。思うに、その答えは、カーネルのどの機能に注目するかで違います。包括的なパフォーマンスや機能のベンチマークで判定すべきことですね。
NF：Free/Open/NetBSDとLinuxカーネルの間では、共有が一般化しているのでしょうか? もしそうなら、双方向の共有でしょうか?
Theo de Raadt：私の知る限り、そういうことはまったくないです。私たちのコードは誰でもどんな方法でも（著作権の保護を変更しないという条件付きで ─ 単に「クレジットを受けるべきものにはクレジットを認めよ」ということですが）完全にフリーに利用できるのに、Linuxの人々は使おうとしません。
Christos Zoulas：私の考えでは、共有は双方向で行われています。特に、NetBSDが既に移植されているアーキテクチャにLinuxを移植する場合（またはその逆）がそうです。両プロジェクトの規模の違いやLinuxにはドライバが豊富なことから、NetBSD開発者がLinuxデバイス・ドライバのコードを参照して、そのデバイスに特有のクセやドキュメントに書かれていないデバイス・プログラミング情報を得るケースの方が多いのではないでしょうか。そうする必要があるのは、ハードウェア・ベンダが製品に関する適切なドキュメント（および完全な正誤表）を常に公表するとは限らず、機能するデバイス・ドライバを手に入れるには、試行錯誤を繰り返すか、リバース・エンジニアリングに訴えるか、必要な情報を非公式な手段でベンダから入手するほかに方法がないからです。すべてのオープンソース製品（OpenBSDは例外）が、ドキュメントの提供されない製品をサポートするために、ベンダから提供されるドライバ（バイナリのみの場合も多い）を使うという現状に甘んじているのも、事態を悪くしています。OpenBSDのスリム化戦略が進むべき方向とは思いません（結果は出つつあるようですが）。適切なドキュメントを公表することが得になるとハードウェア・ベンダを納得させられると思いますが、すべてのオープンソース製品がそのために一致団結する必要があります。ベンダを納得させられなければ、背を向けることで意思表示し、そのハードウェアをサポート対象から外す必要があります。
NF：Linuxにあるもので、Free/Open/NetBSDカーネルで採用して欲しいと思うものはありますか?
Theo de Raadt：ありませんね。私たちのソースツリーは完全にフリーです。敬意を示す限り、目的を問わず誰でも利用できます。ですから、商用コードをこのソースツリーに取り入れることは容認できません。また、GPLが適用されるコードが入り込むことも認めません。GPLの制限は「give credit」の域を超えています。
Christos Zoulas：Linuxにある細粒度の対称型マルチプロセッシング、リアルタイム・サポート、豊富なドライバなどがNetBSDカーネルにあればうれしいですが、実際にはLinuxのコードを取り入れることはできません。技術的に不可能だからです。カーネルAPI間の相違点を埋め合わせるのは、コードを最初から書き直すよりずっと時間がかかります。例外的なケースがあったとしても、NetBSDカーネルをGPLから無縁にしたいので、そのようなコードを使うことはないでしょう。
編注：このインタビューへの参加をFreeBSDプロジェクトに打診したが、期限までに回答がなかった。
原文
