Operating Systems book cover

Your technical library

Operating Systems

25 modules · 149 topics

About this book
Concepts · Operating Systems

Operating Systems

This course teaches what actually happens underneath your code — when a process starts, a thread blocks, memory runs out, a file is "saved", or a container boots — from the bare processor up, so that you can reason about performance, debug a production incident at the kernel boundary, and argue a design choice (threads or processes, epoll or io_uring, a journal or copy-on-write, a VM or a container) with mechanisms and numbers rather than folklore. By "the operating system" it means, above all, the kernel — the one program with full authority over the hardware; the shell, libraries, daemons and desktop shipped with it appear only as programs that use the kernel. It is written for a working software engineer who uses Linux, Docker, threads and async every day but was never taught what lies beneath them. No operating-systems course is assumed, and nothing is used before the topic that teaches it. It builds on three other courses on this site: Data Structures (trees, queues and ring buffers the kernel is built from), System Design (the latency numbers and logs it assumes) and, where probability appears, Mathematics. Roughly a third of the original course — the internals a staff engineer meets when the illusion is the bug — now lives in the companion course Operating Systems in Depth; topics this course opens but leaves to it are named as they come up.

An operating system sells three illusions — every program has the processor to itself, has memory to itself, and has storage that survives crashes — and keeps one promise: that one program cannot harm another. The course builds each from the problem that forces it. The machine beneath the operating system opens with a map of the whole computer — its hardware, the layers of software on it, and where the operating system sits — then gives the minimum hardware picture, in plain words: instructions, the call stack, caches and multiple cores. The kernel boundary adds privilege, traps, system calls and interrupts, and shows how programs run at full speed without escaping control. Processes and CPU scheduling build the first illusion: the kernel's record of a running program, fork, exec, signals, sessions and threads, and the policies — up to Linux's EEVDF — that decide who runs next on which core.

Address translation, memory beyond RAM and the memory API and kernel allocators build the second illusion: page tables and TLBs, demand paging and replacement, swap, the OOM killer, mmap, copy-on-write, and how malloc works. Program loading applies all of it end to end — the linker that builds an executable, then the kernel that maps it into a fresh address space. Races and locks, waiting and deadlock and scalable concurrency teach what goes wrong when executions share memory and how to make it right, from atomic instructions and futexes to deadlock. Inter-process communication connects processes through pipes, shared memory and sockets.

The third illusion runs from devices and drivers and storage devices and the block layer through files and directories, the page cache and durability (including exactly what fsync promises) and file system implementation, to crash consistency — fsck, journaling and the contract applications build on it. The applied modules then take the kernel as you meet it in production: event-driven and asynchronous I/O (epoll and the event loop), observing the kernel (load average, profilers and method), protection, virtual machines and containers, followed by distributed file systems. The course closes with case studies that trace one boot, one read() and one accepted connection through everything before. Along the way each topic says what it inherits, what it leaves open — naming the Operating Systems in Depth topic where one answers it — who designed the idea and when, and how it shows up in decisions engineers make.

149 of 149 topics are authored. Read in dependency order. Planned lessons are labelled and excluded from progress; references cover authored material.