2ヶ月ほど前から計画していたところでは、今日は、群馬にいる予定であった。10月28日は群馬県民の日であって、JR東日本では群馬県内のJR線が乗り放題のぐんまフリーパスを発売する、という話をSilphireさんに教えていただいたものだから、それでは10月28日は朝一で群馬へ向かい、吾妻線に乗り、日本一短いトンネルを抜け、ダム底に水没予定の川原湯温泉で一風呂浴び、上越線に戻って本日のみ臨時運行のEF55ムーミン号を見て、さて、紅葉の只見線経由で会津若松方面に抜けて、という600km以上に及ぶ一筆書き切符の旅行を考えていたのだけれど、ここへ来て新潟県中越地震なのである。

在来線の復興状況としては、上越線が水上までは通じていて、おそらくイベント列車も走ることであろうが、途切れたとはいえ被災地への交通動脈を不要不急の観光客がうろうろするのも好ましからず、今日はせっかくの機会で日を空けて待っていたのではあるが、旅行を取りやめたという次第なのである。と、被災された方々への思いやりなく自分の話をつづってみたのだけれど、被災された方にはお見舞い申し上げます。

さて、この空いた一日を何に使うかと考えて、久しぶりに翻訳部活動をすることにした。スラドでは長い沈んだ時期を支えてもらったが、おかげでこの春ぐらいから精神的な調子がずいぶんよくなって、ネットにはあまり近寄らない生活を営んでいた。このところ、数年ぶりに腰を据えて机に向かうということができているのだけれど、やはりスラドには残してきたものがあって、ひょんに空いた時間を翻訳部に貢献してみようと思った。傍には気まぐれのように思えるかもしれないけれど、そんなわけで、ちょっとばかり活動してみる。久しぶりの作業で調子がつかめなかったけれど、果たせるかなこうして出てきたものは以前どおり一本調子の意訳であった。

というわけで、選んだ素材は、10月18日に本家スラッシュドットに掲載された"Rob Pike Responds"で、これは、ロブ・パイクが去る10月5日に"Ask Unix Co-Creator Rob Pike"として募られた質問に答えたもの。パイク本人が"Co-Creator"と称されたことを訂正するところからインタビューは始まっている。

===============

パイク：
はじめに、誤りを正させていただきたいと思います。私は、Unixの共同開発者ではありません。そう表現するのは、私は、あるUnixの本の（ブライアン・カーニハンとの）共著者ではありますが、ブライアンも私もUnixを創ったというクレジットを欲していたわけではないからです。ケン・トンプソンとデニス・リッチーがUnixを創ったのであり、彼らがまったく、またそれ以上にクレジットに値するのです。私は、7th Edition Unixがすでに登場した後、彼らのグループ――ベル研究所コンピュータ科学研究センター――に加わったのです。

1) イノベーションとパテント - by Zocalo

あなたのアイディアは非常にたくさん、現在のオペレーティング・システムの随所で用いられていますが、ソフトウェアのパテント取得や、その他「知的財産権」なる概念の問題について、どういう立場でいらっしゃいますか？　冷戦中の核兵器の集積を想い起こさせるようにビジネス界は懸命にパテントを貯め込んでいて、知的財産権のパテントを放り投げるようにはならないとすると、この問題の解決をどうご覧になりますか？

パイク：
パテントと核兵器を比べるのは少々極端です。

2) システム研究
貴論文「システムソフトウェア研究は見当違いのほうを向いている」（※日本語訳）では、システム・プログラムには革新の余地がほとんどなく、エネルギーのすべては現在のスタンダードに注ぎ込まれていると、主張をなさっておいでです。今ではGoogleにお勤めになっていますが、やはり同様にお感じですか？

パイク：
私は、講演では、自分の使う用語の定義には非常に慎重になります。（それは論文などではありませんでした。）　私が主に話をしたのはオペレーティング・システムについてでしたが、その当時（2000年初め）に私が言ったことのほとんどは、今でも当たっています。

ここGoogleでは、問題はまったく異なっています。私たちが解決しようと試みている問題の規模は非常に広範で、いつもチャレンジがあります。「作るべきもの」についてのその講演のスライドは、ちょっと見ていただくと、私たちがGoogleでやっていることとよくマッチしていて、おもしろく思います。要約すると：

GUI: Googleはもっとも簡潔で出来の良いUIをインターネットに与えましたし、また、データの新しい提示方法を見つけ、その探索を簡単にすることに取り組み続けています。

