はじめに
え？みんなこんな本を UNIX 哲学のオススメ本って紹介してるの？ あえて煽りから入らせていただきます。UNIX 哲学を語る本としてマイク・ガンカーズ (Mike Gancarz) の「UNIXという考え方 - The UNIX Philosophy その設計思想と哲学」はおそらく日本で一番有名な UNIX 哲学の解説本です。名著と言われている通り素晴らしいこともたくさん書かれています。しかし前提知識を持たない人が、この本を読んで正しく UNIX 哲学を理解するのはかなり難しいです。
- 注意 この記事の趣旨を勘違いされませんよう「コメント」もぜひお読みください。
- 2022-08-27 関連記事「シェルスクリプトを学ぶ人のための「新しいUNIX哲学」 〜 ソフトウェアツールという考え方」を執筆しました。
「UNIX という考え方」を正しく読むのが難しい理由の一つは古すぎる技術に基づいた古典だからです。古典は物語の時代背景を知らねば正しく理解することは出来ません。もう一つの理由は著者のガンカーズの立場からくる（少々偏った）UNIX 哲学を説明しているからです。しかし困ったことに ガンカーズって一体何者なんですか？ という問題があります。ガンカーズの事は「UNIX という考え方」を書いたこと以外あまり知られていません。彼が何者なのか簡単にはわからないので、一体どういう立場で UNIX 哲学を説明しているのかがわかりません。さらにガンカーズは重要な事実、何を参照しているとか、どのバージョンの話なのか等を明確に書かない癖があるようで、物語の読者は「作者の気持ち」を推測して読まなければいけません。偉い人（？）が書いた本で、みんなが奨めているのだから、書いてある内容も正しいのだろうで判断していると間違った解釈をしてしまいます。
「ガンカーズの UNIX 哲学」というのは UNIX が誕生した 1969 年の 10 年後の 1980 年から 1990 年中頃、世の中に広がった UNIX に惚れ込んだ人たちが持っていたであろう考え方を、ガンカーズが「UNIX 哲学とはこういうものだ！」という形で 1994 年に紹介した本です。UNIX が誕生してから 25 年も後に出版された本なのです。しかも誰の考えなのかその出どころははっきりとはわかりません。誰が書いたかは重要ではない。問題は中身だ。と言われればそのとおりなのですが、その肝心の中身、つまり ガンカーズの UNIX 哲学の理論的根拠は、技術的に間違いといっても過言ではないぐらいに古くなってしまっています。例を上げると小さい実行イメージはパフォーマンス（実行速度）が高いと書かれているのですが、その技術的な根拠は「スワップやページングが劇的に減るため性能が大幅に向上する」からです。それはコンピュータに搭載されているメインメモリが数百 KB 〜 数 MB しかなく、スワップやページングがどうしても避けられない時代の話です。もちろん最初から技術的に間違った内容として出版されたわけではありません。出版されてから 30 年近く経って古くなってしまっただけです。
「UNIX という考え方」を薦めている人は多いようですが、これを正しく読むには前提知識が必要です。例えば若い人は 20 年以上も前になくなった DEC という会社のことなんか知らないので、そこから始める必要があります。それくらい常識だろという人もいるかも知れませんが、わからない人には全くわかからない話です。この本を読むときの鉄則は「技術書として読まないこと」です。この本に書かれた技術的内容はそのまま捉えるのではなく変形・拡張して考える必要があります。書かれた内容にそのまま従うのではなく、時代背景を知り、文章の意図を汲み取り、今の時代に対応させて読み替えることができない人は「UNIX という考え方」で UNIX 哲学を学ぶことはオススメできません。
とまあいろいろ批判的なことを書きましたが、名著や良書と呼ぶ事に異論があるわけではありません。ただ読むのに注意が必要ということです。この記事は「UNIX という考え方」を読んで勘違いしないようにするための「ガンカーズの UNIX哲学」の解説記事・・・の前編です。本当はもう少し UNIX 哲学の内容に踏み込みたかったのですが、文章量の都合で後編に回します。まずは謎のベールに包まれている著者のガンカーズは一体何者なのか？何を考えていたのか？に迫りたいと思います。
なお「UNIX という考え方」がオススメできないなら他に何があるんだよ？と聞きたい人のために一例を紹介しておきます。UNIX 哲学に興味がある人には、私は以下の本の方をオススメします。
-
The Art of UNIX Programming（「UNIX」に興味がある人向け）
- 「伽藍とバザール」で有名なエリック・レイモンドによるもう一つの UNIX 哲学本
- 2003 年出版なので「UNIX という考え方」よりも現代的である
- UNIX および Linux の技術的な話はこちらの方が圧倒的に詳しくて実践より
- Unix の長所だけではなく短所も語っており公平である
- 引用先を明記して、それが正しいかどうかを考察しており内容に納得できる
- 英語版なら無料で読める
-
人月の神話（「考え方」に興味がある人向け）
- 初版は「UNIX という考え方」の 1994 年よりも更に古い 1975 年
- UNIX よりも古いメインフレーム用 OS の開発の話
- ここまで古くて異なる技術だと逆にそのまま従うという発想もないと思う
- 結局ソフトウェア開発の基本的な考え方は昔も今も変わってないということがわかる
この記事は「名著訂正シリーズ」第二弾です。第一弾は「名著「入門UNIXシェルプログラミング」の超詳細なレビューをしてみた」です。第三弾があるかどうかは未定です。
「UNIX という考え方」を読む上での前提知識
この本はガンカーズの個人の考えと人生観が反映されたものである
技術書に限らず個人が書いた書籍は個人の考えや人生観が反映されるのが当たり前ですが、この本はそうとわかりにくい記述になっています。「UNIX という考え方」は完全に検証された正しい記述だけが書かれた教科書ではありません（教科書であっても間違ったことだらけの本も多々あるで私は無条件で信用することはありませんが）。私は最初、前提知識を持たない状態でこの本を読んだ時に、これは UNIX 哲学の教科書的なものなのだろうか？と勘違いしてしまいました。その理由の一つは文章が断定調で書かれているからです。（多くの人から認められた）提唱者の場合や理論を証明した上でのことであれば断定調でも構わないと思うのですが、ガンカーズの場合はそうではありません。しかしガンカーズが一体何者なのこの本からはわかりにくいため、断定調だから世の中で広く認められた提唱者なのだろうと勘違いされやすい問題があります。
他にも勘違いを引き起こしそうなものとしては wikipedia の不正確な記述があります。2022 年 7 月 14 日時点での「ガンカーズ: UNIXの哲学」の説明には以下のように書かれています。
1994年、マイク・ガンカーズ（X Window System開発チームの一員）は、UNIXで得た経験と、同僚プログラマーやUNIXに依存する他分野の人々との議論を活かし、以下の9つの至上命令に集約される「UNIX哲学」を創出した。
「至上命令」の意味は「絶対に服従しなければならない命令」です。wikipedia の文章を参考にしていけないというのは、よく言われている話ですが日本語の wikipedia は特にひどいです。この文章は「en:Unix philosopy (00:34, 16 May 2008 UTC) を翻訳」らしいのですが、元の文章は「paramount precepts」であり、せめて「最重要の教訓」とするべきで、後述の「The 10 lesser tenets」に対応させて「主要な教訓」がベストなのではないかと思います。教訓 (precepts) が命令に変わっておりほとんど誤訳であると言えます（注意 翻訳者を非難する意図はありません）。「至上命令」を鵜呑みにしてしまうとガンカーズの個人の考えを至上命令のように勘違いしてしまうのは仕方ない話でしょう。
ガンカーズは今は無きコンピュータ会社 DEC のプログラマー
"ガンカーズの" UNIX 哲学を紹介した「UNIX という考え方」は（なぜか日本で）有名なものになっているようですが、ガンカーズは UNIX を開発した AT&T の人間ではありません。DEC という今は存在していない昔の有名なコンピュータ会社のプログラマー（兼コンサルタント）です。それを匂わすようなことは書いてあるのですが明確には書かれていないため、気がついてない人が結構いるような気がします。wikipedia には「X Window System 開発チームの一員」と書いてあるのですが、それよりも書くべき事は「DEC の プログラマー」だと思うのですが、このように書いてあるのは少々不思議でなりません。
UNIX は DEC のコンピュータ（ミニコン）の PDP-7 で動く OS として作られました。その点で UNIX の誕生と DEC に繋がりはあるのですが、UNIX の創始者であるケン・トンプソンが PDP-7 を選んだ理由は、社内で見つけた廃棄寸前になっていた古いコンピュータが PDP-7 だったという程度のものです。一方、DEC は UNIX が開発される以前から TOPS-10 や RSX-11 といった自社の独自 OS を開発しており、DEC が独自の UNIIX を開発するのは AT&T で UNIX が開発された 1969 年から 10 年後の 1980 年です。これは Research Unix として最後に広く公開された Version 7 Unix の開発よりも後のことです。
私が調べた限りガンカーズは DEC のプログラマーの一人に過ぎず（それなりの地位にあったのだろうとは思いますが情報は殆ど見つかりません）、UNIX 創始者たちと特につながりがあったわけでもなさそうです。つまり「UNIX という考え方」にかかれている「"ガンカーズの" UNIX 哲学」というのは、外部の人間が後から打ち立てた哲学だということです。
起源の UNIX 哲学 (1973) とガンカーズの UNIX 哲学 (1994)
UNIX 哲学の起源となる考え方は 1973 年に AT&T ベル研究所で誕生しました。これはガンカーズが自身の UNIX 哲学を打ち立てる 20 年前も前のことです。個人的には 1973 年の時点から「UNIX 哲学 (Unix philosophy)」という"言葉"が使われたかどうかは疑問の余地があると思っていますが、すくなくとも 1989 年に行われた AT&T のダグラス・マキルロイへのインタビューで「UNIX 哲学」という言葉が使われており、UNIX 哲学と言われる"考え方"（別の言い方をすると UNIX はツールのコレクションという考え方）は 1973 年にパイプの誕生と共に生まれたと明らかになっています（参考 Pipe: How the System Call That Ties Unix Together Came About）。
マキルロイは UNIX 開発の初期の頃から参加しており、プログラムとプログラムを接続する方法、すなわちパイプの実装をトンプソンに強く提案していた人物です。マキルロイがプログラム同士を繋げる方法が必要だと考えたのは 1964 年、Unix の誕生よりも前のことでその時のメモが残っています（ただしパイプと同様の仕組みは 1964 年の DTSS のコミュニケーションファイルという前例があります）。マキルロイは 1970 年から 1972 年にかけてトンプソンに何度もパイプの案を提案します。そしてある日、パイプに合わせたシェルの構文を考えだした時にトンプソンが実装すると決断します（というかトンプソンが根負けした感じです）。この話については Interview with M.D. McIlroy Murray Hill, 18 August 1989 に詳細が書かれています。ちなみにパイプを | で表すのはトンプソンの発案です。マキルロイは > を提案していました。
ガンカーズの UNIX 哲学というのは、マキルロイの UNIX 哲学が誕生してから 20 年後に打ち立てたれたもので、それまでのさまざまな人の考え方をまとめたものに過ぎません。しかし「UNIX という考え方」にはその事が書かれていません。序文にはガンカーズが UNIX の考え方について解説している書籍は無いものか？と最初に考えたのは 1991 年とあります。であれば 1989 年のマキルロイへのインタビューを見つけていてもおかしくありませんが、知ってか知らずかマキルロイの名前すら出てきません。そのため UNIX 哲学について「UNIX という考え方」しか読んでいないような人は、ガンカーズの UNIX 哲学が唯一の公式な UNIX 哲学で、ガンカーズが正統な UNIX 哲学の提唱者であると勘違いしてしまう可能性があります。ガンカーズの UNIX 哲学は、おそらく UNIX に関わっている知人や同僚から意見を集めて作った草の根的なものです。絶対に守らなければいけない戒律的な規則でもなく、そういう風に考えていた人がいました程度のものです。
1973 年のパイプの誕生によってプログラムとプログラムをつなげることが可能になりました。ここから「UNIX はツール（コマンド）のコレクションである」という考え方が生まれます。これが UNIX 哲学です。その後に出版された本、1976 年の「Software Tools」（日本語版は 1981 年出版の「ソフトウェア作法」）というタイトルからもソフトウェアツールという考え方が生まれていることがわかります。この本の著者は AT&T のブライアン・カーニハンと P. J. プローガーです。この本ではパイプでつなぎ合わせて動かすことができるツール（コマンド）をどのように作るべきかということが説明されています。アルゴリズムを考えて自分でツールを作っていくという形の説明ですが、古い所があるのと擬似言語が使われてるので少々癖が強いです。カーニハンは「プログラミング言語 C」の著者としても有名です。
また「UNIX 哲学」そのものではありませんが「哲学」または「UNIX プログラミング哲学」という用語であれば AT&T のブライアン・カーニハンとロブ・パイクが 1984 年に出版した「The UNIX Programming Environment」（日本語版は「UNIX プログラミング環境」）の中で使用しています。この本の「はじめに」で著者は「UNIXを効果的にしているのは、プログラミングへのアプローチの仕方、つまりコンピュータ利用の哲学である。この哲学を一言で書きつけることはできない。しかしその核心にあるのは、システムの力というのは、個々のプログラムよりも、それらのつながり方にあるという考えである。UNIXの多くのプログラムは、それぞれ独立に極めて細かな仕事をする。しかし、他のプログラムと結合すると、汎用的で役に立つツールとなるのである。」と UNIX のプログラム（コマンド）はツールであり、それらを組み合わせることの重要性を説明しています。
UNIX 哲学として有名なものにはも一つ「レイモンドの UNIX 哲学」があります。レイモンドの UNIX 哲学は 2003 年に出版された「The Art of UNIX Programming」の中で詳細に解説されています。（レイモンドのやつは「UNIX 思想」ではないのか？と考える人へ説明するとそれは訳が異なってるだけで原著ではちゃんと「UNIX Philosophy」となっています）。UNIX 哲学に従ったプログラムを書くのであればこちらを参考にした方が良いです。そもそも「UNIX という考え方」は技術的な解説を省いているので、UNIX 哲学に従ったプログラムの書き方はわかりません。
このように UNIX 哲学というのは誰か一人が考え出したものではなく、ガンカーズの UNIX 哲学が最初でも公式でもないということがわかると思います。
マキルロイの UNIX 哲学 (1978)
AT&T で UNIX 哲学という考え方が生まれたのは 1973 年ですが、これが初めて文書化されたのは 1978 年に発表された論文 Unix Time-Sharing System: Foreword です。これを「マキルロイの UNIX 哲学」と呼ぶことにします。（以下の文章は「The Art of UNIX Programming」の日本語版に書かれた「マキルロイの UNIX 哲学」の引用です）
(i) 個々のプログラムは1つのことをしっかりやるようにせよ。新しい仕事をするなら、新しい機能を追加して古いプログラムを複雑にするのではなく、まったく新しいプログラムを作れ。
(ii) すべてのプログラムの出力は、他の未知のプログラムの入力になるのだということを予想せよ。余分な情報で出力をごちゃごちゃにしてはならない。縦方向の並びを厳密に揃えたり（下記補足参照）、バイナリ入力形式を使ったりすることを避けよ。対話的な入力にこだわるな。
(iii) オペレーティングシステムであっても、ソフトウェアは早く（できれば数週間以内に）試せるように設計、構築せよ。まずい部分は捨てて作り直すことを躊躇するな。
(iv) 技能の低い者に手伝ってもらうくらいなら、プログラミングの仕事を明確にするためにツールを使え。ツールを作るために遠回りしなければならない場合でも、使ったあとで一部のツールを捨てることになることがわかっている場合でも、ツールを使え。
補足 原書では「Avoid stringently columnar」と書かれており、おそらくスペースで位置調整するのは避けようという意味だと思われます。見た目のための位置調整は余分な情報であり、コマンドによってはスペースの数の違いで異なる動作を行います。（参考 Why should you avoid "stringently columnar" input formats?）。ちなみに ls -x の説明にも columnar という用語が使われておりカラム表示（つまりスペースによる位置調整）に関係する機能です。
上記の「マキルロイの UNIX 哲学」のを要約したのが先程の 1989 年のインタビューの内容です。
McIlroy: Yes, the philosophy that everybody started putting forth, “This is the Unix philosophy. Write programs that do one thing and do it well. Write programs to work together. Write programs that handle text streams, because that is a universal interface.”
翻訳 マキルロイ: はい、皆が打ち出し始めた哲学「これが UNIX 哲学だ。一つのことをうまくやるプログラムを書け。連携して動作するプログラムを書け。テキストストリームを扱うプログラムを書け、なぜならそれは普遍的なインターフェースだ」
「プログラムを書け」と言っていることからもわかるようにプログラムを書くことが出来るプログラマのための哲学です。「ガンカーズの UNIX 哲学」に比べて「マキルロイの UNIX 哲学」はそれほどの多くのことを言っていないということに注意してください。ガンカーズの UNIX 哲学というのは後から（誰かの考えで勝手に）追加されたものなのです。マキルロイの UNIX 哲学では C 言語を使えともシェルスクリプトを使えとも言っていません。ここでいうプログラムとは CLI コマンドのことを指していると思いますが、よく読むと CLI コマンドにしろともパイプを使えとも言っていないということは重要な事実かもしれません。つまりサービス（デーモン）を作って HTTP プロトコルでやり取りするような場合でも「連携して動作するプログラム」と言えるはずです。
DEC というコンピュータ会社について
DEC は コンピュータ会社の名前です。20 年以上も前になくなってしまったので今では馴染みの薄い会社となっており知らない人も多いでしょう。実の所、私も DEC の事はよく知りません。最盛期は IBM に次いで世界 2 位のコンピュータ会社でハッカー気質の会社だったようです。「UNIX という考え方」は DEC のガンカーズが見た UNIX の世界が書かれているので、本に書いてあることを理解するには DEC のことをある程度知る必要があります。次項に歴史年表をまとめているので、それを参考にしながら読むとわかりやすいと思います。
DEC は UNIX が誕生するよりも前からミニコンと呼ばれるコンピュータを発売していました。ミニコンはその名の通りミニコンピュータの略ですがミニと言ってもシステム全体で本棚ぐらいの大きさがありました。ミニコンがミニなコンピュータであるならば、ミニではないコンピュータもあります。それが 1960 年代から続くメインフレームです。メインフレームは大型で高価なコンピュータであったため、気軽に買えるようなものではありませんでした。そういった中で誕生したミニコンは安価、と言っても今のコンピュータに比べれば遥かに高いのですが、パソコンが普及するまでは会社のオフィスや大学の研究室などで広く使われていました。
DEC は PDP シリーズというミニコンを販売していました。トンプソンは古くて廃棄寸前になっていた PDP-7 を見つけ、PDP-7 用の OS として UNIX を開発します。メインメモリはわずか 8 KB しかありませんでした。最初の UNIX はアセンブラで書かれマルチプログラミングにも対応しておらず移植性もありませんでした。UNIX は後継機種の PDP-11/20 などで動作しましたが、当時はまだ様々なアーキテクチャのコンピュータが作られていた時代で、PDP も異なる機種で必ずしも互換性があったわけではなく、UNIX が対応している機種はそんなに多くはありませんでした。ちなみに PDP-11/20 のメインメモリは 24 KB、十分な移植性を実現した 1979 年の Version 7 Unix 時点の PDP-11/70 で 64 KB だったようです（参考）。ちなみに 16 ビットアーキテクチャです。
その後 DEC は PDP-11 の後継となる VAX アーキテクチャのコンピュータを開発します。VAX は 32 ビットアーキテクチャのコンピュータでした。その翌年 DEC は VAX/VMS（後に VMS と略され OpenVMS と名前が変更される）という独自の OS を開発します。OpenVMS は現在も開発が続いているクローズドソースの OS です。OpenVMS の Open はオープンソースという意味ではなくオープンシステムという意味です。VMS のことはよく知らないのですが、当時の時点で DECwindows という GUI を備えたタイムシェアリングシステムで十分に完成度が高い OS であったようです。つまり DEC は 1977 年の時点で独自のコンピュータと独自の OS を手に入れていたことになります。そのため DEC の創始者のケン・オルセンは PC と UNIX に興味を持っていなかったようです。この判断の誤りが後に DEC の業績を大きく悪化させることに繋がります。
それでも DEC 内に Unix のサポートに興味を持っていた人はいたようで、DEC に Unix を持ち込むきっかけとして Unix Engineering Group (UEG) が立ち上がります。ガンカーズは （立ち上がり時からなのかは不明ですが）UEG チームのメンバーです。1980 年に UEG チームは Version 7 Unix の修正版である V7M をリリースします。これが DEC が開発した最初の Unix です。ただし公式サポートではなかったようです（参考）。その後 1982 年に DEC で公式にサポートされた 4.2 BSD ベースの Ultrix が開発されます。Ultrix は PDP-11 対応の Ultrix-11 と VAX 対応の Ultrix-32 がありましたが、PDP-11 の終息とともに単に Ultrix と呼ばれるようになります。他の UNIX ベンダーと同様に Ultrix もクローズドソースでした。Ultrix は 4.2BSD ベースで開発が始まりましたが、バージョンアップとともに 4.3BSD の一部の機能や System V の機能を取り込んでいきました。
1990 年頃に PC の世界に 32 ビットシステムが登場し DEC のシェアは大きく奪われ始めます。そこで 1992 年には VAX アーキテクチャの後継として 64 ビットシステムである Alpha アーキテクチャを投入します。Ultrix は Alpha には移植されず、代わりに OSF/1（1995 年に Digital UNIX へと名前変更）に置き換えられます。OSF/1 はその頃に発生した UNIX 戦争で AT&T 連合に対して、DEC が所属していた Open Software Foundation (OSF) が開発した Unix です。知的財産権を侵害しないよう System V 系でも BSD 系でもない Unix（Mach マイクロカーネル）として開発されました。
一方で UNIX 戦争の裏でフリーソフトウェア文化が誕生します。UNIX 戦争で疲弊した UNIX 業界を横目に 1996 年に誕生した Linux は PC の性能向上とともに勢力を伸ばし続けます。一方 PC を軽んじていた DEC は業績を回復することは出来ず 1998 年に コンパックに買収されてしまいます。そして Digital UNIX は 1999 年に Tru64 UNIX に名前が変わります。 その後 Alpha 関連の知的財産権は 2001 年に Intel に売却され、2002 年にはヒューレット・パッカードがコンパックを吸収合併します。Tru64 UNIX は 2012 年にサポートが終了しました。
UNIX と UNIX 哲学に関する年表
| | UNIX | BSD | DEC | MS、Apple | UNIX 哲学 |
| :--: | ------------ | ---------- | ----------------- | -------------- | :--------: |
| 1964 | Multics 開始 | | PDP-7 (18bit) | | |
| : | | | | | |
| 1969 | UNIX 誕生 | | PDP-11/20 (16bit) | | |
| 1970 | | | | | |
| 1971 | Version 1 | | | | |
| 1972 | Version 2 | | | | |
| 1973 | Version 3/4 | | | | パイプ実装 |
| 1974 | Version 5 | | | | |
| 1975 | Version 6 | | PDP-11/70 (20bit) | | |
| 1976 | | | VAX (32bit) | | |
| 1977 | | 1BSD | VMS (Closed OS) | Apple II | |
| 1978 | | | | | マキルロイ |
| 1979 | Version 7 | 2BSD, 3BSD | | | |
| 1980 | Xenix | 4BSD | V7M (V7) | | |
| 1981 | | 4.1BSD | | IBM PC, DOS1.0 | |
| 1982 | System III | | Ultrix-11 (2BSD) | | |
| 1983 | SVR1, SunOS | 4.2BSD | | DOS2.0 | |
| 1984 | SVR2,HP-UX | | Ultrix-32(4.2BSD) | DOS3.0 | :`: |
| 1985 | | | | | : : |
| 1986 | AIX | 4.3BSD | | | : : |
| 1987 | SVR3 | | | | : : |
| 1988 | SVR4 | | (OSF 設立) | | : : |
| 1989 | | | | | : : |
| 1990 | | | | Win3.0, Mac | : : |
| 1991 | | | | | : : |
| 1992 | Solaris | 386BSD | Alpha 64bit,OSF/1 | Win3.1 | : : |
| 1993 | Novellに売却 | FreeBSD | | DOS6.0, NT3.1 | : : |
| 1994 | Linux 1.0 | | | | ガンカーズ |
| 1995 | | | Digital UNIX | Win95 | : : |
| 1996 | Linux 2.0 | | | | : : |
| 1997 | | | | | : : |
| 1998 | | | Compaqが買収 | | :.: |
| 1999 | | | Tru64 UNIX | | |
| 2000 | Debian 2.2 | | | Win2000 | |
| 2001 | | | | WinXP, OSX10 | 日本語訳版 |
| 2002 | | | | | |
| 2003 | | | | | レイモンド |
補足
- 1975: トンプソンはベル研を一時休職し、母校のカリフォルニア大学バークレー校に Version 6 Unix をインストールする作業を手伝う。これは後に BSD Unix として配布される。
- 1984-1998: ガンカーズが DEC でプリンシパル・ソフトウェア・エンジニアを務めた時期
- ガンカーズは DEC の Unix Engineering Group (UEG) に所属
- いつから DEC に勤めていたのかは不明
- P63 より「小さな会社で Version 7 Unix を使っていた」ので 1979 年よりも後
- V7M の開発には関わってなさそう
- おそらく 1980-1984 の間に DEC に入社したと思われる
- ガンカーズが「UNIX の考え方」についての本はないだろうか？と考えたのは 1991 年
- 1988: POSIX.1 標準化（POSIX.2 は 1992 年）
- 1989: FIPS 151-1 米国政府がコンピュータシステムの調達要件に POSIX 準拠を指定
- FIPS は 2000 年に廃止
- 1992: VAX/VMS は POSIX に準拠し OpenVMS と名前を変える
- 1992: OSF/1 を採用。Ultrix は出荷停止。
- OSF/1 は正確には DEC OSF/1 AXP。4.3 BSD-Reno ベースでMach カーネルを使用
- OSF/1 AXP → Digital UNIX → Tru64 UNIX と名前を変える
- 1994:「UNIX という考え方」の原書の出版
- Linux 初のディストリは 1996 年なのでまだ普及していない
- Windows 95 誕生前でインターネットも普及していない
- 2012: Tru64 UNIX サポート終了
「UNIXという考え方」という本について
日本未発売❗❓ 改訂第２版「Linux と UNIX 哲学」(2003)
「UNIX という考え方」が出版されたのは、原書が 1994 年、日本語版が 2001 年ですが、実は原書では 2003 年に改訂第２版 Linux and the Unix Philosophy が出版されています。なんということでしょう。我々、日本人は原書よりも 10 年も古い本で UNIX 哲学を学んでいるということです。どちらにしろ古いことには変わりませんが、2003 年にもなると Linux やインターネットやオープンソース文化が普及し Unix 界隈や Unix 界隈以外も大きく変わっています。この 10 年の変化は小さくはありません。
目次を見る限り内容のほとんどはそのままで新たな章が追加されただけのように見えますが、Amazon の紹介文には、全ての章が Linux をカバーするように更新されておりオープンソースに関する内容が増えていると書かれています。追加された章もそのタイトルから推測してもそれまでの「UNIX という考え方」の内容に影響を与えそうなものが増えており『「ガンカーズの UNIX 哲学」を語るのであれば』読んでおかなければいけないのではないかと思います。
しかし残念ながら私は原書改訂版は持っていません。英語だというのもありますが、日本語版が 1600 円に対して原書は 6000 円もするからです。日本語版が安すぎるだけのようですが、差分が追加されただけの改訂版でその値段はちょっと高いです......（Amazon で「試し読み」できるのでこっそりその部分だけ読んでいます）。そもそも私は「ガンカーズの UNIX 哲学」が UNIX 哲学の全てではないと思っていますのでガンカーズが何を言おうが実はたいして気にしていません。それどころか UNIX 哲学すらソフトウェア工学の一つとしか見ていません（GUI アプリやゲームなど明らかに適用困難な分野があります）。そんなわけで改訂版を買う気があまりないのです。この記事で色々書いていますが改訂版には当てはまらない内容が含まれているかもしれません。
追加内容（Lnux、Java、オブジェクト指向、ウェブサービス等）
さて目次と試し読みの内容から、改訂版で何が追加されているのかを簡単に見ていくとしましょう。
- 10: Through the Glass Darkly: Linux vs. Windows
- 10.1: It's the content, stupid!
この章ではタイトルどおり Linux と Windows の比較で、どうやらテキストベースとグラフィカルベースのユーザーインターフェースを比較しているようです。また Windows のどこが UNIX 哲学に従っており、どこが従ってないかを述べているようです。Windows であっても UNIX 哲学に従っている部分があるということなのでしょうね。
- 11: A Cathedral? How Bizarre!
この章ではオープンソースの概念が UNIX 哲学とどのように適合しているかが述べられているようです。タイトルの Cathedral は大聖堂または伽藍という意味です。オープンソースの開発モデルに関してのエッセイであるレイモンドの「伽藍とバザール」（無料で読めます）に関係する話ではないかと思われます。
- 12: Brave New (Unix) World
- Java
- Object-Oriented Programming
- Extreme Programming
- Refactoring
- The Apache Jakarta Project
- The Internet
- Wireless Communications
- Web Services
- Artificial Intelligence (AI)
この章では Unix 哲学が新しい技術分野でどのように採用されているのかを述べているようです。新しい技術分野で挙げられている項目は UNIX っぽくない物もありなかなか興味深いです。やはり古さを感じますが 2003 年当時はオブジェクト指向と言えば Java の時代でしたからこんなところでしょう。「オブジェクト指向プログラミング」「エクストリーム・プログラミング」「リファクタリング」ソフトウェア工学として重要な概念が普及し、「インターネット」「ウェブサービス」は誰もが使うものとなりました。それらに受け継がれる UNIX 哲学の考え方は、もはや Unix 開発者のものだけではないと言えるでしょう。
翻訳によって歪められた部分
ガンカーズの「定理」は誤訳❗❗正しくは「教義」だ❗
「UNIX という考え方」ではガンカーズが考えた主張を「定理」と呼んでいます。「【定理４】効率より移植性」みたいなやつです。「定理」とは数学的な定義では、公理や定義から導いて正しいという事が証明されているものを意味する言葉です。つまり、効率より移植性は必ず重視しなければいけないもの・・・？
もちろんそんな事はありません。状況によっては移植性よりも効率の方が重要な場合だってあります。これが定理だというのは少し考えれば明らかにおかしいとわかるはずですね。一体どういう理屈で定理であることが証明されたというのでしょうか？そもそも証明できるようなものなのでしょうか？
「定理」は英語で言うと「theorem」なのですが、さて原書では「定理」の部分はなんと書かれているでしょうか？実は「tenet」と書かれているのです。tenet とは「教義」「信条」「原則」を意味する言葉です。ガンカーズが言っていることは「そうであって欲しいと思ってる（でも実際に違うことがあるよ）」という程度のニュアンスだったのです。えぇ、そういうことです。「定理」は誤訳です。
原書で定理と書いていないものを定理と呼ぶのは誤解を招くだけでしかありません。この記事では「定理」でないことを明確にするために意図的に「教義」という用語に置き換えることにします。みなさんも真似してどうぞ。
ガンカーズの UNIX 哲学にはメインとなる教義の他に「さらなる 10 の UNIX の考え方」というものがあります。これは原書では「Ten Lesser Tenets」と書かれています。Lesser とは劣っているという意味です。LGPL の Lは昔は library の略でしたが GPL よりも劣っているという意味を込めて Lesser の略に改められました。
Lesser Tenets の日本語訳は劣等教義になると思いますが、ちょっとバランス（？）が悪いので「準教義」という用語を使うことにします。小教義だと小定理みたいで劣等というニュアンス「誰もが賛成しているわけではない」が消え失せてしまうので、準レギュラーみたいな意味を込めて準教義です。
ガンカーズはUNIX哲学の教祖に仕立て上げられた？
「UNIX という考え方」の P9 には「ガンカーズの 9 の"教義"」（項目）が書かれており、その下には
ここまでの項目は、UNIX の開発者たちにとって、その教義にも匹敵するものだ。他の UNIX に関する書籍にも取り上げられているだろうし、UNIX の基礎をなす考え方として広く受け入れられている。これらの定理を身に付けていれば、「UNIX 人」として認められるだろう。
と書かれています。ガンカーズが考えたくせに「教義にも匹敵するものだ」とは、教祖にでもなったつもりなのだろうか？と思いつつ、教義が「教義に匹敵するものだ」では文章がおかしくなってしまい、多分私が教義と訳したからおかしくなったのだろうと思い、Amazon の試し読みの範囲に含まれていたので読んでみました。
The preceding list contains tenets about which UNIX developers are dogmatic. You will find similar lists in other books on UNIX, as they are the points that everyone considers to be foundational concepts of UNIX. If you adopt them, you will be considered to be a "UNIX person."
翻訳 ここまでの項目には「UNIX 開発者は独断的である」ということについての教義が含まれています。あなたは似たような項目を他の UNIX に関する他の本で見つけるでしょう、それは誰もが UNIX の基本的なコンセプトだと考えているポイントだからです。もしあなたがこれらを採用すれば、あなたは「UNIX 人」であるとみなされるでしょう。
私の拙い翻訳ですがニュアンスが異なっているようです。本来の文章は UNIX 開発者がこのように独断的に（自説を譲らないと）考えているのだという内容を教義として示し、他の本にも似たような記述があるだろうと言っているだけです。広く受け入れられているなんて断定していません。ただ UNIX 開発者とはこういう人たちなんだという説明をしているだけです。ガンカーズは哲学を打ち立てたかったのではなく、ただ UNIX 開発者たちの考えを説明したかっただけなのです。
誰もが読むであろう最初にあるこの短い文章が、日本でガンカーズが教祖に仕立て上げることになった可能性があります。原書を確認した場所はごく僅かですが、もし他の部分もこのようにニュアンスが微妙に異なっているのであれば、この本の評価を大きく変えなければならなくなるかもしれません。私の訳（解釈）が間違っている可能性もありますし、英語と日本語がスラスラできる人の意見が欲しいですね。
さて、ガンカーズの考えた教義、他の本に似たような記述がありましたか？なければそれは基本的なコンセプトではないということですね。
ガンカーズの UNIX 哲学 (1994) の 9 の教義と 10 の準教義
ガンカーズが「UNIX という考え方」で提唱している教義です。基本的には従った方が良いと考えられるものの、絶対に従うべきというものではありません。
9 の教義
- 【教義１】スモール・イズ・ビューティフル
- 【教義２】一つのプログラムには一つのことをうまくやらせる
- 【教義３】できるだけ早く試作を作成する
- 【教義４】効率より移植性
- 【教義５】数値データはASCIIフラットファイルに保存する
- 【教義６】ソフトウェアの梃子を有効に活用する
- 【教義７】シェルスクリプトを使うことで梃子の効果と移植性を高める
- 【教義８】過度の対話的インターフェースを避ける
- 【教義９】すべてのプログラムをフィルタにする
補足 【教義５】は改訂版で「データをフラットテキストファイルに保存する」(Store data in flat text files) に変わっています。理由はよくわかりませんが、数値だけ、ASCII だけじゃなくなっていますね。数値だけじゃないのは日付データなどを考慮してでしょうか？ASCII じゃないのは Unicode が登場したからでしょうか？具体的すぎるものは時代の変化で古くなりやすいということの証拠だと思っています。
10 の準教義
- 【準教義１】好みに応じて自分で環境を調整できるようにする
- 【準教義２】オペレーティングシステムのカーネルを小さく軽くする
- 【準教義３】小文字を使い、短く
- 【準教義４】森林を守る
- 【準教義５】沈黙は金
- 【準教義６】並行して考える
- 【準教義７】部分の総和は全体よりも大きい
- 【準教義８】90 パーセントの解を目指す
- 【準教義９】劣るほうが優れている
- 【準教義10】階層的に考える
マキルロイの UNIX 哲学と比較してみれば、具体的すぎで蛇足的なものがたくさんあるというのがわかると思います。
著者のマイク・ガンカーズについて
作者紹介ページ（未翻訳）の全文翻訳
「UNIX のという考え方」には著者の情報が殆ど書かれていません。そのため著者が一体どういう人物なのかを本に書いてある内容から推測しなければならない状況です。なぜ著者の情報がないのか？実は日本語版には著者の紹介ページが抜け落ちていているからです。そのページというのは裏表紙です。原書では裏表紙に著者の情報が書かれており、日本語版を作る際にどうやらカバーデザインの変更で消えてしまったようです。
そこで裏表紙の内容を翻訳したいと思います。一ページまるまるの翻訳はやりすぎとも思わなくはないですが、元々誰でも見れる裏表紙は販促のための紹介ページでしょうし Amazon でもスキャンされて公開されています。他のページはすでに翻訳済みですし、著者のバックグラウンドを明らかにすることはこの本の内容を正しく理解するために重要な意味があり、引用するのに十分な合理的な理由があると考えています。なお裏表紙のスキャンは Amazon の The UNIX Philosophy から「試し読み」することができます。
Taken from the back cover of The UNIX Philosophy first edition. It is not included in the Japanese version.
THE UNIX PHILOSOPHY by Mike Gancarz
Unlike so many books that focus on how to use UNIX, The UNIX Philosophy concentrates on answering the question, "Why use UNIX in the first place?" The UNIX Philosophy is a book to be read before tackling the highly technical texts on UNIX internals and programming. In an informative, nontechnical fashion, this book explores general principles for developing UNIX-based software. It describes complex software design principles and addresses the importance of small programs, code and data portability, early prototyping, and open user interfaces.
UNIX の使い方に焦点を当てた多くの本とは異なり、The UNIX Philosophy は「なぜ、そもそも UNIX を使うのか？」という問いに答えることに集中しています。The UNIX Philosophy は、UNIX 内部やプログラミングに関する高度で技術的なテキストに取り組む 前に 読むべき本です。教育的かつ非技術的な流儀で、本書は UNIX ベースのソフトウェアを開発するための一般的な原則を探求しています。複雑なソフトウェアの設計原則を説明し、小さなプログラム、コードとデータの移植性、早めのプロトタイピング、オープンなユーザインタフェースの重要性を取り上げています。
Readers will discover:
- why paper is a death certificate for data;
- how to apply UNIX's small solutions to seemingly insurmountable problems;
- how to find the fastest route to the ideal design.
読者は見出すでしょう
- 紙がデータの死亡証明書である理由
- 一見、乗り越えられないように見える問題に UNIX の小さな解決法を適用する方法
- 理想的な設計への最短ルートを見つける方法
Written for both the computer layperson and the experienced programmer, THE UNIX Philosophy explores the tenets of the UNIX operating system in detail, dealing with powerful concepts in a comprehensible, straightfoward manner. This unique book brings toghter the history and applications of UNIX and thoroughly explains the rationale of the UNIX approach.
コンピュータの素人と経験豊富なプログラマーの両方に向けて書かれた、THE UNIX Philosophy は UNIX オペレーティングシステムの教義を詳しく解説し、強力なコンセプトをわかりやすく扱い、ストレートに表現しています。このユニークな本は UNIX の歴史と応用をまとめ、UNIX の考え方の根拠を徹底的に説き明かします。
Mike Gancarz has taught numerous industry seminars on the UNIX philosophy. As an engineer and a consultant, Mr. Gancarz has promoted UNIX for more than fourteen years.
マイク・ガンカーズは、UNIX の哲学に関する数多くの業界セミナーで教えてきました。エンジニアとして、コンサルタントとして、ガンカーズ氏は 14 年以上（訳注 1980 年頃から）にわたって UNIX の普及に努めてきました。
An expert in UNIX appliation design, Mr Gancarz was a member of the team that gave birth to the X Window System. He wrote the UWM Window Manager, a user interface that set the industry standard for customizable window manager design. His other work includes developing the conceptual design of COMET (a high-performance text-retrieval system written in the UNIX shell language) and leading a project to port the OSF commands and utilities to a 64-bit architecture.
UNIX アプリケーションデザインのエキスパートであるガンカーズ氏は、X Window System を誕生させたチームのメンバーでした。彼はカスタマイズ可能なウィンドウ・マネージャー設計の業界標準となった UWM ウィンドウ・マネージャーを開発しました。彼のその他の仕事には COMET（UNIX シェル言語で書かれた高性能テキスト検索システム）のコンセプトデザインの開発や OSF コマンドとユーティリティを 64 ビットアーキテクチャに移植するプロジェクトの主導が含まれています。
Mike Gancarz is a principal software engineer at Digital Equipment Corporation in Nashua, New Hompshire.
マイク・ガンカーズはニューハンプシャー州ナシュアにある Digital Equipment Corporation のプリンシパル・ソフトウェア・エンジニアです。
ガンカーズは DEC 社のソフトウェアエンジニア兼コンサルタント
裏表紙からいろいろなことがわかりました。まず DEC のソフトウェアエンジニアであることがはっきりしました。これらの多くは本の中には書かれていなかったことです。14 年間 UNIX の普及に努めていたという所から、出版年から逆算して 1980 年。1980 年は Version 7 Unix がリリースされた次の年で DEC が開発した初の UNIX である V7M がリリースされた年です。実は改訂版の About the Author（これも「試し読み」できます）は内容が更新されており Unix Engineering Group (UEG) で働いていたことが書かれています。UNIX の誕生は 1969 年なので 10 年遅れで UNIX の普及に努め始めた事になりますが、まあ外部の人間ですからこんな所でしょう。
ガンカーズが DEC でプリンシパル・ソフトウェア・エンジニアだった時期は Linkedin の情報からです。Linkedin にログインするだけで見ることができますが公開情報と言えるかは微妙なので、あまり書くのは良くないと思いますが、少なくとも 1984 年から 1998 年（つまり DEC がコンパックに買収されるまで）の間は DEC に在籍していたことがわかります。いろんな情報を統合すると UEG の成果である V7M が公開され、DEC が UNIX を扱っていることを知って 1980 年頃に DEC の UEG に加わったというのが可能性が高いかなと思っています。
ガンカーズは X Window System 開発メンバーの一人
ガンカーズは X Window System 開発メンバーの一人でした。ガンカーズが X Window System のどの部分に関わっているのかはわかりませんでしたが、少なくとも X Window System の初期の歴史的なウインドウマネージャ Ultrix Window Manager (uwm) の開発者です。「UNIX という考え方」の P106 にもこのことは書かれています。
X Window System の誕生は 1984 年、当時は MIT のプロジェクトでした。MIT の外部に初めてリリースされたのが 1986 年 2 月の X10R3 からで uwm が標準のウインドウマネージャでした。1989 年 12月の X11R4 で twm に置き換わるまでは、X Window System の唯一のウインドウマネージャだったようです。その後は大きなメンテナンスは行われていないようです。uwm は C 言語で書かれており、BSD ライセンスに似たライセンスです。
ちなみに P107 に「同僚のジョン=ホール」が登場しますが、おそらく Linux Professional Institute の理事長の Jon "maddog" Hall のことだと思われます。彼は改訂版の序文 (foreword) を書いており、その中で 1990 年頃に「UNIX プロフェッショナルの小さなグループ」で誰かが発した「なぜ UNIX が好きなのですか？」という質問に対するさまざまな意見、それをメモに取った人（ガンカーズのことでしょうが名前は書かれていません）がいて、それが「UNIX という考え方」になったと書いています。
ガンカーズはシェルスクリプト製の検索システムの開発者
ガンカーズの UNIX 哲学を読んでいると、少しシェルスクリプトにこだわり過ぎに感じる箇所がいくつかあります。例えば P9 の「シェルスクリプトは、ソフトウェアのテコを活かすと同時に移植性も高めるという二つの効果がある。可能なときは常に、C言語ではなくシェルスクリプトを使うべきだ。」というような極端な文章です。
別にシェルスクリプトじゃなくても他の言語でいいのでは？と思う所ですが、実は「UNIX という考え方」には C 言語とシェルスクリプトぐらいしか高水準言語が出てきません。当時 Unix で現実的に使えた言語はそれぐらいしかなかったからです（候補になりえるとしたら Perl4 ぐらい？）。消去法でシェルスクリプトが残ったと解釈するのが自然だと思いますが、ガンカーズは COMET と呼ばれる「UNIX シェル（Bourne シェル）製の高性能のテキスト検索システム」を開発していたので、もしかしたら好みの言語だったという理由があったのかもしれません。
初版では COMET はコンセプトデザインの開発となっていますが、改訂版ではそのシステムは開発したようで DEC 社の内部文書とソースコードの殆どにインデックスを付け即座に検索できるようにしたことで、同社のテクニカルサポートに革命を起こしたとのことです。実は COMET の開発につながるであろう話は「UNIX という考え方」の P83 に書かれており同じようにインデックスを作成することで Bourne シェルで作ったとは思えないような検索ツールを作ったそうです。「当時の職場の話」として書かれているので以前の職場での経験を元に COMET のコンセプトデザインを考えていたのではないでしょうか？
しかしそれにしてもシェルスクリプトで C 言語のプログラムを呼び出しているくせに「C プログラムがシェルスクリプトよりも速いというのは思い込み」とはよく書けたものです。シェルスクリプトから C のプログラムを呼び出しているから速いのであれば、それは C プログラムが速いという証拠でしかありません。もし使える C プログラムがなかったら、どうせそのプログラムは C 言語で書くのでしょう？この話の本質はシェルスクリプトを使うことが重要なのではなく、誰かが作ったコマンド（やライブラリ）を再利用して開発の手間を減らしましょうという P71 の「独自技術症候群を避けよ」の話のバリエーションでしかありません。ソートルーチンも書けないようなプログラマでも、他人の書いたソートルーチンを利用すれば勝者になれると書いていますが、シェルスクリプトに限らず誰かが作ったライブラリを再利用するのが普通です。ガンカーズは sort コマンドを使わない = 自分でソートルーチンを書くという極端な話をしています。
COMET はオープンソースではなく、社外に公開されたこともなさそうで、おそらく DEC がコンパックに買収された時ぐらいにそのシステムは破棄されたのではないかと思います。どれだけ移植性を重視していたとしても、ソフトウェアの価値を失った時にソフトウェアの寿命は来ます。P73 の「コードを他社がテコとして使うのを認める」を守らなかったのも世の中から消えてしまった原因の一つでしょう。オープンソースでないために移植されずに死んでしまったという残念な例です。オープンソースであったとしても uwm のように使われなくなれば移植されずに寿命を迎えます。であれば最初から作り直す前提でサクッと作ってしまうのもありなわけです。「マキルロイの UNIX 哲学」の「ソフトウェアは早く試せるように構築せよ、まずい部分は捨てて作り直すことを躊躇するな」ということです。移植性を軽視するのはよくありませんが、逆に移植性を重視しすぎるのもよくありません。要は「今、本当に必要なものは何か？」です。UNIX は最初は移植性がありませんでした。移植性が必要になった時に後から付け加えても良いわけです。もし最初から移植性を考慮していたら UNIX の開発は進まず Multics の二の舞になっていたことでしょう。
ガンカーズは UNIX コマンドの 64bit Alpha CPU への移植を担当
OSF コマンドというのが少し謎でしたが、改訂版では UNIX コマンドに修正されているので、商標が取られた UNIX の代わりに、これからの期待を込めて OSF という名前を使っただけだと思われます。ということでガンカーズは UNIX コマンドの 64bit Alpha CPU への移植も行っていました。
ガンカーズの C 言語に対する評価は以下のようなものです。P51 より。
UNIX 環境においての C 言語には、シェルスクリプトのような移植性はない。たいていの C 言語のプログラムは、ヘッダファイルの定義や、マシンアーキテクチャサイズ、その他の UNIX 実装の持つ移植不能なさまざまな特性に依存する。UNIX が 16 ビットアーキテクチャから 32 ビットアーキテクや、さらに 64 ビットアーキテクチャに移植されたときには、ものすごい数のソフトウェアが使えなくなった。C 言語の移植性が乏しいからだ。C 言語の移植性は、80 年代のアセンブリ言語と比べて、少しマシな程度に過ぎない。
もちろんこのような評価はほとんど過去のものです。DEC が開発した Alpha は新しい 64 ビットのCPU なので最大の効率を考えるとアセンブリ言語にも手を加えないといけなかったと思われます。それまでの CISC から RISC に変わっており Alpha アーキテクチャではアライメントされていない（32 ビットまたは 64 ビット単位で並べられていない）メモリにアクセスする場合に複雑な操作が必要（参考）で、コードが膨らみパフォーマンスが低下するという問題がありました。Autotools のようなものもありませんでしたし、UNIX が C 言語で書かれていると言っても、当時はようやく ANSI C (C89) が策定された時期なので、UNIX のソースコードは、まだ ANSI C 準拠ではなかったと思います。それに十分な C 言語用ライブラリもなかったことでしょう。それらを考えると Alpha CPU への対応というガンカーズの作業は大変なものとなり C 言語の移植性はそんなに高くないと考えるのも仕方のない話だと思います。
80 年代のアセンブリ言語というのは少し謎ですが、おそらく新しいアセンブリ言語という意味で使っているのだと思います。初期のアセンブリ言語は完全に機械語と一対一に結びついたニーモニックを使って書くため、特定のアーキテクチャに依存した移植性が低いものでした。しかし後期のアセンブラはマクロ機能を備え IF や WHILE といったアーキテクチャ非依存のマクロから機械語を生成することが出来ます。そのようなアセンブリ言語を High-level assembler というようです。そのためマクロを駆使すれば、機種依存の部分をかなり減らすことが出来ますし、構造化プログラミングも可能です。そういった高度に発展したアセンブリ言語と、まだまだ未発達の C 言語を比べれば、そりゃ C 言語の移植性はそんなに高くないという結論にもなるというものです。
このように当時の C 言語の移植性が低いから消去法でシェルスクリプトを使うべきだと言っているだけなので、現在では別にシェルスクリプトでなくても移植性の問題に悩まされない言語はいくらでもあります。むしろ UNIX 系 OS の間で UNIX コマンドに完全な互換性がないため、今ではシェルスクリプトの方が移植性は低いです。
ところでガンカーズが気にしている移植性は UNIX 間の移植ではなく異なるアーキテクチャのハードウェアへの移植性のことを言っていることに気がついたでしょうか？アーキテクチャがほぼ統一されてしまっている現在の PC の世界に当てはまらない話をしているのです。
ガンカーズの立場はコンピュータ会社の UNIX 開発者
さて、もうおわかりでしょう。ガンカーズの立場というのは、UNIX を搭載したコンピュータ会社、いわゆる UNIX ベンダーの社員で、独自 UNIX の開発者だということです。ここでいう UNIX とはカーネルだけのことではなく UNIX コマンドを含めてです。
ただ、根拠は薄いですがガンカーズは UNIX コマンドの移植などユーザーランド部分の担当で、カーネルプログラマではなかったのではないかと思います。というのは P77 に以下のように UNIX カーネルプログラマにシェルスクリプトを良さを理解されないと嘆いているからです。
この問題に入る前に、注意しておくことがある。UNIX カーネルプログラマの中には、シェルスクリプトプログラマを軽視する人が少なくない。シェルスクリプトを書くのは、「マッチョではない」というわけだ。「熟練シェルプログラマ」を「お手軽 UNIX 使い」とくさす向きもある。シェルスクリプトはあまり頭痛を起こさないので、嫉妬しているのではないかと私は想像している。あるいは、カーネルにはシェルスクリプトを使えないからだろうか。いつの日か誰かが、シェルスクリプトも使えるような UNIX カーネルを書いてくれないだろうか？そうすれば、ソフトウエア梃子の効果というものが、このような人たちにもより良く理解されるだろうに。
さて、ここには矛盾があります。「ガンカーズの UNIX 哲学」とは誰もが従っているものだったはずです。ガンカーズは「【教義７】シェルスクリプトを使うことで梃子の効果と移植性を高める」で「可能なときは常に C 言語ではなくシェルスクリプトを使うべきだ。」と主張していました。しかし「UNIX カーネルプログラマの中には、シェルスクリプトプログラマを軽視する人が少なくない」のであれば、この教義は誰もが従っているようなものではないということになります。教義７とは一体誰が言い出したことなのでしょうか？
話を戻しますが、それにしてもカーネルでシェルスクリプトを使うという発想は理解できません。ソフトウエア梃子の効果というなら別にシェルスクリプト以外でも効果はあります。C 言語から OS のシステムコールやライブラリを呼び出すだけです。元々メインフレーム時代ではシェル相当の機能はカーネルの一部でした。シェルをカーネルから追い出したのは UNIX の優れたポイントなのです。そうすることでシェルは普通のプログラムとなり、開発が容易になり、ユーザーは様々なシェルを使えるようになり、シェルスクリプトのエラーでカーネルが落ちるようなこともなく安定性もあがります。シェルをカーネルに入れるということは「【準教義２】オペレーティングシステムのカーネルを小さく軽くする」にも反するわけで、シェルスクリプトも使える UNIX カーネルなんて悪手です。そもそもそんなにシェルスクリプトが使える UNIX カーネルが欲しいなら、誰かが書いてくれないだろうかではなく自分で書けと。
C でプログラムを書くことが妥当なケースも多々ある。しかし、そのようなケースは一般に考えられているほど多くはない。（中略）シェルという代替もあるのだと気づいて欲しい。
UNIX は殆ど C でプログラムが書かれていることからも、UNIX の開発に限れば C で書くのが妥当でしょう？そのようなケースがほとんどです。もっとも今は Rust でカーネルを書こうという動き（RustをLinuxカーネル開発の第2言語に採用する試みに向け新パッチ）が出ており C 言語に固執するようなものではありません。他にいろいろな言語が使える可能性があります。当時の UNIX には C とシェルしかなかったのでしょうが「C とシェル以外の代替もあるのだと気づいて欲しい」ですね。
ということで、ガンカーズの UNIX カーネルに対する考えはカーネルプログラマっぽい発想ではないので、ガンカーズは UNIX 開発者ではあるもののカーネルの開発には関与しておらず、UNIX コマンドの移植などユーザーランド寄りの UNIX 開発者だったのだろうと推測しています。
初版が出版された時点では Linux はまだ登場していません
これはちゃんと書かれているので歪められたというわけではなく注意しましょうという程度の話ですが「UNIX という考え方」に時々出てくる Linux の話は訳者の脚注です。目次のページに▲が原著者による脚注、*が監訳者による脚注であると書かれています。書いてありますが読み飛ばしちゃいますよね……。
Linux の開発が初めて公になったのは 1991 年です。当時のガンカーズが Linux の存在を知っていた可能性はありますが、初期のディストリビューションの一つ Slackware のリリースは 1993 年です。商用利用の選択肢になったのは 1996 年の Linux 2.0 ぐらいからなので、ガンカーズだけでなく当時の人が Linux が Unix の後継として使われるようになるとはまだ思っていなかったでしょう。
日本語版の「UNIX という考え方」の出版は 2001 年です。翻訳者の芳尾桂さんは「今日からDebian GNU/Linux2.2」という本を書いているのもあって、枠外などにちらほら Linux についてのコメントがあったりします。そのため Linux が誕生した以降の話が含まれていると勘違いしてしまうかもしれませんが、本の物語の中の時代には Linux は登場していません。登場するのは改訂版の「Linux と UNIX 哲学」からです。
ガンカーズにとっての UNIX の歴史認識
まず最初に一言、UNIX の歴史などを知りたい人は「The Art of UNIX Programming」や「Unix考古学 Truth of the Legend」を読んでください。ガンカーズの UNIX の歴史認識は根拠がなく思い込みに近いです。
ガンカーズの UNIX 発明者の扱い
UNIX は誰が開発したのか？と聞かれたら UNIX の歴史を知っている人はケン・トンプソンとデニス・リッチーと答えるのではないでしょうか？
実際そのとおりで、UNIX は 1969 年に AT&T ベル研究所でトンプソンの手によって誕生しました。そしてトンプソンは最初の 2 つか 3 つのバージョンを一人で開発します。その後 C で書き直されることになりますが、リッチーは言語と I/O システムを、トンプソンは残りの全てを担当しています。
https://en.wikipedia.org/wiki/Ken_Thompson より
I did the first of two or three versions of UNIX all alone. And Dennis became an evangelist. Then there was a rewrite in a higher-level language that would come to be called C. He worked mostly on the language and on the I/O system, and I worked on all the rest of the operating system.
しかし、ガンカーズは P5 でこのように書いています。
UNIX の発明者は、AT&T のケン＝トンプソンとされている。ある意味で、それは正しい。
原書: Many people credit Ken Thompson of AT&T with inventing the UNIX operationg system and, in a sense, they're right.
なぜか「ある意味（in a sense)で正しい」ぐらいの扱いしかしていません。
トンプソンは、もともとアセンブリ言語で UNIX を書いた。1972 年に移植性のある B 言語を用いて書き直した。
とありますが、ここは間違いで UNIX が B 言語で書き直された事実はありません。B 言語は型が無く中間コードを実行するインタプリタ方式で遅かっためです。この話は「The Evolution of the Unix Time-sharing System」に詳しく書かれています。以下はその日本語訳「UNIX 原典」の「UNIX タイムシェアリング・システムの発展」の P24 からの引用です。
UNIX 自身をアセンブラではなく B で書こうという考えは一時的に出されただけであった。他のユーティリティについても同様で、結局アセンブラでさえもアセンブラで書き換えられたのである。こうなったのは、主に B の解釈コードが遅いということに原因があった。また些細ではあるが現実問題として重要だったのは、PDP-11 がバイト・アドレス方式のマシンであるのに対し、B がワード・オリエンテッドな言語だったことである。
B 言語は PDP-7 Unix で動作する言語としてトンプソンが開発したものですが、なぜかこの事実が書かれていません。ちなみに PDP-7 Unix 用のアセンブラもトンプソンが開発しています。この文章はすでに移植性がある B 言語が存在していてそれをトンプソンが使っただけのようにも見えてしまいます。
その後、1973 年に AT&T ベル研究所のデニス=リッチーが、B 言語に広汎な拡張を施した C 言語を作った。これが、現在世界中のプログラマによって愛され、また嫌われてもいる C 言語だ。
一方 C 言語に関してはリッチーが開発したとしっかり書かれています。ただし嫌われてもいるとかいう余計な一言がありますが。よく見れば Unix を C 言語で書き直した事も書かれていませんね。まあ常識過ぎて抜けてしまったのでしょう。Unix は 1973 年 2 月の Version 3 Unix でパイプが実装され、1973 年 10 月に開催された第 4 回 Symposium on Operating Systems Principles (SOSP) で AT&T 以外に広く公開され、1973 年 11 月の Version 4 Unix では C 言語で書き直されたものがリリースされます。
ともかくガンカーズは UNIX 発明者の功績を過小評価したいのではないかと疑ってしまいます。そのことは次の文章からも読み取れます。
UNIX の考え方全体の発展にケン=トンプソンが果たした役目はごく限られている。ファイルシステムの構造やパイプ、入力サブシステム移植性などに設計にトンプソンは多大な貢献をしたが、その他の多くはトンプソン以外の多くの人々に帰せられる。
トンプソン以外の人の貢献が多くあったのは疑うことのないところですが、最初の 2 つか 3 つのバージョンはトンプソン一人で開発しています。またパイプの発明もこの時期に含まれており起源となる UNIX 哲学はこの時に誕生しているわけで「UNIX の考え方全体の発展にケン=トンプソンが果たした役目はごく限られている」というのは、さすがに言い過ぎなのではないでしょうか？まるでガンカーズは UNIX 哲学がどこから生まれたのか知らないかのようです。
ガンカーズにとっての初期の UNIX はどこまでか？
P7 には以下のように書かれており「初期の UNIX」に貢献した人の名前から、ガンカーズが考えている初期の UNIX の範囲がわかります。
初期の UNIX に貢献した人々はそれぞれの得意分野で顕著な業績を残した。主だったものを列挙しよう。
この中にはカリフォルニア大学バークレー校のビル・ジョイが「C 言語に似たコマンド言語」、csh のことですね、の貢献者として名前が書かれています。他にもバークレー校に所属していた人の名前が何人かいます。このことからガンカーズの考える「初期の UNIX」は、BSD と csh が誕生した 1978 年が含まれることがわかります。csh は 2 BSD (1979) と共にリリースされました。1979 年には Version 7 Unix や 3BSD もリリースされてるので Research Unix として完成された Unix（Version 8 Unix 以降は非公開）まですべてを「初期の UNIX」として考えているようです。
どこまでを「初期の UNIX」として扱うかについては人ぞれぞれだと思うので、そこに関しては文句は言いません。UNIX がベル研究所の外部に広く公開されたのは Version 6 Unix からでガンカーズは AT&T の外部の人間ですから、UNIX の初期の歴史に疎くても仕方ありません。外部の一般プログラマにとっては、この頃がようやく世間に認知されてきた時期なわけで不自然な考え方でもありません。今はインターネットで当時のことを詳しく知っている人がまとめているから、こうして私は調べて知ることが出来るわけですが、当時をリアルタイムに生きてきた人にとっては詳しく知ることは難しかったでしょう。
私が気に入らないのは、なぜいちいちガンカーズが考えている「初期の UNIX」を推測しなければいけないのか？という所です。ガンカーズが一言「Version 7 Unix のことである」と書いていれば、推測する必要はなかったし、古文書の解読をしているかのような記事を書く必要もなかったわけです。何を引用しているかとか、本来書いて然るべきことを書いていないのが「UNIX という考え方」です。主張の根拠がわからず、根拠を書いてある箇所は古くなった技術に基づいている、それがこの本を「技術書として読まないこと」の理由の一つです。
さて話を戻すと「初期の UNIX に貢献した人々」の中には Perl のラリー・ウォールまで含まれています。ラリー・ウォールの貢献で有名なのは Perl (1987) ですが、例として書かれているソフトウェアの中で最も古いものは rn ニュースリーダーです。rn ニュースリーダーは 1984 年に開発されるのですが、その頃には DEC は自社の VAX 用の Unix である Ultrix (4.2BSD ベース)をリリースしているわけで、そこまで初期の UNIX に含めるには違和感があります。まあこれはおまけで加えちゃったということで見なかったことにしましょう。
従ってガンカーズによっての「初期の UNIX」とは 1979 年の Version 7 Unix までを含んでいることとなります。DEC は 1980 年に初の公式 UNIX である V7M (Version 7 Unix ベース)をリリースします。ガンカーズにとっての UNIX 哲学は 1973 年に生まれたものではなく、Version 6 以降に大学や世間に公開され、みんなでわちゃわちゃと開発していた時に生まれたもののように考えているのでしょう。
ビジネス界は UNIX の価値を認めなかったわけではない
ガンカーズはビジネス界は UNIX に価値を認めなかったと主張しています。P2 には以下のように書かれていますが、本当にそうなのでしょうか？
UNIX は、大学の研究室の閉じ込められ（略）
残念なことに、ビジネス界は UNIX に価値を認めなかった。UNIX はハッカーのおもちゃでしかなく、単なる好奇心の対象でしかなかった。研究室から生まれ、大学で育てられ、買った人間が自分でサポートしていたオペレーティングシステムに、リスクを犯してまで投資する企業はなかった。その結果として、UNIX は、その将来を嘱望されながらも 15 年もの長きに渡って不遇の時代を過ごすことになる。
しかし、1980 年代初頭に驚くべきことが起こった。どのオペレーティングシステムよりも柔軟で移植性に富み、性能の高いオペレーティングシステムがあるという噂が広まりだした。さらには、それは格安の費用で広く入手でき、ほとんどのマシンで動作するという。
UNIX がハッカーのおもちゃだというのはある意味正しいでしょう。元々 UNIX はプログラマーがプログラミングするための道具として作られたからです。しかしビジネス界が認めなかったかどうかは別の話です。
ここでヒントとなるのは、1980 年代初頭にほとんどのマシンで UNIX が動作すると書いてある所です。この「ほとんどマシン」に PC は含まれていません。PC で UNIX が動くようになるのは 1990 年代になってからです。 Xenix は PC にも移植されていたようです（コメント 参照。もう少し調べてからこのあたりの文章を修正する予定です）。具体的には 1992 年の 386BSD で初めて PC-UNIX として PC で UNIX が動くようになり、翌年 FreeBSD が誕生、1994 年に Linux 1.0 の誕生です。1980 年代の間、PC で UNIX は動きませんでした。その一方で MS-DOS は 1981 年に 1.0 がリリースされ 1980 年代の間 MS-DOS が PC の OS として天下を取ります。そして 1990 年代のはじめには Windows 3.x の時代となっています。
UNIX は、徐々にコンピュータ業界へと浸透していったが、会社の官僚組織はこの革命的な考え方を拒否していた。PC とメインフレームの秩序だった世界が好きだったのだ。苦労して覚えたいくつかの簡単なコマンドだけで日々の仕事ができ、それで「職の安定」が得られていると彼らは信じていた。そこでは UNIX は悪魔となった。UNIX は本質的な悪ではなかったが、現状を脅かしたゆえに敵視されたのだ。
この説明はメインフレームには当てはまるかもしれません。しかしものすごく高価なメインフレームを使っているような所が、なんのサポートもないような OS を使うでしょうか？ メインフレームの世界では OS はハードウェアの付属品でした。使ってるプログラミング言語は FORTRAN や COBOL です。1980 年代に入るまでは UNIX は DEC のコンピュータの特定の機種でしか動作せず、移植性はありません。価格が大きく違うから当然ですがメインフレームほどの性能はありません。1980 年代に入ると商用 UNIX の世界となり、それも変わっていきますが、今度は「格安の費用で広く入手でき」なくなってしまいます。PC で UNIX が動かない時代に UNIX が格安の費用で入手できて嬉しいのは DEC のようなコンピュータ開発会社ぐらいでしょう。自社で OS を開発するコストが減らせますからね。PC を買うような多くの人にとっては UNIX が格安で手に入ったとしても、それを動かすコンピュータが高いから手が出せないのです。
つまりビジネス界が認めなかったのは UNIX ではなくそれを動かすコンピュータです。高機能なデスクトップワークステーションとして UNIX は使われるようになっていきますが、「UNIX という考え方」が出版された 1994 年の 1 年前に、AT&T は Novell に UNIX の権利を売却しています。これは PC の性能が向上しワークステーション市場が縮小し始めたからです。この時点で見切りをつけた AT&T の対応は実に早かったと言えます。ガンカーズは世の中が PC の世界へと移行している中で「会社の官僚組織は PC の世界が好きだったのだ」と嘆いていたことになります。今だからこそ言える事ですが、未来を見通せていなかったのはどちらなのでしょうか？そして 1998 年に DEC はコンパックに買収されます。日経新聞の記事では DEC の失敗の本質は独自技術症候群（NIH 症候群）であったと見解を述べています。
これらのケン（ひいてはDEC）の失敗の本質は、いわゆる"Not Invented Here syndrome（NIH症候群）"と呼ばれる技術志向の強い会社に特有のものである。
つまり、自社（Here）の技術を過信するあまり、他社（Not Here）で生み出された（Invented）技術やアイデアや製品を、評価したがらない傾向のことである。
DEC の失敗はどちらかと言えばハードウェアの話です。また DEC の考えとガンカーズの考えが必ずしも一致していたとは限りません。実際 DEC の創業者であるケン・オルセンは UNIX を嫌っていたようなので、どちらかと言えばガンカーズの考えは DEC の中では少数派だった可能性が高いと思います。ガンカーズは独自技術症候群を避けることの重要を痛いほど述べているわけですが、UNIX の価値を認めなかったという批判は、UNIX の価値を認めなかったケン・オルセンへの批判にも等しく、独自技術症候群に陥り PC の価値を認めなかったという形で DEC のビジネスそのものと言えるのです。
知っての通り PC や Mac は今も健在です。しかも Mac は優れた GUI をメインで使う UNIX となり、Windows は WSL で Linux を取り込みました。Linux は UNIX の正統後継として多くの便利な機能を追加して UNIX を置き換えました。すべてが UNIX 哲学を内包しながら UNIX 哲学を超えるものを実現しました。今の世の中はビジネス界が UNIX の価値を認めた結果です。これは UNIX および UNIX 哲学はすべての OS の中の一部として生き続けるということを意味しています。消え去ることはありませんが、他の OS に取って代わることも無いでしょう。
ガンカーズはどこまでの UNIX の歴史の話をしてるのか？
「UNIX という考え方」が出版されたのが 1994 年なので、そこまでの UNIX の話をしているというのは当然なのですが、この時代の UNIX をガンカーズはどう捉えていたのでしょうか？ P3 の最後にはこのように書かれています。
私は、UNIX が世界標準のオペレーティングシステムになるのは時間の問題だと何年も前から言い続けてきた。それは、少なくとも間違ってはいなかった。しかし皮肉なことに、その標準オペレーティングシステムは「UNIX」と呼ばれることはなさそうだ。UNIXという名前の持つ価値に気づいた企業が、弁護士を使って大急ぎで、UNIX を商標として登録してしまったのだ。今後は、「オープンシステム」という名のもとに、インターフェースが設計され、標準が提案され、多くのアプリケーションが開発されることになるだろう。
DEC に UNIX を導入させた Unix Engineering Group (UEG) のメンバーなので、何年も前から言い続けていたのは不思議ではありません。さて UNIX と呼ばれることはなさそうだというのはどういうことでしょうか？「オープンシステム」という言葉から、これは UNIX 戦争の最後の時期の話でしょう。しかし「UNIX という名前の持つ価値に気づいた企業」とはどこなのでしょうか？少し自信がないのですが AT&T が商標登録をしたのは 1985 年です。その事を指しているのでしょうか？ただし米国は商標に使用主義を採用しているので使用している地域内では登録する必要はありません。米国全土でビジネスをする場合は登録が必要なようですが開発した AT&T が取得するのであれば正当な権利でしょう。ガンカーズの書き方は、自分たちが自由に使えたはずの UNIX を誰かが奪い去ったと言ってるように見えてしまいます。1993 年 6 月、AT&T は UNIX の権利のすべてを Novell に売却、Novell は 10 月に X/Open に UNIX の商標権を移管します（参考）。ちなみに原書の始めのページには、Novell が UNIX の商標権を持っていることが書かれています。（X/Open でないのは執筆が間に合わなかった？）
これがこの本の良くない所です。事実をぼかして書くから、何が言いたいのかさっぱりです。さらに私情を挟んでいるようにしか見えないので、それを隠すためにぼかしたのかなと思えてきます。もしかしたら出版された時点では常識レベルで共通認識があったのかもしれませんが、今読む人にとっては前提知識がなければよくわかりません。BSD Unix 寄りの人たちにとっては「元は AT&T の Unix が出発点だったとしても、BSD Unix は自分たち（大学・コミュニティ）の手で開発してきた Unix なんだ」という気持ちがあっただろうというのは想像できるのですが「UNIX という考え方」にはそれが書いておらず、おそらく BSD という文字すらありません。
UNIX 戦争は前半は、AT&T の System V 系と BSD 系の戦いとして 1980 年代の中頃に始まります。後半は AT&T や Sun が属する UNIX International（UI）連合と DEC が属する OSF 連合の二つの戦いとして 1988 年頃に始まります。1980 年代後半にはミニコンはワークステーションへと置き換わっていましたが、ワークステーションの主力マーケットであったデスクトップ市場は Windows と PC によって奪われていきます。それに対抗すべく AT&T は Novell と手を組みますが、最終的には UNIX の開発から撤退し Novell に UNIX の権利を売り UNIX 戦争は幕を閉じることになります。それが 1993 年頃です。それを受け UI 陣営と OSF 陣営は共同で「Common Open Software Environment（COSE）」という新しい標準を作る団体を設立し、翌 1994 年 3 月には UI が OSF に吸収されます。「UNIX という考え方」が出版されたのはこの後の 1994 年 12 月です。OSF としては UNIX の商標は使えないと思っていたのだと思います。だから今後は「オープンシステム」の名のもとに標準が提案されるだろうと言っているのでしょう。
その後は 1996 年に OSF と X/Open が合併し The Open Group という今も存在する標準化団体が設立されます。X/Open が合併したことで、The Open Group は UNIX の商標を手に入れ、Single UNIX Specification という UNIX の標準規格を策定しました。巡り巡ってオープンシステムではなく UNIX という名のもとに標準規格が作られることになったわけです。商用 UNIX のベンダーは（有料の）認証を得て UNIX を名乗るようになります。UNIX 戦争は元々の開発元である AT&T が UNIX の開発から撤退することで 商用 UNIX の世界として統一されました。しかしオープンソースの波と共に登場した Linux や PC-UNIX となった BSD の子孫たちは PC の性能向上と共に商用 UNIX を追い詰めています。
なお Single UNIX Specification はその後 2001 年に もう一つの標準規格である POSIX と内容が統合され、現在は The Open Group、ISO/IEC、IEEE の ３ つの標準化団体からなる AustinGroup によって POSIX は維持され続けています。
（2003 年から始まる SCO による UNIX に関する不当な権利主張は、さすがに省略して良いですよね）
UNIX 間の移植性問題が大きくなる前の時代の話をしている
「UNIX という考え方」を読んで気になる点の一つが「シェルスクリプトは移植性が高い」という前提になっている所です。これはガンカーズが各 UNIX 間での互換性が問題になる前の話をしているからだと考えられます。UNIX 間での互換性の話は POSIX 標準規格の話に繋がりますが「UNIX という考え方」には POSIX という名前すらでてきません。
よく読めばわかると思いますが「UNIX という考え方」で重要だと主張している「移植性」とは「異なるハードウェアに対する UNIX の移植性」の話です。DEC はさまざまなアーキテクチャのコンピュータを開発していたということを思い出してください。そういった自社のさまざまなコンピュータに UNIX を移植するという話をしているのです。当時はまだ PC のように基本のアーキテクチャが統一されている時代ではありません。新しいコンピュータを開発するのであれば、そのコンピュータに OS を移植しなければいけません。格安で使えて異なるコンピュータへの移植性が高い UNIX は、コンピュータ会社にとって OS の開発コストを減らすことができる都合の良い OS だったと言えます。
UNIX が AT&T のベル研究所で作られている間は UNIX 間での移植性の問題はありませんでした。UNIX の開発元が一つしか無いわけだから当然です。UNIX の移植性が問題になるのは UNIX がベル研究所の外に出て、BSD 系 UNIX が誕生し、UNIX に目をつけた DEC を含むいくつもの UNIX ベンダーがそれぞれ独自に UNIX に機能を追加してからです。なぜ UNIX ベンダーはそれぞれ独自の機能を追加したのか？それは自社の UNIX マシンを売るためです。UNIX マシンを売るためには他社よりも優れた機能を持っていなければなりません。ライバルコンピュータ会社のことより自社のコンピュータが売れることの方が重要です。そのためには機能を充実させて差別化し、悪く言えばみんなベンダーロックインを目指していたわけです。UNIX ベンダーによる UNIX の開発競争が UNIX 間の移植性を低下させました。
一方で、ソフトウェア開発会社にとってこの状況は嬉しくありません。各コンピュータ会社が "UNIX" を搭載したコンピュータを販売していながらそれらに互換性がないので、それぞれの UNIX 毎に移植作業が必要になってしまうからです。UNIX のライセンス販売ビジネスを始めた AT&T もこの問題は認識しており UNIX 間での互換性を実現するための標準規格を作りました。それが 1985 年の System V Interface Definition (SVID) です。その名の通り AT&T の System V の動作を説明した標準規格です。一方でベンダー中立の標準規格として作られたのが 1988 年の POSIX (POSIX.1-1988) です。シェルとコマンドに関しては少し遅れて 1992 年の POSIX.2-1992 で標準化されます。元々は BSD と SystemV と Xenix を統一する規格として作られました。後の Linux も POSIX 準拠を目指して開発が進められます。AT&T は後に UNIX 開発から手を引くので 1995 年の SVID Version 4 が最後のバージョンです。一方で POSIX は今も標準規格が維持されています。
しかし POSIX があるからと言って UNIX ベンダーはそれに対応する義理はありません。何かのメリットがなければ採用しないでしょう。そのメリットになったと思われるのが 1989 年の FIPS です。米国政府はコンピューターの購入要件に POSIX に準拠していることを要求しました。各 UNIX ベンダーがいつ頃から POSIX に準拠し、他社の UNIX と互換性を持たせようと考えたかは不明ですが、1980 年代の大部分の期間は UNIX 間の移植性に関して気にしてなかったと思われます。UNIX ベンダーが気にしていたのは自社のコンピューターの移植性なのです。
ここまで来れば、なぜガンカーズがシェルスクリプトが移植性が高いと言っていた理由がわかることでしょう。そうです、シェルスクリプトは実装に細かい違いがある他社の UNIX との移植性は低いのですが、自社の異なるコンピュータへ自社の UNIX を移植するという話に限れば高いのです。これを読み間違えるとおかしな結論になってしまうので十分気をつけてください。
道を外れた UNIX コマンドとは BSD 版と System V 版
序文（ページ iii）より
また、これとは別に UNIX に似たシステム ─ UNIX とうたってはいるが、その方法論からは離れていっているものたち ─ の発展の度合いを本書でチェックできるようにしたい。UNIX システム・ラボラトリーズのブライアン・カーニハンは、最近登場していた「お粗末な UNIX (crappy UNIXes)」に懸念を表明している。私もまた、UNIX を名乗るオペレーティングシステムであるからには、UNIX の基本的な考え方を見失ってほしくないと願っている一人だ。
「crappy UNIXes」を検索してもほとんど何も見つからなかったので、こう言ってるのはブライアン・カーニハンではなくて、ガンカーズなのだと思います。
さてこの「お粗末な UNIX」とはどの UNIX のことでしょうか？すでに答えは書いていますが BSD 版と System V 版、つまり事実上全ての UNIX です。Linux にも当てはまりますが Linux はこの時点ではまだ誕生していません。AT&T ベル研究所のカーニハンにとってお粗末でない UNIX とは Research Unix のみです。そこから大学で育った BSD は、お粗末な UNIX となり、System V 系 UNIX もそれにならいました。
カーニハンが表明した懸念というのは、おそらく 1984 年のブライアン・カーニハンとロブ・パイクによる論文 Program Design in the UNIX Environment （日本語版はUNIX 原典の「UNIX 環境におけるプログラム設計」)のことでしょう。この論文では cat -v と ls の複数列表示の例を挙げて、これらが UNIX 哲学に従っていないことを説明しています。このうち ls の複数列表示の話は「UNIX という考え方」でも紹介されています。相変わらず参照元が書かれていませんが、内容から言って「UNIX 環境におけるプログラム設計」を参照したのは間違いないでしょう。
ls の複数列表示というのはファイル・ディレクトリ一覧を出力した時に、出力先が端末の場合であれば複数列で出力される機能のことです。このような機能は ls コマンドの本質的な機能ではないのだから ls コマンドを大きくするのではなく、別のコマンドに分離すべきだという話です。この機能は 1977 年の 1BSD の時点で実装されていることがわかります。もちろん Research Unix の Version 7 Unix にはありません。
さてここで皮肉なのが DEC の Ultrix です。V7M は Version ７ Unix ベースなので複数列表示の機能はありません。しかし Ultrix は BSD ベースに変わったので見事に複数列表示の機能があるのです。ガンカーズが UNIX の基本的な考えを見失ってほしくないと言いながらも、結局自社の DEC はお粗末な UNIX を作っていたというわけです。もちろんベースとなる BSD が実装していたからなわけですが、UNIX 哲学に従うことよりも互換性を重視した（単に削除するのが面倒なだけかもしれませんが）ということです。ちなみに私はこれを正しい判断だと考えています。
余談ですが「UNIX という考え方」には「ls は端末の横幅を 80 桁だと仮定している」と書かれており、横幅が 132 桁だったりしたらどうするんだ？とまで書いています。知ってのとおり現在は端末の横幅または環境変数 COLUMNS に従って自動的に調整されますが、この機能が入ったのは 4.3BSD からです。4.3BSD は 1986 年にリリースされますが、DEC の Ultrix では 4.2BSD を使っていたので、ガンカーズはそのような機能を持った実装があることに気がついていないのでしょう。「UNIX 環境におけるプログラム設計」でも 80 桁であると書かれているのですが、この論文は 4.3BSD がリリースされる前なのでこっちは仕方ありません。
UNIX に関する細かい間違いが結構ある
ガンカーズは「UNIX という考え方」の冒頭で UNIX というのはどういうものかを説明していますが、細かい間違いや勘違いを引き起こしそうな説明不足が結構あります。それらを軽く見ていきましょう。
P1 より
UNIX の創造者たちは、ある極端なコンセプトから始めた。ユーザーは初めからコンピュータを使えるとみなしたのだ。UNIX は「ユーザーは、、自分が何をしているのかを分かっている」との前提に立っている。他のオペレーティングシステムの設計者が、初心者から専門家まで幅広いユーザーを受け入れようとして苦労しているとき、UNIX の設計者たちは「何をしているのか分からないなら、ここにいるべきではない」という不親切極まりないアプローチを選んだ。
おそらくですが「ユーザーは初めからコンピュータを使える」コンセプトから始まっていません。UNIX の創始者たちは、自分たちが使いやすいという OS を作っただけです。また、初心者を受け入れようとしない不親切極まりないアプローチを選んだのは、AT&T の独占禁止法でコンピュータ業界への参入が禁止されていたので「現物限り、サポートなし、バグ修正なし、前払い」というライセンスポリシーにせざるを得なかっただけです。積極的に初心者までをもサポートしたら、他の OS と競合するビジネスを始めようとしていると思われてしまうのは言うまでもありません。物は与えたから後は自分たちですべてやれと突き放すことしか出来なかっただけです。
P5 より
AT&T ベル研究所で最初の UNIX を書いた。それはスペース・トラベルというゲームプログラムの動作環境として、DEC のミニコンピュータ PDP-7 上で動作した。
まるでスペース・トラベルのために UNIX を書いたように読めますが、スペース・トラベルは元々 PDP-7 上で OS なしで直接動作する形で移植されました。そこから UNIX を開発するのに必要な PDP-7 のプログラミング方法を学んだのです。後に UNIX 上で動くように修正されたようですが、スペース・トラベルの動作環境として UNIX を開発したわけではありません。Space Travel: Exploring the solar system and the PDP-7 より「Later we fixed Space Travel so it would run under (PDP-7) Unix instead of standalone」
もともとスペース・トラベルはマサチューセッツ工科大学で開発されていた Multics システム用に作られていた。
この書き方だと誰かが Multics システム用に開発していたように思えますが、スペース・トラベルを開発したのはケン・トンプソン自身です。それを PDP-7 でのプログラミングを学ぶために書き直したのです。この開発経験から UNIX の開発が始まります。
トンプソンは、UNIX の初期バージョンに Multics から多くの特徴を取り入れた。そのうちで、最も重要なものがタイムシェアリングシステムだ。
どこまでを「UNIX の初期バージョン」と捉えているのか疑問ですが、初期の UNIX はマルチタスク用には設計されていません。アセンブラで書かれており移植性もありませんでした。タイムシェアリングシステムのアイデアは Multics の開発が始まった 1964 以前から存在しており 1961 年には CTSS という世界初のタイムシェアリングシステムや 1964 年には DTSS が誕生しています。Multics から取り入れた特徴とは言えません。
よいプログラマは素晴らしいソフトウェアを書く。偉大なプログラマは、そのプログラムを「盗む」。いや、トンプソンを泥棒呼ばわりしているのではない。そうではなく、彼は「独自技術症候群」を避け、すでにあるものにクリエイティブな付加価値を付けることにしたのだった。
と書かれていますが、また独自技術症候群とは、すでに使える技術があるならそれを使えという話であって、他の人のアイデアを実装する時に使う言葉ではありません。Multics のコードを使うことは出来ないので「すでにあるもの」ではありません。
そもそもケン・トンプソンは Multics 開発プロジェクトのメンバーの一人です。進まない Multics の開発に見切りをつけて（AT&T が）撤退したのですが、なぜかそういった事実も書かれていません。前提知識を持たないで読むとトンプソンが盗んだのだと勘違いしてしまいうでしょう。
さて、トンプソンやリッチーが盗んだプログラムとはどれのことなのでしょうか？UNIX を開発した偉大なプログラマは、多くの素晴らしいソフトウェアを自分の手で書いていますよね？ここは単純に「偉大なプログラマは素晴らしいソフトウェアを書く」で良いのではないでしょうか？
UNIX は追い詰められた人間が書いた？
ガンカーズは、UNIX は追い詰められた人間が書いたと主張しています。
トンプソンは、UNIX 開発者たちへの先例をもう一つ作った。偉大なプログラムは、追い詰められた人間が書く。あるアプリケーションを書かなければいけないとして、「それが実用的でなくてはならず」「どうやればできるか知っているエキスパートがまわりにおらず」、「それを『正しく』やる時間がない」とき、一片のすばらしいソフトウェアが書かれる可能性が非常に高くなる。トンプソンは、移植性のある言語で書かれたオペレーティングシステムが必要だった。自身のプログラムをほかのアーキテクチャに移行させなければならかなったのだ。移植性のあるオペレーティングシステムというもののエキスパートはいなかったし、もちろん彼には「正しく」やる時間などもなかった。
これはガンカーズの「人間による第三のシステム」の話に結びつけるための作り話だと思っています。予算がなかったとかコンピュータがなかったと言うのであればまだわかりますが、トンプソンが追い詰められていたとは思えません。Multics プロジェクトから撤退したので時間はあったはずです。UNIX の最初のバージョンは移植性がないのだから「移植性のある言語で書かれてオペレーティングシステムが必要だった」というのであれば辻褄が合いません。自身のプログラムを移行させねばならなかったと言いますが、それはスペース・トラベルというゲームです。しかも OS 上ではなくそのまま動く形で移植しました。一体どこに追い詰められた要素があるのでしょうか？
私だったら「偉大なプログラムは、それを欲しい人間が書く」と言うでしょう。タイムシェアリングシステムである Multics の対話的なインターフェースは、プログラミングする上でとても快適なインターフェースでした。トンプソンはそれを捨てたくなかった。自分が欲しいと思ったから UNIX を作ったのです。
Origins and History of Unix, 1969-1995 より
Dennis Ritchie, Doug McIlroy, and a few colleagues had become used to interactive computing under Multics and did not want to lose that capability.
翻訳 デニス・リッチー、ダグラス・マキルロイ とを数人の同僚たちは、Multicsの下でインタラクティブなコンピューティングに慣れており、その機能を失いたくないと思っていた。
Unix was built for me. I didn't build it as an operating system for other people, I built it to do games, and to do my stuff.
翻訳 Unixは 私のために作られました。私は他人のための OS として作ったのではなく、ゲームや自分のことをするために作ったのです。
偉大なプログラムというのは、自分が欲しいと思い、それが世の中になかった時に生まれるのです。Linux の誕生もそうでした。
ちなみにガンカーズの「人間による第三のシステム」の話は「人月の神話」に出てくる「セカンドシステム症候群」の焼き直しです。アレンジは入っていますが、二番目のシステムが肥大化し過剰なものになるという話は同じです。ちなみに P35 でガンカーズは以下のように書いています。
フレッド＝ブルックスは、その著書『人月の神話』において「開発プロジェクトがある程度進行した段階でプログラマを追加投入すると、完成は早まらずむしろ遅れる」と指摘している。UNIX 関係者には、以前から分かっていたことだ。
Fred Brooks, in his book The Mythical Man-Month, points out that adding more programmers to a development project too late in the effort makes it later, not earlier. UNIX people have known this for years.
（なぜ UNIX 関係者に限定して「分かっていたことだ」と書いてるのか謎ですが）このように、ガンカーズが人月の神話を参照していることは明らかです。それなのに「セカンドシステム症候群」の名前を出さないの何故なのか疑問です。
まあこの本としては珍しく「人月の神話」を参照していることが書かれているので、その点は良いと思います。と言う話で終わると思いましたか？面白い事実をお伝えしましょう。
改訂版では「人月の神話」を引用していることがなぜか削除されているのです。
P114 ではブルックスの法則（九人に妊婦がいても〜というやつ）がでてきますが、こちらも出典が書かれていません。
UNIX はタダだからコンピュータ会社は開発コスト削減できる
ガンカーズは、UNIX をコンピュータ会社が OS の開発コストを減らす便利な道具のように考えていたふしがあります。こんな便利なものただで配っててラッキー。みんなこの価値がわからないの？みたいな感じです。
P74 より
UNIX の成功は、開発者がソースコードを特に強くコントロールする必要を認めなかったという事実に多くを負っている。ほとんどの人はそんなものに大きな価値があるとは思っていなかった。UNIX は変なもので、研究所や大学には良くても、他に使い道がないものと考えられていた。UNIX を本格的なオペレーティングシステムだと考えるのは、開発者以外には誰もいなかった。結果的に、ソースコードはただ同然の金額で誰でも入手できた。
AT&T がソースコードをただで配っていたのは、米国の独占禁止法でコンピュータ業界への参入が認められていなかったからです。1973 年の SOSP で Unix の開発を社外に公表した時、社外から多数の配布要望を受けました。この時点で「使い道があるもの」と誰もが思っていたのです。ソースコードを公開したのは、独占禁止法によって AT&T が所有する特許情報は競合企業に対してであっても、内容も含めてすべて開示することを義務付けられていたからです。ただ同然の金額で入手できたのはコンピュータ関連事業への参入を企図していると疑われないようにするためで、大学に配布したのは営利的な利用の可能性が低いと考えられていたからです。この話については「Unix 考古学」の「第16章 AT&T とUnix ライセンス」に詳しくまとめられています。
こんな話はガンカーズも知っていたと思うのですが、書き方を見るに「でも大学に配ったよね？大学はその改造版を無料で配布してるよ。だからもう UNIX は誰でも無料で使えるものに変わったんだよ」みたいな、AT&T の権利が消失してしまったかのように考えている感じがします。もちろんそんなことはなくて 1980 年頃に始まった「UNIX 戦争」で AT&T は BSD Unix と権利争いを始めるわけですが、そのような話は全く書かれていません。
開発費用の高騰に苦しむハードウェア会社は、プラットフォームを売るために必要なソフトウェアへの投資を減らさざるをえない。ただ同然で手に入るオペレーティングシステムに目が向かないわけはない。結果的に UNIX の人気が高まった。新しいコンピュータのオペレーティングシステム開発費用を節約しようとする会社が UNIX に目を向けた。今日においても、現存するオペレーティングシステムの中で、UNIX が最も安価だと考える人は少なくない。
結局「ただで使える」ということが、ガンカーズにとって重要だったのだと思います。オープンソース的な考えではありません。当時はソースコードはクローズドなのが当たり前だったのでそれも普通の話なのですが、自分たちはただで使っておきながら作った Ultrix はクローズドなわけです。このような考え方で「コードを他社が梃子として使うのを認める」と言われても「UNIX 創始者たちはそう考えてるようだけど我々は違う。我々はただで使えるから使っているだけだ。」みたいな印象しかありません。
「UNIX という考え方」は UNIX 開発者の考えを伝えているだけ。自分たちがそれに従ってるというわけじゃないと考えれば矛盾はしませんが、重度の独自技術症候群だったのは DEC だったわけです。まあ元々 UNIX 哲学はオープンソース哲学ではないですし、UNIX 哲学を掲げながらソースコード非公開、ベンダーロックインを目指していても構わないわけです。現在そんなやり方が通用するかどうかは別の話ですが。
ガンカーズの「他の OS の考え方」の評価
ここでは「UNIX という考え方」の第 9 章（最終章）のガンカーズによる「UNIX と他のオペレーティングシステムの考え方」の説明を見ていきます。なお英語でのタイトルは「Unix and Other Operating System Philosophies」です。
Atari: なぜコンピュータと OS を比較しているのだろうか？
Atari のことはよく知らないのですが、なぜ OS の考え方の話でコンピュータと比較しているのか謎です。Atari にも OS（BIOS 相当？） はあったようですが、それについての話はありません。やはり OS よりも先にコンピュータ会社である DEC の考えが染み付いているのではないでしょうか？
Atari は個人的にはコンピュータとしても使えるけどほぼゲーム機みたいなイメージを持っています。MSX と同じですね。「UNIX という考え方」でも「彼の作るアプリケーションソフトウェア（つまりゲーム）は標準となり」という文章があるのでそんなに間違いではないでしょう。
Atari と UNIX の比較ですが、結論から言うとアプリケーションソフトウェア（ゲーム）と UNIX のプログラム（CLI コマンド）を比較するのは、どう考えても間違いです。これは作るものの違いと対象とするユーザーの違いでしかありません。「"ガンカーズの" UNIX 哲学」に従って、全てのプログラムをフィルタになんかしていたらゲームとして成り立たないでしょう。UNIX 哲学では不可能なことを実現しているコンピュータと比較して UNIX 哲学の話をしてしまえば、やっぱり UNIX 哲学はだめなんだという結論にしかなりません。
ここで参照されている De Re Atari: A Guide to Effective Programming」の付録 B（「APPENDIX B HUMAN ENGINEERING」）より
The ATARI Home Computer is first and foremost a consumer computer.
このように書かれている通り、Atari は消費者向けのコンピュータなのです。UNIX のようなプログラマのための OS ではありません。消費者とプログラマーの価値観の違いを Atari のクリス・クロフォードは正しく理解しています。哲学の違いを明らかにしたいのであればガンカーズはこの部分を引用すべきでした。
This thesis clashes with the values of many programmers. Programmers crave complete freedom to exercise power over the computer. Their most common complaint against a program is that it somehow restricts their options.
（略）
The answer lies in the difference between the consumer and the programmer. The programmer devotes his life to the computer; the consumer is a casual acquaintance at best. The programmer uses the computer so heavily that it is cost-effective to take the time to learn to use a more powerful tool. The consumer does not have the time to lavish on the machine. He wants to get to point B as quickly as possible. He does not care for the fine points that occupy a programmer's life. Bells and whistles cherished by programmers are only trivia to him. You as a programmer may not share the consumer's values, but if you want to maintain your livelihood you had better cater to them.
翻訳 この論文は多くのプログラマーの価値観と衝突します。 プログラマーはコンピュータに対して完全に自由に力を行使することを望んでいます。彼らのプログラムに対する最も一般的な不満は、それがどういうわけか彼らの選択肢を制限していることです。
（略）
答えは、消費者とプログラマーの違いにあります。プログラマーは自分の人生をコンピューターに捧げます。消費者とはせいぜい顔見知り程度の関係です。プログラマーはコンピュータを多用するので強力なツールの使い方を習得するのに時間をかけるのは費用対効果が高いのです。消費者は機械を惜しみなく使う時間がありません。彼はできるだけ早くポイント B に到達したいのです。彼はプログラマーの人生を占める細かい点を気にしません。プログラマーが大事にしている鐘や笛は、彼にとっては単なる雑学です。
結局の所 UNIX 哲学というのは、コンピュータの使い方の一部、プログラマーのための哲学でしかありません。消費者がコンピュータを使う時に、UNIX 哲学を持ち出してもだめだということです。ゲームはその最もわかり易い例でしょう。非技術者がコンピュータを使う場合 awk ではなくエクセルというグラフィカルでわかりやすいインターフェースが必要なのです。ガンカーズも次のようなことを言えればかっこ良かったんですけどね。（フラグ１）
「Atari と UNIX のどちらが優れているだろうと考える人がいるが、これはその問い自体が間違っている。一方が他方より優れているという問題ではなく、両者は異なるアプローチを採用しているというのが事実だ。ある状況には Atari の考え方がよく適合し、別の状況には UNIX の考え方が正しい選択肢となる。すべては、コンピュータの前に誰が座っているか、つまりそれを使うのが誰であるかによって決まる。」
MS-DOS: 7000 万以上のユーザーは正しかった
MS-DOS が売れたのは「安い PC で十分に使える」以外に何があるのでしょうか？PC を嫌っていた DEC の社員という立場からか、ガンカーズは MS-DOS に対して、群集心理だ、IBM の力だ、メインフレームみたいだ、そんなのパソコンじゃないみたいな事を言っていますが、結局の所 MS-DOS が普及したのは、個人向けに（当時の基準で）安くて性能が低いパソコンで十分にアプリケーションが使えたというだけでしかありません。コンピュータのユーザーが使いたいのはアプリケーションであって OS ではないのですから。
結果論ではありますが MS-DOS は成功し、DEC は PC への参入が遅れ失敗への道をたどることになりました。「7000 万以上のユーザーが間違っているはずがない」はその通りでした。まあそれはコンピュータとして失敗したわけなので OS としての話ではありません。しかし MS-DOS に関して、批判するほどの知識がガンカーズにはないように思えます。
まず MS-DOS のシェルとコマンドですが、これは Digital Research 社の CP/M を参考にして作られています。そして CP/M は DEC の古い OS、TOPS-10 や RSX-11 を参考にして作られています。MS-DOS のルーツを辿ると DEC の OS に行き着くわけですがメインフレームみたいとか言って都合が悪くなったりしませんか？（フラグ２）
MS-DOS 環境の最も意外な側面は、UNIX の考え方をいくつも取り入れていることだろう。例えば、UNIX のパイプメカニズムによく似たパイプ機能があるし、階層を持つディレクトリ構造もある。さらに、MORE コマンドがあり、これはバークレー版 UNIX にある more コマンドと同様に機能する。おそらく MS-DOS の初期設計には、UNIX をよく知る人間が参加していたのだろう。
とありますが、そもそもマイクロソフトは、1980 年に AT&T から正式なライセンスを取得した Xenix という世界初の商用 UNIX をリリースしています。DEC が V7M をリリースしたのと同じ頃ですが、おそらく Xenix の方が行動は早かったと思われます。マイクロソフトは自社で UNIX を作っていたのだから UNIX をよく知る人間がいて当たり前です。Xenix の方が MS-DOS よりも先にリリースされており、MS-DOS 1.0 は翌年の 1981 年、パイプやディレクトリ構造が取り入れられた MS-DOS 2.0 は 1983 年です。ビジネス戦略上 1984 年に SCO に Xenix の権利を売り渡しますが、DEC より早い段階で UNIX に目をつけて早く撤退したということです。しかしそれにしても UNIX に興味がある人が Xenix を知らないとは思えないんですけどね。
しかし、MS-DOS のパイプと UNIX のパイプとは完全に同じではない。MS-DOS のマルチタスクは真のマルチタスクではなく、コマンドラインに同コマンドを入力しても、一度に一つのコマンドしか実行されない。
真のマルチタスクどころか MS-DOS は最初からシングルタスク OS です。パイプラインの各コマンドがマルチタスクで動作しないのは当たり前で、それは当時の PC の性能が低かったからです。ミニコンのような高価なコンピュータと比べるのはフェアではありません。タイムシェアリングシステムというのは元々高価なコンピュータを複数人で使うためのもので、一人がコンピュータを専有することがコスト的に不可能だったからです。しかし PC はその名の通り個人で使用するパソコンですから、タイムシェアリングシステムは必要ないしマルチタスクも必須ではありません。コンピュータの違いによって優先順位が異なり、PC では個人がパソコンを所有できるようにと価格の安さを優先させたのです。
もう一つ、個人的に「真のマルチタスク」という言い方が引っかかりました。この言い方は Windows 3.1 までのノンプリエンプティブマルチタスクの対比として使われていた言葉だと思います。Windows 3.1 のアプリはノンプリエンプティブマルチタスクでしたが、Windows 3.1 上の DOS プロンプト同士はプリエンプティブマルチタスクとして動作するので、この頃の Windows のマルチタスクの話は少しややこしい事情があります。そのためガンカーズは MS-DOS がシングルタスク OS だと知らなかったのではないだろうか？と思っています。知っていたら「MS-DOS はシングルタスク OS なので、一度に一つのコマンドしか実行されない」とシンプルに書くと思うんですよね。
MS-DOS 6.0 の「CONFIG.SYS ファイルと AUTOEXEC.BAT ファイルの複数構成機能」というのはマルチコンフィグと呼ばれる機能のようです。「UNIX は以前から複数構成をサポートしている。ユーザーごとに .profile ファイルを設け、各人の好みに合わせてそれをカスタマイズできるのだ。」と書かれていますが、シングルユーザー OS である MS-DOS のマルチコンフィグ機能は、.profile とは全く違います。今で言う GRUB のブートメニューのようなものです。
話の最後では Windows NT への言及があります。当時 Windows NT は様々なプラットフォームへの対応を表明しており、その中には DEC の Alpha も含まれます。Windows がそういう移植性を打ち出してきたことへの泣き言が書かれています。まあ Alpha の将来性がなくなったため Windows 2000 以降は対応を取りやめるわけですが。それでも Windows は移植性（もちろん異なるアーキテクチャへの移植性です）を考えて作られています。Windows 11 は x64 だけではなく ARM64 にも対応しています。
OpenVMS: DEC 社の主力 OS の評価は甘々
Atari や MS-DOS の場合と違って OpenVMS に対しての評価は甘い方向に偏っています。まあ自分が勤務する DEC の OS を悪く言うことは出来ないでしょう。改めて読むと文章が巧妙でガンカーズが DEC に務めていると気づかないような書き方になってるように見えます。原書では裏表紙に書いてあるのだから隠す意味はないはずなのですが。
UNIX が世に注目されるまで、ミニコンピュータの世界でこれほど忠実な支持者を集めたオペレーティングシステムはない。
システム構築に対する DEC のアプローチは、業界で羨望の的だった。同社が OpenVMS と VAX シリーズで行ったことは、コンピュータ業界では他に例がない。
IBM やヒューレット・パッカード社も、各種製品シリーズを一つのアーキテクチャに統一しようと試みて惨めに失敗した。（注意 DEC はコンパックに買収され、ヒューレット・パッカードがコンパックを吸収合併します）
同社の他のオペレーティングシステムとの類似点は多い。例えば RSX-11（DEC の初期のオペレーティングシステム）のユーザーにも OpenVMS のコマンドインタープリタはほとんど違和感がない。
恥ずかしいぐらいに自画自賛ですね。最後のコマンドインタプリタの話は、MS-DOS のコマンドインタープリタも元をたどると RSX-11 に行き着くので、MS-DOS ユーザーにとっても OpenVMS のコマンドインタプリタとほとんど違和感なくなるはずなのですが。（フラグ２回収）
ガンカーズは他にも OpenVMS についていろいろ書いており、OpenVMS の哲学と UNIX の哲学は正反対なわけですが、
OpenVMS と UNIX のどちらが優れているだろうと考える人がいるが、これはその問い自体が間違っている。一方が他方より優れているという問題ではなく、両者は異なるアプローチを採用しているというのが事実だ。ある状況には OpenVMS の考え方がよく適合し、別の状況には UNIX の考え方が正しい選択肢となる。すべては、運転席に誰が座っているか、つまりそれを使うのが誰であるかによって決まる。
はい、フラグ１回収です。OpenVMS の場合は「両者は異なるアプローチを採用しているというのが事実だ。」と擁護しています。同じことを Atari や MS-DOS に対しては言わなかったのは何故なのでしょうか？これは UNIX 以外も含めて全ての OS に当てはまります。UNIX はある状況には正しい選択肢ですが、別の状況の場合であれば Windows や macOS が正しい選択肢となることもあるのです。そのとおりですよ。すべては運転手（ユーザー）が誰であるかによって決まるのです。結局の所「UNIX という考え方」は UNIX の考えを説明しているだけで、UNIX の考え方がコンピュータの使い方の全てではないと言って終わっているのです。
ガンカーズは DEC と UNIX との板挟み状態だった？
「UNIX という考え方」を読んでいて思うのは、なんでこんな不明瞭な書き方をするんだろうということです。未来を見通すことは誰にも出来ませんから、古くなってしまう内容はどうしようもありません。しかしその時わかっていることを書くことはできるはずです。何を参考にしたとか、何の情報だとか、具体的な UNIX のバージョンとかです。
「UNIX という考え方」に全て賛同するわけではないものの、私も最初は一つの考え方として普通に読んでいました、しかし UNIX の歴史や UNIX 哲学を学ぶうちに、だんだんおかしなポイントが見えてきて、DEC との繋がりに気がついて本腰を入れて調べた結果がこれです。改めて見ると不明瞭で誤解を招きそうな書き方が多いし、明らかに他の文献を引用しているであろう部分にその事が書かれていないし、挙句の果てには改訂版で「人月の神話」を参照したということを消すなんてこともしています。
この記事では触れませんでしたが「【準教義９】劣るほうが優れている」は 1989 年 Richard P. Gabriel による Worse is better の引用でしょう。もちろん引用したとは「UNIX という考え方」には書かれていません。ちなみに本家の Worse is better ではニュージャージースタイル（悪いデザイン）と MIT スタイル（良いデザイン）を比較していて、AT&T ベル研究所があった場所がニュージャージーです。MIT は X Window System を開発していた所でガンカーズは X Window System を開発していたメンバーで Ultrix Window Manager を開発していた割に P20 では X11 に文句を言ってるんですよね。ここは少し不思議です。
好意的に考えるならば、もしかしたらガンカーズは DEC と UNIX の板挟み状態だったのではないかと思っています。ガンカーズ自身は UNIX に惚れ込んでいましたが、それは DEC の自社 OS である OpenVMS を普及させるという方針とは一致していません。OpenVMS のことを悪く書くことは出来ないでしょう。だから具体的に書きたくても書けなかったのではないのかと。でもそれだと DEC 以外のことまで不明瞭な書き方をしてる理由にはなりませんが。
また一時期は DEC と AT&T は仲が悪かったと聞きます。以下は「UNIX 考古学」の P127 からの引用です。
当時のDEC のエンジニアは、自社製品を無視して独自の OS を開発する Unix グループの面々を快く思っていなかったようです。一方、Unix グループの面々も、教育関係を中心に多くのユーザーを獲得している Unix を完全に無視する DEC のエンジニアを快く思っていなかったようです。ゆえに、彼らは日常的に顔を合わせるコンピュータ関連の学会などでバトルを繰り返していたと推測されます。気の毒なのは、両者の板挟みになっていたDEC のセールスマンでしょう。せっかく新製品に関してスペシャルなオファーをしたにもかかわらず、Unix グループの面々からは拒絶されたようです。けっきょく、彼らはBTL の他のグループを口説き落とし、VAX–11/780 へのUnix の移植の約束を取り付けました。
Ultrix は 4.2BSD ベースですし、AT&T 陣営とは反対の OSF 陣営ですし、UNIX を無料で使える OS として扱いたいようですし、ガンカーズが BSD 寄りの考え方であったことは間違いないでしょう。そういった中でガンカーズは AT&T の功績を素直に認めることが出来なかったのではないでしょうか？その結果 AT&T のことはあまり表に出さずに、UNIX の哲学を書きたかったとすれば、このような内容になるのもわからなくはないです。しかし「UNIX という考え方」が出版されてから 30 年。世代は交代しており世の中も大きく変わっています。読む方は大変です。
さいごに
いかがだったでしょうか？元々この記事は「ガンカーズの UNIX 哲学」の UNIX 哲学の理論的根拠を鵜呑みにすることがないように、現代において今も適用できる部分、古くなってしまい適用できない部分を技術的な観点から解説する予定でした。その過程でガンカーズの事を調べているうちに「UNIX という考え方」は、単に古くなっているだけではなく彼の立場から来ていた発言が極めて多いことに気が付きました。
「UNIX という考え方」で一番注意が必要なのは移植性に関する考え方の違いでしょう。1987 年頃に日本ファルコムというゲーム会社が開発したイースというゲームがあります。ファミコンなどの家庭用ゲーム機にも移植されていますが、オリジナル版は PC-88 というパソコン用です。その他 X1、PC98、FM7/77、FM77AV、MSX2、Apple IIGS、PC/AT、X68K というパソコンに移植されました。これが当時の移植性の考え方です。OS がないか最低限の機能しか持たない DOS の時代、昔はコンピュータに対してソフトウェアを開発していました。多くのハードウェアに対応することがソフトウェアの売上を伸ばす上で重要なことでした。
そのようなコンピュータの違いは今は OS が吸収しており、Windows、Linux、macOS といった OS に対してソフトウェアを開発するという形に変わっています（もちろん家庭用ゲーム機など例外はあります）。ハードウェアの違いを OS が吸収している限り、普通に作るだけで移植性があるソフトウェアを作れるというのが今の世の中です。正しくプログラムを書けば、高性能なハードウェアの特殊機能を使用しながら高い移植性を持ったソフトウェアを開発することだって出来ます。Apple M1 のようにプラットフォームが変わった場合でも、その違いに対応するのは開発ツールの仕事となっておりソフトウェアの開発者はビルドオプションを指定するだけです。互換性も OS によって実現されているため、例えば 20 年以上前に何も考えずに作った Windows アプリが今でも平気で動いたりします。すべて OS がやってくれているのです。
現在のソフトウェア開発者を悩ませているのは Windows や macOS など完全に異なる OS をまたがった移植性ですが、その場合でもクロスプラットフォームの言語やライブラリを使うことで、比較的簡単に移植性も互換性も実現できます。偉大なプログラマは良いコードを盗むというのはまさにこのことです。オープンソース文化のおかげで今ではコード（ライブラリ）を自由に使うことが出来るようになりました。また本文中では説明しませんでしたが、パッケージ管理システムの誕生も移植性に関して重要な意味を果たしており、昔のプログラムは利用者自らがソースコードからビルドするものでしたが（シェルスクリプトはコピーするだけで済むので、これがガンカーズがシェルスクリプトの方が移植性が高いと主張していたもう一つの理由です）、今はビルド済みのパッケージをインストールするだけなので、シェルスクリプトでなくても多くの環境で簡単に同じプログラムを使うことが出来るようになっています。現在はパッケージを活用することが「ガンカーズの UNIX 哲学」の一つ「【教義６】ソフトウェアの梃子を有効に活用する」を意味しています。
UNIX もハードウェアの違いを吸収しており、ソースコードレベルとはいえ POSIX のおかげで一定の移植性が保たれているので UNIX という OS に対してソフトウェアを書けば、理想的にはどの UNIX でもソフトウェアが動きます。UNIX でも異なるハードウェアとの移植性は昔ほど気にする必要はないという点では同じなのですが「UNIX という考え方」では気にしなくて良いはずの異なるハードウェアとの移植性の話をしています。ガンカーズはあるソフトウェアが他社の UNIX で動くことではなく、自社の UNIX を新しいハードウェアに対応させるときの移植性の話をしているのです。なぜこのような違いがあるのかと言うとガンカーズの立場の違いが原因です。ハードウェアの違いや移植性や互換性は OS が解決するものですが、私達は OS を使う側なのに対して、ガンカーズは OS を作る側にいるので自分たちの手でハードウェアの違いや移植性や互換性を解決しなければいけないわけです。この記事でガンカーズが一体何者なのか？を詳しく解説した理由はこれです。彼は立場の違いから私達とは違うものを見ています。しかしその立場が明確になってないから「UNIX という考え方」を正しく理解するのが困難になっています。だから先にガンカーズの立場を説明する必要があったのです。
違う立場から説明しているのだとしたら、この本は役に立たないじゃないかと思うかもしれませんが、そうではありません。この本は「UNIX 開発者が考えていること」を非技術者に説明するものだからです。UNIX 開発者が考えてることが分かっても UNIX 哲学が実践できるようになるわけではないことに注意してください。例えば「【教義９】すべてのプログラムをフィルタにする」と言われてもプログラムが作れない人にそれを実践することは出来ませんし「UNIX という考え方」には作り方は書かれていません。UNIX 開発者が考えている UNIX 哲学というものを理解できるというのがこの本の趣旨です。もし自分で UNIX 哲学を実践したいのであれば、次にエリック・レイモンドの「The Art of UNIX Programming」などのプログラマ向けの UNIX 哲学本を読むことをおすすめします。ガンカーズも裏表紙で言っています。「The UNIX Philosophy は、UNIX 内部やプログラミングに関する高度で技術的なテキストに取り組む 前に 読むべき本です。」次は技術的な本です。（非技術者なら「人月の神話」がオススメです）
最後に勘違いされないように書いておくと、私は UNIX 哲学を否定しているわけではありません。むしろ肯定しており従っています。ただし UNIX 哲学がソフトウェア工学の全てだとは思っていません。UNIX 哲学が及ばない領域もあります。UNIX 哲学はあくまで UNIX の哲学というだけで、コンピュータ利用者の全ての人にとっての哲学ではありません。ガンカーズの UNIX 哲学でさえも、注意すべきものがあるとは思っていますが、全てが悪いとは思っていません。絶対に守らなければいけないルールと勘違いしてない限りガイドラインとしては良いでしょう。現状に合わない古くなった部分を修正すれば良い形に改善できるでしょう。そういった細かい話を後編でしたいと考えています。そして最終的にこの話は UNIX 哲学を実践する上で、現状何が足りないのか？何を作るべきなのか？という話につながります。皮肉な事に異なるハードウェアとの移植性が高かったシェルスクリプトは、異なる UNIX 系 OS との間での移植性では低いという問題があります。各 UNIX または UNIX 系 OS のベンダーがシェルスクリプトや UNIX コマンドの移植性を向上させようとしないからです。これではソフトウェアツールとして使いづらいと言わざるを得ません。この記事は古典となった古い UNIX 哲学本を読んで分かった気になって終わるのではなく、UNIX 哲学の本質を理解し、その核であるソフトウェアツールを改善し、プログラマの道具として新しい姿へと作り変えるために書いています。