UNIX哲学

UNIX哲学（）とは、ソフトウェア開発の文化的な規範と哲学のまとまりであり、UNIX OS開発者たちの経験に基づくものとされている。その内容は発言者によって異なり、以下の点に留意が必要である：
すなわち、この哲学は当初から一貫して存在していたわけではなく、UNIXに関わる全ての人の共通認識でもなく、UNIXの現在や過去の状況を必ずしも的確に表現しているわけでもない。妥当性や有効性が普遍的に立証されているわけでもない。UNIXに関心を示す人々の一部の希望、願望、理想にすぎない。
起源.
1978年のBell System Technical Journalにダグラス・マキルロイ他によって記載されている：
その後、が『A Quarter-Century of Unix』（1994年）にまとめている：
1974年のUnix論文で、ケン・トンプソンとデニス・リッチーはUNIXの設計で以下を考慮したと述べている：
マキルロイ: UNIXの四半世紀.
パイプの発明者でありUNIX創始者の一人でもあるマキルロイはこの哲学を以下のように要約した：
この哲学は「一つのことを、うまくやれ」とさらに要約されることがある。このうち3つめだけがUNIXに特有である。
パイク: Cプログラミングに関する覚え書き.
（注意: これは直接にはUNIX哲学ではない。強い結びつきのあるC言語の記述ではある）
ロブ・パイクは "Notes on Programming in C" で以下をプログラミングの格言として提案している。UNIX哲学と共通点がある。
ルール1と2は、ドナルド・クヌースの格言「早すぎる最適化は諸悪の根源である」を言い換えたものである（最適化 (情報工学)#最適化する時期も参照）。
ケン・トンプソンはルール3と4を「疑いがあるときは総当たり（brute force）を使え」と言い換えている。これらは設計哲学のKISSの例でもある。
ルール5はフレッド・ブルックスが以前に「人月の神話」で述べている。ジョン・ベントレーの "" にも同じ原則が述べられている。これは「スマートなデータを使うつまらないコードを書け」と短縮されこともある。また「データ構造が十分に良いものなら、それを扱うアルゴリズムは平凡であるべきだ」というガイドラインの実例でもある。
ルール6はモンティ・パイソンの「ブルース・スケッチ」をふざけて引用したのものである。
ガンカーズ: UNIXの哲学.
1994年、マイク・ガンカーズ（X Window System開発チームの一員）は、UNIXで得た経験と、同僚プログラマーや他分野のUNIX利用者との議論を活かし、以下9つのUNIX哲学を創出した：
以下の教義は重要性が比較的低いとされ、UNIX哲学として普遍的に合意されるものではなく、場合によっては現在も激しく議論されている（例：モノリシックカーネルとマイクロカーネル）。
より悪いことは、より良いことだ（Worse is better）.
リチャード・P・ガブリエルは、UNIXの優位性のひとつは「より悪いことは、より良いことだ」（"Worse is better"）という哲学にあると述べている。ここではインターフェースと実装の両面がシンプルであることが、他のいかなる特性（正確さ、堅牢さ、完全さ）よりも重視される。
その一方で、以下のような疑問も投げかけている。例えば、もしI/Oやsleepなどのシステムコール（例：codice_1、codice_2、codice_3、codice_4）により、あるプロセスがカーネル内で長期間ブロックされているときに、そのプロセスにシグナルが通知されたら何を行うべきだろうか。システムコールが完了するまでの長い間（場合よっては永遠に）シグナルは遅延されるべきなのか。はたまた、カーネルはシステムコールをあとで再実行できるように状態を保存した上で一時中断し、シグナルハンドル、システムコールへと再復帰すべきか。いずれも時間はかかるがシステムコールを完遂する完全性を考慮したものである。
しかしながら、このようなケースではケン・トンプソンとデニス・リッチーは完全性よりもシンプルさを好む。聡明期のUNIXはシステムコールを終了させ、エラーを素早く通知する - "Interrupted System Call"（システムコール実行中にユーザーが割り込みを発行）、エラー番号4（EINTR）。後にシステムコールは再開されない。この実装はI/Oシステムを設計、理解しやすくする事に利点がある。
レイモンド: UNIXプログラミングの技法.
エリック・S・レイモンドは著書『The Art of UNIX Programming』で、UNIX哲学を "Keep it Simple, Stupid" （KISS原則、「シンプルでつまらないものに保て」）という工学哲学として要約した。いかにこの哲学がUNIXの文化的規範として適用されているか信念を述べている。しかしながら、以下のルールを違反した例も比較的簡単に発見できる。
これら規範の多くはUNIXコミュニティの外でも受け入れられている――最初にUNIXが採用したときはそうでなかったとしても、後にそうなった。また、多くはUNIXコミュニティ独特のものではなく、UNIXコミュニティから生じたわけでもない。にもかかわらず、熟練のUNIXプログラマーはこれらの考え方を組み合わせたものをUNIXスタイルの基礎として受け入れる傾向がある。
論争.
GNUプロジェクトによる標準的なUNIXプログラムの代替（diffやfind等）がUNIX哲学に従うものであるのか、あるいはそれを誤解しているのかは議論の分かれるところである。おそらく、UNIXに古くから関わる人々のうちのいくらかは後者を主張するであろう。なぜならGNUプロジェクトのツール群はしばしばUNIXのものよりも十分に大きく、また機能も豊富だからである（GNUはコーディング標準において、いくつかの点でUNIXと同じにしないことを薦めている）。
GNU以前の1983年、ロブ・パイクはUNIXの基本的なツールについて、BSDによって拡張された機能のいくつか（代表例として挙げられたのは、cat に制御コードを文字に変換して可視化させる -v ）の仕様が、UNIX的でないとした批判がある。UNIX哲学に従えば、cat -v の機能は独立したフィルタで果たされるべきである。本来「連結」コマンドである cat が、単にストリームを読んで書くだけの目的に流用されることが多いとはいえ、それに加えてあれこれと機能を持つべきではないという考え方もある。
同様にして批判されたls コマンドのオプション：出力を表示される幅に合わせて整形する機能は十分に便利であるが、UNIX哲学に従えば column コマンドをパイプで繋ぐ必要があり、これは煩わしいと考える事もできる 。