My idea was that there are a lot of people that know what they are talking about with respect to the subject and that thus would be able to offer a simple way for noobs to determine what their situation is.
IMHO the subject is scary for many and the discussion is not very enlightening to point to the one and most important factor for most: is my system for for Leap 15.6 or not, a simple “yes” or “no”.
I am aware that this is Open Chat, thus maybe I should not have expected a useful helping technical answer for those, but thanks for the suggestion to everybody to find out on their own.
… The whole “v2”, “v3”, “v4” etc naming seems to be some crazy glibc artifact and is stupid and needs to die. … It has no relevance to anything. Please do not introduce that mind-fart into the kernel sources. … There is a very real model for microarchitectural features, and it’s
the CPUID bits. Trying to linearize those bits is technically wrong,
since these things simply aren’t some kind of linear progression.
As you might have recognized my question did not refer to post #1 but to your quote of what glibc does (what according to Linus Torvalds seems not what should be done to determine a CPUs features).
However I understand that you do not have an answer to my question.
Hi All
As already indicated the command to run on your system as defined by the openSUSE Developers is /lib64/ld-linux-x86-64.so.2 --help
Since this post refers to Leap 16.0, then if you believe a cpu flag has been omitted, then run Leap 16.0 alpha and create a bug report to state your case…
This is, as far as I’m aware, the openSUSE Project process, how upstream, other distributions etc implement that is while, perhaps informative, somewhat irrelevant.
Kernel and userspace are using the same CPU. So if a distribution gets installed isn’t there the necessity to make sure that neither the kernel nor userspace of that distribution is trying to use a CPU feature which is not provided by the CPU?
My understanding is that the point of the change is to enable programmers to write programs which assume that the chip is at least a version 2 chip. But programs running at present do not make this assumption. Therefore only a few programs initially but, presumably, an increasing number as they are updated will be affected by the change. And some may never be affected by the change because they will not use features which are only available with version 2 or above.
The question is really whether any programs which are essential to running the distribution will initially only work with a version 2 chip.
Inxi is correct here - Intel Core i7-8550U supports v3, => it supports v2 too.
For your old GA-790XTA-UD4 + AMD Athlon II X2 250: you can change mobo to AM3+ socket and install AMD FX-4100 … AMD FX-8370 CPUs, which support v2.
OFC, AM4 socket and CPUs are much better.
MS Windows 11 requires rather new CPUs, all of them support x86-64-v2, MS compilers use v2 by default for Win 11, MS Win 11 OS code uses them, newly compiled software uses them, developers are starting to drop older code paths.
For instance, dav1d decoder drops some SSE2 optimizations:
1.5.0 is a major release of dav1d, that:
WARNING: we removed some of the SSE2 optimizations, so if you care about
systems without SSSE3, you should be careful when updating!
In the next 2-3 years the main part of software will use v2. Developers don’t care about CPUs older than v2 anymore. They don’t have such hardware.
Comparison:
The fastest desktop CPU without v2 - AMD Phenom II X6