Unixの哲学

1984年に出版された書籍『The UNIX Programming Environment』の序文で、ベル研究所のブライアン・カーニハンとロブ・パイクは、Unixの設計と哲学について簡単に説明しています。^{[ 5 ]}

UNIXシステムは数々の革新的なプログラムや技術を導入していますが、単一のプログラムやアイデアだけでその性能が決まるわけではありません。むしろ、その有効性を支えているのは、プログラミングへのアプローチ、つまりコンピュータの使い方に関する哲学です。その哲学をたった一文で言い表すことはできませんが、その核心は、システムの力は個々のプログラムそのものよりも、プログラム間の関係性から生まれるという考え方にあります。多くのUNIXプログラムは単独ではごく些細なことしか実行しませんが、他のプログラムと組み合わせることで、汎用的で便利なツールとなるのです。

著者らはさらに、本書の目的は「UNIXプログラミングの哲学を伝えること」だと述べている。^{[ 5 ]}

1984 年 10 月、ブライアン・カーニハンとロブ・パイクは「UNIX 環境におけるプログラム設計」という論文を発表しました。この論文の中で、彼らは4.2BSDやSystem Vなどの新しい Unix システムで見られるプログラムオプションや機能の増加を批判し、それぞれが 1 つの一般的な機能を実行するソフトウェアツールの Unix 哲学について説明しています。^{[ 6 ]}

UNIX オペレーティングシステムの強力な機能の多くは、プログラムを使いやすく、さらに重要なことに、他のプログラムと簡単に組み合わせられるようにするプログラム設計スタイルに由来しています。このスタイルはソフトウェアツールの使用と呼ばれ、プログラムが内部的にどのように設計されているかよりも、プログラムがプログラミング環境にどのように適合し、他のプログラムとどのように使用できるかに大きく依存しています。[...] このスタイルはツールの使用に基づいています。つまり、手作業で、モノリシックな自己完結型のサブシステムで、または特殊な目的の単発プログラムで作業を行うのではなく、プログラムを個別に、または組み合わせて使用​​して作業を完了します。

著者らは、catなどのUnixツールと、他のシステムで使用されるより大規模なプログラムスイートを比較している。^{[ 6 ]}

catの設計は、ほとんどの UNIX プログラムに典型的なものです。つまり、多くの異なるアプリケーション (元の作者が想定していなかったものも含む) で使用できる、シンプルながらも汎用的な機能を 1 つ実装しています。他の機能には、他のコマンドが使用されます。たとえば、ファイル名の変更、削除、ファイルサイズの取得など、ファイルシステム関連のタスクには個別のコマンドがあります。他のシステムでは、これらを独自の内部構造とコマンド言語を持つ単一の「ファイルシステム」コマンドにまとめています。( CP/MやRSX-11などのオペレーティングシステムにあるPIPファイルコピー プログラム^{[ 7 ]}はその一例です。) このアプローチは必ずしも優れているとも劣っているとも言えませんが、UNIX の哲学には明らかに反しています。

当時ベル研究所コンピューティング科学研究センターの責任者であり、Unixパイプの発明者でもあるマッキルロイ^{[ 8 ]}は、Unixの哲学を次のように要約した。^{[ 3 ]}

これがUnixの哲学です。一つのことをうまくこなすプログラムを書きましょう。プログラム同士が連携して動作するように書きましょう。テキストストリームを扱うプログラムを書きましょう。なぜなら、テキストストリームは普遍的なインターフェースだからです。

これらの発言に加えて、彼はUnixプログラミングにおけるシンプルさとミニマリズムも強調している。 ^{[ 3 ]}

「複雑で美しい複雑さ」という概念は、ほとんど矛盾語法と言えるでしょう。Unixプログラマーは「シンプルで美しい」という栄誉を競い合っています。 この点はこれらのルールに暗黙のうちに含まれていますが、あえて明言する価値は十分にあります。

逆に、マッキルロイは現代のLinuxをソフトウェア肥大化していると批判し、「熱狂的なファンがLinuxの便利な機能を与えすぎて、落胆するような肥満状態に陥らせた」と述べている。^{[ 9 ]}彼はこれを、ベル研究所がResearch Unixを開発および改訂した際の以前のアプローチと対比させている。^{[ 10 ]}

