Chapter 20. Futures¶

未来を forcast するのは難しいが、二つの方法で anticipate することはできる：

• Unix が過去にどのように設計上の課題に対処してきたかを見る。
• 解決策を探している問題や活用待ちの機運を特定する。

Essence and Accident in Unix Tradition¶

目標は Unix の設計が将来どのように変化するかを理解することだ。そのために Unix のプログラミング流儀が過去にどのように変化してきたかを見ることから始める。

• 目標：偶然と本質の区別する。言い換えると、一過性の技術的状況から生じる特徴と、 Unix の中心的な設計課題と深く結びついている特徴を認識する。
• Unix の中心的な設計課題：システムの透明性と単純性を維持しながら、モジュール化 と抽象化をいかに正しくやるか。

偶発的に生まれた特質が本質的な有用性を持つことが後で判明することもあるから、この区別は難しい可能性がある。例：Chapter 11 で検討した「沈黙は金なり」法則。

その一方で、かつて不可欠と思われた特性のいくつかは、特定の費用比率に結びついた事故であることが判明した。例えば、

• 古の Unix は入力を一行ずつ、一レコードずつ処理する設計を好んだ。
• 新派の Unix 設計は全入力をメモリーに読み込んで、その後はランダムアクセスできる という前提で、一般的に満足している。

この変更は、より単純で透明性の高いコードを得るために、ストレージの経済性を手放すということだ。プログラマーの時間に対するメモリーの費用が急落していることへの適応だ。

Unix の設計様式を大きく変化させたな技術の変化を特定することができた：

• Internetworking
• Bitmapped graphics displays
• The personal computer

いずれの場合も、Unix の伝統はもはや適応できない偶然の出来事を捨て去り、その本質的な思いつきの新しい適用を見つけることで難題に適応してきた。

復習：

• Chapter 2: TCP/IP が Unix と ARPANET の二つの文化を結合した。
• Chapter 7: System V の STREAMS のような、時代遅れのプロセス間通信やネット ワーキングの手法に関する資料が示唆するように、Unix の開発者たちが初手から誤 り、歩みを誤り、十年間行き詰まった。

やがて TCP/IP が勝利し、BSD ソケットが「すべてがバイトストリーム」という主張を再び示すようになると混乱は解消した。1990-1991 年の WWW の発明はその帰結だ。

TCP/IP の数年後、1984 年にビットマップグラフィックスと Macintosh の例が登場したとき、さらなる難題が突きつけられた。Unix プログラマーの対応はポリシーとメカニズムの分離を明確な原則とすることだった。X Window System は 1988 年までに確立された。

X のウィンドウ部品集合を低水準のグラフィックスを扱うディスプレイマネジャーから切り離すことで、彼らは Unix 的にモジュール化されたきれいな建築方式を作り上げた。

難しいのは、Unix が統一インターフェイスポリシーを持つべきかどうか、持つとしたらどうあるべきかを決めることだった。Motif のような市販ツールキットを通じて統一インターフェースを確立しようとした試みがいくつあり、それらは失敗した。2003 年の今日、GTK と Qt がその役割を争っている。

新しい流派の Unix 設計は、コマンドラインを維持し、両方の方式で使用できる CLI エンジンと GUI のペアをたくさん書くことで、GUI と CLI の着手方法の間の緊張に対処してきた。

PC はそれ自体の技術としては設計上の大きな課題はほとんどなかった。真の挑戦は、 Unix の潜在的な市場の変化だった。ハードウェアの全体的な価格が大幅に下がったことで、PC は、技術的に洗練されていない、より幅広い使用者層にとって魅力的なものになった。

末端使用者向けデスクトップへの最初の本格的な取り組みはオープンソース共同体から生まれた。2003 年半ば現在、市場調査によると Linux の市場占有率は約 4, 5% に達した。 Apple 社の Macintosh とほぼ同等だ。