コンポーネント・アーキテクチャ：　Googleファイル・システムとマップリデュース（今度のOSDIで発表される、ジェフ・ディーンとサンジャイ・ゲマワットの論文を参照のことhttp://labs.google.com/papers/mapreduce.html）のような大きな（大きな！）要素のパーツをたくさん用いて、データ処理用の大規模なエンジンを作り上げます。そういった要素を用いることによって、天文学的なほどの数のマシンをわずかのキー・ストロークで制し、インターネット全体をインデックス化させるような問題にあたることができるのです。（えぇ、それはまったくそれほどに簡単ではないけれど、それでも驚異的なことです。）　私は毎日、自分で開発中のシステムのひとつの健康状態をモニターするテスト・ジョブを実行しています。それは、一週間分のCPU時間を用いますが、実行には、実時間でほんの数分しかかかりません。

分散コンピューティング用言語：　そういった流れに沿って取り組んでいるチームの一員なのですが、そろそろ書き上がったらいいなと思っています。

他所のやり方と違った、ユーザへのデータのもらたし方：　ダメなブラウザが今も邪魔をしていますが、データへの接続として他の方法では、Google APIのようなものが出現し始めています。とはいえ、このトピックでは、その表面はがわずかにひっかいてある程度です。

システム管理：　Googleでモノを作っている人間が、そういったすべてのマシンを調子よく保ってクエリを待つようにしている様には、目を見張らせられます。システム管理の分野における本当の進歩がそこにあり、前進させ続けることを、見せ付けてくれます。

3) あの日に帰って - by Greyfox
プログラマは、今日のようにホットプラグできる機器みたいに扱われていたのでしょうか？　1995年頃より前には、プログラマには神秘的な雰囲気があったように思うのですが。

様々なネット・ニュースの投稿や昔のプログラマたちの回想を読んだところによると、当時のプログラマというものは、彼らの関与するコンピュータがすべてたちどころに壊れてしまうというものではなく、魔法使いのようなすごい人と目されていました。何か本当に変わったものはあるのでしょうか？　あるいは、当時に戻っても、今あるようなものと同じなのでしょうか？　私が読んだもののどのくらいが単なるノスタルジアであったか、と思っています。

パイク：
今日、もっと多くのコンピュータがあって、もっと多くのプログラマがいて、ほとんどの人間がコンピュータやプログラマがやっていることに通じているということは、ないですか？　あなたが1995年に触れているのはよく分からないが、とはいえ、20年か30年前、コンピュータというのは巨大で巨額な現代性の寺院であり、その力を制御できる者は誰しも、まさに定義どおり、ほぼ魔法使いでした。今日では、ミュージシャンだってコンピュータを使えます。(ね、ゲイリー。)

4) どんなことをなさっているんですか… - by Mark Wilkinson
Googleの従業員は、勤務時間の20%を自分自身のプロジェクトに取り組むよう許可されているようですが、Googleのために何をしているかはコメントできないでしょうから、そうすると、その他20%は何をして費やしておいでなのですか？

パイク：
その外でやっているもっともおもしろいプロジェクトのひとつに、私は末梢（といって、ただの抹消でしかないんですが）で関わっているのですが、大口径シノプティック・サーベイ望遠鏡http://www.lsst.org/があります。それは、一年に何度も、何色も使って、可視の空を非常に高角度の分解能に送るのです。8.4メートル口径の視野10平方度。3ギガピクセルのカメラで、20秒毎に一度画像を取得します。結果のデータ・セットは、ペタバイトにもなるたくさんの画像とカタログ・データとなり、データマイニングに勤しむ者の夢です。望遠鏡用のソフトウェアは、その装置自体ぐらいの大きなチャレンジです。つまり、山上のリアル・タイムの画素のパイプラインが、今日のコンピュート・クラスターを無価値なものにしてしまうのです。

5) データベース・ファイルシステム - by defile
今日のファイルシステム研究の周辺での活気で、UNIXのファイルシステムをよりデータベース的になっています。今日のデータベース研究の周辺での活気で、リレーショナル・データベースがよりOOP的になっています。

この研究は、今や、最初の設計者たちの「創造物」が必需品となっていつつも、「今すぐに物事をする」ために原点回帰をしているため、その「創造物」の限界に自ら疲弊しているのだ、というように私には思えます。その再発明バージョンは、複雑すぎ得難すぎて、人気を博することな決してない、と私は予言します。

