Hi Andreas On Wed, 2022-11-23 at 16:28 +0100, Andreas Jaeger wrote:

On 23/11/2022 16.22, Dominique Leuenberger / DimStar wrote:

...

[...] To become Old Factory * for users of legacy systems, we will introduce openSUSE:Factory:Intel, the same setup we have for ports like ARM, PowerPC, zSystems, RISCV. This repo will build packages for x86-64 (v1) plus i586, so basically what the current openSUSE:Factory repository does.

So, this is for the x86-64 architecture that was created by AMD and then later by Intel as well? Then, let's not call it :Intel, please. What about legacy in the name?

Intel is IMHO wrong for two reasons: * It implies that Intel processors are not part of Tumbleweed * It implies that x86-64 was created by Intel

Fair point! What about :LegacyX86? (it will be i586, and x86-64) Cheers, Dominique

Am Mittwoch, 23. November 2022, 16:32:36 CET schrieb Andreas Jaeger:

On 23/11/2022 16.30, Dominique Leuenberger / DimStar wrote:

...

On Wed, 2022-11-23 at 16:28 +0100, Andreas Jaeger wrote:

...

On 23/11/2022 16.22, Dominique Leuenberger / DimStar wrote:

Intel is IMHO wrong for two reasons: * It implies that Intel processors are not part of Tumbleweed * It implies that x86-64 was created by Intel

Fair point!

What about :LegacyX86? (it will be i586, and x86-64)

That also underlines the fact of its very nature. Cheers, Pete -- Life without chameleons is possible, but pointless.

On Fri, 2022-11-25 at 15:20 +0100, Hans-Peter Jansen wrote:

What about calling it x86-64-v1? Sure, this name will cover the i586 part implicitly only, but would leave room for a x86-64-v3 tree and following.

Or even more radical:

Create -v1, -v2 and v3 trees, make Factory a link to x86-64-v2 and in five years, switch it to -v3. Ideally, these trees share all noarch packages.

I'm sure, you get the idea.

I get the idea, but as the ports are independent, they can by no means share noarch packages between them. They won't even forcibly have the same release cadance (i.e. openSUSE Tumbleweed might publish a release, but the legacyx86 port might not, because something is utterly broken) And openSUSE:Factory being a 'link' to anything sounds very backwards - Factory is the leading project. The only one I care for (bluntly spoken) All the ports are up to the larger community and interested parties to be maintained. So if Factory moves to v3, and somebody really cares to maintain a v2 port at that time, we'll have to tripple efforts (or hopefully give up on v1 by then) Cheers, Dominique

On Tue, 2022-11-29 at 10:18 +0100, Bjoern Voigt wrote:

On 25.11.22 16:10, Dominique Leuenberger / DimStar wrote:

...

All the ports are up to the larger community and interested parties to be maintained. So if Factory moves to v3, and somebody really cares to maintain a v2 port at that time, we'll have to tripple efforts (or hopefully give up on v1 by then)

I don't think we will have tripple efforts. How likely is it, that a package bug only appears in the x86-64-v1 or x86-64-v2 package variant, but not in x86-64-v3? Maybe 2%? I think for nearly all RPM packages only some compiler switches are different.

There is at least tripple the OBS resource consumption to build a package three times, instead of once. There is at least tripped the openQA resource consumption to test three flavors instead of one. The openQA test results are, in most cases, expected to be the same. Yet, somebody has to do the work to review the failures and tag them with the corresponding bug reports (most frequently probably copying them from the STandard Tumbleweed port). Doing this on 2 extra ports is definitively more work than not doing this. And the occasional (albeit rare) case of something really being specific to x86-64-v1 (and i586, as announced, this won't be part of Tumbleweed anymore) will need to be analyzed and fixed. I hope this is not news for you - but nothing comes for free in this world. At least some heartbeets and sweat-pearls need to be invested in everything. The expectation that 'somebody is doing it' only works until there is nobody else volunteering todo the work. Cheers, Dominique

On 29.11.22 11:39, Bjoern Voigt wrote:

support their old hardware, they will probably use SLES 11 until EOL and

SLES11 is actually EOL... ;-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman

On 08.12.22 14:00, Simon Lees wrote:

On 11/29/22 21:25, Stefan Seyfried wrote:

...

SLES11 is actually EOL... ;-)

Nah it still has some LTSS support kicking on atleast for now.

Hm, I thought we really had bought all available LTSS packages, but then apparently sanity prevailed and we did no longer buy SLES11 ;-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman

On 11/29/22 10:44, Dominique Leuenberger / DimStar wrote:

There is at least tripple the OBS resource consumption to build a package three times, instead of once.

There is at least tripped the openQA resource consumption to test three flavors instead of one.

The openQA test results are, in most cases, expected to be the same. Yet, somebody has to do the work to review the failures and tag them with the corresponding bug reports (most frequently probably copying them from the STandard Tumbleweed port). Doing this on 2 extra ports is definitively more work than not doing this. And the occasional (albeit rare) case of something really being specific to x86-64-v1 (and i586, as announced, this won't be part of Tumbleweed anymore) will need to be analyzed and fixed.

I hope this is not news for you - but nothing comes for free in this world. At least some heartbeets and sweat-pearls need to be invested in everything. The expectation that 'somebody is doing it' only works until there is nobody else volunteering todo the work.

I think one of the barriers is that openSUSE isn't really a porter-friendly distribution. For example, I have been trying for ages to find proper documentation on how to bootstrap openSUSE on a new architecture, but nothing seems to exist. There cross-compilation capabilities in openSUSE are also rather limited as compared to Debian, for example. If openSUSE was accessible in this regard as Debian, I wouldn't mind maintaining additional architectures there. In Debian, I'm currently maintaining 9 architectures for Debian Ports without much hassle. Adrian

Am 29.11.22 um 11:14 schrieb Jan Engelhardt:

# TW goes v3 (ALP wants it too![1]) and I take care of LegacyX86 inasmuch I did for the i586 portion of present-day-Factory.

v3 as default still doesn't make sense. There is way too much hardware in heavy use (just take OBS and openQA) only capable of v2 level. So *still* it makes sense to have only a subset of packages compiled in v3 and have the base compiled in (actually v1, but I don't care so much about that difference) v2. Then you don't need a full tree, you only add some i986.rpm into the repo and can pick on installation time what you're capable of. Greetings, Stephan

On Wed, 2022-11-23 at 16:32 +0100, John Paul Adrian Glaubitz wrote:

Hi!

On 11/23/22 16:22, Dominique Leuenberger / DimStar wrote:

...

To become Old Factory * for users of legacy systems, we will introduce openSUSE:Factory:Intel, the same setup we have for ports like ARM, PowerPC, zSystems, RISCV. This repo will build packages for x86-64 (v1) plus i586, so basically what the current openSUSE:Factory repository does.

Community Actions Needed The :Intel port will require volunteers from the community to look after it. This will entail monitoring the builds, validating QA results (if not passing) and monitoring/pushing on bugs that are exclusive to these architectures (...) **Once the new intel port repository is ready, I'll let you know the exact location of it. We can expect for these changes to take place in the first quarter of the new year of 2023.**

This sounds like a very reasonable approach to me. I assume that means there will be ISO images for the "Intel" port as well, won't there?

YEs, I'd defintiively make ISO files for the installers. But it mostly dpeends on the volunteers that step up to actually maintain the things. I'll help with the initial setup (incl openQA) but, once running, expect not to touch this anymore (unless the people opting to take care ask for specific help). So in short: yes, I expect installer ISO files, but I'd not expect Live images.

I think it's a pity that openSUSE doesn't build images for all the architectures built in Factory. Some ports like big-endian PowerPC (32- and 64-bit) are missing.

Honestly, I'm not even sure which of the ports even have users - we build ISO files for PPC64 and PPC64le (but not ppc32) https://download.opensuse.org/ports/ppc/tumbleweed/iso/ Cheers, Dominique

Hi Am 23.11.22 um 18:18 schrieb Larry Finger:

On 11/23/22 09:36, Dominique Leuenberger / DimStar wrote:

...

YEs, I'd defintiively make ISO files for the installers. But it mostly dpeends on the volunteers that step up to actually maintain the things. I'll help with the initial setup (incl openQA) but, once running, expect not to touch this anymore (unless the people opting to take care ask for specific help).

So in short: yes, I expect installer ISO files, but I'd not expect Live images.

...

I think it's a pity that openSUSE doesn't build images for all the architectures built in Factory. Some ports like big-endian PowerPC (32- and 64-bit) are missing. Honestly, I'm not even sure which of the ports even have users - we build ISO files for PPC64 and PPC64le (but not ppc32) https://download.opensuse.org/ports/ppc/tumbleweed/iso/

Are there any others that would like a ppc32 version of openSUSE? I am stuck with Debian on my PowerBook G4 Aluminum, and I dislike it a lot.

I'm stuck with Gentoo on an old ppc32 system. Tumbleweed would be much preferred. Best regards Thomas

Larry

-- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev

Dominique Leuenberger / DimStar wrote:

So in short: yes, I expect installer ISO files, but I'd not expect Live images.

...

I think it's a pity that openSUSE doesn't build images for all the architectures built in Factory. Some ports like big-endian PowerPC (32- and 64-bit) are missing. Honestly, I'm not even sure which of the ports even have users - we build ISO files for PPC64 and PPC64le (but not ppc32) https://download.opensuse.org/ports/ppc/tumbleweed/iso/ Cheers, Dominique A related issue is that not all architectures offer a /snapshot repo on OBS. Only the ARM{6,7,64} and RISCV do (but RISCV is currently broken).

This makes it harder to offer builds for exotic architectures as the Factory /standard repo is often in an inconsistent state. A good place to notice the breakage is https://build.opensuse.org/project/show/openSUSE:Factory:Update

On Wed, 2022-11-23 at 16:36 +0100, Vojtěch Zeisek wrote:

Everything sounds reasonable, just one point. Do You think this change of repos could be done automatically? I.e. the compatibility is somehow detected, action performed, user notified. What would happen if user would forget to change the repos and packages would be upgraded?

That's something I'm trying to work out. I'd say at least a notification should be presented to the user of 'Real Tumbleweed' on i586/x86-64-v1 hardware that they have to change their repos. Changing them directly might be error prone - but an option to look in to. Not changing the repos, and having a x86-64-v1 machine will result in an unbootable system (glibc/kernel will be updated to use new CPU instructions) A sample failed boot-process would be something like seen here: https://openqa.opensuse.org/tests/2882517#step/welcome/8 An extra worry will be 3rd party repos; depending on their setup they might simply start building v2 (as they normally follow Factory, not ports). Cheers, Dominique

