コンテナとクラウドOSに息づくケン・トンプソンのUNIXの原則

なぜケン・トンプソンとUNIXが今も重要なのか

ケン・トンプソンは「永続するOS」を作ろうとしたわけではありません。デニス・リッチーらと共にベル研究所で目指したのは、開発者が理解し、改良し、別の機械に移せるような小さく実用的なシステムでした。UNIXは実践的な目標で形作られました：コアを単純に保ち、ツールが協調して動くようにし、ユーザを特定のコンピュータモデルに縛らないこと。

驚くべきことに、初期の選択は現代の計算にもよく当てはまります。端末がウェブダッシュボードに置き換わり、単一サーバが仮想マシンの群れに変わっても、同じ問いが繰り返し現れます：

• コンポーネントを混乱させずにつなぐにはどうするか？
• 仕事を安全に隔離するには？
• ある部分を変えても全体を壊さないには？

原則は機能に勝る

具体的なUNIXの機能は進化（あるいは置き換え）されてきましたが、設計原則は「システムをどう作るか」を示すため有用性を保っています：

• 巨大なオールインワンよりも小さく焦点を絞ったツールを優先する
• 部品が再結合できるように単純なインターフェイスを使う
• 境界を明確に保つ（ユーザ、プロセス、権限の間）

これらの考えはLinuxやPOSIX互換性から、プロセス隔離やネームスペース、ファイルシステムトリックに依存するコンテナランタイムまで、あらゆるところに現れます。

記事の狙い

トンプソン時代のUNIX概念を、今日あなたが扱うものにつなげます：

• プロセスモデルと標準ストリームがコンテナとどう関係するか
• 「すべてはファイル」の考えがクラウド運用と自動化にどう響くか
• 安定したインターフェイスが大規模システムの保守をどう容易にするか

期待すること

これは実用的なガイドです：専門用語は最小限に、具体例を示し、「なぜ機能するか」に焦点を当てます。コンテナやクラウドOSの振る舞いを素早く理解するためのメンタルモデルが欲しいなら、ここは良い出発点です。

準備ができたら /blog/how-unix-ideas-show-up-in-containers に進めます。

UNIXの短く実践的な歴史

UNIXは壮大なプラットフォーム戦略として始まったわけではありません。ケン・トンプソン（およびデニス・リッチーらの重要な貢献）によって作られた、小さく実用的なシステムとして始まり、明快さ、単純さ、有用な作業を優先しました。

短い年表（重要なポイント）

• 1969–1971: 初期のUNIXが質素なハードウェアで作られる。目的はプログラムを書く・実行するのに便利な環境であり、「メインフレームの置き換え」ではない。
• 1973年: UNIXが大部分をCで書き直される。これはUNIXを別の機械に移しやすくした転換点。
• 1970年代後半–1980年代: UNIXは大学やベンダに広がり、多くの「UNIX互換」システムが各々の調整を伴って登場。
• 1990年代以降: 標準化努力（特にPOSIX）によって、実装が異なってもコアの振る舞いが一貫するようになる。

当時の「移植可能なOS」が意味したこと — そしてそれが重要だった理由

初期にはOSが特定のコンピュータモデルに強く結びつくことが多く、ハードウェアを変えると実質的にOS（そしてしばしばソフトウェア）も書き換える必要がありました。

移植可能なOSとは実用的な意味で、同じOSの概念や多くの同じコードが、はるかに少ない書き換えで別のマシン上で動くことを指します。UNIXをCで表現したことで、チームは特定のCPUへの依存を減らし、他者がUNIXを採用・適応する現実性を高めました。

UNIXは製品ではなくアイデアの系譜

「UNIX」と言うと、オリジナルのベル研究所版、商用の派生、あるいはLinuxやBSDのような現代のUNIX系を指す場合があります。共通点は単一のブランドよりも、共有された設計選択とインターフェイスにあります。

そこにPOSIXの重要性があります：多くのUNIX的振る舞い（コマンド、システムコール、慣習）を規格化することで、基盤の実装が異なっていてもソフトウェアを互換的に保つ助けになります。

小さく合成可能なツール：UNIXの核心理念

UNIXは一見単純なルールを普及させました：一つの仕事をうまくこなすプログラムを作り、それらを組み合わせやすくする。ケン・トンプソンら初期のUNIXチームは巨大なオールインワンを目指さず、振る舞いが明確な小さなユーティリティを目指しました——それらを積み重ねて実際の問題を解けるように。

