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 _______________________________________________ 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
