Design Philosophy: Unix/Linux

The Unix philosophy as a thinking tool for modern system design.

Mechanism vs Policy

The deepest principle in Unix. The kernel provides mechanisms (process scheduling, file descriptors, memory mapping). User-space provides policy (which processes run, what files mean, how memory is used). The kernel doesn't have opinions about your workflow. It gives you the tools to build any workflow.

The litmus test: Could two reasonable users want different behavior here? If yes, you're looking at policy — don't hardcode it. Provide a mechanism and let the caller decide.

How this applies broadly:

• Frameworks provide mechanisms; applications provide policy. A web framework gives you routing, middleware, and request handling. It should not decide your authentication strategy, your URL naming conventions, or your error page content. When a framework makes policy decisions for you, it works until your policy diverges — then you fight the framework.
• Libraries vs. frameworks is often a mechanism-vs-policy question. A library gives you mechanisms you call. A framework calls your code within its policy structure. Prefer libraries when the domain is well-understood and teams have strong opinions. Prefer frameworks when teams need guardrails and the policy is genuinely standard.
• Configuration systems should separate mechanism (how config is loaded, merged, validated) from policy (what the config values mean, what defaults are appropriate). The mechanism should be boring. The policy is the interesting part.

Design evaluation questions:

• Where in this design are mechanism and policy entangled? Can they be separated?
• When this system's users inevitably want different behavior, which parts will they need to fork vs. configure?
• Are we embedding today's policy decisions into tomorrow's mechanism layer?

The failure mode: Over-separating mechanism from policy creates systems that are infinitely flexible and impossible to use out of the box. X11 separated mechanism from policy so aggressively that every desktop environment had to reinvent window management from scratch. The mechanism layer should be opinionated enough to be useful — just not so opinionated that it precludes valid alternatives.

Do One Thing Well

The most cited and most misunderstood Unix principle. grep searches. sort sorts. uniq deduplicates. Each does one thing, does it thoroughly, and handles edge cases within its domain. The key word is well, not small.

What this actually means:

A component should have a clear responsibility boundary. Everything inside that boundary, it handles completely. Everything outside, it delegates. grep doesn't sort its output because sorting is outside its boundary. But grep handles binary files, compressed input, recursive directories, regex dialects, and colorized output — because those are all within "searching text."

How microservices got this wrong: "Do one thing" was interpreted as "be small." Teams created services so thin they couldn't do anything useful alone. A "user service" that only stores user records but can't validate an email address. A "notification service" that can't template a message. The result: every operation requires orchestrating five services, and the real logic lives in the orchestration layer — which is now doing everything and doing it badly.

The real principle: Draw clear responsibility boundaries. A component owns a coherent piece of functionality, not a minimal piece. The question isn't "Is this small enough?" but "If I need to change how X works, do I change exactly one component?"

Design evaluation questions:

• Can you describe what this component does in one sentence without using "and"?
• If the requirements for this responsibility change, how many components must change?

…