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.
SUSE has offered some level of support for RHEL/CentOS for a long time. They’ve had various programs over the years, long before this, to support customers who are on RHEL but might migrate to SLES.
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.
Oh man does SUSE(often via Microsoft referrals) provide support for a lot of Linux distros. If you are willing, they'll pretty much support any reasonable distro.
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.
That is amazing, especially as RHEL has a critical CVE sitting there for months that will never be backported to 8, while plenty of enterprises are sitting on 7.9 still.
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.
The product was called "expanded support" before. It was used to buy companies out of their RHEL contract before the renewal date, and ship SLES for new deployments. Nothing new.
Ahh yes, there was that kind of thing as well. SUSE provided us with ways of replacing all packages on a RHEL running system with SUSE augmented CentOS packages. It was often used by people who wanted a cheaper alternative to RHEL, but still wanted CentOS for their random 3rd party apps.
Curious, what CVE is this? I thought that even CentOS 7.x was still under support, so not patching vulnerabilities sounds like a great way to lose even more (would-be) customers.
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
Repeating from sibling post to make sure I'm not leaving any misinformation spread.
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
I've been working on SUSE Manager and we offer support with RHEL clients and all the clones like CENTOS and others. We actually are cheaper for rhel licenses. (you don't' get the same support ilke redhat but if you just wanted updates we can do it. )
This sounds interesting. Does that mean that if Rocky Linux and Almalinux die now, I can start paying you to provide security updates for my Rocky Linux 9 servers for 10 years?
SuSE's bread and butter is professional services. They don't care what software you use, as long as you pay SuSE to consult on it.
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.
Interesting… my experience has been the opposite, except for getting support. I prefer being able to get the product for free immediately and then chat about support later. It’s why we use Rancher, because it takes 20min to set up with Helm, vs like Tanzu where you have to have. an entire call and licensing and accounts to even download anything. Or D2iQ where you need to fumble with getting everything set up for a while with the sales and technical people.
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.
It appears you have content blocking enabled. To use all the features of this site, use a non-private window, or turn off content blocking for this site.
It is but OpenSUSE is free and binary-compatible since the last release - just like CentOS used to be for RHEL. SLES is also cheaper from my experience.
There isn't really an equivalent of Tumbleweed in the RH ecosystem.
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.
Stability-wise, it's more like this:
* openSUSE Factory is comparable to Fedora Rawhide (upstream "development" rolling release);
* openSUSE Tumbleweed is comparable to Fedora
* openSUSE Leap is comparable to CentOS Stream
* SLE is equivalent to RHEL (stable conventional point releases)
I'm considering trying SuSE MicroOS as a desktop for a while. Any thoughts? I tried suse for a few weeks about a quarter century ago then went back to slackware, so I have no relevant experience.
I haven't tries MicroOS, so I cannot comment on that. I use both Leap and Tumbleweed and am quite happy with both.
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.
I've been using a mix of things. I actually like gnome for some reason, but anything that lets me avoid the mouse is fine. Systemd is a don't care for this experiment because I want something container focused anyway, where init or systemd can start podman and I'll take it from there. And I want rolling because I like not messing with things that aren't the thing I'm doing. I like apt better than dnf for cross compiling tools, but dnf better for most everything else.
I use openSUSE Aeon (former MicroOS Desktop) for about a year. It is based on rolling Tumleweed and the system is stable. It updates on a background automatically.
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.
That looks interesting. I've been looking for a new OS to migrate away from Fedora Silverblue recently, since I pretty much no longer trust RH.
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.
At work we traditionally have almost only SLES servers with some Oracle Linux and RHEL ones.
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 :)
Didn't realize witnessing a market leader flex their strength and have it backfire so badly would be so cathartic. Wish it would happen to other businesses more often.
Cadence for example, the software that the engineers design and run simulations of the latest and greatest ICs with, from HN's favorite RISC Vs to Nvidia's 4090, only runs on SLES and RHEL.
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.
At this scale, the difference doesn't matter. "No support" means "only runs on". Those software makes everything we use daily and we depend our literal lives on. No sane management will risk billions of losses, the literal production and accounting of the company or possible loss of human lives on some ideological or aesthetic preferences on the OS. Moreover the licensing agreements usually prevent the licensees from even trying such things. Compared to their licensing fees, RHEL or SLES are a cent to a 100 bill.
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.
Any company building safety critical stuff should be using a separate set of hardware to validate the CAD designs. Even with ECC memory and machine check exceptions, processors still corrupt stuff and make mistakes.
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 you're spending five or six figures on a licence, paying Red Hat or SUSE on top is easy, and part of the cost. It makes no sense to try and run it on Debian.
Productivity matters though (especially at 5-6 figures per seat!).
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?
In the (now far away?) past I used chroot jails in Ubuntu containing binary-compatible dependencies for chip sim tools. Regressions would be run on proper RHEL though so tool vendor support wasn't impeded by anything even remotely suspect.
I've dealt with an environment that was using custom software that relied on a library that only SUSE had in their repo.
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.
You could have the exact same problem with FOSS: a piece of software that the organization relies on that's ancient, crufty, and barely maintained and the org won't invest in the resources to get rid of the technical debt.
SUSE gets an ex-Red Hat CEO and decides to offer support for RHEL. Interesting. Seems RHEL is still the gold standard of commercial support ;) DISCLAIMER: I’m a 18 year Red Hatter and know the SUSE CEO since many years.
SUSE does not offer support for RHEL but for their own RHEL clone (SLL, formerly and still internally SLES ES). This product has existed for a long long time.
The catch with switching from RHEL to SUSE (or Ubuntu, or whatever), is what does your vendor support?
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.
> The Red Hat Developer Subscription for Individuals is still only available to individuals, not organizations or teams, and is designed for personal servers, home labs, and small open source communities
This is why I try to avoid healthcare and banking etc. Too much legacy vendor stuff which is hard to modernise. This whole "supported distro" stuff wouldn't matter if they just packaged their software in the shape of a container, even with container persistence. No more "required" distros. They would probably still have some CPU feature requirements and maybe a kernel version support range.
Containers don’t necessarily solve this challenge. Containers still run (on top of) an OS.
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.
If they deliver their EMR as a container, it no longer matters what host OS it runs on because the container doesn't have to interact with it.
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.
Yeah, there are a lot of misconceptions about how containers work, and partly that’s due (IMO and experience) to the earlier days of containers, before we had things like standard formats and interfaces.
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.
As long as you have a complete userland in your image and a compatible kernel and no extra CAP or binds, it really doesn't matter at all what else the host is doing. That's true for most mainstream architectures and distros of the past 5 years (and more, but I can't be bothered to look it up).
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.
Devuan and Synology come to mind. Devuan's kernels lead to segfaults that I didn't successfully diagnose. Synology's are missing some obscure system call that non-obsolete OpenSSL needs.
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.
DHH interacted with a reseller and not directly with SUSE… We have our issues (as does any company selling enterprise support) but this is not an accurate representation.
Everyone can fork gcc and glibc, they are fully open source. In any case the question remains why one would want to... there are alternatives for both of 'em (musl/dietlibc for glibc, llvm for gcc).
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.
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.