## Linus Torvalds 来日講演会 (1995/12/04)

1996/06/02
Linus
Torvalds
日本語訳
こじまみつひろ

1995年12月4日に京都大学で行なわれた、Linus Torvalds さんの来日講演会 の模様(全訳)です。

当日や来日の間の Linus さんの様子を知りたい方は、 http://jf.gee.kyoto-u.ac.jp/JF/linus-japan.html を御覧下さい。

## Linux とは何か

僕がヘルシンキ大学のリィナス・トルヴァドゥス、Linux カーネルの開発者で す。僕の英語が通じるかな？質問の時に、みんなの英語が僕に通じるとうれし いけど。(会場 笑)

(川井さん撮影, 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 年後に は、この星の人口と同じくらいのユーザー数になるだろう(会場 笑)

もちろん、こんなに増加し続けるはずはないけど、カッコいいグラフだよね。

さて、実際の「デザインについて」の話題に入ろう。

## 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 の基本的なデザインの話。次にモノリシックカーネルに ついての説明をしよう。

## モノリシックカーネルについて

    (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&lsqb;345&rsqb;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 の開発方針について説明しよう。

## 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 デバイスを担当している人、などが存在する。 それぞれの担当者の下にも、同様により小さな部分を担当している人が存在し ている。そして、例えばネットワークに関する修正点はネットワークの担当者 のところで集約され、僕に伝えられる。そして僕がそれを元にカーネルを修正 する、というわけだ。

もちろん、このシステムは強制力をもつものではないので、バグを見つけたら 僕に直接送ってもらっても構わない。実際、今までにも、見たことも聞いたこ とも無い人からバグレポートとパッチが届いて、そのパッチをそのままソース コードに組みこんだこともある。この開発者のピラミッドは、誰が何を成した かによって、きわめて動的に変動するもので決して固定したシステムではない。

## カーネルを書く際の注意点

    (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 を例に「移植性」の話を詳しくしておこう。

## 移植性について

    (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 (水晶玉占いをしている女性の絵)
    -------------

カーネルの側から見た未来について少し話しておこう。

## カーネルの側から見た未来

    (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 全体の将来像 を述べてみよう。

## 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 サポートは メジャーバージョンを上げるに値することだと思っている。

これで僕の話は終りだけど、何か質問は？

## Q & A

フロアからの質問

(仙田さん撮影, 1995)

DEC Alpha への移植について。あるプログラム(ghostscript)を DEC Alpha マシンに移植しようとしているのだがうまくいかない。何かアドバイスを貰え ないだろうか？

Alpha への移植の際にユーザーレベルのプログラムで特に問題になるのは 32 ビットと 64 ビットの問題だろう。例えば、 int と long を同じとみなし ているプログラムもあるが、これは Alpha では成立しない。その場合、プロ グラム中の long を int に置きかえてやればいい。ただ、これだけでは不十 分な場合もあって、Alpha ではポインタも 64 ビットになっているので、ポイ ンタを int と同じとみなしているプログラムは問題になる。これらを手がか りに調べてみてはどうか？

他の機種への移植に関して Alpha ではバイナリ互換ということだが、他の 機種ではどうか？

Alpha については、僕自身 Digital UNIX のバイナリプログラムをいくつ か持っているので、テストのためにもバイナリの互換性を追及している。きち んと動くバイナリプログラムがあればカーネルのテストにも便利だからね。

Sparc についても SunOS とバイナリ互換にしたいと思っている。SunOS との 互換性はかなりなところまでいっているみたいだけど、Sparc Linux はまだま だ不安定みたいだ。

mips についてはあまりバイナリ互換性は期待できないだろう。DEC もかって は mipsマシンを作っていたことがあるが、DEC の mips マシン用のバイナリ はほとんど無いし、今、mips を使っている SGI のマシンはレンダリングといっ たプログラムに特化しているのであまり Linux ユーザに便利なバイナリはな いだろう。それに SGI は特殊なマザーボードを使っているので、バイナリ互 換は困難だと思う。もっとも、僕自身 mips についてよく知らないから、詳し くはドイツで mips への移植をやってる人たちに聞いて欲しい。

WINE についてもう少し教えて欲しい。

WINE は WINdows Emulator の略で、MS-Windows 用のプログラムを X11 上でエミュレートして動かすためのプログラムだ。ちょうど SUN の WABI と 同じことを free なプログラムで実現しようとするものだ。

マイクロカーネルとモノリシックカーネル、どちらがいいんだろう？

どちらにも一長一短があると思う。僕は昔マイクロカーネルの minix を使っ ていたことがある。確かにいくつか気にいった部分はあったが、minix はあく までマイクロカーネルを使った OS の教材として書かれているので、全体とし ての性能には不満で、マイクロカーネルのあまり適切な例ではないように思っ た。だから、minix の欠点を取りこまないように Linux をデザインしたつも りだ。もちろん、minix は OS の働きを理解するための教材としてはいい例だ と思うけどね。

minix よりもいいマイクロカーネルはいくつもあり、例えば Mach もその一つ だ。でも Mach はすごく複雑な OS になってしまっている。Mach の複雑さの 大部分は性能の向上を目指すための工夫で、マイクロカーネル化による性能低 下をカバーしようとして、必要以上に複雑になっているように思う。

カーネルモジュールはある意味ではマイクロカーネルみたいなものでは？

たしかに、ある部分についてはマイクロカーネルと同じことをしようとし ている。しかし、カーネルモジュールは動いている時でも、カーネルに直接リ ンクされてしまうので、マイクロカーネルのようなプロテクションバウンダリ に関する問題は起こなさい。

カーネルのドライバの中で PPP モジュールなどはモジュールとしてのみ提 供されているが、そうすることに何か意味があるのか？

PPP をモジュールとしてのみ提供するというのは僕が決めたことじゃない。 ppp の開発者である Al Longyear がそう決めたんだ。彼は多分モジュール化 することでデバッグが容易になると考えたんじゃないかな。つまり、モジュー ル化しておけば、カーネル全体を作り直さなくても新しいモジュールをロード することで、新しい ppp のテストは可能になるからね。

1.3.x 用には kerneld というデーモンがあるが、1.2.x 用にも kerneld は あるのか？

1.2.x では insmod/rmmod といったモジュールをロードするためのツールが 用意されている。それは 1.3.x でも同じように使える。kerneld は、その手 順を自動化するためのものなので、insmod/rmmod を使いつづけても構わない。

以前は PC 上で MS Windows を使っていたんだけど(ここで Linus が指で バツ印を作り、会場が笑いに包まれる)、Linux に切りかえたら、そのパフォー マンスのよさにびっくりした。なぜ、Linux のような free な OS が Microsoft のような巨大企業の作るソフトよりも性能がいいんだろう？

「なぜ 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 から始めたから、同じ間違いをしないよう に気をつけたし。

Microsoft からあなたに何らかの接触されたことはないのか？

Microsoft は我々のことなんか気にしてないんじゃないかな？ Microsoft のユーザーは 5000 万人、Linux のユーザーは推定で 50 万ってところだから、 彼らのユーザーの 1% に過ぎないしね。でも、将来は彼らも Linux のことを 脅威に感じてくれればいいなと思うよ(会場笑)。

私自身、科学計算ライブラリを作ろうとしているのだが、そのようなソフ トウェアプロジェクトを計画している人に対して Linux というビッグプロジェ クトを成功させた立場から何かアドバイスを。

Linux での経験から僕が言えることは、まず何か基本的な小さなシステム を作って、それはそれほど優れたものでなくてもいいから、それをネットワー ク上で公開することだ。そうすると、世界中に同じようなソフトウェアを欲し がっている人がきっと見つかるだろう。そして、君のシステムに関心を持って くれる人を見つけて、彼らと共に開発していくことだ。それがまさに Linux に起こったことなんだ。

僕が作った最初の Linux は、ほんとうにごく基本的なものだった。でも、多 くの人の協力で、今あるような素晴しいシステムに成長していった。だから、 そういう風に開発するのが一番いいんじゃないかな？関連するニュースグルー プに投稿して、自分と関心を同じくする人を見つけることから始めるのも手だ ろう。

Linux の開発に携わっている人はどれくらいいるのか？

Linux の開発者の数は、数え方によって変るね。もしカーネルの大部分を 書いた主要な開発者に限るなら、10 - 20 人程度だろう。デバイスドライバを 書いた人やカーネルの小さな改良に貢献してくれた人まで含めると 100 - 200 人規模になるだろう。カーネルと同等かそれ以上に重要なユーザーレベルのプ ログラム、例えば gcc や X11 なら、それぞれにまた何百人もの開発者が関わっ ているから、それらを全て含めたら、何千人の規模になるはずだ。経験を積ん だプログラマをこんなに多く抱えているソフト会社は存在しない。普通の大き なソフト会社でもプログラマはせいぜい数百人といったところだからね。BSD も含めて Unix のプロジェクトはいかにすごい数のプログラマに支えられてき たかがわかるだろう。

GNU Hurd について一言？

GNU Hurd についてはほとんど知らない。GNU Hurd の主要な開発者には会っ たことがあるけど、僕自身は Hurd のプロジェクトには全く関係していない。 現時点では、GNU の連中も Linux が GNU のカーネルだと思ってるみたいだけ ど、将来についてもそうだという保障はないね。ただ、Hurd は未来のプロジェ クトで、いつになれば使えるようになるのかわからない。

Linux はさまざまなプラットフォームに移植されているが、それらの間で バイナリの互換性はあるのか？例えば Intel CPU 用のバイナリが Alpha で動 く、といったような。

アーキテクチャー間のバイナリ互換といった機能は、将来とも Linux には 組みこまれないだろう。ただ、「バイナリトランスレーション」と呼ばれる面 白いプロジェクトがある。例えば DEC の人たちは mips のバイナリを Alpha で動くようにし、現在は intel のバイナリを Alpha 上で動かそうとしている。 この技術が使えるようになればアーキテクチャー間のバイナリ互換も可能かも 知れないが、多分彼らはその技術をフリーでは公開しないだろう。それに、こ のプロジェクトはずいぶん大規模なもので、個人がそう簡単に実現できるよう なものではない。

Java のサポートは？

Linux 用の Netscape では Java がサポートされたと聞いている。ただ、 それはベータバージョンで、まだまだ不安定らしい。Alpha Linux 用の Netscape は存在しないが、Digital Unix 用の Arena が Alpha Linux でも使 えるようだ。

Debian は Gnu 版の Linux と聞いたが？

A: Debian は元々 Gnu とは関係ないディストリビューションだったが、GNU の連中が彼らの公式の Linux ディストリビューションを作る時に Debian を 選んだ。技術的にも Debian は slackware よりも優れていたしね。僕自身は slackware しか使ったことはなく、Debian は試したことはないけど、実際に 使っている人は Debian は優れている、と言うね。それに、個人的には RedHat のディストリビューションも優れたものだと思っている。でも、 slackware が一番広く使われているね。

VIPER というプロジェクトはどうなっていますか？

一年くらい前に、スレッドとリアルタイムのサポートを目指して VIPER と いうプロジェクトが始まったが、最近はその名前を聞かないね。スレッドとリ アルタイムはまだ不完全だけど、公式のカーネルでサポートを始めたので、 2.0 までにスレッドのサポートを完成させたいと願ってはいる。

copyleft ソフトウェアは将来どうなるだろう？

僕は copyleft が全てに正しい解だとは思わない。でも、Linux を含めた いくつかのプロジェクトにとっては copyleft は素晴らしい解だ。でも、僕は 著作権(copyright)で保護された商用ソフトウェアも必要だと思っている。こ の点で僕は GNU の連中とは意見を異にしている。彼らは全ての商用ソフトウェ ア無しでやっていこうとしているからね。

僕自身は、あまりおもしろみがなく free software が生まれないような分野 の仕事は商用ソフトウェアが必要だと思っている。たとえばデータベースといっ た分野がそれだ。

僕は Linux 用にもっと商用のソフトウェアが出てきて欲しいと思っている。 その一方で、新しいソフトウェアがフリーに公開されていくことも望む。この 両者は互いに対立する排他的なものではなく、両方とも同時に使うことはでき るんじゃないかな？

今手に入れられる最速の Linux マシンは？

今のところ、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)