On Fri, Sep 2, 2022 at 8:46 AM David C. Rankin wrote:

On 9/2/22 01:40, Roger Oberholtzer wrote:

...

Is there a good description of the future of Leap in SUSE? A roadmap type of thing to help one understand where things are headed?

Looks grim.

The thread on factory "openSUSE Release Engineering meeting 31.08.2022" seems to say Leap 15.5 will be the last and I'm trying to get clarification on what they mean by support of HW older than x86_64-v3.

Pains me to see it, but looks like SUSE is killing the release model for openSUSE. I guess it's Tumbleweed or nothing from 15.5 on (I hope I'm wrong)

That's what's unclear to me. I thought that I had read that Leap as an entity was not so much going away as being merged with SUSE. Already in 15.3 the publisher for most all RPMs is no longer openSUSE. It is SUSE. I got the impression that releases that can be used like Leap would now be the standard SUSE release, but with a different license for use. A 'free' version would still be available. But I don't know that that is the case. I have no trouble paying for SUSE. The question is how it would be priced for a Leap-type use: you can use it, but there is no support. And, could one still make their own variation on the release via KIWI? That last one is a biggie for us. We make an OEM installer based on Leap that lets us ensure an absolutely identical install on all systems. Almost no user interaction. Knowing the current plans would be beneficial. -- Roger Oberholtzer

Le 02/09/2022 à 15:14, Predrag Ivanović a écrit :

AFAIK, 15.5*will* be the last Leap release, and what comes next will be based on ALP, and first alpha proof-of-concept of that is, AFAIK, planned for end of September/early October of 2022.

And that's exactly the problem. Announcing the replacement of a rock-solid proven concept by something that has not even yet reached pre-alpha state will like cause some raised eyebrows among the crowd of admins who need something reliable to work with. It's not like this sort of thing hasn't happened before. Remember the transition from GNOME 2.32 to 3.0 ? The transition from KDE 3.5 to 4.0 ? Or when CentOS 8 announced to be EOL eight years sooner than expected ? While giving OpenSUSE the benefit of the doubt, I'm already busy reading this: https://debian-handbook.info/browse/stable/ Cheers, Niki -- Microlinux - Solutions informatiques durables 7, place de l'église - 30730 Montpezat Site : https://www.microlinux.fr Blog : https://blog.microlinux.fr Mail : info@microlinux.fr Tél. : 04 66 63 10 32 Mob. : 06 51 80 12 12

On 2022-09-03 01:28:05 jdd@dodin.org wrote:

|Le 03/09/2022 à 06:54, Nicolas Kovacs a écrit : |> the crowd of admins who need something reliable to work with. | |openSUSE is more and more tied with SLED or SLES and I don't see SUSE |cutting of it's own client base, so we may wait a bit before saying too |definitive words... | |jdd

It would be nice if they would make a definitive statement, then. Leslie -- Operating System: Linux Distribution: openSUSE Leap 15.4 x86_64 Desktop Environment: Trinity

On 9/2/22 02:06, Andrei Borzenkov wrote:

What it actually says is that Leap 15.5 will likely be the last in the 15.x series and then comes whatever comes after SLE 15 (ALP or whatever). SLE 15 itself may have more service packs but there won't be corresponding openSUSE releases.

Thank Andrei, The last time this came up, the "what comes after Leap", was suggested to be a containerized implementation of SUSE. Is this still the plan? -- David C. Rankin, J.D.,P.E.

On 9/2/22 15:26, Darryl Gregorash wrote:

...

Thank Andrei,

  The last time this came up, the "what comes after Leap", was suggested to be a containerized implementation of SUSE. Is this still the plan?

What does "containerized version" even mean?

Micro Leap - minimal OS to support app deployment via containers, docker, or the other abominations like flatpak, etc.. -- David C. Rankin, J.D.,P.E.

On 2022-09-02 14:51, David C. Rankin wrote:

On 9/2/22 15:26, Darryl Gregorash wrote:

...

...

Thank Andrei,

   The last time this came up, the "what comes after Leap", was suggested to be a containerized implementation of SUSE. Is this still the plan?

What does "containerized version" even mean?

Micro Leap - minimal OS to support app deployment via containers, docker, or the other abominations like flatpak, etc..

"Abomination" somehow doesn't seem to do it justice. If that does happen, I'm gone -- very regrettably, but I'm gone.

On Fri, Sep 2, 2022 at 11:08 AM gumb wrote:

On 02/09/2022 08:46, David C. Rankin wrote:

...

The thread on factory "openSUSE Release Engineering meeting 31.08.2022" seems to say Leap 15.5 will be the last and I'm trying to get clarification on what they mean by support of HW older than x86_64-v3.

The Wikipedia page on x86_64 contains a mention of SUSE under the Implementations -> Microarchitecture levels section: https://en.wikipedia.org/wiki/X86-64#Implementations_2 Noted alongside is this reference, if you're on standard Intel hardware:

x86-64-v3 (circa 2015: Haswell and Excavator)

seriously, we had this discussion on factory or somewhere else like month/s? ago. i never understood the greed of cpu feature levels for the basic packages to make a system work. other people also wrote about special cpu featuresets being used in libraries and binaries where it would make sense and let various code paths decide there what the cpu would offer etc. thats how i understood it. its not that long ago that opensuse went to the x64 / x86-64 world to begin with. anyhow, i kind of feel over the past years that this opensuse project is strongly headed down the abandonware path :///// :( so sad

