On Montag, 5. Dezember 2022 21:00:55 CET Michael Ströder wrote:
On 12/5/22 17:47, Larry Len Rainey wrote:
I woke up this morning with this question?
If Tumbleweed is the latest Kernel and Software Versions, why are we worried about hardware that is over 8 years old?
So here's another question for you:
Why does the recent Linux kernel still support pretty old hardware?
1. The kernel is sources, not binary. Support for old hardware does not preclude support for new hardware. 2. The kernel targets a broad range of use cases, HPC, desktop, embedded. Expecially the latter has significant longer development life cycles than generic desktop computers. 3. Official hardware deprecation for the kernel typically happens long after the fact - "this code has not worked for the last 5 years and nobody has noticed it, drop it."
And now the key question:
Why should Tumbleweed cut off supporting old hardware if nobody benefits from this move?
1. For being honest. Tumbleweed is hardly tested on v1 hardware. 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". 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. For packages without any users even the second outcome would pose no problem. Iff there are users, it would be their obligation to submit fixes - the package maintainer probably has no access to v1 only hardware. Stefan [1] https://jamborm.github.io/spec-2022-07-29-levels/index.html