なぜ「小さい」ことが実用的利点になるのか

一つの仕事に絞ったツールは可動部分が少ないため理解しやすく、テストもしやすい。既知の入力を与えて出力を検証すれば、まわりの環境を全部用意しなくても動作確認できます。要求が変わったとき、一部を置き換えるだけで済み、すべてを書き直す必要がありません。

このアプローチは「置換可能性」も促します。ユーティリティが遅い、機能が足りない、あるいは存在しない場合、基本的な入出力の期待が同じであればより良いものと差し替えられます。

メンタルモデル：複合が複雑性に勝つ

UNIXツールをLEGOブロックのように考えてください。各ブロックは単純で、つなぎ方に力があります。

テキスト処理の古典的な例では、データを段階的に変換します：

cat access.log | grep \" 500 \" | sort | uniq -c | sort -nr | head

コマンドを覚えていなくても、考え方は明確です：データから始めて、フィルタして、集約して、上位を表示する。

これは現代のシステムでどう反響するか（同じではないが）

マイクロサービスを「ネットワーク上のUNIXツール」と無理に同一視すると誤解を招きますが、根底にある直感は似ています：コンポーネントを集中させ、境界を明確に定義し、小さなパーツから進化可能な大きなシステムを組み立てること。

パイプと標準ストリーム：大きなシステムを作る

UNIXが持っていた力は単純な慣習に由来します：プログラムは予測可能な場所から入力を読み、別の場所に出力を書くべきだということ。この慣習により小さなツールを組み合わせて大きな「システム」を作れるようになりました。

パイプを平易に説明すると

パイプはあるコマンドの出力を直接次のコマンドの入力につなげます。ノートを回すように、一つのツールがテキストを出力し、次のツールがそれを消費します。

UNIXツールは典型的に三つの標準チャネルを使います：

• 標準入力（stdin）：プログラムが読む場所（多くはキーボードか別のプログラム）
• 標準出力（stdout）：プログラムが通常の結果を書く場所
• 標準エラー（stderr）：警告やエラーを書く場所

これらのチャネルが一貫しているため、ツール同士は互いに何も知らずに配線（ワイヤ）できるのです。

なぜこれが再利用と自動化につながるのか

パイプはツールを小さく集中させることを促します。プログラムがstdinを受け取りstdoutを出せるなら、多くの文脈で再利用可能になります：対話的利用、バッチジョブ、スケジュールされたタスク、スクリプトなど。これがUNIX系システムがスクリプトフレンドリーである理由です：自動化はしばしば「これらの部品を繋ぐこと」にすぎません。

あなたが既に使っている現代的な類似物

• ストリーミングログ： ログをtailしてフィルタする（ローカルやプラットフォーム上で）は、テキストをフィルタに通すパイプに似ています。
• ETLパイプライン： 抽出→変換→ロードは、データがJSONであっても段階的な合成という同じ考え方です。
• グルースクリプト： シェル、Python、CIステップは多くの場合ツールを繋ぐだけの役割で、まさにパイプとストリームの考え方です。

この合成性は初期UNIXから現代のクラウドワークフローの組み立て方への直接の系譜です。

「すべてはファイル」：単純なインターフェイスの大きな効力

UNIXは大胆な簡略化を行いました：さまざまなリソースをファイルのように扱う。ディスクファイルとキーボードが同じであるからではなく、共通のインターフェイス（open, read, write, close）を与えることでシステムを理解しやすく自動化しやすくするためです。

あなたがおそらく使った具体例

• デバイス： 端末、ディスク、乱数発生器などは /dev/ 以下に現れます。/dev/urandom を読むことはファイルを読むように感じますが、実際にはバイトを生成するデバイスドライバです。
• ソケットとパイプ： ネットワーク接続やプロセス間通信はファイル記述子を通じて扱えることがあります。プログラムはバイトを書き、OSがそれをルーティングします。
• 設定： プレーンテキストの設定ファイルは同じツールをどこでも使えるようにします：テキストエディタで編集し、スクリプトで検証し、Gitで管理する。
• ログ： ログはしばしば追記専用のファイルです。これによりローテーション、grep、tail、アーカイブ、転送が容易になります。

なぜ重要か：一貫したツールと予測可能な振る舞い

