Hi, <to be clear I'm replying on a personal title here, not on behalf of my employer (Red Hat)> On 4/5/22 16:52, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS <snip> > Fedora already requires a 2GHz dual core CPU at minimum (and therefore > mandates that machines must have been made after 2006). But machines made between 2006-2012 generally did not have EFI support, anf for example at home I still have several machines from that era which are BIOS only in active use: 1. My daughter's workstation is an i5-2400 with 8G RAM, this is a 3.1 GHz base-freq quad-core processor very easily matching Fedora's minimal requirements. Currently running Fedora 35 just fine. Making it impossible to keep using this in the future is just causing unnecessary ewaste for no good reason IMHO. 2. My wife's workstation is a Core 2 Duo E6600 2.4 Ghz dual core machine with 4G RAM, which also still works fine for what she uses it for. 3. The living room laptop is another Core 2 Duo machine with 4G RAM. Looking specifically at fixed PCs and not laptops this proposal would (eventually) turn 2/5 PCs in my home unusable, which really is unacceptable IMHO. Also note that all these machines use somewhat older Intel integrated graphics. As he has already mentioned on this this thread, Dave Airlie has just spend a lot of time on making sure those iGPU-s will work with a gallium driver so that the classic mesa code can be removed and it seems rather silly to drop support for this hw after just investing a significant chunk of time to breathe new live into their GPU support. So a big -1 from me for this proposal as it stand. ### But I do completely understand that there is a workload issue for the bootloader team and the proposal also mentions: > == Contingency Plan == > Leave things as they are. Code continues to rot. Community > assistance is required to continue the status quo. Current owners > plan to orphan some packages regardless of whether the proposal is > accepted. If the current owners no longer want to support some packages which are only necessary for legacy BIOS support, then orphaning these seems completely reasonable to me. Maybe you can provide a list of these pkgs before hand so that people can already volunteer as co-maintainers now and then when they are orphaned, instead of orphaning them they can be directly handed over (using the "give away" button) to the new maintainers ? > Another fallback option could be, if a Legacy BIOS SIG organizes, to > donate the relevant packages there and provide some initial mentoring. I believe that that is a great idea, I hereby volunteer to try and setup such a SIG. If anyone reading this is interested in joining such a SIG please drop me an email. I realize that there have been similar attempts around keeping 32 bit x86 alive and that those have failed, but I believe that this is different for a number of reasons: 1. i686 support required making sure that *all* of Fedora kept working on i686, the problem was not just the kernel breaking sometimes, but also that huge projects like libreoffice would no longer start on i686 (at least on some of my machines). Legacy BIOS boot support is basically only about the image-creation tools + the bootloader. As various people have mentioned in the thread BIOS support is still very much a thing in data-centers, so I expect the upstream kernel community to keep the kernel working with this for at least a couple of years. Where as both the kernel + many userspace apps were breaking on i686. 2. I personally basically gave up on i686 support also because there was very little 32 bit only x86 hw around remaining in active use when it was dropped. And what was still on active use was getting close to unusable from a performance pov. Where as here we are talking about up to 2nd and 3th gen core i5 / i7 machines which are still quite performant. Esp. the 2nd gen core machines (Sandy Bridge) are still quite popular and lots of people have hung on to desktops with those because the CPU performance increase in generations after SNB have been rather underwhelming. > Longer term, packages that cannot be wholly donated could be split, > though it is unclear whether the synchronization thereby required > would reduce the work for anyone. I've been thinking about how this could be done for grub; also because of the issue that the EFI builds of grub need to be signed with Fedora's secure boot keys, which means only a few people can do grub2 builds atm. One option which I think we should consider is sticking with a single downstream git fork (until we have managed to get everything we need upstream), so stick with: https://github.com/rhboot/grub2/ As the Source0 provider for the packages and then next to: https://src.fedoraproject.org/rpms/grub2 Add a: https://src.fedoraproject.org/rpms/grub2-bios And moving the build of all sub-packages which are only necessary for BIOS support to the second src.rpm. This way the Legacy BIOS SIG could maintain the grub2-bios src.rpm (and binary pkgs it builds). The SIG _must_ then of course still submit pull-reqs to: https://github.com/rhboot/grub2/ for any changes. But in case of e.g. a beta blocking BIOS only bug they could solve that with a patch in the src.rpm and kickof a build right away without blocking on the bootloader team and thus without causing a spike in work-pressure/load for the bootloader team. And then once the pull-req is merged (possibly a revised version of it) the next build of the grub2-bios src.rpm can pull in the new Source0 and drop its local changes (IOW grub2-bios _must_ not become a separate fork). Regards, Hans _______________________________________________ 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
