the boot sequence
When you press the power button, the computer faces a chicken-and-egg problem: the operating system that runs everything is itself just a file on a disk, and nothing has loaded yet to read that file. The boot sequence is the carefully staged chain of small programs that solves this - each stage just capable enough to find and start the next, larger stage, until finally the full kernel is in memory and running. The word 'boot' comes from 'pulling yourself up by your bootstraps,' which is exactly the trick: the system lifts itself into existence one rung at a time.
On a modern PC the rungs go roughly like this. First, firmware burned into a chip - today usually UEFI (older systems used a BIOS) - runs the moment power is stable; it tests the hardware and knows how to read a disk. The firmware loads a bootloader (such as GRUB), a slightly larger program whose job is to find the kernel, often stored compressed to save space, load it into memory, decompress it, and jump to its entry point. The kernel then takes over: it initializes the CPU into its full mode, sets up memory management, page tables, interrupts, and the scheduler, and probes and initializes devices. Finally the kernel starts the very first user-space process, traditionally called init and given process ID 1 (PID 1); systemd is a common modern init. PID 1 then launches all the services and login prompts you actually see.
Why this matters beyond trivia: almost every 'it won't boot' problem maps to a specific failed rung - bad firmware settings, a bootloader that cannot find the kernel, a kernel that panics during device init, or PID 1 failing to start. Knowing the chain lets you reason about where in the climb things broke instead of treating startup as one opaque event. The same staged idea reappears on phones, servers, and embedded boards, just with different firmware and bootloaders.
power on -> UEFI firmware -> bootloader (GRUB) loads + decompresses the kernel image -> kernel init: CPU mode, page tables, interrupts, scheduler, drivers -> exec /sbin/init as PID 1 -> services + login.
Each rung is just powerful enough to start the next, until the kernel is running and launches PID 1.
PID 1 is special: the kernel keeps it for the machine's entire life, it adopts orphaned processes, and if it ever exits the kernel panics because the system has no first process to fall back to. So 'init' is not just the first program - it is a process the kernel structurally depends on.