リソースが共通のインターフェイスを共有するとレバレッジが生まれます：「出力はバイト」「入力はバイト」であれば、単純なユーティリティ群を無数の方法で組み合わせられます。各ツールがデバイスやネットワーク、カーネルの詳細を知らなくて済むのです。

これは安定性も促します。チームは少数のプリミティブ（読み書きストリーム、ファイルパス、権限）を中心にスクリプトや運用習慣を構築し、基盤技術が変わってもそのプリミティブは変わらないと信頼できます。

クラウドとの結びつき：ログや/proc風のテレメトリ

現代のクラウド運用もこの考えに依存しています。コンテナのログはストリームとして扱われ、tailして転送されます。Linuxの/procはプロセスやシステムのテレメトリをファイルとして公開するので、監視エージェントはCPUやメモリ、プロセス統計を普通のテキストのように「読む」ことができます。このファイル形状のインターフェイスが大規模でも可観測性と自動化を扱いやすくしているのです。

権限と最小権限：スケールするセキュリティ

UNIXの権限モデルは一見小さいものです：すべてのファイル（およびファイルのように振る舞う多くのシステムリソース）にはオーナー、グループ、そしてユーザ／グループ以外のその他という三者向けの権限があり、読み／書き／実行ビットで表されます。

基本：所有権＋単純なルール

一度でも -rwxr-x--- のような表示を見たことがあれば、その行にモデルが詰まっています：

• オーナー（user）：通常はファイルを作成したか「所有」するアカウント
• グループ：アクセスを共有するユーザの集合
• その他（others）：システム上のその他全員

この構造はスケールしやすく、理由は単純で監査しやすいからです。またチームに「動かすために全部を開けるな」という習慣を促します。

最小権限を平易に説明すると

最小権限は人物・プロセス・サービスに対してその仕事に必要な権限だけを与え、それ以上は与えないことを指します。実務ではしばしば：

• プログラムを非管理者ユーザーとして実行する
• 書き込みが必要な場所にのみ書き込み権を与える
• 強力な単一アカウントを共有するのではなく職務を分離する

これが現代のシステムにどうマップされるか

クラウドプラットフォームやコンテナランタイムは異なる道具で同じ考えを反映します：

• サービスアカウントは人間ではないワークロードのためのUNIXユーザーのようなもの
• IAMポリシー／ロールは単純なrwxビットより詳細で粒度のある権限システム
• ランタイム権限（コンテナがどのファイルを書けるか、ホストデバイスにアクセスできるか）は、最小権限の実行コンテキスト版

重要な注意点

UNIXの権限は有用ですが完全なセキュリティ戦略ではありません。データ漏洩をすべて防ぐわけでも、脆弱なコードが悪用されるのを止めるわけでも、ネットワーク制御やシークレット管理に代わるものでもありません。基礎として有用で理解しやすく効果的ですが、単独では不十分です。

プロセスを第一級概念として扱う

UNIXはプロセス（実行中のインスタンス）を中核的な構成要素として扱います。これは抽象的に聞こえますが、信頼性やマルチタスク、現代のサーバ（およびコンテナ）がマシンを共有する方法に大きな影響を与えます。

プログラムとプロセス（身近な例え）

プログラムは「レシピカード」のようなもの：何をするかを書いたもの。

プロセスはそのレシピで実際に料理しているシェフ：現在の手順、並べられた材料、使用中のコンロ、動いているタイマーを持ちます。同じレシピから複数のシェフが同時に料理できます——それぞれが独立したプロセスで、同じプログラムから始まっていても状態は別です。

なぜプロセス隔離が信頼性を高めるのか

UNIXシステムでは各プロセスが自身の「バブル」を持ちます：独自のメモリ、開かれたファイルのビュー、触れる範囲の境界があるためです。

この隔離により障害が局所化されます。あるプロセスがクラッシュしても通常は他を巻き込まず、ウェブサーバ、データベース、バックグラウンドスケジューラ、ログシッパーなどを一台のマシンで安全に動かせます。プロセスごとに開始・停止・再起動・監視が可能なのは大きな利点です。

共有システムでは、隔離は安全なリソース共有も支えます：OSはCPU時間やメモリといった制限を課して一つの暴走プロセスが全体を枯渇させないようにできます。

シグナルとジョブ制御（「肩を叩く」ようなもの）