もちろん、第二次システム・シンドロームは、システムに限られただけのものではありません。バンドにも、ディレクターにも、もしかしたら、創造的な芸術のすべてにおいて、起こりましょう。

私たちが現代的なファイル・システムとRDBMSにあるということは、私たちはそちらに向かうべきぐらい、良いことだと思います。どうお考えですか？

パイク：
データベースとファイル・システムが衝突し、統合され、議論され、分割されたのはこれが初めてではありませんし、また、これが最後とはならないでしょう。どんなファイル・システムないしデータベースを持つかという中身は、どちらも勝たないように仕掛けられたいくぶん無価値な意味論の論争であって、誰が最高のテクノロジを持っているのかというコンテストようのです。そう、大部分のテクノロジのように、解法は問題に依ります。ひとつだけ正しい答えがあるというものではありません。

本当におもしろいことは、自分のデータにアクセスするということを自分はどう考えるか、ということです。ファイル・システムやデータベースは、あなたが格納したものの中の構造や意味を見つけることに資して、データの組織化の違った方法を提供します。もっと言えば、それらが提供する構造は、実は、ひとつの目的のためにあるということです。つまり、アクセスを簡単にする、ということです。ここが大切ですが、それがストラクチャではなく、アクセスであることを一度理解してもらえたなら、この議論全体は性格が異になります。

過去数年での見事な洞察のひとつは、インターネットのサーチ・エンジンによる成果物やウディ・マンバーのGlimpseのようなツールによるもので、それは、データが伴っているのが無意味なストラクチャであっても、データの検索に資するツールが十分であれば、それでも非常にパワフルでありうる、というものです。実のところ、ストラクチャは、前日に解決しようとする問題にどれくらいよくフィットしていたかに関わらず、今日、解決しようとする問題にフィットしないストラクチャであれば、そのストラクチャは低質なものでありうるのです。というわけで、私は、自分のデータがどのように格納されているかは、もう気にしないのです。つまり、問題なのは、それらを必要としたときに、関連するピースをどうやって持ってくるか、ということなのです。

GrepはUnixに前々からあるもっとも決定的なツールですが、今では、私たちには「自分のマシンをgrepする」とか「インターネットをgrepする」とか言って特徴を示し得るツールがあります。Googleのメール・プロダクトであるGMailは、そんなアイディアを採り入れてメールに適用しています。つまり、メールのメッセージを組織化することに煩わされず、後で検索するように取っておくだけ、ということです。昔のファイル・フォルダ志向のメンタリティを追いやれるとしたら、それはまったく解放的です。データを扱う方法として、検索がストラクチャに取って代わるような解放を、もっと期待します。

6) ベル研に思うこと - by geeber
Plan 9、Unix、その他たくさんのすばらしいものがベル研から登場しました。インターネット・バブルが崩壊してからというもの、電気通信会社は非常に苦しんでいます。このひとつの結果として、ルーセントが、世界最大の産業研究施設のひとつを組織的に廃止しました。あなたは、ご自身のキャリアの大部分をベル研でお過ごしになっています。ベル研の歴史と（あるとすれば）未来をどう思われますか？　また、ベル研の文化がUnixの成長にどう影響したと思われますか？

パイク：
「組織的に廃止した」と言ってしまうのはフェアではありません。それは、まるで周到なプロセスであり、残るものが何もなかったようであるかのようです。より素直な評価としては、市場や政府規制における変化によって、かつてのベル研の規模で活況を呈するような規則に囚われない研究所を維持するのが困難になったということかもしれません。ベル研は、近時、たいへん小さくなっていますが、非常に聡明なひとの幾人かがそこでは働いていて、すばらしいことをやっているのです。ベル研が、いつの日にか、かつての栄光を取り戻すことを私は期待しています。とはいえ、世界はそれが決して起こることはなかろうほど変化をしているのですが。