Am 23.11.22 um 17:14 schrieb Dominique Leuenberger / DimStar:

On Wed, 2022-11-23 at 16:56 +0100, Rainer Klier wrote:

...

sorry to ask such dumb question, but what is a x86-64-v2 system?

There were a lot of discussions and really long threads to this topic in the last couple months, so I assumed this would be clear by now. Sorry for this.

https://en.wikipedia.org/wiki/X86-64#Microarchitecture_levels

thanks for that link.

$ /lib64/ld-linux-x86-64.so.2 --help

This contains a section such as: Subdirectories of glibc-hwcaps directories, in priority order: x86-64-v4 x86-64-v3 (supported, searched) <-- My machine supports up to here) x86-64-v2 (supported, searched) <-- This is what Tumbleweed will require

Alternatively, you can also use inxi:

$ inxi -aC CPU: Info: model: Intel Core i5-4200U bits: 64 type: MT MCP arch: Haswell gen: core 4 level: v3 note: check built: 2013-15 process: Intel 22nm

Here, level: v3 is the relevant piece (we will want at least v2)

whow, thanks a lot for that clear and detailed explanation. now i understand. funnywise my notebook CPU reports the same result as yours, seems to be the same family:  x86-64-v4  x86-64-v3 (supported, searched)  x86-64-v2 (supported, searched) Info:model:Intel Core i7-4700HQ bits:64 type:MT MCP arch:Haswell gen:core 4 level:v3 built:2013-15 process:Intel 22nm family:6 will we as end-users notice any difference in operation, when we install packages from that x86-64-v2 repositories? -- Best Regards | Freundliche Grüße | Cordialement | Cordiali Saluti | Atenciosamente | Saludos Cordiales *DI Rainer Klier* DevOps, Research & Development

On Wed, Nov 23, 2022 at 05:34:12PM +0100, Dominique Leuenberger / DimStar wrote:

On Wed, 2022-11-23 at 17:24 +0100, Rainer Klier wrote:

...

will we as end-users notice any difference in operation, when we install packages from that x86-64-v2 repositories?

Unlikely, unless something breaks.

'It depends' on the workloads you run. We basically allow the compiler to use optimizations for newer CPU classes which is supposedly leading to improved performance. In some cases this can be noticable, in many cases it's only measurable.

Not even measurable. The benchmarks presented so far do not even show universal performance gain. The v3 would be adifferent story but that would exclude way too many CPUs. There are some highly parallelized programs that would significantly benefit from 128bit atomics but that sets the bar much lower than v2. What v2 brings besides that are the SSE instructions up to SSE 4.2 which are not all that useful. Thanks Michal

Am Freitag, 25. November 2022, 09:23:06 CET schrieb Richard Biener:

On Thu, 24 Nov 2022, Michal Such?nek wrote:

...

On Wed, Nov 23, 2022 at 05:34:12PM +0100, Dominique Leuenberger / DimStar wrote:

...

On Wed, 2022-11-23 at 17:24 +0100, Rainer Klier wrote:

...

will we as end-users notice any difference in operation, when we install packages from that x86-64-v2 repositories?

Unlikely, unless something breaks.

...

'It depends' on the workloads you run. We basically allow the compiler to use optimizations for newer CPU classes which is supposedly leading to improved performance. In some cases this can be noticable, in many cases it's only measurable.

Not even measurable. The benchmarks presented so far do not even show universal performance gain.

The v3 would be adifferent story but that would exclude way too many CPUs.

There are some highly parallelized programs that would significantly benefit from 128bit atomics but that sets the bar much lower than v2.

What v2 brings besides that are the SSE instructions up to SSE 4.2 which are not all that useful.

I wouldn't say that, but sure, most enhancements in the vector ISA are targeted at specific workloads. The vector widening from SSE to AVX on the other hand benefits most (vectorizable) workloads.

Richard, are you sure about AVX? If I interpret https://en.wikipedia.org/wiki/X86-64#Microarchitecture_levels correctly, we only get AVX with on x86-64-v3 level. That is the reason I brought -v3 to the table. But unless we find a way to clone Dominique, the implementation probably won't work. Cheers, Pete -- Life without chameleons is possible, but pointless.

On Mon, Nov 28, 2022 at 06:35:12PM +0000, Richard Biener wrote:

On Mon, 28 Nov 2022, Hans-Peter Jansen wrote:

...

Am Freitag, 25. November 2022, 09:23:06 CET schrieb Richard Biener:

...

On Thu, 24 Nov 2022, Michal Such?nek wrote:

...

On Wed, Nov 23, 2022 at 05:34:12PM +0100, Dominique Leuenberger / DimStar wrote:

...

On Wed, 2022-11-23 at 17:24 +0100, Rainer Klier wrote:

...

will we as end-users notice any difference in operation, when we install packages from that x86-64-v2 repositories?

Unlikely, unless something breaks.

...

'It depends' on the workloads you run. We basically allow the compiler to use optimizations for newer CPU classes which is supposedly leading to improved performance. In some cases this can be noticable, in many cases it's only measurable.

Not even measurable. The benchmarks presented so far do not even show universal performance gain.

The v3 would be adifferent story but that would exclude way too many CPUs.

There are some highly parallelized programs that would significantly benefit from 128bit atomics but that sets the bar much lower than v2.

What v2 brings besides that are the SSE instructions up to SSE 4.2 which are not all that useful.

I wouldn't say that, but sure, most enhancements in the vector ISA are targeted at specific workloads. The vector widening from SSE to AVX on the other hand benefits most (vectorizable) workloads.

Richard, are you sure about AVX?

If I interpret https://en.wikipedia.org/wiki/X86-64#Microarchitecture_levels correctly, we only get AVX with on x86-64-v3 level.

That is the reason I brought -v3 to the table.

Yes, sorry - I was meant to say that the -v3 improvement is more obvious because AVX widens the vectors. -v2 only is going to improve more specific vectorizable workloads while -v3 is going to improve most vectorizable workloads.

As in compilling the whole distro for -v2 does not provide appreciable benefits because most of the specific workloads that benefit a lot from sse already use it in one way or another, and compiling general purpose code with it gives mixed results (as far as the few banchmarks provided show). Thanks Michal

Jiri Slaby composed on 2022-11-29 00:54 (UTC-0500):

Michal Suchánek wrote:

...

...

Yes, sorry - I was meant to say that the -v3 improvement is more obvious because AVX widens the vectors. -v2 only is going to improve more specific vectorizable workloads while -v3 is going to improve most vectorizable workloads.

...

As in compilling the whole distro for -v2 does not provide appreciable benefits because most of the specific workloads that benefit a lot from sse already use it in one way or another, and compiling general purpose code with it gives mixed results (as far as the few banchmarks provided show).

So can someone explain me at last why it was decided Leap/ALP adopts this then? It makes no sense to me. Neither performance-wise (there is almost no diff), nor maintenance-wise (there is almost no diff).

I haven't seen one, so I'm suspicious it's to avoid need to support non-UEFI installations. By the time v1 disappeared from the marketplace, so had lack of UEFI. Based on the little data I've seen or accumulated, all of which indicates trivial overall performance improvement, there must be some ulterior motive. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata

On Tue, Nov 29, Felix Miata wrote:

I haven't seen one, so I'm suspicious it's to avoid need to support non-UEFI installations.

1. UEFI is a hard requirement for TPM, so legacy BIOS is out anyways if you want to secure your system 2. Cloud is still prefering legacy BIOS, so security features are out in the cloud But since the main security features are requested by the public cloud providers, my guess is, they will also move from legacy BIOS to UEFI in the public cloud. Else their requirements don't make any sense. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman (HRB 36809, AG Nürnberg)

On 29. 11. 22, 8:24, Richard Biener wrote:

On Tue, 29 Nov 2022, Jiri Slaby wrote:

...

On 28. 11. 22, 20:10, Michal Such?nek wrote:

...

...

Yes, sorry - I was meant to say that the -v3 improvement is more obvious because AVX widens the vectors. -v2 only is going to improve more specific vectorizable workloads while -v3 is going to improve most vectorizable workloads.

As in compilling the whole distro for -v2 does not provide appreciable benefits because most of the specific workloads that benefit a lot from sse already use it in one way or another, and compiling general purpose code with it gives mixed results (as far as the few banchmarks provided show).

So can someone explain me at last why it was decided Leap/ALP adopts this then? It makes no sense to me. Neither performance-wise (there is almost no diff), nor maintenance-wise (there is almost no diff).

It was first decided to go with -v3 but then backtracked to -v2 for a variety of FUD & technical reasons. That there is Factory-First and the close ALP/Leap relationship didn't help of course.

Yes, in this particular case, the policy IMO sucks more than helps. So do an exception instead of rebuilding the whole TW because of some rigid rule?

Anyway, I kind-of agree that -v2 doesn't make much sense on its own but at least some advancement over x86-64 makes sense (for atomics and other minor details), but since there's no -v1.5 there's not much choice here (and yes, -v2 is kind of arbirtrary).

Croak on < "1.5" during runtime in glibc then and die. Still no point to pick arbitrary vX, provided there is still a heap of v2 out there. What required cpu features do you have in your mind regarding the atomics and other minor details? We might need to require those instead.

I think that even defaulting to -v2 is going to help some ISVs (since RHEL 9 now requires x86-64-v2), both in compatibility and performance.

I don't understand the compatibility point. With v1 we should be compatible "more", or not? Citation needed regarding performance. thanks, -- js suse labs

On Tue, 29 Nov 2022, Jiri Slaby wrote:

On 29. 11. 22, 8:24, Richard Biener wrote:

...

On Tue, 29 Nov 2022, Jiri Slaby wrote:

...

On 28. 11. 22, 20:10, Michal Such?nek wrote:

...

...

Yes, sorry - I was meant to say that the -v3 improvement is more obvious because AVX widens the vectors. -v2 only is going to improve more specific vectorizable workloads while -v3 is going to improve most vectorizable workloads.

As in compilling the whole distro for -v2 does not provide appreciable benefits because most of the specific workloads that benefit a lot from sse already use it in one way or another, and compiling general purpose code with it gives mixed results (as far as the few banchmarks provided show).

