Boot to Shutdown: Every Operating System Concept from Fireship's 15-Minute Video

You use an operating system every single day. But have you ever stopped to think about what actually happens in that gap between pressing the power button and your first program lighting up on screen? There's a whole sequence of events happening in there, and most of us treat it like a black box. Today, we're going to open that box.

There's a Fireship video that pulls off something pretty clever. It takes every major operating system concept — the kind of stuff textbooks spread across dozens of chapters — and compresses it into about fifteen minutes. And the trick that makes it work is the narrative spine: it follows a computer's life from power-on to shutdown. Each stage of that journey maps onto a specific piece of the OS. So that's exactly the path we're going to walk today.

Let's start with the big picture. What even is an operating system? At its heart, it's the software layer sitting between your applications and the raw hardware. And it has four core jobs. First, resource management — deciding who gets CPU time, how much memory each program gets, which chunks of disk go where. Second, isolation — making sure that when one program crashes, it doesn't drag the whole machine down with it. Third, abstraction — so your app doesn't need to know which exact CPU model or disk format it's running on. And fourth, providing an interface — a standard set of APIs that applications can reliably build against.

Now, why does any of this matter? Well, imagine a world with no operating system. Every single app you write would have to handle its own CPU scheduling, its own memory allocation, its own hardware drivers. That's practically impossible. The OS absorbs all that complexity so developers can just focus on their actual application. And once you understand what's happening underneath, you become a genuinely better systems programmer. You start to understand why forking a process is cheap but exec is expensive, why a thousand tiny files are slower than one big file, why context switches quietly become performance bottlenecks. So let's follow the machine from boot to shutdown.

It all starts the instant you press the power button. And here's the first surprise: the very first thing your CPU runs is not Linux, not Windows. It's firmware — a low-level program burned right into a chip on the motherboard. Modern machines use something called UEFI; older ones used BIOS. And firmware has a specific to-do list. It runs the Power-On Self Test, or POST, which is basically the machine checking its own pulse — is the CPU okay, is the RAM there, is the storage responding? Then it initializes the hardware devices, and finally it goes hunting for the bootloader to hand off control. UEFI, by the way, was a big leap over the old BIOS. It handles disks bigger than two terabytes, it gives you a graphical interface, and it enables Secure Boot.

So firmware finds the bootloader sitting on your boot disk — on Linux that's usually GRUB — and passes the baton. And the bootloader has exactly one job, but it's a crucial one. It reads the operating system kernel image off the disk, loads that kernel into RAM, and then transfers control over to it. That's it. It takes a few seconds, and it's really the bridge between the world of firmware and the world of the operating system proper.

And now we arrive at the kernel — the beating heart of the OS. The kernel runs in what's called kernel mode, which means it has direct, unrestricted access to all the hardware. Everything from here on out lives under the kernel's roof: process management, memory management, the file system, device drivers, and the system call interface. Now, there's an interesting design distinction here. Linux is what we call a monolithic kernel — all of those subsystems share one single memory space, which makes calls between them lightning fast. macOS, on the other hand, uses a hybrid kernel called XNU, where some components run out in user space instead, trading a bit of speed for extra stability.

Once the kernel is up, it starts creating processes. Think of a process as an independent instance of a running program. Each one gets its own virtual address space, its own set of open files, its own process ID, and at least one thread of execution. The magic here is isolation — processes are walled off from each other, so if one crashes, it doesn't directly kill the others. Now, within a process you have threads, and these are the actual units of execution. All the threads inside one process share the same memory, which makes them super efficient for working together on a task — but, and this is important, that shared memory means you need locks to stop them from stepping on each other's data.

Here's the thing, though. Your machine might have dozens of processes all claiming to run at the same time, but you've only got a finite number of CPU cores. So who actually gets to run? That's the scheduler's call. Modern schedulers are preemptive, which means they can forcibly pause a running process mid-execution and hand the CPU to someone else. Each process gets a time slice — usually just a few milliseconds per turn. And there's priority in the mix too: real-time stuff like audio playback or handling your keyboard input jumps ahead of background chores. Linux uses something called the Completely Fair Scheduler, and I love how it thinks about this. It tracks how much "virtual runtime" each process has racked up, and it always picks the one that's run the least. The result? No process ever gets starved out and left waiting forever.