On 2022-09-02 08:46, David C. Rankin wrote:

On 9/2/22 01:40, Roger Oberholtzer wrote:

...

Is there a good description of the future of Leap in SUSE? A roadmap type of thing to help one understand where things are headed?

Looks grim.

  The thread on factory "openSUSE Release Engineering meeting 31.08.2022" seems to say Leap 15.5 will be the last and I'm trying to get clarification on what they mean by support of HW older than x86_64-v3.

  Pains me to see it, but looks like SUSE is killing the release model for openSUSE. I guess it's Tumbleweed or nothing from 15.5 on (I hope I'm wrong)

Looks very grim. Some kind of thing with containers on top. No longer Linux :-/ See this thread in factory: Archived-At: https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/message/... From: Axel Braun To: factory@lists.opensuse.org Subject: And what about Leap 15.5? (was: ALP Communty Meetings have started!) Date: Fri, 24 Jun 2022 10:27:29 +0200 -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)

On Fri, 2 Sep 2022 12:38:43 +0100 Dave Howorth wrote:

If I was going to have to move to a rolling release, I'd look first at arch.

And why is that? openSUSE Tumbleweed has several advantages over Arch (openQA, many good engineers, no need of AUR everything in official repos, good quality of packages and good process of adding packages compared to AUR, as fast or even faster, less breakages..)

On Fri, 2 Sep 2022 13:11:03 +0100 Dave Howorth wrote:

On Fri, 2 Sep 2022 13:50:05 +0200 Michael Vetter wrote:

...

On Fri, 2 Sep 2022 12:38:43 +0100 Dave Howorth wrote:

...

If I was going to have to move to a rolling release, I'd look first at arch.

And why is that? openSUSE Tumbleweed has several advantages over Arch (openQA, many good engineers, no need of AUR everything in official repos, good quality of packages and good process of adding packages compared to AUR, as fast or even faster, less breakages..)

I haven't thought about it too hard, because my main focus is stability and long support times, but AFAICT arch has much better documentation and it and the online support offered often answers questions I have about my Leap system. Opensuse has a decent community here but often very confusing documentation IME.

Their wiki indeed is very good. I would suggest to still read it about generic subjects but use Tumbleweed to have a more stable base. A lot of the information they have there is not Arch specific I think.

On Fri, 2 Sep 2022 16:11:42 -0500 "David C. Rankin" wrote:

On 9/2/22 07:11, Dave Howorth wrote:

...

I haven't thought about it too hard, because my main focus is stability and long support times, but AFAICT arch has much better documentation and it and the online support offered often answers questions I have about my Leap system. Opensuse has a decent community here but often very confusing documentation IME.

I've had Arch laptops, desktops and servers since 2009. Had fun watching the distro grow. A rolling release will never match the "reliability" of a release model -- but they come close. In 13 years, I've probably had only 3-4 issue that caused breakage -- but when they hit, you better be prepared to put the time in to resolve them -- and they always hit at the wrong time (like on vacation with the kids at Disney...) Linux 5.17 introduced an amdgpu bug that causes:

[ 10.028870] BUG: kernel NULL pointer dereference, address: 0000000000000000

and the folks at Freedesktop could apparently care less. There are a dozen bugs open at Freedesktop.org and after months it is not yet assigned. It causes hardlock on reboot, so if you remote admin that box -- your screwed.

Yes, but I don't think much of freedesktop anyway. I avoid nvidia like the plague and GPUs in general, specifically so I don't encounter problems with them. What's their purpose for the general user?

It also depends on how you use your system. If you have NVidia, Virtualbox or other 3rd party requirements (or just non-regularly maintained normal apps), that's where a rolling-release hurts. Just ask the TW folks about NVidia issues that crop up on kernel updates. The basic problem is when some app or kernel is updated and forced updates to other parts of your system, unless the developers for the other parts keep up to date, then that part of your system breaks.

I also avoid containers and VMs and suchlike for the same reason.

Both Arch an openSUSE try and minimize this by staging and holding back some packages until it will play nice with the rest -- the rest being being the distro packages, not your 3rd party packages -- those may still break.

Indeed, and that's fine by me. The one idiosyncracy I do admit to is an out-of-tree TV card driver (TBS) and I recently bought an Hauppauge card to replace it to avoid that issue.

The biggest test for a rolling-release is how long can you go without updates and still be able to update? There are changes that will come along that make updates problematic. If you can guarantee 2-3 months without problems, that's not bad. If you can guarantee 6 months that's great. Arch used to be able to go years between updates without issue, but changes to the package manager pacman has put fixed-points in the update timeline. (you can still move forward over years -- it just becomes much more involved)

Thanks for that; I'll check out the implications for me.

That said, I have 3 Arch servers, but I keep a 4th test machine (old Dell not worth much -- but a perfect test maching) that I update first to prevent being caught by surprise.

Daily driver has always been SUSE/openSUSE since Mandrake -- just for the stability. I can't have a breakage "at the wrong time" and have to spend a day dorking with it. That's what will be lost when Leap goes away.

Yes, I can't claim that long, maybe just 19 years with opensuse, but stability is what I crave. I want to use my system, not spend my life maintaining it!

Hi, On 9/2/22 07:38, Dave Howorth wrote:

