SUSE Liberty Linux: secure your Linux future without fear of vendor lock-in.
suse.com
suse.com
Interesting play - basically they will offer generic enterprise-grade Linux support, with a not-so-veiled view to slowly replace existing installations (typically RHEL or CentOS, both explicitly namechecked) with SuSE, leveraging "SuSE Manager".
It's clearly a reaction to the civil war in the RedHat world.
The specific SKUs and details change from time to time, but it’s not really a new thing. As a trailing competitor, it’s a reasonable thing to do.
Ages ago at a large managed hosting company we had 10s of 10000s of RHEL licenses but we also had a lot of people using CentOS for various reasons. Long story short, since CentOS only supported the current point release at the time we had a lot of boxes out there that needed critical patches.
SUSE provided us with CVE fixes for any CentOS release we wanted to support and we were able to distribute them via our internal RHN system to CentOS machines.
It made the auditors happy.
The auditors being happy is important, but part of what people pay for with RHEL is liability, and I can't imagine you get that with third party support.
It looks like they finished fixing it last week and it looks like it was only a high. When I first ran into it in audit reports python said it wasn't a defect in python, just how it was used, but they would change it in 3.11.4 but no official backports. The bugzilla issue for 7 and 8 said they couldn't fix it without breaking things, so they wouldn't. It seems they found a way. https://access.redhat.com/security/cve/cve-2023-24329
The date of the announcement is January 2022 so it can't be that.
From a practical perspective: I wouldn't use them. Their acquisition of Rancher was/is terrible. I literally couldn't give them my money without one of those stupid sales calls. Their website doesn't even have a working contact form; I had to go to their Slack to get some random engineer's attention. I'm told by colleagues that they ignore your (paid) support tickets. I have worked for enough pain-in-the-ass enterprises that I will avoid them at all costs.
Rancher has been great for me with around 200 clusters. They don’t support temporary creds for IAM stuff, so I have to provision EKS clusters on my own.
We pay for paid support and have very little problems getting them on the phone, but it is generally a consulting firm that ends up helping.
Yeah... No need to fear of vendor lock-in huh?
SUSE may be a viable alternative depending on the workload requirements and cost. RHEL's push could be Red Hat's loss.
“The more you tighten your grip, the more systems will slip through your fingers.”
* openSUSE Factory is comparable to Fedora Rawhide (upstream "development" rolling release);
* openSUSE Tumbleweed is comparable to CentOS Stream (upstream "stable" rolling release);
* openSUSE Leap is comparable to SLE and RHEL (stable conventional point releases).
CentOS Stream maintains various API and ABI stability guarantees whereas openSUSE Tumbleweed just upgrades you to the latest version regardless, once it has been tested in Factory a bit.
And only one half of Leap is comparable to SLE (because it literally is SLE), the other half is rebuilt from Factory; it's like RHEL + everything that doesn't exist in RHEL from Fedora.
I think it's good that everybody is trying slightly different approaches, keeps things more interesting.
(ex-SUSE here)
But SuSE Linux was my first Linux distro, an for the past couple of years[0], I've been a happy openSUSE user, so I'm not that cynical.
[0] I still have the box with the CDs and manuals sitting on my bookshelf. :-)
EDIT: Forgot a word.
Tumbleweed occasionally breaks something, but but it uses snapper to create a snapshot before each update, so if there's a problem, I boot into the most recent stable snapshot and wait for a couple of days before I update again.
Leap is very stable in my experience, while also offering relatively up-to-date packages.
The main problem is that out of the box, support for multimedia is not very good, but there is community-run repository with everything I need, i.e. video codecs and such.
If you have a spare computer, I suggest just installing it on that and giving it a try. Otherwise, a virtual machine. It's a lot more heavyweight than Slackware, obviously, and if you dislike systemd, you might not like it very much. But I don't know your preferences and requirements are, so the best I can say is to give it a try and decide for yourself.
If you are not looking for a fine tunning your system and expects stable (yet bleeding edge) base, which just works, I can recommend it.
The biggest thing is that the model pushes one to embrace usage of a distrobox/flatpak.
Would you happen to know if there are any major differences between distrobox and toolbox? Does distrobox also support running graphical apps with hardware acceleration and CUDA with the official Nvidia drivers? That's pretty much my biggest concern.
It’s almost identical in capability, but with MUCH less pre-installed package layered over it (IE: it comes with the Firefox flatpak pre-installed).
I enjoy that it’s a rolling release as well personally
In the last months we gained a few more RHEL servers, which I needed to provide updates for. Our servers don't have internet connection so some sort of mirror server is required. For SUSE we use their free-of-cost RMT (and the older SMT) mirror services.
For RHEL something like this doesn't seem to exist or looks a little kludgy. So I bought some licenses for SLL: * there where still some "repo errors" when changing from RHEL to SLL on a existing server * I opened a support ticket, there was no finger pointing to RedHat and one or two weeks later the issue was resolved :)
I would say it's at least worth a try.
Which software?
ANSYS fluid dynamics simulator is another. All the advanced planes, future engines have been simulated with it.
CATIA and NX are advanced and very expensive CAD software (the basic licensing packages for a medium grade company can easily near a million and often exceed). Both runs only on SLES or RHEL.
Many large businesses use on-prem SAP deployments which runs only on SLES.
Debian alien worked the last time I had to install some janky rpm-only commercial software.
Technically the programs may or may not work. Those programs are large and even if you have access to the source code, they can be very tricky to understand. Making all of their parts and their extensively used C++ plugin systems work in a foreign distro is probably harder than reverse engineering some hardware. They are not "janky commercial software". People can and do produce cars, planes, UAVs, latest supercomputers and ICs, satellites and even nuclear warheads with them.
Linux userspace libraries don't provide stability or featureset guarantees and distros patch them and worsen the compatibility. Enterprise distros guarantee them and take responsibility for that. In addition the commercial software developers and their customers get premium tier support often connecting you to the developers who curated the distro. You cannot expect community to provide any of that, especially after many years of tradition of almost intentional breaking.
On a practical note, I've dealt with $$$ software that only runs on enterprise Linux or particular versions of Windows. Without fail, it has been buggy as hell, and crashed if there was a slight breeze outside or under gibbous moons.
Examples:
"When you boot the computer, first click this, then that, and finally this."
"We all need to share this one laptop. No one may use the laptop for anything but this one flow in this one program because the laptop's OS install is irreplacable, and the equipment it drives costs $250,000"
"Don't run anything in the background because their verification kernel was only tested with two cores, and we can't buy CPUs that old any more"
"Don't turn the printer on until after the UI is done booting up because if it sees an HP vendor ID on the USB bus it thinks it's a spectrophotometer or a license dongle or something"
If the CAD designer can't get the rest of their job done with a Red Hat box, do you want them carrying two laptops and or using an HDMI switch, or that they spend 30-60 minutes futzing with .so's until the one special snowflake program starts working on their main machine?
From a tamer perspective (and that's not that bad,) there are definitely vendors who will develop only against a single distro and won't set it up on anything else you've got. It's like the browser wars of decades ago and today.
This sounds like you have all the disadvantages of linux and all the disadvantages of vendor lock in.
Maybe I've been burned by iTunes DRM and short lived WYSIWYG editors, but since then, my tech stack and software needs to be flexible. Better to use a slightly less user friendly experience than to be locked in as the quality deteriorates.
Big fancy medical records software at the hospital? It used to run on either RHEL or CentOS. They stopped supporting 8. They won't do stream. You only have to buy one Red Hat License (unless you want to run CentOS 7.9 for the next 11-12 months), and it's tiny in comparison to what the actual software license and support costs, and we won't even get into the hardware that you're required to buy.
Will your vendor be buying RHEL to develop their product?
Anyone developing products for RHEL will now need to buy RHEL licenses unless Rocky Linux / Alma Linux are able to maintain 100% compatibility.
This will probably make the RHEL ecosystem more expensive for everyone using it.
Sounds like IBM.
What you want in EMR and banking is stability and reliability. Validating your logic against a stable, consistent suite of APIs, binaries, etc is a basic building block of those use cases.
The industry would ask the same of containers.
You could take a more abstract approach instead, but you’re really just passing the validation and certification buck around the stack.
Just like RHEL doesn't have to care if it runs on AMD or Intel or if it is virtual or physically hosted, or if the RAM is from Samsung or Micron. And if it needs to talk to a database, say, Oracle, it really doesn't care if it's oracle on Oracle Linux or oracle on SunOS, or if it's in the same rack, or even hall. It just wants to talk to oracle, and it probably has a latency and TNS requirement and that's about it from the hosts's perspective.
With 'install my package in a userland' you bind to the userland. But with 'run my container' you only bind to a container runtime, which has a very small and very portable interface in comparison.
So no, I don't think the host OS would be relevant at all in a containerised case, as long as it can run containers.
As for the userland inside the container: that's up to the EMR provider to choose and deliver. Instead of delivering RPMs you'd get OCI images (or tgz images). In a way, it would work the same way an OVA delivery would work, but smaller and more portable. In some other markets this is already done for WMS software for example, albeit using outdated methods like having a Swarm dependency so you're still runtime-locked.
In my experience, getting containers to run on non-mainstream Linux distributions is a complete crapshoot.
It’s also partly complicated by higher level abstractions like Kubernetes, Mesos, Racher, et al.
So at the minimum, pushing these workloads to containers with existing codebases would likely just replace the “certified on RHEL X” with “certified for use in RHEL X containers on RHEL X hypervisors, managed by container orchestration platform X version Y” and so on.
Epic has been working on an implementation of their client application (Hyperspace) as a web app (Hyperweb), and that’s probably where we’ll see any new abstraction from incumbent players with large install bases for quite a long time.
Edit: typo
If you add orchestration tools in to the mix, that's a different story, but even then you can argue that the orchestrator is your API and not the host OS. A bare kubeadm setup vs. EKS vs. AKS vs. GKE all have the same base API, which means as long as you don't extend past this API it doesn't matter where you run. Again, that breaks as soon as you start including hard dependencies on StorageClass configurations for PVCs, CNIs or CSIs.
The only real reason a specific host OS matters is the case where someone writes software against the specific userland of that OS. If you use the same syscalls that are available everywhere, the host OS no longer matters as long as it complies. In a way, if you didn't need the host OS userland, you could just build a single static binary. Or if the software really has special needs, build it as a unikernel.
As a concept the 'we build the software, you install the OS' deal is critically flawed and a bad point to abstract an interface between a third party vendor and a server they don't supply.
I thought with Docker the only thing you depend on from the host system was the kernel.
SmartOS (an Illumnos / solaris variant) is also a bit flaky, though was more stable than those two the last time I checked.
edit: Also, switching between RHEL and Ubuntu sometimes leads to VDSO mismatches, which can cause severe performance regressions. I've seen that with and without containers.
As long as you keep to the POSIX/C/C++ standards and don't use vendor-specific attributes (or at least abstract them away via macros), you shouldn't run into issues using another kernel, libc or compiler.
Any fork is deterred by the massive size and complexity of those. c++ is adding several orders of magnitude on complexity (there are no reasonable comparison to make between C syntax complexity and c++ syntax complexity). All that is part of the developer/vendor lock-in. This is how Big Tech has vendor locked some open source software.
That's why generic "open source" is hardly less worse than corpo binaries, because it includes grotesquely and absurdely massive and complex software.
We need lean, functional enough, open source, SDK included.