Closing the Leap Gap (2021)(suse.com)
suse.com
Closing the Leap Gap (2021)
https://www.suse.com/c/closing-the-leap-gap-src/
24 comments
Same here: Leap 42 -> 15.4 . Never had any upgrade issues. Will move to 15.5 imminently.
However 15.6 will be the last release of Leap as we know it.
>openSUSE Leap 15.6 Now Planned To Provide More Time For ALP
https://www.phoronix.com/news/openSUSE-Leap-15.6-Plan
However 15.6 will be the last release of Leap as we know it.
>openSUSE Leap 15.6 Now Planned To Provide More Time For ALP
https://www.phoronix.com/news/openSUSE-Leap-15.6-Plan
A real shame about the timing too. I understand the general reasoning behind it (it sounds like SUSE internally is moving more towards the container/MicroOS focus) but making such destabilizing changes right when people are really looking for RHEL/CentOS alternatives feels like such a missed opportunity.
I tried tumbleweed after hearing much about it being stable.
Turned out, the swaywm package was broken, and I saw a post from someone that it had broken several times in the past few months.
I know it is not exactly a "common" package, but Manjaro has been far more stable for me than that experience was, even on lesser-used packages.
Turned out, the swaywm package was broken, and I saw a post from someone that it had broken several times in the past few months.
I know it is not exactly a "common" package, but Manjaro has been far more stable for me than that experience was, even on lesser-used packages.
I like it. Red hat seem to be trying to squeeze out their non paying consumers while Suse seem to be embracing their community.
Related discussion: OpenSUSE Leap 15.3 (2021) https://news.ycombinator.com/item?id=27369344
For those who do not know, Leap has a yearly release schedule. The most recent release is 15.4 with 15.5 scheduled for early July, i.e. ~2 weeks from now.
Close, but 15.5 actually came out about a week[0] ago :). I've already updated most of my Leap boxes to it, smooth as silk.
[0]https://en.opensuse.org/Release_announcement_15.5
[0]https://en.opensuse.org/Release_announcement_15.5
How did I miss that?! I was sure it was July 6... Thank you very much, I'll get right on it! :-)
openSUSE Leap 15.5 was released on June 7 (6 days ago at time of comment)[0][1].
[0]: https://en.opensuse.org/Release_announcement_15.5
[1]: https://en.opensuse.org/Portal:15.5
[0]: https://en.opensuse.org/Release_announcement_15.5
[1]: https://en.opensuse.org/Portal:15.5
Thank you! I'll get to it right away. :)
Interesting that both Red Hat and SUSE ended up with quite similar processes now with Centos Stream+EPEL vs. RHEL and openSUSE Leap vs. SLE.
https://lists.fedoraproject.org/archives/list/[email protected]...
https://lists.fedoraproject.org/archives/list/[email protected]...
Both have opened up their processes by allowing community contributions into their enterprise distribution packages.
https://lists.fedoraproject.org/archives/list/[email protected]...
https://lists.fedoraproject.org/archives/list/[email protected]...
Both have opened up their processes by allowing community contributions into their enterprise distribution packages.
There are important differences.
CentOS Stream is a continuously integrated 'midstream' between Fedora and Red Hat. Red Hat is developed from it to provide subscribers with a stable distribution, but there are still parts that take place in private even though they've introduced a midstream that is much more helpful for accepting contributions.
OpenSUSE Leap and SLE always stick to the same schedule and share the same source code. Because they are developed together, the process for stabilizing it, putting out security errata and metadata, and ensuring compatibility -- is all in the public eye (aside from sensitive matters). The Factory and Build Service is where all the branched versions of packages are kept, and they have a policy of aggressively upstreaming.
SLE does have a very close equivalent to EPEL called Package Hub, which supplements the enterprise SLE with community-provided packages. (https://www.suse.com/c/how-suse-builds-its-enterprise-linux-... )
CentOS Stream is a continuously integrated 'midstream' between Fedora and Red Hat. Red Hat is developed from it to provide subscribers with a stable distribution, but there are still parts that take place in private even though they've introduced a midstream that is much more helpful for accepting contributions.
OpenSUSE Leap and SLE always stick to the same schedule and share the same source code. Because they are developed together, the process for stabilizing it, putting out security errata and metadata, and ensuring compatibility -- is all in the public eye (aside from sensitive matters). The Factory and Build Service is where all the branched versions of packages are kept, and they have a policy of aggressively upstreaming.
SLE does have a very close equivalent to EPEL called Package Hub, which supplements the enterprise SLE with community-provided packages. (https://www.suse.com/c/how-suse-builds-its-enterprise-linux-... )
Suse has become my go-to distro for desktop after the Ubuntu push for snaps.
Me too. It's been generally painless once remembered the differences (e.g. zypper v apt). I almost went to Alma because $DAYJOB is an RPM shop, and considering recent events I may have dodged a bullet.
Yep, Suse ticks many boxes. I don't know why it isn't more popular. I've installed it in desktop and laptop without issues.
I want to say at one time multimedia was a little wonky on SuSE. Stuff like getting my OTA TV cards and some of the HTPC apps required an excessive amount of googling for rando repositories that inevitably ran into a broken dependency at some point down the road. That's about all I can remember going badly over the years. Hopefully that's no longer an issue.
I am not a Linux expert, but I wonder why binary compatibility is not something that is a given? I mean, I can use a binary from Win95 in Win11 or WinServer. I know Windows is coming from the same company, but I am still confused. Anyone can explain?
The binary compatibility exists, it's just that the ecosystems have too many differences. e.g. distro A may ship libfoo.so.1.5.3 and distro B libfoo.so.1.3.2 and distro C ships libfoo.so.2.0.0
Other than that you can run a binary for distro X on distro Y without any problems, and "Linux binaries" from the 90s should also still work as such today (as in, the kernel will run them). I frequently run binaries from Debian packages in spite of not using Debian or anything derived from it and that usually works without any tinkering, and when it doesn't you can usually make it work by also fetching a library or two from Debian.
This is also a problem on Windows, because your Windows 95 binary may also not work because of issues like this, depending on exactly how it's compiled, what it does, etc.
Static linking solves many of these issues, but also has its own set of downsides, and it's an old discussion. In general, I'm in favour of this though. Some people are vehemently opposed to it with an aggressive passion which means that in practice support for it isn't that great.
Other than that you can run a binary for distro X on distro Y without any problems, and "Linux binaries" from the 90s should also still work as such today (as in, the kernel will run them). I frequently run binaries from Debian packages in spite of not using Debian or anything derived from it and that usually works without any tinkering, and when it doesn't you can usually make it work by also fetching a library or two from Debian.
This is also a problem on Windows, because your Windows 95 binary may also not work because of issues like this, depending on exactly how it's compiled, what it does, etc.
Static linking solves many of these issues, but also has its own set of downsides, and it's an old discussion. In general, I'm in favour of this though. Some people are vehemently opposed to it with an aggressive passion which means that in practice support for it isn't that great.
Cause in FLOSS we can compile from source whereas in Windows Closed world you are given permission to use a binary you cannot recompile to any other target or fix or port or optimize or remove dependencies.
Now they just have to close the pronunciation gap :P
How do you say SUSE? - SUSE
https://www.youtube.com/watch?v=nLdexZlVkAY
https://www.youtube.com/watch?v=nLdexZlVkAY
Haha I forgot about that glorious video. The success of Among Us since then probably hasn't helped I would imagine.
It's quite funny he's saying it wrong. Su-seh, not su-sah.
I am not sure if I benefit in any way from Leap and SLE having a shared code base, but I see no downside either. The version number of the kernel is a bit dated, but AFAIK, with enterprise distros that doesn't mean as much as it would otherwise. I have not noticed any features missing I wanted to have/use, let's put it that way.