So can someone explain me at last why it was decided Leap/ALP adopts this then? It makes no sense to me. Neither performance-wise (there is almost no diff), nor maintenance-wise (there is almost no diff).

It was first decided to go with -v3 but then backtracked to -v2 for a variety of FUD & technical reasons. That there is Factory-First and the close ALP/Leap relationship didn't help of course.

Yes, in this particular case, the policy IMO sucks more than helps. So do an exception instead of rebuilding the whole TW because of some rigid rule?

...

Anyway, I kind-of agree that -v2 doesn't make much sense on its own but at least some advancement over x86-64 makes sense (for atomics and other minor details), but since there's no -v1.5 there's not much choice here (and yes, -v2 is kind of arbirtrary).

Croak on < "1.5" during runtime in glibc then and die. Still no point to pick arbitrary vX, provided there is still a heap of v2 out there.

What required cpu features do you have in your mind regarding the atomics and other minor details? We might need to require those instead.

cmpxchg16 was mentioned in that context

...

I think that even defaulting to -v2 is going to help some ISVs (since RHEL 9 now requires x86-64-v2), both in compatibility and performance.

I don't understand the compatibility point. With v1 we should be compatible "more", or not?

Well, if ISV builds their product on RHEL9 then they might hesitate to say it's certified for ALP since any "under the condition the HW can do -v2" will in practice be difficult to sell and support. And on the notion that -v2 is better than "-v0" they will likely refuse to build with that.

Citation needed regarding performance.

It always depends on the benchmark, but the more strong argument is marketing and manager perception. Richard. -- Richard Biener SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman; HRB 36809 (AG Nuernberg)

On Tue, 29 Nov 2022, Jiri Slaby wrote:

On 29. 11. 22, 10:17, Richard Biener wrote:

...

...

Croak on < "1.5" during runtime in glibc then and die. Still no point to pick arbitrary vX, provided there is still a heap of v2 out there.

What required cpu features do you have in your mind regarding the atomics and other minor details? We might need to require those instead.

cmpxchg16 was mentioned in that context

Which is very legible. Yet, despite my two CPUs are NOT so called "v2", they both support cmpxchg16 (cx16).

...

...

...

I think that even defaulting to -v2 is going to help some ISVs (since RHEL 9 now requires x86-64-v2), both in compatibility and performance.

I don't understand the compatibility point. With v1 we should be compatible "more", or not?

Well, if ISV builds their product on RHEL9 then they might hesitate to say it's certified for ALP since any "under the condition the HW can do -v2" will in practice be difficult to sell and support. And on the notion that -v2 is better than "-v0" they will likely refuse to build with that.

...

...

Citation needed regarding performance.

It always depends on the benchmark, but the more strong argument is marketing and manager perception.

Ah, I was so dumb and now I see -- it's only politics in it. And it affects community-based distro. Yes, I understand the SUSE's POV -- to sell, sell, sell. I also know, that managers always affected openSUSE in some manner. At least indirectly by e.g. providing HW, manpower etc. But this is sort of different. This appears to be a non-technical decision applied to _open_SUSE for reasons I still don't follow. And as a workaround, it seems it will result in building Tumbleweed exactly twice. Bah. OK.

Yep, the original -v3 decision was technical, the backtracking was political (openSUSE folks complained). Sticking to -v2 instead of plain x86-64 is then political as well. IMHO the mistake was to backtrack to -v2 for ALP. I didn't have a nice solution for the conflict with Factory-First or ALP and Leap sharing binary packages though. Richard. -- Richard Biener SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman; HRB 36809 (AG Nuernberg)

On Tue, 2022-11-29 at 10:46 +0100, Jiri Slaby wrote:

On 29. 11. 22, 10:17, Richard Biener wrote:

...

It always depends on the benchmark, but the more strong argument is marketing and manager perception.

Ah, I was so dumb and now I see -- it's only politics in it. And it affects community-based distro. Yes, I understand the SUSE's POV -- to sell, sell, sell. I also know, that managers always affected openSUSE in some manner. At least indirectly by e.g. providing HW, manpower etc. But this is sort of different. This appears to be a non-technical decision applied to _open_SUSE for reasons I still don't follow.

How about considering the following Factory/Tumbleweed has an important role as the target for SUSE's "Factory First" policy That function of Factory/Tumbleweed is a lynchpin that justifies the HW, manpower, etc that SUSE provide openSUSE for Factory/Tumbleweed A Factory/Tumbleweed that is still v0 when SUSE's commercial products are all v2 is significantly degraded/pointless in it's role as SUSE's "Factory First" target Ergo, it makes perfect sense that Factory/Tumbleweed must at least be v2 if SUSE is jumping to v2 (no matter SUSE's reasons, be they technical, political, religious, or otherwise) It's the right call, purely to ensure the relationship between Tumbleweed and SUSE's products remains relevant.

And as a workaround, it seems it will result in building Tumbleweed exactly twice. Bah. OK.

Well we don't NEED to build Tumbleweed twice. If we didn't have you or someone like you stepping up to take on the burden of looking after it, I'm pretty sure we wouldn't be doing the second build. Regards, -- Richard Brown Linux Distribution Engineer - Future Technology Team SUSE Software Solutions Germany GmbH, Frankenstraße 146, D-90461 Nuremberg, Germany (HRB 36809, AG Nürnberg) Managing Directors/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman

On Tue, Nov 29, 2022 at 10:46:58AM +0100, Jiri Slaby wrote:

On 29. 11. 22, 10:17, Richard Biener wrote:

...

...

Croak on < "1.5" during runtime in glibc then and die. Still no point to pick arbitrary vX, provided there is still a heap of v2 out there.

What required cpu features do you have in your mind regarding the atomics and other minor details? We might need to require those instead.

cmpxchg16 was mentioned in that context

Which is very legible. Yet, despite my two CPUs are NOT so called "v2", they both support cmpxchg16 (cx16).

And unlike the SSE required for x86_64-v2 it's pretty clear-cut, too. Intel Core2 and AMD K10 and later CPUs have cx16, once introduced it was never rertacted. The situation with SSE required for x86_64-v2 there are quite a few CPU generations in which SSE is on and off depending on product line. Another piece of trivia is that cx16 is required by Windows 8.1 or such so you can use those Windows certicication stickers to tell that you have it. Thanks Michal

On Tue, Nov 29, Jiri Slaby wrote:

On 28. 11. 22, 20:10, Michal Suchánek wrote:

...

...

Yes, sorry - I was meant to say that the -v3 improvement is more obvious because AVX widens the vectors. -v2 only is going to improve more specific vectorizable workloads while -v3 is going to improve most vectorizable workloads.

As in compilling the whole distro for -v2 does not provide appreciable benefits because most of the specific workloads that benefit a lot from sse already use it in one way or another, and compiling general purpose code with it gives mixed results (as far as the few banchmarks provided show).

So can someone explain me at last why it was decided Leap/ALP adopts this then? It makes no sense to me. Neither performance-wise (there is almost no diff), nor maintenance-wise (there is almost no diff).

ALP wanted -v3, but because if openSUSE -v2 was a compromise. At least as far as I have seen the discussions. -- Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman (HRB 36809, AG Nürnberg)

X86-64-v2 is the newest available feature level for Intel Atom, and old Intel Pentiums & Celerons. Intel uses Atom architecture for some servers. We cannot go further without proper support for glibc microarchitecture levels. For TW we have glibc and compilers (gcc & clang) being ready: https://www.phoronix.com/news/GCC-11-x86-64-Feature-Levels. We need support from package manager (RPM), which is absent right now. If all parts will work then it will be possible to ship v1 + v3, without useless v2. And we can introduce new level v1a instead of v1 and v2: v1a = v1 + {CMPXCHG16B, LAHF-SAHF, POPCNT, SSE3}. With v1a AMD K10 (Phenom & others) will work. Here are my suggestions: https://code.opensuse.org/leap/features/issue/79 - and they're SLE-accepted.

Neal Gompa wrote:

On Wed, Nov 30, 2022 at 4:23 PM Nikolai Nikolaevskii wrote:

...

X86-64-v2 is the newest available feature level for Intel Atom, and old Intel Pentiums & Celerons. Intel uses Atom architecture for some servers. We cannot go further without proper support for glibc microarchitecture levels. For TW we have glibc and compilers (gcc & clang) being ready: https://www.phoronix.com/news/GCC-11-x86-64-Feature-Levels. We need support from package manager (RPM), which is absent right now. If all parts will work then it will be possible to ship v1 + v3, without useless v2. And we can introduce new level v1a instead of v1 and v2: v1a = v1 + {CMPXCHG16B, LAHF-SAHF, POPCNT, SSE3}. With v1a AMD K10 (Phenom & others) will work. Here are my suggestions: https://code.opensuse.org/leap/features/issue/79 - and they're SLE-accepted. I should revise that to account for what actually happened afterward. It's now SLE-rejected since we're using x86_64-v2.

{CMPXCHG16B, LAHF-SAHF, POPCNT, SSE3} is a subset of x86_64-v2. So there is nothing to do.

On 01. 12. 22, 5:51, Jiri Slaby wrote:

On 30. 11. 22, 22:23, Nikolai Nikolaevskii wrote:

...

X86-64-v2 is the newest available feature level for Intel Atom, and old Intel Pentiums & Celerons. Intel uses Atom architecture for some servers.

I'm not sure what you are trying to say and who you are replying to. But Core2 Duo is _not_ v2 quite yet.

In particular, it appears not to have POPCNT and SSE4.2. It supports SSE4.1 though.

thanks,-- js suse labs

On Thu, 24 Nov 2022, Simon Lees wrote:

Hi,

On 11/24/22 07:57, Larry Len Rainey wrote:

...

Question:

With only 32 bit support to allow wine to run.

What about all the printer drivers that are 32bit. HP, Brother and Epson are all 32 bit printer drivers.

Are we going to lose the ability to print with the 32bit shrinkage?

Larry Rainey

Unix since 1973, Linux before Y2K.

If we are willing to maintain a set of -32bit packages for wine, maybe we should also assess if there are other usecases such as printer drivers with a clear set of requirements that we should also keep 32bit packages for.

I think it doesn't make sense to drop the basic 32bit system runtime which should be mostly glibc-32bit. Richard. -- Richard Biener SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman; HRB 36809 (AG Nuernberg)

On Wed, 23 Nov 2022 at 22:08, Marco Calistri wrote:

My Goodnees!!!

My laptop begins to be a bit aged now 😁

marco@linux-turion64:~> inxi -aC CPU: Info: model: Intel Core i5-2410M bits: 64 type: MT MCP arch: Sandy Bridge gen: core 2 level: v2 built: 2010-12 process: Intel 32nm family: 6 model-id: 0x2A (42) stepping: 7 microcode: 0x2F

I confess I am surprised at people considering a circa 2013 computer old or aged. I just bought myself another Thinkpad last week: a Thinkpad X220 with a Core i7. (I already have an X220, but mine is a Core i5 one and it's very battered with cracks in the case that I superglued together. The newer one is in excellent condition, with USB3 and a fingerprint reader.) This is a 2011 machine, and it's more than fast enough for my purposes. I have now got 2 × X220, 2 × T420 (in both instances, Core i5 plus Core i7 models), and W520 machines. All are in regular use, and all date back to 2011 or thereabouts. To me, they are fast modern multicore hyperthreaded 64-bit machines, with 8-16GB of RAM. I dislike newer Thinkpads, because they have much inferior keyboards. I really hate flat chiclet keyboards. Surely it is not just me? Anyway, I wanted to ask: Does this mean that Tumbleweed is officially dropping x86-32? -- Liam Proven ~ Profile: https://about.me/liamproven Email: lproven@cix.co.uk ~ gMail/gTalk/FB: lproven@gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053

On Thu, 2022-11-24 at 09:41 +0100, Jiri Slaby wrote:

On 23. 11. 22, 16:22, Dominique Leuenberger / DimStar wrote:

...

Community Actions Needed The :Intel port will require volunteers from the community to look after it. This will entail monitoring the builds, validating QA results (if not passing) and monitoring/pushing on bugs that are exclusive to these architectures

/me raises hands. With three "conditions": * I won't be alone in long term. * I won't care about i586 -- whoever cares about i586 should raise their hands now. * only as long as I own a working x86_64-v1 hardware. (Some more years, I assume.)

Thank you very much Jiri! Very much appreciated. Dominique

Hi, On Mon, Nov 28, Mathias Homann wrote:

Am Mittwoch, 23. November 2022, 16:22:30 CET schrieb Dominique Leuenberger / DimStar:

...

Dear Tumbleweed users and hackers,

...

Actions for Users:

Users of V2 compatible machines Users will automatically be upgraded to x86-64-v2 flavors (which is what we want to happen for the majority of users)

Users who can't migrate to V2 and i586 users The repository list will need to be updated away from download.o.o/tumbleweed/repo/oss to something like download.o.o/ports/intel/tumblewed/repo/oss

So just to clarify for stupid old me, I have three servers running on HP MicroServers N10 (x86_64 without any -v-something), Leap 15.5 is still going to support x86_64 (-v1), but then I'll either have to migrate to TW with those legacy repos, or buy three new servers?

If your hardware is so old, that it does not support Tumbleweed anymore, yes, either legacy repos or new servers. Don't forget: Tumbleweed as rolling release is using always the newest and greatest stuff. And sometimes this increases the requirements for hardware. Be the amount of memory, harddisk size or CPU features.

Related question, is there a **reliable** way to see one's hardware "level" when your /lib64/ld-linux*.so does not understand --help (yet)?

Boot a Tumbleweed installation media, switch to the text console or boot the rescue system, and run ld-linux.so with the --help option. This should work reliable. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman (HRB 36809, AG Nürnberg)

On Monday 2022-11-28 14:11, Mathias Homann wrote:

Related question, is there a **reliable** way to see one's hardware "level" when your /lib64/ld-linux*.so does not understand --help (yet)?

You could extract and run the ld-linux.so.2 from Tumbleweed's glibc.rpm. It is a standalone program after all.

On Tuesday 2022-11-29 22:53, Lukas Straub wrote:

Where do I vote against deprecating i586?

Who said you had a vote?

Am 30.11.22 um 00:26 schrieb Martin Schröder:

Am Di., 29. Nov. 2022 um 22:53 Uhr schrieb Lukas Straub :

...

Where do I vote against deprecating i586?

You 'vote' by stepping up to maintain that.

;-))) Peter

