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? -- Roger Oberholtzer
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) -- David C. Rankin, J.D.,P.E.
On Fri, Sep 2, 2022 at 8:46 AM David C. Rankin <drankinatty@suddenlinkmail.com> 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
On Fri, 02 Sep 2022 08:57:55 +0200 Roger Oberholtzer wrote: <snip>
Knowing the current plans would be beneficial.
FWIW, there are fairly regular meetings at https://meet.opensuse.org/meeting, every Tuesday at 14:30 UTC (ALP(SLE-next gen) work group), and Thursdays at 19:00 UTC (Community etc). Lubos Kocman(Leap Release Manager) is a regular at both, so drop by and ask :) 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. Pedja
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
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 -- http://dodin.org http://valeriedodin.com
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 Fri, Sep 2, 2022 at 9:46 AM David C. Rankin <drankinatty@suddenlinkmail.com> 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
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.
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)
-- David C. Rankin, J.D.,P.E.
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 2022-09-02 13:59, David C. Rankin wrote:
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?
What does "containerized version" even mean?
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 15:51:53 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..
Yuk. Leslie -- Operating System: Linux Distribution: openSUSE Leap 15.4 x86_64 Desktop Environment: Trinity
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 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) gumb
On Fri, Sep 2, 2022 at 11:08 AM gumb <gumb@linuxmail.org> 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
Le 02/09/2022 à 08:46, David C. Rankin a écrit :
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)
We've moved all our desktop clients from Leap to Tumbleweed, but we are having a few issues with it. We'll probably move all client machines to Debian stable and KDE in the near future. Curiously enough, the guy working on Gecko Linux (custom desktop based on OpenSUSE) is also currently moving to Debian with Spiral Linux. Developers seem to love moving targets. Admins not so much. 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-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/7KXDUYD3UKUSG3XDN6QEH7DP3UIMJK4K/> From: Axel Braun <docb@opensuse.org> 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 13:11:36 +0200 "Carlos E. R." <robin.listas@telefonica.net> 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 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.
On Fri, 2 Sep 2022 12:38:43 +0100 Dave Howorth <dave@howorth.org.uk> 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:50:05 +0200 Michael Vetter <mvetter@suse.com> wrote:
On Fri, 2 Sep 2022 12:38:43 +0100 Dave Howorth <dave@howorth.org.uk> 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.
On Fri, 2 Sep 2022 13:11:03 +0100 Dave Howorth <dave@howorth.org.uk> wrote:
On Fri, 2 Sep 2022 13:50:05 +0200 Michael Vetter <mvetter@suse.com> wrote:
On Fri, 2 Sep 2022 12:38:43 +0100 Dave Howorth <dave@howorth.org.uk> 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 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. 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. 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. 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) 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. -- David C. Rankin, J.D.,P.E.
On Fri, 2 Sep 2022 16:11:42 -0500 "David C. Rankin" <drankinatty@suddenlinkmail.com> 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!
On 9/2/22 14:11, David C. Rankin wrote:
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.
Rolling releases won't work for us either. But if Leap's successor won't support our use cases, what are the alternatives? Our use case includes basic HPC with petabyte-scale RAID arrays. In-house Python and C code is used for data reduction and visualization. In the near future we may start developing GPU code with NVIDIA hardware. We also need all of the standard Linux command-line programs. Work is also done with the USB ports and RS232 interfaces. Our hosts are also required to be security scanned with Nessus. I know that this was an issue with Tumbleweed, Nessus didn't know what to do with it. If Micro openSUSE ALP can't provide this functionality, what are the alternatives? Ubuntu was too difficult for us to live with. Regards, Lew
Hi, On 9/2/22 07:38, Dave Howorth wrote:
On Fri, 2 Sep 2022 13:11:36 +0200 "Carlos E. R." <robin.listas@telefonica.net> 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 08:11:01 -0400 Robert Schweikert <rjschwei@suse.com> wrote: [snip]
Makes me wonder if other distributions have a 2 year roadmap? I've never looked, so I really do not know.
Well a lot of distros are based off debian in one way or another and it has a fairly predictable roadmap for well over two years as far as I can see. Predictable in that I can see approximately when new releases will arrive and what support they will get for how many years.
On Fri, 2 Sep 2022 12:38:43 +0100 Dave Howorth <dave@howorth.org.uk> wrote:
On Fri, 2 Sep 2022 13:11:36 +0200 "Carlos E. R." <robin.listas@telefonica.net> 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 2022-09-02 16:13:55 Dave Howorth wrote:
|On Fri, 2 Sep 2022 12:38:43 +0100 | |Dave Howorth <dave@howorth.org.uk> wrote: |> On Fri, 2 Sep 2022 13:11:36 +0200 |> |> "Carlos E. R." <robin.listas@telefonica.net> 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?
One supposes that some of the maintainers haven't heard about update-alternatives? Leslie -- Operating System: Linux Distribution: openSUSE Leap 15.4 x86_64 Desktop Environment: Trinity
On 9/2/22 16:13, Dave Howorth wrote:
On Fri, 2 Sep 2022 12:38:43 +0100 Dave Howorth <dave@howorth.org.uk> wrote:
On Fri, 2 Sep 2022 13:11:36 +0200 "Carlos E. R." <robin.listas@telefonica.net> 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.
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. -- 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, 3 Sep 2022 01:03:00 -0400 Felix Miata <mrmazda@earthlink.net> 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.
* Dave Howorth <dave@howorth.org.uk> [09-03-22 06:09]:
On Sat, 3 Sep 2022 01:03:00 -0400 Felix Miata <mrmazda@earthlink.net> 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.
following 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 } -- (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 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 Sat, 3 Sep 2022 11:37:14 -0500 "David C. Rankin" <drankinatty@suddenlinkmail.com> 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?
On 2022-09-03 15:32:18 Dave Howorth wrote:
|On Sat, 3 Sep 2022 11:37:14 -0500 | |"David C. Rankin" <drankinatty@suddenlinkmail.com> 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 2022-09-03 15:32:18 Dave Howorth wrote:
|On Sat, 3 Sep 2022 11:37:14 -0500 | |"David C. Rankin" <drankinatty@suddenlinkmail.com> 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 -- Operating System: Linux Distribution: openSUSE Leap 15.4 x86_64 Desktop Environment: Trinity
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.
On 2022-09-02 22:38, David C. Rankin wrote:
On 9/2/22 16:13, Dave Howorth wrote:
On Fri, 2 Sep 2022 12:38:43 +0100 Dave Howorth <dave@howorth.org.uk> wrote:
On Fri, 2 Sep 2022 13:11:36 +0200 "Carlos E. R." <robin.listas@telefonica.net> 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.
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.
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 09:02:00 Darryl Gregorash wrote:
|On 2022-09-02 22:38, David C. Rankin wrote: |> On 9/2/22 16:13, Dave Howorth wrote: |>> On Fri, 2 Sep 2022 12:38:43 +0100 |>> |>> Dave Howorth <dave@howorth.org.uk> wrote: |>>> On Fri, 2 Sep 2022 13:11:36 +0200 |>>> |>>> "Carlos E. R." <robin.listas@telefonica.net> 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. | |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. Leslie -- Operating System: Linux Distribution: openSUSE Leap 15.4 x86_64 Desktop Environment: Trinity
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 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. Leslie -- Operating System: Linux Distribution: openSUSE Leap 15.4 x86_64 Desktop Environment: Trinity
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
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 :( -- 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
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)
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. -- 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 Sun, 04 Sep 2022 11:02:01 +0200 Mathias Homann <Mathias.Homann@opensuse.org> 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.
On Sun, 04 Sep 2022 11:28:40 +0100 Dave Howorth wrote:
On Sun, 04 Sep 2022 11:02:01 +0200 Mathias Homann <Mathias.Homann@openSUSE.org> 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. But, to make that decision, Leap/openALP release management team requires data/numbers to back it up (which CPU level to go for and/or is it worth the time/resources etc.), so there will be a survey about that soon-ish, which I recommend people interested/planning/considering sticking with what comes after Leap be a part of. If you can't make it to meetings, notes from them are available at https://etherpad.opensuse.org/p/weeklymeeting. BTW, 'openALP' I use is a placeholder, the actual name for Leap-next-gen isn't decided yet, AFAIK. Pedja
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 <Mathias.Homann@openSUSE.org> 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 Sun, Sep 4, 2022 at 3:19 PM Predrag Ivanović <predivan@mts.rs> wrote:
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. But, to make that decision, Leap/openALP release management team requires data/numbers to back it up (which CPU level to go for and/or is it worth the time/resources etc.), so there will be a survey about that soon-ish, which I recommend people interested/planning/considering sticking with what comes after Leap be a part of.
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. now i read that some management or people in general would need data hard facts statistics and whatnot. sigh. one newer project i sometimes submit to these days, is e.g. <https://linux-hardware.org/?view=howto> but apparently not even this is a default or built into opensuse these days or even available in an easy way for the opensuse user :(
On Mon, Sep 5, 2022 at 12:58 PM cagsm <cumandgets0mem00f@gmail.com> 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_hardware_information_to/>
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
* cagsm <cumandgets0mem00f@gmail.com> [09-05-22 10:32]:
On Mon, Sep 5, 2022 at 12:58 PM cagsm <cumandgets0mem00f@gmail.com> 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_hardware_information_to/>
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
https://en.wikipedia.org/wiki/Linux_Counter#:~:text=The%20Linux%20Counter%20.... -- (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-05 16:30, cagsm wrote:
On Mon, Sep 5, 2022 at 12:58 PM cagsm <cumandgets0mem00f@gmail.com> 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_hardware_information_to/>
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)
* Carlos E. R. <robin.listas@telefonica.net> [09-05-22 13:54]:
On 2022-09-05 16:30, cagsm wrote:
On Mon, Sep 5, 2022 at 12:58 PM cagsm <cumandgets0mem00f@gmail.com> 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_hardware_information_to/>
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.
no, it counted both and uptime. -- (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
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
On Sun, Sep 4, 2022 at 10:36 AM Per Jessen <per@computer.org> 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
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
just who is programming proper stuff and doing the detection or interpretation of cpu flags properly? my results e.g. ----------- ./inxi -Cxxxx CPU: Info: quad core model: Intel Core2 Quad Q9xxx bits: 64 type: MCP smt: <unsupported> arch: Penryn level: v2 rev: A cache: L1: 256 KiB L2: 12 MiB Speed (MHz): avg: 1995 min/max: 2003/3003 cores: 1: 1995 2: 1995 3: 1995 4: 1995 bogomips: 23940 Flags: ht lm nx pae sse sse2 sse3 sse4_1 ssse3 vmx ----------- <https://unix.stackexchange.com/posts/631226/revisions> ./x86abilevelinfo CPU supports x86-64-v1 less x86abilevelinfo #!/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 }
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)
Am Sonntag, 4. September 2022, 13:33:32 CEST schrieb Carlos E. R.:
cagsm composed on 2022-09-04 12:14 (UTC+0200):
I just grabbed from the official inxi github place
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 level is what you see when you do that with the most recent inxi, i.e. 3.3.21. For example: lemmy@kumiko:~> ssh root@mio inxi -Cxx CPU: Info: quad core model: 11th Gen Intel Core i7-1185G7 bits: 64 type: MT MCP arch: Tiger Lake level: v4 rev: 1 cache: L1: 320 KiB L2: 5 MiB L3: 12 MiB Speed (MHz): avg: 3000 min/max: 400/4800 cores: 1: 3000 2: 3000 3: 3000 4: 3000 5: 3000 6: 3000 7: 3000 8: 3000 bogomips: 47923 Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx lemmy@kumiko:~> As you can see: level 4. Now here's the interesting bit: "that AWK script" labels a HP N54 as "level 1", inxi -Cxx levels the same system as level 2... I foresee mayhem. Cheers Mathias -- 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
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 -- 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 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.
Carlos E. R. composed on 2022-09-04 13:33 (UTC+0200):
Felix Miata wrote:
Selected options: x - add more detail xx - add more detail than simply x xxx - add even more detail than xx
^^^ More than three x goto /dev/null.
a - maximize details ... 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
-Cxxxxxx == -Cxxx Any beyond three "x" are ignored by inxi, yet xxx yields not the maximum available response.
CPU: Topology: 6-Core model: AMD Ryzen 5 3600X bits: 64 type: MT MCP arch: Zen 2 L2 cache: 3072 KiB ...
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. -- 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
-----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-----
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. -- 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 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 04.09.2022 21:12, Carlos E. R. wrote:
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
...
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
inxi is wrong, this is *NOT* x86_64-v3. Both "this awk script" and just check flags in /proc/cpuinfo. But inxi does it fundamentally wrong for two reasons 1. It checks for any CPU flag on corresponding level instead of checking for *all* of them. 2. It starts with the highest level and assumes that if features in this level are present CPU is on this level. This is wrong, every level must also include all "lower" features. Combined with 1 this results in false detection. awk script starts with the lowest level and checks that all features on this level are present. Note that detection of v3 and above is unreliable in any case because 1. OSXSAVE flag is not exposed in /proc/cpuinfo at all (inxi checks for this non-existent flag but as we have seen it ignores lack of it, awk script checks for XSAVE which is strictly speaking wrong) 2. Not only XSAVE must be enabled (OSXSAVE), it must also support saving/restoring of processor state for features on this level. This information is not exposed either, it is printed by kernel on startup x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' So any detection based on flags in /proc/cpuinfo is optimistic guess at most. "Official" definition of levels is in https://gitlab.com/x86-psABIs/x86-64-ABI/-/blob/master/x86-64-ABI/low-level-...
On Mon, Sep 5, 2022 at 6:12 AM Andrei Borzenkov <arvidjaar@gmail.com> 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.
Am Montag, 5. September 2022, 10:10:15 CEST schrieb cagsm:
On Mon, Sep 5, 2022 at 6:12 AM Andrei Borzenkov <arvidjaar@gmail.com> 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 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. 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 Mon, Sep 5, 2022 at 12:54 PM Mathias Homann <Mathias.Homann@opensuse.org> 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 04.09.2022 13:14, cagsm wrote:
On Sun, Sep 4, 2022 at 10:36 AM Per Jessen <per@computer.org> 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
Post full flags line from your /proc/cpuinfo on the system where results are different.
<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
On 2022-09-04 05:14:25 cagsm wrote:
|On Sun, Sep 4, 2022 at 10:36 AM Per Jessen <per@computer.org> 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
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. -- 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
From: Mathias Homann <Mathias.Homann@opensuse.org> 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/
Am Sonntag, 4. September 2022, 00:28:43 CEST schrieb Bob Rogers:
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. ;-}
I also have several HP MicroServer with an AMD Turion 2 - "the script" calls them X86-64-v1. -- 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
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.
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. -- 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 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.
exactly. word. thanks. i strongly dislike ditching hardware. we are here talking open source software after all. this all should be much more flexible and tailored to the hardware a user has access to. instead of inventing and introducing artificial boundaries and slots people need to fit into :( please do stop the forcing of v2 or v3 or whatever. stick to x64 in general and offer optimised select packages or subpackages where it would really make sense. ty
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
On 9/2/22 06:11, Carlos E. R. wrote:
Looks very grim.
Some kind of thing with containers on top. No longer Linux :-/
Well, You got to admire the business model. Request 20 years of support, time, toil, effort, input, ideas and bug-reports to perfect a distro, build and QA systems and then kill off the traditional open-source offering in light of the rolling release. All boils down to $$ -- so a very few at the top can put more in their pockets and put out forward looking statements to buoy the next quarters estimate. I wouldn't have a great deal of heartache over it if the traditional set of repos and packages were brought along, but if you follow the factory list, those are getting axed and swatted like flies. The idea of a micro Leap which is nothing but a partial Linux providing the ability to run apps in containers, like a cloud service, is a non-starter. That may sell to confused corporate IT that are chasing the latest fad, but goes over like a lead balloon for traditional Linux users. I hope I'm wrong again, but I strongly suspect this list will be a shadow of what it is now (which is a shadow of what it was 10 years ago). The old auditorium physics class where the professor says "look to your left, and look to your right, one of those sitting beside you won't be here when the semester ends..." And I don't blame the devs here either. They take their marching orders from on-high. Do things you know will kill the disto you've nourished for a better part of your career -- or hit the door. That's the uncomfortable coat of corporate employment that has caused a great number of men and women to compromise their profession integrity over the years. It's just become a damn pandemic over the past 30 years... -- David C. Rankin, J.D.,P.E.
participants (23)
-
Andrei Borzenkov -
Bob Rogers -
cagsm -
Carlos E. R. -
Darryl Gregorash -
Dave Howorth -
David C. Rankin -
doug demaio -
Felix Miata -
gumb -
Harrie Baken -
J Leslie Turriff -
jdd＠dodin.org -
Lew Wolfgang -
Mathias Homann -
Michael Vetter -
Nicolas Kovacs -
Nikolai Nikolaevskii -
Patrick Shanahan -
Per Jessen -
Predrag Ivanović -
Robert Schweikert -
Roger Oberholtzer