UNIXはシグナルという、システム（またはあなた）がプロセスに通知する軽量の仕組みを提供します。肩をちょっと叩くようなものです：

• 「止めてください」（終了）
• 「ちょっと休んで」（一時停止）
• 「設定をリロードして」（長時間稼働するサービスで一般的）

ジョブ制御は対話的利用でこの考えを発展させます：タスクを一時停止し、フォアグラウンドで再開し、バックグラウンドで動かすなど。ポイントはプロセスが生きている単位として管理されることです。

ノートパソコン一台からサーバ上の多くのワークロードへ

プロセスを簡単に作成し隔離し制御できるようになると、一台のマシンで多くのワークロードを安全に動かすことが普通になります。そのメンタルモデル——小さな単位を監督・再起動・制限できる——は現代のサービスマネージャやコンテナランタイムの直接の先祖です。

安定したインターフェイス：UNIXが長く続いた隠れた理由

UNIXが勝ったのはすべての機能を最初に持っていたからではありません。いくつかのインターフェイスをあえて退屈にして、そこを変えないようにしたからです。開発者が同じシステムコール、同じコマンドライン振る舞い、同じファイル慣習を年々頼りにできると、ツールは作り直される代わりに蓄積されます。

「安定したインターフェイス」が本当に意味するもの

インターフェイスはプログラムとその周囲のシステムとの間の合意です：「Xを要求したらYが返る」。UNIXは重要な合意（プロセス、ファイル記述子、パイプ、権限）を安定して維持し、新しいアイデアが古いソフトウェアを壊さずに上に成長できるようにしました。

APIとABI（平易に）

人々はよく「API互換性」と言いますが、二つの層があります：

• API（アプリケーションプログラミングインターフェイス）：ソースコードが期待するもの。関数名や引数、振る舞いが変わるとコンパイルできなくなったり動作が変わる。
• ABI（アプリケーションバイナリインターフェイス）：コンパイル済みプログラムが期待するもの。呼び出し規約やバイナリ形式、共有ライブラリのシンボルが変わると、ソースコードが問題なくても既存のバイナリが起動しなくなる。

安定したABIはエコシステムが長く続く大きな理由の一つです。

POSIX：移植性を方針にする

POSIXは共通の「UNIX的」ユーザ空間（システムコール、ユーティリティ、シェルの振る舞い、慣習）を取りまとめました。すべてのシステムを同じにするわけではありませんが、Linux、BSD、その他のUNIX派生システムで同じソフトウェアを構築・利用できる重なりを作ります。

これがコンテナにとって重要な理由

コンテナイメージは静かにUNIX的な振る舞いの安定に依存しています。多くのイメージは次を前提とします：

• 予測可能なファイルシステム配置と権限モデル
• 共通のユーティリティやシェルが慣習通りに動くこと
• 標準ストリーム（stdin/stdout/stderr）やプロセスシグナルが一貫して動作すること

コンテナが移植性を感じさせるのは「すべてを含む」からではなく、広く共有された安定した契約の上に乗っているからです。その契約はUNIXの最も持続的な貢献の一つです。

UNIXのアイデアがコンテナに現れる方法

コンテナはモダンに見えますが、メンタルモデルは非常にUNIX的です：実行中のプログラムをプロセスとして扱い、明確なファイル群、権限、リソース制限を設定します。

コンテナはプロセス隔離とパッケージ化の組合せ

コンテナは「軽量なVM」ではありません。アプリケーションとそのライブラリや設定をまとめたパッケージであり、孤立して動作するように隔離された通常のホスト上のプロセス群です。大きな違いは、コンテナはホストカーネルを共有し、VMは自身のカーネルを持つことです。

古典的なUNIXの構成要素を再構成したもの

多くのコンテナ機能はUNIXの考えの直接の延長です：

• プロセス： コンテナの「メイン」アプリは単なるプロセス（コンテナ内ビューではしばしばPID 1）であり、子プロセス、シグナル、終了コード、ログはUNIXの期待通りに振る舞います。
• インターフェイスとしてのファイルシステム： コンテナイメージはファイルシステムのスナップショット（レイヤー化された変更）であり、コンテナ実行は特定のルートファイルシステムビューを持つプロセスを起動することです。
• 権限： ユーザ、グループ、ファイルモード、ケーパビリティがコンテナ化されたプロセスの振る舞いを決めます—ここでも最小権限の物語は同じです。