On Thu, Dec 01, 2022 at 10:25:22AM +0100, Jiri Slaby wrote:

On 23. 11. 22, 16:22, Dominique Leuenberger / DimStar wrote:

...

* openSUSE Tumbleweed main repository: + will move to x86-64-v2 (like ALP will)

Thinking about this more. Given we are going to have :LegacyX86 (likely?), can we move TW to -v3 instead?

_That_ would very make sense and _measurable benefit_ for vast majority of current machines.

Yes, if we are going to have two builds v1 and v3 makes more sense. This won't be aligned with the current ALP plan, though. ALP plans only one build, v3 as only the build was rejected on the basis it excludes way too much hardware, and there seems to be some political pressure to go with something other than the basseline. I think that investing into the infrastructure to make it possible to build and install select packages with support for newer CPUs in one way or another is really the way to go. Then users can benefit from the hardware features they have without excluding users that don't have them from using the distribution. Also with providing the packages for different CPUs in one way or another we would get at least some download statistics which could be used for some rough estimate about the prevalence of hardware with different features. At this point we have absolutely no data on that. Thanks Michal

On Sat, 03 Dec 2022 23:31:44 +0100, AW wrote:

Am Mittwoch, 23. November 2022, 16:22:30 CET schrieb Dominique Leuenberger / DimStar:

...

With this solution, we provide benefits to users of more recent machines than that of V1 by using the newer CPU instructions

This seems so obvious, but after a long discussion I haven't read any explanation yet.

So what would be the advantage of switching to v3? Yes, v3. I'm aware that TW will switch to v2, but can somebody compare v1 to v3, please? Would it be an advantage for users or for the maintenance of TW?

You want v1 to be compared to v3, assuming that TW (Tumbleweed) will be v2? Then the comparison should be of *what* as v1 or v3? -- Robert Webb

On Sun, 4 Dec 2022, Neal Gompa wrote:

On Sun, Dec 4, 2022 at 11:53 AM Larry Len Rainey wrote:

...

Microsoft has already spoken on v3, that is why Windows 11 requires Gen 8 I3, i5 and i7 and newer.

(I think they get a kickback on new PC and Laptop sales for the requirement).

The push for raising the x86_64 baseline for RHEL and SLE came from the CPU vendors.

That's not factually correct (for SUSE at least). The Toolchain team brings the opportunity to raise the architecture level to the table when a new codestream (SLE12, SLE15, now ALP) is developed. For SLE15 there was pushback from the CPU vendors because esp. Intel liked to differentiate products with ISA features. For ALP they were both indifferent, aka saw no reason to not raise to -v3 (which is what the Toolchain team proposed for ALP). There has been by no means any push from the CPU vendors to do this, that's just spreading FUD.

That's what triggered the creation of the x86_64 subarch variants (-v1, -v2, -v3). From discussions I've had with people familiar with the matter, they have been pressuring their commercial Linux vendor partners to raise the baseline for a few years now. Ultimately Red Hat compromised[1] and went with x86_64-v2 and while SUSE initially was going to go -v3, I pushed back pretty hard on this and helped make the compromise for -v2 happen for ALP as well.

Intel at some point lobbied to go for AVX-512 but do so by providing packages built for that in addition to the default ones. Richard. -- Richard Biener SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman; HRB 36809 (AG Nuernberg)

Am Montag, 5. Dezember 2022, 09:21:03 CET schrieb Martin Jambor:

The fact is that -v3 baseline means better floating point performance out of the box. That is why many think it is the right choice for a new product that will be deployed almost exclusively on new hardware. No need to invent conspiracy theories to explain what is happening.

Thank you very much for this start of an explanation. You see, even here on this list people lack the technical knowledge about advantages of -v3 and thus it's a good move to explain it. May I ask you to amend your answer a bit to the part »out of the box«? Does this mean -- right now -- that all the machines running TW and with a -v3 capable CPU don't get the improved floating point performance at all OR that they get it nonetheless, because -- while it does not work out of the box -- TW somehow manages to use the -v3 advantages? -- Regards, Alexander

Am Montag, 5. Dezember 2022, 17:07:43 CET schrieb Martin Jambor:

I hope this explains it,

Yes, and the Specs at github as well. Thank you very much !¡! Result from my point of view as a user on a quite recent machine: yes, I might lose a small margin of performance, but -- since I'm not into video / audio editing -- probably not even noticable and definitely not worth the trouble of compiling software on my own. -- Regards, Alexander

Hi, The more I think about it, the more wrong this approach looks to me. To get one thing out of the way: I'm fine with moving support for 32bit HW outside of openSUSE:Factory. That's truly legacy now and there are visible benefits by dropping it or making it "secondary". However, the decision to make openSUSE:Factory x86_64-v2 only has practically only downsides. Either we drop x86_64-v1 HW support completely, or introduce a project to build the distro for x86_64-v1 separately. At this point it looks like the latter is inevitable. That means: - It doubles the amount of builds and test runs (power, storage, time) - It doubles the release effort (looking at openQA, handling product changes, all the infrastructure) - It makes it necessary to migrate affected users over, which needs to work seamlessly but also inform them about this topic - It will be treated as a second-class distro, with bug reports getting less attention if "LegacyX86" is mentioned - There will be loss of functionality when some parts are not explicitly looked at for x86_64-v1. There might no longer be MicroOS/Live CDs/whatever built. (Which also means that "LegacyX86 solves your problems" is not true, at least not for long) - Various projects are not able to distinguish between x86-64 "levels", so it's not possible to seamlessly provide x86_64-v1 container and Vagrant images. (OCI/Docker can tell armv[5678] apart, but all amd64 is just amd64). What are the actual benefits of moving openSUSE:Factory to x86_64-v2 that make all this worth it? - "It's faster!": By how much? A lot of performance critical code already uses runtime dispatching, even Qt does that. It looks like x86_64-v2 alone does not have much performance improvement, based on the opinion of experts on this ML and (little) available data. At the highest end (HPC), custom builds with -march=native are preferred anyway. - "ALP wants us to because of 'Factory First'": The point of Factory First is to avoid extra work by addressing issues or adding features once for both upstream (oS:F) and downstream (SLE/ALP). In this case I don't think there's much (if any) benefit for ALP if Factory switches over. ALP will be built and tested separately anyway. If ALP hits some bug caused by x86_64-v2 and fixes that, this fix should be sent to openSUSE:Factory as well - that is Factory First! Switching to -v2 now also implies that there will be a switch to -v3 or later at some point in the future. Then we'll have this discussion all over again. That then implies dropping support for -v2, so we can only do that after -v2 is no longer relevant, which is much later than other distros which might already provide -v3+ binaries next to -v1/-v2. Am Dienstag, 6. Dezember 2022, 17:12:03 CET schrieb Lars Marowsky-Bree:

On 2022-12-05T17:07:43, Martin Jambor wrote:

...

Often they don't. To get the performance advantage you'd have to build the programs yourself of install them from a source which compiles them targeting a more recent ISA.

So I can see there may be some applications or libraries that do show significant improvement. Alright.

Would it be possible to have those few in an additional repo, or as .x86_64_vX architecture or something that gets pulled in when needed?

It really should be doable to build -v3 alongside -v1 (all of the distro or a hand-picked selection) and install the matching packages on capable hardware. That already works with i586/i686 and armv6/armv7 as well. That allows to be much more flexible and we'll be able to offer -v4+ support instantly as well. If there are concerns about additional build/test efforts - those will be less than with the current LegacyX86 design. Cheers, Fabian

Regards, Lars

On 12/7/22 23:12, Fabian Vogt wrote:

Hi,

The more I think about it, the more wrong this approach looks to me.

To get one thing out of the way: I'm fine with moving support for 32bit HW outside of openSUSE:Factory. That's truly legacy now and there are visible benefits by dropping it or making it "secondary".

However, the decision to make openSUSE:Factory x86_64-v2 only has practically only downsides. Either we drop x86_64-v1 HW support completely, or introduce a project to build the distro for x86_64-v1 separately. At this point it looks like the latter is inevitable. That means:

- It doubles the amount of builds and test runs (power, storage, time) - It doubles the release effort (looking at openQA, handling product changes, all the infrastructure) - It makes it necessary to migrate affected users over, which needs to work seamlessly but also inform them about this topic - It will be treated as a second-class distro, with bug reports getting less attention if "LegacyX86" is mentioned - There will be loss of functionality when some parts are not explicitly looked at for x86_64-v1. There might no longer be MicroOS/Live CDs/whatever built. (Which also means that "LegacyX86 solves your problems" is not true, at least not for long) - Various projects are not able to distinguish between x86-64 "levels", so it's not possible to seamlessly provide x86_64-v1 container and Vagrant images. (OCI/Docker can tell armv[5678] apart, but all amd64 is just amd64).

What are the actual benefits of moving openSUSE:Factory to x86_64-v2 that make all this worth it? - "It's faster!": By how much? A lot of performance critical code already uses runtime dispatching, even Qt does that. It looks like x86_64-v2 alone does not have much performance improvement, based on the opinion of experts on this ML and (little) available data. At the highest end (HPC), custom builds with -march=native are preferred anyway. - "ALP wants us to because of 'Factory First'": The point of Factory First is to avoid extra work by addressing issues or adding features once for both upstream (oS:F) and downstream (SLE/ALP). In this case I don't think there's much (if any) benefit for ALP if Factory switches over. ALP will be built and tested separately anyway. If ALP hits some bug caused by x86_64-v2 and fixes that, this fix should be sent to openSUSE:Factory as well - that is Factory First!

Switching to -v2 now also implies that there will be a switch to -v3 or later at some point in the future. Then we'll have this discussion all over again. That then implies dropping support for -v2, so we can only do that after -v2 is no longer relevant, which is much later than other distros which might already provide -v3+ binaries next to -v1/-v2.

On the plus side if we do end up with a -v1 port then it makes the -v3 discussion much easier to have again once ALP is released or close to release and tumbleweed is more free to move away from it, so in a year and a half to 2 years we could possibly have just -v1 and -v3 in tumbleweed which is what most people feel is best we just have to go via -v2 until such a time as this major version of ALP is released or in beta. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

On Wed, 7 Dec 2022, Aaron Puchert wrote:

Am 05.12.22 um 09:21 schrieb Martin Jambor:

...

The fact is that -v3 baseline means better floating point performance out of the box.

Are the VEX-prefixed single-data instructions really faster, i.e. addsd vs vaddsd or mulsd vs vmulsd? I thought compilers emit the latter preferably if available only to avoid the need for vzeroupper and not because they're faster, but I admit I haven't benchmarked this.

No, they are not faster - unless the upper portions of the destination register is not cleared (as you say, vzeroupper is needed to avoid this situation). But they are bigger. Richard. -- Richard Biener SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman; HRB 36809 (AG Nuernberg)

On Monday 2022-12-05 10:54, Thomas Zimmermann wrote:

Or could we beef-up our support for the old i586 a bit, so that the -v1 systems could run this instead?

You first. Go and take the -44% then see how that goes. https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/C...

On Mon, 5 Dec 2022, Thomas Zimmermann wrote:

Hi

Am 05.12.22 um 11:46 schrieb Jan Engelhardt:

...

On Monday 2022-12-05 10:54, Thomas Zimmermann wrote:

...

Or could we beef-up our support for the old i586 a bit, so that the -v1 systems could run this instead?

You first.

Go and take the -44% then see how that goes. https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/C...

It was a simple question.

I'm grateful that there still is i586 support in TW and I don't claim that promoting i586 would be without problems. However, with limited resources available, dropping -v1 and investing a bit more into i586 might be a better choice than having both, -v1 and i586, in bad shape.

A -v0 x86_64 kernel with a i586 userland might do, but I understand using a 32bit kernel is really bad for a x86_64 capable CPU. Note that in case we want to advance to a mixed -vN system with packages selected according to CPU requirements we'd still need a pure -v0 installer / image to bootstrap this. Keeping such a thing officially maintained looks quite sensible to me. Richard. -- Richard Biener SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman; HRB 36809 (AG Nuernberg)

Hi Am 05.12.22 um 17:47 schrieb Larry Len Rainey:

Ok,

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?

I think the problem is that hardware and software life cycles have long decoupled themselves from each other. Ten-year-old PC hardware is typically not old, but a 10-month-old web browser might well be.

If the hardware is old - force them to go to Leap or other Linux flavors that specialize in i586 and 32 bit stuff.

That sounds like a major break from current practice. Even more than any -v2 changes. Best regards Thomas

I know that the Levovo IdeaStick 300 (2017) could not run Tumbleweed or Leap as the BIOS only supported 32 bit UEFI code. That forced me to Sparky Linux on those computers as they had a 32 bit /boot/EFI that worked.

The sales pitch that I used with Walmart to go to Unix (and later to Linux) is if you dislike the vendor - you can switch to another with little application impact (if on the same processor family). Walmart like to play the hardware vendors against each other - they had NCR MPRAS, IBM AIX and HP HPUX machines all running the same apps to force lower pricing. Sometimes, it does not pay to migrate to newer, Walmart has an application they cannot find a "cost acceptable" replacement and it still runs on a 1989 100 mhz 486 running NCR MPRAS 1.0. - they have stockpiles bunches of used old NCR 486 machine and dozens of SCSI I drives that the old Microchannel computers use. That application is so embedded with other applications that it would cost millions to replace it and most of the programs that use it may not have the source code to change.

I have switched from Mandrake to Fedora, to Centos, to openSUSE and every application and script I wrote worked (sometime after recompiling from 32 bit to 64 bit). I use Tumbleweed for osc development on 8th Gen Intel processors - You can find nice 8th gen units on eBay for under $250 with everything including Windows 11. I also have Leap 15.4 as my primary computer OS.

Sometimes it is "Time to cut bait" as American say when the fishing is so bad you go home.

Larry Rainey - (VirtualBox co-support with Larry Finger).

Sorry about the ramble, I used to be marketing then support.

-- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev

Hello, On Mon, Dec 05, 2022 at 10:47:33AM -0600, Larry Len Rainey wrote:

Ok,

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?

One of the things that Linux has going for it is that it is not particularly picky about hardaware - it can run pretty much on anything, even the newest versions.

If the hardware is old - force them to go to Leap or other Linux flavors

Except it's not clear Leap wiil. It certainly does not do 32bit.

that specialize in i586 and 32 bit stuff.

I know that the Levovo IdeaStick 300 (2017) could not run Tumbleweed or Leap as the BIOS only supported 32 bit UEFI code. That forced me to Sparky Linux on those computers as they had a 32 bit /boot/EFI that worked.

The sales pitch that I used with Walmart to go to Unix (and later to Linux) is if you dislike the vendor - you can switch to another with little application impact (if on the same processor family). Walmart like to play the hardware vendors against each other - they had NCR MPRAS, IBM AIX and HP HPUX machines all running the same apps to force lower pricing. Sometimes, it does not pay to migrate to newer, Walmart has an application they cannot find a "cost acceptable" replacement and it still runs on a 1989 100 mhz 486 running NCR MPRAS 1.0. - they have stockpiles bunches of used old NCR 486 machine and dozens of SCSI I drives that the old Microchannel computers use. That application is so embedded with other applications that it would cost millions to replace it and most of the programs that use it may not have the source code to change.

I have switched from Mandrake to Fedora, to Centos, to openSUSE and every application and script I wrote worked (sometime after recompiling from 32 bit to 64 bit). I use Tumbleweed for osc development on 8th Gen Intel processors - You can find nice 8th gen units on eBay for under $250 with everything including Windows 11. I also have Leap 15.4 as my primary computer OS.

One of the benefits Linux distributions may offer is that they run on all my hardaware. If I have to change the distribution on one machine I am likely to migrate the others as well for consistency. While a program may work on all of the distributions the network settings and other system settings are implemented differently, there are different package managers, etc. I do not want to deal with that stuff when I am actively using under a dozen machines that are not particularly exotic.

Sometimes it is "Time to cut bait" as American say when the fishing is so bad you go home.

Such as go to another distro that does not impose arbitrary restrictions on the hardware that you can use, sure. Most of them actually don't as far as x86-vN goes because there have been no proven technical benefits to doing it that would outweigh the costs of replacing a lot of hardware on the user side as well as the distro infrastructure side. This discussion is, however, about Tumbleweed and how Tumbleweed can balance development and maintenanace effort with utility for the users. My personal view is that the userbase of openSUSE is not so large that we have to actively turn users away. Thanks Michal

Hi Am 05.12.22 um 18:57 schrieb Michal Suchánek:

This discussion is, however, about Tumbleweed and how Tumbleweed can balance development and maintenanace effort with utility for the users.

My personal view is that the userbase of openSUSE is not so large that we have to actively turn users away.