On Fri, 2 Sep 2022 13:11:36 +0200 "Carlos E. R." wrote:

...

On 2022-09-02 08:46, David C. Rankin wrote:

...

On 9/2/22 01:40, Roger Oberholtzer wrote:

...

Is there a good description of the future of Leap in SUSE? A roadmap type of thing to help one understand where things are headed?

Looks grim.

Looks very grim.

Does anybody have a good answer to Roger's question, or is there no roadmap?

15.5 is committed and being worked on. 15.4 was just released a couple of months ago. Meaning if we do the math, 15.4 will carry us into 2023, then 15.5 will carry us to the end of 2024 before maintenance updates _potentially_ stop. Basically a question is being asked for planning of a community project about 2 years out. That's a stretch IMHO. Do we have a plan for all the Linux kernel features that are coming along in the next 2 years or what GNOME or KDE or many other bits an pieces of the distro will deliver in the next 2 years? Anybody know if docker will really be dead in 2 years and the world will have switched to podman? What other services will systemd try to subsume? There are new ideas being kicked around but no one really knows what this is going to look like even 1 year from now. I'd say it is recognized that abandoning a distribution that looks similar to what we are all used to is probably not the greatest idea since sliced bread. However, just because it may look similar to what we are used to does not mean it has to be put together in the same way.

I use Leap and would like to keep doing so. But I've been experimenting with Mint since it offers longer support for versions. If I was going to have to move to a rolling release, I'd look first at arch.

Makes me wonder if other distributions have a 2 year roadmap? I've never looked, so I really do not know. But you are of course free to choose a distribution of your liking. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Distinguished Engineer LINUX Technical Team Lead Public Cloud rjschwei@suse.com IRC: robjo

On Fri, 2 Sep 2022 12:38:43 +0100 Dave Howorth wrote:

On Fri, 2 Sep 2022 13:11:36 +0200 "Carlos E. R." wrote:

...

On 2022-09-02 08:46, David C. Rankin wrote:

...

On 9/2/22 01:40, Roger Oberholtzer wrote:

...

Is there a good description of the future of Leap in SUSE? A roadmap type of thing to help one understand where things are headed?

Looks grim.

Looks very grim.

Does anybody have a good answer to Roger's question, or is there no roadmap?

I repeat my question!

I use Leap and would like to keep doing so. But I've been experimenting with Mint since it offers longer support for versions. If I was going to have to move to a rolling release, I'd look first at arch.

I found https://news.opensuse.org/tag/adaptable-linux-platform and if that's Opensuse's idea of 'communication', I'm very disappointed. Also why I, or an OSS project, should care about a 'microarchitecture' other than as an implementation detail isn't clear to me. I've been able to have multiple versions of perl on my machine for many years without affecting the system's use of a particular version. I can't believe other languages haven't found solutions that are at least as good, so what's the problem?

On 9/2/22 16:13, Dave Howorth wrote:

On Fri, 2 Sep 2022 12:38:43 +0100 Dave Howorth wrote:

...

On Fri, 2 Sep 2022 13:11:36 +0200 "Carlos E. R." wrote:

...

On 2022-09-02 08:46, David C. Rankin wrote:

...

On 9/2/22 01:40, Roger Oberholtzer wrote:

...

Is there a good description of the future of Leap in SUSE? A roadmap type of thing to help one understand where things are headed?

Looks grim.

Looks very grim.

Does anybody have a good answer to Roger's question, or is there no roadmap?

I repeat my question!

...

I use Leap and would like to keep doing so. But I've been experimenting with Mint since it offers longer support for versions. If I was going to have to move to a rolling release, I'd look first at arch.

I found https://news.opensuse.org/tag/adaptable-linux-platform and if that's Opensuse's idea of 'communication', I'm very disappointed. Also why I, or an OSS project, should care about a 'microarchitecture' other than as an implementation detail isn't clear to me.

<quote> SUSE’s aim with its Adaptable Linux Platform is to build a new immutable-base operating system for enhanced application-layer features and container orchestration on newer hardware. The prototype that is expected soon will have x86-64-v3 as a baseline. </quote> From what I gather on the factory list, that means processors and motherboards from 2020 on. If you have older hardware -- you're not invited to the party and you are just fsck'ed. -- David C. Rankin, J.D.,P.E.

On Sat, 3 Sep 2022 01:03:00 -0400 Felix Miata wrote:

David C. Rankin composed on 2022-09-02 23:38 (UTC-0500):

...

SUSE’s aim with its Adaptable Linux Platform is to build a new immutable-base operating system for enhanced application-layer features and container orchestration on newer hardware. The prototype that is expected soon will have x86-64-v3 as a baseline.

...

From what I gather on the factory list, that means processors and motherboards from 2020 on. If you have older hardware -- you're not invited to the party and you are just fsck'ed.

IMO it's more accurate to say v3 means when released next year or after, it might be targeted to hardware about 9-10 years old or newer. I have two v3 from 2014, one from 2012. Intel Sandy Bridge from Q1-2012 I don't have but I think may be v3.

I don't know what processors I have exactly, let alone what 'v' they are. One of the points of linux for me is that it generally works out what you've got and configures itself to run OK, as long as you avoid nvidia and such. If ALP doesn't do that then I don't want it.

On 9/3/22 06:55, Patrick Shanahan wrote:

ollowing script will tell you what your processor level is,

