Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

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

 



On Thu, 2022-04-07 at 15:26 -0400, Neal Gompa wrote:
> On Thu, Apr 7, 2022 at 3:16 PM Simo Sorce <simo@xxxxxxxxxx> 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 <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.
> > 
> 
> I like Zbigniew's plan too! But I gotta ask, what is "FWMOIW"?

For What My Opinion Is Worth :-)


> 
> 
> 
> --
> 真実はいつも一つ!/ 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
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

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




[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