Operating system concepts from boot to shutdown

Source: Every operating system concept in one video…, Fireship, 11:30, uploaded 2026-05-07, playlist index 49.

Fireship begins with the ordinary desktop as an improbably busy arrangement. A modern CPU may be running around 400 other programmes whilst Chrome uses 20 GB of RAM, yet the cursor still responds when the mouse moves. The operating system keeps that activity coherent by deciding which programmes may use the processor, which memory they can see, and how they reach hardware that they cannot touch directly.

The video follows that work from the instant electricity reaches the motherboard to the moment the machine shuts down. Its route passes through the bootloader, privilege rings, virtual memory, the filesystem, drivers, interrupts, processes, system calls, scheduling, threads, and inter-process communication. Fireship opens with GM-NAAIO, which General Motors shipped in 1956. That system could run one programme at a time on a large IBM mainframe. It had no memory protection, users, or files. The rest of the video explains the layers that let a current computer run many isolated programmes at once.

From firmware to the kernel

When the power button is pressed, the CPU wakes in a primitive state. It executes instructions from a hard-coded address in the machine’s firmware, before the computer has a memory manager or a concept of files. Modern machines use UEFI for this first step. Older machines used BIOS.

The firmware wakes enough hardware to locate a disk and then hands control to a bootloader. Fireship names GRUB, the Grand Unified Bootloader, for Linux, iBoot for macOS, and Bootmgr for Windows. Their shared job is to find the kernel on disk and load it into RAM. The CPU then runs kernel code with full hardware privileges.

At that point, the visible parts of the computer have yet to be made. Windows, files, processes, and application memory are arrangements the kernel builds after the handoff. The bootloader starts the kernel. The kernel constructs the world in which ordinary software can run.

Two privilege levels that keep programmes apart

The processor enforces the first important boundary. x86 chips provide four privilege levels, although the video reduces the working model to ring zero and ring three. The kernel runs in ring zero and can control the machine. Applications run in ring three, or user space, where they must ask the kernel for access to protected operations.

The distinction matters because kernel code has very little protection from its own mistakes. A bad pointer in the kernel can bring down the machine. A faulty application usually has a smaller blast radius because the processor prevents it from reading another application’s memory or issuing hardware operations by itself. The privilege ring therefore turns a process failure into a local failure in many cases. The kernel remains the trusted part of the arrangement, which is why a faulty driver can still crash the whole system later in the sequence.

Virtual addresses and pages

The kernel next creates virtual memory, which gives each process an address space that looks private and continuous. When a programme asks for an address, the address refers to a virtual location. The memory management unit, or MMU, translates it into a physical location by consulting a page table built by the kernel.

Memory arrives in pages, typically 4 kilobytes each. Every process has its own page table, so a browser and a password manager can use the same virtual address without pointing at the same physical bytes. The kernel can see across those address spaces whilst the applications remain separated. The MMU keeps recent translations in a translation lookaside buffer, or TLB, so it does not need to walk the page table for every access.

When a programme touches a page that is absent from RAM, the MMU raises a page fault. The kernel handles the fault, loads the page from disk, and resumes the programme. Fireship presents this as another useful fiction supplied by the operating system: software sees an address space that feels stable even though the physical memory behind it can move and pages can spend time on storage.

Files as names, metadata, and blocks

At the lowest level, a disk is a line of numbered blocks. A filesystem turns those blocks into files and folders. The kernel mounts the filesystem and uses its data structures to translate the familiar names into storage locations.

Fireship calls the central structure an index node, or inode. The inode stores metadata such as file size, permissions, and timestamps, along with a pointer to the data blocks containing the file. The file name lives elsewhere. Directories are special files that map names to inode numbers. That separation allows several names to point to the same underlying file.

The exact architecture depends on the filesystem. The video names EXT4, NTFS, and APFS, then focuses on journaling as a shared idea in modern systems. A journal records an intended change before the filesystem commits the data. If power disappears during a write, the system can use the journal to recover its intended state instead of treating every half-written block as final.

Drivers and the electrical interruption

Once memory and a filesystem exist, the kernel loads device drivers. A driver translates a general request from the kernel into the instructions required by a particular chip. The GPU, Wi-Fi card, and keyboard each need code that knows their hardware.

