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.
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.
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.
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.
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.
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.
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.
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.