Closing the Leap Gap (2021)
suse.com
suse.com
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
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://lists.fedoraproject.org/archives/list/devel@lists.fe...
https://lists.fedoraproject.org/archives/list/devel@lists.fe...
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 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.