#!/usr/bin/awk -f BEGIN { while (!/flags/) if (getline < "/proc/cpuinfo" != 1) exit 1 if (/lm/&&/cmov/&&/cx8/&&/fpu/&&/fxsr/&&/mmx/&&/syscall/&&/sse2/) level = 1 if (level == 1 &&/cx16/&&/lahf/&&/popcnt/&&/sse4_1/&&/sse4_2/&&/ssse3/) level = 2 if (level == 2 &&/avx/&&/avx2/&&/bmi1/&&/bmi2/&&/f16c/&&/fma/&&/abm/&&/movbe/&&/xsave/) level = 3 if (level == 3 &&/avx512f/&&/avx512bw/&&/avx512cd/&&/avx512dq/&&/avx512vl/) level = 4 if (level > 0) { print "CPU supports x86-64-v" level; exit level + 1 } exit 1 }

How does that work for processors with avx, but no avx2? -- David C. Rankin, J.D.,P.E.

On 2022-09-03 15:32:18 Dave Howorth wrote:

|On Sat, 3 Sep 2022 11:37:14 -0500 | |"David C. Rankin" wrote: |> On 9/3/22 06:55, Patrick Shanahan wrote: |> > ollowing script will tell you what your processor level is, |> > |> > #!/usr/bin/awk -f |> > BEGIN { |> > while (!/flags/) if (getline < "/proc/cpuinfo" != 1) exit 1 |> > if |> > (/lm/&&/cmov/&&/cx8/&&/fpu/&&/fxsr/&&/mmx/&&/syscall/&&/sse2/) |> > level = 1 if (level == 1 |> > &&/cx16/&&/lahf/&&/popcnt/&&/sse4_1/&&/sse4_2/&&/ssse3/) level = 2 |> > if (level == 2 |> > &&/avx/&&/avx2/&&/bmi1/&&/bmi2/&&/f16c/&&/fma/&&/abm/&&/movbe/&&/xsave |> >/) level = 3 if (level == 3 |> > &&/avx512f/&&/avx512bw/&&/avx512cd/&&/avx512dq/&&/avx512vl/) level |> > = 4 if (level > 0) { print "CPU supports x86-64-v" level; exit |> > level + 1 } exit 1 } |> |> How does that work for processors with avx, but no avx2? | |And why should I have to care about any of it?

See David Rankin's post @ 2022-09-02 23:38. Leslie --

On 9/3/22 00:03, Felix Miata wrote:

IMO it's more accurate to say v3 means when released next year or after, it might be targeted to hardware about 9-10 years old or newer. I have two v3 from 2014, one from 2012. Intel Sandy Bridge from Q1-2012 I don't have but I think may be v3.

We will find out. Sandy Bridge is about as new as I go. Kids all have the new fangled Coffee Lake, but that's just not necessary for driving a full server and desktop application (it may be needed to spin containers, the proverbial 1G of dependencies for the Qt6 "Hello World" program). That's the issue with ill-advised v3 baseline -- it has no rational relation to the hardware out there or its capibilities. I still have one server (mail, web (groupware, caldav/carddav serving iPhones, photo gallery), dns, dhcp, ssh, samba, print server, fax server) on a AMD Opteron(tm) Processor 180. Never breaks a sweat. What possible reason is there for saying, sorry, we're just not going to build for that hardware? I guess if you want to cater to corporate only, and are taking subsidies to help drive hardware sales -- it makes sense in that light, but otherwise it just looks like the community is being thrown under the bus. -- David C. Rankin, J.D.,P.E.

Le 03/09/2022 à 16:02, Darryl Gregorash a écrit :

If SUSE were to move to a platform that could run only on hardware available since 2020, it would probably knock itself out of the game as far as the vast majority of commercial clients are concerned.

I highly doubt that is going to happen. Those clients are not going to go to the expense of replacing the vast bulk of their hardware, just so they can stick with SUSE. They would instead move to another distro.

Looks like OpenSUSE Leap users have a promising future behind them. :o) -- Microlinux - Solutions informatiques durables 7, place de l'église - 30730 Montpezat Site : https://www.microlinux.fr Blog : https://blog.microlinux.fr Mail : info@microlinux.fr Tél. : 04 66 63 10 32 Mob. : 06 51 80 12 12

On 2022-09-03 15:31, J Leslie Turriff wrote:

On 2022-09-03 09:02:00 Darryl Gregorash wrote:

...

| |If SUSE were to move to a platform that could run only on hardware |available since 2020, it would probably knock itself out of the game as |far as the vast majority of commercial clients are concerned. | |I highly doubt that is going to happen. Those clients are not going to |go to the expense of replacing the vast bulk of their hardware, just so |they can stick with SUSE. They would instead move to another distro.

SUSE probably wouldn't make that restriction, but OpenSUSE might.

Are you serious? How many openSUSE users do you think are that flush with cash, that they can toss out a perfectly good computer, and buy all new, just because their preferred distro said it was necessary?

On 9/3/22 16:57, J Leslie Turriff wrote:

On 2022-09-03 18:42:44 Darryl Gregorash wrote:

...

