How a computer wakes up, and how it reacts to surprises

Waking up a very forgetful giant

A computer's memory (RAM) is like a whiteboard that gets completely wiped clean the instant power is off — nothing survives. So when you press the power button, the CPU wakes up into a completely empty room with absolutely no idea what an "operating system" even is. Booting is the story of how that empty room ends up, a few seconds later, running your entire desktop.

The boot process, step by step

1. Firmware wakes up first. A small, permanent program stored in a special chip (historically called the BIOS, on modern machines called UEFI) is hardwired to run the instant power arrives. It knows nothing about your OS — its only job is to do a quick hardware sanity check (called POST, power-on self-test) and then find something bootable.
2. The firmware finds a bootloader. It looks at your storage devices for a small program called a bootloader (examples: GRUB on Linux, the Windows Boot Manager) sitting in a known, fixed location, and loads that tiny program into RAM.
3. The bootloader loads the real kernel. The bootloader's whole purpose is to find the actual operating system kernel file on disk (which can be tens of megabytes — far too much for firmware to handle directly) and load it into memory, then hand over control.
4. The kernel initializes everything. The kernel sets up memory management, starts essential internal services, detects and initializes hardware devices (network cards, disks, etc.), and finally starts the first user-space process — on Linux this is traditionally called init (or systemd today) with process ID 1.
5. Init starts everything else. That first process is responsible for starting every other background service and eventually your login screen or desktop.

Power on → Firmware (POST) → Bootloader → Kernel → init (PID 1) → your desktop

Every step exists because each layer only knows how to load something slightly smarter than itself — firmware can't understand a full kernel, but it can understand a tiny bootloader, and a tiny bootloader can understand how to load a full kernel. This is a chain of increasingly capable programs bootstrapping each other, which is literally where the word "booting" comes from (short for "pulling itself up by its own bootstraps").

Once running, how does the OS react to the outside world?

After boot, the CPU is executing normal program instructions constantly — but the real world doesn't wait politely for the CPU to finish. A key is pressed, a network packet arrives, a disk finishes reading data. The OS needs a way to react to these events immediately, without constantly stopping to check "did anything happen yet?" (which would waste enormous amounts of CPU time). The mechanism for this is the interrupt.

An interrupt is a signal sent by hardware directly to the CPU, saying "stop what you're doing right now, something needs attention." When an interrupt fires:

1. The CPU immediately pauses whatever program it was running and saves exactly enough state to resume later.
2. It jumps to a specific function in the kernel called an interrupt handler (or interrupt service routine), looked up from a table of handlers, one per type of interrupt.
3. That handler does the minimum urgent work (e.g., "a network packet arrived, copy it out of the network card's buffer before it's overwritten").
4. The CPU resumes exactly where the original program left off, usually with no visible disruption at all.

Polling versus interrupts: the math of wasted effort

The alternative to interrupts is polling — the CPU repeatedly asking a device "are you done yet? are you done yet?" in a tight loop. Suppose a disk takes 10 milliseconds to complete a read, and the CPU checks every 0.01 milliseconds (a very tight poll) using 50 CPU cycles per check on a 2 GHz CPU:

$\text{number of checks during the wait} = \frac{10 \text{ ms}}{0.01 \text{ ms}} = 1{,}000 \text{ checks}$

$\text{cycles wasted purely on checking} = 1{,}000 \times 50 = 50{,}000 \text{ cycles}$

Every one of those cycles does zero useful work — it's the CPU equivalent of repeatedly asking "are we there yet?" With interrupts, the CPU instead runs other useful programs during that entire 10 ms wait and is only notified exactly once, the instant the disk is actually done, spending close to 0 wasted cycles on waiting. This is why every modern OS is built around interrupts rather than polling for anything that takes a noticeable amount of time.

Common mistakes

1. Thinking the kernel is loaded directly by the firmware. It's almost always loaded indirectly, through a small bootloader, because firmware is deliberately kept extremely simple and limited.
2. Assuming interrupts are rare. A busy computer fields thousands of interrupts per second — every keystroke, mouse movement, network packet, and timer tick generates one.
3. Confusing an interrupt with a system call. A system call is a program voluntarily asking the kernel for help; an interrupt is hardware forcing the CPU's attention, often with no program involved at all (like a timer or a network card).

A few more concepts worth knowing

• BIOS vs UEFI: BIOS is the older, simpler firmware standard limited to 16-bit code and small disks; UEFI is its modern replacement, supporting larger disks, faster boots, and secure boot.
• Secure boot: a UEFI feature that cryptographically verifies the bootloader and kernel haven't been tampered with before running them, refusing to run anything not properly signed.
• Interrupts vs exceptions vs traps: a hardware interrupt comes from an external device; an exception (or fault) comes from the CPU itself hitting a problem (like an invalid instruction); a trap is a deliberate, software-triggered interrupt — a system call is technically a trap.
• Maskable vs non-maskable interrupts (NMI): most interrupts can be temporarily disabled ("masked") during sensitive kernel code; an NMI cannot be disabled at all, reserved for truly critical events like hardware failure.

Summary

Booting is a bootstrapping chain — tiny, permanent firmware loads a small bootloader, which loads the real kernel, which starts every other service — because each stage can only understand something a little more complex than itself. Once running, the OS reacts to the real world through interrupts, hardware signals that immediately pause the CPU and jump to a handler, which is dramatically more efficient than constantly polling devices to check if they're done, wasting cycles on repeated "are you done yet?" checks that do no real work.