Unixにおけるインタフェースと実装の単純さと複雑さのトレードオフ

『rootから/へのメッセージ』には、Unixには、トレードオフがある時、実装が複雑になることをいとわない、という性格がある、とある。

root(ルート)から/(ルート)へのメッセージ―スーパーユーザーが見たひととコンピュータ

（Thompson の "UNIX Implementation" の紹介中で）どちらかというと、UNIX は考え方のシンプルさとは逆に、プログラムのほうはけっこう複雑である。（略）。最初に話したように、私は本来ハード屋であり、私が OS を作るとメカニズムのシンプルさを優先しがちである。（後略）
（『rootから/へのメッセージ』p. 110 ）

これは後半にあるように、プロのハードウェア技術者である筆者の感覚からの評価であることに注意。別のところで、

OS のオーバーヘッド
オーバーロードになった場合、まずできることは無駄を極力排除することである。無駄には、オペレーティング・システムに起因するものと、無駄遣いがある。私自身は“オペレーティング・システムは、それが存在することそのものが悪であり、オーバーヘッド以外の何物でもない”と考えている。暴言と思われるかもしれないが、当然それらが作られた目的や効果は十分認識したうえでの発言である。（後略）
（『rootから/へのメッセージ』p. 96 ）

とあり、いわゆる「リアルタイムモニタ」のようなごく軽量なシステムのシンプルさが念頭にあるものと考えられる。
一方、「The Rise of ``Worse is Better''」には、Unixは、

The New Jersey guy said that the right tradeoff has been selected in Unix-namely, implementation simplicity was more important than interface simplicity.

とある。
『rootから/へのメッセージ』の記述と相反するようにも見えるが、こちらで話題にされていたのは、ディスクからの読み書きのような、プロセスがシステムからの応答を待つようなシステムコールの実行中に中断があった場合、そこからの回復をどうするか、という話である、という点に注意が必要かもしれない。
プロセッサの設計にもよるが、たとえばユーザプログラムの側で errno を見てエラーが起きていたら再実行する、というような、面倒をユーザ側のプログラマに押し付けるような解決法以外（曰 MIT guy の主張するような、なんとかしてユーザプロセスのコンテキストを復元し、システムコールの処理をやり直すような）は、かなり実装が大変ではある（不可能な場合もあるほどに）。
（追記）なお、実際の仕様でこの話を確認すると、read や write でのブロック中にシグナルの処理が入った場合には、昔（研究所時代）の Unix や System V、初期の Linux では（ http://www.coins.tsukuba.ac.jp/~syspro/2005/No5.html を参照）、ブロックを抜けて（データを読み書きしてなければ） EINTR を返す、という仕様であった。BSD では、データを読み書きしてなければ r/w 待ちのブロックにシグナルの処理後は戻る、という仕様に改良され（ http://pubs.opengroup.org/onlinepubs/009695399/functions/read.html によれば 4.3BSD から）、Linux でも現在は BSD 風の動作だという。（「Linux は SysV」とその昔は言われた、という伝説の水源の一つかもしれない）