Re:OpenSUSE – Closing the Leap Gap (2021)
by krylon on Friday June 23, 2023 @09:23AM
(#36446496)
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.
Re:OpenSUSE – Closing the Leap Gap (2021)
by krylon on Friday June 23, 2023 @05:08AM
(#36444487)
I really like OpenSUSE. I run Leap on one laptop and Tumbleweed on another as well as my desktop. The Leap system I installed at 42.1 and have since upgraded all the way to 15.4 without anything breaking or the need to reinstall from scratch. I don't do very much with that machine, to be fair, and I don't have a very large number of packages installed on it, but with that in mind, it has been very stable over the years and not given me any trouble.
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.
Re:OpenSUSE – Closing the Leap Gap (2021)
by stryan on Friday June 23, 2023 @10:07AM
(#36447002)
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.
Re:OpenSUSE – Closing the Leap Gap (2021)
by creatonez on Friday June 23, 2023 @05:58AM
(#36444796)
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.
Re:OpenSUSE – Closing the Leap Gap (2021)
by kwanbix on Friday June 23, 2023 @08:00AM
(#36445651)
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?
Re:OpenSUSE – Closing the Leap Gap (2021)
by n3storm on Friday June 23, 2023 @08:56AM
(#36446198)
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.
Re:OpenSUSE – Closing the Leap Gap (2021)
by arp242 on Friday June 23, 2023 @09:08AM
(#36446330)
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 (but not always) works.
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.
Re:OpenSUSE – Closing the Leap Gap (2021)
by kjs3 on Friday June 23, 2023 @09:33AM
(#36446630)
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.
Re:OpenSUSE – Closing the Leap Gap (2021)
by kjs3 on Friday June 23, 2023 @02:32PM
(#36450585)
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.
[0]https://en.opensuse.org/Release_announcement_15.5
[0]: https://en.opensuse.org/Release_announcement_15.5
[1]: https://en.opensuse.org/Portal:15.5
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.
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
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.
https://www.youtube.com/watch?v=nLdexZlVkAY
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.
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-... )
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 (but not always) works.
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.