RHEL 10 is planned to require v3 as implied in their blog. Three of my computers have microprocessors that are only v2 compliant but not v3, will future Fedora releases stop working?
1 Like
Maybe someone here may have the answer, but it seems more relevant to ask questions about RHEL in the RH support environment. Your question seems specifically about a RHEL product.
I am not in planning, but have seen nothing related to the changes you are asking about as it applies to fedora.
I will move your post to discussion so those who are more in the know may answer.
From Ask Fedora to Project Discussion
Good. Because such a change would break some newer Pentiums/Celerons and select low-end AMD CPUs, QEMU could also possibly have problems on ARM as it emulates the 80386 and AMD64 architectures respectively.
1 Like
Some related discussions have occurred this year. See the following links. The proposal for providing optimized binaries has been withdrawn. This would be the logical first step required. Once optimized binaries are available, there could be a discussion to deprecate/eliminate older versions. As it stands now, it doesn’t appear that this is going to happen anytime soon.
https://fedoraproject.org/wiki/Changes/Optimized_Binaries_for_the_AMD64_Architecture
3 Likes
So it means it searches for support and calls the instructions if supported, leaving older machines functional?
I didn’t read into it, but I would be surprised if v3 was pushed on RHEL before receiving any kind of testing on Fedora; it seems like Fedora would have had this for a while.
I believe it means that package maintainers would have the option to provide optimized variants of their packages (e.g. -v2, -v3, -v4). And if your CPU supports it, it will use those binaries.
Whether or not those optimized variants would be automatically be chosen when you dnf install foo a package, or if you have to specify dnf install foo-v3 is unclear to me based on what I read.
RHEL actually moved to the x86-64-v2 baseline for version 9, and is looking at x86-64-v3 for RHEL 10.
I think for enterprise server applications it makes sense. Often there is a direct correlation between code efficiency and server operating costs - so customers would more likely benefit from an optimized binary if it means their servers can be stretched further. At the same time, enterprises running the latest RHEL probably aren’t running it on CPUs with architectures >15 years old.
On the Fedora side, I would guess it’s more common to see it used on older systems and thus the need to support older ISAs is more relevant.
6 Likes
Prepare to be amazed!
So I’m not here to comment about RHEL specifically, but I can say that Fedora serves a very different user base and Fedora users expect the operating system to be usable on much older hardware than enterprise Linux users do. The two user bases are completely different. You probably don’t recycle your laptop when warranty expires, for example.
6 Likes
For reference, an 11th Gen Intel Core i7 has v4, this is already 3 Generations old.
But the comment about the low-end CPU series that may be new but still not v3 is interesting.
Hanging on the old versions for compatibility… is annoying. Afaik even my 2012 Thinkpad is v3 and that is Intel Core i5 3rd Gen!
But yeah, shipping both is a ton of effort. Shipping only one will cause users needing to switch.
Arent there telemitry numbers on this?
I figured Fedora to be more-appealing for up-to-date software and going for the latest and greatest tech (systemd, Wayland, upstream GNOME presented with default Workstation).
I kind of figured Fedora would have had v3 on as much as possible before other distros started talking about it (oS TW had v3 default in installer for a while), and especially before RHEL that’s expected to be stable on servers.
Supporting latest software does not force a move to newer intel micro architectures.
One upstream project did force a move, but the Fedora maintainer convinced them to revert mandating of newer microarchitecture.
From memory the change proposal to change from the existing status quo was rejected for a number of reasons:
- Usable hardware current running Fedora would no longer be support
- Recent CPU SKUs from Intel lack the required instructions.
- The benefit of compiling against the newer microarchiteures is very small for the vast majority of apps.
- Apps that can benifit can be handled wither with run time checks or provide alternate RPMs
2 Likes
Runtime checks are definitely possible, has been since the 1980s, The Sims in 2000 had a RAM check that warned users under 64MB RAM, it also had a Pentium check that required a Pentium (i586) or newer. IIRC AutoCAD in 1982 also had an FPU check that looked for a 8087 alongside the regular 8086 or 8088. And about usability, i have a Core 2 Duo system that’s still perfectly usable, runs GNOME 46 with okay performance with the integrated GMA X3100 (also known as GMA 965) graphics, it even runs OpenTTD smoothly with a 4096x4096 map.
FYI The detection code is built into glibc.
1 Like
That’s what i mean. The infrastructure is already there and works well.
Maybe fedora is a upstream of rhel and ubuntu already switched to v3.
Fedora maybe in future provide 2iso
1 v2.img
2 v3.img
Like 32 bit now discontinued by various distros v2 mighty be discontinued slowly like this.
Coz technically rhel 11will be on fedora 46 hence I don’t think fedora will keep v2 for fedora 46
And i think this is something good as modern cpus running v4 we are still on v2.
I don’t know much but from the benchmark that ubuntu have i can clearly say even with v3 we can have a good performance uplift.
No. This was discussed and rejected as there the overhead for doing this is far to big.
No the uplift is very small. Only a small number of packages benefit and can be packaged with dynamic runtime algorithm switching.
1 Like
Did it? I know it experimented with a v3 build but the requirements make no mention of this requirement. See Installation/SystemRequirements - Community Help Wiki