Part 1 — What an operating system actually does

Lab set up, learning flow read — time to start. Before processes, memory, or any specific subsystem: what is an operating system actually for, and why does it need to lie to every program running on it? Everything in the next fifteen parts is a specific instance of that lie and the machinery that maintains it.

Chapter 1 — The OS as a resource manager and a liar

In one sentence

An operating system's whole job is to let many programs share one computer's hardware safely, by pretending to each program that it has the machine to itself.

Why this matters

Every "why is my server slow" investigation, every container resource limit, every "noisy neighbour" incident traces back to this one idea: programs don't actually get dedicated hardware — they get a convincing illusion of it, arbitrated by the OS, and that arbitration can go wrong or run out.

How it actually works

   WITHOUT AN OS: your program would need to know EXACTLY which physical
   RAM address is free, EXACTLY how to talk to this specific disk
   controller, and EXACTLY how to avoid another program overwriting its
   memory at the same instant. Every program would need to be its own
   tiny operating system. This was, roughly, how computing worked before
   the 1960s-70s: one program, one computer, no sharing.

   WITH AN OS, three lies are told to every program, consistently:
     1. "You have the CPU to yourself."
        (Reality: the scheduler, Chapter 8, is switching between you and
         every other runnable program many times per second.)
     2. "You have a huge, private block of memory, starting at address 0."
        (Reality: virtual memory, Chapter 10, maps your program's private
         address space onto scattered, shared physical RAM -- and part of
         it might not even be in RAM right now.)
     3. "Files and devices are just streams of bytes you can read/write."
        (Reality: a "file" might be on a spinning disk, an SSD, a network
         share, or not even really exist, like /dev/random.)

   The OS maintains these lies by being the ONLY thing with direct
   hardware access (Chapter 2) and mediating every request. This is what
   "operating system" means: it OPERATES the hardware ON BEHALF of every
   program that wants to use it.

Real-world example

   Open a modern browser and look at your process list (Chapter 31) --
   Chrome alone might show 50-150 separate OS processes for a browser
   window with a handful of tabs. Google's own engineering documentation
   explains this was a DELIBERATE architecture decision: each tab (and
   each extension, and the browser UI itself) runs in its OWN OS process,
   specifically so the OS's process-isolation guarantee (Chapter 4) means
   one crashed or malicious tab can't read another tab's memory or bring
   down the whole browser.
   This is "the OS as resource manager" used as a SECURITY boundary, not
   just a performance one: Chrome is deliberately paying the OS's process-
   creation and context-switching cost (Chapter 9) in exchange for the
   isolation guarantee only the OS can provide. You'll see this exact
   trade-off again with containers in Phase 3 -- isolation has a cost, and
   engineers pay it on purpose, constantly.

Try it yourself

# See how many processes are "really" running on your machine right now
ps aux | wc -l

# Watch the illusion of "you have the CPU to yourself" break down --
# start a CPU-heavy loop, then watch top show it competing for time
yes > /dev/null &
top    # note the %CPU for the `yes` process; press 'q' to quit
kill %1   # stop the background job

Common mistakes

"More cores means my single-threaded program runs faster." A program using one thread can only ever use one core at a time, no matter how many cores the machine has (Chapter 7 explains why, and when more cores DO help).
Thinking "virtual memory" means "not real." It's real memory your program can actually use — "virtual" describes the ADDRESSING scheme, not whether the memory works (Chapter 10).
Assuming isolation is free. Every layer of isolation (processes, containers, VMs) costs CPU and memory to maintain. More isolation is a trade-off, not a free win.

Check yourself

Name the three "lies" the OS tells every program, and what's really happening behind each one.
Why couldn't programs safely share a computer before operating systems existed?
Why did Chrome's engineers choose a multi-process architecture, and what did they pay for that choice?

(Answers: Appendix E.)