I agree.

Thanks

Michal

-- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev

On Tue, 2022-12-06 at 09:15 +0100, Mathias Homann wrote:

Here is my personal situation: If openSUSE/TW enforces -v2 or higher I will have to either buy new hardware for my home server or find a new linux for my homeserver.

OR: people that care look after the Legacy X86 port. It's all open source - you can't always expect 'somebody else' to do all the work for you. Sometimes you have to invest work too (not meaning you, Mathias, as a singular, but rather 'you, the people that care') Cheers, Dominique

On 12/6/22 09:29, Juergen Gross wrote:

On 06.12.22 09:23, Dominique Leuenberger / DimStar wrote:

...

OR: people that care look after the Legacy X86 port.

It's all open source - you can't always expect 'somebody else' to do all the work for you. Sometimes you have to invest work too (not meaning you, Mathias, as a singular, but rather 'you, the people that care')

Hmm, is this fair?

Good question.

"Someone" has decided to go with x86_64-v2, forcing others to either do more work or buy new hardware. And now you blame the "others" to expect "somebody else" to do the work for them. I'm also wondering why SUSE thinks anybody in the community would appreciate this move. Overall it's very discouraging.

It would be fair if the one deciding to go with -v2 would do this work.

Yupp. Ciao, Michael.

On Tue, 2022-12-06 at 10:16 +0100, Stephan Kulow wrote:

On 06.12.22 09:40, Michael Ströder wrote:

...

...

"Someone" has decided to go with x86_64-v2, forcing others to either do more work or buy new hardware. And now you blame the "others" to expect "somebody else" to do the work for them. I'm also wondering why SUSE thinks anybody in the community would appreciate this move. Overall it's very discouraging.

I for one still need to hear *any* argument to duplicate x86_64. The only one I heard was "factory first" - but how do the compiler flags matter between code streams that will soon enough diverge in compiler versions wasn't really explained at all.

so, your proposed solution would be to just kick i586 to the curbs (ports) and leave the x86_64 port at baseline? Or go v3? or not build x86_64 for baseline and go v2 in TW? or ignore everything and let it all just the way it is?

On Tue, 6 Dec 2022, Stephan Kulow wrote:

On 06.12.22 10:23, Dominique Leuenberger / DimStar wrote:

...

On Tue, 2022-12-06 at 10:16 +0100, Stephan Kulow wrote:

...

On 06.12.22 09:40, Michael Str?der wrote:

...

...

"Someone" has decided to go with x86_64-v2, forcing others to either do more work or buy new hardware. And now you blame the "others" to expect "somebody else" to do the work for them. I'm also wondering why SUSE thinks anybody in the community would appreciate this move. Overall it's very discouraging.

I for one still need to hear *any* argument to duplicate x86_64. The only one I heard was "factory first" - but how do the compiler flags matter between code streams that will soon enough diverge in compiler versions wasn't really explained at all.

so, your proposed solution would be to just kick i586 to the curbs (ports) and leave the x86_64 port at baseline? Or go v3? or not build x86_64 for baseline and go v2 in TW? or ignore everything and let it all just the way it is? I would indeed prefer if we dropped i586 before we touched x86_64. And having v2/v3 biarch repo sounds appealing to me - but obviously is a little harder to get.