テーマ化された GUI とインストールパッケージの下では、依然としてモジュール性ときれいなコード、つまり本格的で高信頼性の演算と通信の基盤を正しく構築することに重点が置かれている。

Mozilla や OpenOffice.org のようなデスクトップに焦点を当てた大規模な開発の歴史はこの強調をよく物語っている。どちらの事例においても、共同体からのフィードバックで最も重要な主題は怪物的一枚岩に対する嫌悪感であり、これらの巨大なプログラムが厄介な存在になる前に、減量し、内部構造を整頓し、モジュールに切り分けなければならないという一般的な感覚であった。

この三技術は基本的な Unix の設計法則、つまりモジュール性、透明性、ポリシーとメカニズムの分離、そして本書の前半で特徴づけようとしたその他の品質に関しては保守的なものだった。

三十年以上にわたって強化されてきた Unix プログラマーの学習された反応は、最初の原則に戻ることだった。つまり、新しいものを重ねることよりも、ストリーム、名前空間、プロセスといった Unix の基本的な抽象化からより多くの力を引き出そうとすることだった。

Plan 9: The Way the Future Was¶

Unix を構築した Bell Labs の研究グループが設計した Plan 9 from Bell Labs はかつての Unix の未来とはどのようなものであるかを体現したものだった。Plan 9 は Unix をより良くやり直す試みだった。

• Plan 9 という名称は 1958 年の映画 Plan 9 from Outer Space へのオマージュだ。

Plan 9 設計者が試みた中心的な設計課題は：

integrating graphics and ubiquitous networking into a comfortable Unix-like framework

だった。

• 単一の大きなファイル階層名前空間を通じてシステムサービスへのアクセスを仲介する。
• 装置ファイルに類似した特別ファイルに対する読み書きで多くの機能にアクセスする。
• 装置ファイルのほとんどはテキストファイル。
• システムサービスのほとんどはファイルサーバー。
• 資源はすべてファイルとして表現する。異なるサーバー上の資源へのアクセス問題 を異なるサーバー上のファイルへのアクセス問題に転換する。

Plan 9 では Unix ファイルモデルを超えた Unix ファイルモデルと、私有名前空間という新しい概念を組み合わせた。

使用者（実際にはプロセス）はすべて、ファイルサーバーのマウントの独自の木を作成することによって、システムのサービスの独自のビューを持つことができる。ファイルサーバーのマウントは使用者が手動で設定したものもあれば、ログイン時に自動的に設定されたものもある。そのため、

Plan 9 from Bell Labs 調査資料： /dev/cons はあなたの端末装置を、/bin/date は実行する date コマンドの正し いバージョンを常に指すが、これらのファイル名がどのファイルを表すかは、dateを 実行する計算機の建築方式などの状況に依存する。

Plan 9 の単一で最も重要な特徴は、マウントされたファイルサーバーはすべて、その背後にある実装に関係なく、同じファイルシステムのようなインターフェイスをエクスポートするということだ。

• あるものは局地ファイルシステムに対応し、
• あるものはネットワーク経由でアクセスされる遠隔ファイルシステムに対応し、
• あるものは使用者空間で実行されるシステムサーバーの実物に対応し、
• あるものはカーネルインターフェイスに対応する

ことがある。使用者やクライアントプログラムにとってはすべて同じように見える。

Plan 9 の調査報告書にある例の一つは遠隔サイトへの FTP アクセスの実装方法だ。 Plan 9 では ftp(1) コマンドがない。その代わりに ftpfs ファイルサーバーがある。各 FTP 接続はファイルシステムのマウントのように見える。

Plan 9 には

• Unix のシステムコールインターフェイスの問題点の再発明
• スーパーユーザーの廃止
• その他多くの興味深い再考

など、推薦できる点がたくさんある。設計は上品で、Unix の設計におけるいくつかの重大な誤りを露呈している。なぜ世界を征服しなかったのか。