すべてが小さかった…そしてLinuxのサイズを見ると、私は心が沈む。[…] かつて本当にマニュアルページだったマニュアルページは、今では1000ものオプションがある小さな冊子になっている…私たちはUnixルームに集まって、「何を捨てられるだろうか？なぜこのオプションがあるのか​​？」と話し合っていた。それは多くの場合、基本設計に何らかの欠陥があるからだ。つまり、正しい設計ポイントに到達していなかったのだ。オプションを追加するのではなく、なぜそのオプションを追加せざるを得なかったのかを考えてみよう。 

McIlroy氏が述べたように、またUnixコミュニティ全体で広く受け入れられているように、Unixプログラムは常にDOTADIW、つまり「Do One Thing And Do It Well（一つのことをきちんと行う）」という概念に従うことが期待されてきました。インターネット上にはDOTADIWという略語に関する情報源は限られていますが、特にLinuxコミュニティでは、新しいオペレーティングシステムの開発やパッケージングの際に詳しく議論されています。

Slackware LinuxのプロジェクトリーダーであるPatrick Volkerding氏は、 systemdアーキテクチャを批判する際にこの設計原則を持ち出し、「サービス、ソケット、デバイス、マウントなどをすべて 1 つのデーモン内で制御しようとすることは、1 つのことをうまく行うという Unix の概念に反する」と述べています。^{[ 11 ]}

2003年に初版が出版された著書『The Art of Unix Programming』^{[ 12 ]}の中で、オープンソースの提唱者でありプログラマーでもあるエリック・S・レイモンドは、Unixの哲学を「Keep it Simple, Stupid（シンプルに保て、バカ）」と要約している。^{[ 13 ]} 彼は一連の設計ルールを提供している。^{[ 3 ]}

• モジュール型プログラムを構築する
• 読みやすいプログラムを書く
• 構成を使用する
• メカニズムと政策を分離する
• 簡単なプログラムを書く
• 小さなプログラムを書く
• 透明性の高いプログラムを作成する
• 堅牢なプログラムを作成する
• 必要に応じてデータを複雑化させるが、プログラムを複雑化させてはならない。
• 潜在ユーザーの期待する知識に基づいて構築する
• 不要な出力を避ける
• 診断しやすい形で失敗するプログラムを作成する
• 機械時間よりも開発者の時間を重視する
• 手作業でコードを書く代わりに、コードを生成する抽象プログラムを作成する
• ソフトウェアを改良する前にプロトタイプを作成する
• 柔軟でオープンなプログラムを作成する
• プログラムとプロトコルを拡張可能にする。

1994年、デジタル・イクイップメント・コーポレーション（DEC）のUnixエンジニアリンググループ（UEG）のメンバーであるマイク・ガンカーズは、1980年代にDECで自身が行ったUnix（Ultrix ）移植開発と同僚との議論に基づき、 『The UNIX Philosophy』を出版した。彼はまた、 X Window System開発チームのメンバーであり、 Ultrix Window Manager （uwm）の作者でもある。

本書は、 1980年代のUNIX戦争中にUNIXを様々なコンピュータに移植することに焦点を当て、ハードウェアやグラフィックデバイスに非標準のインターフェースを使用する効率性よりも、移植性の方が重要であるという著者の哲学を述べている。

彼が重要だと主張する9つの基本的な「信条」は以下の通りである。

1. 小さいことは美しい。
2. 各プログラムは、一つのことをうまくこなせるようにする。
3. できるだけ早くプロトタイプを作成してください。
4. 効率性よりも携帯性を優先しよう。
5. データをフラットなテキストファイルに保存します。
6. ソフトウェアの力を有利に活用しましょう。
7. シェルスクリプトを使用することで、利便性と移植性を高めることができます。
8. 強制的なユーザーインターフェースは避ける。
9. すべてのプログラムをフィルターにする。

リチャード・P・ガブリエルは、Unixの重要な利点は、「悪い方が良い」という設計思想を体現していたことだと指摘する。この思想では、インターフェースと実装のシンプルさが、システムの他の属性（正確性、一貫性、完全性など）よりも重要視される。ガブリエルはこの設計スタイルが進化上の重要な利点をもたらすと主張する一方で、その結果の質については疑問を呈している。

例えば、初期のUnixではモノリシックカーネルが使用されていました（つまり、ユーザープロセスはカーネルシステムコールをすべてユーザースタック上で実行していました）。プロセスがカーネル内で長時間のI/O処理でブロックされている間にシグナルが届いた場合、その状況の処理方法は不明確でした。プロセスがカーネルモードであり、スタック上に機密性の高いカーネルデータが存在する場合、シグナルハンドラを実行することはできなかったのです。