openSUSE Tumbleweed Rolls Out Optional x86-64-v3 Optimized Packages

[phoronix]

Phoronix: openSUSE Tumbleweed Rolls Out Optional x86-64-v3 Optimized Packages

The rolling-release openSUSE Tumbleweed package has begun rolling out a new "patterns-glibc-hwcaps-x86_64_v3" package that is automatically installed on supported systems and allows for automatically installing "recommended" x86-64-v3 optimized packages where available in the name of enjoying greater performance...

https://www.phoronix.com/news/openSUSE-TW-x86-64-v3-RPM

[TemplarGR]

Does Arch indeed offer v3 packages? I wasn't aware.

[-MacNuke-]

Does Arch indeed offer v3 packages? I wasn't aware.

No. Just an RFC was merged but nothing was done to do that. As far as I know ArchLinux currently (slowly) works on more automation for building and delivering packages. When this is finished such things are planned. Currently every maintainer builds and uploads the package more or less manually. So such things would mean that there would be more manual work for the maintainer. That not what everyone wants.

[Toggleton]

Does Arch indeed offer v3 packages? I wasn't aware.

I think only as third party repository's. Like this https://github.com/an0nfunc/ALHP Did have them for a while but had some bugs that have been fixed by switching back to the official ones. Will need to test again. Or they have done it so sneaky that i did not notice one year ago they did still talk about starting it https://lists.archlinux.org/archives...S4AT2IMZQ7IJE/

And here a message of September https://lists.archlinux.org/archives...AKYLUTBY6AK2U/

[TemplarGR]

Thanks for the replies guys. I thought as much, but i asked because sometimes i may miss stuff like this.

While the OpenSUSE way of doing it is really good, when Michael wrote the article in 2021 IIRC i commented that i preferred if they just raised the level across the board instead of splitting the repositories. In my opinion it would be preferable to just make v2 the baseline right NOW, and wait another 5-6 years to raise it again to v3. There is no need for multiple levels. v1 is ANCIENT in 2023.

And before someone comes and says "b-b-b-b-but some newer cpus lack features", it is the responsibility of the users to be INFORMED about the hardware they purchase when they plan on using Linux, especially an advanced distro like Arch. The vast majority of cpus sold in the last decade had v3, let alone v2, aside from really budget options. At some point, a bleeding edge distro like Arch needs to make the hard decisions and raise the requirements, like they did when they ditched x32. Instead of doing so much extra work on maintaining multiple versions or creating more automation, how about just raising the level? It is simple, very simple, requires no work at all. And i am pretty sure 99,9% of the users of Arch won't be affected. If someone has an old secondary PC and uses Arch, let him switch to some other distro. v2 is a nice balance for now. And give a warning to everyone that in 5-6 years time they will go to v3. Plenty of time so no one will be caught by surprise. In 2028 v3 will be more than 14 years old. No excuses.

[Toggleton]

And i am pretty sure 99,9% of the users of Arch won't be affected. If someone has an old secondary PC and uses Arch, let him switch to some other distro. v2 is a nice balance for now. And give a warning to everyone that in 5-6 years time they will go to v3. Plenty of time so no one will be caught by surprise. In 2028 v3 will be more than 14 years old. No excuses.

https://gitlab.archlinux.org/archlin...476#note_55569 it has been a year ago 7% with v1 and 28% with only v2. and that are only from the users that have the pkgstats package uploading data.

The office PC of my mom has no v2 so i need to switch away from openSuse Leap if they force that requirement. Not every PC needs the newest hardware. And throwing good working hardware to the trash makes not always sense.

And there is a reason why there is still a 32bit x86 version of arch https://archlinux32.org/

[otoomet]

Thanks for the replies guys. I thought as much, but i asked because sometimes i may miss stuff like this.
And give a warning to everyone that in 5-6 years time they will go to v3. Plenty of time so no one will be caught by surprise. In 2028 v3 will be more than 14 years old. No excuses.

I like the idea of "early warning". This needs good planning though, so it may require a bit of work still.

Anyone knows how will the corresponding installers behave? I'd expect it to stop with a clear message along the lines "Your cpu--i5-2400 (or whatever) does not support the features required for this distro. Please upgrade your hardware". The worst behavior is for the installer to work silently and the system to crash later...

[Vistaus]

Didn't install automatically for me even though my system is slightly over a year old and has pretty impressive specs. So it should be supported.

[Estranged1906]

While the OpenSUSE way of doing it is really good, when Michael wrote the article in 2021 IIRC i commented that i preferred if they just raised the level across the board instead of splitting the repositories. In my opinion it would be preferable to just make v2 the baseline right NOW, and wait another 5-6 years to raise it again to v3. There is no need for multiple levels. v1 is ANCIENT in 2023.
.

But unlike Arch OpenSUSE also run on exotic hardware like POWER9/10 or IBM z Mainframes. So they should have the infrastructure in place to have multiple x64 versions.

By the way I wonder what they'll do for MicroOS. That's supposed to be an immutable image that's the same for all users (which the choice of Gnome, KDE, or nothing = server).

[EphemeralEft]

While the OpenSUSE way of doing it is really good, when Michael wrote the article in 2021 IIRC i commented that i preferred if they just raised the level across the board instead of splitting the repositories. In my opinion it would be preferable to just make v2 the baseline right NOW, and wait another 5-6 years to raise it again to v3. There is no need for multiple levels. v1 is ANCIENT in 2023.

I’m not familiar with Arch, but my understanding is that there is infrastructure and tooling already there to make locally compiling source packages easy and automatic. In which case they should only offer pre-compiled packages for the lowest common denominator, because those machines would have the most difficulty or be unable to locally compile packages. And then for everyone else, compile the packages locally with -march=native (or whatever level performance-seekers want).