Operating systems balance fundamental design principles: resource management (sharing fairly and efficiently), abstraction (hiding complexity), protection (isolating processes), and performance. These principles often conflict; understanding them explains the structure of real OSes.
From your introduction to operating systems, you know that the OS sits between hardware and applications, managing resources and providing services. But *how* an OS is structured — which parts go where, what is exposed to applications, and what is hidden — follows from a small set of design principles that are in constant tension with each other. Understanding these principles gives you a framework for evaluating why operating systems are built the way they are, rather than memorizing their features as arbitrary design choices.
Abstraction is the principle that the OS should hide hardware complexity behind clean, simple interfaces. A program calls `write()` and bytes appear on disk; it does not need to know whether the disk is magnetic, solid-state, or networked, nor does it manage disk arm scheduling or wear leveling. Abstraction is what makes software portable and programmers productive. But abstraction has costs: every layer of indirection adds overhead, and if the abstraction does not match the hardware well (the "impedance mismatch" problem), performance suffers. A database engine might want to control exactly which disk blocks are written and in what order — the OS's file system abstraction gets in the way, which is why some databases bypass it entirely.
Resource management means the OS must share finite hardware — CPU time, memory, disk bandwidth, network capacity — among competing processes fairly and efficiently. "Fairly" and "efficiently" are themselves in tension: strict fairness (equal time slices for all) might waste resources on idle processes, while optimizing for throughput might starve low-priority tasks. The OS uses scheduling algorithms, memory allocation policies, and I/O queuing disciplines to navigate these tradeoffs, and different operating systems make different choices depending on their target workload (a real-time system prioritizes predictability; a server OS prioritizes throughput).
Protection and isolation ensure that one process cannot read or corrupt another's memory, monopolize the CPU, or access hardware it is not authorized to use. This principle motivates the hardware distinction between kernel mode and user mode that you studied as a prerequisite. The OS kernel runs in privileged mode with full hardware access; applications run in restricted mode and must request services through system calls. Protection adds overhead — every system call requires a mode switch, and memory protection requires hardware like the MMU to check every access — but without it, a single buggy program could crash the entire system. The art of OS design lies in balancing these competing principles: enough abstraction to be usable, enough protection to be safe, enough resource management to be fair, and enough performance to be practical. Every major OS design debate — monolithic kernel versus microkernel, preemptive versus cooperative scheduling, virtual memory overhead versus isolation guarantees — is a specific instance of this fundamental tension.
No topics depend on this one yet.