歴史の長い目で見れば話は違ってくるかもしれないが、2003 年の時点では、Plan 9 が失敗したのは、単に Unix の先祖を置き換えるほどの説得力のある改良には至らなかったからだと思われる。Unix はガタが来ているものの、その地位を維持するのに十分な仕事をこなしている。

There is a lesson here for ambitious system architects: the most dangerous enemy of a better solution is an existing codebase that is just good enough.

Plan 9 の作意のいくつかは現代の Unix, とりわけ革新的なオープンソースのバージョンに吸収されている：

• FreeBSD には、Plan 9 を正確にモデル化した proc ファイルシステムがあり、 実行 中のプロセスの問い合わせや制御に使うことができる。
• FreeBSD の rfork(2) と Linux の clone(2) システムコールは Plan 9 の rfork(2) を手本にしている。
• Linux の /proc ファイルシステムはプロセス情報の提示に加えて、主にテキストイ ンターフェイスを使用してカーネル内部を照会し制御するために使用される、さまざま な人工 Plan 9 風装置ファイルを保持している。
• Linux の実験的な 2003 年版はプロセスごとのマウントポイントを実装している。 Plan 9 の私有名前空間への大きな一歩だ。
• オープンソースの Unix はすべて、Plan 9 のために実際に発明された UTF-8 をシステ ム全体で支持する方向に進んでいる。

Unix の建築術のさまざまな部分が老衰に向かうにつれて、Plan 9 の多くが Unix に導入されることになるかもしれない。

Problems in the Design of Unix¶

Plan 9 は Unix をすっきりさせた。基本的な設計構想に新しい思想である私有名前空間を加えたことしかしなかった。

A Unix File Is Just a Big Bag of Bytes¶

Unix のファイルは単なるバイトの大きな袋であって、他の属性はない。特に、

• ファイル型に関する情報
• 関連するアプリケーションプログラムへの関連

のようなものはない。

より一般的には、すべてがバイトストリームであり、ハードウェア装置でさえそうだ。ここの比喩（そうではないなのか？）は初期の Unix で大成功を収めた。パイプとシェルプログラミングはこの比喩から生まれた。

Unix のバイトストリーム比喩はあまりにも中心的なものであるため、バイトストリームやファイル操作にうまく当てはまらない操作を持つソフトウェアオブジェクトを統合するのに苦労している。これは GUI オブジェクトでは特に問題となる。

Unix 支持者はファイルデータを自己記述させる取り組みを好み、実質的に同じ種類のメタデータがファイル内に格納されるようにする。この手法では、ファイルを書き込むプログラムすべてがそのファイルについて知っていなければならないことが問題だ。例えばファイルに型情報を持たせたい場合、ファイルに触れるすべての工具は、型欄を変更せずに保存するか、解釈してから書き換えるかのどちらかに注意しなければならない。

一方、ファイル属性を指示すると、どのファイル操作で属性を保持するかという厄介な問題が生じる。名前付きファイルを別の名前にコピーする場合、データだけでなく元ファイルの属性もコピーすべきであることは明らかだ。しかし、そのファイルを cat(1) し、 cat(1) の出力を新しい名前にリダイレクトする場合はどうなるか。

質問はこうなる：どの操作がもちものを明らかにするのか。

Xerox PARC ファイルシステム設計はの問題に取り組んでいた。属性と内容物の両方を含むバイトストリームを返す open serialized 呼び出しを持っていた。ディレクトリーに適用すると属性のシリアライズとその中のすべてのファイルのシリアライズが返された。

Linux 2.5 では任意の名前と値のペアをファイル名のもちものとして取り付けることをすでに支援しているが、本稿執筆時点では、この機能はアプリケーションではまだあまり使われていない。最近のバージョンの Solaris にはほぼ同等の機能がある。

Unix Support for GUIs Is Weak¶