|On 2022-09-03 15:31, J Leslie Turriff wrote: |> On 2022-09-03 09:02:00 Darryl Gregorash wrote: |>> |If SUSE were to move to a platform that could run only on hardware |>> |available since 2020, it would probably knock itself out of the game |>> | as far as the vast majority of commercial clients are concerned. |>> | |>> |I highly doubt that is going to happen. Those clients are not going to |>> |go to the expense of replacing the vast bulk of their hardware, just |>> | so they can stick with SUSE. They would instead move to another |>> | distro. |> |> SUSE probably wouldn't make that restriction, but OpenSUSE might. | |Are you serious? How many openSUSE users do you think are that flush |with cash, that they can toss out a perfectly good computer, and buy all |new, just because their preferred distro said it was necessary? Ah, but SUSE (SLED, SLES) are intended for paying customers, while OpenSUSE isn't really.

But still, large well-funded organizations can and do use openSUSE. I've been supporting one since SuSE 5.2.  And trust me, they will not replace dozens of SuperMicro servers on a whim.  And many of those servers are more than eight-years old and still going strong. Regards, Lew

Mathias Homann wrote:

Am Sonntag, 4. September 2022, 02:28:49 CEST schrieb Lew Wolfgang:

...

dozens of SuperMicro servers

HP MicroServer N54 and the likes? I have some of those here too, they're rated as x86-64-v1 :(

We have about 100 servers (80 are Supermicro) downstairs, not one is x86-64-v3 - only my fairly recent Lenovo laptop does x86-64-v3. -- Per Jessen, Zürich (19.8°C)

On Sun, 04 Sep 2022 11:02:01 +0200 Mathias Homann wrote:

Am Sonntag, 4. September 2022, 10:35:53 CEST schrieb Per Jessen:

...

...

HP MicroServer N54 and the likes? I have some of those here too, they're rated as x86-64-v1 :(

We have about 100 servers (80 are Supermicro) downstairs, not one is x86-64-v3 - only my fairly recent Lenovo laptop does x86-64-v3.

My desktop is literally 10 years old. x86-64-v3. My new laptop was bought last year, x86-64-v4.

I don't think anybody is arguing that it is impossible to have an old v3 processor, they're just saying that a lot of people have a lot of non-v3 processors and aren't going to scrap them just to be able to run either SUSE or openSUSE. So the market for both would be substantially reduced if the requirement were brought in.

Am Sonntag, 4. September 2022, 15:17:40 CEST schrieb Predrag Ivanović:

On Sun, 04 Sep 2022 11:28:40 +0100

Dave Howorth wrote:

...

On Sun, 04 Sep 2022 11:02:01 +0200

Mathias Homann wrote:

...

Am Sonntag, 4. September 2022, 10:35:53 CEST schrieb Per Jessen:

...

...

HP MicroServer N54 and the likes? I have some of those here too, they're rated as x86-64-v1 :(

We have about 100 servers (80 are Supermicro) downstairs, not one is x86-64-v3 - only my fairly recent Lenovo laptop does x86-64-v3.

My desktop is literally 10 years old. x86-64-v3. My new laptop was bought last year, x86-64-v4.

I don't think anybody is arguing that it is impossible to have an old v3 processor, they're just saying that a lot of people have a lot of non-v3 processors and aren't going to scrap them just to be able to run either SUSE or openSUSE. So the market for both would be substantially reduced if the requirement were brought in.

This is/was discussed on several meetings, and, IIRC, SUSE ALP will be v3+-only, and there is a possibility that openSUSE variant will be v2+, maybe even v1+, there are no objections about that from SUSE side.

What about tumbleweed? Cheers MH -- Mathias Homann Mathias.Homann@openSUSE.org Jabber (XMPP): lemmy@tuxonline.tech Matrix: @mathias:eregion.de IRC: [Lemmy] on freenode and ircnet (bouncer active) keybase: https://keybase.io/lemmy gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102

On Mon, Sep 5, 2022 at 12:58 PM cagsm wrote:

I am really annoyed, that some years ago, anyone still recall that package?, there used to be a opensuse built-in hardware statistics collection package of some name and kind, I think it came from redhat upstream or something, and there was an own domain name webservers etc associated to it, similar to its project package name or whatever, and linux users in general and opensuse users could participate it it, install and run the script or daemon and submit their stuff to that website, allowing it to collect stats on hardware platforms and such stuff. after a while eventually it was dissolved or abandoned, i think suse aborted the participate before even redhat EOLd it or so. it seems laughable to me and a pita and sad that the whole world and academia relies on measurements, sensory data, statistics and all, and such a project was deleted and everybody jumped ship with no replacement and losing all the value of it and all the efforts all the work and data of the participants.

heck talking to myself, but my brain just resurrected the memory to this package and i found it on the web once again after all those years: it was named smolt whatever https://www.reddit.com/r/linux/comments/gncfx/smolt_you_can_upload_your_hard...

now i read that some management or people in general would need data hard facts statistics and what-not. sigh. one newer project i sometimes submit to these days, is e.g. https://linux-hardware.org/?view=howto

https://lizards.opensuse.org/2008/12/01/smolt-and-opensuse/ https://en.opensuse.org/Smolt it is fun to read the intentions of the smolt project the reasoning the goals et al

On 2022-09-05 16:30, cagsm wrote:

On Mon, Sep 5, 2022 at 12:58 PM cagsm wrote:

...

I am really annoyed, that some years ago, anyone still recall that package?, there used to be a opensuse built-in hardware statistics collection package of some name and kind, I think it came from redhat upstream or something, and there was an own domain name webservers etc associated to it, similar to its project package name or whatever, and linux users in general and opensuse users could participate it it, install and run the script or daemon and submit their stuff to that website, allowing it to collect stats on hardware platforms and such stuff. after a while eventually it was dissolved or abandoned, i think suse aborted the participate before even redhat EOLd it or so. it seems laughable to me and a pita and sad that the whole world and academia relies on measurements, sensory data, statistics and all, and such a project was deleted and everybody jumped ship with no replacement and losing all the value of it and all the efforts all the work and data of the participants.

heck talking to myself, but my brain just resurrected the memory to this package and i found it on the web once again after all those years: it was named smolt whatever

Yes, I remember that one. I have foggy details of this one or another running automatically at boot after install.

https://www.reddit.com/r/linux/comments/gncfx/smolt_you_can_upload_your_hard...

...

now i read that some management or people in general would need data hard facts statistics and what-not. sigh. one newer project i sometimes submit to these days, is e.g. https://linux-hardware.org/?view=howto

https://lizards.opensuse.org/2008/12/01/smolt-and-opensuse/ https://en.opensuse.org/Smolt

it is fun to read the intentions of the smolt project the reasoning the goals et al

The Linux Counter was a different thing. aimed at counting users, not machines. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)

Hallo Patrick Shanahan, op 05-09-2022 om 20:20 schreef je:

...

The Linux Counter was a different thing. aimed at counting users, not machines.

no, it counted both and uptime.

Indeed! https://www.harriebaken.nl/wp-content/uploads/2019/02/Linux-Counter-Harrie-B... ;-) -- Harrie Baken

cagsm composed on 2022-09-04 12:14 (UTC+0200): ...

I just grabbed from the official inxi github place

https://github.com/smxi/inxi via

...

wget -O inxi https://github.com/smxi/inxi/raw/master/inxi

and simply chmod a+x ./inxi

and running it: ./inxi -Cxxxxxx

or similar ...

Man page for inxi explains options and sub options determine categories and amount of detail: Selected options: x - add more detail xx - add more detail than simply x xxx - add even more detail than xx a - maximize details z - filter out sensitive data, such as serial numbers and MAC addresses Selected categories: C - CPU F - Full (most categories) G - graphics S - system M - machine m - memory N - network P - partitions To get "level" requires -Cxx, or -Cxxx or -Ca. For C, there are extra options regarding vulnerabilities available in the man page. -- 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-04 12:41, Felix Miata wrote:

cagsm composed on 2022-09-04 12:14 (UTC+0200): ...

...

I just grabbed from the official inxi github place

...

https://github.com/smxi/inxi via

...

wget -O inxi https://github.com/smxi/inxi/raw/master/inxi

...

and simply chmod a+x ./inxi

...

and running it: ./inxi -Cxxxxxx

...

or similar ...

Man page for inxi explains options and sub options determine categories and amount of detail:

Selected options: x - add more detail xx - add more detail than simply x xxx - add even more detail than xx a - maximize details z - filter out sensitive data, such as serial numbers and MAC addresses

Selected categories: C - CPU F - Full (most categories) G - graphics S - system M - machine m - memory N - network P - partitions

To get "level" requires -Cxx, or -Cxxx or -Ca. For C, there are extra options regarding vulnerabilities available in the man page.

cer@Telcontar:~> inxi -Cxxxxxx CPU: Topology: 6-Core model: AMD Ryzen 5 3600X bits: 64 type: MT MCP arch: Zen 2 L2 cache: 3072 KiB flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm bogomips: 91202 Speed: 2443 MHz min/max: 2200/3800 MHz boost: enabled Core speeds (MHz): 1: 2443 2: 2278 3: 3904 4: 3451 5: 3139 6: 2198 7: 2280 8: 2411 9: 2185 10: 2254 11: 3286 12: 2197 cer@Telcontar:~> So, what's the level? The other awk script says: cer@Telcontar:~> cpulevel CPU supports x86-64-v3 cer@Telcontar:~> On my server machine: cer@Isengard:~> cpulevel CPU supports x86-64-v2 cer@Isengard:~> cer@Isengard:~> inxi -Cxxxxxx CPU: Topology: Quad Core model: Intel Pentium N3710 bits: 64 type: MCP arch: Airmont rev: 4 L2 cache: 1024 KiB flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 12800 Speed: 480 MHz min/max: 480/2560 MHz Core speeds (MHz): 1: 949 2: 657 3: 2130 4: 1968 cer@Isengard:~> -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)

On 04.09.2022 15:39, Mathias Homann wrote:

"that AWK script" labels a HP N54 as "level 1", inxi -Cxx levels the same system as level 2...

Provide full flags line from /proc/cpuinfo

On 04.09.2022 23:08, Mathias Homann wrote:

Am Sonntag, 4. September 2022, 15:01:48 CEST schrieb Andrei Borzenkov:

...

On 04.09.2022 15:39, Mathias Homann wrote:

...

"that AWK script" labels a HP N54 as "level 1", inxi -Cxx levels the same system as level 2...

Provide full flags line from /proc/cpuinfo

flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt nodeid_msr hw_pstate vmmcall npt lbrv svm_lock nrip_save

inxi is wrong.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2022-09-04 a las 11:58 -0400, Felix Miata escribió:

Carlos E. R. composed on 2022-09-04 13:33 (UTC+0200):