Drivers run in kernel mode. A defect in one can therefore damage the whole operating system, which is why graphics drivers often appear in Windows blue-screen failures. Fireship uses the 2024 CrowdStrike outage as a recent example of the reach of a bad low-level update, saying that the driver almost brought down the global economy. The claim carries the video’s scale and humour. It does not come with a supporting source in the description.

Drivers also let the kernel respond to hardware through interrupts. The keyboard sends an electrical signal when a key is pressed. The CPU pauses its current work and jumps to an interrupt handler in the kernel, which deals with the event. The same pattern lets the machine react to mouse movement or wake the network stack when a Wi-Fi card receives data. The operating system spends its time arranging work, whilst the hardware interrupts it when something needs attention.

PID 1 and the system-call boundary

The kernel eventually creates the first user-space programme, process ID 1. On Linux, Fireship identifies that programme as usually being systemd. A process is a running programme, and creating one requires the kernel to allocate memory, load an executable from disk, establish its virtual address space and page table, and add an entry to the process table.

PID 1 has a special role because it becomes the ancestor of every later process. If it dies, the kernel panics and the system goes down. It also runs in ring three. From this point, ordinary software has to request the kernel’s help through system calls.

A process cannot reach into a disk or perform a protected operation directly. It places arguments in particular CPU registers, runs a special instruction, and crosses from ring three into ring zero. The kernel performs the operation, then returns control to user space. That boundary is the practical security line between an application and the machine underneath it.

Fireship uses a C printing function as a rough example. A call that looks like ordinary application code can reach the write system call below the language library. Linux exposes around 400 system calls, and the video treats them as the computer’s underlying API. Libraries make that API easier to use. The fork and exec calls provide the basic process-building pattern that later produces the many programmes visible on a desktop.

CPU time, threads, and process communication

The running system soon has more processes than CPU cores. A scheduler decides which process receives processor time and when it must yield. Fireship describes the scheduler as an air-traffic controller for a busy airport, then names Linux’s current approach as earliest eligible virtual deadline first. The rules aim to give each process a fair share of the available CPU time while the machine switches between them quickly enough to appear simultaneous.

Some programmes need several activities to proceed within one process. Threads share the process’s memory and file descriptors, while each thread keeps its own stack and programme counter. This reduces the cost of creating separate processes and lets one programme work on separate tasks at once. Shared memory also creates race conditions when two threads update the same value at the same time.

The video points to Go’s goroutines and Rust’s borrow checker as language-level attempts to make threaded code safer. Rust can reject code that would allow a data race before the programme runs. The underlying operating-system arrangement remains shared memory, so the language can reduce a class of mistakes without removing the need to understand the shared state.

Separate processes need a different channel because their address spaces remain isolated. Fireship uses a Linux terminal pipeline as the concrete case. cat reads a file, and grep searches its output. The operating system creates a pipe that turns the output stream of one process into the input stream of the next. The processes exchange bytes without sharing their memory.

Pipes date to 1973 in the video’s account. Sockets and message queues provide other forms of inter-process communication, yet the common purpose stays the same: the kernel mediates a controlled exchange between programmes that cannot simply write into one another’s address spaces.

The orderly violence of shutdown

Fireship calls the shutdown sequence stage 10, even though IPC already received that label. PID 1 sends SIGTERM to each process first. The signal gives programmes a chance to save their state and stop cleanly. After a timeout, the system sends SIGKILL, which ends processes that remain alive.

The filesystem flushes its journal and unmounts. Drivers release their hardware. The kernel synchronises memory to disk and disables interrupts. The CPU halts, power is cut, and the screen goes black. The machine can return to its primitive pre-boot state because the kernel has dismantled the arrangements that made the running desktop possible.

Limits of the walkthrough

This is a compact teaching sequence rather than a complete account of any one operating system. Fireship moves between Linux, macOS, Windows, and general x86 ideas, so examples such as GRUB, systemd, EXT4, and the Linux scheduler describe particular systems inside a wider explanation. The video compresses details that matter in practice, including the exact boot path on current hardware, page replacement and storage layers, filesystem recovery rules, driver trust, scheduler configuration, and the difference between concurrency and parallel execution.

The historical and numerical claims remain claims made in the video. The description provides the topic list and sponsor links, yet it gives no citations for GM-NAAIO, the 400-programme estimate, the CrowdStrike example, the 1973 pipe date, or the scheduler description. The durable lesson comes from the sequence itself: the operating system builds boundaries, translates between abstractions, responds to hardware, and mediates every transition from a running programme to the machine beneath it.