Unix の経験は、フレームワークの基礎としてわずかな比喩を使うことが強力な戦略であることを証明 (Chapter 13) している。現代の GUI の中心にある視覚的比喩（アイコンで表現されたファイル、そしてクリックすることで開かれ、指定された処理プログラムを呼び出す）は、1970 年代に Xerox PARC が先駆者となって以来、使用者とインターフェイス設計者に強い影響を与え、成功と長寿の両方を証明してきた。

2003 年現在、Unix はまだこの比喩を不十分かつ不本意な形でしか支援していない。 Unix の古参者の典型的な反応は、これが GUI 比喩自体の深い問題を反映しているのではないかと疑うものだ。

Steve Johnson: 例えば、Mac ではファイルをゴミ箱にドラッグして削除する。ディスクにドラッグするとコピーされる。印刷機アイコンにドラッグすると印刷はできない。他にもいろいろある。

GUI には欠点もあるが、末端使用者からの需要は大きい。仮に、UI の設計段階で比喩を正しく理解できたとして、Unix はそれを丁重に支援できるだろうか。

Macintosh 流のファイル属性は GUI をより豊富に支援する仕組みを備えるのに役立つかもしれないが、それが答えのすべてである可能性は相当低いと思われる。Unix のオブジェクトモデルには適切な基本構造が含まれていない。GUI のための本当に強力なフレームワークがどのようなものか、そして、それが Unix の既存のフレームワークとどのように統合できるかを考え抜く必要がある。

File Deletion Is Forever¶

VMS や TOPS-20 というシステムにはファイルバージョン管理機能が備わっていたらしい。既存のファイルを書き込みのために開いたり、削除したりすると、実際にはバージョン番号を含む予測可能な方法でファイル名が変更された。実際にデータが消去されるのは、バージョンファイルに対する明示的な削除操作が必要だった。

Unix ではこのようなことはなく、打ち間違いやシェルのワイルドカードの予期せぬ影響によって使用者の意図でないファイルが削除される。

Unix の開発者は、たとえ使用者の指示が「自分の足を撃て」という命令に等しいものであったとしても、指示したことを実行する明確で単純な操作を好む。彼らの本能は、使用者を自分自身から守ることは OS ではなく、GUI やアプリケーション水準で行うべきだということだ。

Unix Assumes a Static File System¶

• プログラムは暗黙のうちに短時間しか実行されないと仮定すれば、ファイルやディレク トリーの背景は、その実行中は静的であると仮定できる。
• 指定されたファイルやディレクトリーが変更されたときに、アプリケーションに通知す るようにシステムに要求する標準的方法が確立していない。

背景の変更について知りたがっている長寿命の UI ソフトウェアを書くときに重要な問題となる。

Linux にはファイルとディレクトリーの変更通知機能があり、BSD のいくつかのバージョンはそれをコピーしているが、これらはまだ他の Unix に移植可能ではない。

The Design of Job Control Was Badly Botched¶

プロセスを suspend する機能を除けば、ジョブ制御とは複数のプロセス間で端末を切り替えることだ。最も簡単な部分、つまりキーストリークの行き先を決めるだけで、画面の状態を保存したり復元したりといった難しい部分はすべてアプリケーションに押し付ける。

このような機能の本当に優れた実装は、使用者プロセスからは完全に見えない。専用信号も、端末モードの保存と復元も、アプリケーションが不定期に画面を再描画する必要もない。

仮想キーボードが実際のキーボードに接続されることがあり（接続されていないときに入力を要求するとブロックされる）、仮想画面が実画面に表示されることがあるというモデルであるべきで、システムはディスクや演算装置などへのアクセスのそれと同じ方法で多重化を行い、使用者プログラムにはまったく影響を与えない。

以上を正しく行うには、Unixの tty ドライバーが、単に行バッファーを維持するだけでなく、現在の画面状態全体を追跡し、カーネルレベルで（おそらくデーモンプロセスの助けを借りて）端末の型を知る必要がある。これを誤ると、Unix カーネルは xterm や Emacs ジョブのようなセッションをある端末から切り離して、別の端末（別型の場合がある）に再接続することが不可能になる。

