The real problem is linux is just a kernel - they cannot force you to have good hardware. If you want fast boot you need to start with the hardware: a lot of hardware has an long init sequence so there is no way the kernel can boot fast as it cannot boot until that hardware is initialized. Then you can look at the kernel, step one is strip out all the drivers for that slow to init hardware you don't have (since those drivers have to insert waits into the boot while they check for the hardware you don't have). If you do this you can save a lot of boot time.

Of course in the real world the people who select your hardware don't talk to the people who care about software. So you are stuck with slow boots just because it is too late to go back and do a fill million dollars each board re-spins now that we know our boot times are too slow.

It gets worse, even if you select fast init hardware that doesn't mean it really is fast. I've seen hardware that claims to not need long inits, but if you don't insert waits in the boot there are bugs.

At least on my completely unoptimized desktop, majority of boot time is already spent in UEFI firmware, not in kernel or userspace startup. So realistically there is limited opportunity to optimize the boot times.

That's not what I'm doing. I'm saying if your distro, your hardware, or your setup takes significantly more time, examine why. The hardware part is tough because we're effectively locked into whatever is cheap on the market, everything else is 100% fixable. Fast booting is not really a hard problem, especially in embedded where you know & control the hardware.

Ah I see where you're coming from. I don't see any reason to expect that's the case here though. Package management has some fairly obvious tough CS problems inherent in it -- dependency resolution with version upgrades inherently feels NP-hard, for example. Whereas booting is about making hardware that initializes quickly and then making software that abstracts over a variety of hardware well... within the development budget you have. And then you're stuck with backward compatibility as everything changes. I could be wrong here but it feels like a costly engineering problem more than anything else.

(Note I'm not saying you can't do a PhD in it and improve the situation -- you could probably do that for any problem, honestly. Just saying that I think you could get most of the way there by just paying the engineering cost.)