昔のベル研の文化について私が紙面を割き続けることはできますが、それでも要約となるに違いありません。1980年、またの名を127と言った（後には1127。そこにはドラマがありますが）コンピュータ科学センターに私が着任したときは、7th Edition Unixを世に送り出したばかりで、また、センターは、実質的にゼロ成長の長い期間の後に、急速な拡大期に入ったところでした。その拡大は、新しいアイディアとともにたくさんの新しい人々を招き入れました。当時、私はグラフィックスをやっていて、もう1人のグラフィックスの担当者バート・ロカンシーと付き合い始めましたが、私たちは、Research UnixにBlitでグラフィックスを持ち込みました。他の者たちは、新しい言語や、斬新なハードウェア、ネットワーキング、つまり、すべての種類のものに持ち込みました。1980年代初頭は、研究所と外部コミュニティの両方にUnixに影響するたくさんのアイディアを作り出しました。センターが成長していたという事実は、その成功の大きな部分であったと確信しています。その成長は、単に新しいアイディアを提供するのみではなく、停滞状態や縮小中のグループには存在しないようなある種の熱狂を生んでいました。大学では、大学院生のフローが継続的にあって、そういった各種のエネルギーを利用できますが、産業研究所においては、他の方法で創り出す必要があります。

そのグループが如何に機能したかということに欠かせなかったと私が考える、奇妙な詳細は、それは、マシン・ルームの端末を用いてある格好悪いミニコン上でUnixを最初に動かしたことの結果であります。そのシステムに取り組んでいた人たちは、その部屋に集まっていました――コンピュータを使うには、そこにいる必要がかなりあったのです。（この考え方は当時では奇妙なものには見えませんでした。つまり、IBM 7090のマシンのように、一度に一時間予約するという古い方法が自然に進化したものです。）　みんなはそういうふうにして働くのが好きだったので、そのマシンが違う部屋に移動しても、また、プライベートのオフィスから接続することが可能になってさえも、やはりそこは、人が集まり、コーディングをし、設計をし、また、単にたむろをした、かなりの数の端末のある「Unix部屋」があったのです。（コーヒー・マシンもそこにありました。）　そのUnix部屋はまだあって、それがUnix のテクノロジとしての成功の最大の文化的な理由であるのかもしれません。よりたくさんのグループがこの教訓から益するかもしれませんけれど、既存の組織にUnix部屋的な空間を付加するのは、実に難しいことです。自分らのオフィスに隠れないようにさせる文化が必要であるし、パブリックなマシンを仕事するに発展的な場所にする――典型的には「デスクトップ」ではない他の場所にデータを保存することで――システムを用いることが必要であるし、あとは、ケンとデニス（あと、ブライアン・カーニハンとダグ・マキロイとマイク・レスクとスチュ・フェルドマンとグレッグ・チェソンと、それから…）のような人たちを必要とします。

私は研究所でスタートした当初、自分の時間のほとんどはそのUnix部屋で過ごしました。活気に触れられましたが、教育には触れられませんでした。

（ダグについて言えば、彼はUnixの賞賛されていないヒーローです。それを世に送り出したグループのマネージャーであり、そのグループで彼は非常に大きな創造的な力でありましたが、Unix界でほとんど知られていません。）彼は、あなたも聞いたことがあるかもしれない2～3のものを発明しています。pipeと――いいですか―マクロです。そう、誰かがそれをしなければならなかったし、その誰かとは、ダグのことでした。かつてケンが、ある日Unix部屋で話をしているときに言ったように、「ダグより賢い奴はいない。」）

7) 言語 - by btlzu2
こんにちは！

これは何度も何度も聞かれている質問かもしれないと思うのですが、それでも、私はこれをしばしば考えてしまうのです。オブジェクト指向の設計は、 Unixが引き続き人気を博すという未来の展望を否定ないし損ねるでしょうか？

私は開発はCでやってきました（いまでも愛しています）が、最近では、Javaで純粋なオブジェクト指向の開発をたくさん行っています。委譲や再利用可能なクラスは、たくさんの意味で私の人生をとても楽にしてくれました。*nixはC言語に依存しますから、UnixとあわせたCという点で、未来をどうご覧になるだろう、と思っていたのです。私は、自分で言ったように、Cが好きですし、Unixでの開発も今でも好きですが、私見では、進歩やオブジェクト指向言語に則って築き上げるべきポイントがあるように思えるのです。

あなたの貢献のすべてに感謝します！！

パイク：
未来は実にOO色に染まっているように見えます。それはUnixに影響を与えているかもしれませんが、私はそれは疑わしく思っています。様々な種類のすべてのUnixは、Javaのアプリケーションやデスクトップ・ダンスが導くかもしれない何物であるインターネットのオペレーティング・システムという程に重要なものとなっています。それでも、しばらくの間は、Unixはパケットを送り出すでしょう。

