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: