On Thu, 2022-04-07 at 16:16 +0200, Zbigniew Jędrzejewski-Szmek wrote: > On Thu, Apr 07, 2022 at 10:58:29AM +0200, Peter Boy wrote: > > > > > > > Am 07.04.2022 um 00:25 schrieb Neal Gompa <ngompa13@xxxxxxxxx>: > > > > > > It would be useful if we do indeed get a x86 BIOS SIG as Hans de Goede > > > proposed. I think Fedora Server and Fedora Cloud would be interested > > > in such a thing, given all the caveats right now with dropping BIOS > > > support for server-class hardware. > > > > As the soul who currently coordinates and moderates the work of the Server WG, I would be very much in favor of such a SIG as a possible way out. If it's good enough, that is. > > > > Just coming up with the idea of removing the (new) installation of such a central part from one release to the next leaves me speechless. That's tens of thousands of devices / users affected and we don't even know how many tens of thousands. And then phrases like "..will remove it anyway". What else is there to say? > > > > I'm afraid just creating an x86 BIOS SIG is not sufficient anymore. We need a completely different spirit in this area. > > > > Don’t get me wrong. Lack of resources to maintain something is completely legitimate. But I expect more open-mindedness and willingness for constructive alternatives. And none of that is evident in the Change proposal, nor in the discussion here (by the change proposal authors). > > > > And it is OK for me to migrate to UEFI only in the long run. But not that way. > > This summarizes my feelings about the proposal very well. > > We should look to the Xorg → Wayland transition for inspiration: > it's long, it's messy, it requires a lot of effort from people doing > the work, and it's still not finished. Those are the downsides. But > the big upside is that we're not leaving users who need Xorg in the > ditch. > > A similar pattern should be followed here: encourage users to switch, > fix bugs so that $new is better than $old in all cases we care about, > iterate until the number of users on $old is negligible, > *then* announce that $old is not supported, but keep it working, > and only after that start cutting off parts of $old. > > The proposed plan seems to be to jump to the last two steps before the > middle parts have been done. Based on the examples posted to this > thread, it'd leave our users and developers with 10%–30% of hardware > unsupported by the next installer. It also depends on changes that are > only *planned* in external projects like VirtualBox and libvirt. > > Sorry, but the plan needs to be inverted to at least make sure that > the UEFI works for all the cloud providers and virtualization software > in a testable way, and then switch to UEFI as the default in as many > places as possible. Then we can talk about dropping support for BIOS, > taking into account how many users are still left with BIOS-only > hardware. FWMOIW this sounds like the most reasonable comment I have seen here. The plan is nice, it is just trying to get to the end goal too fast, more nuanced steps are necessary and more time. Too many users would be left behind otherwise. simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc _______________________________________________ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