Unix の利用が端末エミュレーターなどに移行するにつれ、ジョブ制御の重要性は相対的に低下し、この問題はかつてのような影響力を持たなくなった。

プログラム screen(1) はこれらの問題のいくつかを解決している。しかし、使用者が明示的に呼び出す必要があるため、その機能がすべての端末セッションに存在することは保証されていない。

The Unix API Doesn't Use Exceptions¶

Unix 実装言語である C には例外機能がない。そのため、Unix API の C 関数は識別値（通常は -1 または NULL ポインター）を返し、大域変数 errno を設定することでエラーを示す。

これが多くの微妙な失敗の原因となっている。急いでいるプログラマーは戻り値の確認をしばしば怠る。例外が送出されないため、Rule of Repair に違反する。エラー状態が実行の後半で何らかの障害やデータ破損として現れるまで、プログラムの流れは続く。

例外がないということは、複雑で、移植性に問題があり、バグが発生しやすいコードで実行されなければならないということでもある。

この問題は例外を持つ Python や Java のような言語で Unix API をバインディングすることで隠せる。

C 言語は型の枠組が弱いので、C 言語で実装された高水準言語間の通信に問題があるのだ。例えば、現代的な言語のほとんどはリストや辞書を主要なデータ型として持っている。しかし、これらは C の世界では正統的な表現を持っていないため、例えば Perl と Python の間でリストを渡そうとすると、多くの接着剤を必要とする不自然な行為になる。

ioctl2 and fcntl2 Are an Embarrassment¶

これらは文書がしばしば不十分であり、移植性の問題の原因にもなっている。そのたびに操作型や特殊な引数値を記述したマクロ定義が山ほど出てくる。

Unix のオブジェクトモデルは弱く、多くの補助操作を置く自然な場所がない。設計者は満足のいかない選択肢の中から整然としたものを選択しなければならない：

• /dev にある装置を経由する fcntl/ioctl
• 新しい特別な目的のシステムコール
• カーネルにフックする特別な目的の仮想ファイルシステムを経由するフック (e.g. /proc)

Unix のオブジェクトモデルが将来的に強化されるかどうか、あるいはどのように強化されるかは定かではない。

• Mac OS のようなファイル属性が Unix の一般的な機能になれば、デバイスドライバー で魔法名前付き属性を微調整することが、現在の ioctl/fcntl の役割を引き継ぐ かもしれない。この場合、マクロ大量定義を必要としないという利点がある。
• Plan 9 が示したような、ファイル・バイトストリームではなく、名前付きファイル サーバーやファイルシステムを基本オブジェクトとして使用する方向。

The Unix Security Model May Be Too Primitive¶

おそらく root は強力であり過ぎる。何でもできる superuser を一人にするのではなく、システム管理機能のために、よりきめ細かい機能や ACL を持つべきだ。あまりにも多くのシステムプログラムが setuid メカニズムによって永久的な root 権限を持っている。一箇所でも侵害されれば、あらゆるところがそうされることになる。

しかし、この議論は弱い。最近の Unix では任意のユーザーアカウントが複数のセキュリティーグループに属することができる。プログラム実行ファイルの実行権限ビットと setgid ビットを使うことで、各グループは事実上、ファイルやプログラムの ACL として機能することができる。

しかし、この理論的な可能性はほとんど利用されておらず、ACL の需要が理論上よりも実際にははるかに少ないことを示唆している。

Unix Has Too Many Different Kinds of Names¶

Unix で統一されたファイルや局地装置はすべて単なるバイトストリームだ。しかし、ソケットを通してアクセスされるネットワーク装置は異なる名前空間で異なる語義を持っている。

Plan 9 はファイルを局地装置と遠隔（ネットワーク）装置の両方と滑らかに統合できること、そしてこれらすべてを、使用者ごと、さらにはプログラムごとに動的に調整可能な名前空間を通じて管理できることを示している。

