> Systemd-boot, any boot loader, that aims to replicate the things that the kernel does is ultimately going to run into the same problems as grub. We're going to have the font CVEs, we're going to have filesystem and storage and memory allocation bugs. All of that stuff is going to exist in whatever boot loader.
> Again, for an individual user, if you want to install systemd-boot, great, go ahead and use it. It's good, it works. But as a general option it's just going to have the same issues, unfortunately.
This is completely wrong though - the main point of sd-boot is that it does _not_ implement any of that - no filesystems, no fonts, no themes, nothing at all, the firmware is used to do all the risky stuff via the UEFI protocols. So it is very much not reimplementing what grub or the kernel do, the exact opposite in fact, it's the number one design goal.
Ahh ok so it sounds like systemd-boot's philosophy is keeping things simple and minimal and re-using UEFI firmware as much as possible, to minimize risks with the linux kernel having issues booting, at the expense of not having as many features.
I suppose then the hope is that nmbl would basically be a general-purpose fully-featured replacement for grub, which seems to be going in the direction of being a full kernel anyway:
> one with quite some bells and whistles, with networking, complex storage, cryptography, http client, ca store and stuff (I mean, that's how I understand it, i.e. it should be able to load kernels from sources that require all that). It hence will need require regular updating (as much as the 2nd stage kernel most likely, if not more often, since it probably needs ca store built in), and quite possibly will break every now and then nonetheless, because it's basically a full OS you are boot as first stage.
It sounds like if you don't need grub's complex features, then systemd-boot is probably the safest way to go, but if you do need grub's complex features, then nbml aims to be the safest and most reliable way to get those features.
This is completely wrong though - the main point of sd-boot is that it does _not_ implement any of that - no filesystems, no fonts, no themes, nothing at all, the firmware is used to do all the risky stuff via the UEFI protocols. So it is very much not reimplementing what grub or the kernel do, the exact opposite in fact, it's the number one design goal.