部分の集積は全体よりも大きい。90パーセントの解決を模索せよ。悪いことは、より良いことだ。better")という用語に込めるデザイン哲学を体現しているところにあると述べている。「より悪いことは、より良いことだ」式のデザイン・スタイルでは、インターフェースと実装の両面がシンプルであることが、システムにおける他のいかなる特性よりも重視される――正確さ、堅牢さ、完全さよりも、である。ガブリエルは、このデザイン・スタイルが発展のための重要な利点を持っていると論じているが、一方でいくつかの結果の質について疑問を抱いてもいる。黎明期のUNIXにおいて、プロセスはカーネル・システムコールをすべてユーザスタック上で実行した。プロセスがカーネルモードで動いている場合、シグナル・ハンドラは実行され得ず、スタックには繊細なカーネル・データが残ったままである。カーネルはシステムコールを棄却(バックアウト)し、応答と再始動に備えて保管し、成功裏にシグナルハンドラを完了することを引き受けるべきなのか?このようなケースでは、ケン・トンプソンとデニス・リッチーは完全性よりもシンプルさを好む。システムコールに割り込みが発生」)を行う。エラー番号4(EINTR)である。このような呼び出しはシグナルハンドラを呼び出すために中断されている。したことは、長期間実行されうる一群のシステムコール(つまりread()、write()、open()、select()等)において起こり得る。利点としては、この仕組みはI/Oシステムを何倍もデザインしやすく、理解しやすいものにしている。圧倒的多数のプログラムは影響を受けない。したプログラムはSIGINT/^C以外のシグナルを扱わず、経験もしないし、SIGINTが発せられたときには正確に終了(die)するからである。それ以外の少数のプログラム(ジョブ制御のキー入力を受け付けるシェルやテキストエディタのようなもの)のためには、システムコールの小さなラッパー(wrapper)を追加することができ、EINTRエラーが起こったらすぐにシステムコールを再試行できるのである。問題はシンプルな方法で解決される。(現在のUnixクローンでは、カーネルコードがユーザスタックで実行されたりしないし、I/O中のシグナルについて、このようなふるまいであったのは、初期のUNIXやSystemV(あるいは初期のLinux)においてのことである。(KISS原則、「シンプルでつまらないものに保て」)という、広く使われている工学哲学として要約した。レイモンドは、彼がいかにこの総体的な哲学がUNIXの文化的規範として適用されていると信じているか述べている。以下のルールを深刻に違反した例が実際のUNIXの実践において簡単に発見できるのも驚くべきことではない。モジュール性のルールクリーンなインターフェースで接続されるシンプルなパーツを書け。明瞭さのルール明瞭さは独創性よりも良い。合成のルール他のプログラムと接続できるようプログラムをデザインせよ。分割のルールポリシーをメカニズムから分離せよ。インターフェースをエンジンから分離せよ。シンプルさのルールシンプルさを求めてデザインせよ。複雑にしなければならない場合に限り、複雑さを加えよ。倹約のルール他に方法がないことが実験により明らかである場合に限り、大きいプログラムを書け。透明性のルール透明性を求めてデザインせよ。調査とデバッグが簡単になる。頑丈さのルール頑丈さは透明性とシンプルさから生まれる。代表のルール知識をデータに織り込め。するとプログラムのロジックをつまらなくて頑丈なものにできる。最小限の驚きのルールインターフェースデザインにおいては、常に驚きが最小限であるようにせよ。沈黙のルール余計な出力をすべきではない。他の開発者にとってただ邪魔なだけである。修復のルール失敗しなければならないときは、騒がしく、かつできるだけ早く失敗せよ。経済のルールプログラマの時間は貴重である。プログラマの時間をコンピュータの時間より優先して節約せよ。生成のルールhand-hacking[3]は避けよ。プログラムを書けるときに、プログラムを書くためにプログラムを書け。最適化のルール洗練させる前に原型(プロトタイプ)を作れ。最適化する前に原型が動くようにせよ。多様性のルールあらゆる「ただ一つの本当の方法」という主張は信じるな。拡張性のルール未来に向けてデザインせよ。未来は思ったよりもすぐにやってくる。writes.これら規範の多くはUNIXコミュニティの外で受け入れられている――最初にUNIXが採用したときはそうでなかったとしても、後にそうなった。多くはUNIXコミュニティ独特のものではなく、UNIXコミュニティから生じたわけでもない。かかわらず、熟練のUNIXプログラマーはこれらの考え方を組み合わせたものをUNIXスタイルの基礎として受け入れる傾向がある。論争[編集]GNUプロジェクトによる標準的なUNIXプログラムの代替(diffやfind等)が「Unix哲学」に従うものであるのか、あるいはそれを誤解しているのかは議論の分かれるところである。UNIXに古くから関わる人々のうちの少なくともいくらかは後者を主張するであろう。GNUプロジェクトのツール群はしばしばUNIXと同等のものよりも十分に大きく、また機能も豊富だからである(GNUはコーディング標準において、いくつかの点でUNIXと同じにしないことを薦めている)。)の仕様が、Unix的でないとした批判がある[4]。ストリームを読んで書くだけの目的に流用されることが多いとはいえ、それに加えてあれこれと機能を持つべきではない。コマンドをパイプで繋げるのはどう考えてもかったるい。いったわけで、現代では議論されることはあまり見られなくなったものの、普段Linux等を使っている際に当然とされていることが本当に当然なのか、考えさせられる論点がある。引用[編集]「UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである。「UNIXはユーザが愚かなことをするのを止めるために作られたのではない。小器用なことをするのも防いでくれるのだ。ダグ・グウィン「UNIXはユーザフレンドリーだ。誰彼構わずフレンドリーになるわけではないだけだ。UNIX哲学の着想の源の一つ。2008年11月21日閲覧。(日時は個人設定で未設定ならばUTC)。表示-継承ライセンスの下で利用可能です。追加の条件が適用される場合があります。詳細は利用規約を参照してください。開発者Cookieに関する声明モバイルビュ。