ネームスペースとcgroups（概念的に）

二つのカーネル機構が大部分の重労働を担います：

• ネームスペースはプロセスに固有の「ビュー」を与えます。プロセスは異なるPIDやマウント、ネットワークインターフェイス、ホスト名を見ることができ、自分だけの小さなシステムのように振る舞えます。
• **cgroups（コントロールグループ）**はリソース使用（CPU、メモリなど）を制限・計測します。UNIX単体では十分に解決していなかった「ひとつのワークロードがマシンを食い尽くすのをどう防ぐか」という実務的な問いに答えます。

留意すべき制限とリスク

コンテナはカーネルを共有するため隔離は絶対ではありません。カーネルの脆弱性は全コンテナに影響し得ますし、設定ミス（rootでの実行、広範なケーパビリティ、センシティブなホストパスのマウント）は境界を弱体化します。エスケープリスクは現実的ですが、慎重なデフォルト、最小権限、良好な運用慣行で緩和されるのが一般的です。

UNIXの合成からクラウドネイティブなパターンへ

UNIXは一つの単純な習慣を広めました：一つの仕事をする小さなツールを作り、明確なインターフェイスでつなぎ、環境に配線を任せる。クラウドネイティブなシステムは外見は違いますが、分散作業には同じ考え方が驚くほどよく当てはまります：サービスを集中させ、統合点を明示にし、運用を予測可能に保つ。

小さなコンポーネント、明確な契約

クラスターでは「小さなツール」はしばしば「小さなコンテナ」を意味します。すべてをやろうとする大きなイメージを出荷する代わりに、責務を分割して振る舞いが狭くテストしやすいコンテナ群に分けます。

いくつかの一般例は古典的なUNIXの合成を反映します：

• Initコンテナはメインワークロードの前に環境を準備する（マイグレーション、設定生成、権限設定）—セットアップスクリプトのように実行して終了する。
• サイドカーはプロキシ、mTLS、キャッシュ、スクレイピングなど単一の機能を追加し、アプリ本体を変えない。
• ログコレクタはログを読み転送し、アプリは有用な出力を書くことに専念する。
• ヘルスチェックは「動いているか？」の単純な信号を提供し、コマンドの終了コードを契約として使うのと似ている。

各部品のインターフェイスは明確です：ポート、ファイル、HTTPエンドポイント、またはstdout/stderr。

パイプとストリームは可観測性向けに更新された

パイプがプログラムを繋いだように、現代のプラットフォームはテレメトリストリームを繋ぎます。ログ、メトリクス、トレースはエージェントやコレクタ、バックエンドを通るパイプラインになります：

アプリケーション → ノード／サイドカーエージェント → コレクタ → ストレージ／アラート

パイプと同じ利点があり、ステージを挿入・交換・削除してもプロデューサを書き換える必要がありません（フィルタ、サンプリング、付加など）。

合成による運用の単純化

合成可能なビルディングブロックはデプロイを再現可能にします：「これをどう実行するか」のロジックは個人の記憶ではなく宣言的なマニフェストと自動化に置かれます。標準的なインターフェイスにより、変更を展開し、診断を追加し、ポリシーを一貫して適用できます—ひとつずつ小さな単位で。

現代的なワークフローの注記：UNIX的にシステムを作る（より速く）

UNIX原則が繰り返し現れる理由の一つは、チームの実際の働き方に合っているからです：小さなステップで反復し、インターフェイスを安定させ、驚いたらロールバックする。

ウェブサービスや内部ツールを構築しているなら、Koder.ai のようなプラットフォームはその思考法を摩擦少なく適用するための意見をもった手段だと言えます：チャットでシステムを記述し、小さなコンポーネントを反復し、境界を明確に保つ。planning mode、スナップショットとロールバック、ソースコードエクスポートのような機能はUNIXが促した運用習慣――安全に変更し、結果を観察し、システムを説明できる状態に保つ――を支援します。

今日すぐ使える実践的原則

UNIXの考えはカーネル開発者だけのものではありません。日常のエンジニアリングを落ち着かせる実践習慣です：驚きが少なく、障害が明確で、書き直しなしに進化するシステムにします。

1) インターフェイスを小さく（そして退屈に）保つ

