Re: The future of legacy BIOS support in Fedora.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux