On system startup, the CPU begins executing from the EFI ROM - a few-megabyte chip on the motherboard somewhere. The EFI is essentially a simple (won't say small) OS: it can enumerate devices and partitions, mount filesystems, draw graphics, and connect to the internet (shudder). It provides APIs for these capabilities to the loaded EFI executables. EFIs are either 32-bit or 64-bit so its boot code must switch from real mode at some point.
After handling whatever system initialization, the EFI looks through the connected disks in the order configured by the user, searching for an EFI system partition. This partition is FAT32 and has a special GPT partition attribute to mark it. These partitions are usually 100-500MB and are usually the first partition on the disk. If found, the EFI mounts this partition.
At this point, the boot process depends on the value of various EFI variables, which you can inspect with the `efivar` command on linux. These instruct the EFI bootloader to load various EFI executables, which are PE-format but otherwise fairly normal. First it will load any drivers specified by the `Driver####` and `DriverOrder` variables, which could be used to enable the EFI bootloader to load from e.g. a RAID controller or a BTRFS partition. I haven't seen this used in practice, however. Next it will run an executable specified by a `Boot####` variable, depending on the `BootNext` or `BootOrder` variables or a user-selection at the EFI boot menu. These EFI applications are stored in vendor-specific directories of the EFI system partition like `/EFI/Fedora/shimx64.efi`. These applications are usually either an EFI shim which executes a traditional bootloader, or a traditional bootloader compiled as an EFI application. EFI could also be used to directly boot a kernel, such as linux compiled with EFISTUB enabled.
If the EFI isn't able to boot any of the registered entries, it will usually run the EFI Shell (if installed) or try to run whatever is at `/EFI/BOOT/bootx64.efi`.
My (perhaps overly simple) conclusion is that the boot process is doing stuff it doesn't need to do.
Is it? Not in my experience running Debian.
Although, hibernation does have the advantage for magnetic disks of being a single file that can be read sequentially, rather than a bunch of files scattered throughout the disk. But I believe certain tools can help with that, by profiling and optimizing those accesses at boot time.
Which is also true in 99% of cases when I boot.
Problem is, you can't utilize those shortcuts when doing a completely cold boot. Like another commenter said, in that case most of the boot time is preparing hardware.
Parent seems to confuse two different kinds of boot. The one discussed in the article concerns itself with getting the OS loaded and beginning to execute that. Traditionally, this is where booting ends. But you OS still needs to do a lot of work, starting services, loading widgets and helpers and Bonzi Buddy etc. It's perhaps debatable if this can still be considered part of the boot process, since the OS is loaded and executing user space code, but it's certainly part of the startup process. I believe this is the process parent is referring to.
I'm using Firefox