Hello, On Mon, Dec 05, 2022 at 09:40:28PM +0100, Stefan Brüns wrote:
On Montag, 5. Dezember 2022 21:00:55 CET Michael Ströder wrote:
On 12/5/22 17:47, Larry Len Rainey wrote:
And now the key question:
Why should Tumbleweed cut off supporting old hardware if nobody benefits from this move?
Let's assume this argument is just not very well thought-out, not outright dishonest.
1. For being honest. Tumbleweed is hardly tested on v1 hardware.
Most of the hardware on which you can theoretically run Tumbleweed is not tested, ever. There is much more to CPU revisions than these -v1 -v2 -v3 and -v4 feature bags. Each contains a number of features that were enabled one by one over time, individually. CPUs with various combinations of these exist. There are Intel CPUs, and AMD CPUs. There are crypto extensions and others tha were not bagged into any of these 'versions' and are orthogonal. openQA has workers that are have some mix of CPUs that is in no way representatiove of this variation. AFAIK the tests are scheduled based on available worker capacity without regard for the worker architecture. And that's only the CPU, there is firmware, and actual hardware. None of that is tested - the QA runs on virtual machines that use firmware that very few if any real world machines use, and paravirtualized hardware. Singling out x86_64-v1 and saying this cannot be supported because it's not tested .. sounds like a very poor argument at best. There is the other kind of testing that TW recieves - when it works in at least one VM for some specific tasks the packages are released, and uers try to run them on their machines, and report problems with the scenarios not tested. Clearly there are users runnig x86_64-v1 so it does receive this kind of testing.
2. For being honest. There are packages which actually require SSE3 or later, and do not support generic x86. Still these package claim to be "x86_64".
SSE3 is pretty much part of the baseline - 64bit CPUs that don't support it exist but those are AFAICT only truly obsolete ones. Like still using DDR1 memory. Arguably if there are packages that require SSE4 unconditionally that's a bug. AFAIK the vast majority of packages just get compiled with whatever flags the distribution uses or use dynamic code dispatch to take advantage of specific CPU features as avaialble.
3. There are small performance benefits on average for targeting v2 [1]. 4. It allows to reduce the runtime-dispatched code from the shipped binaries.
I'm opposed to this change.
There is no compelling reason for it. At least two of my family/friend users are affected by this because of old notebooks currently running fine for their usage.
Splitting support for -v1 to separate port repo means more maintenance work. But the openSUSE project does not have plenty of helping hands.
Ciao, Michael.
Being one of the helping hands, at least removing i586 will be a significant improvement. Trying to keep i586 alive is a burden, and many packages e.g. just disable the test suite for i586 to pass the build.
For v1, there are two possible outcomes: 1. Packages just work, without further involvement - no extra maintenance 2. Packages need more work than just a different "-march" option for the compiler.
3. Not doing any switch at all, resulting in no pain for neither maintainers nor users - win win. Thanks Michal