On Thu, Apr 7, 2022 at 3:16 PM Simo Sorce <s...@redhat.com> wrote: > > 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 <ngomp...@gmail.com>: > > > > > > > > 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. >
I like Zbigniew's plan too! But I gotta ask, what is "FWMOIW"? -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