関連する話題として、私はたいしてオブジェクト指向の設計のファンではないと言わせていただきましょう。私は、OOでいくつか美しい仕事を見たことがあるし、自分でもOOでモノを創ったことさえありますが、しかし、それはひとつの問題へのひとつのアプローチでしかないのです。いくつかの問題にとっては、それは理想的な方法ですが、またいくつかにとってはよくフィットしないのです。

ここにアナロジーがあります。あなたが、何らかの工芸品を作りたいと思ったとします。 その品の美しさに木目を与えるのが好きという理由で、純粋に木で作ろうと決めるかもしれません。実のところ、世界のもっとも美しい品々の多くは、木でできています。とはいえ、木は、何にでも理想的であるわけではありません。木目の美しさがあったところで、木では電気を扱えませんし、高層ビルも支えられませんし、折れずには大量のエネルギーを吸収することもできません。時には、金属やプラスチックや合成物質を必要となるでしょう。つまり、耐久性のある何かを作るなら、たいてい、広範な物質が必要となるのです。あなたが木が好きだということを以って、木が物質として持っている問題、つまり、他の物質によって供される可能性、を無視してはいけないのです。

オブジェクト指向設計の推進者は、時に、仕事を始める前に、木製ブロックの美しさがその姿を現すのを待っている木工品の熟達者のように思えます。「おぉ、見ろよ。この木をこっちに回して、まさにこの角度なら、この木目の流れが椅子の角度に沿う。分かるか？」　すばらしい、良い椅子です。でも、あなたは椅子に座るときに木目に気づきますか？　次に座るときならどうですか？　時として、創る必要があるものは、どの木製ブロックには隠されていないものなのです。

OOは、ひとつのインタフェイスが広範囲のタイプに自然と適用されるような問題にはすばらしいのですが、多型性（コレクションをOO言語に送り込むというたくらみは見るに気が遠くなるほどで、それで仕事をするには悲惨でありえます。）を扱うには良くありませんし、また、ネットワーク・コンピューティングには並外れて不適です。それが、私がその問題にその言語をマッチさせる権利を保留している理由であり、また、ひとつの問題を解決するのにも、複数の言語でソフトウェアをコーディネートしさえする――しばしばですが――理由なのです。

さきほどのポイント――違う副問題には違う言語を――ですが、これは、OOの人たちには欠けているように、時どき思います。典型的な労働日では、私は6言語ほど使用します。C、C++、Java、Python、Awk、Shell。そして、みなさんならそれを言語と考えさえしないようなちっちゃな言語をもっといっぱい使います。正規表現、Makefiles、シェルのワイルドカード、arithmetic、logic、statistics、 calculus――リストはまだ続きます。

オブジェクト指向の設計はUnixに十分といえるでしょうか？　もちろん、でも、機能や、 データベースや、パターン・マッチングや、ちっちゃな言語…といったものに過ぎないのです。

私がどう考えるかに関わらず、最近では、OOの設計は、人々がコンピューティングというものを考えるべく教わる方法です。それは、OKだと思います。――結局のところ、仕事はできるようであるし――でも、その見解がもうちょっと広くあったらと願うのです。

8) ひとつの仕事にはひとつの道具？ - by sczimme
現在のオペレーティング・システムとアプリケーションの性質を所与とすると、「ひとつの仕事にはひとつの道具で十分」というという考え方はもう廃れているとお考えですか？　もしそうであれば、このモデルへの回帰が、ソフトウェア開発へ革新をもたらすことに資するとお考えにはなりますでしょうか？

（小さな、単目的のアプリを放り投げてやり直すのは、大きな、機能をたくさん積んだアプリを放り投げてやり直すよりも簡単です。）

パイク：
あの頃の日々は消え去ったし、その賞賛はPerlがもたらしたものでした。

9) Emacsなの？　Viなの? - by Neil Blender

パイク：
どちらでもないです。

子供の頃は、qedを蘇らせようとedの第6版をトム・ダフやヒュー・レーデルマイヤーやデイヴィッド・ティルブルックとハックしました。qedというのは、ケン・トンプソンがCTSS用に書いたエディタで、そこには、ずっとスリムなedを創ろうという刺激がありました。（初心者はそれらを独力で学ばねばならなかった。）　デニス・リッチーが、qedの歴史をよく書いています。http://cm.bell-labs.com/cm/cs/who/dmr/qed.html

