| Honestly, I think a lot of the parts that people complain about aren't actually as complex as they seem - but they are the surface visible parts. And lack of knowledge and nostalgia glasses sometimes make people unaware of how complex things used to be. A lot of underappreciated thing with boot firmware these days is that what is presented to you as end user is absolutely not connected to what options are actually possible. Also tons of complex and quirky code just to get the CPU and memory to the point of running other code. IIRC there's bits of code spanning early CPU reset and intel IME that are necessary to prevent the CPU from destroying itself, at least on some models. Similarly on AMD PSP. Some of them will be disabled because the hw physically doesn't support them, or can result in weird behaviour that isn't going to be something you like, or effectively brick things. Another part is that it allows real proper modularity of an open platform, at least on the vendor side. Add a new device that requires special driver? No longer you have to spend a long time just to integrate a blob, there's a standard API/ABI whether the driver is closed or open source. ACPI provides tons of ways to just specify the details of where something is and how to connect it. I love a lot about openpower, but PetitBoot is effectively less open if only because there's no possibility to use add-in card requiring drivers that wasn't already compiled into flash. With UEFI it works. UEFI is honestly in many ways less complex than previous systems (no more hooking into tape drive boot sequence), especially since there's much less that needs to be in SMM block except for things required by hw (an example: some CPUs required SMM code for changing certain power levels, because the OS level API doesn't expose the low-level details like enforcing a synchronization point on all CPUs or low level internal registers). If you use UEFI, you also don't need to implement whole complex (and IBM PC incompatible) craziness that is GRUB (or NTLDR with its ARC firmware emulation, or non-UEFI WINLDR which emulates chunk of UEFI...) - n.b. the last linux bootloader that properly handled IBM PC compatibility was LILO if installed in appropriate way (read: not how distros did it). TPM and Secure Boot are reasonably easy parts of the whole thing. NFC and smartcards are also things that are reasonable for single engineer to grasp. There's less visible, though some people remember about it, complexity that is enforced on us by corporate interests - big part of why AMD PSP is closed source is the same reason AMD was unable to open source some of the HDMI code recently - both AMD PSP and Intel IME are part of implementing "Secure Media Path", aka DRM bullshit for MPAA (HDCP and its DisplayPort equivalent). It's also why various DRM systems don't fully support fully open systems (for example normal linux distros, not ones that are built by vendor of a device with special blobs) Now, systemd I'll agree it takes a good idea but does with horrible implementation, and that's from someone who gave in and tries to use it fully (mainly because I have no time to implement an alternative). Wayland also makes in many ways life more complex than X11, OTOH XFree86 legacy of being lowest common denominator implementation even after reverting to X.Org means that people felt stuck. |