exactly like happened with systemd. all the complexity was ignored.. then bolted on. do you miss crontab -e?
my point is that the alternative to "crontab -e" is writting two files with 10~20 lines in difficult to remember paths. it's impossible to do without a webbrowser nearby.
Systemctl looks a lot like a modern init on another OS because a modern init on any OS looks a lot the same. Whether it should spawn 1800 subprojects is a different debate, but I for one am much happier maintaining trivial .ini like files than trying to teach the new engineer bash.
> The question is: that there are CVEs everywhere, we're not unique in this sense, and whether we would use systemd-boot.
> So, systemd-boot, it also works only on UEFI, and I believe that the plans are to keep it that way.
> Ultimately, the thing is that the kernel CVEs will get fixed no matter what, the question is: do we want to have more work fixing more CVEs. The kernel has a lot of developers, has very high visibility, and they're able to fix the CVEs in a reasonable time period. And, those aren't going to going to go away, the kernel CVEs aren't going to go away, whether we do this or not.
> 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.
> The lowest possible target for the rump kernel hypercall layer is firmware and hardware. This adaption would allow the use of anykernel drivers both in bootloaders and lightweight appliances. A typical firmware does not provide a thread scheduler, and this lack would either mandate limited driver support, i.e. running only drivers which do not create or rely on kernel threads, or the addition of a simple thread scheduler in the rump kernel hypervisor. If there is no need to run multiple isolated rump kernels, virtual memory support is not necessary.
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.
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.
- https://lwn.net/Articles/981149/
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.
> [grub] features create complexity that is difficult to maintain, and that both duplicate and lag behind the Linux kernel while also creating numerous security holes.
No mention of the alternatives. No mention how useful are those features. Handwaiving "security" arguments.
> Loaded by the EFI stub
All the talk about booting the kernel directly is moot, because by this they mean "we will use systemd-boot" ;)
IMHO, this is part of the RH wider push for PKCS11/TPM2/FIDO2 stuff. So it is not really fixing boot loader, as it is standardizing on their bootloader "as the correct one" but using the kernel reputation on the double speak.
Just like they pushed the equivalent of https://www.tenforums.com/attachments/tutorials/195499d15314... as the interface of init. (i'm not salty on systemd, in fact i already use bootd even. but if you cannot see how systemctl is the same UX as that, you are blind)