私がqedを好きな主な理由は：　たくさんのファイルを同時に編集するのに非常に良いということ。Edでは、一度に一つのファイルしか扱えない。

Edとqedは、フル・スクリーン画面用ではなく、印刷端末用に設計されたコマンド操作のライン・エディタです。私は、ベル研に就いてからviを試してみましたが、それは一度に一つのファイルしか扱えず、それでは窮屈すぎると思いました。それから、Emacsを試したが、それは複数のファイルを扱えてもqedよりももっとぎこちない。Viとemacsについて、もっとも悩まされたことは、ファイルが2次元の画面で与えられているのに、それに当たるには1次元の入力デバイスしか持ち合わせないということです。それは、テーブルの上の地図で方向を指示するのに似ているのですが、地図上に指をただ置くのではなくて、「ちょっと上、右、下には戻らないで、ちょうどそこ、そうそこで曲がったところ」と言うのを余儀なくさせられているようでありました。

（今では、emacsとviはマウスをサポートしているが、1980年に戻ると、私が接したそれらのバージョンには、マウスのサポートはなかったのです。ついでながら言うと、まだマウスなんてそんなにたくさんはなかったのですけれど。）

というわけで、Blitが動き出すや、入力デバイスとしてマウスを用いるエディタを書く時が来ました。私は、（ほとんどは）qedを使い、（すこしだけ）emacsを使って、jimのファースト・ドラフトを書きました。Jimというのは、テキストをマウスでポイントするっよう表示するフル・スクリーン・エディタです。Jimでは非常にスムースに複数のファイルを扱え、その操作は非常に簡単ではあったが、際立ててパワフルというわけでもありませんでした。（似たようなエディタがXeroxのPARCや他のリサーチ研究所にありましたが、そう、初心者はそれらを独力で学ばねばならなかった。）

数年して、私は、jimの基本的な入力アイディアを採り上げ、その下に新しいedライクなコマンド言語を据えて、それをsamと呼びました。Samは、今日でも信奉者がいるほど局所的にポピュラーとなったエディタです。私にとっては、samの成功の証拠は、ケン・トンプソンが気に入った初めてのフル・スクリーン・エディタであったことにあります。（彼は今でもそれを使っています）。ここに、samに関する1987年のSP&Eの論文があります。http://plan9.bell-labs.com/sys/doc/sam/sam.pdf

数年して、私は、エディタのコマンド操作をマウスでするポップ・アップ・メニューのモデルは非常に制限的だという結論に達し、やり直して、よりいっそう急進的なよりラジカルな、Acmeを創りました。Acmeは、これらの回答を書くのに使っているのはAcmeです。Acmeの論文はこちら：　http://plan9.bell-labs.com/sys/doc/acme/acme.pdf

これらの論文を読んでエディタを替えましょうとは、スラッシュドットの読者の誰ひとりに期待しているのではなくて、編集の――そして仕事の――仕方は、「Emacsなの？　Viなの？」などという質問で捉えられるよりずっと範囲が広がっているのだ、ということを理解するのにはそれらは読むに値するのだ、と私は考えるのです。

10) Unix最大の問題 - by akaina
最近のGoogle研究所適性テストで、こんな問題がありました。「Unixはどこが壊れているか？　あなたならどう直すか？」

どうです？

パイク：
この問題への答えとして、ケン・トンプソンと私は、Plan 9をスタートしました。1985年のこと、Plan 9とはどんなものになるかと私たちが語り始めたとき、Unixで私たちが誤りと捉えた主要なものはすべて、ネットワークの出現に起因していました。スタンド・アローンのシステムとしては、Unixはたいへん良い。しかし、Unixマシンでネットワークにつながろうとすると、得るものは、一個のシームレスで統合されたネットワーク・システムではなく、スタンド・アローンのシステムたちのネットワークなのです。ひとつひとつのマシンはそれ自身で十分なものであるというUnixの基本的な設計判断に対して行うのは、一個の大きなファイル・システムや、一個のユーザ・コミュニティや、マシンのネットワークに結びつける一個のセキュアな設定ではなく、その場しのぎの寄せ集めであったのです。

今日でも、本当に変わったものは何もありません。そういったその場しのぎがよりスムースになり、Unixマシンでできることのいくつかは非常に感動的なのですが、sshをセキュリティ・アーキテクチャの基礎とするなら、物事は働くべきようには働いていないということを知ることになります。