Next up, memory. Here's a beautiful bit of illusion: every process thinks it has its own private address space. It's not looking at real physical memory addresses at all. The OS pulls this off with paging — it maintains a mapping table that translates those virtual addresses to actual physical page frames in RAM. And this design buys you three great things. One, isolation — process A physically cannot peek into process B's memory, even on the same machine. Two, demand paging — the OS only hands out physical memory when a program actually touches it, which makes startup faster. And three, swap — when RAM fills up, the OS quietly moves the least-used pages out to disk to make room for what's active right now.

But wait — if processes are all isolated from each other, how do they ever cooperate? That's where inter-process communication comes in, and the OS offers a whole toolbox. There are pipes, which send data one direction between a parent and child process — that's literally what's happening when you pipe one command into another in your terminal. There are Unix sockets for two-way local chatter. There's shared memory when you need to move a lot of data fast. There are signals — lightweight little pokes, like SIGTERM asking a process to please shut down, or SIGKILL, which is the non-negotiable version. And there are message queues for passing messages asynchronously. Different tools for different conversations.

Now let's talk storage. To your applications, everything persistent is just a "file." And the OS keeps that illusion consistent through the Virtual File System, or VFS. Underneath, the actual storage could be ext4, or APFS, or NTFS, or a RAM disk, or a network file system — but the API looks identical to your app no matter what. Linux takes this idea to an almost philosophical extreme with "everything is a file." Your hardware devices show up as file paths. Live information about a running process shows up as a file you can read. Even kernel settings are just files you can write to. One single, consistent interface for the entire system. It's elegant.

Okay, but here's a wall your applications keep running into. They live in user mode, and user mode is not allowed to touch hardware or kernel data structures directly. So any time an app needs the OS to do something real — read a file, open a network socket, spawn a new process — it has to make a system call, which flips the CPU over into kernel mode. These are the workhorses: open to get a handle on a file, read to pull data in, write to push it out, fork to clone the current process, exec to swap in a whole new program, exit to shut down and give back resources. And here's the catch — every single one of those syscalls involves flipping from user mode to kernel mode and back, and that switch has a real, measurable cost. That's the whole reason high-performance I/O frameworks like epoll and io_uring exist. Their entire design goal is to make fewer syscalls. Oh, and if you ever want to spy on exactly what a program is asking the OS to do, there's a tool called strace that intercepts these calls and shows them to you live. Point it at a command and you can literally watch every file it opens and every byte it reads.

So let's zoom out and see the whole arc as one flow. You press the power button. Firmware — UEFI or BIOS — wakes up and checks the hardware. It hands off to the bootloader. The bootloader loads the kernel. The kernel spins up its two great pillars, process management and memory management, plus the file system. Out of that, your user processes come to life. And whenever those processes need something privileged, they reach back down through a syscall into the kernel. That's the entire lifecycle in one clean line.

Before we wrap, there's one comparison worth making, because people get this wrong all the time — how an OS differs from virtual machines and containers. A regular operating system runs its own kernel, isolates programs at the hardware level, boots in seconds, and has low overhead. A virtual machine also runs its own full kernel, but it isolates through a hypervisor, can take seconds to minutes to boot, and carries heavy overhead. A container is the odd one out: it does not have its own kernel — it shares the host's kernel. It isolates using Linux cgroups and namespaces, boots in milliseconds, and has almost no overhead. So here's the myth to kill: containers are not tiny lightweight VMs. They're just isolated processes sharing the host kernel — cgroups cap their resources, namespaces limit what they can see. And that, by the way, is exactly why Docker on a Mac or Windows machine secretly runs a Linux VM underneath. Neither of those systems ships a Linux kernel, and containers need one.

So let me leave you with the three ideas worth holding onto. First: the operating system is not a mysterious black box — it's a clear, logical chain. Firmware initializes the hardware, the bootloader loads the kernel, the kernel establishes process and memory management, and processes reach the OS through syscalls. Second: every single layer exists to solve one specific problem. Firmware abstracts away hardware variation, the kernel abstracts away resource contention, the VFS abstracts away storage backends, and the syscall interface abstracts away the jump into privileged mode. And third, the payoff: once you can see this abstraction chain, you stop treating your computer as magic. You can actually reason about why your program behaves the way it does, right down at the level of the machine. And honestly, that's the difference between someone who just uses a computer and someone who truly understands one.