🧠 Operating Systems

What you’ll learn

1. Why an Operating System ExistsExplain why operating systems exist, and meet the illusion the rest of the course unpacks.Before operating systems, a computer ran one program at a time and idled while humans carried cards between jobs. The resident monitor removed the human delay; the question 'why not run job B while A waits?' created every hard problem in the field. The answer to all of them is one move: a layer of software that owns the hardware and hands out convincing fakes.
2. Two Worlds: User Mode and the KernelDescribe the user/kernel divide and the system call as the only door through it.The wall between programs and hardware is enforced by a privilege bit in the CPU, not by software. User-mode code cannot touch devices; it must trap into the kernel via a system call, which jumps to a fixed address the kernel chose. The kernel supplies mechanism, not policy — and every crossing costs enough that buffering and batching exist to avoid it.
3. Processes: Your Own Private ComputerDistinguish a program from a process, and read the process table as the illusion itemized.A program is a file; a process is that program in execution, wrapped in kernel bookkeeping — registers, page tables, open files, identity. Processes are Running, Ready, or Blocked, and on a real machine nearly all are Blocked and free. Unix creates processes with fork then exec, producing a tree descending from PID 1.
4. The Scheduler: Slicing Time Too Thin to SeeExplain how the scheduler multiplexes cores, and why throughput and latency cannot both be maximized.A context switch saves every register and restores another process's, so a program can be frozen and resumed without noticing — thousands of times a second. Policy decides who runs next, favoring interactive work; preemption via a hardware timer is what makes any policy enforceable. Every scheduler is a chosen point on the throughput-versus-latency tradeoff.
5. Threads, and the Bill Concurrency SendsExplain threads, race conditions, locks and deadlock as the cost of sharing memory on purpose.Threads share one address space so parts of a program can run at once, which reintroduces exactly the danger processes were designed to prevent. count = count + 1 is three steps, and interleaving two of them loses an increment. Locks fix races and bring their own costs: lost parallelism, and deadlock when two threads each hold what the other wants.
6. Virtual Memory: Your Own Private Address SpaceExplain virtual memory: pages, page tables, the MMU, and what the indirection buys.Program addresses are fictional and translated by the MMU through per-process page tables, so the same virtual address in two processes is two different frames. The indirection also buys per-page permissions, shared libraries mapped once into many processes, and copy-on-write — which makes fork affordable by copying pages only when someone writes to them.
7. When the Illusion Strains: Faults, Swap, ThrashExplain demand paging, eviction and thrashing as the illusion of infinite memory under strain.Virtual memory overcommits: a page may be a promise rather than RAM. A page fault is the mechanism working — the kernel supplies the page and restarts the instruction. When RAM is full, pages are evicted (cheaply if clean, at the cost of a write if dirty), and when working sets exceed RAM the machine thrashes: CPU idle, disk saturated, no work done.
8. Files: A Durable, Named World That Isn't ThereExplain how names, inodes and blocks conjure a filesystem, and why durability is a separate promise.A disk offers numbered blocks and nothing else. An inode holds a file's metadata and block list but not its name; a directory is a file mapping names to inode numbers — which explains instant renames, hard links, and deletion by reference count. Writes land in the page cache, not on the media, so durability requires fsync, and crash-safety requires journaling.
9. Interrupts: How the Machine Notices the WorldExplain interrupts, handlers, drivers and DMA as the way the kernel notices and serves the outside world.Polling devices would burn the machine, so devices interrupt the CPU instead: it saves state, runs a kernel handler, and returns. Nearly all kernel work is reactive — the timer drives preemption, the disk's completion wakes blocked processes — and an idle machine literally halts between interrupts. Drivers do this work in kernel mode, which is why their bugs are fatal, and DMA lets devices move bulk data without the CPU.
10. Boot to Login, and Where the Illusion LeaksTrace the boot chain, read everyday symptoms as seams in the illusion, and see the trick applied to itself.Firmware loads a bootloader, which loads the kernel, which starts PID 1 — each stage building enough world for the next. With the model in hand, everyday symptoms become diagnoses: beachball = blocked on I/O, silent freeze = deadlock, disk-pinned crawl = thrashing. Virtual machines apply the OS trick to an entire OS; containers are just processes with a narrowed view.

Questions this course answers

Grounded in trusted sources

• Silberschatz, Galvin & Gagne, Operating System Concepts (10th ed., Wiley, 2018)
• Arpaci-Dusseau & Arpaci-Dusseau, Operating Systems: Three Easy Pieces (University of Wisconsin, free online)
• Ritchie & Thompson, 'The UNIX Time-Sharing System', Communications of the ACM 17(7), 1974
• Intel 64 and IA-32 Architectures Software Developer's Manual, Vol. 3 — protection, paging, interrupts
• Linux man-pages project — fork(2), execve(2), syscalls(2), inode(7), fsync(2)
• Linux kernel documentation — scheduler (CFS), memory management, device drivers
• Denning, 'The Working Set Model for Program Behavior', CACM 11(5), 1968
• Multicians.org — F. Corbató, 'Compatible Time-Sharing System (1961–1973), Fiftieth Anniversary' (CTSS demonstrated November 1961)

Every Wunder lesson is built from real, reputable sources — never invented.

Related Science courses