Tumbleweed - Move to x86-64-v2 (plus mitigation plan and call for help)
Dear Tumbleweed users and hackers, I'm sorry to bring up an old topic once again, but it is an important one and I believe we have found a solution that works for most users and still allows openSUSE Tumbleweed to move ahead. openSUSE Factory repository is be repurposed to move forward with x86-64-v2, and openSUSE:Factory:Intel will be set up as openSUSE Factory currently exists today. This change is necessary to align with the SUSE factory first policy (https://opensource.suse.com/legal/policy) to keep aligned with the project's sponsor's development efforts. The discussed and agreed upon solution forward is the following: Repurpose of Factory * openSUSE Tumbleweed main repository: + will move to x86-64-v2 (like ALP will) + i586 support will be dropped from the repository (i.e. only x86-64-v2 left) + -32bit packages as needed by wine and such will remain present (but no complete repo to be installed meaning only the necessary -32bit parts for specific packages will exist) 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 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 With this solution, we provide benefits to users of more recent machines than that of V1 by using the newer CPU instructions (and staying aligned, and thus relevant, with ALP). Yet this provides a path for users to still run Tumbleweed on machines that might not have the needed hardware. **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.** Cheers, Dominique
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 Andreas -- Andreas Jaeger aj@suse.com Twitter: jaegerandi SUSE Software Solutions Germany GmbH, Frankenstr.146, D 90461 Nürnberg (HRB 36809, AG Nürnberg) GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman GPG fingerprint = EF18 1673 38C4 A372 86B1 E699 5294 24A3 FF91 2ACB
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
On 23/11/2022 16.30, Dominique Leuenberger / DimStar wrote:
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)
Hi Dominique, That works for me, Thanks, Andreas -- Andreas Jaeger aj@suse.com Twitter: jaegerandi SUSE Software Solutions Germany GmbH, Frankenstr.146, D 90461 Nürnberg (HRB 36809, AG Nürnberg) GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman GPG fingerprint = EF18 1673 38C4 A372 86B1 E699 5294 24A3 FF91 2ACB
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.
Am Mittwoch, 23. November 2022, 16:30:35 CET schrieb Dominique Leuenberger / DimStar:
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)
After diving into it.. 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. 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 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. Then we would have 1.02 times effort to maintain x86-64-v1, x86-64-v2 and x86-64-v3 repository variants. Greetings, Björn
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 10:44, Dominique Leuenberger / DimStar wrote:
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.
Okay, I understand, openQA and OBS needs additional resources for each repository. As a compromise, openQA could be only enabled for the hardware version with the most users (probably v2). The v1 users will then see problems a little more often.
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.
If I am affected as a developer or administrator depends on the fact, which would be the minimum supported version. All my machines support at least v2, but only 50% support v3. Probably some of the v2 machines will be exchanged in the next years. My next developer machine will the v4. I am more concerned about my customers. Some of them use SLES, but most prefer Windows servers. They use old versions of SLES and Windows and relatively old server hardware. Already now it is difficult to persuade customers to upgrade their SLES mayor version e.g. to get more recent database server versions. If they hear, that the next SLES will not support their old hardware, they will probably use SLES 11 until EOL and then move everything to Windows server. You said, nothing comes for free. But loosing SLES customers is also problem. Greetings, Björn
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 11/29/22 21:25, Stefan Seyfried wrote:
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... ;-)
Nah it still has some LTSS support kicking on atleast for now. -- 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 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
Bjoern Voigt wrote:
I am more concerned about my customers. Some of them use SLES, but most prefer Windows servers. They use old versions of SLES and Windows and relatively old server hardware. Already now it is difficult to persuade customers to upgrade their SLES mayor version e.g. to get more recent database server versions. If they hear, that the next SLES will not support their old hardware, they will probably use SLES 11 until EOL and then move everything to Windows server. You said, nothing comes for free. But loosing SLES customers is also problem. Greetings, Björn
Leap 15.5 (= SLE 15 SP5) will be supported till the end of 2024, with x86-64-v1 support. With SLE subscription you'll get up to 5 or 10 years of support for it. Windows Server (and Windows 8.1 64-bit & newer) requirements (CMPXCHG16b, LAHF/SAHF, PrefetchW at least as NOOP) means using CPUs that are newer than Intel Nehalem (x86-64-v2, 2008 year), for AMD it'll be AMD K8 on AM2 (2006 year). https://learn.microsoft.com/en-us/windows-server/get-started/hardware-requir... What hardware is in use by your customers? Server hardware upgrade can be very profitable - less machines, less space, much less power bills.
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
On Friday 2022-11-25 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)
You had the balls to create openSUSE:Factory:LegacyX86 so that changed the care-o-meter metrics of and for the playing field. I'll put forward to stern options: # TW stays v2 and I care about :LegacyX86 as much as I do for :zSystems # 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. (I don't know if i586 involvement could be meaningfully measured, or whether the contributions were not insignificant enough to make a difference, so I'll just run with the statistical uncertainty.) [1] <20221129084848.GA28663@suse.com>
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
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? 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. Adrian
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
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. Larry
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
On Tue, Nov 29, 2022 at 12:21:08PM +0100, Thomas Zimmermann wrote:
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/
I don't think there are many people who actually use this for anything but occasional cross-architecture testing but it's the Factory that becomes our stable release eventually. The ppc64 big endian port is useful when you want to test some big endian quirk and don't want to run your test on a mainframe.
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.
Besides building the distribution (which tends to bitrot on 32bit because upstream maintainers tend to care little about their software building with only 2G address space, and on 32bit architectures in general) we also lack support for the Apple pmap and HFS in the installer. These machines used to be nice but are rare, getting one is pretty expensive because the ones that survived until now are colloctor items, and the performance is not as great as it used to due to increasing performance requirements of software over time. Thanks Michal
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
Dne 23.11.2022 16:22, Dominique Leuenberger / DimStar napsal:
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
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? -- Vojtěch Zeisek https://trapa.cz/ Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux https://www.opensuse.org/
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
On Wednesday 2022-11-23 16:48, Dominique Leuenberger / DimStar wrote:
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).
Well, consider it another incentive for 3rd parties to submit their packages to Factory. Think of all the free porting to receive from Factory:ARM, Factory:RISCV, Factory:PowerPC, etc. :-D (Non-free software is obviously exempt. But the labor intensity was already in the name: *not* *free*)
hi, Am 23.11.22 um 16:22 schrieb Dominique Leuenberger / DimStar:
openSUSE Factory repository is be repurposed to move forward with x86-64-v2, and
sorry to ask such dumb question, but what is a x86-64-v2 system? i know CPU architecures like ARM, x86 and x86-64 but what do you mean with x86-64-v2? which CPUs belong to that category? and does every tumbleweed user know under which category the used CPU belongs? -- Best Regards | Freundliche Grüße | Cordialement | Cordiali Saluti | Atenciosamente | Saludos Cordiales *DI Rainer Klier* DevOps, Research & Development
On Wed, 2022-11-23 at 16:56 +0100, Rainer Klier wrote:
hi,
Am 23.11.22 um 16:22 schrieb Dominique Leuenberger / DimStar:
openSUSE Factory repository is be repurposed to move forward with x86-64-v2, and
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
i know CPU architecures like ARM, x86 and x86-64
but what do you mean with x86-64-v2?
which CPUs belong to that category?
That started around Nehalem/Jaguar chipsets, back in 2009; Some might have come a bit later. Nevertheless, most somewhat decent machine will be v2 compatible (e.g my Notebook is from 2014 and supports even the v3 set)
and does every tumbleweed user know under which category the used CPU belongs?
Probably not - that's certainly going to be a fun challenge (see also my reply to Vojtech) The quickest ways to find out if your CPU is -v2 (or newer) are, on a current Tumbleweed system: $ /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) HTH, 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, 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?
'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. Cheers, Dominique
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
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. -- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman; HRB 36809 (AG Nuernberg)
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, 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. Richard. -- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman; HRB 36809 (AG Nuernberg)
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
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). thanks, -- js suse labs
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 29. 11. 22, 7:14, Felix Miata wrote:
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.
If that was the reason, we can kick this out of the distros and I can become grub 2 maintainer again to support non-EFI systems in some :legacy project. As that's by the order of magnitude easier than maintaining full-rebuilt TW-v1 there :P. Yes, I know, it's currently more than grub (like installer support). But having working grub is actually sufficient condition to install and run anything. -- js suse labs
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 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. 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). 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. Richard. -- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman; HRB 36809 (AG Nuernberg)
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 29. 11. 22, 8:36, Jiri Slaby wrote:
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.
Or even s/glibc/kernel/. Like it complains about missing long mode support for 32bit processors.
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 <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman; HRB 36809 (AG Nuernberg)
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. -- js suse labs
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 <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman; HRB 36809 (AG Nuernberg)
On 29. 11. 22, 10:50, Richard Biener wrote:
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.
Yes, -v3 would actually very make technical sense for ALP.
IMHO the mistake was to backtrack to -v2 for ALP.
Agreed.
I didn't have a nice solution for the conflict with Factory-First or ALP and Leap sharing binary packages though.
Nice solution? Ignore the policy in this regards! Sometimes policies need to be lifted. After all, the same way it was already done for TW's full-stack ix86 long time ago. It wasn't abandoned when Leap's was. Note that I specifically named TW. I'm not sure we can/will build Leap and ALP differently. At least it was repeated many times, that ALP and Leap won't share this decision (I remember Coolo was one of the ones repeatedly noting this). -- js suse labs
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 29. 11. 22, 10:54, Richard Brown wrote:
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
We (I literally mean we: me and others) maintainted Tumbleweed even without this "Factory First" policy. And surprise, it well made sense and was supported even then.
That function of Factory/Tumbleweed is a lynchpin that justifies the HW, manpower, etc that SUSE provide openSUSE for Factory/Tumbleweed
Nah. What justifies all that are the results. Not a policy, sorry.
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
Could you elaborate on that "degraded/pointless"? We cover ix86 in TW and TW is not degraded in any way due to that WRT to SUSE. It's rather mostly we waste resource to build it. Including -v0 (I am not inclined to -v0 BTW, having cx16 sounds like a reasonable cut, as I wrote elsewhere) by any means does not make TW will have less coverage and testing. Quite the contrary. So this is a very legit reason when potentially talking to SUSE managers.
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.
Yep, covering -v2 _plus_ a bit older machines fulfills the role even more. Again, those machines are still quite alive and will be for more years.
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.
Yep, we can force the users to migrate to another (saner) distro. Less coverage, less testing, less cookies. That's what would managers love to hear. Note that I'm still concerned about the picking up of "v2" to be the right choice and spread it everywhere. From the technical POV, it is not (saying so while wearing one of few x86 maintainers hats inside SUSE). regards, -- js suse labs
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, 2022 at 09:17:56AM +0000, Richard Biener wrote:
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.
Won't we have that great ld.so in ALP that can clearly tell you what bag of random features is fully implemented by your CPU? And yes, -v2 is quite difficult to support, even for the whole distribution. It's difficult to tell in advance if your hardware is compliant or not. 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)
On 29. 11. 22, 9:48, Thorsten Kukuk wrote:
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.
Sorry, but how does this answer my concerns? Namely, why is ALP picking any vX at all? Who decided that and what lead them to the decision? I just want to make sure this was decided based on technical basis by people who understand the problem well and what it both brings and takes. And with ALP picking v2, it's even less reasonable. So what's the matter? -- js suse labs
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.
On Wed, Nov 30, 2022 at 4:23 PM Nikolai Nikolaevskii <kaykaykay123@gmail.com> 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. -- 真実はいつも一つ!/ Always, there's only one truth!
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 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. thanks, -- js suse labs
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
Il 23/11/22 13:14, Dominique Leuenberger / DimStar ha scritto:
On Wed, 2022-11-23 at 16:56 +0100, Rainer Klier wrote:
hi,
Am 23.11.22 um 16:22 schrieb Dominique Leuenberger / DimStar:
openSUSE Factory repository is be repurposed to move forward with x86-64-v2, and 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
i know CPU architecures like ARM, x86 and x86-64
but what do you mean with x86-64-v2?
which CPUs belong to that category? That started around Nehalem/Jaguar chipsets, back in 2009; Some might have come a bit later. Nevertheless, most somewhat decent machine will be v2 compatible (e.g my Notebook is from 2014 and supports even the v3 set) and does every tumbleweed user know under which category the used CPU belongs? Probably not - that's certainly going to be a fun challenge (see also my reply to Vojtech)
The quickest ways to find out if your CPU is -v2 (or newer) are, on a current Tumbleweed system:
$ /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)
HTH, Dominique
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 Best regards! -- Marco Calistri Build: openSUSE Tumbleweed 20221122 Kernel: 6.0.8-1-default - XFCE: (4.16.0)
On Wednesday 2022-11-23 22:27, Larry Len Rainey wrote:
What about all the printer drivers that are 32bit. Are we going to lose the ability to print with the 32bit shrinkage?
People lamenting the loss x86-64-v0 system support in some places... understandable. People lamenting the loss of i586 operating system support... well ok if you're really an enthusiast and have something to show. People lamenting the loss of fixed-bit field-specific, vendor-locked, unportable and/or non-free software... sorry, ran out of sympathies. Apple has been pushing for driverless printing for the past decade (or thereabout). https://en.wikipedia.org/wiki/AirPrint https://en.wikipedia.org/wiki/Internet_Printing_Protocol """IPP is the basis of several printer logo certification programs including AirPrint, IPP Everywhere, and Mopria Alliance, and is supported by over 98% of printers sold today."""
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. -- 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 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 <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman; HRB 36809 (AG Nuernberg)
On Thu, Nov 24, 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.
Since we want to keep wine I'm pretty sure most 32bit printer drivers will continue to work out of the box. The only and real problem is: the packaging of this drivers is very often terrible broken :( As an example, RPM requires: cups-libs >= 1.1.17 libstdc++.so.6(CXXABI_1.3.1) /bin/sh But ldd says: linux-gate.so.1 (0xf7f51000) libcups.so.2 => /usr/lib/libcups.so.2 (0xf7e77000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xf7c5e000) libm.so.6 => /lib/libm.so.6 (0xf7b5a000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xf7b3c000) libc.so.6 => /lib/libc.so.6 (0xf7952000) libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0xf78f7000) libgnutls.so.30 => /usr/lib/libgnutls.so.30 (0xf770c000) libavahi-common.so.3 => /usr/lib/libavahi-common.so.3 (0xf76fd000) libavahi-client.so.3 => /usr/lib/libavahi-client.so.3 (0xf76e9000) libpthread.so.0 => /lib/libpthread.so.0 (0xf76c8000) libz.so.1 => /lib/libz.so.1 (0xf76af000) /lib/ld-linux.so.2 (0xf7f53000) libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0xf75d0000) libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0xf75b6000) libcom_err.so.2 => /lib/libcom_err.so.2 (0xf75b1000) libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0xf75a0000) libp11-kit.so.0 => /usr/lib/libp11-kit.so.0 (0xf7540000) libdl.so.2 => /lib/libdl.so.2 (0xf753b000) libtasn1.so.6 => /usr/lib/libtasn1.so.6 (0xf7526000) libnettle.so.6 => /usr/lib/libnettle.so.6 (0xf74e8000) libhogweed.so.4 => /usr/lib/libhogweed.so.4 (0xf74ae000) libgmp.so.10 => /usr/lib/libgmp.so.10 (0xf741f000) libidn2.so.0 => /usr/lib/libidn2.so.0 (0xf7400000) libunistring.so.2 => /usr/lib/libunistring.so.2 (0xf7279000) libdbus-1.so.3 => /usr/lib/libdbus-1.so.3 (0xf721b000) libkeyutils.so.1 => /usr/lib/libkeyutils.so.1 (0xf7215000) libresolv.so.2 => /lib/libresolv.so.2 (0xf71fd000) libcrypto.so.1.1 => /usr/lib/libcrypto.so.1.1 (0xf6f2d000) libselinux.so.1 => /lib/libselinux.so.1 (0xf6f00000) libffi.so.7 => /usr/lib/libffi.so.7 (0xf6ef7000) libsystemd.so.0 => /usr/lib/libsystemd.so.0 (0xf6e09000) libpcre.so.1 => /usr/lib/libpcre.so.1 (0xf6d7d000) librt.so.1 => /lib/librt.so.1 (0xf6d73000) liblzma.so.5 => /usr/lib/liblzma.so.5 (0xf6d31000) libzstd.so.1 => /usr/lib/libzstd.so.1 (0xf6c8f000) liblz4.so.1 => /usr/lib/liblz4.so.1 (0xf6c6c000) libcap.so.2 => /usr/lib/libcap.so.2 (0xf6c66000) libgcrypt.so.20 => /usr/lib/libgcrypt.so.20 (0xf6b84000) libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0xf6b5c000) ... -- 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 Wed, 23 Nov 2022 at 22:08, Marco Calistri <PY1ZRJ@outlook.com> 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 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.) thanks, -- js suse labs
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
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.) > thanks, Just hopeful I get to keep 32bit libs for gstreamer (old games that uses mpeg)
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? Or am I still misunderstanding things? Related question, is there a **reliable** way to see one's hardware "level" when your /lib64/ld-linux*.so does not understand --help (yet)? Yes, I know "that perl script" and yes I know that there's some way to have inxi to show the hwcaps, but I've also seen those two come up with a different result on the same box. So - what's the rub? 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
On Mon, Nov 28, 2022 at 4:11 PM Mathias Homann <Mathias.Homann@opensuse.org> 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)?
Yes, I know "that perl script" and yes I know that there's some way to have inxi to show the hwcaps, but I've also seen those two come up with a different result on the same box.
I am not aware of the Perl script, but last time I looked inxi was wrong (it was over optimistic and detected too high a level). awk script posted during the last discussion on this topic should be mostly correct (there is a theoretical corner case, but it was believed to be theoretical only).
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)
Am Montag, 28. November 2022, 14:41:02 CET schrieb Thorsten Kukuk:
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.
hmmmm what about a docker image... yep, that works: akari:~ # docker run opensuse/tumbleweed /lib64/ld-linux-x86-64.so.2 --help [output deleted...] Subdirectories of glibc-hwcaps directories, in priority order: x86-64-v4 x86-64-v3 x86-64-v2 Legacy HWCAP subdirectories under library search path directories: x86_64 (AT_PLATFORM; supported, searched) tls (supported, searched) avx512_1 x86_64 (supported, searched) 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
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 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. thanks, -- js suse labs
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 01. 12. 22, 10:43, Michal Suchánek wrote:
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.
Yeah, but I don't care about ALP at all in the above. AIU the politics, Factory has to have more, but not less. Which is satisfied by the above.
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.
Agreed, having a v3-only build is a no-go, ATM. So keep ALP at v2 (which is nonsense from technical POV, but OK).
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.
+1. We can even have v2 for TW from the beginning to test the Factory -> Factory:LegacyX86 repo switch on fewer machines. Collect the download data of v2. And do the switch to v3. And collect the data again. We would know how much is v2 of use and v3 too. thanks, -- js suse labs
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? Thank you! -- Regards, Alexander
Am Sa., 3. Dez. 2022 um 23:32 Uhr schrieb AW <alexander.willand@t-online.de>:
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?
If I understand the politics (and I believe this is more politics/sales then tech driven) correctly, RH decided on -v2 for RHEL9, SUSE followed with -v2 for SLES 16/ALP and since TW/LEAP follow SLES... Don't know about Debian/Ubuntu/*BSD/... IMHO there may be benefits of v2/v3/v4 for HPC and servers/hyperscalers, but I've not yet seen anybody claiming that end users (e.g. browsers/vlc/...) will *notice* any difference in the near future. This might be different in 2030++, and the move to v2 is probably the start of moving to v3++ with RHEL10/SLES 17. Best Martin PS: https://developers.redhat.com/blog/2021/01/05/building-red-hat-enterprise-li... PPS: Have Linus or Greg voiced any opinion in this regard? PPPS: Any word from Microsoft?
On Sat, 03 Dec 2022 23:31:44 +0100, AW <alexander.willand@t-online.de> 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
Am Sonntag, 4. Dezember 2022, 00:15:41 CET schrieb Robert Webb:
On Sat, 03 Dec 2022 23:31:44 +0100, AW <alexander.willand@t-online.de> 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?
As far as I have understood the discussion here the switch to v2 is a kind of compromise and won't do much good, but get things starting. But I'd be interested to know what the potential advantages could be, compromise aside. So I asked for a comparison between v1 and v3. -- Regards, Alexander
On Sun, Dec 4, 2022 at 11:53 AM Larry Len Rainey <llrainey15@gmail.com> 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 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. (As an aside, Microsoft gets paid for every new PC sale in the form of a Windows license, and OEMs are incentivized to sell more because it lowers their per unit costs and gets them better deals in the future.) [1]: https://developers.redhat.com/blog/2021/01/05/building-red-hat-enterprise-li... -- 真実はいつも一つ!/ Always, there's only one truth!
On Sun, 4 Dec 2022, Neal Gompa wrote:
On Sun, Dec 4, 2022 at 11:53 AM Larry Len Rainey <llrainey15@gmail.com> 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 <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman; HRB 36809 (AG Nuernberg)
Hello, On Sun, Dec 04 2022, Neal Gompa wrote:
On Sun, Dec 4, 2022 at 11:53 AM Larry Len Rainey <llrainey15@gmail.com> 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.
The above statement is not true, at least as far as SUSE is concerned.
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.
For what is worth, I have been part of most of discussions between AMD and SUSE for the last eight years, I would have noticed and been asked to comment if AMD ever raised this. They never have. I repeat: they never have. In fact it was me personally who brought this to their attention after we had the huge thread about this in summer and their response was "do whatever you think will is best." I am not aware of anybody from Intel attempting anything similar either and again if there was concentrated effort I would. 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. Martin
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
Hi, On Mon, Dec 05 2022, AW wrote:
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.
I have shared SPEC results illustrating the point on this mailing list in the summer (and they are still available at https://jamborm.github.io/spec-2022-07-29-levels/index.html )
May I ask you to amend your answer a bit to the part »out of the box«?
The software you install from Tumbleweed repositories target the distribution base ISA (Instruction Set Architecture) which is currently v1. If the base was moved to v3, those programs would use AVX256 which quite often speeds floating-point operations. See e.g. ImageMagick results in the report linked above.
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?
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. The exception is software where the authors themselves included specialized versions of heavily used functions which take advantage of new CPUs and run those if a new CPU is detected. Video codecs and glibc string functions fall into this category. I hope this explains it, Martin
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
On 2022-12-05T17:07:43, Martin Jambor <mjambor@suse.cz> 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? Regards, Lars -- SUSE Software Solutions Germany GmbH Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman (HRB 36809, AG Nürnberg)
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 <mjambor@suse.cz> 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 Wed, 2022-12-07 at 13:42 +0100, Fabian Vogt wrote:
The more I think about it, the more wrong this approach looks to me.
As someone who is just an openSUSE user (it's on all my systems), and a contributor of some minor packages, I fully agree with Fabians assessment. In particular his summary:
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!
The rebuttal of why "ALP want us to" is spot on. (And just to be clear: None of my hardware would be obsoleted by an upgrade to v2. In fact, all of it would benefit from an upgrade to -v3. But, like Fabian, I still don't think it's a good idea to raise the bar for the entire distribution in the way currently suggested.) Regards, Olav
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
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. Aaron
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 <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman; HRB 36809 (AG Nuernberg)
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. 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. BTW it's worth to look at the regional stats for Windows usage. Africa and South America still have higher usage of older Windows releases, but only by a few percent. Interestingly Windows 7 still has a marketshare of ~23% in India. I guess this has been discussed already, but could '-v2' support be provided for selected packages only, while the default packages would remain at -v1? The installer would then suggest to enable an additional repo with those v2-packages that take precedence over their v1-builds. I assume that kernel, glibc, Mesa and BLAS could make use of the additional CPU features, but most packages probably not. (?) Or could we beef-up our support for the old i586 a bit, so that the -v1 systems could run this instead? In my experience, TW on i586 works well, except for those programs that use SSE2, which most of the i586 CPUs don't support. But -v0 always has SSE2. Best regards Thomas [1] https://gs.statcounter.com/os-version-market-share/windows/desktop/worldwide... Am 23.11.22 um 16:22 schrieb Dominique Leuenberger / DimStar:
Dear Tumbleweed users and hackers,
I'm sorry to bring up an old topic once again, but it is an important one and I believe we have found a solution that works for most users and still allows openSUSE Tumbleweed to move ahead. openSUSE Factory repository is be repurposed to move forward with x86-64-v2, and openSUSE:Factory:Intel will be set up as openSUSE Factory currently exists today. This change is necessary to align with the SUSE factory first policy (https://opensource.suse.com/legal/policy) to keep aligned with the project's sponsor's development efforts.
The discussed and agreed upon solution forward is the following:
Repurpose of Factory * openSUSE Tumbleweed main repository: + will move to x86-64-v2 (like ALP will) + i586 support will be dropped from the repository (i.e. only x86-64-v2 left) + -32bit packages as needed by wine and such will remain present (but no complete repo to be installed meaning only the necessary -32bit parts for specific packages will exist)
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
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
With this solution, we provide benefits to users of more recent machines than that of V1 by using the newer CPU instructions (and staying aligned, and thus relevant, with ALP). Yet this provides a path for users to still run Tumbleweed on machines that might not have the needed hardware.
**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.**
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 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...
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. Best regards Thomas -- 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 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 <rguenther@suse.de> 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
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.
That is a VERY VALID point and a big change from when I started working with computers back in the mid 1980's! I think that is a big reason why people are pushing back on this change which does not seem to consider that point. Also reading the benchmarks that others have done it does not seem like there is much benefit to the change going with v2. I've been following this ongoing discussion since it started. I noticed several people talk about their old Core2Duo machines that are still working reasonable well. I also have one of those Core2Duo machines which was updated to add and SSD and memory updated to 6 GB. It is currently running Windows 10 but I had planned to move it to TW at some point in the future but I would go with a different distro as I wouldn't want to run 32 bit OS on it. Regards, Joe
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
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.
Except on ARM :-)
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.
+1
My personal view is that the userbase of openSUSE is not so large that we have to actively turn users away.
Yeah. -- Per Jessen, Zürich (2.7°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
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
Am Dienstag, 6. Dezember 2022, 09:01:43 CET schrieb Thomas Zimmermann:
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.
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. 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? Yep, moving to a different linux. Which will also mean: I'll eventually move all my other systems to the same other linux for simplification of maintenance, and I'm not sure I'll have the time to be working on packages for a linux distro that I don't even use myself, when first and foremost I'll be needing those packages for whatever other distro replaces openSUSE for me... Cheers MH -- Mathias Homann Mathias.Homann@openSUSE.org OBS: lemmy04 Jabber (XMPP): lemmy@tuxonline.tech Matrix: @mathias:eregion.de IRC: [Lemmy] on liberachat and ircnet (bouncer active) keybase: https://keybase.io/lemmy gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102
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 06.12.22 09:23, Dominique Leuenberger / DimStar wrote:
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')
Hmm, is this fair? "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. It would be fair if the one deciding to go with -v2 would do this work. Juergen
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 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. Greetings, Stephan
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 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.
Greetings, Stephan
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 <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman; HRB 36809 (AG Nuernberg)
On 06.12.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. 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 :/ It's driving me mad that we're doing something for the public stunt of it. Call it politics, I call it madness.
Greetings, Stephan
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.
On 2022-12-06T09:45:04, Richard Biener <rguenther@suse.de> 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 strikes me as the most sensible answer. I've not yet seen an argument that made me want -v2/v3, even though my hardware _is_ recent enough. Maybe on my desktop? I wonder how difficult it'd be to generate v3 binaries that are slightly larger, but still can fall back to v0? -- SUSE Software Solutions Germany GmbH Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman (HRB 36809, AG Nürnberg)
Hi Richard, Am Di., 6. Dez. 2022 um 10:45 Uhr schrieb Richard Biener <rguenther@suse.de>:
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 Tue, 2022-12-06 at 10:40 +0100, 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.
Greetings, Stephan
i586 (except -32bit packages) are scheduled to go out to the ports as well (if somebody cares to look after it) Having TW itself as v2/v3/v4 multiarch would be really interesting indeed, and I do hope that for the time when we want to start discussing to raise to a next level post v2, the infrastructure (build/QA and also zypper and rpm) can be thought about this. in OBS we could add multiple repos (v2/v3) and have them built (v3 a bit slower, due to a smaller hw pool for it in OBS), but then if they end up in repo, zypper has no clue which one to pick. And for this, I 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. That's certainly something to look at *in the nearer future*. if we only move i586 to the Legacy port, then I really doubt we will have anybody looking after that port at all, even though we heard people wanting i586; so far the only volunteer to look after the legacy port is still only Jiri; so in t Cheers, Dominique
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 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). Cheers, Dominique
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.
On Dez 06 2022, Jan Engelhardt wrote:
Or does it? There is glibc.i686 and it would appear zypper knows when to (not) install it.
glibc.i686 has a different RPM arch than glibc.i586. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Dominique Leuenberger / DimStar <dimstar@opensuse.org> 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 <dcermak@suse.com> 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
On Tue, 2022-12-06 at 11:52 +0100, Dan Čermák wrote:
Dominique Leuenberger / DimStar <dimstar@opensuse.org> writes:
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.
Absolutely! This is nothing I'd want to promote at all; it was more to show that to get 'multiple sub archs built', we need proper support by the underlying tooling (zypper, rpm, OBS) Cheers, Dominique
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
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? 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
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 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
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 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
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 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.
problem is a lack of people actually engaging with the opportunities already available to contribute and being far happier to complain instead of contributing.
I'm maintaining 9 ports in Debian unstable together with a bunch of other people that randomly help me with the effort. In Gentoo, there are also only a handful of people doing that work. You don't need as much manpower if the distribution is porter-friendly.
So..how about we call this nonsense thread to a close?
That's not how mailing list discussions work :-). Adrian
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 Tue, Dec 06, 2022 at 02:31:23PM +0100, 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
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
I see certain pattern here. All therse people mentioned are SUSE employees that have access to internal knowledge and other resources that most people just don't. As I see it starting a port is only friendly to people who can talk to the OBS maintainer in the hallway on their way to lunch. Thanks Michal
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 10:35, Richard Brown wrote:
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.
Oh come on! That "sponsor" does not exist as an entity. There is no contract whatsoever on the expected outcome - it's all interpretation of individuals. So if your decisions cost tons of more build jobs, longer wait times on openQA, more noise in general, ... - it needs to be part of your calculation. You can't excuse yourself with "SUSE wants this". SUSE at the current point of time wants to know how many real life benefits and risks switching to V2 brings - but that's tried in SUSE:ALP using the same OBS and the same openQA. So there is no benefit for anyone breaking Factory. Greetings, Stephan
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
On 12/6/22 09:23, Dominique Leuenberger / DimStar wrote:
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')
While this is generally true it's also true that SUSE is actively pushing away people from doing any work at all by erratic decisions like this. Splitting repos cause more work without more people doing stuff. Enforcing this without a real benefit is simply crazy. Ciao, Michael.
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 Tue, 2022-12-06 at 11:09 +0100, Stefan Seyfried wrote:
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.
If you consider you can also sell the E5730 for ~€25-€40 on eBay, then you find yourself in a situation where moving to the new hardware actually more than pays off in the first year.
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)
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?
If the hardware is old - force them to go to Leap or other Linux flavors that specialize in i586 and 32 bit stuff. This has already been discussed in summer. On the one hand it seems the old hardware is still "good enough" for
Hi Larry, On Mon, 5 Dec 2022 10:47:33 -0600 Larry Len Rainey wrote: the people who use it. Otherwise they would have replaced it. BTW, there is no 32 bit version of Leap for long time. Tumbleweed is the last openSUSE variant with x86_32 support. And to force users to switch to other Linux distributions seems not like good marketing to me. To use a current Linux version, like Tumbleweed, even on an old system has the advantage to get bug fixes and security updates and new features. So if it is possible, why not? On the other hand, according to the benchmarks presented, the performance improvement by switching to x86-64-v2 is just measurable tiny and very likely will not be noticeable except for maybe some very special use cases.
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. I fail to see the marketing point of "wont run on pre-x86-64-v2 CPUs". I admit I do not understand how "our new version has restricted CPU support" can make it sell better. But I have no experience in marketing. It seems to boil down to "we obsolete CPUs in order to obsolete CPUs".
Kind regards, Dieter
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.
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 -- Per Jessen, Zürich (2.7°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
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
On Montag, 5. Dezember 2022 21:00:55 CET Michael Ströder wrote:
On 12/5/22 17:47, Larry Len Rainey wrote:
I woke up this morning with this question?
If Tumbleweed is the latest Kernel and Software Versions, why are we worried about hardware that is over 8 years old?
So here's another question for you:
Why does the recent Linux kernel still support pretty old hardware?
1. The kernel is sources, not binary. Support for old hardware does not preclude support for new hardware. 2. The kernel targets a broad range of use cases, HPC, desktop, embedded. Expecially the latter has significant longer development life cycles than generic desktop computers. 3. Official hardware deprecation for the kernel typically happens long after the fact - "this code has not worked for the last 5 years and nobody has noticed it, drop it."
And now the key question:
Why should Tumbleweed cut off supporting old hardware if nobody benefits from this move?
1. For being honest. Tumbleweed is hardly tested on v1 hardware. 2. For being honest. There are packages which actually require SSE3 or later, and do not support generic x86. Still these package claim to be "x86_64". 3. There are small performance benefits on average for targeting v2 [1]. 4. It allows to reduce the runtime-dispatched code from the shipped binaries.
I'm opposed to this change.
There is no compelling reason for it. At least two of my family/friend users are affected by this because of old notebooks currently running fine for their usage.
Splitting support for -v1 to separate port repo means more maintenance work. But the openSUSE project does not have plenty of helping hands.
Ciao, Michael.
Being one of the helping hands, at least removing i586 will be a significant improvement. Trying to keep i586 alive is a burden, and many packages e.g. just disable the test suite for i586 to pass the build. For v1, there are two possible outcomes: 1. Packages just work, without further involvement - no extra maintenance 2. Packages need more work than just a different "-march" option for the compiler. For packages without any users even the second outcome would pose no problem. Iff there are users, it would be their obligation to submit fixes - the package maintainer probably has no access to v1 only hardware. Stefan [1] https://jamborm.github.io/spec-2022-07-29-levels/index.html
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 Mon, Dec 05, 2022 at 10:54:09AM +0100, 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, Nope. From the available information Windows require cx16 since 8.1, not v2. around 10% of _possible_ would not be supported by dropping pre-v2. That might be worth the performance/feature gains or not; IDK.
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.
BTW it's worth to look at the regional stats for Windows usage. Africa and South America still have higher usage of older Windows releases, but only by a few percent. Interestingly Windows 7 still has a marketshare of ~23% in India.
I guess this has been discussed already, but could '-v2' support be provided for selected packages only, while the default packages would remain at -v1?
We don't have infra for that in rpm although the linker can do this at this coarse granularity. Unfortunately, these -vn feature bags aren't in any way related to real needs of software so it would be better if the actual CPU features were supported rather than these arbitrary bags. Support for that exists only as dynamic cpu dispatch inside the software in question or building software with optimizations tayloerd for your system. I think even defining these feature bags sidetracked developers from designing a real solution to the cpu feature problem. 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
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: Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg cx16 xtpr pdcm pcid sse4_1 sse4_2 movbe popcnt tsc_deadline_timer xsave rdrand lahf_lm abm cpuid_fault epb invpcid_single pti ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust erms invpcid xsaveopt dtherm arat pln pts -- 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 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
Stefan Brüns composed on 2022-12-06 01:23 (UTC+0100):
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:
My comment didn't require that much context, nor did its question get answered.
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.
Exactly the point. Introduction year constitutes a poor measure of support introduction.
I even mentioned Pentiums had no AVX2 until 2019 (i.e. 3 years ago) - both your Kaby Lake and your Haswell Pentium are older.
Speaking of context, these threads have been lacking an important point, which is the first year or so of product life applicable to Windows can't be counted as applicable to Linux. So, when you say a product is 7 years old, that means it was available in Windows 7 years ago. Availability in Linux takes a while, up to 2+ years for LTS distros. My Kaby lake released to market in 2017 was nearly a year on market when I bought it, and it still wasn't yet fully supported by the latest Leap release. Same thing happened three years later, Rocket Lake released Q1'21 didn't have serious kernel bugs fixed until after 15.4 was out the door in spring of following year. <https://bugzilla.opensuse.org/show_bug.cgi?id=1193640> <https://gitlab.freedesktop.org/drm/intel/-/issues/4762> <https://gitlab.freedesktop.org/drm/intel/-/issues/4150> IOW, "2012" CPU technology doesn't begin to become 10 years old in Linux until at least sometime in 2023, and may not be entirely for another 4-7 years due to unadvertised marketing tiering, which at least some of us didn't know about before v0 v1 v2 v3 v4 discussions began, much too late for CPU shopping. -- 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
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
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. So if there's negligible or no performance benefit, is there some other reason why we want to move away to v2? https://lists.archlinux.org/pipermail/arch-general/2021-March/048739.html
Hi, Am Di., 6. Dez. 2022 um 21:28 Uhr schrieb llyyr <llyyr.public@gmail.com>:
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 Wed, 2022-12-07 at 13:07 +0100, Dirk Müller wrote:
Hi,
Am Di., 6. Dez. 2022 um 21:28 Uhr schrieb llyyr <llyyr.public@gmail.com>:
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.
As we can't go v3 (which would probably be much nicer) due to missing build hardware (QA should be fine with the exception of one worker host), and cutting off even much more users, sticking to v0 for now might really turn out to be the best, BUT: * Once we have sufficient v3 build power, we should still do the switch, which brings the entire discussion up again; even if that's half a year out, people will complain that their old hardware is not supported. The LegacyX86 port will remain the solution (unless we get proper sub-arch support in rpm/zypp/obs by then and are willing to build everything v0 AND v3 in one repo, increasing the size for the mirrors (3rd point might mitigate this a bit) * building 'some packages' as v3 strikes as a really bad idea, as that would mean any random package might not work on a machine that otherwise works. => For libraries we can look at least into the hwcaps feature of glibc; the 'how to build' those without duplicating all specs or adding multibuilds is an open point. Also, this only supports libraries, not executables. In most cases probably fine, but something to consider * The i586 stuff will be removed from openSUSE:Factory no matter the outcome of the v0->v<N> switch. Anybody caring for that will have to look after it in LegacyX86 port or accept the architecture to be dead. Cheers, Dominique
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?
Hi Alberto, Am Mi., 7. Dez. 2022 um 13:30 Uhr schrieb aplanas <aplanas@suse.de>:
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?
I don't know what the best solution is, but this sounds workable. the other option is to have a standard_v3 repository in the same project(s) and do the switch via prjconf + onlybuilds
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?
well, if you install the library into a HWCAPS specific subdirectory, then the glibc loader is selectign this on your own, and you don't need to do any libsolv/zypper magic at all. you can install it, if it is there and the hardware doesn't support it, it won't get used. so we could defer that into a pattern / installer /user choice that a user has to opt in manually for the first iteration.
aplanas <aplanas@suse.de> 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 <dcermak@suse.com> 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
On 2022-12-07 14:08, Dan Čermák wrote:
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.
Yes. Dirks idea is better.
Hi Dan, Am Mi., 7. Dez. 2022 um 14:08 Uhr schrieb Dan Čermák <dcermak@suse.de>:
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
On Wed, 2022-12-07 at 15:08 +0100, Dirk Müller wrote:
* 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.
except it is not a 'repackage' across archs like -32bit; it's rather a 2nd build started with different flags. So more similar to the kernel- signing 2nd step. Doing it in the main package we'll have to be very careful: not all workers support v3 and running the build on a worker that doesn't support it will fail. Cheers, Dominique PS: I started https://en.opensuse.org/openSUSE:X86-64-Architecture-Levels to get to a clean solution of the problem. This is a draft proposal without any commitment to get this imlemented.
On Wed, Dec 07, 2022 at 03:26:31PM +0100, Dominique Leuenberger / DimStar wrote:
On Wed, 2022-12-07 at 15:08 +0100, Dirk Müller wrote:
* 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.
except it is not a 'repackage' across archs like -32bit; it's rather a 2nd build started with different flags. So more similar to the kernel- signing 2nd step. Doing it in the main package we'll have to be very
It's an implementation choice if it's done as a different architecture or as a second pass. Doing it as a different architecture is what we can do today, right now, with the tools and as they are. For that only a repository with different buildflags that builds the select packages is needed. Thanks Michal
On 2022/12/07 15:08:16 +0100, Dirk Müller wrote:
Hi Dan,
Am Mi., 7. Dez. 2022 um 14:08 Uhr schrieb Dan Čermák <dcermak@suse.de>:
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
AFAICR the ffmpeg/kodi people are able to build and load on demand optimized code for e.g. sse4 support. Also glibc/gcc has the opportunity to load/map optimized code at runtime for different CPUs all x86_64, at least I can remember on debugging a strange crash on an older AMD CPU within string operations which was not reproducable on Intel. I really wonder why this should not possible for v0 up to v3, maybe with an extended runtime linker. Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr
On 08/12/2022 08.23, Dr. Werner Fink wrote:
[...] AFAICR the ffmpeg/kodi people are able to build and load on demand optimized code for e.g. sse4 support. Also glibc/gcc has the opportunity to load/map optimized code at runtime for different CPUs all x86_64, at least I can remember on debugging a strange crash on an older AMD CPU within string operations which was not reproducable on Intel.
glibc uses hand-optimized assembler files for certain string routines and has a handler that checks for cpu capabilities and then calls these routines as needed. I expect ffmpeg to do something similar. So, there's extra logic needed to do this in a single binary. Just compiling a library with certain flags and moving it into the proper subdirectory is a far easier approach. Andreas -- Andreas Jaeger aj@suse.com Twitter: jaegerandi SUSE Software Solutions Germany GmbH, Frankenstr.146, D 90461 Nürnberg (HRB 36809, AG Nürnberg) GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman GPG fingerprint = EF18 1673 38C4 A372 86B1 E699 5294 24A3 FF91 2ACB
On Thu, Dec 8, 2022 at 8:14 AM Andreas Jaeger <aj@suse.com> wrote:
On 08/12/2022 08.23, Dr. Werner Fink wrote:
[...] AFAICR the ffmpeg/kodi people are able to build and load on demand optimized code for e.g. sse4 support. Also glibc/gcc has the opportunity to load/map optimized code at runtime for different CPUs all x86_64, at least I can remember on debugging a strange crash on an older AMD CPU within string operations which was not reproducable on Intel.
glibc uses hand-optimized assembler files for certain string routines and has a handler that checks for cpu capabilities and then calls these routines as needed. I expect ffmpeg to do something similar.
So, there's extra logic needed to do this in a single binary. Just compiling a library with certain flags and moving it into the proper subdirectory is a far easier approach.
Or FatELF: https://icculus.org/fatelf/ (We could only hope...) -- 真実はいつも一つ!/ Always, there's only one truth!
Or FatELF: https://icculus.org/fatelf/
(We could only hope...) That in general sounds like something gcc/binutils could do on a function level. Like compiling with v3, identifying cpu instructions used not fitting v1 and
Am 08.12.22 um 15:05 schrieb Neal Gompa: then creating a jump table based on cpu information. Patent pending :) Greetings, Stephan
On Thursday 2022-12-08 15:39, Stephan Kulow wrote:
Am 08.12.22 um 15:05 schrieb Neal Gompa:
Or FatELF: https://icculus.org/fatelf/
(We could only hope...)
That in general sounds like something gcc/binutils could do on a function level. Like compiling with v3, identifying cpu instructions used not fitting v1 and then creating a jump table based on cpu information. Patent pending :)
Just like https://gcc.gnu.org/onlinedocs/gcc/Function-Multiversioning.html , but have gcc do it automatically for every function without source code modification. Could Richard cook us something up?
On Donnerstag, 8. Dezember 2022 16:25:41 CET Jan Engelhardt wrote:
On Thursday 2022-12-08 15:39, Stephan Kulow wrote:
Am 08.12.22 um 15:05 schrieb Neal Gompa:
Or FatELF: https://icculus.org/fatelf/
(We could only hope...)
That in general sounds like something gcc/binutils could do on a function level. Like compiling with v3, identifying cpu instructions used not fitting v1 and then creating a jump table based on cpu information. Patent pending :)
Just like https://gcc.gnu.org/onlinedocs/gcc/Function-Multiversioning.html , but have gcc do it automatically for every function without source code modification.
IIRC since GCC 6 it can do automatic clones for a specified list of instruction extensions. Clang gained the same with LLVM 14?/15?. Unfortunately, MSVC does not support this (yet [1]), so this is a big barrier for multiplatform projects, and the reason many projects still use their own home grown dispatcher. Regards, Stefan [1] https://www.youtube.com/watch?v=LTM1was1dTU -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019
participants (53)
-
Aaron Puchert
-
Aaron Stern
-
Andreas Jaeger
-
Andreas Schwab
-
Andrei Borzenkov
-
aplanas
-
AW
-
Bjoern Voigt
-
Bruno Pitrus
-
Carlos E. R.
-
Dan Čermák
-
Dan Čermák
-
dieter
-
Dirk Müller
-
Dominique Leuenberger / DimStar
-
Dr. Werner Fink
-
Fabian Vogt
-
Felix Miata
-
Hans-Peter Jansen
-
Jan Engelhardt
-
Jiri Slaby
-
Joe Salmeri
-
John Paul Adrian Glaubitz
-
Juergen Gross
-
Koen De Jaeger
-
Larry Finger
-
Larry Len Rainey
-
Lars Marowsky-Bree
-
Liam Proven
-
llyyr
-
Lukas Straub
-
Marco Calistri
-
Martin Jambor
-
Martin Schröder
-
Mathias Homann
-
Michael Ströder
-
Michal Suchánek
-
Neal Gompa
-
Nikolai Nikolaevskii
-
Olav Reinert
-
Per Jessen
-
Peter McD
-
Rainer Klier
-
Richard Biener
-
Richard Brown
-
Robert Webb
-
Simon Lees
-
Stefan Brüns
-
Stefan Seyfried
-
Stephan Kulow
-
Thomas Zimmermann
-
Thorsten Kukuk
-
Vojtěch Zeisek