> Booting linux directly just boots you into that install. It doesn't give you a boot menu or any of the other functionality GRUB provides. This project is basically proposing building that in a small initramfs userland instead
I indeed understood that part, but their motivation for this was security. If you want security, you should want to boot directly into the kernel. And if you're the occasional user who has multiple OSes installed in parallel... you can just add more kernels from your dual-boot installs directly to the UEFI screen; there's really no need to go through any form of intermediate stage, whether kernel-based or boot-loader-based.
What I'm trying to say is: as cool as this is from a technical standpoint, I just don't understand the root of the premise or motivation here whose optimal solution is this approach. Whom is RedHat trying to please with this? The small fraction of users who dual-boot Linux, or the rest of the users who just have a single install? And what problem are they actually trying to solve -- security, performance, or something else? Because the optimal solution to the first two doesn't feel like this one, unless they're targeting a niche use case I'm not seeing? e.g., do they have lots of enterprise users that boot off a network, but whom would rather have a local Linux install whose sole job is to boot that...?
They have to cater to a pretty wide set of users, and deal with a wide array of hardware and scenarios. UEFI, especially whatever random implementations of UEFI their users have, can't cover all of it. Addressing those needs currently requires something like GRUB (or a customised initramfs, which would be my preferred solution, but it requires more know-how), but GRUB effectively has to duplicate a large subset of the work that the kernel does, and inevitably (if only due to lack of resources), does so poorly, hence their argument that this is good for security: it's better than the status quo of GRUB. Indeed, if you have a UEFI firmware and it supports your use case, and it's well implemented, then this project is of no extra use (though it seems designed to just get out of the way in that situation and more or less just boot directly), but Red Hat's userbase does not entirely consist of people who are in that situation.
I indeed understood that part, but their motivation for this was security. If you want security, you should want to boot directly into the kernel. And if you're the occasional user who has multiple OSes installed in parallel... you can just add more kernels from your dual-boot installs directly to the UEFI screen; there's really no need to go through any form of intermediate stage, whether kernel-based or boot-loader-based.
What I'm trying to say is: as cool as this is from a technical standpoint, I just don't understand the root of the premise or motivation here whose optimal solution is this approach. Whom is RedHat trying to please with this? The small fraction of users who dual-boot Linux, or the rest of the users who just have a single install? And what problem are they actually trying to solve -- security, performance, or something else? Because the optimal solution to the first two doesn't feel like this one, unless they're targeting a niche use case I'm not seeing? e.g., do they have lots of enterprise users that boot off a network, but whom would rather have a local Linux install whose sole job is to boot that...?