レンタルサーバ + Webシステム開発 = E-business
|
レンタルサーバ + Webシステム開発 = E-business
|
|
■レンタルサーバご利用参考資料 サーバご利用の参考にJF Project によるJF (Japanese FAQ)を掲載しています。
Linux JF(Japanese FAQ)Project. 一覧に戻る
Linus Torvalds 来日講演会 (1995/12/04)
Linus Torvalds
日本語訳 / こじまみつひろ
1996/06/02
1995年12月4日に京都大学で行なわれた、Linus Torvalds さんの来日講演会の
模様(全訳)です。
当日や来日の間の Linus さんの様子を知りたい方は、 http://
jf.gee.kyoto-u.ac.jp/JF/linus-japan.html を御覧下さい。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Table of Contents
1. Linux とは何か
2. Linux の基本デザイン
3. モノリシックカーネルについて
4. Linux の開発方針
5. カーネルを書く際の注意点
6. 移植性について
7. カーネルの側から見た未来
8. Linux の将来像
9. Q & A
1. Linux とは何か
僕がヘルシンキ大学のリィナス・トルヴァドゥス、Linux カーネルの開発者で
す。僕の英語が通じるかな？質問の時に、みんなの英語が僕に通じるとうれし
いけど。(会場笑)
[linus]
(川井さん撮影, 1995)
僕はわいわいにぎやかな講演が好きだから、もし質問があったら、途中でも遠
慮しないで手をあげて質問してね。
まず、この講演を実現してくれた小野さんと小島さんにありがとう。さて、そ
れではざっと今日何を話すつもりかを紹介しよう。
(OHP 1)
-----------------------
・What is Linux
・Design Issues
・Basic Design
・Development Cycle
・Kernel vs User Level
・Portability(DEC Alpha)
・Work in Progress
------------------------
僕の話は、Linux とは何か、ってところから始まるんだけど、この中で Linux
をよく使っている人は？(多くの手があがる)
Linux について聞いたことの無い人は？(ちらほら手があがる)
なぜ、君たちはここにいるんだい？(会場笑)
多くの人が知ってるようなので、「Linux とは何か」という話題は簡単に済ま
せて、「Linux の基本デザイン」の話題を中心に話そう。
kernel のプログラムというのは、通常のプログラムとはどこが違うのか、とい
うところから始めよう。この中でプログラマやプログラム、コンピュータ科学
を専門に勉強している人はどれくらいいるのかな？(ちらほら手があがる)
あんがい少ないね。じゃ、あまり細かい話よりも、今までに僕がやってきたこ
と、これからやろうとしていることを中心に話してみよう。
(OHP 2)
---------------------------------------
What is Linux
- Unix clone
- Source Compatible with "UNIX"
- Binary Compatible
---------------------------------------
これが僕が「Linux とは何か」を説明するために使っているスライド。みんな
知ってることばかりで、あまり目新しいことは無いと思うけど。
「Linux」は「Unix クローン」、すなわち、Linux は例えば BSD のカーネルと
は違って(AT&T が持っていた)元々のUnix のソースライセンスは使わずに、
Unix とほとんど同じことができることを目指したカーネルなんだ。
IBM PC 互換機(クローン)が元々の IBM 機とよく似てるけど、IBM 機よりもず
っと性能がいいのと同じように、僕は Linux が元々の Unix よりも優れたもの
になることを期待している(会場笑)
「クローン」だからといって、全てがオリジナルと同じである必要はない。で
も、僕は Linux を全く新しい OS にするつもりはなく、基本的には Unix のよ
いところを活かすように作った。例えば、マルチユーザー、ネットワーク、メ
モリプロテクションなどなど。Linux には元々の Unix にない機能もいくつか
追加されているけれど、そのような部分は本当に必要なところだけに限って、
最小限にしようとしている。
Linux にとって一番重要なことは Unix と「ソース互換」だという点だろう。
Unix にはいくつかの仕様があるけど、Linux はそのうちの POSIX(Portable
Operating System Standard)に基づきながら、Unix 使いのみんなが使いやすい
ように BSD や SYSV の機能を取りこんで拡張してきた。だから、BSD の世界か
ら来た人が Linux で全てが BSD と同じように動くからビックリしたという話
もよく聞く。
「ソース互換」という点に加えて、僕たちはいくつかの機種との「バイナリ互
換」も追及している。例えば "DOS EMUlator" というプログラムがあって、こ
れを使えば DOS のプログラムを Linux で動かすことができる。iBCS2 モジュ
ールは 386 系の CPU 用の市販の Unix プログラムを動かすためのものだ。こ
れを使えば SCO Unix 用のプログラムを Linux で動かすことができるので、
SCO 用の WordPerfect を Linux で使うこともできる。また、DEC Alpha 用の
Linux では Digital Unix とバイナリ互換なので、Digital Unix 用のプログラ
ムを Alpha Linux で動かすことができるはずだ。
最後に Linux で MS-Windows のソフトを動かすプログラムも開発中だ。WINE
という名前で、まだ完成していないけど、いくつかの Windows 用のプログラム
、例えば「ソリティア」(会場笑)や「マインスイーパー」(会場笑)といったプ
ログラム、ある人によると、これが Windows で一番重要なプログラムだそうだ
けど(会場爆笑)、これらは既に Wine 上で動いている。「Word」のようなプロ
グラムはまだ動いていないけど、多くの人が動かそうと作業中だ。
これが Linux の売上げを示すスライド。世界中にいる Linux ユーザーの数を
推測したグラフだ。
(OHP 3)
----------+---------------------------
1,000,000 |
100,000 | |
10,000 | |
1,000 | |
100 | |
10 | |
----------+---------------------------
1991 92 93 94 95
実際には、僕は Linux を売りあるいてるわけじゃないけどね。この図の縦軸は
対数表示になってるから、一つあがるごとに 10 倍になってるのに注意して。
1991 年にはたった一人の Linux ユーザーしかいなかった、すなわち僕自身、
でもその年のうちに、僕以外にも何人かの Linux ユーザーが誕生したので、
1991 年の終りには、おおむね 10 人くらいの Linux ユーザーがいたはずだ。
その後の Linux ユーザーは、この対数グラフで示すように、指数関数的に増加
している。数学を知ってる人はわかってるだろうけど、この直線を延していく
と、あと 2 年ほどのうちにはユーザーが 5000 万人に達し、その 2 年後には
、この星の人口と同じくらいのユーザー数になるだろう(会場笑)
もちろん、こんなに増加し続けるはずはないけど、カッコいいグラフだよね。
さて、実際の「デザインについて」の話題に入ろう。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2. Linux の基本デザイン
(OHP 4)
-----------------------------
Design Issues
- KISS
- Compatibility
- Performance
- Expandability
--------------------------------
Linux にとって最も重要なのは、「KISS principle」と呼ばれるものだ。KISS
とは "Keep it Simple, Stupid", あるいは "Keep it Simple and Small" の略
なんだけど、カーネルは元々すごく複雑なプログラムだから、ちゃんと動くよ
うにするには可能なかぎり単純にしておく必要がある。そうしようと努めてい
ても、今日のカーネルのようにずいぶん複雑なものになってしまうんだから。
もう一つ Linux のデザインについて重要なポイントは、「互換性」という点だ
。僕は Unix カーネルを自分で書きたかったけど、全てのプログラムを自分で
書く気はなかった。だから、gcc や GNU Emacs のような Unix 用の既存のフリ
ーソフトウェアが可能な限りそのままコンパイルできて動くことが重要だった
。
「互換性」の問題はプログラムを動かす場合だけでなく、Unix のようなネット
ワーク環境で使われる OS の場合、環境に対する「互換性」の問題も重要にな
る。だから、Linux はネットワーク的に見ても他の Unix と互換性を持つよう
に作っている。だから HP-UX や BSD などが動いている環境でも Linux は問題
なく使えるはずだ。
僕が自分の書く全てのプログラムで極めて重視しているのが、第三のポイント
、「性能(パフォーマンス)」だ。僕は遅いプログラムが嫌いで、手元の速いマ
シンの上に、ノロノロ動いているプログラムがあって、コンピュータ全体の性
能が落ちているのには耐えられない。だから、Linux はできるだけ速くしたか
ったんだ。そのため、新しい機能を持ったマシンが手に入れば、その機能を積
極的に活かして Linux のスピードアップを図ろうとしてきた。例えば Pentium
マシンでは Pentium の新しいメモリ管理機能を利用している。詳細には触れな
いけど、Linux は速い機種用に最適化されている、ということだ。もちろん、
古くて遅い 386 マシンでも使えるようにしていることは言うまでもない。もっ
とも、個人的にはそんな遅いマシンはもう使わないけどね。
4 つめのポイント、これはカーネルに限らず、あらゆるプログラムにとっても
っとも重要なポイントだけど、「拡張性」という点だ。「拡張性」についてき
ちんと考えていないと、3,4 年もしないうちにどうしようもなくなってしまう
ことがある。例えば DOS の 8 + 3 文字のファイル名の制限に関する問題は、
後になってからは極めて修正のしにくいものだ。マイクロソフトは Windows95
でファイル名の問題を解決しようとしているけど、多少コンピュータに詳しい
人なら、まだまだたくさんの問題が残っていることを知っている。
だから、この種の問題が起きないように、デザインのごく早い段階から十二分
に注意しておく必要がある。というのも、ユーザーが増えてきてから基本的な
デザインを修正することはほとんど不可能だからだ。
以上の 4 点が Linux の基本的なデザインの話。次にモノリシックカーネルに
ついての説明をしよう。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
3. モノリシックカーネルについて
(OHP 5)
------------------------
Basic Design
- Monolithic kernel vs Micro kernel
- Non pre-emptible
- Portability
-----------------------
コンピュータサイエンスを勉強している人は御存知だと思うけど、最近の新し
いカーネルはほとんどマイクロカーネルを採用している。しかし、マイクロカ
ーネルに比べてモノリシックカーネルはずっと簡単に書けるし、保守もしやす
い。だから、Linux はモノリシックカーネルになっている。
マイクロカーネルは多少良い点はあるものの、遅くて書くのも大変だという問
題点がある。このあたりについては多くの議論があるところだけどね。
マイクロカーネルの特徴は、システムは多数の小さなモジュールからできてそ
れらが互いに通信しながら OS の基本的な機能を果していることだ。一方、
Linux では一つのモノリシックなカーネルが全ての機能を果しているので、プ
ログラムはずっと書きやすくなる。もっとも、僕を含めた Linux の開発者たち
は、カーネルをできるだけ「モジュール化」しようとしており、ソースレベル
では機種に依存する部分はそれぞれ別のディレクトリに分かれているし、概念
的に区分されるドライバ類も別々のファイル、別々のディレクトリに分かれて
いる。
もう一つ、カーネルの基本的なデザイン上の特徴は、Linux カーネルは non
pre-emptibleだ、ということだ。すなわち、一つのプログラムだけがカーネル
モードにあり、その他のプログラムはカーネルモードプロセスにならない。こ
のようにしておけばプログラムはずっと簡単になる。競合状態やデッドロック
のような状態は non pre-emptible カーネルの方がずっと処理しやすい。
別の例で説明すると、例えば "10 goto 10" みたいな Basic のプログラムがあ
って、無限ループしているとしても、このプロセスはカーネルモードにないか
ら簡単に kill できる。カーネルモードにいるプロセスだけがマシンを完全に
コントロールしてしまうわけだ。
昨年あたりからは「移植性」についても考慮しはじめた。もともとの Linux は
80[345]86 が動いている PC しか対象に考えていなかったけど、1 年半前に
DEC が僕に Alpha マシンをくれたので、それ以来 Linux を異なる機種に移植
する、という問題が重要になってきた。
現在では、CPU に依存している部分はきれいに整理されて、僕も家では主に
Alpha マシンを使ってる。僕の持ってるマシンの中では、Alpha マシンがもっ
とも速いからね。
でも、現在の Linux では、ソースコードの約半分はデバイスドライバが占めて
いる。これらのデバイスドライバは機種にきわめて依存しているので移植が困
難だけど、DEC Alpha の場合、IBM-PC と同じ PCI バスを使っているので、移
植はそれほど難しくない。一方、sparc や 68k マシンの場合、デバイスドライ
バは 0 から書き直さなければならない。
(OHP 7)
---------------
kernel とそれを取りまく gcc, X11R6 といった基本アプリ、ユーザープログ
ラムを図示したもの
--------------
さて、このあたりで、僕が Linux の開発で果している役割は、本当はずいぶん
小さいものだ、ということを白状しておこう。この図は「Linux とは何か」を
示したもので、カーネルはこの円の中のブルーと赤の部分になる。それ以外に
も、多くの shell utility や daemon 類、X11R6 といったプログラム、その他
無数の "end user program" がある。この中で僕がやってるのは、この中心の
ごくわずかな部分だけだ。
例えば日本語の問題一つとってみても、たくさんの人々がカーネルの外側で日
本語を使えるようにコードを書いてる。でも、正直いって僕にとっては日本語
処理の問題点が何かすら理解できていない。だから、僕がやってるのは、本当
にシステム全体のうち、中心のごく一部だけなんだ。何千もの人が Linux 用に
、あるいは Unix 用にプログラムを書いてくれている。こんな人々のおかげで
、Linux は今日のように使いやすいシステムになったと言える。
次に Linux の開発方針について説明しよう。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
4. Linux の開発方針
(OHP 8)
-------------------------------------
Development Cycle
- Open Development tree
- Open Fast feedback
---------------------------------------
Linux kernel を開発するにあたって、僕は開発過程を公開すること(Open
Development tree)を選んだ。最新のソースコードを週に 2 度ほど、Internet
上の anon-ftp サイトに公開しているので、誰でも、僕が使っているのと同じ
最新のソースコードを入手することができる。もちろん、この公開のサイクル
はもっと頻繁なこともあるし、もっとまばらなこともある。例えば今週は日本
に来てるので、この一週間は新しいカーネルの公開ができない。
開発過程が公開されているから、C コンパイラを持ってる人なら誰でも、ソー
スを入手して僕の持っているのと同じ最新のカーネルを手元で作成できる。必
ずしも常に最新のカーネルを追いかける必要はないが、やろうと思えばそうす
ることもできる。カーネルは大部分 C 言語で、一部のドライバ類はアセンブラ
も使って書かれているが、コンパイルするだけならアセンブラの知識は不要だ
ろう。
開発過程を「公開」していることは、僕のような開発者にとって大きな利点に
なっている。なぜなら、新しいカーネルを ftp サイト上に公開すれば、その日
のうちに数十から数百人の人がさまざまな環境でテストして、もし僕が何か間
違いをしでかしていたら、すぐに e-mail で教えてくれるからだ。この結果、
問題はすぐ解決できる。このような feedback のおかげで、過去数日のあいだ
にやった修正のどこが問題だったかをすぐに知ることができる。
また、常に最新のソースコードが公開されているから、さまざまな開発者がバ
ラバラに開発した何十ものバージョンを誰かが一つに統合するような作業が不
要になるので、そのことも開発速度を上げることに役立っている。
もちろん、カーネルそのものにそれほど関心のない普通のユーザーが常に最新
のカーネルを使う必要はなく、CD-ROM 等に入っているコンパイル済みのカーネ
ルを使うこともできる。週に 2 回、新しいカーネルを公開しているからといっ
て、必ずしも最新のカーネルを使わなければならないわけじゃない。でも、最
新のカーネルをテストしてくれれば開発者としては助かるな。
会場からの質問
Ｑ: そんなに多くの人たちが開発に参加してるなら、どうやってドライバ
同士の衝突を避けているのか？
Ａ: 公開で開発している、ということは誰でも常に最新のカーネルを利用
できるということだ。
先に述べたように、Linux ではソースコードの「モジュール化」がすすん
でいるので、例えば僕がファイルシステムに何か変更を加えたとしても、
それはドライバの開発者に影響することはあまりない。すなわち、大部分
の変更は「ローカルに」行える、ということだ。カーネルそのものは何万
もの部品が集ってできているので、二人の開発者が同じコードを修正する
ような事態はまず生じないだろう。もしそのような事態が起きた場合、ど
ちらのコードを採用するかは両方のコードを見て僕が決めている。
カーネルは巨大なプログラムで最近だと 35 万行にも達している。最近の肥大
化したアプリケーションプログラムから見ると、35 万行ぐらいではそれほど大
きくないと言われるかも知れないが、35 万もの「複雑な」コードで書かれたプ
ログラムはあまり無いだろう。
我々開発者は一つの集団を構成している。そのピラミッドのトップに立ってい
るのが僕だが、僕以外にもネットワークコードを保守している人、ファイルシ
ステムを保守している人、SCSI デバイスを担当している人、などが存在する。
それぞれの担当者の下にも、同様により小さな部分を担当している人が存在し
ている。そして、例えばネットワークに関する修正点はネットワークの担当者
のところで集約され、僕に伝えられる。そして僕がそれを元にカーネルを修正
する、というわけだ。
もちろん、このシステムは強制力をもつものではないので、バグを見つけたら
僕に直接送ってもらっても構わない。実際、今までにも、見たことも聞いたこ
とも無い人からバグレポートとパッチが届いて、そのパッチをそのままソース
コードに組みこんだこともある。この開発者のピラミッドは、誰が何を成した
かによって、きわめて動的に変動するもので決して固定したシステムではない
。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
5. カーネルを書く際の注意点
(OHP 9)
-----------------------------------------------------
Kernel vs User Level
- Inherently multi-threaded
- Security
- Stack and Memory allocation
----------------------------------------------------
このスライドは Linux kernel を改造しようとしている人向けに基本的なとこ
ろを説明するためのものだ。この中で Kernel のソースコードを見たことのあ
る人は？(あまり手はあがらない)
あー、ずいぶん少ないね。他のところだともっと手があがるのにね。カーネル
のソースコードは読むとずいぶん面白いものだよ。僕がそう感じているんだか
ら。(会場笑)
カーネルを書く際に特に注意しなければいけないことが 3 点ほどある。
一つは「カーネルのマルチスレッド性」という点。カーネルは何百ものプロセ
スが動いているマシンを管理しているプログラムで、もし 2 つのプロセスが同
じことをしようとすると、どちらを先に処理させるかという判断をするのもカ
ーネルの仕事になる。カーネルを書く場合、競合状態やデッドロック状態に特
に注意を払う必要がある。普通のプログラムではこのような状態が起きること
は滅多にないし、これらにはなかなか気づかないんだけど。
カーネルのソースを初めて見た人は、「馬鹿みたい、なんで同じチェックを 2
回もするの」とか言いたくなるかも知れない。でも、それはカーネルにのみ起
りうることをチェックしてるんだ。
すなわち、それが「セキュリティ」ということで、我々が扱っているのはマル
チタスクシステムであり、普通のユーザーが書いたプログラムが少々問題とな
る振る舞いをしても、それがシステムダウンを引き起してはならない。すなわ
ち、一つのプロセスがシステムをクラッシュさせないように、カーネルの中で
は「セキュリティ」について十二分に配慮する必要がある。百人もの人が同時
に使っているマシンを何かのプログラムがダウンさせれば、他の人にずいぶん
迷惑をかけることになってしまうからね。
もう一つ、カーネルはシステム全体のメモリやプロセスを管理しているプログ
ラムだから、カーネル自身のメモリ管理は自分でやらなければならない。カー
ネルプログラムがもっとメモリが必要だと思っても、カーネルにメモリを要求
することはできない、だって自分自身がカーネルなんだから。だから、カーネ
ルのメモリアロケーションは自らの手でやらねばならない。
フロアからの質問
Ｑ: カーネルはずいぶん巨大なプログラムになっているが、カーネルにつ
いて勉強するとすれば、どこから手をつければいいのか？
Ａ: カーネルについて勉強したいなら、まずカーネルについて説明した良
い教科書を読むことだろう。僕が推薦するのは A.Tannenbaum の
"Operating System : Design and Implementation" だ。この本は専門書と
して抜群のものだとは言いにくいけど、読みやすいし、理解しやすい本だ
。この本で基礎的な知識を得たら、Linux のスケジューラのあたりを読ん
でみてほしい。Linux のスケジューラは、どのプロセスを走らせるかを一
つのファイルの中で処理しているおもしろいプログラムだから。
次に僕が現在取りくんでいる問題を話しておこう。僕が今取りくんでいるのは
、「移植性」に関する問題だ。Linux は御存知のように Intel 80x86 プロセッ
サから始まった。現在では多くの機種に移植が進み、先にも述べたように DEC
Alpha では既に安定に動いているし、MIPS への移植はドイツで進められており
、shell が動いたと聞いている。最近のカーネルではいくつか PowerPC 用のコ
ードが入っていることに気づいている人もいると思うけど、PowerPC ではまだ
動いていない。動くようになるにはもう半年くらいはかかるんじゃないかな？
SUN-4 といった Sparc への移植も進められているがまだまだ不安定な状態だ。
少し Alpha を例に「移植性」の話を詳しくしておこう。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
6. 移植性について
(OHP 10)
--------------------------------
Portability (Alpha)
- Memory management
- Processor management
- Device driver
- 64 bits vs 32 bits
--------------------------------
このスライドの最後のところから始めよう。それが一番おもしろいからね。
僕が Alpha を好きなのは、それが完全な 64ビットマシンで 64ビットのポイン
タと 64ビットのレジスタを持っているからだ。これは OS にも大きな変更を要
する。なぜなら、32 bits のマシンだと 4G バイトまでの空間しか確保できな
いけど、Alpha マシンでは 8T バイトまで管理でき、膨大な大きさの仮想メモ
リが使えるので、それをきちんと管理する方法を考えないといけない。
もう一つ、異なる機種に移植する際に大きな変更が必要なのはデバイスドライ
バの部分だ。ただし、先に述べたように Alpha は PC 互換機と同じ PCI バス
を使っているので、大部分のデバイスドライバは PC 用のものがそのまま使え
る。一方、sparc や Atari、Amiga と言ったマシンの場合、I/O バスの処理の
仕方が PC 互換機と根本的に違うので、デバイスドライバは全て 0 から書きな
おさねばならない。
プロセッサ自身ずいぶん違う。もちろん、32 ビットと 64 ビットという違いは
あるけど、それ以外にもメモリのアラインメントという問題がある。
386 ではメモリのどこでも自由にアクセスできるのでアラインメントという問
題は生じないが、Alpha の場合、8 バイト = 1 ワードをロードする場合はメモ
リのアラインメントを合わさなければならない。これもカーネルの仕事だ。キ
ャッシュやプロセッサの状態推移もプロセッサの機種ごとに異なっている。こ
れらの問題はユーザープログラムでは気にする必要はないが、カーネルにとっ
てはきわめて重要な問題だ。
メモリ管理については、ページテーブルや MMU の状態遷移をちゃんと処理する
のもカーネルの重要な仕事だ。
あまりプログラマ、特にカーネルプログラマはあまりいないようなので、次の
スライドは飛ばすね。
(OHP 11)
--------------
Future (水晶玉占いをしている女性の絵)
-------------
カーネルの側から見た未来について少し話しておこう。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
7. カーネルの側から見た未来
(OHP 12)
--------------------------
Work in Progress
- Porting to Alpha, MIPS, Sparc and PowerPC
- Filesystem optimization
- Kernel threads
- Symmetric Multiprocessing
- Loadable Module
---------------------------
これが今考えているカーネルの将来。このうち移植についての話は既に述べた
ので飛ばそう。ファイルシステムの最適化は、現在一番やりたいと思っている
問題だ。これがうまく行けば、ファイル処理がずいぶん高速化されるはずだ。
今の Linux でもファイル処理は遅くないけど、いくつかの部分には改善の余地
があるので、それらを改善すればずっとファイル処理は速くなるはずだ。ただ
、実際に取りかかれるのはしばらく先になると思う。どうすればいいのかはだ
いたい見当がついてるので、あとはコーディングの問題だけなんだけど。
もう一つ、カーネルにとっての重要な宿題はスレッド化だ。マルチスレッド化
できれば、一つのプロセスが複数のスレッドを同時に実行できるようになるの
で、一つのスレッドがユーザーからの入力を受けつけ、別のスレッドが計算を
続けるような使い方も可能になり、ウィンドウシステムなどには特に有効だろ
う。
カーネルをスレッド化すると SMP マシン、すなわち、マルチプロセッサのマシ
ンにもきわめて有益だ。マルチプロセッサのマシンでは複数のスレッドを並列
して同時に動かすことが可能なので、プログラムはずっと速く動くようになる
はずだ。
SMP(Symmetric Multi Processor)対応というのもこれからの課題だ。今でも
Intel のマシンではマルチプロセッサに対応しているので、2 つの Pentium が
載ったマシンで Linux を動かすことができる。Linux はちゃんと 2 つの CPU
を使いこなしている。もちろん、4 つのプロセッサを持つマシンならもっと速
く動く。SMP 対応は現在も開発が進行中なので完全に安定しているとは言えな
いけど、もし本当に速いマシンが必要な場合は SMP Linux も十分選択肢に入る
と思う。
現在取り組んでいるもう一つの課題は、実行時ロードモジュール(loadable
module) だ。これは、実行中のカーネルに新しいドライバを動的に組み込む機
能で、この機能を使えば、普段はあまり使わない特殊なハードウェア用のドラ
イバを常にカーネルに組みこんでおく必要が無くなり、必要な時にドライバを
ロードしてそのハードウェアを使い、必要が無くなったらドライバをアンロー
ドして、大事なメモリを別の仕事に使うことが可能になる。
以上がカーネルについての将来。次にカーネルに限らず、Linux 全体の将来像
を述べてみよう。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
8. Linux の将来像
(OHP 13)
-------------------------
Future I
- Source compatibility
- Binary compatibility
- Commercial Support
-------------------------
「ソースレベルの互換性」については、現在でもそうなっているわけだが、こ
れを何らかの形で認証して欲しいと思っている。すなわち、Linux が POSIX と
いったオペレーティングシステムの規格に合致していることを証明して欲しい
と思っている。ただし、認証してもらうにはかなりのお金がかかるのでまだ誰
もやっていないけど、アメリカのある会社がやろうとしていると聞いている。
この認証に通れば、Linux は Unix 互換である、と胸を張って言えるわけだ。
「バイナリ互換」についても、互換性を強める方向に向いたいと思っている。
WINE については既に述べたが、大きなプログラムを動かすにはまだまだやらね
ばならない仕事がたくさん残っている。あと半年くらいで大きなプログラムが
動くようになればいいんだけど、実際のところ、多分まだ一年はかかるだろう
ね。現在でも小さなプログラムはいろいろ動いているんだけど。
「商業サポート」については、すでにかなりの種類が現われてきた。日本でど
の程度商業的に Linux がサポートされているかは知らないけど、すでに Linux
については多数の本が出版され、アメリカでは書店で簡単に手に入るようにな
っている。市販のソフトウェアも、Wordperfect や Maple, Mathematica とい
った商用のソフトウェアの Linux 用バージョンがリリースされて、Linux 上で
数式処理をすることも可能になっている。
それ以外にも、Linux を収めた CD-ROM は多数販売されている。Laser5 もその
一つだし、Caldera Network Desktop は Linux カーネル上で多数の市販ソフト
ウェアを動かすことができる商用パッケージだ。Caldera には Netware に対応
する機能も付いているので、Linux を Netware のサーバーにすることも可能に
なる。
これが最後のスライドだけど、
(OHP 14)
----------------------
Future II
- Continued development
1.2.x is out: stable release
1.3.x used for development
Linux 2.0: Multi-platform, SMP
-----------------------
一言で言えば、Linux は今後も発展を続けていく、ということだ。僕は既に 5
年ほど Linux の開発に携わってきたけど、まだまだ Linux の発展が止まるこ
とは無いと感じている。
現在の安定版カーネルは 1.2.xのシリーズで、市販のパッケージにはこのバー
ジョンが入っているはずだ。今開発しているのは 1.3.x のシリーズで、これは
開発者用のバージョンという位置づけになる。このシリーズのカーネルはあま
り安定していない。いくつかのバージョンには致命的なバグがある。だから、
本当に 1.3.x の機能が必要か、自分でそういうトラブルを回避できるだけの実
力のある人以外は 1.3.x のカーネルは使わない方がいい。
次にリリースする安定版のカーネルのバージョンは 2.0 になる予定だ。1.3.x
のシリーズは近い将来に code freeze を宣言して新しい機能の追加を止め、そ
の後数か月間、徹底的にデバッグを行なって十分バグを取って安定した時点で
2.0 としてリリースする予定だ。2.0 は機能的には 1.3 と同じだが、徹底的に
テストされてずっと安定しているはずだ。
始めの計画では次の安定版は 1.4 になる予定だったが、複数のプラットフォー
ムに対応したことと、SMP マシンに対応したことの 2 つの大きな改良が行なわ
れたから、メジャーバージョンを上げることにした。特に SMP サポートはメジ
ャーバージョンを上げるに値することだと思っている。
これで僕の話は終りだけど、何か質問は？
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
9. Q & A
フロアからの質問
[qv_007]
(仙田さん撮影, 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 マシンは？
Q: DEC Alpha への移植について。あるプログラム(ghostscript)を DEC Alpha
マシンに移植しようとしているのだがうまくいかない。何かアドバイスを貰え
ないだろうか？
A: Alpha への移植の際にユーザーレベルのプログラムで特に問題になるのは
32 ビットと 64 ビットの問題だろう。例えば、 int と long を同じとみなし
ているプログラムもあるが、これは Alpha では成立しない。その場合、プログ
ラム中の long を int に置きかえてやればいい。ただ、これだけでは不十分な
場合もあって、Alpha ではポインタも 64 ビットになっているので、ポインタ
を int と同じとみなしているプログラムは問題になる。これらを手がかりに調
べてみてはどうか？
Q: 他の機種への移植に関して Alpha ではバイナリ互換ということだが、他の
機種ではどうか？
A: Alpha については、僕自身 Digital UNIX のバイナリプログラムをいくつか
持っているので、テストのためにもバイナリの互換性を追及している。きちん
と動くバイナリプログラムがあればカーネルのテストにも便利だからね。
Sparc についても SunOS とバイナリ互換にしたいと思っている。SunOS との互
換性はかなりなところまでいっているみたいだけど、Sparc Linux はまだまだ
不安定みたいだ。
mips についてはあまりバイナリ互換性は期待できないだろう。DEC もかっては
mipsマシンを作っていたことがあるが、DEC の mips マシン用のバイナリはほ
とんど無いし、今、mips を使っている SGI のマシンはレンダリングといった
プログラムに特化しているのであまり Linux ユーザに便利なバイナリはないだ
ろう。それに SGI は特殊なマザーボードを使っているので、バイナリ互換は困
難だと思う。もっとも、僕自身 mips についてよく知らないから、詳しくはド
イツで mips への移植をやってる人たちに聞いて欲しい。
Q: WINE についてもう少し教えて欲しい。
A: WINE は WINdows Emulator の略で、MS-Windows 用のプログラムを X11 上
でエミュレートして動かすためのプログラムだ。ちょうど SUN の WABI と同じ
ことを free なプログラムで実現しようとするものだ。
Q: マイクロカーネルとモノリシックカーネル、どちらがいいんだろう？
A: どちらにも一長一短があると思う。僕は昔マイクロカーネルの minix を使
っていたことがある。確かにいくつか気にいった部分はあったが、minix はあ
くまでマイクロカーネルを使った OS の教材として書かれているので、全体と
しての性能には不満で、マイクロカーネルのあまり適切な例ではないように思
った。だから、minix の欠点を取りこまないように Linux をデザインしたつも
りだ。もちろん、minix は OS の働きを理解するための教材としてはいい例だ
と思うけどね。
minix よりもいいマイクロカーネルはいくつもあり、例えば Mach もその一つ
だ。でも Mach はすごく複雑な OS になってしまっている。Mach の複雑さの大
部分は性能の向上を目指すための工夫で、マイクロカーネル化による性能低下
をカバーしようとして、必要以上に複雑になっているように思う。
Q: カーネルモジュールはある意味ではマイクロカーネルみたいなものでは？
A: たしかに、ある部分についてはマイクロカーネルと同じことをしようとして
いる。しかし、カーネルモジュールは動いている時でも、カーネルに直接リン
クされてしまうので、マイクロカーネルのようなプロテクションバウンダリに
関する問題は起こなさい。
Q: カーネルのドライバの中で PPP モジュールなどはモジュールとしてのみ提
供されているが、そうすることに何か意味があるのか？
A: PPP をモジュールとしてのみ提供するというのは僕が決めたことじゃない。
ppp の開発者である Al Longyear がそう決めたんだ。彼は多分モジュール化す
ることでデバッグが容易になると考えたんじゃないかな。つまり、モジュール
化しておけば、カーネル全体を作り直さなくても新しいモジュールをロードす
ることで、新しい ppp のテストは可能になるからね。
Q: 1.3.x 用には kerneld というデーモンがあるが、1.2.x 用にも kerneld は
あるのか？
A: 1.2.x では insmod/rmmod といったモジュールをロードするためのツールが
用意されている。それは 1.3.x でも同じように使える。kerneld は、その手順
を自動化するためのものなので、insmod/rmmod を使いつづけても構わない。
Q: 以前は PC 上で MS Windows を使っていたんだけど(ここで Linus が指でバ
ツ印を作り、会場が笑いに包まれる)、Linux に切りかえたら、そのパフォーマ
ンスのよさにびっくりした。なぜ、Linux のような free な OS が Microsoft
のような巨大企業の作るソフトよりも性能がいいんだろう？
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 から始めたから、同じ間違いをしないように気
をつけたし。
Q: Microsoft からあなたに何らかの接触されたことはないのか？
A: Microsoft は我々のことなんか気にしてないんじゃないかな？ Microsoft
のユーザーは 5000 万人、Linux のユーザーは推定で 50 万ってところだから
、彼らのユーザーの 1% に過ぎないしね。でも、将来は彼らも Linux のことを
脅威に感じてくれればいいなと思うよ(会場笑)。
Q: 私自身、科学計算ライブラリを作ろうとしているのだが、そのようなソフト
ウェアプロジェクトを計画している人に対して Linux というビッグプロジェク
トを成功させた立場から何かアドバイスを。
A: Linux での経験から僕が言えることは、まず何か基本的な小さなシステムを
作って、それはそれほど優れたものでなくてもいいから、それをネットワーク
上で公開することだ。そうすると、世界中に同じようなソフトウェアを欲しが
っている人がきっと見つかるだろう。そして、君のシステムに関心を持ってく
れる人を見つけて、彼らと共に開発していくことだ。それがまさに Linux に起
こったことなんだ。
僕が作った最初の Linux は、ほんとうにごく基本的なものだった。でも、多く
の人の協力で、今あるような素晴しいシステムに成長していった。だから、そ
ういう風に開発するのが一番いいんじゃないかな？関連するニュースグループ
に投稿して、自分と関心を同じくする人を見つけることから始めるのも手だろ
う。
Q: Linux の開発に携わっている人はどれくらいいるのか？
A: Linux の開発者の数は、数え方によって変るね。もしカーネルの大部分を書
いた主要な開発者に限るなら、10 - 20 人程度だろう。デバイスドライバを書
いた人やカーネルの小さな改良に貢献してくれた人まで含めると 100 - 200 人
規模になるだろう。カーネルと同等かそれ以上に重要なユーザーレベルのプロ
グラム、例えば gcc や X11 なら、それぞれにまた何百人もの開発者が関わっ
ているから、それらを全て含めたら、何千人の規模になるはずだ。経験を積ん
だプログラマをこんなに多く抱えているソフト会社は存在しない。普通の大き
なソフト会社でもプログラマはせいぜい数百人といったところだからね。BSD
も含めて Unix のプロジェクトはいかにすごい数のプログラマに支えられてき
たかがわかるだろう。
Q: GNU Hurd について一言？
A: GNU Hurd についてはほとんど知らない。GNU Hurd の主要な開発者には会っ
たことがあるけど、僕自身は Hurd のプロジェクトには全く関係していない。
現時点では、GNU の連中も Linux が GNU のカーネルだと思ってるみたいだけ
ど、将来についてもそうだという保障はないね。ただ、Hurd は未来のプロジェ
クトで、いつになれば使えるようになるのかわからない。
Q: Linux はさまざまなプラットフォームに移植されているが、それらの間でバ
イナリの互換性はあるのか？例えば Intel CPU 用のバイナリが Alpha で動く
、といったような。
A: アーキテクチャー間のバイナリ互換といった機能は、将来とも Linux には
組みこまれないだろう。ただ、「バイナリトランスレーション」と呼ばれる面
白いプロジェクトがある。例えば DEC の人たちは mips のバイナリを Alpha
で動くようにし、現在は intel のバイナリを Alpha 上で動かそうとしている
。この技術が使えるようになればアーキテクチャー間のバイナリ互換も可能か
も知れないが、多分彼らはその技術をフリーでは公開しないだろう。それに、
このプロジェクトはずいぶん大規模なもので、個人がそう簡単に実現できるよ
うなものではない。
Q: Java のサポートは？
A: Linux 用の Netscape では Java がサポートされたと聞いている。ただ、そ
れはベータバージョンで、まだまだ不安定らしい。Alpha Linux 用の Netscape
は存在しないが、Digital Unix 用の Arena が Alpha Linux でも使えるようだ
。
Q: Debian は Gnu 版の Linux と聞いたが？
A: A: Debian は元々 Gnu とは関係ないディストリビューションだったが、GNU
の連中が彼らの公式の Linux ディストリビューションを作る時に Debian を選
んだ。技術的にも Debian は slackware よりも優れていたしね。僕自身は
slackware しか使ったことはなく、Debian は試したことはないけど、実際に使
っている人は Debian は優れている、と言うね。それに、個人的には RedHat
のディストリビューションも優れたものだと思っている。でも、 slackware が
一番広く使われているね。
Q: VIPER というプロジェクトはどうなっていますか？
A: 一年くらい前に、スレッドとリアルタイムのサポートを目指して VIPER と
いうプロジェクトが始まったが、最近はその名前を聞かないね。スレッドとリ
アルタイムはまだ不完全だけど、公式のカーネルでサポートを始めたので、
2.0 までにスレッドのサポートを完成させたいと願ってはいる。
Q: copyleft ソフトウェアは将来どうなるだろう？
A: 僕は copyleft が全てに正しい解だとは思わない。でも、Linux を含めたい
くつかのプロジェクトにとっては copyleft は素晴らしい解だ。でも、僕は著
作権(copyright)で保護された商用ソフトウェアも必要だと思っている。この点
で僕は GNU の連中とは意見を異にしている。彼らは全ての商用ソフトウェア無
しでやっていこうとしているからね。
僕自身は、あまりおもしろみがなく free software が生まれないような分野の
仕事は商用ソフトウェアが必要だと思っている。たとえばデータベースといっ
た分野がそれだ。
僕は Linux 用にもっと商用のソフトウェアが出てきて欲しいと思っている。そ
の一方で、新しいソフトウェアがフリーに公開されていくことも望む。この両
者は互いに対立する排他的なものではなく、両方とも同時に使うことはできる
んじゃないかな？
Q: 今手に入れられる最速の 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)
一覧に戻る
グリーンネット・トップページへ戻る |