File Systems Might Be Considered Harmful¶

ファイルシステムを持つことが Unix の失敗であるとすれば、それはすべての競合 OS の失敗でもある。

記憶ストレージを巨大なスワップ領域として扱い、仮想化されたオブジェクトポインターを通じてすべてを行う OS に関する興味深い研究の歴史があった。

この分野での最新の取り組みは、このような設計が安全保障方策への証明可能な適合性と、より高い性能の両方を含む、大きな利点を与えられることを示唆している。

Towards a Global Internet Address Space¶

URL では不十分なのかもしれない。

Ken Thompson: 私の将来の理想は、Plan 9 のようなファイルシステムの遠隔インターフェイスを開発し、HTML ではなく標準としてインターネット上で実装することだ。

Problems in the Environment of Unix¶

オープンソースの問題が Unix 文化人のものにもなった。

その一つはオープンソース開発を経済的に持続可能なものにする方法だ。長い道のりを歩んできた。どのようなビジネスモデルが有効かは理論的には分かっているし、実際に機能することを示す成功を少しは挙げることもできる。今は、より長期にわたって確実に機能することを示さなければならない。

オープンソースはソフトウェアをサービス産業に変える。サービス提供型企業（医療や法律事務所を思い浮かべろ）は、資本を注入することで規模を拡大することはできない。固定費だけを拡大しようとしても、収益基盤を行き過ぎて餓死するだけだ。選択肢は次に絞られる：

• 祝儀や寄付で報酬を得る
• 小規模で間接費の少ないサービス業を経営する
• 裕福な金主（業務目的でオープンソースソフトウェアを使用し、修正する必要がある大 企業）を見つける

自動車の価格が下がると整備工の時給が上がるのと同じ理由で、ソフトウェア開発者を雇うために使われる金額は、全体として上昇することが予想される。

本当に大規模なソフトウェアビジネスを維持することが難しくなっていることに関連する重要な副次的問題の一つは、末端使用者試験をどのように組織化するかということだ。

• Unix 文化は基盤に集中してきた歴史があり、末端使用者に快適なインターフェイスを 与えることにその価値を依存するプログラムを構築する傾向がなかった。
• 末端使用者インターフェイスを、実際の末端使用者を使って系統的に試験する必要があ る。

ワープロ、表計算、その他生産力のあるアプリケーションは末端使用者試験に必要な設備、人員を手配するのが困難だと長々と述べられている。

Hollywood と Big Media はインターネットに深い脅威を感じており、無秩序なソフトウェア開発に対して多角的な攻撃を開始した。Digital Millennium Copyright Act のような既存の法律は、メディア大物が嫌うことを行っているソフトウェア開発者を起訴するためにすでに使われている。いわゆる Trusted Computing Platform Alliance や Palladium のような構想中の企画はオープンソースの開発を事実上違法にする恐れがある。

政治の可能性は通信技術によっていよいよ形成されている。誰がそれを使い、誰がそれを検閲し、誰がそれを統率できるのか。政府や企業がネットの内容や、人々が自分の計算機でできること統率することは政治的自由に対する長期的な脅威だ。

Problems in the Culture of Unix¶

Unix を取り巻く共同体の文化的な問題として、少なくとも深刻な問題が二つある。

• （あまり大きくない問題）内部的な移行
• （大きい問題）歴史的なエリート主義の克服

それより小さい課題は、

• 旧来の Unixの達人たちと新しいオープンソース勢との間の摩擦

だ。特に Linux の成功は、多くの古参の Unix プログラマーにとって、世代的な問題もあり、まったく快適な現象ではない。年長者が失敗したところで子供たちが成功しているという事実によってさらに悪化している。

The greater problem of psychology only became clear to me after spending three days at a Macintosh developer conference in 2000. It was a very enlightening experience to be immersed in a programming culture with assumptions diametrically opposed to those of the Unix world.

それは良かった。

