On Thu, Jul 2, 2020 at 1:55 AM John M. Harris Jr <johnmh@xxxxxxxxxxxxx> wrote: > > 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? > Hardly. I completely disagree with your entire statement, so stop using "we". Here's the thing: systemd-boot is very good at what it does. The Gummiboot project was a great demonstration of a nice, simple boot manager. Kay decided to fold it into the systemd project, which is fine. It has benefited from the tighter integration with tools like systemctl. I have two problems with sd-boot: 1. It is absolutely butt-ugly. 2. It is absolutely horrible for people who need to navigate this "by surprise". Neither the Windows Boot Manager nor the Apple "Option Boot" menus are this bad. I literally do not care about anything else about it except for those two things. I've used sd-boot before and it's more than sufficient as long as the UEFI firmware isn't broken. Nowadays, it's more common to have UEFI firmware that does the right thing than the wrong thing, which is great. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
