A lot of the commentary here is based on misunderstandings of the capabilities and constraints of a UEFI environment and what the actual goals of this project are, and I think miss the mark to a large degree. Lennart's written some more explicit criticism at https://lwn.net/Articles/981149/ and I think that's a much more interesting set of concerns.
I have to say I find Lennart's arguments quite unconvincing. As another person said, the vast majority of people just want default boot to the most recent kernel (which this proposal could do well).
But then when it comes to the other points, yes I want to be able to reliably boot into other systems, but both systemd-boot and grub are notoriously bad at detecting other systems on disks (both use install-time detection IIRC). The only one which does a reasonable job is rEFInd. But even more a kernel with appropriate drivers could even add kernels/systems on usb disks to the selections (why do I have to go to the UEFI selection to boot from USB).
The next thing he completely ignores is booting into zfs or btrfs snapshots, which is not possible using systemd-boot AFAIK, and again would be much nicer to do with a kernel.
Also, from what I understand after watching some of the video demonstration in the Q&A, I could just have another EFI entry point towards the nmbl configuration with a grub like menu, and get an exact replica of the grub experience. Having to go through the BIOS boot menu for those rare occasions where I need it is perfectly reasonable.
I feel like that post misses the biggest one that pulls people to GRUB: complicated boot sources and procedures. Filesystems that UEFI doesn't understand, more complex network boot sources, all that kind of complex messiness that GRUB enables and others don't. Now, whether those are good idea or not is a different question, but I think this is a good concept for a full replacement for GRUB, as opposed to the existing replacements which already cover the 90% case pretty well. (And I think it's got a case for handling the other cases OK: from the sounds of it they plan to lean on UEFI and A/B image to handle fallback, and it'll basically just work as a direct UEFI boot in the common case)
Thinking about it a bit more, though, it does feel like a hybrid approach is probably better. For dual-booting off local disks and other simple cases, just having the kernel and initramfs alongside other OS options makes a lot of sense, and you can use the UEFI boot menu or something deliberately simple like systemd-boot to select between them for dual-boot or recovery. For more complex cases (where your rootfs is not just something the kernel can mount on its own), instead you basically just want a process for building your initramfs to do that from a config like grub (which is already how a lot of cases like that are solved, anyway), and in extreme cases where you also want to stash a kernel in some other location then you can use kexec from that. But for just a boot menu (which is aready in the minority case and 90% of users in that case need nothing more) it feels even heavier than grub for little benefit.
> completely useless if you care about Measured Boot
I stopped reading there. All these engineers who help build and defend this draconian crap should be forced to used only an iPad for the rest of their lives.
Measured boot is, in itself, under user control - you can seal whatever secrets you want to any specific state and they'll only be accessible in that situation. This has obvious benefits in terms of being able to (for instance) tie disk encryption keys to a known boot state and so avoid needing to type in a decryption phrase while still preventing anyone from being able to simply modify your boot process to obtain that secret. The largest risk around this is from remote attestation, and that's simply not something where the infrastructure exists for anyone to implement any kind of user restriction (and also it's trivial to circumvent by simply tying any remote attestation to a TPM that's not present at boot time and so can be programmed as necessary - it's just not good at being useful DRM)
Unfortunately nothing is "in itself" in the real world. All these so called security features end up locking down users more and more in their own devices.
