What an operating system actually does

A program never talks to a hard disk, a network card, or the CPU's scheduler directly — it talks to the operating system, which mediates every one of those interactions. This isn't an implementation detail; it's the entire reason multiple programs can run at once on one machine without each one needing to know the others exist, or without one program's bug corrupting another's memory.

Modern CPUs support at least two privilege levels. User space is where your normal programs run — they can't directly touch hardware or read another process's memory. Kernel space is where the operating system's own core code runs, with full hardware access. This separation is a deliberate security and stability boundary: a bug in a normal program can crash that program, but it can't (in a correctly designed system) crash the whole machine or read another program's secrets, because it never had the privilege to touch that hardware or memory directly in the first place.

When a program needs something only the kernel can do — reading a file, opening a network connection, allocating more memory, creating a new process — it makes a system call: a controlled, well-defined request that temporarily hands control to the kernel, which performs the privileged operation and hands control back. read(), write(), open(), fork(), and mmap() are all system calls under the hood, even when a higher-level language wraps them in a friendlier function name. Every "impossible for user code to do directly" operation goes through this same narrow, controlled door.

Nearly every confusing production bug that isn't a straightforward logic error — a mysterious slowdown, a memory leak, a "works on my machine" file permission failure, a deadlocked service — traces back to one of these four resources being managed, contended for, or exhausted in a way the application code didn't anticipate. Understanding what the OS is actually doing underneath turns those bugs from mysterious into diagnosable.