Your reply indicates a similar software-centric focus, which I've come to realize is one of the flaws to the article. LinuxBoot is nifty in that it replaces all

Your reply indicates a similar software-centric focus, which I've come to realize is one of the flaws to the article. LinuxBoot is nifty in that it replaces all those UEFI chunks that no one spent time bothering to make fast, but guess what? I'm looking at an embedded system I have in hand and the Linux part, with a minimalist u-boot and fixed hardware, still takes over 3 seconds to transfer control to init. Assuming you've laid out your memory layout to fixed storage and your bootloader just tosses it in RAM as fast as possible, what else needs to happen? The hardware needs to be ready to initialize and then get initialized. This isn't trivial, fast, or resolvable solely by getting better about software. Waiting for inrush currents to stabilize takes time. Waiting for a component to signal its readiness for firmware and initialization takes time. Firmware downloads frequently take on the order of hundreds of milliseconds, if not seconds. One can, in theory (and sometimes in practice) deal with this by being clever about timeslicing and never spinning, but even then. Many systems have some peripherals queried by I2C; even at 400kHz, the maximum I2C speed, you aren't going to be able to shove mass quantities of data, let alone if you need to act on any results from a read. Humorously, I just realized I neglected the time to initialize said RAM with the appropriate settings. Glancing over at a help forum for the Snapdragon 820, it looks like the initial RAM setup takes 18ms and it's waiting for the DDR for what looks like the better part of a second, which makes it awful hard to continue doing other things. None of that can just be changed by the folks doing software. Certainly Microsoft tried -- many of their boot improvements have been making boot more like resuming from hibernation, and it still takes time to boot. Yes, we've built our towers of abstraction a bit high, and yes folks tend to throw threads at things and hope it fixes our throughput issues -- but there are also fundamental failures to understand that the abstractions are abstracting away real-world aspects.