On Wednesday, July 1, 2020 7:30:37 AM MST Lennart Poettering wrote: > On Mi, 01.07.20 14:45, Hans de Goede (hdegoede@xxxxxxxxxx) wrote: > > > > I'm not in the bootloader-team, but I do work very closely with them, > > so I have only one question: who is going to pick up the extra > > maintenance load this is going to cause ? > > > There are distros already using it. And so far we have been pretty OK > with supporting it upstream and downstream. At least upstream I am not > aware of any big issues left open. > > Note that sd-boot is a lot simpler than grub, i.e. it doesn't contain > Turing complete programming languages, module loaders, file system > drivers, storage stacks and such. There's simply not that much to > maintain! > > > > Also note that this entails a lot more work then just maintaining > > sd-boot, > > anaconda will need to be adjusted, kernel-install scripts will need to > > be adjusted, etc. > > > kernel-install itself is actually maintained in the same repo as > sd-boot: systemd upstream. They are developed along the same lines > already. > > > > Also I wonder, if you are not proposing to completely drop grub2 on > > x86_64 what does offering sd-boot in addition to grub2 actually > > offer as advantages? > > > Primarily simplicity, and that it implements the boot loader spec > correctly. > > it automatically discovers windows and Macos installations at each > boot, without any userspace involvement. You can talk to it very > nicely, i.e. implement trivially "boot-into-windows" buttons and such > in GNOME and so on. It makes things very robust, since you don't need > a script that generates a script that generates a script (yeah, that's > how grub is hooked up). it just works on its own. You drop in boot > menu items, and that's it. You don't need to regenerate stuff, and you > never have to run an interpretor for a turing complete language. > > By using sd-boot, you can do stuff like "systemctl reboot > --boot-loader-entry=windows", you can do "systemctl reboot > --boot-loader-menu=0", you can do "systemctl kexec" and it boots the > right thing, and so on. > > It also implements boot time assessement that is simple and just works > (i.e. automatic revert to previous boot menu choice when the one > selected doesn't work). > > Oh, and it as support for seeding the Linux random seed pre-boot > already, in a safe and simple fashion. > > Moreover, it communicates which ESP is used to the host OS, so that > the host can automatically discover what other partitions to mount. > > And the list goes on and on and on. > > All these features are very simple individually, but put together they > are just a much nicer and expose a much more integrated behaviour > than Grub ever did. > > > > sd-boot is simpler and a bit tighter integrated with systemd, which would > > mean it is less work to maintain if we use it instead of grub, but if we > > use it next to grub then all those advantages fall away. IOW if we use > > it next to grub then all I see is a whole lot of extra work, with very > > little gain. > > > Well, you appear to believe in the race to the bottom, i.e. that the > lowest common denominator should be where the future is. I am pretty > sure it's the wrong approach: pick the simple contender that can do > all the nice things, and has the nice integration, and use it as a > blueprint for the other archs where Grub is still needed, and make > them catch up. > > I mean, I understand you are interested in exotic platforms that lack > modern things like UEFI, but it kinda sucks to hold the boot loader > hostage due to that, and just stick to the terrible ways of yesteryear > because of it. > > > > AFAIK this (lot of extra work, very little gain) is exactly why we have > > been sticking with grub2 so far. We need to maintain it anyway, at which > > point we want to use it in as much cases as possible so that we can have > > unified code and documentation for dealing with the bootloader. > > > I don't see "very little gain". I see a lot of gain, and all while > things become simpler. Much simpler. > > Lennart > > -- > Lennart Poettering, Berlin Lennart, We don't need more systemd-bloat just to boot our systems. However your bootloader works, it doesn't really matter if it's not up to snuff with GRUB2. When it supports LUKS, LVM, LUKS+LVM, a recovery console and several filesystems, then it'll be more of a viable option, and I still wouldn't recommend having yet another systemd component as a core part of our systems. At what point is systemd large enough that you'll stop adding more cruft? -- John M. Harris, Jr. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