...

Felix Miata wrote:

...

...

So, what's the level?

You can't get it from Leap's ancient inxi. level first appeared in current 3.3.21 two weeks ago: # 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 ...

-Cxxx, -Ca, -Fxx, -Fxxx and -Fa also output level.

--vs first appeared in 3.3.17 in June. Prior to then, -I or -V or --version flags were the only way to get it to output its version.

Run sudo inxi -U. Then you will have the current upstream version, but only until Leap's inxi rpm gets next upgrade, after which to stay current you'll need -U again in as little as less than one week. Its version ticks up frequently and irregularly, 15 times in the past 10 months.

Ok. Now both machines say "level: v3". But on the old server machine, the awk script posted here say "CPU supports x86-64-v2" Isengard:~ # cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 76 model name : Intel(R) Pentium(R) CPU N3710 @ 1.60GHz stepping : 4 microcode : 0x411 cpu MHz : 2320.377 cache size : 1024 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology tsc_reliable nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 movbe popcnt tsc_deadline_timer aes rdrand lahf_lm 3dnowprefetch epb pti ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid tsc_adjust smep erms dtherm ida arat md_clear bugs : cpu_meltdown spectre_v1 spectre_v2 mds msbds_only bogomips : 3200.00 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 76 model name : Intel(R) Pentium(R) CPU N3710 @ 1.60GHz stepping : 4 microcode : 0x411 cpu MHz : 2320.199 cache size : 1024 KB physical id : 0 siblings : 4 core id : 1 cpu cores : 4 apicid : 2 initial apicid : 2 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology tsc_reliable nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 movbe popcnt tsc_deadline_timer aes rdrand lahf_lm 3dnowprefetch epb pti ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid tsc_adjust smep erms dtherm ida arat md_clear bugs : cpu_meltdown spectre_v1 spectre_v2 mds msbds_only bogomips : 3200.00 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 2 vendor_id : GenuineIntel cpu family : 6 model : 76 model name : Intel(R) Pentium(R) CPU N3710 @ 1.60GHz stepping : 4 microcode : 0x411 cpu MHz : 2147.800 cache size : 1024 KB physical id : 0 siblings : 4 core id : 2 cpu cores : 4 apicid : 4 initial apicid : 4 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology tsc_reliable nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 movbe popcnt tsc_deadline_timer aes rdrand lahf_lm 3dnowprefetch epb pti ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid tsc_adjust smep erms dtherm ida arat md_clear bugs : cpu_meltdown spectre_v1 spectre_v2 mds msbds_only bogomips : 3200.00 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 3 vendor_id : GenuineIntel cpu family : 6 model : 76 model name : Intel(R) Pentium(R) CPU N3710 @ 1.60GHz stepping : 4 microcode : 0x411 cpu MHz : 1498.741 cache size : 1024 KB physical id : 0 siblings : 4 core id : 3 cpu cores : 4 apicid : 6 initial apicid : 6 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology tsc_reliable nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 movbe popcnt tsc_deadline_timer aes rdrand lahf_lm 3dnowprefetch epb pti ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid tsc_adjust smep erms dtherm ida arat md_clear bugs : cpu_meltdown spectre_v1 spectre_v2 mds msbds_only bogomips : 3200.00 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: Isengard:~ # - -- Cheers, Carlos E. R. (from openSUSE 15.3 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCYxTqoxwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfV6moAmgN3bj/BUMAZFu/jZoAc LpSs/UMaAJsEsbdezUOcx86O8kKcx8Ms6n075A== =F3zx -----END PGP SIGNATURE-----

On 2022-09-04 20:18, Felix Miata wrote:

Carlos E. R. composed on 2022-09-04 20:12 (UTC+0200):

...

Isengard:~ # cat /proc/cpuinfo ... processor : 3 vendor_id : GenuineIntel cpu family : 6 model : 76 model name : Intel(R) Pentium(R) CPU N3710 @ 1.60GHz

lscpu won't repeat the same data for every core.

But Andrei asked for /proc/cpuinfo output. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)

On Mon, Sep 5, 2022 at 6:12 AM Andrei Borzenkov wrote:

So any detection based on flags in /proc/cpuinfo is optimistic guess at most.

so whos gonna come up with a proper detection little tool? if that awk and inxi scripts are bollocks..... any package for opensuse yet? ty.

On Mon, Sep 5, 2022 at 12:54 PM Mathias Homann wrote:

On sufficiently new glibc versions: /lib64/ld-linux-x86-64.so.2 --help|grep x86.*support|head -1|awk '{print $1}' glibc on 15.4 and before is *not* sufficiently new enough for this.

exactl. brand new leap. outdated packagery :/ sweet

On 2022-09-04 05:14:25 cagsm wrote:

