Oh boy, yeah this topic. Hold on, we’re gonna go off the handle with this one…
“Wow did you see how fast the logo disappeared?”
Okay, while performance matters, I do think comparing boot times across any system is mostly pointless, mildly misleading, and occasionally hilarious.
Some folks love to draw comparisons between good ol’ retro consoles like the NES (yeah I’m going there!) and modern Linux, and maybe Android, based handhelds.
“The NES was instant! Why does my device take 15-30 seconds to boot?”
Of course the NES was instant. It’s a glorified microwave with a controller port. No kernel, no multitasking, no filesystem (as such). You chuck in a cartridge and it jumps straight into executing code. Instant boot wasn’t a feature, it was a byproduct of having literally nothing else going on.
Modern devices though? Well, for the most part, they’re tiny embedded computers. For most of these devices you’ve got:
- A multitasking kernel (sometimes running real time)
- Filesystems to check and mount
- Bind mounts to manage
- Networks to initialise
- Storage to verify
- Services to start
- and a bunch of other stuff to run so the device doesn’t throw a tantrum…
Even if most of that happens in the background, it’s not nothing. It’s a coordinated balance between hardware and software just to get to the point where the usable frontend starts. We want that to work reliably every single time and not just the one lucky boot when the mSD card didn’t blink wrong and collapse in a heap.
So if you’re holding a stopwatch and judging the entire firmware on its boot time alone, you’re missing the forest for the trees boot logs.
Let’s compare a classic pocket calculator to a smartphone? Both can do maths. The calculator is fast because it does one thing. The smartphone, and these Linux based handhelds, does many. That’s the point. Yes, I know there are more clever calculators out there, blah blah blah.
All of us working hard on muOS try our best to ensure a fast loading system and to optimise boot times, but we also balance that against system integrity, flexibility, and recoverability. If something breaks, we want to know about it before you start playing.
Next time someone tells you a certain firmware is “better” because it boots a few seconds faster, just smile and ask, “Does it also do everything else just as well?”. If you are genuinely keen on performance tuning, muOS and the development crew will fully support, and guide you, to better the community. Get your hands dirty, break stuff, and then improve it. Everything we have is on our GitHub repo here,
Until then, let’s all agree (and probably some disagree) that comparing boot times is fine for the most part, but geez, comparing them without context is like ranking cars based on how fast their doors close!
Funny? Sure.
Useful? Not really.