小さなインターフェイスは理解しやすく、文書化しやすく、テストしやすく、差し替えやすい。サービスエンドポイント、CLIフラグセット、内部ライブラリを設計するときは：

• 多数の特殊ケースを増やすよりも、いくつかのよく選ばれた操作を優先する
• 互換性を機能と見なす：他が依存し始めると変更は高コストになる
• 新機能は合成（新しいツール／モジュール）で追加し、巨大なメガツールの拡張は避ける

2) 出力を可観測に：テキスト／ログの明快さを優先する

UNIXツールは透明性が高く、何をしているかを確認できます。サービスやパイプラインにも同じ基準を適用しましょう：

• 明確なイベント名と安定したフィールドを持つ構造化ログを出す
• 障害は明示的にする：エラーメッセージは何がどこで起きたか、次に試すべきことを示す
• JSONを提供する場合でも、平易なテキストで検査できる出力を優先する

コンテナ化サービスを構築しているなら基礎を /blog/containers-basics で見直してください。

3) 「最小権限」デフォルトで安全に自動化する

自動化はリスクを減らすためのもの。最小限の権限を使いましょう：

• 読み取りと書き込みの資格情報は分ける
• トークンは単一のサービスや環境に限定する
• OS権限は最小にし、「とりあえずrootで実行」の近道を避ける

権限の実用的な復習は /blog/linux-permissions-explained を参照してください。

4) 新しいツールを評価する方法：合成できるか、可観測か、差し替え可能か

新しい依存（フレームワーク、ワークフローエンジン、プラットフォーム機能）を採用する前に次の三つを問います：

1. 合成できるか？ 既存のスクリプト／サービスに無理やり書き換えを強いることなく差し込めるか？
2. 可観測か？ ログ／メトリクスでデバッグでき、単純な検査で問題が見えるか？
3. 差し替え可能か？ 後で置き換えられるか、その仮定を全体に広げないか？

どれか一つでも「いいえ」なら、あなたはただツールを買うのではなく、ロックインと隠れた複雑性を買っている可能性があります。

誤解、トレードオフ、そして明快な要約

UNIXは二つの反対の神話を引き寄せますが、どちらも本質を見誤っています。

神話1：「UNIXは時代遅れ」

UNIXはインストールする製品ではなく、インターフェイスに関する一連の考え方です。具体は進化しました（Linux、POSIX、systemd、コンテナ）が、UNIXを有用にした習慣は、理解可能でデバッグしやすく拡張可能なシステムが必要な場所ならどこにでも現れます。あなたのコンテナログが標準出力へ行き、ツールがパイプから入力を受け、権限が被害範囲を制限するなら、同じメンタルモデルを使っています。

神話2：「UNIXはすべてを解決する」

小さなツールの合成性はチームを“賢く”ではなく“明瞭”にする誘惑を生むことがあります。合成は強力な道具であり、強い慣習と慎重な境界があるときに最も働きます。

UNIXの考えが誤用される場面

過剰な細分化はよく見られます：「小さい方が良い」という理由で数十のマイクロサービスや小さなスクリプトに分割し、結果として調整、バージョニング、サービス間デバッグのコストを払う羽目になる。

シェルスクリプトのスプロールも問題です：素早いグルーコードがテストやエラーハンドリング、可観測性、オーナーシップなしで本番クリティカルになると、結果は単純さではなく脆弱な依存関係の網になります。

クラウドでのトレードオフ：抽象化は助けるが、隠れた複雑性が増える

クラウドプラットフォームはUNIXの強み（標準インターフェイス、隔離、自動化）を増幅しますが、抽象化の重ね合わせも生みます：コンテナランタイム、オーケストレータ、サービスメッシュ、マネージドデータベース、IAM層。各層は局所的な作業を減らす一方で「どこで壊れたか」の不確実性を増やします。信頼性の仕事はコードを書くことから、境界・デフォルト・故障モードを理解することへシフトします。

明快な要約

ケン・トンプソンのUNIX原則が今も重要なのは、システムを単純なインターフェイス、合成可能なビルディングブロック、最小権限に偏らせるからです。思慮深く適用すれば、現代のインフラは運用しやすく変更しやすくなります。盲目的に適用すれば、不必要な細分化とデバッグ困難な複雑性を生みます。目標は1970年代のUNIXを模倣することではなく、プレッシャー下でも説明可能なシステムを保つことです。