What an Operating System Is For

Hardware is embarrassingly literal. A CPU core executes one instruction stream at a time. RAM is a flat array of bytes with no notion of ownership. An SSD accepts read and write commands for block numbers. A NIC transmits whatever frame you hand it. Nothing in the hardware knows that the browser and the database are different programs, that one should not overwrite the other’s memory, or that a program waiting for a disk read should not burn a core doing nothing.

If every program talked to hardware directly, each would need its own driver for every disk and NIC model, each would have to trust every other program not to scribble on its memory, and one infinite loop would freeze the machine. Early machines actually worked that way: one job at a time, loaded by an operator. The moment you want two programs resident at once, you need a third program whose job is arbitration.

That third program is the operating system. It runs with more privilege than anything else (see User Mode vs Kernel Mode), it is the only code allowed to touch the hardware directly, and every other program gets its CPU time, memory, files and network access by asking it (see System Calls).

For each raw resource the OS invents an abstraction that is easier to program against and safe to hand to untrusted code. A core becomes a process or thread that appears to run continuously. Physical RAM becomes an address space that appears private and contiguous. Blocks on a disk become files with names, sizes and offsets. A NIC becomes a socket you can send() to. A keyboard, a GPU and a USB stick become devices behind a uniform read/write/ioctl interface.

Two things happen at once in every abstraction: it hides mechanism (you never see the SSD’s block numbers) and it enforces policy (you cannot read a file you lack permission for, you cannot exceed your memory limit). The rest of this domain is about what is behind each abstraction and how it fails, because when something breaks in production the abstraction is exactly what stops explaining the symptom.

Strictly, the kernel is the privileged program that does the arbitration: Linux, the XNU kernel in macOS, the Windows NT kernel. It runs in a protected CPU mode, it is entered only through system calls and interrupts, and it is the only thing that can program the MMU or a device register. When this domain says "the OS does X" it almost always means the kernel does X.

What you install and call "Ubuntu" or "Windows 11" is a distribution: the kernel plus a C library that wraps system calls (glibc, musl, msvcrt), an init system (systemd, launchd, the Windows Service Control Manager), a shell, package tooling, a window system and a few thousand user-space programs. Those are ordinary processes with no special privilege; ls is a process exactly like your server is. The line that matters for understanding behaviour is user mode versus kernel mode, not "part of the OS" versus "not".

This matters practically. Some behaviour you attribute to "the OS" is really the C library (e.g. malloc deciding whether to use brk or mmap, stdio buffering) or the init system (who reaps orphaned processes). When a symptom does not match the kernel documentation, check which layer you are actually talking to.

Every abstraction is paid for. Entering the kernel for a system call costs on the order of 100 ns to a microsecond of pure overhead before any work is done. Switching the CPU from one process to another costs roughly 1–5 µs plus the indirect cost of cold caches and a flushed TLB (see Context Switching). Translating every memory access through page tables costs a TLB lookup, and a TLB miss costs a page-table walk of several memory references (see The TLB).

Those costs are why systems engineering is full of batching: reading 64 kB per read() instead of 1 byte, epoll returning many ready sockets per call, io_uring submitting many requests per entry into the kernel, and thread pools that avoid creating a thread per task. Whenever a system is slow with idle CPU, one of the first questions is "how many times per second are we crossing the user/kernel boundary, and could we cross it less?".