Fedora Stakeholders Back To Discussing Raising x86_64 Requirements Or Using Glibc HWCAPS
While Red Hat Enterprise Linux 9 is dropping support for older x86_64 CPUs by raising the baseline requirement to "x86_64-v2" that roughly correlates to Intel Nehalem era processors and newer, so far Fedora has not changed its default. There was a proposal shot down last year for raising the x86_64 microarchitecture feature level while now that discussion has been restarted or alternatively making use of Glibc's HWCAPS facility for allowing run-time detection and loading of optimized libraries.
The discussion over whether Fedora should raise its x86_64 microarchitecture feature level requirement or make use of Glibc HWCAPS has been restarted on their mailing list. The talk stems from SUSE Linux Enterprise / openSUSE Leap pursuing x86_64-v2 optimized libraries by way of Glibc-HWCAPS for their next point release / service pack.
As was the case last year, developers and other stakeholders remain quite divided over what should be done: there are many out there wanting to see Fedora and other Linux distributions continuing to support the early generation Intel/AMD x86_64 CPUs while others believe it's time to retire that support and focus on better out-of-the-box performance. If not raising the base requirement, Glibc-HWCAPS allows largely having the best of both worlds by punting it to run-time detection and selectively loading the optimized libraries for a given system. But that leaves Linux distributions then to building multiple packages or inflating their packages by carrying multiple builds within there in order to have the libraries comply with the different x86_64 microarchitecture feature levels. Some Linux distributions are resorting as well to making their own ports/archives of a more modern x86_64 feature level that users can rely upon instead of the generic x86_64 archive/repository.
At this stage no new proposal has been drafted in the Fedora camp, but the discussion remains lively by users concerned about old hardware support and others wanting to see Linux advance its offering for modern hardware. See this mailing list thread if the topic interests you. So far most Linux distributions seem to be in favor of the HWCAPS approach while RHEL9 will raise the base requirement and Arch is looking at a higher feature level port.
The discussion over whether Fedora should raise its x86_64 microarchitecture feature level requirement or make use of Glibc HWCAPS has been restarted on their mailing list. The talk stems from SUSE Linux Enterprise / openSUSE Leap pursuing x86_64-v2 optimized libraries by way of Glibc-HWCAPS for their next point release / service pack.
As was the case last year, developers and other stakeholders remain quite divided over what should be done: there are many out there wanting to see Fedora and other Linux distributions continuing to support the early generation Intel/AMD x86_64 CPUs while others believe it's time to retire that support and focus on better out-of-the-box performance. If not raising the base requirement, Glibc-HWCAPS allows largely having the best of both worlds by punting it to run-time detection and selectively loading the optimized libraries for a given system. But that leaves Linux distributions then to building multiple packages or inflating their packages by carrying multiple builds within there in order to have the libraries comply with the different x86_64 microarchitecture feature levels. Some Linux distributions are resorting as well to making their own ports/archives of a more modern x86_64 feature level that users can rely upon instead of the generic x86_64 archive/repository.
At this stage no new proposal has been drafted in the Fedora camp, but the discussion remains lively by users concerned about old hardware support and others wanting to see Linux advance its offering for modern hardware. See this mailing list thread if the topic interests you. So far most Linux distributions seem to be in favor of the HWCAPS approach while RHEL9 will raise the base requirement and Arch is looking at a higher feature level port.
20 Comments