Macintosh のプログラマーは使用者体験にこだわる。まず「どんな相互作用を支援したいのか」と問いかけ、UI 設計の要求を満たすために、その背後にあるアプリケーション論理を構築する。その結果、プログラムはべらぼうに美しく、基盤は脆弱でガタガタになる。

それとは対照的に、Unix 人は基盤がすべてだ。私たちは、抽象的に定義された問題を解決するために、強大なエンジンを構築し、内側から外側へと設計する。そして、そのエンジンに、薄くて、しばしばべらぼうに醜いインターフェイスを巻きつける。コマンド date(1), find(1), ed(1) は悪くて有名な例だが、他にも何百とある。

どちらの設計思想にもそれなりの正当性はあるが、この二つの陣営は互いの主張を理解するのがとても難しい。

Unix 人はインターネットと WWW の番人なのだ。Unix 人のソフトウェアと伝統が 24 時間 365 日の信頼性と最小限の休止時間が必須のアプリケーションを支配している。この実績に近いソフトウェア技術文化は他にはない。

And our implicit demand is that if you want to use our software, you must learn to think like us.

Unix 人の姿勢には両義性がある。

• GNOME や KDE のような、Unix にきれいな顔を与えるように（独特の表現）設計された プロジェクトに大きな労力を費やしている。
• Tillie （※典型的な非技術使用者。高齢で散漫な乙女）の要望に共感したり、耳を傾け たりすることには消極的で、多くの場合、耳を傾けることができない。

Unix 人の文化としての最大の挑戦は、これまで役に立ってきた思い込みを卒業できるかどうか、つまり、Macintosh の人々の言い分にも一理あることを、日々の実践の中で認めることができるかどうかということだ。

The Inmates Are Running the Asylum (1999) という論証的な本を読むことを推奨している。Unix プログラマーが知っておくべき厳しい真実が数多く含まれている。

Chapter 4 では技術的な問題を解決する上で、限定的な思い込みを捨て、過去を捨てることの重要性について述べた。禅の「離俗」や「初心」の思想との類比を示唆している。謙虚さを学ばなければならない。過去に成功を収めた長年の偏見を捨てなければならない。

Macintosh 文化が Unix 文化に収束し始めた。MacOS X の下には Unix があり、2003 年、 Mac の開発者たちは Unix の基盤重視の良さを学ぶために精神的な調整を行なっている。 Macintosh の使用者中心の美徳を受け入れることが Unix 人の挑戦となる。

リファクタリング、単体試験、その他のアジャイルコンセプトは、これまで Unix の伝統の中で暗黙のうちに広まっていた実践を明確にし、研ぎ澄ますものだ。一方、Unix の伝統はアジャイルプログラミング派に、地に足のついた、長い経験からの教訓をもたらすことができる。昔のインターネット文化と初期の Unix 文化が融合したときのように、アジャイルと Unix の文化がそうなることも考えられる。

Reasons to Believe¶

Unix の三十年以上の挑戦で収めてきた成功：

• ソフトウェア工学の最善実践の先駆者だ。
• 今日のインターネットと Web を作り上げた。
• これまでに存在した中で最も大きく、複雑で、信頼できるソフトウェアシステムを構築 してきた。
• IBM の独占を凌駕し、Microsoft の独占を脅かすのに十分な実績を上げている。

決してすべてが勝利したわけではない：

• 1980 年代、Unix の独占的奪取に屈し、すんでのところで自滅するところだった。
• 技術者でない末端使用者をあまりにも長い間軽視し、それによって Microsoft にソフ トウェアの品質基準を著しく低下させる隙を与えてしまった。

失敗から学ぶこともある。初期の学術機関ハッカー、ARPANET の実験者、マイコン愛好家、その他多くの文化から、優れたものを吸収してきたのだ。オープンソース運動は Unix 人の初期の活力と理想主義を復活させ、かつてないほど強くなり、人数もより多くなっている。