Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS > > == Summary == > Make UEFI a hardware requirement for new Fedora installations on > platforms that support it (x86_64). Legacy BIOS support is not > removed, but new non-UEFI installation is not supported on those > platforms. This is a first step toward eventually removing legacy > BIOS support entirely. > > == Owner == > * Name: [[User:rharwood| Robbie Harwood]], [[User:jkonecny| Jiří > Konečný]], [[User:bcl| Brian C. Lane]] > * Email: rharwood@xxxxxxxxxx Considering that this will desupport my notebook that runs Fedora just fine, and that I am not alone with this issue judging from the other comments, I am totally opposed to this change. > == Detailed Description == > UEFI is defined by a versioned standard that can be tested and > certified against. By contrast, every legacy BIOS is unique. Legacy > BIOS is widely considered deprecated (Intel, AMD, Microsoft, Apple) > and on its way out. As it ages, maintainability has decreased, and > the status quo of maintaining both stacks in perpetuity is not viable > for those currently doing that work. I do not see what is there to maintain given that it is legacy technology that does not change anymore. > It is inevitable that legacy BIOS will be removed in a future release. Hence, I do not see the inevitability at all! > To ease this transition as best we can, there will be a period (of at > least one Fedora release) where it will be possible to boot using the > legacy BIOS codepaths, but new installations will not be possible. > While it would be easier for us to cut support off today, our hope is > that this compromise position will make for a smoother transition. > Additional support with issues during the transition would be > appreciated. As others have pointed out, that broken "compromise" means that corrupt installations, hard disk failures, etc. can no longer be recovered on those machines. So it does not solve the problem at all. And I disagree with the ultimate goal of the transition (complete desupport of legacy BIOS) to begin with. By the way, if you just drop support from Anaconda, that does not preclude installing Fedora on those systems using Calamares. > While this will eventually reduce workload for boot/installation > components (grub2 reduces surface area, syslinux goes away entirely, > anaconda reduces surface area), the reduction in support burden > extends much further into the stack - for instance, VESA support can > be removed from the distro. That (dropping VESA), too, will desupport a whole class of perfectly working hardware, though it should not affect me personally. > Fedora already requires a 2GHz dual core CPU at minimum (and therefore > mandates that machines must have been made after 2006). My notebook has a 2.4 GHz Core 2 Duo T7700, so it fits that requirement. (But Fedora probably actually runs on even lower-powered machines. After all, the PinePhone, on which Fedora is known to run, has a 1.2 GHz aarch64 CPU (with 4 cores).) Still, the notebook does not support UEFI. > Like the already accepted Fedora 37 change to retire ARMv7 support, > the hardware targeted tends to be rather underpowered by today’s > standards, and the world has moved on from it. The difference is, Fedora on ARM has always been a niche thing, so dropping ARMv7 affects far fewer users than dropping support for some x86_64 machines. (Also note that the change was not about dropping a subset of aarch64 machines, only 32-bit was dropped, years after that happened for x86.) And also, performance-wise, my Core 2 Duo notebook is probably faster than most of those 32-bit ARMv7 devices. > Intel stopped shipping the last vestiges of BIOS support in 2020 (as have > other vendors, and Apple and Microsoft), so this is clearly the way things > are heading - and therefore aligns with Fedora’s “First” objective. "First" was never meant to be a synonym for planned obsolescence of hardware. It means being first to offer the latest and greatest software, nothing more. > * There is no way to deprecate hardware without causing some amount of > friction. Indeed. So do not do that then. > Current owners plan to orphan some packages regardless of whether the > proposal is accepted. And that is completely unacceptable blackmailing. Kevin Kofler _______________________________________________ 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