Just to (again) chime in here, my prefered solution would be to continue building Tumbleweed with -v0 and build ALP with -v3 (OK, for other reasons that's going to be -v2). That is, "break" the Factory-First policy here. It's not that the prjconf is the same between Factory and SLE and this detail could be confined to a prjconf difference (in practice I hope to configure GCC itself to a different default). But as you say - politics :/ But sure, having v2/v3 repos for select packages and those auto-selected would have been my cheap solution for those who want that on Tumbleweed. Thanks, Richard. -- Richard Biener SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman; HRB 36809 (AG Nuernberg)

On 12/6/22 10:45, Richard Biener wrote:

Just to (again) chime in here, my prefered solution would be to continue building Tumbleweed with -v0 and build ALP with -v3 (OK, for other reasons that's going to be -v2). That is, "break" the Factory-First policy here.

Why not splitting out a port for -v3 and keep main Tumbleweed at -v0?

But as you say - politics :/

Politics exists, but is not an argument itself. Ciao, Michael.

Hi Richard, Am Di., 6. Dez. 2022 um 10:45 Uhr schrieb Richard Biener :

Just to (again) chime in here, my prefered solution would be to continue building Tumbleweed with -v0 and build ALP with -v3 (OK, for other reasons that's going to be -v2). That is, "break" the Factory-First policy here.

There is no breakage of the factory first policy here. Factory first is defined in the open source policy: https://opensource.suse.com/legal/policy and it talks about considering the *sources* of factory as an intermediary upstream for the regularly maintained (SLE, Leap) products. It doesn't talk about sharing the compiler flags at all, these changes could remain a downstream distribution choice without "breaking" the factory first policy. Greetings, Dirk

On 06.12.22 10:50, Dominique Leuenberger / DimStar wrote:

think RPM should also gain some support as it should not just call the arch x86_64 in this case, but differentiate between the subsets we would build for.

Requires: cpufeatures(cx16, avx512, xyz) in all packages? And in the worst case some "aaa_base-arch-x86_64-v3" package that provides this in the beginning, later maybe rpm can get this automatically? -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman

On Tuesday 2022-12-06 11:29, Dominique Leuenberger / DimStar wrote:

Nothing will stop the installation of such a baseline package, and on the other hand probably nothing will pull it in if the user does not do it - as zypper does not have a clue about subarchs (yet).

Or does it? There is glibc.i686 and it would appear zypper knows when to (not) install it.

Dominique Leuenberger / DimStar writes:

On Tue, 2022-12-06 at 11:19 +0100, Stefan Seyfried wrote:

...

On 06.12.22 10:50, Dominique Leuenberger / DimStar wrote:

...

think RPM should also gain some support as it should not just call the arch x86_64 in this case, but differentiate between the subsets we would build for.

Requires: cpufeatures(cx16, avx512, xyz)

in all packages? And in the worst case some "aaa_base-arch-x86_64-v3" package that provides this in the beginning, later maybe rpm can get this automatically?

Nothing will stop the installation of such a baseline package, and on the other hand probably nothing will pull it in if the user does not do it - as zypper does not have a clue about subarchs (yet).

And besides that, it would still give us two packages with the exact same name in the repo as the rpm would still be called NVR.x86_64.rpm; for this, rpm would need to learn about it (or we rename all packages to N_v3-V-R.x86_64.rpm for that - which in turn requires creating _multibuild for everything (to add a second flavor, as a 2nd repo would use the same names) and manual overrides of the optflags (of course via macros).

There's been a bit of discussion around supporting sub-architectures in RPM (e.g. [1]), but I haven't seen any clear progress in this regard. Introducing hacks like _multibuild for many packages will unfortunately further degrade the packager UX, which I'd like to avoid. Cheers, Dan Footnotes: [1] https://github.com/rpm-software-management/rpm/discussions/2140 -- Dan Čermák Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman

Hi Am 06.12.22 um 09:23 schrieb Dominique Leuenberger / DimStar:

On Tue, 2022-12-06 at 09:15 +0100, Mathias Homann wrote:

...

Here is my personal situation: If openSUSE/TW enforces -v2 or higher I will have to either buy new hardware for my home server or find a new linux for my homeserver.

OR: people that care look after the Legacy X86 port.

It's all open source - you can't always expect 'somebody else' to do all the work for you. Sometimes you have to invest work too (not meaning you, Mathias, as a singular, but rather 'you, the people that care')

To me, this sounds like 'We're going to break your computer. Fix it if you care.' That's somehow not right. And I think the discussion here shows that people do care. Best regards Thomas

Cheers, Dominique

-- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev

Hi Am 06.12.22 um 09:38 schrieb Dominique Leuenberger / DimStar:

On Tue, 2022-12-06 at 09:31 +0100, Thomas Zimmermann wrote:

...

Hi

Am 06.12.22 um 09:23 schrieb Dominique Leuenberger / DimStar:

...

On Tue, 2022-12-06 at 09:15 +0100, Mathias Homann wrote:

...

Here is my personal situation: If openSUSE/TW enforces -v2 or higher I will have to either buy new hardware for my home server or find a new linux for my homeserver.

OR: people that care look after the Legacy X86 port.

It's all open source - you can't always expect 'somebody else' to do all the work for you. Sometimes you have to invest work too (not meaning you, Mathias, as a singular, but rather 'you, the people that care')

To me, this sounds like 'We're going to break your computer. Fix it if you care.' That's somehow not right. And I think the discussion here shows that people do care.

As much as another group of people DOES care to stay relevant in a Factory-First model for SLE/ALP. It's not news that Tumbleweed is the distro running ahead of SLE/ALP in helping ensuring to find issues before the changes reach the commercial products (with a lot of openQA in order to not abuse the TW-userbase as guinea pigs).

How much worth do you see for a commercial entity to sponsor workforce on something that has little to no benefit to them in the end? If they still have to do all the work a 2nd time for the commercial products, because whatever is being tested/used outside is not representative?

I've seen this reasoning before and it didn't turn out well. Before I came to SUSE, I worked at Mozilla for several years. The organization's management is somewhat disconnected from its community. They cut features and functionality on a similar rational: 'That's not relevant to our core business and/or product, so we stop maintaining it. Volunteers can take over if they care.' But volunteers are also always invested emotionally in their community. So over time, this reasoning destroyed a lot of goodwill and drove away community. I would attribute the decline of Firefox' marketshare to these decisions to some extend. Best regards Thomas

The ports setup is something we offered to do, people need to commit to care enough to look after it. If using the port is 'too much hassle for the users', then there is probably not much we can do (the ports build from the exact same sources, each checkin to openSUSE:Factory immediately triggers relevant rebuilds in the ports; only the release to QA and to the mirrors in case of passed QA is timely decoupled from the main branch, in exactly the same way as ARM, PowerPC, s390x, RISCV.

Cheers, Dominique

-- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev

On Tue, 2022-12-06 at 10:17 +0100, John Paul Adrian Glaubitz wrote:

On 12/6/22 09:38, Dominique Leuenberger / DimStar wrote:

...

How much worth do you see for a commercial entity to sponsor workforce on something that has little to no benefit to them in the end? If they still have to do all the work a 2nd time for the commercial products, because whatever is being tested/used outside is not representative?

I would argue that a lot of the porter work is done outside openSUSE, so we usually will have to report bugs upstream only and update packages accordingly.

It's not like x86_64-v1 is as unmaintained as ia64 is ;-).

Adrian

Yeah..and? You seem to be agreeing with each other here. Dominique is pointing out that the non-port, mainline, of Tumbleweed/Factory will be continuing on its merry way aligned with the needs of openSUSE's main sponsor. The sponsor, who I add, provides all of our build hardware, all of our test hardware, and all of our release management manpower for Factory mainline. In addition, that sponsor is willing/not opposed to allowing reuse of that build and test hardware in the persuit of a port that takes care of the LegacyX86 systems that will no longer be served by mainline Factory. That is generous, I wouldn't have been surprised if such an opportunity was not available. Even more so, that sponsor is even willing/not opposed to some of that release management manpower being spent *enabling* the creation of that port. That is also generous - You don't think Dominique started this thread out of the kindness of his heart, do you? But, a line has to be drawn somewhere, and the long term, ongoing, release management/wrangling of the LegacyX86 port will, just like all of our other ports, need volunteers to do it. And I think that's perfectly reasonable. SUSE can't be expected to maintain things that are irrelevant for their business, and Legacy X86 architectures that SUSE has no intention of ever producing new commercial software for is certainly irrelevant to their business. So..if people care, people need to step up and do the work. It's Open Source, It's Free Software, and _THIS_ is what community is about..stepping up to do the work when it needs to be done..not making demands that other people should do work for you, for free. Regards, Rcihard

On Tue, 2022-12-06 at 10:46 +0100, John Paul Adrian Glaubitz wrote:

On 12/6/22 10:35, Richard Brown wrote:

...

Dominique is pointing out that the non-port, mainline, of Tumbleweed/Factory will be continuing on its merry way aligned with the needs of openSUSE's main sponsor.

The sponsor, who I add, provides all of our build hardware, all of our test hardware, and all of our release management manpower for Factory mainline.

That's what I meant in my other mail: openSUSE is not a porter- friendly distribution.

What you are describing here, e.g. build hardware, is a no-brainer in Debian, for example. We've got one loaner machine from IBM plus two PowerKVM instances, both hosted as OSUOSL at Oregon State University and have more than enough capacity to build packages for 32-bit and 64-bit PowerPC as well as providing a porter box to developers, i.e. test hardware.

If providing a second x86_64 baseline in openSUSE causes so much pain and effort, it's a problem with how the distribution is maintained and not with the porting idea in general.

Adrian

And openSUSE has a wonderfully well maintained aarch64 port. And IBM provided hardware and Tumbleweed once had a very well maintained ppc64 port when we had contributors taking care of it. The problem isn't the 'porter-friendliness' of the distribution, the problem is a lack of people actually engaging with the opportunities already available to contribute and being far happier to complain instead of contributing. LegacyX86 could very well be the next port success story after aarch64, it's got the hardware, it's clearly got users who want it, it's already got bootstrapped thanks to Dominique. Now it just needs someone to look after it in perpututy because Dominique won't/can't So..how about we call this nonsense thread to a close? those people who want to care for LegacyX86 can start caring for it, and everyone else can just shut up with the nonproductive noise?

On 2022-12-06 13:16, John Paul Adrian Glaubitz wrote:

On 12/6/22 10:53, Richard Brown wrote:

...

The problem isn't the 'porter-friendliness' of the distribution

It is. Otherwise I would have already added a multitude of ports to openSUSE. It's just too complicated.

I talked to multiple SUSE people with experience in that regard and they all told me that openSUSE has no easy approach for bootstrapping the distribution for a new target.

And yet you clearly didn't speak to any SUSE people who are actually involved in bootstrapping ports, because Dirk and Andreas handled it pretty smoothly for RISCV Or of course Dominique who started this thread did it already for LegacyX86 faster during the time you've spent telling everyone how hard it is

...

So..how about we call this nonsense thread to a close?

That's not how mailing list discussions work :-).

Well at least your willingness to continue to demonstrate your ignorance is transparent

On 12/6/22 14:31, Richard Brown wrote:

On 2022-12-06 13:16, John Paul Adrian Glaubitz wrote:

...

On 12/6/22 10:53, Richard Brown wrote:

...

The problem isn't the 'porter-friendliness' of the distribution

It is. Otherwise I would have already added a multitude of ports to openSUSE. It's just too complicated.

I talked to multiple SUSE people with experience in that regard and they all told me that openSUSE has no easy approach for bootstrapping the distribution for a new target.

And yet you clearly didn't speak to any SUSE people who are actually involved in bootstrapping ports, because Dirk and Andreas handled it pretty smoothly for RISCV

I talked to Andreas and he told me there is no straight-forward way and it involved a lot of manual work. In fact, he admitted he used some packages from Debian for easier bootstrapping for riscv64. I also had a discussion with Marcus Schäfer on the topic and the response was a similar one.

Or of course Dominique who started this thread did it already for LegacyX86 faster during the time you've spent telling everyone how hard it is

That was not a bootstrap. A bootstrap means building a binary distribution for a new architecture completely from source. Dominique copied existing binaries over to a new repo or at least the base system to build the rest of the repo. Debian has a project called reboostrap which does a full bootstrap from source to any architecture of your choice with any baseline:

https://jenkins.debian.net/view/rebootstrap/ https://wiki.debian.org/HelmutGrohne/rebootstrap

...

...

So..how about we call this nonsense thread to a close?

That's not how mailing list discussions work :-).

Well at least your willingness to continue to demonstrate your ignorance is transparent

It would be nice if you don't answer with rudeness and insults if people express constructive criticism against openSUSE. Acting like that within a community isn't particularly helpful if you want to find new contributors. Adrian

On 06. 12. 22, 9:38, Dominique Leuenberger / DimStar wrote:

As much as another group of people DOES care to stay relevant in a Factory-First model for SLE/ALP. It's not news that Tumbleweed is the distro running ahead of SLE/ALP in helping ensuring to find issues before the changes reach the commercial products (with a lot of openQA in order to not abuse the TW-userbase as guinea pigs).

How much worth do you see for a commercial entity to sponsor workforce on something that has little to no benefit to them in the end? If they still have to do all the work a 2nd time for the commercial products, because whatever is being tested/used outside is not representative?

Sorry, but this is not the case. Even if TW didn't follow Factory-first rule here, the test base of all the things is quite large. So the above is not true at all. So if any manager has a problem with this, let me talk to them. Following your "little benefit" argument above, the compiler will be most of the time different in TW and any other/older distro (be it ALP or Leap). So the nuances between compilers (and compiler flags) will be much more different than v0 vs v2 would be now. That is, would they have to do the work 2nd time only because TW will be at gcc 13 and Leap at gcc 12? No. regards, -- js suse labs

Hi Mathias, On 06.12.22 09:15, Mathias Homann wrote:

Here is my personal situation: If openSUSE/TW enforces -v2 or higher I will have to either buy new hardware for my home server or find a new linux for my homeserver.

I was on the exact same boat, just that I would have had some time as my home server runs Leap ;-)

Now put this in the limelight of the current economical situation, with inflation AND crazy price hikes from the energy providers: which is more likely?

Energy price would actually hint that you look at getting a newer machine. Yes, I did not think this was true, too. My old machine (FUJITSU ESPRIMO E5730, Core2 Duo E8500@3.16GHz, 8GB RAM) was using about 40W idling (disks off,...). The new one (FUJITSU ESPRIMO P757, Core i3-6100@3.70GHz, 8GB RAM) is using about 20W in the same configuration. 20 Watts saved is about 175kWh per year. I'm going to pay 38,92¢/kWh from 2023-01-01. This means I'm going to save about 68€ per year with the new machine. The machine cost about 85€ from a professional seller on ebay. Do your own math. (Even if the machine is under load, I could not spot higher power usage than the old machine had, but I did not do sufficiently large samples to be 100% sure. Even if the peak power consumption is higher, it is probably also much faster finished with the cpu intensive task. But as this server is mostly idling >90% of the time, there was just no reason to conduct extensive tests on this). I'm all for keeping old machines running. But the "energy cost for my 24/7 running home server" argument is not a good one to make. Have fun, -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman

On 2022-12-05 18:57, Michal Suchánek wrote:

Hello,

On Mon, Dec 05, 2022 at 10:47:33AM -0600, Larry Len Rainey wrote:

...

Ok,

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?

One of the things that Linux has going for it is that it is not particularly picky about hardaware - it can run pretty much on anything, even the newest versions.

...

If the hardware is old - force them to go to Leap or other Linux flavors

Except it's not clear Leap wiil. It certainly does not do 32bit.

...

that specialize in i586 and 32 bit stuff.

I know that the Levovo IdeaStick 300 (2017) could not run Tumbleweed or Leap as the BIOS only supported 32 bit UEFI code. That forced me to Sparky Linux on those computers as they had a 32 bit /boot/EFI that worked.

The sales pitch that I used with Walmart to go to Unix (and later to Linux) is if you dislike the vendor - you can switch to another with little application impact (if on the same processor family). Walmart like to play the hardware vendors against each other - they had NCR MPRAS, IBM AIX and HP HPUX machines all running the same apps to force lower pricing. Sometimes, it does not pay to migrate to newer, Walmart has an application they cannot find a "cost acceptable" replacement and it still runs on a 1989 100 mhz 486 running NCR MPRAS 1.0. - they have stockpiles bunches of used old NCR 486 machine and dozens of SCSI I drives that the old Microchannel computers use. That application is so embedded with other applications that it would cost millions to replace it and most of the programs that use it may not have the source code to change.

I have switched from Mandrake to Fedora, to Centos, to openSUSE and every application and script I wrote worked (sometime after recompiling from 32 bit to 64 bit). I use Tumbleweed for osc development on 8th Gen Intel processors - You can find nice 8th gen units on eBay for under $250 with everything including Windows 11. I also have Leap 15.4 as my primary computer OS.

One of the benefits Linux distributions may offer is that they run on all my hardaware. If I have to change the distribution on one machine I am likely to migrate the others as well for consistency. While a program may work on all of the distributions the network settings and other system settings are implemented differently, there are different package managers, etc.

I do not want to deal with that stuff when I am actively using under a dozen machines that are not particularly exotic.

...

Sometimes it is "Time to cut bait" as American say when the fishing is so bad you go home.

Such as go to another distro that does not impose arbitrary restrictions on the hardware that you can use, sure. Most of them actually don't as far as x86-vN goes because there have been no proven technical benefits to doing it that would outweigh the costs of replacing a lot of hardware on the user side as well as the distro infrastructure side.

This discussion is, however, about Tumbleweed and how Tumbleweed can balance development and maintenanace effort with utility for the users.

My personal view is that the userbase of openSUSE is not so large that we have to actively turn users away.

Agree to all. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)

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? And now the key question: Why should Tumbleweed cut off supporting old hardware if nobody benefits from this move? 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.

Am Montag, 5. Dezember 2022, 21:26:02 CET schrieb Per Jessen:

Michael Strc3b6der 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?

And now the key question:

Why should Tumbleweed cut off supporting old hardware if nobody benefits from this move?

I'm opposed to this change.

+1

+1. I seriously believe we (openSUSE) should *not* drop an architecture(- level) that is (still) supported by the kernel. Also: From what I've gathered from all this discussion it'll be mainly floating point number crunching that benefits from -v2 or higher, unless I missed something. ...the average desktop system spends 99.99999999% of its cpu cycles by simply waiting for user input. Which applications ship with Leap today that will actually and *NOTICEABLY* benefit from -v2 or higher could just be offered for -v2/3 by means of an additional, rather small, repo... Seriously, is there a list of applications that would show a noticeable difference? I'd guess long running stuff like blender or ffmpeg, perhaps? Cheers MH -- Mathias Homann Mathias.Homann@openSUSE.org Jabber (XMPP): lemmy@tuxonline.tech Matrix: @mathias:eregion.de IRC: [Lemmy] on freenode and ircnet (bouncer active) keybase: https://keybase.io/lemmy gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102

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

On Montag, 5. Dezember 2022 10:54:09 CET Thomas Zimmermann wrote:

Hi,

I don't have a strong opinion on this topic, but after the long discussion about using old systems, I wondered if we could get an idea about the number of users with then-obsolete machines.

I couldn't find information about x86 CPU market share so I looked at Windows releases instead. Statcounter has information on that. [1] The worldwide stats looks something like this:

Win11: ~16%; Win10: ~70%; Win8.x: ~3.5%; Win7: ~10%; WinXP: ~0.5%

There's no clear connection between Windows releases and CPUs, so the metric is somewhat fuzzy. According to Wikipedia, Windows 7 was first released in 2009 and Windows 8 in 2012. x86-64-v2 was also released in 2009, but wasn't present in AMD CPUs until 2013.

Assuming that Windows 7 systems don't support -v2, but Windows 8 systems do, around 10% of _possible_ would not be supported by dropping pre-v2. That might be worth the performance/feature gains or not; IDK.

Many people still using Windows 7 do because they dislike the design changes introduced with Windows 8. Otherwise, Win8 market share would be higher (also requires just v1, same as Win7). Intel systems shipped between 2009 and 2012 shipped with Windows 7 but likely support v2.

Windows 10 and -v3 were both first released in 2015. It's much less clear what the impact would be. Win 11 requires it, so at least 16% of the possible users could use it. On pre-Windows 10 systems, -v3 is probably not supported. And for Windows 10 systems, IDK.

Lucky me obviously had a time machine when I bought my Haswell systems (x86_64-v3) in 2013. Though, for the Pentium and Celeron budget line, you have to wait until 2019 (Icelake) for AVX2. Win 11 runs on e.g. a Celeron G5900, which is v2 only (no AVX). So, your factual statements are full of errors already. Any interpretations based thereon are moot. Stefan

On Dienstag, 6. Dezember 2022 01:03:53 CET Felix Miata wrote:

Stefan Brüns composed on 2022-12-05 22:08 (UTC+0100):

...

Lucky me obviously had a time machine when I bought my Haswell systems (x86_64-v3) in 2013. Though, for the Pentium and Celeron budget line, you have to wait until 2019 (Icelake) for AVX2.

Win 11 runs on e.g. a Celeron G5900, which is v2 only (no AVX).

2017 Kaby Lake Pentium G4600 not yet 6 years old not only lacks AVX/AVX2, but also v3's:

BMI, BMI2, F16C, FMA, LZCNT

My 2013 Haswell Pentium G3220 falls short of v2, unless LAHF-SAHF & SSE3 are aliases to something else it does have:

You removed the context from the quote. This was a response to:

...

...

Windows 10 and -v3 were both first released in 2015.

Core-i3/i5/i7 Haswell from 2013 has AVX2. This does not imply all Haswells support AVX2. I even mentioned Pentiums had no AVX2 until 2019 (i.e. 3 years ago) - both your Kaby Lake and your Haswell Pentium are older. Stefan

Hi Am 05.12.22 um 22:08 schrieb Stefan Brüns:

On Montag, 5. Dezember 2022 10:54:09 CET Thomas Zimmermann wrote:

...

Hi,

I don't have a strong opinion on this topic, but after the long discussion about using old systems, I wondered if we could get an idea about the number of users with then-obsolete machines.

I couldn't find information about x86 CPU market share so I looked at Windows releases instead. Statcounter has information on that. [1] The worldwide stats looks something like this:

Win11: ~16%; Win10: ~70%; Win8.x: ~3.5%; Win7: ~10%; WinXP: ~0.5%

There's no clear connection between Windows releases and CPUs, so the metric is somewhat fuzzy. According to Wikipedia, Windows 7 was first released in 2009 and Windows 8 in 2012. x86-64-v2 was also released in 2009, but wasn't present in AMD CPUs until 2013.

Assuming that Windows 7 systems don't support -v2, but Windows 8 systems do, around 10% of _possible_ would not be supported by dropping pre-v2. That might be worth the performance/feature gains or not; IDK.

Many people still using Windows 7 do because they dislike the design changes introduced with Windows 8. Otherwise, Win8 market share would be higher (also requires just v1, same as Win7). Intel systems shipped between 2009 and 2012 shipped with Windows 7 but likely support v2.

...

Windows 10 and -v3 were both first released in 2015. It's much less clear what the impact would be. Win 11 requires it, so at least 16% of the possible users could use it. On pre-Windows 10 systems, -v3 is probably not supported. And for Windows 10 systems, IDK.

Lucky me obviously had a time machine when I bought my Haswell systems (x86_64-v3) in 2013. Though, for the Pentium and Celeron budget line, you have to wait until 2019 (Icelake) for AVX2.

The year 2015 comes from the Wikipedia page on the topic. I think they took it from AMD's Excavator. https://en.wikipedia.org/wiki/Excavator_(microarchitecture) All the numbers I listed come from Wikipedia.

Win 11 runs on e.g. a Celeron G5900, which is v2 only (no AVX).

So, your factual statements are full of errors already. Any interpretations based thereon are moot.

I said that I wanted to 'get an idea about the number of users with then-obsolete machines'. I also stated that 'There's no clear connection between Windows releases and CPUs, so the metric is somewhat fuzzy.' Please don't read more into it. I'm also aware that the Windows userbase is different from openSUSE's user demographic. So anything here does not say much about current users, but potential ones. Best regards Thomas

Stefan

-- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev

Hi, Am Di., 6. Dez. 2022 um 21:28 Uhr schrieb llyyr :

I really apologize if this has already been discussed, but do we have any benchmarks for how much of a speed up we're expecting in some use cases? I looked at the benchmarks Arch Linux did and it appears that there's not a big enough improvement for the effort to move to x86-64-v2 to be worth it, unless we move to x86-64-v3.

That's pretty much the summary, still. -v2 generally does not bring any tangible benefit except for a few specific cases (in which -v3 would bring significantly more). so the best option would indeed be -v0 with selected packages as -v3 when needed. Greetings, Dirk

On 2022-12-07 13:07, Dirk Müller wrote:

so the best option would indeed be -v0 with selected packages as -v3 when needed.

How this should be done? Maybe having openSUSE:Factory as v0, and openSUSE:Factory:V3 with a project config to set it as v3, and duplicating a very small subset of packages in the subproject? Should a generator add some `Requires: ($magic)` for those v3, and make a change in libsolv that will prioritize them in case of the correct hardware is present?

aplanas writes:

On 2022-12-07 13:07, Dirk Müller wrote:

...

so the best option would indeed be -v0 with selected packages as -v3 when needed.

How this should be done? Maybe having openSUSE:Factory as v0, and openSUSE:Factory:V3 with a project config to set it as v3, and duplicating a very small subset of packages in the subproject?

Yes.

Should a generator add some `Requires: ($magic)` for those v3, and make a change in libsolv that will prioritize them in case of the correct hardware is present?

That is not enough, because you'll end up with two rpms with exactly the same architecture and thereby potentially with the same NEVR. Any tooling that relies on rpm will not be able to distinguish these two packages and could pick the wrong one. The correct solution for this is to implement subarchitectures in rpm. Cheers, Dan -- Dan Čermák Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman

Hi Dan, Am Mi., 7. Dez. 2022 um 14:08 Uhr schrieb Dan Čermák :

That is not enough, because you'll end up with two rpms with exactly the same architecture and thereby potentially with the same NEVR. Any tooling that relies on rpm will not be able to distinguish these two packages and could pick the wrong one.

That is not a problem, if you restrict this to shared libraries. lets make an example with zstd (arbitrary choice). you have zstd (/usr/bin/zstd) which requires a shared library libzstd.so.1. This is provided by libzstd1.x86_64 in opensuse (built for x86_64-v0). you can in addition to that provide a libzstd1-x86_64-v3.x86_64 package (so new name, same architecture) which contains the v3 optimized library in the hwcaps subdirectory. it does *not* provide anything by itself, but supplements libzstd1.x86_64. in this setup, both packages are co-installable. the solver would only ever install the x86_64-v0 variant (so compatibility is always there) but if available, and --with-recommends is enabled, the -v3 package is installed in *addition*, and dynamically used automatically at runtime if hardware can do it. so you have the following choices: * really minimal (disk size) installations turn off --recommends, or remove the -v3 repo, and only get the x86_64-v0 (which is anyway code wise smaller, so if you want it, you get the smaller binary) * default installations get both libraries installed, so your hardware selects which variant gets picked. you get the better one if better hardware allows it. * you can not accidentally wreck your system by installing the -v3 variant only because it does not provide anything, so the solver would prevent you from doing something stupid. This would be implementable via the existing build-baselibs mechanics which we use for building the -32bit/-64bit packages for years (by repacking them into a new name on the other architecture). it feels like this is relatively easy to implement. Greetings, Dirk