9. Q & A
フロアからの質問
(仙田さん撮影, 1995)
- Q: DEC Alpha への移植について。あるプログラム(ghostscript)を DEC Alpha マシンに移植しようとしているのだがうまくいかない。何かアドバイスを貰え ないだろうか？
- Q: 他の機種への移植に関して Alpha ではバイナリ互換ということだが、他の 機種ではどうか？
- Q: WINE についてもう少し教えて欲しい。
- Q: マイクロカーネルとモノリシックカーネル、どちらがいいんだろう？
- Q: カーネルモジュールはある意味ではマイクロカーネルみたいなものでは？
- Q: カーネルのドライバの中で PPP モジュールなどはモジュールとしてのみ提 供されているが、そうすることに何か意味があるのか？
- Q: 1.3.x 用には kerneld というデーモンがあるが、1.2.x 用にも kerneld は あるのか？
- Q: 以前は PC 上で MS Windows を使っていたんだけど(ここで Linus が指で バツ印を作り、会場が笑いに包まれる)、Linux に切りかえたら、そのパフォー マンスのよさにびっくりした。なぜ、Linux のような free な OS が Microsoft のような巨大企業の作るソフトよりも性能がいいんだろう？
- Q: Microsoft からあなたに何らかの接触されたことはないのか？
- Q: 私自身、科学計算ライブラリを作ろうとしているのだが、そのようなソフ トウェアプロジェクトを計画している人に対して Linux というビッグプロジェ クトを成功させた立場から何かアドバイスを。
- Q: Linux の開発に携わっている人はどれくらいいるのか？
- Q: GNU Hurd について一言？
- Q: Linux はさまざまなプラットフォームに移植されているが、それらの間で バイナリの互換性はあるのか？例えば Intel CPU 用のバイナリが Alpha で動 く、といったような。
- Q: Java のサポートは？
- Q: Debian は Gnu 版の Linux と聞いたが？
- Q: VIPER というプロジェクトはどうなっていますか？
- Q: copyleft ソフトウェアは将来どうなるだろう？
- Q: 今手に入れられる最速の Linux マシンは？
A: Alpha への移植の際にユーザーレベルのプログラムで特に問題になるのは 32 ビットと 64 ビットの問題だろう。例えば、 int と long を同じとみなし ているプログラムもあるが、これは Alpha では成立しない。その場合、プロ グラム中の long を int に置きかえてやればいい。ただ、これだけでは不十 分な場合もあって、Alpha ではポインタも 64 ビットになっているので、ポイ ンタを int と同じとみなしているプログラムは問題になる。これらを手がか りに調べてみてはどうか？
A: Alpha については、僕自身 Digital UNIX のバイナリプログラムをいくつ か持っているので、テストのためにもバイナリの互換性を追及している。きち んと動くバイナリプログラムがあればカーネルのテストにも便利だからね。
Sparc についても SunOS とバイナリ互換にしたいと思っている。SunOS との 互換性はかなりなところまでいっているみたいだけど、Sparc Linux はまだま だ不安定みたいだ。
mips についてはあまりバイナリ互換性は期待できないだろう。DEC もかって は mipsマシンを作っていたことがあるが、DEC の mips マシン用のバイナリ はほとんど無いし、今、mips を使っている SGI のマシンはレンダリングといっ たプログラムに特化しているのであまり Linux ユーザに便利なバイナリはな いだろう。それに SGI は特殊なマザーボードを使っているので、バイナリ互 換は困難だと思う。もっとも、僕自身 mips についてよく知らないから、詳し くはドイツで mips への移植をやってる人たちに聞いて欲しい。
A: WINE は WINdows Emulator の略で、MS-Windows 用のプログラムを X11 上でエミュレートして動かすためのプログラムだ。ちょうど SUN の WABI と 同じことを free なプログラムで実現しようとするものだ。
A: どちらにも一長一短があると思う。僕は昔マイクロカーネルの minix を使っ ていたことがある。確かにいくつか気にいった部分はあったが、minix はあく までマイクロカーネルを使った OS の教材として書かれているので、全体とし ての性能には不満で、マイクロカーネルのあまり適切な例ではないように思っ た。だから、minix の欠点を取りこまないように Linux をデザインしたつも りだ。もちろん、minix は OS の働きを理解するための教材としてはいい例だ と思うけどね。
minix よりもいいマイクロカーネルはいくつもあり、例えば Mach もその一つ だ。でも Mach はすごく複雑な OS になってしまっている。Mach の複雑さの 大部分は性能の向上を目指すための工夫で、マイクロカーネル化による性能低 下をカバーしようとして、必要以上に複雑になっているように思う。
A: たしかに、ある部分についてはマイクロカーネルと同じことをしようとし ている。しかし、カーネルモジュールは動いている時でも、カーネルに直接リ ンクされてしまうので、マイクロカーネルのようなプロテクションバウンダリ に関する問題は起こなさい。
A: PPP をモジュールとしてのみ提供するというのは僕が決めたことじゃない。 ppp の開発者である Al Longyear がそう決めたんだ。彼は多分モジュール化 することでデバッグが容易になると考えたんじゃないかな。つまり、モジュー ル化しておけば、カーネル全体を作り直さなくても新しいモジュールをロード することで、新しい ppp のテストは可能になるからね。
A: 1.2.x では insmod/rmmod といったモジュールをロードするためのツールが 用意されている。それは 1.3.x でも同じように使える。kerneld は、その手 順を自動化するためのものなので、insmod/rmmod を使いつづけても構わない。
A: 「なぜ Linux は Windows よりも高性能か」これは僕の大好きな質問だね (会場笑)。これには 2 つの理由があると思う。1 つは、Linux は熱意に満ち た開発者が作っていること。僕を含めて、カーネルを書こうと言う人間は「完 璧な」コードを目指している。だから、もし何か問題が起きたら、その問題を 自らの手で積極的に解決しようとしてきた。
一方、Microsoft のような巨大企業だと、Windows のソースコードは誰のもの でもないから、誰もそれに誇りを持てないんじゃないかな。一方、Linux の開 発者は Linux のコードに誇りを持っている。それに Windows だと担当してい るプログラマが 100 人を超えているだろうから、問題が起きても、積極的に 自分の手で解決しようとせずに、どこか別の人に送ってしまう、すなわち問題 を解決するのではなく、隠すことで解決しようとしているんじゃないかな。僕 は、それが Linux と Windows の性能の違いになっているように思う。
もう1つの理由は「互換性」の問題だ。Microsoft の製品は DOS, 特に DOS の ファイルシステムと互換性を保つ必要がある。すなわち、彼らは 15 年も前の 悪いデザインに縛られている。その結果、現在でも 15 年前と同様の悪い方法 を取らざるを得ない。それに対し、Linux は 0 から書き始めた OS だから、 過去のしがらみはない。Linux が目指した Unix は、もともと優れたデザイン の OS だったしね。僕は全てを 0 から始めたから、同じ間違いをしないよう に気をつけたし。
A: Microsoft は我々のことなんか気にしてないんじゃないかな？ Microsoft のユーザーは 5000 万人、Linux のユーザーは推定で 50 万ってところだから、 彼らのユーザーの 1% に過ぎないしね。でも、将来は彼らも Linux のことを 脅威に感じてくれればいいなと思うよ(会場笑)。
A: Linux での経験から僕が言えることは、まず何か基本的な小さなシステム を作って、それはそれほど優れたものでなくてもいいから、それをネットワー ク上で公開することだ。そうすると、世界中に同じようなソフトウェアを欲し がっている人がきっと見つかるだろう。そして、君のシステムに関心を持って くれる人を見つけて、彼らと共に開発していくことだ。それがまさに Linux に起こったことなんだ。
僕が作った最初の Linux は、ほんとうにごく基本的なものだった。でも、多 くの人の協力で、今あるような素晴しいシステムに成長していった。だから、 そういう風に開発するのが一番いいんじゃないかな？関連するニュースグルー プに投稿して、自分と関心を同じくする人を見つけることから始めるのも手だ ろう。
A: Linux の開発者の数は、数え方によって変るね。もしカーネルの大部分を 書いた主要な開発者に限るなら、10 - 20 人程度だろう。デバイスドライバを 書いた人やカーネルの小さな改良に貢献してくれた人まで含めると 100 - 200 人規模になるだろう。カーネルと同等かそれ以上に重要なユーザーレベルのプ ログラム、例えば gcc や X11 なら、それぞれにまた何百人もの開発者が関わっ ているから、それらを全て含めたら、何千人の規模になるはずだ。経験を積ん だプログラマをこんなに多く抱えているソフト会社は存在しない。普通の大き なソフト会社でもプログラマはせいぜい数百人といったところだからね。BSD も含めて Unix のプロジェクトはいかにすごい数のプログラマに支えられてき たかがわかるだろう。
A: GNU Hurd についてはほとんど知らない。GNU Hurd の主要な開発者には会っ たことがあるけど、僕自身は Hurd のプロジェクトには全く関係していない。 現時点では、GNU の連中も Linux が GNU のカーネルだと思ってるみたいだけ ど、将来についてもそうだという保障はないね。ただ、Hurd は未来のプロジェ クトで、いつになれば使えるようになるのかわからない。
A: アーキテクチャー間のバイナリ互換といった機能は、将来とも Linux には 組みこまれないだろう。ただ、「バイナリトランスレーション」と呼ばれる面 白いプロジェクトがある。例えば DEC の人たちは mips のバイナリを Alpha で動くようにし、現在は intel のバイナリを Alpha 上で動かそうとしている。 この技術が使えるようになればアーキテクチャー間のバイナリ互換も可能かも 知れないが、多分彼らはその技術をフリーでは公開しないだろう。それに、こ のプロジェクトはずいぶん大規模なもので、個人がそう簡単に実現できるよう なものではない。
A: Linux 用の Netscape では Java がサポートされたと聞いている。ただ、 それはベータバージョンで、まだまだ不安定らしい。Alpha Linux 用の Netscape は存在しないが、Digital Unix 用の Arena が Alpha Linux でも使 えるようだ。
A: A: Debian は元々 Gnu とは関係ないディストリビューションだったが、GNU の連中が彼らの公式の Linux ディストリビューションを作る時に Debian を 選んだ。技術的にも Debian は slackware よりも優れていたしね。僕自身は slackware しか使ったことはなく、Debian は試したことはないけど、実際に 使っている人は Debian は優れている、と言うね。それに、個人的には RedHat のディストリビューションも優れたものだと思っている。でも、 slackware が一番広く使われているね。
A: 一年くらい前に、スレッドとリアルタイムのサポートを目指して VIPER と いうプロジェクトが始まったが、最近はその名前を聞かないね。スレッドとリ アルタイムはまだ不完全だけど、公式のカーネルでサポートを始めたので、 2.0 までにスレッドのサポートを完成させたいと願ってはいる。
A: 僕は copyleft が全てに正しい解だとは思わない。でも、Linux を含めた いくつかのプロジェクトにとっては copyleft は素晴らしい解だ。でも、僕は 著作権(copyright)で保護された商用ソフトウェアも必要だと思っている。こ の点で僕は GNU の連中とは意見を異にしている。彼らは全ての商用ソフトウェ ア無しでやっていこうとしているからね。
僕自身は、あまりおもしろみがなく free software が生まれないような分野 の仕事は商用ソフトウェアが必要だと思っている。たとえばデータベースといっ た分野がそれだ。
僕は Linux 用にもっと商用のソフトウェアが出てきて欲しいと思っている。 その一方で、新しいソフトウェアがフリーに公開されていくことも望む。この 両者は互いに対立する排他的なものではなく、両方とも同時に使うことはでき るんじゃないかな？
A: 今のところ、150MHz の Pentium Pro マシンが最速の Linux マシンじゃな いかな？ 僕は、家では Alpha を使っているが、このマシンは Alpha の第一 世代のマシンで最速のマシンじゃない。第二世代の Alpha マシンではまだ Linux が動いていない。その主な理由は僕がその種のマシンに触れていないこ となんだけどね(会場笑)。
Pentium Pro を持っている人によると、カーネルのコンパイルが 4 分で終る らしい。僕が大学で使っている 100M Hz の Pentium では 10 分くらいかかる から Pentium Pro は確かに速いと思う。もっとも Penitum Pro は Windows のバイナリを動かすと遅いそうだけど、僕はそんなの関係ないしね(会場 笑)。
------------------------------------------------------------------------
こじまみつひろ＠りむねっと
------------------------------------------------------------------------
(SGML conversion, Y.Senda, 2000/12/20)