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.
jzb 774 days ago [-]
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.
_4ta5 774 days ago [-]
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.
It made the auditors happy.
galangalalgol 774 days ago [-]
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.
throwawayExSUSE 774 days ago [-]
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.
chadcatlett 774 days ago [-]
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.
tripflag 774 days ago [-]
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.
galangalalgol 773 days ago [-]
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
worthless-trash 773 days ago [-]
Citation ? as Criticals are -definitely- still in el7 lifecycle support.
galangalalgol 773 days ago [-]
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
mseidl 774 days ago [-]
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. )
stracer 773 days ago [-]
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?
jkaplowitz 773 days ago [-]
Cheaper for RHEL licenses (with reduced scope of support) than Red Hat themselves, meaning SUSE is a RHEL license reseller approved by Red Hat?
carlosrg 774 days ago [-]
> It's clearly a reaction to the civil war in the RedHat world.
The date of the announcement is January 2022 so it can't be that.
coldtea 774 days ago [-]
It's not like RedHat started the civil war with the recent announcement only...
0xbadcafebee 774 days ago [-]
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.
hhh 774 days ago [-]
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.
itpcc 774 days ago [-]
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.
Yeah... No need to fear of vendor lock-in huh?
c_r_w 774 days ago [-]
Came here to say the same thing. "Liberty"... I'm using a Pihole to block trackers.
yonatan8070 774 days ago [-]
It works fine for me on Android, in a private Firefox tab, with uBlock Origin and a PiHole
thesuperbigfrog 774 days ago [-]
All of the shops using RHEL derivatives may be looking at their options with Red Hat's forced changes.
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.”
vbezhenar 774 days ago [-]
I thought SLES is paid as well?
przemub 774 days ago [-]
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.
dev_daftly 774 days ago [-]
I'm pretty sure opensuse is upstream from sles and probably closer to fedora than centos stream.
madspindel 774 days ago [-]
> Leap uses source from SUSE Linux Enterprise (SLE), which gives Leap a level of stability unmatched by other Linux distributions
* 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).
the_why_of_y 774 days ago [-]
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.
zxspectrum1982 773 days ago [-]
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)
(ex-SUSE here)
krylon 774 days ago [-]
A cynical person might read this as: "Even if you don't use SUSE, you can still give us your money"
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.
galangalalgol 774 days ago [-]
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.
krylon 774 days ago [-]
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.
galangalalgol 774 days ago [-]
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.
vyskocilm 774 days ago [-]
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.
bogwog 774 days ago [-]
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.
krylon 774 days ago [-]
I just installed µOS in a VM and will play with it for a bit. It seems very intriguing. If I like it, I might switch my openSUSE machines.
signalblur 774 days ago [-]
I’ve been using Fedora Silverblue for about two years and recently tried MicroOS (OpenSuse Aeon) and it is really wonderful.
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
jonsger 774 days ago [-]
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 :)
I would say it's at least worth a try.
candiddevmike 774 days ago [-]
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.
jacooper 774 days ago [-]
This was announced in 2022, not a response to red hats recent decision.
fmajid 774 days ago [-]
Preempting the writing on the wall is a smart business strategy
NegativeK 774 days ago [-]
It probably wasn't hard; Red Hat nuked CentOS in 2020.
ilyt 774 days ago [-]
...just use Debian. Soooo much less fuss than any of the "enterprise" ones.
SoftTalker 774 days ago [-]
But if your commercial or scientific software is only supported on RHEL or SLES then you can't just "use Debian."
hospitalJail 774 days ago [-]
I suppose I can google/chatGPT this, but since both are unreliable I'll ask here:
Which software?
okanat 774 days ago [-]
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.
hedora 774 days ago [-]
“Only runs on”, or “is only supported on”?
Debian alien worked the last time I had to install some janky rpm-only commercial software.
okanat 774 days ago [-]
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.
hedora 772 days ago [-]
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"
Symbiote 774 days ago [-]
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.
hedora 772 days ago [-]
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?
dallas 773 days ago [-]
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.
jrockway 773 days ago [-]
If it's just client applications that force people to be on RHEL, why is RHEL so heavily involved in the server-side business? OpenStack, etc.
NegativeK 774 days ago [-]
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.
hospitalJail 774 days ago [-]
Isnt this just a reason to stick with FOSS?
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.
rilindo 774 days ago [-]
Depending on the business or OP's role, they may not have a choice in the sofware they support.
hospitalJail 774 days ago [-]
I can relate to that :(
NegativeK 773 days ago [-]
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.
jrockway 773 days ago [-]
Isn't this just a reason to statically link, and recompile once a decade when the kernel ABI changes?
ilyt 774 days ago [-]
Shove it in the container with absolute minimum deps.
jwildeboer 774 days ago [-]
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.
zxspectrum1982 773 days ago [-]
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.
yankcrime 774 days ago [-]
This announcement predates the new CEO’s appointment.
bluedino 774 days ago [-]
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.
thesuperbigfrog 774 days ago [-]
>> what does your vendor support?
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.
> 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
TheNewsIsHere 774 days ago [-]
That page also makes it pretty clear where Red Hat is going generally. The idea of a business is effectively caged to “enterprise”.
Sounds like IBM.
Hfdlmsh 773 days ago [-]
There is a different subscription for "Teams", aka business use.
oneplane 774 days ago [-]
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.
TheNewsIsHere 774 days ago [-]
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.
oneplane 774 days ago [-]
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.
hedora 774 days ago [-]
Containers have to be compatible with the host operating system kernel.
In my experience, getting containers to run on non-mainstream Linux distributions is a complete crapshoot.
TheNewsIsHere 773 days ago [-]
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.
Edit: typo
oneplane 770 days ago [-]
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.
pxc 774 days ago [-]
What non-mainstream distros did you run into this with? Was it Docker containers or desktop containers like Flatpak?
I thought with Docker the only thing you depend on from the host system was the kernel.
hedora 772 days ago [-]
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.
oneplane 774 days ago [-]
That's why I mentioned kernel and runtime compatibility.
EwanToo 774 days ago [-]
This is from 2022, not a response to this months Redhat announcements?
Animats 774 days ago [-]
So this is basically a support contract deal, correct? Not a distro.
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.
sylware 774 days ago [-]
developer/vendor lock-in is done at the SDK level: gcc(via c++), glibc(via manic abuse of versioning + a hard dep on gcc), etc.
mschuster91 774 days ago [-]
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.
sylware 774 days ago [-]
You missed the point.
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.
photonbeam 774 days ago [-]
Red hat’s lock-in is in certifications for various software and situations. Suse is a genuine competitor in this space
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.”
https://get.opensuse.org/leap/15.5/
* 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.
https://news.ycombinator.com/item?id=36573872