より低い高さから物事を見てみましょう。

1990年頃から、Googleに入った2002年まで、私は、実にまったくUnixを使っていませんでした。（私はPlan 9に全面的に従事していたし、Plan 9はその根本的な問題を解決する、かなりいい仕事をするものであると、私はやはり確信しています。）　Unixに戻ってきたとき、私は驚きました。1990年に悩まされていた物事が、小さなものでさえ如何にたくさん今日でも悩まし続けていることか、と。1975年、引数ベクトルが512バイト・ブロックに格納されていた頃、6th Edition Unixは、「引数リストが長すぎます」と、しばしば文句を言っていました。しかし、今日ではマシンには数ギガバイトのメモリがありますが、こんな馬鹿げたメッセージをあまりにも頻繁に今でも目にするのです。引数リストは今では、私の使っているLinuxマシンでは100K北方のどこかに制限されているのだが、みなさん、動的メモリ配置はすでに解決しているのですよ！

私はこの悩みの種をリストし続け始めましたが、それは非常に長くて失望させられて、私はそれらと再び暮らすようにしたところです。私たちは、実に、品質保証期限がとっくに切れた1970年代のオペレーティング・システムを使っているのです。私たちは、たくさんのことをやったし、楽しかったですが、この30年の間には、コンピューティングやネットワーキングに関して数多くの違った、すばらしいアイディアが発展してきているというのに、Unixの基本的な設計は、スラッシュドットの多くの読者よりも歳をとっている、ということを直視しましょう。Unixを使うということは、デイヴィッド・キャシディの音楽だけを聴いているということをコンピューティングで言うと同じことなのです。

11) Re: Plan9 - by Spyffe

ロブ、

今現在、Plan 9、Inferno、AtheOS、Syllable、K42、Mach、L4、等々、数多くのリサーチ・カーネルがありますが、そのいずれにも、カーネルの未来についてのあなた自身のアイディアが採り入れられています。しかし、それらすべては、UNIXのユーザランドがデフォルトなので、結局POSIXインタフェイスを実装することになってしまっています。

カーネル空間は、システムの基礎から、革新的な新しい機能性を要求するような新しいユーザランドを用いて活性化させることが必要です。ここで、あなたが次の30年間のユーザ環境を設計することになるとします。中心的な抽象概念はどんなものになりますか？　どんな種類のアプリケーションがサポートされますか？

パイク：
先ほどの答えと少々反対のことを言うリスクがありますが、反問させてください。カーネルにこれ以上の問題がありますか？　私はそうは思いません。それらは、あるレベルではまったく同じです。カーネルが行うことについて、私は以前していたようには心配をしていません。つまり、似たような状況に戻るようエミュレートするのは非常に簡単なのです。

アプリケーション――ウェブ・ブラウザ、MP3プレーヤ、ゲーム、などなど――そして、ネットワークは、その活動があるところにあり、非互換性にいらいらさせられることを措いては、カーネルは必需品です。私が気に掛けるプログラムのほとんどすべては、PCでも、Macでも、palmtopでも、その他でも、Windows上でも、Unix上でも、Plan 9上でも実行することができます。もちろん、それが、それらすべてがPOSIXインタフェイスを採用しているという理由です。つまり、だから、それらのアプリケーションをサポートすることができるのです。

それからまた、それらを糊付けするような標準的なネットワーク・プロトコルがあります。それはまったく、相互操作性（とバグ）のひとつの海なのです。

未来は、新しいソフトウェアにあるように、新しいハードウェアにもある、と考えます。今後ひとつ先の世代では、マシンは、今よりもっとポータブルでもっとパワフルで、それらがもたらす変化を考え始めてもいなかったようにもっともったインタラクティブなものになるでしょう。これは、マイクロソフトへの最大の脅威となり得るかもしれません。つまり、PCや、デスクトップ、ラップトップは、すべて、計算尺の道を行くでしょう。

ひとつの例として、フレキシブル有機半導体ディスプレイが数年内に量産されるようになります。コンピュータやその他デバイスがどこでどのように使われるかという様が変わるのは、驚くべきものとなるでしょう。大荒れになることでしょう。

===============

以上のインタビュー荒訳は、見直しの上で数日後にタレコミ予定。つぎに時間が取れるのは…、11月になってしまうかもしれない。