openSUSE Release Engineering meeting 31.08.2022
All meeting minutes can be found here: https://etherpad.opensuse.org/p/ReleaseEngineering-meeting Meeting is hosted here https://meet.opensuse.org/ReleaseEngineeringMeeting ## Attendees bittin, guillaumeg, lkocman, DimStar, ddemaio, adrian, richard, maxlin, mmeissner ## Leap 270.3 looks good, most failure are related to missing 15.5 /oss repo (more details below) rest of upgrade failures are related to boo#1202963 (missing liborcus-0.16.so.0) I expect that to be fixed with next snapshot update. I did kill pending jobs, @ttm ignored all failures and started publish. Publishing obs-> ftp-stage seems was fixed by Adrian during the call https://bugzilla.opensuse.org/show_bug.cgi?id=1202116 15.3 nvidia issue missing kernel-devel*57.3 in the GA repo (caused by rewriting ftp-trees as part of QU) https://en.opensuse.org/openSUSE:LeapQuarterlyUpdates_howto Plan for 15.3 is that autobuild team will rsync ftp trees from OBS to pontifex (while ignorning /iso). ^ Plan for 15.4 ongoing is to not do it this way, perhaps we should simply start building DVD as part of live-images effort. Our net-install image would not work as it expect to have the very same boot-related files from /oss. TW has this addressed according to Fabian lkocman@pontifex2:/home/lkocman> cat /etc/fstab | grep 15.5 /srv/ftp/pub/opensuse/update/leap/15.5/oss_debug /srv/ftp/pub/opensuse/debug/update/leap/15.5/oss auto bind 0 0 /srv/ftp-stage/pub/opensuse/update/leap/15.5/oss_debug /srv/ftp-stage/pub/opensuse/debug/update/leap/15.5/oss auto bind 0 0 Current understanding (based on autobuild) is that we're waiting for maintenance team to finish channel creation. I did @ttm ignore all failures on last build so we have Leap Micro 5.3 publish setup done, image build failures started by end of previous week. Originally I thought it was related to forking udica package, log is not super verbose, I'll reach out to snwint, currently images are rebuilding. (could be allso fixed from SLE Micro side). pontifex / osrt-publish_distro (was ~mirror/publish-distro/publish_distro) change was deployed to pontifex https://progress.opensuse.org/issues/115667 (discussed with heroes) Next candidate for similar move could be scripts/wrappers in ~mirror/bin, ~mirror is under git but not pushed (backed up) anywhere and we have some uncommited changes. mirror@pontifex2:~> cat .git/config [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true mirror@pontifex2:~> git diff | wc -l 85 Discussion about redesign and strategy of get oo.org for the ALP Release and last Leap etc and (related to support of HW older than x86_64-v3) more discussion during next weeks meeting ## openSUSE Tumbleweed openSUSE:Factory build fail stats: 198 failed, 34 unresolvable (1 week ago: 233/18) https://tinyurl.com/ysy4nnnz 26 snapshots in a row without interruption - until today that is: 0830 won't be published due to libxml2 update to 2.10.1, same so-version, but less features enabled thus not ABI compatible (https://bugzilla.opensuse.org/show_bug.cgi?id=1202965) * glibc 2.36 was published as part of snapshot 0827; no full rebuild was triggered, but in combination with libxml2 (which has like half the distro behind it), it's the right moment to do today * Mozilla Thunderbird 102: I have received notice that the new integrated key manager (openpgp) is not very comfortable, especially as 'searching keys' only queries openpgp.com, but no ^ news-o-o / factory@ announcement? <bittin>: there is a new Thunderbird update 6th September 2022, with some bugfixes and security fixes, not sure whats fixed exactly however ## Richard (MicroOS) BCI-for-Tumbleweed containers are progressing slowly Richard moving his daily driver to another laptop, using the exercise as a detailed UX re-evaluation of MicroOS Desktop GNOMEs current status and hitlist for getting things polished up (lubos can help) Currently hindered by investigating TPM/FDE issues with GRUB <lubos>: jeos-firstboot wizard being used? or combustion minimal installation use cases? Richard: we should consider dropping transactional-server role - it is no longer maintained by it's creator (Richard) who believes MicroOS fully obsoletes it. There is also a discussion as to whether the minimal role should be removed due to it's large overlapping usecases with MicroOS ## Max * The Backports checker is finished and the PR is open for review on Github and is open for suggestions https://github.com/openSUSE/openSUSE-release-tools/pull/2848 * Regarding to missing liborcus issue on the latest Leap snapshot, skippkg-finder removes liborcus 0.16 from the ftp-tree after it sees liborcus 0.17 was there, we need to update snpshots repo that should fix this problem Trying to work to solve the missing liborcus-0.16.so.0 problem for Leap 15.5 Lubos: to request a snapshot-update today *Drop python2* packages completely at the end of devel phase. We keep the interpret as a compromise as of now. dimstar: even python2 stuff still in TW lkocman to setup meeting for the next steps Rough idea: announce, keep interpret for some time to allow developer to rebuild packages, drop it with certain milestone (prior to Beta). Max: will check how many package still rely on python2 interpret(Alpha phase) ## Guillaume - Arm Thanks for the backup while I was on vacation! Tumbleweed: * Rolling, no blocker had a new snapshot yesterday 30th August 2022 Leap: * Started to work on 15.5 images ALP: * We have 3 projects in OBS for ALP: devel:LEO (used by openQA atm), devel:ALP and SUSE:ALP. This would need some clarification to know where the work should happen. lkocman: need to check on ARM:Images ARM:Images:ToTest (seems to be done) ## Sarah - s390 Not Available DimStar: s390x is rolling again. Snapshot 0823 has been published (ahead of intel x86_64 thats on 0822). DimStar: same issue again, we have an issue with workers lkocman: to reach out to Sarah and Ihno (these issues are related to openQA - https://progress.opensuse.org/issues/115583 / https://bugzilla.opensuse.org/show_bug.cgi?id=1202821). ## Doug * Events * Asked sponsor a Reproducible Builds event * https://reproducible-builds.org/events/venice2022/ * Connected community rep for KDE Akademy (thx you Stathis) * Submitted asknot-ng PR with several yml inputs * Question on Twitter providing mixed results about the logo& brand colors - https://paste.opensuse.org/75722100 * TSP solution * Discussions sound promissing. Should be briefed on new solution in the next two weeks * ALP * Will discuss marketing of it in community meeting * https://etherpad.opensuse.org/p/weeklymeeting20220901 * GSoC * Planning to send swag to particpants * Final evaluations due Sept. 19 at 18:00 UTC <lubos>: Swag for Chinese students at the SUSE Office ## Dirk Not available Trying to keep the Factory-ARM project building Debugging lack of publishing - Richard to investigate TTM Will be on vacation for the next two weeks ## Wolfgang (Package Hub), Scott Bahling Not available sbahling: Still fixing Package Hub 15 SP4. Around 3500 packages missing compared to SP3. Almost daily customer issue reports. Requires Maintenance Service Center requests for channel modification to process. Seems to be a slow process. Priority on KDE and monitoring-plugins packages. ## Maintenance team (Marina or Marcus, Maurizio (m4u)) 15.5 test update should go out in next test ours, the openSUSE setup is not yet done, we need to setup backports checks and pool repos, we have to do work on our side. Marcus mailed us with project config. The openSUSE / SLE side in IBS it seems to be ready, on openSUSE side there is a lot of setup that needs to be done first. Adrian: the pool repos should be in place now. Some openQA issues in one of the 15.4 groups (timeout), Marcus messaged QE core, however there seems to be no activity. ## Adrian - OBS Working on 15.5 publishing and it should hopefully work now and 15.3 FTP-tree is now downgraded on stage as the new media had NVIDIA bugs openSUSE Leap 15.5 started building yesterday to be published no update on SR mirroring issue (no feedback loop for submit request creators) ## Open Floor New openSUSE Wallpaper
On 8/31/22 06:42, Lubos Kocman wrote:
Discussion about redesign and strategy of get oo.org for the ALP Release and last Leap etc and (related to support of HW older than x86_64-v3) more discussion during next weeks meeting
What is "HW older than x86_64-v3" ? -- David C. Rankin, J.D.,P.E.
On 02.09.22 07:45, David C. Rankin wrote:
On 8/31/22 06:42, Lubos Kocman wrote:
Discussion about redesign and strategy of get oo.org for the ALP Release and last Leap etc and (related to support of HW older than x86_64-v3) more discussion during next weeks meeting
What is "HW older than x86_64-v3" ?
Anything older than 2020 -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
On 9/2/22 01:24, Stefan Seyfried wrote:
On 02.09.22 07:45, David C. Rankin wrote:
On 8/31/22 06:42, Lubos Kocman wrote:
Discussion about redesign and strategy of get oo.org for the ALP Release and last Leap etc and (related to support of HW older than x86_64-v3) more discussion during next weeks meeting
What is "HW older than x86_64-v3" ?
Anything older than 2020
You're kidding right? What does that paragraph say? Is it saying there will be no more Leap after 15.5 and no more support for hardware built before 2020? -- David C. Rankin, J.D.,P.E.
On Fri, Sep 02 2022, Stefan Seyfried wrote:
On 02.09.22 07:45, David C. Rankin wrote:
On 8/31/22 06:42, Lubos Kocman wrote:
Discussion about redesign and strategy of get oo.org for the ALP Release and last Leap etc and (related to support of HW older than x86_64-v3) more discussion during next weeks meeting
What is "HW older than x86_64-v3" ?
Anything older than 2020 --
Ummm.... no, definitely no. My >5 year notebook is also x86_64-v3 and that's just an example, I'm sure there is plenty of x86_64-v3 machines quite a bit older than that. See https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/message/... to find out if a particular machine is x86_64-v3 or not. Martin
On Fri, 2 Sep 2022, Martin Jambor wrote:
On Fri, Sep 02 2022, Stefan Seyfried wrote:
On 02.09.22 07:45, David C. Rankin wrote:
On 8/31/22 06:42, Lubos Kocman wrote:
Discussion about redesign and strategy of get oo.org for the ALP Release and last Leap etc and (related to support of HW older than x86_64-v3) more discussion during next weeks meeting
What is "HW older than x86_64-v3" ?
Anything older than 2020 --
Ummm.... no, definitely no. My >5 year notebook is also x86_64-v3 and that's just an example, I'm sure there is plenty of x86_64-v3 machines quite a bit older than that.
I think you can at most make a stmt like "Nothing newer than 2020" but even then, Intel continues to produce (read: has not EOLed) SKUs where they chose to fuse off AVX2 support for whatever reason, so that '2020' year might only apply to products _released_ after that (but you can never be sure with Intel!). So I'd say "it's unlikely you bought a new consumer class x86 computer after year X that does not qualify for x86_64-v3". Where X might be actually 2017. But of course counter examples will exist. 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 Fri, 2022-09-02 at 08:24 +0200, Stefan Seyfried wrote:
On 02.09.22 07:45, David C. Rankin wrote:
On 8/31/22 06:42, Lubos Kocman wrote:
Discussion about redesign and strategy of get oo.org for the ALP Release and last Leap etc and (related to support of HW older than x86_64-v3) more discussion during next weeks meeting
What is "HW older than x86_64-v3" ?
Anything older than 2020
https://en.wikipedia.org/wiki/X86-64#Microarchitecture_levels Wiki says v3 has been around since 2015 (except some Atom CPUs, wher eonly the very new ones are up to the game) eg. my HP Elitebook 820G1 from end of 2014 supports v3 Cheers, Dominique
On 02.09.22 12:15, Dominique Leuenberger / DimStar wrote:
On Fri, 2022-09-02 at 08:24 +0200, Stefan Seyfried wrote:
Anything older than 2020
https://en.wikipedia.org/wiki/X86-64#Microarchitecture_levels
Wiki says v3 has been around since 2015 (except some Atom CPUs, wher eonly the very new ones are up to the game)
"Has been around since" is not "all machines since then support..." You mentioned some exceptions already.
eg. my HP Elitebook 820G1 from end of 2014 supports v3
My Thinkpad 430 (probably 2013) does not. So Richard is probably more correct with "anything newer than 2020 will support it" than my statement. Let me correct it. "Anything older than 2020 might not support x86_64-v3." -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
Am 02.09.22 um 08:24 schrieb Stefan Seyfried:
On 02.09.22 07:45, David C. Rankin wrote:
On 8/31/22 06:42, Lubos Kocman wrote:
Discussion about redesign and strategy of get oo.org for the ALP Release and last Leap etc and (related to support of HW older than x86_64-v3) more discussion during next weeks meeting
What is "HW older than x86_64-v3" ?
Anything older than 2020
Well, it seems it is time to throw away my perfectly working sandybridge pc which i use for testing. :( -- Dennis Knorr, dennis.knorr@suse.com SUSE Software Solutions Germany GmbH Frankenstraße 146, 90461 Nürnberg, Germany Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman (HRB 36809, AG Nürnberg)
Dennis Knorr <dennis.knorr@suse.com> writes:
Am 02.09.22 um 08:24 schrieb Stefan Seyfried:
On 02.09.22 07:45, David C. Rankin wrote:
On 8/31/22 06:42, Lubos Kocman wrote:
Discussion about redesign and strategy of get oo.org for the ALP Release and last Leap etc and (related to support of HW older than x86_64-v3) more discussion during next weeks meeting
What is "HW older than x86_64-v3" ?
Anything older than 2020
Well, it seems it is time to throw away my perfectly working sandybridge pc which i use for testing.
That would be a pretty premature action, given that: 1) no decision about x86_64v2/v3 has been made for the community ALP spin 2) the quote *explicitly* states that the discussion is about supporting pre-x86_64v3 hardware and *not* about dropping support So please everyone calm down and keep your machines. We do want to keep machines which do not support x86_64v3 supported in one way or the other. 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
David C. Rankin composed on 2022-09-02 01:45 (UTC-0400):
What is "HW older than x86_64-v3" ?
Run inxi -Cxx to see what you have for "level:". e.g., Intel Haswell (2014) and AMD A10 (2012) are: "level: v3" e8400 Core2Duo (2008): "level: v2" Netburst Presler P4: "level: v1" Kaby Lake (2017): "level: v3" Rocket Lake (2021): "level: v4" -- 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
Hello Felix, Am Freitag, 2. September 2022, 09:31:56 CEST schrieb Felix Miata:
Run inxi -Cxx to see what you have for "level:".
I fail to find 'level' in my output: docb@X1E:~> inxi -Cxx CPU: Info: 6-core model: Intel Core i7-9750H bits: 64 type: MT MCP arch: Coffee Lake rev: A cache: L1: 384 KiB L2: 1.5 MiB L3: 12 MiB Speed (MHz): avg: 2337 high: 2600 min/max: 800/4500 cores: 1: 2600 2: 2600 3: 2600 4: 2600 5: 2600 6: 1129 7: 2600 8: 2600 9: 2600 10: 2600 11: 920 12: 2600 bogomips: 62399 Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
Axel Braun wrote:
Hello Felix,
Am Freitag, 2. September 2022, 09:31:56 CEST schrieb Felix Miata:
Run inxi -Cxx to see what you have for "level:".
I fail to find 'level' in my output:
Ditto - machines all too old? per@office38:~> inxi -Cxx CPU: Topology: Quad Core model: Intel Core2 Quad Q6700 bits: 64 type: MCP arch: Core Merom rev: B L2 cache: 4096 KiB flags: lm nx pae sse sse2 sse3 ssse3 vmx bogomips: 21278 Speed: 1596 MHz min/max: 1600/2667 MHz Core speeds (MHz): 1: 1596 2: 1596 3: 1596 4: 1596 per@office68:~> inxi -Cxx CPU: Topology: Dual Core model: Intel Core i3-5005U bits: 64 type: MT MCP arch: Broadwell rev: 4 L2 cache: 3072 KiB flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 15963 Speed: 1696 MHz min/max: 500/1900 MHz Core speeds (MHz): 1: 1737 2: 1718 3: 1762 4: 1783 per@gaston:~> inxi -Cxx CPU: Topology: Single Core model: Intel Celeron bits: 64 type: MCP arch: Netburst Smithfield rev: 9 L2 cache: 256 KiB flags: lm nx pae sse sse2 sse3 bogomips: 5586 Speed: 2793 MHz min/max: N/A Core speed (MHz): 1: 2793 per@mirage:~> inxi -Cxx CPU: Quad core Intel Xeon X5450 (-HT-MCP-) arch: Penryn rev.6 cache: 6144 KB flags: (lm nx sse sse2 sse3 sse4_1 ssse3) bmips: 24000 clock speeds: max: 3000 MHz 1: 3000 MHz 2: 3000 MHz 3: 3000 MHz 4: 3000 MHz 5: 3000 MHz 6: 3000 MHz 7: 3000 MHz 8: 3000 MHz -- Per Jessen, Zürich (17.9°C) Member, openSUSE Heroes
About a year ago I stumbled upon this. (I usually save all interesting commands for later use) /lib64/ld-linux-x86-64.so.2 --help I can't say for sure that it actually proves that the cpu is up to it. Have a look under: "Subdirectories of glibc-hwcaps directories, in priority order:" /bengan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2022-09-02 a las 11:20 +0200, Bengt Gördén escribió:
About a year ago I stumbled upon this. (I usually save all interesting commands for later use)
/lib64/ld-linux-x86-64.so.2 --help
Telcontar:~ # /lib64/ld-linux-x86-64.so.2 --help - --help: error while loading shared libraries: --help: cannot open shared object file Telcontar:~ # - -- Cheers, Carlos E. R. (from openSUSE 15.3 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCYzHOwxwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVvfYAnRkE2lFYEWfNYOSFxoax vMkmAo+zAJ9c9VClWdW22snwY3upfeLZQRVEUg== =HaSs -----END PGP SIGNATURE-----
* Carlos E. R. <robin.listas@telefonica.net> [09-26-22 12:11]:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2022-09-02 a las 11:20 +0200, Bengt Gördén escribió:
About a year ago I stumbled upon this. (I usually save all interesting commands for later use)
/lib64/ld-linux-x86-64.so.2 --help
Telcontar:~ # /lib64/ld-linux-x86-64.so.2 --help - --help: error while loading shared libraries: --help: cannot open shared object file Telcontar:~ #
- -- Cheers, Carlos E. R. (from openSUSE 15.3 x86_64 at Telcontar)
-----BEGIN PGP SIGNATURE-----
iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCYzHOwxwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVvfYAnRkE2lFYEWfNYOSFxoax vMkmAo+zAJ9c9VClWdW22snwY3upfeLZQRVEUg== =HaSs -----END PGP SIGNATURE-----
rpm -qf /lib6 4/ld-linux-x86-64.so.2 glibc-2.36-5.1.x86_64 seems your installation/box is missing something. and I know you know about rpm -V glibc-<your-version> -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc
On 2022-09-26 18:19, Patrick Shanahan wrote:
* Carlos E. R. <> [09-26-22 12:11] > El 2022-09-02 a las 11:20 +0200, Bengt Gördén escribió:
About a year ago I stumbled upon this. (I usually save all interesting commands for later use)
/lib64/ld-linux-x86-64.so.2 --help
Telcontar:~ # /lib64/ld-linux-x86-64.so.2 --help --help: error while loading shared libraries: --help: cannot open shared object file Telcontar:~ #
rpm -qf /lib6 4/ld-linux-x86-64.so.2 glibc-2.36-5.1.x86_64
seems your installation/box is missing something. and I know you know about rpm -V glibc-<your-version>
My system is not missing anything. cer@Telcontar:~> rpm -qf /lib64/ld-linux-x86-64.so.2 glibc-2.31-150300.37.1.x86_64 cer@Telcontar:~> -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
* Carlos E. R. <robin.listas@telefonica.net> [09-26-22 12:30]:
On 2022-09-26 18:19, Patrick Shanahan wrote:
* Carlos E. R. <> [09-26-22 12:11] > El 2022-09-02 a las 11:20 +0200, Bengt Gördén escribió:
About a year ago I stumbled upon this. (I usually save all interesting commands for later use)
/lib64/ld-linux-x86-64.so.2 --help
Telcontar:~ # /lib64/ld-linux-x86-64.so.2 --help --help: error while loading shared libraries: --help: cannot open shared object file Telcontar:~ #
rpm -qf /lib6 4/ld-linux-x86-64.so.2 glibc-2.36-5.1.x86_64
seems your installation/box is missing something. and I know you know about rpm -V glibc-<your-version>
My system is not missing anything.
cer@Telcontar:~> rpm -qf /lib64/ld-linux-x86-64.so.2 glibc-2.31-150300.37.1.x86_64 cer@Telcontar:~>
- - Cheers / Saludos,
Carlos E. R. (from 15.3 x86_64 at Telcontar)
rpm -V glibc-2.31-150300.37.1.x86_64 rpm -q --requires glibc-2.31-150300.37.1.x86_64 your system reports it cannot open a "shared object file" something is missing or corrupt -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc
On 2022-09-26 18:43, Patrick Shanahan wrote:
* Carlos E. R. <> [09-26-22 12:30]:
On 2022-09-26 18:19, Patrick Shanahan wrote:
* Carlos E. R. <> [09-26-22 12:11]
El 2022-09-02 a las 11:20 +0200, Bengt Gördén escribió:
About a year ago I stumbled upon this. (I usually save all interesting commands for later use)
/lib64/ld-linux-x86-64.so.2 --help
Telcontar:~ # /lib64/ld-linux-x86-64.so.2 --help --help: error while loading shared libraries: --help: cannot open shared object file Telcontar:~ #
rpm -qf /lib6 4/ld-linux-x86-64.so.2 glibc-2.36-5.1.x86_64
seems your installation/box is missing something. and I know you know about rpm -V glibc-<your-version>
My system is not missing anything.
cer@Telcontar:~> rpm -qf /lib64/ld-linux-x86-64.so.2 glibc-2.31-150300.37.1.x86_64 cer@Telcontar:~>
rpm -V glibc-2.31-150300.37.1.x86_64 rpm -q --requires glibc-2.31-150300.37.1.x86_64
your system reports it cannot open a "shared object file" something is missing or corrupt
Nope. I have a guess what it is, but not that. Hint: I'm not using TW. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
On Mon, 2022-09-26 at 19:11 +0200, Carlos E. R. wrote:
On 2022-09-26 18:43, Patrick Shanahan wrote:
* Carlos E. R. <> [09-26-22 12:30]:
On 2022-09-26 18:19, Patrick Shanahan wrote:
* Carlos E. R. <> [09-26-22 12:11]
El 2022-09-02 a las 11:20 +0200, Bengt Gördén escribió:
> About a year ago I stumbled upon this. (I usually save > all interesting > commands for later use) > > /lib64/ld-linux-x86-64.so.2 --help
Telcontar:~ # /lib64/ld-linux-x86-64.so.2 --help --help: error while loading shared libraries: --help: cannot open shared object file Telcontar:~ #
rpm -qf /lib6 4/ld-linux-x86-64.so.2 glibc-2.36-5.1.x86_64
seems your installation/box is missing something. and I know you know about rpm -V glibc-<your-version>
My system is not missing anything.
cer@Telcontar:~> rpm -qf /lib64/ld-linux-x86-64.so.2 glibc-2.31-150300.37.1.x86_64 cer@Telcontar:~>
rpm -V glibc-2.31-150300.37.1.x86_64 rpm -q --requires glibc-2.31-150300.37.1.x86_64
your system reports it cannot open a "shared object file" something is missing or corrupt
Nope.
I have a guess what it is, but not that.
Hint: I'm not using TW.
Hello Carlos me and few others already shared a stack-overflow based scripted solution for Leap15/SLES 15 earlier in the tread :-) https://unix.stackexchange.com/questions/631217/how-do-i-check-if-my-cpu-sup...
-- Cheers / Saludos,
Carlos E. R. (from 15.3 x86_64 at Telcontar)
-- Luboš Kocman (he/him) openSUSE Leap Release Manager SUSE +1 2345678910 www.suse.com
On 2022-09-27 15:35, Lubos Kocman wrote:
me and few others already shared a stack-overflow based scripted solution for Leap15/SLES 15 earlier in the tread 😄 https://unix.stackexchange.com/questions/631217/how-do-i-check-if-my-cpu-sup...
Wasn't that method dismissed as unreliable by Andrei Borzenkov? On 2022-09-06 10:33, Andrei Borzenkov wrote:
As I already explained in this thread on the user list, you cannot reliably detect v3 and above based on information in /proc/cpuinfo. Neither the OSXSAVE flag nor supported XSAVE bits are exposed. Testing for XSAVE is an optimistic approximation where you hope that if XSAVE is supported then everything else will be correctly set up.
libc actually queries processor for current OSXSAVE and supported XSAVE bits. Maybe it is possible to provide standalone binary replicating these tests.
-- /bengan
On Tue, Sep 27, 2022 at 04:51:49PM +0200, Bengt Gördén wrote:
On 2022-09-27 15:35, Lubos Kocman wrote:
me and few others already shared a stack-overflow based scripted solution for Leap15/SLES 15 earlier in the tread 😄 https://unix.stackexchange.com/questions/631217/how-do-i-check-if-my-cpu-sup...
Wasn't that method dismissed as unreliable by Andrei Borzenkov?
Unreliable for v3, for v2 it should suffice. Thanks Michal
On 2022-09-06 10:33, Andrei Borzenkov wrote:
As I already explained in this thread on the user list, you cannot reliably detect v3 and above based on information in /proc/cpuinfo. Neither the OSXSAVE flag nor supported XSAVE bits are exposed. Testing for XSAVE is an optimistic approximation where you hope that if XSAVE is supported then everything else will be correctly set up.
libc actually queries processor for current OSXSAVE and supported XSAVE bits. Maybe it is possible to provide standalone binary replicating these tests.
-- /bengan
Carlos E. R. composed on 2022-09-26 12:09 (UTC+0200):
El 2022-09-02 a las 11:20 +0200, Bengt Gördén escribió:
About a year ago I stumbled upon this. (I usually save all interesting commands for later use)
/lib64/ld-linux-x86-64.so.2 --help
Telcontar:~ # /lib64/ld-linux-x86-64.so.2 --help - --help: error while loading shared libraries: --help: cannot open shared object file Telcontar:~ #
This is the Factory mailing list, not support. The function doesn't exist in Leap yet: # inxi -S System: Host: p5bse Kernel: 5.14.21-150400.24.21-default arch: x86_64 bits: 64 Console: pty pts/0 Distro: openSUSE Leap 15.5 Alpha # /lib64/ld-linux-x86-64.so.2 --help --help: error while loading shared libraries: --help: cannot open shared object file -- 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 2022-09-26 20:24, Felix Miata wrote:
Carlos E. R. composed on 2022-09-26 12:09 (UTC+0200):
El 2022-09-02 a las 11:20 +0200, Bengt Gördén escribió:
About a year ago I stumbled upon this. (I usually save all interesting commands for later use)
/lib64/ld-linux-x86-64.so.2 --help
Telcontar:~ # /lib64/ld-linux-x86-64.so.2 --help - --help: error while loading shared libraries: --help: cannot open shared object file Telcontar:~ #
This is the Factory mailing list, not support. The function doesn't exist in Leap yet:
Understood, but if a command is posted here, I have to ask here to the people that know that command. And yes, I guessed that the Leap library doesn't have this functionality, it is new. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
* Carlos E. R. <robin.listas@telefonica.net> [09-26-22 14:32]: > On 2022-09-26 20:24, Felix Miata wrote: > > Carlos E. R. composed on 2022-09-26 12:09 (UTC+0200): > > > El 2022-09-02 a las 11:20 +0200, Bengt Gördén escribió: > > > > About a year ago I stumbled upon this. (I usually save all interesting > > > > commands for later use) > > > > > > /lib64/ld-linux-x86-64.so.2 --help > > > Telcontar:~ # /lib64/ld-linux-x86-64.so.2 --help > > > - --help: error while loading shared libraries: --help: cannot open shared object file > > > Telcontar:~ # > > > > This is the Factory mailing list, not support. The function doesn't exist in Leap yet: > > Understood, but if a command is posted here, I have to ask here to the > people that know that command. > > And yes, I guessed that the Leap library doesn't have this functionality, it > is new. then please be clear about your question and it's intention and much superfluous conversation will be avoided to everyone's benefit. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc
On Fri, 2022-09-02 at 11:03 +0200, Per Jessen wrote:
Ditto - machines all too old?
Going by avx/avx2 support, according to <https://en.wikipedia.org/wiki/X86-64#Microarchitecture_levels>:
per@office38:~> inxi -Cxx CPU: Topology: Quad Core model: Intel Core2 Quad Q6700 bits: 64 type: MCP arch: Core Merom rev: B L2 cache: 4096 KiB flags: lm nx pae sse sse2 sse3 ssse3 vmx bogomips: 21278 Speed: 1596 MHz min/max: 1600/2667 MHz Core speeds (MHz): 1: 1596 2: 1596 3: 1596 4: 1596
x86_64-v2
per@office68:~> inxi -Cxx CPU: Topology: Dual Core model: Intel Core i3-5005U bits: 64 type: MT MCP arch: Broadwell rev: 4 L2 cache: 3072 KiB flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 15963 Speed: 1696 MHz min/max: 500/1900 MHz Core speeds (MHz): 1: 1737 2: 1718 3: 1762 4: 1783
x86_64-v3
per@gaston:~> inxi -Cxx CPU: Topology: Single Core model: Intel Celeron bits: 64 type: MCP arch: Netburst Smithfield rev: 9 L2 cache: 256 KiB flags: lm nx pae sse sse2 sse3 bogomips: 5586 Speed: 2793 MHz min/max: N/A Core speed (MHz): 1: 2793
x86_64-v2
per@mirage:~> inxi -Cxx CPU: Quad core Intel Xeon X5450 (-HT-MCP-) arch: Penryn rev.6 cache: 6144 KB flags: (lm nx sse sse2 sse3 sse4_1 ssse3) bmips: 24000 clock speeds: max: 3000 MHz 1: 3000 MHz 2: 3000 MHz 3: 3000 MHz 4: 3000 MHz 5: 3000 MHz 6: 3000 MHz 7: 3000 MHz 8: 3000 MHz
x86_64-v2 Best wishes. -- Atri Bhattacharya <badshah400>
On Fri, 2022-09-02 at 10:36 +0200, Axel Braun wrote:
Hello Felix,
Am Freitag, 2. September 2022, 09:31:56 CEST schrieb Felix Miata:
Run inxi -Cxx to see what you have for "level:".
I fail to find 'level' in my output:
docb@X1E:~> inxi -Cxx CPU: Info: 6-core model: Intel Core i7-9750H bits: 64 type: MT MCP arch: Coffee Lake rev: A cache: L1: 384 KiB L2: 1.5 MiB L3: 12 MiB Speed (MHz): avg: 2337 high: 2600 min/max: 800/4500 cores: 1: 2600 2: 2600 3: 2600 4: 2600 5: 2600 6: 1129 7: 2600 8: 2600 9: 2600 10: 2600 11: 920 12: 2600 bogomips: 62399 Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
For a general idea of which instruction sets are supported at what microarchitecture level, please have a look at <https://en.wikipedia.org/wiki/X86-64#Microarchitecture_levels>. More specifically, if you see avx/avx2 supported on your CPU — as your inxi output shows — it supports at least x86_64-v3. Hope that helps. -- Atri Bhattacharya <badshah400>
On 9/2/22 04:21, Atri Bhattacharya wrote:
More specifically, if you see avx/avx2 supported on your CPU — as your inxi output shows — it supports at least x86_64-v3.
avx - that mean Sandy Bridge is the Intel cutoff for support, and somewhere around Vishera for AMD. -- David C. Rankin, J.D.,P.E.
Axel Braun composed on 2022-09-02 10:36 (UTC+0200):
Felix Miata composed:
Run inxi -Cxx to see what you have for "level:".
I fail to find 'level' in my output:
docb@X1E:~> inxi -Cxx CPU: Info: 6-core model: Intel Core i7-9750H bits: 64 type: MT MCP arch: Coffee Lake rev: A cache: L1: 384 KiB L2: 1.5 MiB L3: 12 MiB Speed (MHz): avg: 2337 high: 2600 min/max: 800/4500 cores: 1: 2600 2: 2600 3: 2600 4: 2600 5: 2600 6: 1129 7: 2600 8: 2600 9: 2600 10: 2600 11: 920 12: 2600 bogomips: 62399 Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
Sorry. I forgot to mention it's a new feature in the upcoming release of inxi, 3.3.22. I'm getting it now from inxi's devel version, pinxi 3.3.21-11: http://smxi.org/pinxi -- 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
Felix Miata composed on 2022-09-02 15:26 (UTC-0400):
Axel Braun composed on 2022-09-02 10:36 (UTC+0200):
Felix Miata composed:
Run inxi -Cxx to see what you have for "level:".
I fail to find 'level' in my output:
docb@X1E:~> inxi -Cxx CPU: Info: 6-core model: Intel Core i7-9750H bits: 64 type: MT MCP arch: Coffee Lake rev: A cache: L1: 384 KiB L2: 1.5 MiB L3: 12 MiB Speed (MHz): avg: 2337 high: 2600 min/max: 800/4500 cores: 1: 2600 2: 2600 3: 2600 4: 2600 5: 2600 6: 1129 7: 2600 8: 2600 9: 2600 10: 2600 11: 920 12: 2600 bogomips: 62399 Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
Sorry. I forgot to mention it's a new feature in the upcoming release of inxi, 3.3.22. I'm getting it now from inxi's devel version, pinxi 3.3.21-11:
Wrong again. It's already in inxi 3.3.21. It's Mesa dri info that's new in next release. -- 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
Hello openSUSE! sorry to yet again for the thread but this time I think this time we have some really good news! 1. Community (and mostly -v2 internal infra) was heard ALP will have minimal architecture baselines set to x86_64-v2, according to DimStar Factory will adopt the change first! SUSE plans to investigate hwcaps for v3 and potentially v4 support. Users of v1 can still use our 32 bit Intel images/rpms. This also means that we won't have to figure out how to do a reasonable benchmark in between v1 and v3! :) Slightly more in https://news.opensuse.org/2022/09/26/alp-architecture-baselevel-x86_64-v2/ Happy Hacking!
On Mon, Sep 26, 2022, 11:55 AM Lubos Kocman <lubos.kocman@suse.com> wrote:
Hello openSUSE!
sorry to yet again for the thread but this time I think this time we have some really good news!
1. Community (and mostly -v2 internal infra) was heard ALP will have minimal architecture baselines set to x86_64-v2, according to DimStar Factory will adopt the change first!
SUSE plans to investigate hwcaps for v3 and potentially v4 support. Users of v1 can still use our 32 bit Intel images/rpms.
This also means that we won't have to figure out how to do a reasonable benchmark in between v1 and v3! :)
Slightly more in https://news.opensuse.org/2022/09/26/alp-architecture-baselevel-x86_64-v2/
Happy Hacking!
This is great to hear!
Hi, Dominique, I ask you to very clearly announce which snapshot will bring this change so that the users of obsoleted hardware do not have to find it out the hard way. And it is probably a good decision not to make measurements of real life use cases so that we will never know how big the performance gain of this change really is. Kind regards, Dieter On Mon, 26 Sep 2022 15:54:23 +0000 Lubos Kocman wrote:
sorry to yet again for the thread but this time I think this time we have some really good news!
1. Community (and mostly -v2 internal infra) was heard ALP will have minimal architecture baselines set to x86_64-v2, according to DimStar Factory will adopt the change first!
SUSE plans to investigate hwcaps for v3 and potentially v4 support. Users of v1 can still use our 32 bit Intel images/rpms.
This also means that we won't have to figure out how to do a reasonable benchmark in between v1 and v3! :)
On 26.09.22 17:54, Lubos Kocman wrote:
SUSE plans to investigate hwcaps for v3 and potentially v4 support. Users of v1 can still use our 32 bit Intel images/rpms.
There will be 32bit Intel again for post-15.5 / ALP? Cool! It will be interesting to see how zypper dup handles this on my factory machines. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
Le lundi 26 septembre 2022 à 19:25 +0200, Stefan Seyfried a écrit :
On 26.09.22 17:54, Lubos Kocman wrote:
SUSE plans to investigate hwcaps for v3 and potentially v4 support. Users of v1 can still use our 32 bit Intel images/rpms.
There will be 32bit Intel again for post-15.5 / ALP? Cool!
ALP, for Intel platform, will be x86_64-v2. There won't be a 32bit flavor. -- Frederic CROZAT Enterprise Linux OS and Containers Architect SUSE
On 27.09.22 08:56, Frederic Crozat wrote:
Le lundi 26 septembre 2022 à 19:25 +0200, Stefan Seyfried a écrit :
On 26.09.22 17:54, Lubos Kocman wrote:
SUSE plans to investigate hwcaps for v3 and potentially v4 support. Users of v1 can still use our 32 bit Intel images/rpms.
There will be 32bit Intel again for post-15.5 / ALP? Cool!
ALP, for Intel platform, will be x86_64-v2. There won't be a 32bit flavor.
So openSUSE will not offer a stable (non-rolling) distribution for pre-x86_64-v2 at all, correct? -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
Le mardi 27 septembre 2022 à 09:00 +0200, Stefan Seyfried a écrit :
On 27.09.22 08:56, Frederic Crozat wrote:
Le lundi 26 septembre 2022 à 19:25 +0200, Stefan Seyfried a écrit :
On 26.09.22 17:54, Lubos Kocman wrote:
SUSE plans to investigate hwcaps for v3 and potentially v4 support. Users of v1 can still use our 32 bit Intel images/rpms.
There will be 32bit Intel again for post-15.5 / ALP? Cool!
ALP, for Intel platform, will be x86_64-v2. There won't be a 32bit flavor.
So openSUSE will not offer a stable (non-rolling) distribution for pre-x86_64-v2 at all, correct?
I can't speak for openSUSE community. I'm only speaking for SUSE ALP. -- Frederic CROZAT Enterprise Linux OS and Containers Architect SUSE
On 27. 09. 22, 9:00, Stefan Seyfried wrote:
On 27.09.22 08:56, Frederic Crozat wrote:
Le lundi 26 septembre 2022 à 19:25 +0200, Stefan Seyfried a écrit :
On 26.09.22 17:54, Lubos Kocman wrote:
SUSE plans to investigate hwcaps for v3 and potentially v4 support. Users of v1 can still use our 32 bit Intel images/rpms.
There will be 32bit Intel again for post-15.5 / ALP? Cool!
ALP, for Intel platform, will be x86_64-v2. There won't be a 32bit flavor.
So openSUSE will not offer a stable (non-rolling) distribution for pre-x86_64-v2 at all, correct?
No, I understand it like this: openSUSE will not offer any really supported distribution for pre-x86_64-v2 at all. regards, -- js suse labs
On Mon, 2022-09-26 at 19:25 +0200, Stefan Seyfried wrote:
On 26.09.22 17:54, Lubos Kocman wrote:
SUSE plans to investigate hwcaps for v3 and potentially v4 support. Users of v1 can still use our 32 bit Intel images/rpms.
There will be 32bit Intel again for post-15.5 / ALP? Cool!
It was meant that users might still use Factory. We'll not introduce additional architecture to SUSE's ALP in "openSUSE's ALP", especially now when full -v3 build is out of question.
It will be interesting to see how zypper dup handles this on my factory machines.
-- Luboš Kocman (he/him) openSUSE Leap Release Manager SUSE +1 2345678910 www.suse.com
Am Mo., 26. Sept. 2022 um 17:55 Uhr schrieb Lubos Kocman <lubos.kocman@suse.com>:
1. Community (and mostly -v2 internal infra) was heard ALP will have minimal architecture baselines set to x86_64-v2, according to DimStar Factory will adopt the change first!
Does that mean that Leap 16 will be -v2?
SUSE plans to investigate hwcaps for v3 and potentially v4 support. Users of v1 can still use our 32 bit Intel images/rpms.
Not an option. See https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/message/... Best Martin
On Mon, 2022-09-26 at 21:46 +0200, Martin Schröder wrote:
Am Mo., 26. Sept. 2022 um 17:55 Uhr schrieb Lubos Kocman <lubos.kocman@suse.com>:
1. Community (and mostly -v2 internal infra) was heard ALP will have minimal architecture baselines set to x86_64-v2, according to DimStar Factory will adopt the change first!
Does that mean that Leap 16 will be -v2?
Leap was built on top of the newest SLE product family. ALP is quite different from SLE and that's why SUSE advertises it as a new parallel "family of sollution" rather than direct sucessor. I think the name of openSUSE's take on ALP will be in a some way related to SUSE's name whatever it will be.
SUSE plans to investigate hwcaps for v3 and potentially v4 support. Users of v1 can still use our 32 bit Intel images/rpms.
Not an option.
See https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/message/...
Best Martin
-- Luboš Kocman (he/him) openSUSE Leap Release Manager SUSE +1 2345678910 www.suse.com
Dne úterý 27. září 2022 15:13:03 CEST, Lubos Kocman napsal(a):
Leap was built on top of the newest SLE product family. ALP is quite different from SLE and that's why SUSE advertises it as a new parallel "family of sollution" rather than direct sucessor. I think the name of openSUSE's take on ALP will be in a some way related to SUSE's name whatever it will be.
I'm sorry, I'm bit lost. So, will there be TW, ALP, and also some future Leap (following SLE as now)? -- Vojtěch Zeisek https://trapa.cz/ Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux https://www.opensuse.org/
Am Di., 27. Sept. 2022 um 15:13 Uhr schrieb Lubos Kocman <lubos.kocman@suse.com>:
On Mon, 2022-09-26 at 21:46 +0200, Martin Schröder wrote:
Does that mean that Leap 16 will be -v2?
Leap was built on top of the newest SLE product family. ALP is quite different from SLE and that's why SUSE advertises it as a new parallel "family of sollution" rather than direct sucessor.
That sounds like there could be SLE 16 *and* ALP. You haven't really answered my question: Will the successor of Leap 15 be -v2? Currently Leap uses SLE binaries. Best Martin
Am 27.09.22 um 17:23 schrieb Martin Schröder:
That sounds like there could be SLE 16 *and* ALP. ALP is merely a codename - just as "SLE 16" is one. Just because it contains SLE and has a number higher than 15 doesn't imply anything about the product. SLE 11, SLE 12 and SLE 15 are all vastely different products.
And ALP is by name a "platform", so even less a product comparable to SLE 15. And what openSUSE does out of it, largely depends on the community. History has shown that many will object to changes affecting their beloved old laptop - but are not willing to do the least to keep it alive.
You haven't really answered my question: Will the successor of Leap 15 be -v2? Currently Leap uses SLE binaries.
To be fully transparent: what was decided lately: it will *not* be V3. How much code we will compile to require V2 is up in the air and also depends on the cost/benefit calculation that is currently in progress. As mentioned, building with V2 was just recently started in one staging project of Factory. But we do know: if we don't deprecate V1 with the new code stream, we won't do it in the next decade. Greetings, Stephan P.s. Hardware sucks - and it always had.
On 27.09.22 18:00, Stephan Kulow wrote:
History has shown that many will object to changes affecting their beloved old laptop - but are not willing to do the least to keep it alive.
I'm trying but OBS won't let me ("quota exceeded"). Will something like this: <project name="home:seife:Factory"> <title/> <description/> <link project="openSUSE.org:openSUSE:Factory"/> <build> <enable/> </build> <repository name="standard" rebuild="direct" linkedbuild="all"> <path project="openSUSE.org:openSUSE:Factory" repository="snapshot"/> <arch>x86_64</arch> </repository> </project> also work in a linked downstream OBS instance? If yes I'll try to spin up some big workers tomorrow to test it.
But we do know: if we don't deprecate V1 with the new code stream, we won't do it in the next decade.
And what gains will deprecating V1 bring -- apart from satisfying hardware partners/sponsors? -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
Am 27.09.22 um 18:12 schrieb Stefan Seyfried:
On 27.09.22 18:00, Stephan Kulow wrote:
History has shown that many will object to changes affecting their beloved old laptop - but are not willing to do the least to keep it alive.
I'm trying but OBS won't let me ("quota exceeded").
Will something like this:
<project name="home:seife:Factory"> <title/> <description/> <link project="openSUSE.org:openSUSE:Factory"/> <build> <enable/> </build> <repository name="standard" rebuild="direct" linkedbuild="all"> <path project="openSUSE.org:openSUSE:Factory" repository="snapshot"/> <arch>x86_64</arch> </repository> </project>
also work in a linked downstream OBS instance? If yes I'll try to spin up some big workers tomorrow to test it. Yes, it should.
But we do know: if we don't deprecate V1 with the new code stream, we won't do it in the next decade.
And what gains will deprecating V1 bring -- apart from satisfying hardware partners/sponsors? To paraquote Thorsten: why did you remove the part about benefit/cost calculation in my mail?
Greetings, Stephan
On 27.09.22 18:16, Stephan Kulow wrote:
Am 27.09.22 um 18:12 schrieb Stefan Seyfried:
And what gains will deprecating V1 bring -- apart from satisfying hardware partners/sponsors? To paraquote Thorsten: why did you remove the part about benefit/cost calculation in my mail?
Ok, I'll bite: What are the costs of keeping V1 compatibility? -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
Am 27.09.22 um 20:43 schrieb Stefan Seyfried:
Ok, I'll bite: What are the costs of keeping V1 compatibility?
Let's assume cutting out V1 brings X% performance gain (and I understand that X is low and I repeat again, I'm not argueing for the case, I'm argueing against a No based on 2012 hardware without further arguments). Keeping V1 compatiblity for the sake of it means dropping X% performance gain for everyone so that Mathias can keep using his old MicroServer[1] (that is not even running Tumbleweed). That is a cost to me. Now my expectation is that someone somewhere will identify specific packages that make a reasonable difference if provided with different hwcaps and then we should do that. Just as we offer a glibc.i686 but still have a i586 distro. Greetings, Stephan
Hello, On Tue, Sep 27, 2022 at 06:00:32PM +0200, Stephan Kulow wrote:
Am 27.09.22 um 17:23 schrieb Martin Schröder:
History has shown that many will object to changes affecting their beloved old laptop - but are not willing to do the least to keep it alive.
Except in this case there is nothing to be done to keep the old hardware working, the objection is to a change that arbitrarily disables support for perfectly working hardware.
You haven't really answered my question: Will the successor of Leap 15 be -v2? Currently Leap uses SLE binaries. To be fully transparent: what was decided lately: it will *not* be V3. How much code we will compile to require V2 is up in the air and also depends on the cost/benefit calculation that is currently in progress.
As mentioned, building with V2 was just recently started in one staging project of Factory.
But we do know: if we don't deprecate V1 with the new code stream, we won't do it in the next decade.
And does v1 need deprecating? If we included some more modern CPU features we could get some actual performance benefit. With v2 alone nobody provided any demostration of actual improvement. Sure, v1 hardware will probably not be very useful in 10 years but we are talking about deprecating it now. Also it is not very useful talking in terms of v1, v2, v3, v4. These are just bunch of unrelated CPU features lumped together. With Intel vs AMD and different CPu models the availablility of features varies wildly between CPU of the same vintage. And to get performance benefit in a specific case a specific CPU feature is required, not v2, v3, or v4. Thanks Michal
Am 27.09.22 um 18:19 schrieb Michal Suchánek:
Except in this case there is nothing to be done to keep the old hardware working, the objection is to a change that arbitrarily disables support for perfectly working hardware. Well, if that was the argument we would still all run 32bit.
I don't know where the benefits are for changing compiler flags and I didn't ask for it - but in case it does help, there must be a way forward other than "no, this will break my 2014 laptop". So please keep an open mind and ask the right questions - what helps where and why and how can we mitigate the impact of raising the bar? Greetings, Stephan
On Tue, Sep 27, 2022 at 06:29:09PM +0200, Stephan Kulow wrote:
Am 27.09.22 um 18:19 schrieb Michal Suchánek:
Except in this case there is nothing to be done to keep the old hardware working, the objection is to a change that arbitrarily disables support for perfectly working hardware. Well, if that was the argument we would still all run 32bit.
I don't know where the benefits are for changing compiler flags and I didn't ask for it - but in case it does help, there must be a way forward other than "no, this will break my 2014 laptop".
So please keep an open mind and ask the right questions - what helps where and why and how can we mitigate the impact of raising the bar?
Now you removed exactly the question about what helps where and why. If ALP is about adaptability wouldn't it make more sense to figure out how to deliver packages built to take advantage of the most modern CPU extensions where it matters without raising the bar in general? There will be always users with the newest CPUs that could greatly benefit from some optimizations of specific performance-critical packages but can't if we insist that everyone must run the same binary of everything, and we can't cut off users of CPUs that were released last year or a few years ago. Thanks Michal
Now you removed exactly the question about what helps where and why. Because I can't answer it - and I don't have to, because I don't want
Am 27.09.22 um 18:39 schrieb Michal Suchánek: this change either [nor opposing it]. I'm just trying to get reason into this discussion :)
If ALP is about adaptability wouldn't it make more sense to figure out how to deliver packages built to take advantage of the most modern CPU extensions where it matters without raising the bar in general?
That's already the plan to support V3 hardware. We really have to measure this. If it's e.g. only crypto algorithms benefiting, it's a different discussion to have than if it's multimedia codecs or if it's general workloads (like spellcheking emails). Greetings, Stephan
On Tue, Sep 27, 2022 at 07:34:59PM +0200, Stephan Kulow wrote:
Am 27.09.22 um 18:39 schrieb Michal Suchánek:
If ALP is about adaptability wouldn't it make more sense to figure out how to deliver packages built to take advantage of the most modern CPU extensions where it matters without raising the bar in general?
That's already the plan to support V3 hardware. We really have to measure this. If it's e.g. only crypto algorithms benefiting, it's a different discussion to have than if it's multimedia codecs or if it's general workloads (like spellcheking emails).
Yes, crypto algorithms and multimedia codecs can typically benefit a lot from new CPU features (in absence of hardware accelerators). Some libraries that benefit a lot from new CPU features support dynamic dispatch upstream, and are built to make use of it. For these benefit of compiling for newer architecture will be minimal if any. And sure, compiling your e-mail client for x86_64-v4 can make spellchecking your mail a few % faster. The thing is, how much time do you spend waiting for your e-mails to be spellchecked? Typically none as opposed to typing them, fetching them from the server, and sending them. And that's the thing: for vast majority of code being able to run it a few % faster makes absolutely no difference for vast majority of use cases. And for a lot of code it would be great to run it faster but the bottleneck is not the CPU so the new instructions don't really help. Thanks Michal
How about this, let the "vanilla" Alp still run on all x86-64 levels, and if someone actually has a workload that would really benefit from the more optimized binaries, have them add another repository and run zypper dup. Could even be done during install. Am 27. September 2022 18:14:07 GMT-04:00 schrieb "Michal Suchánek" <msuchanek@suse.de>:
On Tue, Sep 27, 2022 at 07:34:59PM +0200, Stephan Kulow wrote:
Am 27.09.22 um 18:39 schrieb Michal Suchánek:
If ALP is about adaptability wouldn't it make more sense to figure out how to deliver packages built to take advantage of the most modern CPU extensions where it matters without raising the bar in general?
That's already the plan to support V3 hardware. We really have to measure this. If it's e.g. only crypto algorithms benefiting, it's a different discussion to have than if it's multimedia codecs or if it's general workloads (like spellcheking emails).
Yes, crypto algorithms and multimedia codecs can typically benefit a lot from new CPU features (in absence of hardware accelerators).
Some libraries that benefit a lot from new CPU features support dynamic dispatch upstream, and are built to make use of it. For these benefit of compiling for newer architecture will be minimal if any.
And sure, compiling your e-mail client for x86_64-v4 can make spellchecking your mail a few % faster. The thing is, how much time do you spend waiting for your e-mails to be spellchecked? Typically none as opposed to typing them, fetching them from the server, and sending them.
And that's the thing: for vast majority of code being able to run it a few % faster makes absolutely no difference for vast majority of use cases.
And for a lot of code it would be great to run it faster but the bottleneck is not the CPU so the new instructions don't really help.
Thanks
Michal
-- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
On 28/09/2022 00.34, Mathias Homann wrote:
How about this, let the "vanilla" Alp still run on all x86-64 levels, and if someone actually has a workload that would really benefit from the more optimized binaries, have them add another repository and run zypper dup. Could even be done during install.
In principle yes, but then you need to QA both of them and if only one of them fails, you either have different timelines of updates or you hold up both. If we had a kernel-v1 rpm and 32bit core userland (that does not need
3GB RAM), then there could be different containers for workload.
OTOH the last real 32-bit-only hardware I saw was that Pentium-4 and my early eeepcs with slow Atom processor, so why do we keep i586 around? Probably for wine + steam + Windows games.
On Wed, Sep 28, 2022 at 12:14:07AM +0200, Michal Suchánek wrote:
And that's the thing: for vast majority of code being able to run it a few % faster makes absolutely no difference for vast majority of use cases.
And for a lot of code it would be great to run it faster but the bottleneck is not the CPU so the new instructions don't really help.
Whilst not wanting to dead-end lots of very serviceable hardware, should be careful about not exploiting newer features too. Findings presented at a power conference by Intel a few years ago (seen similar from others too) was the benefit of doing things as quickly as possible, then diving into a low-power mode and/or shutting down subsystems of the chip. One might think "who cares about power-saving? This system's not a laptop/embedded/sensor etc", but inefficient work gets turned into heat, which then requires further management - one of our colos has charged us per U (rackspace), per GiB (bandwidth) and per W (thermal cost of aircon) for two decades; which was an unusual pricing structure at the outset. Seemingly marginal gains do add up over time. Full disclosure, our company collaborated on further research to instrument a system and see if power optimisations could be written into gcc/a compiler. Initially it was an immense project, similar to "extracting a decagram of myelin from 4 tons of earth worms". Daniel
On Wed, Sep 28, 2022 at 10:24:56AM +0100, Daniel Morris wrote:
On Wed, Sep 28, 2022 at 12:14:07AM +0200, Michal Suchánek wrote:
And that's the thing: for vast majority of code being able to run it a few % faster makes absolutely no difference for vast majority of use cases.
And for a lot of code it would be great to run it faster but the bottleneck is not the CPU so the new instructions don't really help.
Whilst not wanting to dead-end lots of very serviceable hardware, should be careful about not exploiting newer features too. Findings presented at a power conference by Intel a few years ago (seen similar from others too) was the benefit of doing things as quickly as possible, then diving into a low-power mode and/or shutting down subsystems of the chip.
One might think "who cares about power-saving? This system's not a laptop/embedded/sensor etc", but inefficient work gets turned into heat, which then requires further management - one of our colos has charged us per U (rackspace), per GiB (bandwidth) and per W (thermal cost of aircon) for two decades; which was an unusual pricing structure at the outset. Seemingly marginal gains do add up over time.
Full disclosure, our company collaborated on further research to instrument a system and see if power optimisations could be written into gcc/a compiler. Initially it was an immense project, similar to "extracting a decagram of myelin from 4 tons of earth worms".
And do you have some data that you can share that shows which optimizarions save how much power for which workloads? That's exactly the thing I am missing here: some data showing the benefits of axing that hardware. Because the same applies to power savings as applies to time savings - optimizing code you do not run at all or very rarely does not save you time nor power. So far we only got some benchmark showing that compiling random pieces of code for x86-64-v3 runs mostly faster, and compiling some random pieces of code for x86-64-v2 runs sometimes faster and sometimes slower. Whith no summary so it is not clear how often it runs faster, and how often it runs slower. And it is not clear how often you will encounter such pieces of code in real world workloads, either. Thanks Michal
On Wed, Sep 28, 2022 at 09:12:43PM +0200, Michal Suchánek wrote:
Full disclosure, our company collaborated on further research to instrument a system and see if power optimisations could be written into gcc/a compiler. Initially it was an immense project, similar to "extracting a decagram of myelin from 4 tons of earth worms".
And do you have some data that you can share that shows which optimizarions save how much power for which workloads?
Sadly I don't think anything is as clear cut as that, but here's a link to Bristol Uni's research (courtesy of Embecosm stumping up the open access publication fee): https://doi.org/10.1093/comjnl/bxt129
That's exactly the thing I am missing here: some data showing the benefits of axing that hardware.
Because the same applies to power savings as applies to time savings - optimizing code you do not run at all or very rarely does not save you time nor power.
So far we only got some benchmark showing that compiling random pieces of code for x86-64-v3 runs mostly faster, and compiling some random pieces of code for x86-64-v2 runs sometimes faster and sometimes slower.
Whith no summary so it is not clear how often it runs faster, and how often it runs slower.
And it is not clear how often you will encounter such pieces of code in real world workloads, either.
There's always a chance that chip-feature X was hyper-specific to deep-pocketed customer Y and there is no general benefit. At least with RISC-V there'll be a ton of cryptic changelogs to grep through for the rationale. Daniel
On Thu, Sep 29, 2022 at 10:14:59AM +0100, Daniel Morris wrote:
On Wed, Sep 28, 2022 at 09:12:43PM +0200, Michal Suchánek wrote:
Full disclosure, our company collaborated on further research to instrument a system and see if power optimisations could be written into gcc/a compiler. Initially it was an immense project, similar to "extracting a decagram of myelin from 4 tons of earth worms".
And do you have some data that you can share that shows which optimizarions save how much power for which workloads?
Sadly I don't think anything is as clear cut as that, but here's a link to Bristol Uni's research (courtesy of Embecosm stumping up the open access publication fee):
That's an interesting paper, thanks. It's mostly focused on embedded systems, and mostly ARM architecture, and is not exactly recent. However, there are a few points that are clear. It is pretty much impossible to predict how optimization techniques affect performance without doing the actual measurement. For decisions arguing about performance solid data is a must, otherwise it's nonsense. Short execution time correlates with less power consumption in general but there is a case when it does not. On Cartex-A8 cores enabling NEON instruction generation switches from using the general purpose arithmetic unit to the SIMD unit which does not save time but is more energy efficient on this CPU for the tested benchmarks. This is interesting in multiple ways. The benchmarks used are mostly number crunching, and on this particular CPU it is difficult to move data between the general purpose arithmetic unit and the SIMD unit so you get to use one or the other. And the SIMD unit is not faster but is more energy efficient. If you had an algorithm that was easier to parallelize you could use both units but with the code in question GCC could not pull it off. But it can be seen in a different way, too. This NEON unit is an accelerator which you can use to offload computation in a more efficient way, and for many common computations accelerators are becoming available, either inside the CPU core itself or as a separate device. This makes the performance of the code running on the general purpose CPU less important over time, and this chase for more CPU features enabled for all code less rewarding. Thanks Michal
Stephan Kulow composed on 2022-09-27 18:29 (UTC+0200):
So please keep an open mind and ask the right questions - what helps> where and why and how can we mitigate the impact of raising the bar?
Is mitigation possible at all? I can't imagine it. It would be like removing Ukraine from the global food production map via radioactive poisoning, recoverable only via a vast amount of time and expense. Where would the money come from? -- 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
Stephan Kulow composed on 2022-09-27 18:29 (UTC+0200):
So please keep an open mind and ask the right questions - what helps> where and why and how can we mitigate the impact of raising the bar? Is mitigation possible at all? I can't imagine it. It would be like removing Ukraine from the global food production map via radioactive poisoning, recoverable only via a vast amount of time and expense. Where would the money come from? You really need to work on your analogies. But what I have in mind is
Am 27.09.22 um 20:45 schrieb Felix Miata: providing "legacy" repos as Richard outlined. Greetings, Stephan
Stephan Kulow composed on 2022-09-27 15:10 (UTC-0400):
what I have in mind is providing "legacy" repos as Richard outlined.
<https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/message/UUWBC6OFSBQ7SWQD6GSKIFUVC2EKSTC2/> I don't see promise in that. What I foresee is an aversion of new users to "SUSE" like it suffered from the Novell/Microsoft era, and a necessary exodus of current users, absent the required extra doers and hardware, spreading available resources thin to the detriment of distro quality. I hope to be proven wrong. -- 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
Am 27.09.22 um 18:19 schrieb Michal Suchánek:
And to get performance benefit in a specific case a specific CPU feature is required, not v2, v3, or v4.
This is btw also the argument why the rpm feature went nowhere: https://github.com/rpm-software-management/rpm/pull/1035 Greetings, Stephan
On Tue, Sep 27, 2022 at 06:39:05PM +0200, Stephan Kulow wrote:
Am 27.09.22 um 18:19 schrieb Michal Suchánek:
And to get performance benefit in a specific case a specific CPU feature is required, not v2, v3, or v4.
This is btw also the argument why the rpm feature went nowhere: https://github.com/rpm-software-management/rpm/pull/1035
Which also an argument against doing this arbirtaty cutoff, not in favor. Thanks Michal
Am 27.09.22 um 18:57 schrieb Michal Suchánek:
On Tue, Sep 27, 2022 at 06:39:05PM +0200, Stephan Kulow wrote:
Am 27.09.22 um 18:19 schrieb Michal Suchánek:
And to get performance benefit in a specific case a specific CPU feature is required, not v2, v3, or v4. This is btw also the argument why the rpm feature went nowhere: https://github.com/rpm-software-management/rpm/pull/1035 Which also an argument against doing this arbirtaty cutoff, not in favor.
I didn't say otherwise. Greetings, Stephan
Lubos Kocman composed on 2022-09-26 15:54 (UTC):
sorry to yet again for the thread but this time I think this time we have some really good news!
1. Community (and mostly -v2 internal infra) was heard ALP will have minimal architecture baselines set to x86_64-v2, according to DimStar Factory will adopt the change first!
Not good news at all! I have the following x86_64/amd64 CPUs currently running Leap and/or TW, most both. The following is the age and level inventory of those with v2 or better according to output from lscpu, inxi -Ca and/or /lib64/ld-linux-x86-64.so.2 --help \| tail -n17: v4 Q1'21 Rocket Lake i5-11400 v3 Q1'17 Kaby Lake i3-7100T v2 Q1'17 Kaby Lake G4600 # no avx, no avx2 v? Q3'15 AMD Godaveri A8-8650-B # avx yes; avx2 no (dead motherboard ATM) v3 Q2'14 Haswell i4150T v2 Q1'14 AMD Kaveri A10-7850K # avx yes; avx2 no v2 Q3'13 Haswell G3220 # no avx, no avx2 ------- Total 6, 7 only if I find a suitable replacement motherboard at reasonable cost Active openSUSE hosts' CPUs with v1 & at least 2 CPU "threads" v1 Q3'13 Sempron 3000+ (single thread) v1 Q3'09 Athlon II X2 240 v1 Q2'09 Core2Duo E7600 v1 Q2'09 Core2Duo E7600 v1 Q1'09 Core2Duo E7500 v1 Q1'08 Core2Duo E8400 v1 Q1'08 Core2Duo E8400 v1 Q1'08 Core2Duo E8400 v1 Q1'08 Core2Duo E8400 v1 Q2'07 Core2Duo E4400 v1 Q2'07 Core2Duo T7700 # iMac 24" v1 Q1'07 Pentium D 935 v1 Q3'06 Pentium D 945 v1 Q3'06 Core2Duo E6700 v1 Q3'06 Core2Duo E6700 v1 Q2'06 Pentium 651 v1 Q1'06 Core2Duo E6400 v1 Q1'06 Pentium D 930 v1 Q1'06 Pentium 641 v1 Q1'05 Pentium 630 -------- Total 19, assuming I didn't forget any. If we count 7 for v2-up, that's 7 of 26 or 73% of my active 64bit PCs unable to continue with a stable + safe *openSUSE* release after 15.5 support ends in just over 2 years from now. Both my brothers, each with >2 PCs running Leap, and one sister, have no PCs supporting more than v1. Like many people, they can only afford to buy pre-owned, meaning 5 or so years old when acquired, and typically more than 15 years old when retirement anticipated. The gain from v2 vs. v1 *really* needs to be quantified before the switch is flipped. -- 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, On 26. 09. 22, 17:54, Lubos Kocman wrote:
sorry to yet again for the thread but this time I think this time we have some really good news!
1. Community (and mostly -v2 internal infra) was heard ALP will have minimal architecture baselines set to x86_64-v2, according to
Fine for ALP, I don't care, but:
DimStar Factory will adopt the change first!
NACK (from a person who was taking care about tumbleweed with Greg at the beginning) Provided one of the non-avx procs is still rather wide-spread Core 2 Duo (correct me if I am wrong), you cannot simply cut them all off.
SUSE plans to investigate hwcaps for v3 and potentially v4 support. Users of v1 can still use our 32 bit Intel images/rpms.
You must be kidding. 1) i586 support is literally _NONE_. At least from the kernel side, but I am sure every other package is 2nd class citizen on 32bit. Ask also x86 kernel maintainers like Boris what they think before you suggest something like this. 2) You are going to support old 32 sh*t and not modern 64bit processors? Who is going to do that and how? Noone cares (in both meanings of the word) about 32bit nowadays. Are you going to hire devs to support 32bit? I doubt that. You are just going to throw the passengers overboard. 3) If you suggest people running 32bit kernel on a HW which already supports 64bit, I will stop providing 32bit kernel for TW (as it's merely provided, not supported). With that, I will also remove the x86_64-v2 flags from the x86_64 kernel build, so that it still runs on procs like Core 2 Duo (and with your suggested 32bit userspace). There are several reasons for that. From the main ones: using more than 4G of RAM without stupid remapping all the time; no limit of 3G VM (or 800M of vmap) space etc. I personally run some machines with Core 2 Duo to support drivers in the kernel for devices on the (now legacy) PCI bus. I see no single reason to discontinue that. Core 2 Duo are modern enough processors even nowadays, IMNSHO. You'd have to wait more years before
This also means that we won't have to figure out how to do a reasonable benchmark in between v1 and v3! :)
You'd have to. You have to persuade people why you are doing the step in the first place. It makes no sense to me. So again, NACK for tumbleweed. Do whatever you want in your ALP experiment. thanks, -- js suse labs
On Monday 2022-09-26 17:54, Lubos Kocman wrote:
1. Community (and mostly -v2 internal infra) was heard ALP will have minimal architecture baselines set to x86_64-v2, according to DimStar Factory will adopt the change first!
Of the benchmarks done by mjambor, there were no compelling benchmark results that speak for v2. To give you a reminder: https://jamborm.github.io/spec-2022-07-29-levels/spec2017int-1.html https://jamborm.github.io/spec-2022-07-29-levels/spec2017fp-1.html https://jamborm.github.io/spec-2022-07-29-levels/spec2006int-1.html https://jamborm.github.io/spec-2022-07-29-levels/spec2006fp-1.html
On Tue, Sep 27, 2022 at 4:22 AM Jan Engelhardt <jengelh@inai.de> wrote:
On Monday 2022-09-26 17:54, Lubos Kocman wrote:
1. Community (and mostly -v2 internal infra) was heard ALP will have minimal architecture baselines set to x86_64-v2, according to DimStar Factory will adopt the change first!
Of the benchmarks done by mjambor, there were no compelling benchmark results that speak for v2. To give you a reminder:
https://jamborm.github.io/spec-2022-07-29-levels/spec2017int-1.html https://jamborm.github.io/spec-2022-07-29-levels/spec2017fp-1.html https://jamborm.github.io/spec-2022-07-29-levels/spec2006int-1.html https://jamborm.github.io/spec-2022-07-29-levels/spec2006fp-1.html
The primary driver for upgrading the ISA level wasn't for performance. Between v2 or v3, I'd rather have v2 for more compatibility. -- 真実はいつも一つ！/ Always, there's only one truth!
On Tuesday 2022-09-27 10:28, Neal Gompa wrote:
1. Community (and mostly -v2 internal infra) was heard ALP will have minimal architecture baselines set to x86_64-v2, according to DimStar Factory will adopt the change first!
Of the benchmarks done by mjambor, there were no compelling benchmark results that speak for v2. To give you a reminder:
https://jamborm.github.io/spec-2022-07-29-levels/spec2017int-1.html https://jamborm.github.io/spec-2022-07-29-levels/spec2017fp-1.html https://jamborm.github.io/spec-2022-07-29-levels/spec2006int-1.html https://jamborm.github.io/spec-2022-07-29-levels/spec2006fp-1.html
The primary driver for upgrading the ISA level wasn't for performance.
But then, what was, and why is that something rated higher than a performance argument?
On 27.09.22 10:33, Jan Engelhardt wrote:
On Tuesday 2022-09-27 10:28, Neal Gompa wrote:
The primary driver for upgrading the ISA level wasn't for performance.
But then, what was, and why is that something rated higher than a performance argument?
Good question. Let me guess what the reason might be. From Wikipedia.org X86-64 article, the "Microarchitecture levels" were invented by AMD and Intel together with RedHat and SUSE. I'd say at least the first two have a very strong interest in people getting rid of old hardware. Unfortunately (for them), 10 years old hardware nowadays is easily good enough for many uses. Of course that does not fit their interest in selling new stuff. So it needs to be made obsolete by means of "Windows 11 will not run because of missing TPM" (or whatever), "Linux distributions will not run because of missing x86-64-vX". I hope that at least debian will not be bribed into implementing this. These core2 duo machines with 8GB RAM of mine (Thinkpad X200s) that "we" are trying to get rid of here are happily running even Windows 10 or normally sized Browser sessions. They are not as snappy as my core i5-2520 (Thinkpad T420) or core i3-3320 (Thinkpad T430) machines, but very usable still. Not to mention home server machines using core2 duo / 16GB RAM and happily running owncloud, vdr (with a PCI card that can not be put into a newer PC due to apparent lack of PCI slots in newer machines), NFS server, openVPN, ... and some VMs for testing from time to time. So, at least for me, there really should be some convincing performance or maintenance cost arguments that persuade me to get rid of all these machines and replace them with newer ones, but not just "Intel/AMD wants this old stuff to die". -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
On Tue, 27 Sep 2022, Jan Engelhardt wrote:
On Tuesday 2022-09-27 10:28, Neal Gompa wrote:
1. Community (and mostly -v2 internal infra) was heard ALP will have minimal architecture baselines set to x86_64-v2, according to DimStar Factory will adopt the change first!
Of the benchmarks done by mjambor, there were no compelling benchmark results that speak for v2. To give you a reminder:
https://jamborm.github.io/spec-2022-07-29-levels/spec2017int-1.html https://jamborm.github.io/spec-2022-07-29-levels/spec2017fp-1.html https://jamborm.github.io/spec-2022-07-29-levels/spec2006int-1.html https://jamborm.github.io/spec-2022-07-29-levels/spec2006fp-1.html
The primary driver for upgrading the ISA level wasn't for performance.
But then, what was, and why is that something rated higher than a performance argument?
For a business there's always marketing (and there comparing with competitors). From a technical POV you just need to pick the appropriate benchmark to show the (missing) advantage. 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 27.09.22 13:07, Richard Biener wrote:
On Tue, 27 Sep 2022, Jan Engelhardt wrote:
On Tuesday 2022-09-27 10:28, Neal Gompa wrote:
1. Community (and mostly -v2 internal infra) was heard ALP will have minimal architecture baselines set to x86_64-v2, according to DimStar Factory will adopt the change first!
Of the benchmarks done by mjambor, there were no compelling benchmark results that speak for v2. To give you a reminder:
https://jamborm.github.io/spec-2022-07-29-levels/spec2017int-1.html https://jamborm.github.io/spec-2022-07-29-levels/spec2017fp-1.html https://jamborm.github.io/spec-2022-07-29-levels/spec2006int-1.html https://jamborm.github.io/spec-2022-07-29-levels/spec2006fp-1.html
The primary driver for upgrading the ISA level wasn't for performance.
But then, what was, and why is that something rated higher than a performance argument?
For a business there's always marketing (and there comparing with competitors).
On the official website of SUSE [1] I can read: At SUSE, we believe we all bear a responsibility to preserve our planet for generations to come. We want to be part of the solution to the challenges facing our world. So the capability to run an older system and thus to avoid having to throw it away and to harm the environment by that action should be supported actively by SUSE. Seems marketing is more important than SUSE's focus areas. Juergen [1]: https://www.suse.com/esg/
Hear hear Am 30. September 2022 11:06:01 GMT-04:00 schrieb Juergen Gross <jgross@infradead.org>:
On 27.09.22 13:07, Richard Biener wrote:
On Tue, 27 Sep 2022, Jan Engelhardt wrote:
On Tuesday 2022-09-27 10:28, Neal Gompa wrote:
1. Community (and mostly -v2 internal infra) was heard ALP will have minimal architecture baselines set to x86_64-v2, according to DimStar Factory will adopt the change first!
Of the benchmarks done by mjambor, there were no compelling benchmark results that speak for v2. To give you a reminder:
https://jamborm.github.io/spec-2022-07-29-levels/spec2017int-1.html https://jamborm.github.io/spec-2022-07-29-levels/spec2017fp-1.html https://jamborm.github.io/spec-2022-07-29-levels/spec2006int-1.html https://jamborm.github.io/spec-2022-07-29-levels/spec2006fp-1.html
The primary driver for upgrading the ISA level wasn't for performance.
But then, what was, and why is that something rated higher than a performance argument?
For a business there's always marketing (and there comparing with competitors).
On the official website of SUSE [1] I can read:
At SUSE, we believe we all bear a responsibility to preserve our planet for generations to come. We want to be part of the solution to the challenges facing our world.
So the capability to run an older system and thus to avoid having to throw it away and to harm the environment by that action should be supported actively by SUSE.
Seems marketing is more important than SUSE's focus areas.
Juergen
-- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
On 30.09.22 17:06, Juergen Gross wrote:
On the official website of SUSE [1] I can read:
At SUSE, we believe we all bear a responsibility to preserve our planet for generations to come. We want to be part of the solution to the challenges facing our world.
So the capability to run an older system and thus to avoid having to throw it away and to harm the environment by that action should be supported actively by SUSE.
This can also be interpreted the other way round: if 10% energy can be saved by using more efficient programs (ususally, "better performance" translates to "less time in high power full-cpu-consumption mode"), this gain should not be wasted by tending to a small fraction of the installed base. I'm not saying it is correct one or the other way, but I'm also strongly opposed to obsoleting perfectly good machines without showing that there is an actual reason other than "intel and amd wants these machines to finally go away so they can sell new ones". -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
Stefan Seyfried composed on 2022-10-01 10:38 (UTC+0200):
gain should not be wasted by tending to a small fraction of the installed base.
Small? Where's the data that says so? What does "small" mean? How do we know half the planet's user-base isn't pre-level2? How do we know the size of the fraction below level2 that has the means to get past level1 before avx9 and sse100 have reached the marketplace? -- 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 Sat, Oct 01, 2022 at 05:30:08AM -0400, Felix Miata wrote:
Stefan Seyfried composed on 2022-10-01 10:38 (UTC+0200):
gain should not be wasted by tending to a small fraction of the installed base.
Small? Where's the data that says so? What does "small" mean? How do we know half the planet's user-base isn't pre-level2? How do we know the size of the fraction below level2 that has the means to get past level1 before avx9 and sse100 have reached the marketplace?
Yes, maybe if we provided multiple builds of glibc or openssl for different CPU feature sets and a mechanim that automatically installs the one that's suitable for the CPU you are using we would get download statitics, and decide what to do when we have some data. Thanks Michal
so is it fair to exclude most of the student base that may be pushed to spend more than a few hundred £/$ on a secondhand machine , remembering that the dell t7600 workstation still fetches around that for a machine that is still a v1 (twin CPU E5-2680 0 cpus with ht giving 32 cores at 2.8ghz 64gb ram ) still quite a good machine by todays specs but unfortunately to be scrap as no v2 support ,,,, and £750 for a system thats v4 to replace it at the same spec's i seem to think theres going to be a vast number in the user base , especially those that cant afford to spend so much on a new (secondhand machine ) to replace there current ones , and having equipment that is going to be redundant after that was the main user base for suse , and linux in general ,, it could be quite a high number of users 50%+ , a small fraction ? david On Sat, 1 Oct 2022 at 10:57, Michal Suchánek <msuchanek@suse.de> wrote:
On Sat, Oct 01, 2022 at 05:30:08AM -0400, Felix Miata wrote:
Stefan Seyfried composed on 2022-10-01 10:38 (UTC+0200):
gain should not be wasted by tending to a small fraction of the installed base.
Small? Where's the data that says so? What does "small" mean? How do we know half the planet's user-base isn't pre-level2? How do we know the size of the fraction below level2 that has the means to get past level1 before avx9 and sse100 have reached the marketplace?
Yes, maybe if we provided multiple builds of glibc or openssl for different CPU feature sets and a mechanim that automatically installs the one that's suitable for the CPU you are using we would get download statitics, and decide what to do when we have some data.
Thanks
Michal
Hello Jan, thank you for sharing the data. Lubos On Tue, 2022-09-27 at 10:21 +0200, Jan Engelhardt wrote:
On Monday 2022-09-26 17:54, Lubos Kocman wrote:
1. Community (and mostly -v2 internal infra) was heard ALP will have minimal architecture baselines set to x86_64-v2, according to DimStar Factory will adopt the change first!
Of the benchmarks done by mjambor, there were no compelling benchmark results that speak for v2. To give you a reminder:
https://jamborm.github.io/spec-2022-07-29-levels/spec2017int-1.html https://jamborm.github.io/spec-2022-07-29-levels/spec2017fp-1.html https://jamborm.github.io/spec-2022-07-29-levels/spec2006int-1.html https://jamborm.github.io/spec-2022-07-29-levels/spec2006fp-1.html
-- Luboš Kocman (he/him) openSUSE Leap Release Manager SUSE +1 2345678910 www.suse.com
Am 26. September 2022 11:54:23 GMT-04:00 schrieb Lubos Kocman <lubos.kocman@suse.com>:
Hello openSUSE!
Users of v1 can still use our 32 bit Intel images/rpms.
So I'll be throwing out most of the RAM in my server? -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
Am 27.09.22 um 18:26 schrieb Mathias Homann:
So I'll be throwing out most of the RAM in my server?
What server is that if I may ask? I think we're lacking data on how many systems are truely affected - and how many of those are running Tumbleweed. And a little less discussed topic: ALP is also said to support only UEFI hardware, is your V1 server already using UEFI? Greetings, Stephan
On Tue, Sep 27, 2022 at 06:35:28PM +0200, Stephan Kulow wrote:
Am 27.09.22 um 18:26 schrieb Mathias Homann:
So I'll be throwing out most of the RAM in my server?
What server is that if I may ask? I think we're lacking data on how many systems are truely affected - and how many of those are running Tumbleweed.
And a little less discussed topic: ALP is also said to support only UEFI hardware, is your V1 server already using UEFI?
ALP will drop support for non-efi, or also Tumbleweed? This discussion for the large part about Tumbleweed, and so far there is a lot of v1 non-efi hrdware that can run Tumbleweed perfectly fine. Thanks Michal
Am 27.09.22 um 18:46 schrieb Michal Suchánek:
ALP will drop support for non-efi, or also Tumbleweed? This discussion for the large part about Tumbleweed, and so far there is a lot of v1 non-efi hrdware that can run Tumbleweed perfectly fine. No, the discussion I replied to is about "Leap 16".
Greetings, Stephan
Am Di., 27. Sept. 2022 um 18:35 Uhr schrieb Stephan Kulow <coolo@suse.de>:
Am 27.09.22 um 18:26 schrieb Mathias Homann:
So I'll be throwing out most of the RAM in my server?
What server is that if I may ask? I think we're lacking data
E.g. HP ProLiant MicroServer N36L/N40L/N54L, introduced in 2011. Best Martin
On Tue, Sep 27, 2022 at 06:57:22PM +0200, Martin Schröder wrote:
Am Di., 27. Sept. 2022 um 18:35 Uhr schrieb Stephan Kulow <coolo@suse.de>:
Am 27.09.22 um 18:26 schrieb Mathias Homann:
So I'll be throwing out most of the RAM in my server?
What server is that if I may ask? I think we're lacking data
E.g. HP ProLiant MicroServer N36L/N40L/N54L, introduced in 2011.
And discontinued sometime around 2015. That's not exactly new hardware but there is no reason to replace it while it's working, either. Thanks Michal
It's a HP MicoServer N54L, running 15.4 right now. https://susepaste.org/79411374 I'm not sure if it could run with efi, right now it's installed as oldstyle mbr. What I do know is that out of 16GB ram the system uses 9-10GB on a normal day, so going back to 32bit would cripple it. Is TW heading the same way?? Cheers MH Am 27. September 2022 12:35:28 GMT-04:00 schrieb Stephan Kulow <coolo@suse.de>:
Am 27.09.22 um 18:26 schrieb Mathias Homann:
So I'll be throwing out most of the RAM in my server?
What server is that if I may ask? I think we're lacking data on how many systems are truely affected - and how many of those are running Tumbleweed.
And a little less discussed topic: ALP is also said to support only UEFI hardware, is your V1 server already using UEFI?
Greetings, Stephan
-- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
Am 27.09.22 um 19:01 schrieb Mathias Homann:
It's a HP MicoServer N54L, running 15.4 right now. 15.X will live for quite a while. Just for completness.
https://susepaste.org/79411374
I'm not sure if it could run with efi, right now it's installed as oldstyle mbr. Google says it's UEFI 2 - but then again the sites I find also claim it's maxed at 8GB.
Greetings, Stephan
On Tue, Sep 27, 2022 at 7:44 PM Stephan Kulow <coolo@suse.de> wrote:
Am 27.09.22 um 19:01 schrieb Mathias Homann:
It's a HP MicoServer N54L, running 15.4 right now. 15.X will live for quite a while. Just for completness.
https://susepaste.org/79411374
I'm not sure if it could run with efi, right now it's installed as oldstyle mbr. Google says it's UEFI 2 - but then again the sites I find also claim it's maxed at 8GB.
In my experience, HP hardware had broken UEFI until 2016. :( It was pretty much a given you needed to boot in CSM mode for most of their initial UEFI systems. -- 真実はいつも一つ！/ Always, there's only one truth!
On Fri, Sep 2, 2022 at 10:36 AM Axel Braun <docb@opensuse.org> wrote:
Am Freitag, 2. September 2022, 09:31:56 CEST schrieb Felix Miata:
Run inxi -Cxx to see what you have for "level:". I fail to find 'level' in my output: docb@X1E:~> inxi -Cxx
dont see any level stuff here either on plain 15.4. anyone? :(
On Sat, 03 Sep 2022, 17:36:50 +0200, cagsm wrote:
On Fri, Sep 2, 2022 at 10:36 AM Axel Braun <docb@opensuse.org> wrote:
Am Freitag, 2. September 2022, 09:31:56 CEST schrieb Felix Miata:
Run inxi -Cxx to see what you have for "level:". I fail to find 'level' in my output: docb@X1E:~> inxi -Cxx
dont see any level stuff here either on plain 15.4. anyone? :(
come on, Felix described which version of inxi is required to get that info. This version does not even exist on Tumbleweed, so why on Leap? Please use what's available out of the box as other described here: # /lib64/ld-linux-x86-64.so.2 --help It'll tell you which architecture your CPU is at. Cheers. l8er manfred
cagsm composed on 2022-09-03 17:36 (UTC+0200):
Axel Braun wrote:
schrieb Felix Miata:
Run inxi -Cxx to see what you have for "level:".
I fail to find 'level' in my output: docb@X1E:~> inxi -Cxx
dont see any level stuff here either on plain 15.4. anyone? :(
Releases of inxi are frequent, so Leap's inxi rarely is anywhere near current: inxi version: 3.3.21, Date: 2022-08-22 inxi version: 3.3.20, Date: 2022-07-27 inxi version: 3.3.19, Date: 2022-06-16 inxi version: 3.3.18, Date: 2022-06-13 inxi version: 3.3.17, Date: 2022-06-10 inxi version: 3.3.16, Date: 2022-05-19 inxi version: 3.3.15, Date: 2022-04-08 inxi version: 3.3.14, Date: 2022-03-24 inxi version: 3.3.13, Date: 2022-02-22 inxi version: 3.3.12, Date: 2022-01-18 inxi version: 3.3.11, Date: 2021-12-16 inxi version: 3.3.10, Date: 2021-12-13 inxi version: 3.3.09, Date: 2021-11-22 inxi version: 3.3.08, Date: 2021-10-21 inxi version: 3.3.07, Date: 2021-10-11 15 releases in 10 months. Most represent both bug fixes and enhancements. # zypse inxi | inxi | package | 3.3.07-bp154.1.19 | noarch | OSS | inxi | package | 3.3.20-lp154.46.1 | noarch | Utilities # cat /usr/local/bin/zypse #!/bin/sh zypper --no-refresh se -s $* | egrep -v 'debug|devel|srcp|openSUSE-20' | egrep 'x86|noarch'| sort Leap's inxi version was out of date more than 10 months ago. Its kernel version reporting began in 3.3.21. Latest functionality is available in the devel version pinxi: http://smxi.org/pinxi # inxi -Cxx --vs inxi 3.3.21-00 (2022-08-22) CPU: Info: dual core model: Intel Core i3-4150T bits: 64 type: MT MCP arch: Haswell level: v3 rev: 3 cache: L1: 128 KiB L2: 512 KiB L3: 3 MiB # Its -U switch run with sudo will update inxi to current, so old version isn't a serious issue except when a new feature leaks out before official release. Users who use -U now will find level reported. -- 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
Hello openSUSE! I found this help super helpful. On TW / MicroOS machine you can simply use (mentioned above) /lib64/ld-linux-x86-64.so.2 --help on Leap/SLES you'll can it from /proc/cpuinfo manually, this little wrapper from stackowerflow helps with that. #!/bin/sh -eu flags=$(cat /proc/cpuinfo | grep flags | head -n 1 | cut -d: -f2) supports_v2='awk "/cx16/&&/lahf/&&/popcnt/&&/sse4_1/&&/sse4_2/&&/ssse3/ {found=1} END {exit !found}"' supports_v3='awk "/avx/&&/avx2/&&/bmi1/&&/bmi2/&&/f16c/&&/fma/&&/abm/&&/movbe/&&/xsave/ {found=1} END {exit !found}"' supports_v4='awk "/avx512f/&&/avx512bw/&&/avx512cd/&&/avx512dq/&&/avx512vl/ {found=1} END {exit !found}"' echo "$flags" | eval $supports_v2 || exit 2 && echo "CPU supports x86- 64-v2" echo "$flags" | eval $supports_v3 || exit 3 && echo "CPU supports x86- 64-v3" echo "$flags" | eval $supports_v4 || exit 4 && echo "CPU supports x86- 64-v4" My "old tuxedo" with dead battery for years is v3 as well. I think people should really check their HW before pushing back. In many cases you might be surprised just like I was. We've had similar pushback on armv7, several people insisted on support, promised help and now it's pretty much just Dirk and Guillaume's best effort.That's the reality. We're just trying to have conversation. Either way the plan is to provide either v1 or v2 Community/Enterprise solution (depends on Factory) after 15.5. We're just waiting to see some actual data (performance benchmark). Lubos On Sat, 2022-09-03 at 13:02 -0400, Felix Miata wrote:
cagsm composed on 2022-09-03 17:36 (UTC+0200):
Axel Braun wrote:
schrieb Felix Miata:
Run inxi -Cxx to see what you have for "level:".
I fail to find 'level' in my output: docb@X1E:~> inxi -Cxx dont see any level stuff here either on plain 15.4. anyone? :( Releases of inxi are frequent, so Leap's inxi rarely is anywhere near current:
inxi version: 3.3.21, Date: 2022-08-22 inxi version: 3.3.20, Date: 2022-07-27 inxi version: 3.3.19, Date: 2022-06-16 inxi version: 3.3.18, Date: 2022-06-13 inxi version: 3.3.17, Date: 2022-06-10 inxi version: 3.3.16, Date: 2022-05-19 inxi version: 3.3.15, Date: 2022-04-08 inxi version: 3.3.14, Date: 2022-03-24 inxi version: 3.3.13, Date: 2022-02-22 inxi version: 3.3.12, Date: 2022-01-18 inxi version: 3.3.11, Date: 2021-12-16 inxi version: 3.3.10, Date: 2021-12-13 inxi version: 3.3.09, Date: 2021-11-22 inxi version: 3.3.08, Date: 2021-10-21 inxi version: 3.3.07, Date: 2021-10-11
15 releases in 10 months. Most represent both bug fixes and enhancements.
# zypse inxi | inxi | package | 3.3.07-bp154.1.19 | noarch | OSS | inxi | package | 3.3.20-lp154.46.1 | noarch | Utilities # cat /usr/local/bin/zypse #!/bin/sh zypper --no-refresh se -s $* | egrep -v 'debug|devel|srcp|openSUSE- 20' | egrep 'x86|noarch'| sort
Leap's inxi version was out of date more than 10 months ago. Its kernel version reporting began in 3.3.21. Latest functionality is available in the devel version pinxi: http://smxi.org/pinxi
# inxi -Cxx --vs inxi 3.3.21-00 (2022-08-22) CPU: Info: dual core model: Intel Core i3-4150T bits: 64 type: MT MCP arch: Haswell level: v3 rev: 3 cache: L1: 128 KiB L2: 512 KiB L3: 3 MiB #
Its -U switch run with sudo will update inxi to current, so old version isn't a serious issue except when a new feature leaks out before official release. Users who use -U now will find level reported.
-- Luboš Kocman (he/him) openSUSE Leap Release Manager SUSE +1 2345678910 www.suse.com
On Tue, Sep 6, 2022 at 11:02 AM Lubos Kocman <lubos.kocman@suse.com> wrote:
Hello openSUSE!
I found this help super helpful.
On TW / MicroOS machine you can simply use (mentioned above)
/lib64/ld-linux-x86-64.so.2 --help
on Leap/SLES you'll can it from /proc/cpuinfo manually, this little wrapper from stackowerflow helps with that.
#!/bin/sh -eu
flags=$(cat /proc/cpuinfo | grep flags | head -n 1 | cut -d: -f2)
supports_v2='awk "/cx16/&&/lahf/&&/popcnt/&&/sse4_1/&&/sse4_2/&&/ssse3/ {found=1} END {exit !found}"' supports_v3='awk "/avx/&&/avx2/&&/bmi1/&&/bmi2/&&/f16c/&&/fma/&&/abm/&&/movbe/&&/xsave/
"xsave" is wrong here
{found=1} END {exit !found}"' supports_v4='awk "/avx512f/&&/avx512bw/&&/avx512cd/&&/avx512dq/&&/avx512vl/ {found=1} END {exit !found}"'
echo "$flags" | eval $supports_v2 || exit 2 && echo "CPU supports x86- 64-v2" echo "$flags" | eval $supports_v3 || exit 3 && echo "CPU supports x86- 64-v3" echo "$flags" | eval $supports_v4 || exit 4 && echo "CPU supports x86- 64-v4"
As I already explained in this thread on the user list, you cannot reliably detect v3 and above based on information in /proc/cpuinfo. Neither the OSXSAVE flag nor supported XSAVE bits are exposed. Testing for XSAVE is an optimistic approximation where you hope that if XSAVE is supported then everything else will be correctly set up. libc actually queries processor for current OSXSAVE and supported XSAVE bits. Maybe it is possible to provide standalone binary replicating these tests.
My "old tuxedo" with dead battery for years is v3 as well. I think people should really check their HW before pushing back.
In many cases you might be surprised just like I was. We've had similar pushback on armv7, several people insisted on support, promised help and now it's pretty much just Dirk and Guillaume's best effort.That's the reality.
We're just trying to have conversation. Either way the plan is to provide either v1 or v2 Community/Enterprise solution (depends on Factory) after 15.5. We're just waiting to see some actual data (performance benchmark).
Lubos
On Sat, 2022-09-03 at 13:02 -0400, Felix Miata wrote:
cagsm composed on 2022-09-03 17:36 (UTC+0200):
Axel Braun wrote:
schrieb Felix Miata:
Run inxi -Cxx to see what you have for "level:".
I fail to find 'level' in my output: docb@X1E:~> inxi -Cxx
dont see any level stuff here either on plain 15.4. anyone? :(
Releases of inxi are frequent, so Leap's inxi rarely is anywhere near current:
inxi version: 3.3.21, Date: 2022-08-22 inxi version: 3.3.20, Date: 2022-07-27 inxi version: 3.3.19, Date: 2022-06-16 inxi version: 3.3.18, Date: 2022-06-13 inxi version: 3.3.17, Date: 2022-06-10 inxi version: 3.3.16, Date: 2022-05-19 inxi version: 3.3.15, Date: 2022-04-08 inxi version: 3.3.14, Date: 2022-03-24 inxi version: 3.3.13, Date: 2022-02-22 inxi version: 3.3.12, Date: 2022-01-18 inxi version: 3.3.11, Date: 2021-12-16 inxi version: 3.3.10, Date: 2021-12-13 inxi version: 3.3.09, Date: 2021-11-22 inxi version: 3.3.08, Date: 2021-10-21 inxi version: 3.3.07, Date: 2021-10-11
15 releases in 10 months. Most represent both bug fixes and enhancements.
# zypse inxi | inxi | package | 3.3.07-bp154.1.19 | noarch | OSS | inxi | package | 3.3.20-lp154.46.1 | noarch | Utilities # cat /usr/local/bin/zypse #!/bin/sh zypper --no-refresh se -s $* | egrep -v 'debug|devel|srcp|openSUSE- 20' | egrep 'x86|noarch'| sort
Leap's inxi version was out of date more than 10 months ago. Its kernel version reporting began in 3.3.21. Latest functionality is available in the devel version pinxi: http://smxi.org/pinxi
# inxi -Cxx --vs inxi 3.3.21-00 (2022-08-22) CPU: Info: dual core model: Intel Core i3-4150T bits: 64 type: MT MCP arch: Haswell level: v3 rev: 3 cache: L1: 128 KiB L2: 512 KiB L3: 3 MiB #
Its -U switch run with sudo will update inxi to current, so old version isn't a serious issue except when a new feature leaks out before official release. Users who use -U now will find level reported.
--
Luboš Kocman (he/him) openSUSE Leap Release Manager
SUSE +1 2345678910 www.suse.com
Am Dienstag, 6. September 2022, 10:33:36 CEST schrieb Andrei Borzenkov:
libc actually queries processor for current OSXSAVE and supported XSAVE bits. Maybe it is possible to provide standalone binary replicating these tests.
So basically you're saying the /lib64/ld-linux* --help test is the authoritative one, and both inxi and "that other script" can't actually be correct anyway, is that right? 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, 6 Sep 2022, Mathias Homann wrote:
Am Dienstag, 6. September 2022, 10:33:36 CEST schrieb Andrei Borzenkov:
libc actually queries processor for current OSXSAVE and supported XSAVE bits. Maybe it is possible to provide standalone binary replicating these tests.
So basically you're saying the /lib64/ld-linux* --help test is the authoritative one, and both inxi and "that other script" can't actually be correct anyway, is that right?
Not sure if this detail is really relevant - if the CPU supports saving the AVX state then our kernels will have that enabled. In theory you can probably run a virtual machine with the AVX state saving disabled but does that really matter here? That is, we don't support running a very old kernel without AVX support with ALP. 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 8/31/22 21:12, Lubos Kocman wrote:
All meeting minutes can be found here: https://etherpad.opensuse.org/p/ReleaseEngineering-meeting Meeting is hosted here https://meet.opensuse.org/ReleaseEngineeringMeeting
Richard: we should consider dropping transactional-server role - it is no longer maintained by it's creator (Richard) who believes MicroOS fully obsoletes it. There is also a discussion as to whether the minimal role should be removed due to it's large overlapping usecases with MicroOS
The Minimal Role still has a range of other uses, for example for anyone such as myself who does a "Non Standard" install, selecting the Minimal Role then using the installer to pick the other patterns that are actually needed such as kvm server and my desktop of choice is the easiest way to setup a system that may not be necessarily suitable for MicroOS. -- 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
participants (34)
-
Andrei Borzenkov -
Atri Bhattacharya -
Axel Braun -
Bengt Gördén -
Bernhard M. Wiedemann -
cagsm -
Carlos E. R. -
Dan Čermák -
Daniel Morris -
David C. Rankin -
David Powell -
Dennis Knorr -
dieter -
Dominique Leuenberger / DimStar -
Felix Miata -
Frederic Crozat -
James Knott -
Jan Engelhardt -
Jiri Slaby -
Juergen Gross -
Lubos Kocman -
Manfred Hollstein -
Martin Jambor -
Martin Schröder -
Mathias Homann -
Michal Suchánek -
Neal Gompa -
Patrick Shanahan -
Per Jessen -
Richard Biener -
Simon Lees -
Stefan Seyfried -
Stephan Kulow -
Vojtěch Zeisek