|On Sun, Sep 4, 2022 at 10:36 AM Per Jessen wrote: |> We have about 100 servers (80 are Supermicro) downstairs, not one is |> x86-64-v3 - only my fairly recent Lenovo laptop does x86-64-v3. | |i am not very happy with this detection of x86 abi levels of the |various tools and scripts and would like to ask for a really official |and robust way of the opensuse leap official binaries or package to |detect this because: | |this other awk script I found long ago at |<https://unix.stackexchange.com/questions/631217/how-do-i-check-if-my-cpu- |supports-x86-64-v2> | |(stephen kitts awk script, i wonder if its reporting values correctly |though, see below...) | |always (mostly) shows one level lower (older) than the inxi stuff that |I just grabbed from the official inxi github place | |https://github.com/smxi/inxi |via | |> wget -O inxi https://github.com/smxi/inxi/raw/master/inxi | |and simply chmod a+x ./inxi | |and running it: ./inxi -Cxxxxxx | |or similar | |in the end it matters what opensuse project detect as abi levels even |if opensuse detection would be wrong ;) or if other scripts report |funny stuff. I am wondering..... | | |inxi mostly gives me one level newer (higher) than the other scripts i |found so far. now I am wondering how these detections really work |(only looking into /proc/cpuinfo and feature flags there ) or how this |inxi stuff works (perl script just as well), but then there is another |way on newer linux versions and opensuse factory apparently with that |one other libclibraryxxxxx.so or similar and some parameter to is, but |this ofcourse how could it be otherwise, does not work with even the |most current leap 15.4 as it ships ancient stuff :( | |ty

It seems to me that if the ABI level is important to proper interaction of the CPU, that value should be displayed directly in /proc/cpuinfo, as are such items as cpu family, model, and cpuid level. We shouldn't have to rely on kludgy scripts to infer this value. Leslie -- Operating System: Linux Distribution: openSUSE Leap 15.4 x86_64 Desktop Environment: Trinity

From: Mathias Homann Date: Sun, 04 Sep 2022 00:19:35 +0200 Am Samstag, 3. September 2022, 06:38:27 CEST schrieb David C. Rankin:

From what I gather on the factory list, that means processors and motherboards from 2020 on. If you have older hardware -- you're not invited to the party and you are just fsck'ed.

my 10 year old i7-4771 and ASRock board combo identifies as x86-64-v3 with that AWK script that's somewhere in this thread. Interesting. The same script calls my 7-year-old AMD A10-7700K Radeon R7, which sounds fancier to me, an x86-64-v2. I guess AMD has better marketing. ;-} -- Bob Rogers http://www.rgrjr.com/

David C. Rankin wrote:

SUSE’s aim with its Adaptable Linux Platform is to build a new immutable-base operating system for enhanced application-layer features and container orchestration on newer hardware. The prototype that is expected soon will have x86-64-v3 as a baseline. </quote> From what I gather on the factory list, that means processors and motherboards from 2020 on. If you have older hardware -- you're not invited to the party and you are just fsck'ed.

x86-64-v3 means CPUs from Intel Haswell and newer, or AMD Excavator and newer. That means motherboards from 2013 and newer. In 2024, when SUSE ALP supposedly will be released, supported SUSE ALP systems will be 11 years old and newer. How much 11-year system costs? Right now new x86-64-v3 compatible AMD AM4 hardware kit with motherboard (A320) + APU (A6/A8 with builtin GCN3 video) + 4-8 GiB of DDR4 RAM can cost about $100. Please describe features that SUSE ALP wants which require "processors and motherboards from 2020 on". P.S.: Intel Sandy Bridge is not compatible with x86-64-v3, only Haswell and newer.

On 9/6/22 16:29, Felix Miata wrote:

Nikolai Nikolaevskii composed on 2022-09-06 20:41 (UTC):

...

Intel Sandy Bridge is not compatible with x86-64-v3, only Haswell and newer.

Sandy Bridge is 32nm 201101. Haswell is 22nm 201306. What is Ivy Bridge 22nm in between those two, 201204?

~80% of my working 64bit CPUs are older than Haswell, all except one of my AMD CPU motherboards.

Unconditionally replacing hardware every 10-11 years is very un-green, rewarding of waste and hardware producers at the expense of users and the environment.

We'll all be running Debian before the v3 debacle is over. At least Arch is creating a separate branch for v3 optimization (which add on average 10% boost in performance -- for packages that DON'T ALREADY OPTIMIZE) All this "chase the latest fad" is the result of gcc 11 implementing optimizations for v3 microarchetecture. With 99% of installs running at less than 100% CPU utilization - the v3 optimization changes will never be noticed unless you are running one of the dedicated apps doing, e.g. huge data computations or video rendering, etc.. that get the 10% boost from the optimizations. Start top and if you don't see (nCores * 100) for %CPU use (or 100% on each core if you list each core separately in the summary information) -- you likely would never notice the difference anyway. Seems like a moronic approach to take as a hard constraint distribution wide. A far better approach is the 2nd branch approach, which at least for Arch, adds no more than 37G to their total storage requirements. Another issue Arch ran into is developers not being able to debug v3 issues in the packages they maintain -- due to not having v3 CPUs themselves -- but I'm sure openSUSE will ensure all the computers used in it's build-farm have v3 CPUs t begin with. Otherwise, the cart seems to be placed squarely in front of the horse. Funny what issues crop up when 1/2 baked ideas gain traction. -- David C. Rankin, J.D.,P.E.

Not sure if replacing hardware every 10-11 years is un-green. Seems like this topic would open up a whole discussion about energy conservation. Older hardware with software optimization that is using (example) 4x the energy for what newer hardware could also be viewed as un-green as well. Good to see KDE is already discussing these topics (https://youtu.be/VzLi-_PI02M?t=507) and it's a conversation that will likely increase with the energy crisis and power demands around the globe. It's good to be having these conversations now. v/r Doug