This is a great write up and was really interesting to read.
My question is why would the proposed changes are not already included upstream?
Isn't a faster boot what everybody wants?
Yes, but glancing quickly at the article some solutions are not generally acceptable, such as moving filesystem processes to the application code. If you have a RPi project where you plan to run a single Qt app then you can do stuff like this, but that is generally speaking not the use case.
> My question is why would the proposed changes are not already included upstream?
Because these changes remove networking, USB support, sound, debugging support, and even the entire init system. It's useful if you need to boot into a single, simple app without networking or USB as fast as possible, but it's not useful for general purpose computing.
Lazy troll is lazy. I like that my Linux-based head-unit comes ready 3 seconds after starting the car, so the volume control works, and if I was listening to a simple input like the broadcast tuner at the last shutdown, it returns to that and I've got music right away. It takes a little longer for maps to render, and longer still for the Bluetooth module to load, but that's okay. Delaying simple functions until all the most complex stuff had loaded would be a terrible UX.
I’ll rather have slow boot and proper UEFI support so I can boot any vanilla ARM64 Linux distro (Debian proper), instead of images/distros which have been crafted to be device-specific (Raspbian).
I boot this thing once every second month at most. I honestly couldn’t care less about boot-times.
Luckily for me, there are solutions to my problem too ;)
Incidentally, I have used this for for the ESXi Fling for the Pi when benchmarking it against KVM performance (for those curious, KVM far outperformed ESXi), but I heard that it doesn't work as well for Linux distros (some hardware was broken last I heard [a few months ago]).
But yeah, I agree that getting UEFI support and standardising the ARM boot procedure is very useful for all of us.
Yes, but glancing quickly at the article some solutions are not generally acceptable, such as moving filesystem processes to the application code. If you have a RPi project where you plan to run a single Qt app then you can do stuff like this, but that is generally speaking not the use case.