Oracle, SUSE, and CIQ Go After Red Hat With the Open Enterprise Linux Association (zdnet.com) 70
In a groundbreaking move, CIQ, Oracle, and SUSE have come together to announce the formation of the Open Enterprise Linux Association (OpenELA). From a report: The goal of this new collaborative trade association is to foster "the development of distributions compatible with Red Hat Enterprise Linux (RHEL) by providing open and free enterprise Linux source code."
The inception of OpenELA is a direct response to Red Hat's recent alterations to RHEL source code availability. This new Delaware 501(c)(6) US nonprofit association will provide an open process for organizations to access source code. This will enable it to build RHEL-compatible distributions. The initiative underscores the importance of community-driven source code, which serves as a foundation for creating compatible distributions.
Mike McGrath, Red Hat's vice president of Red Hat Core Platforms, sparked this when he announced Red Hat would be changing how users can access RHEL's source code. For the non-Hatters among you, Core Platforms is the division in charge of RHEL. McGrath wrote, "CentOS Stream will now be the sole repository for public RHEL-related source code releases. For Red Hat customers and partners, source code will remain available via the Red Hat Customer Portal."
This made it much more difficult for RHEL clone vendors, such as AlmaLinux, Rocky Linux, and Oracle Linux, to create perfect RHEL variant distributions. AlmaLinux elected to try to work with Red Hat's new source code rules. Oracle restarted its old fighting ways with IBM/Red Hat; SUSE announced an RHEL-compatible distro fork plan; and Rocky Linux found new ways to obtain RHEL code. Now the last two, along with CIQ, which started Rocky Linux, have joined forces.
The inception of OpenELA is a direct response to Red Hat's recent alterations to RHEL source code availability. This new Delaware 501(c)(6) US nonprofit association will provide an open process for organizations to access source code. This will enable it to build RHEL-compatible distributions. The initiative underscores the importance of community-driven source code, which serves as a foundation for creating compatible distributions.
Mike McGrath, Red Hat's vice president of Red Hat Core Platforms, sparked this when he announced Red Hat would be changing how users can access RHEL's source code. For the non-Hatters among you, Core Platforms is the division in charge of RHEL. McGrath wrote, "CentOS Stream will now be the sole repository for public RHEL-related source code releases. For Red Hat customers and partners, source code will remain available via the Red Hat Customer Portal."
This made it much more difficult for RHEL clone vendors, such as AlmaLinux, Rocky Linux, and Oracle Linux, to create perfect RHEL variant distributions. AlmaLinux elected to try to work with Red Hat's new source code rules. Oracle restarted its old fighting ways with IBM/Red Hat; SUSE announced an RHEL-compatible distro fork plan; and Rocky Linux found new ways to obtain RHEL code. Now the last two, along with CIQ, which started Rocky Linux, have joined forces.
Thank goodness for Debian. (Score:1)
I wouldn't trust any of these corporations.
Re: (Score:3)
Re: (Score:3)
I'm noticing a quiet move for Debian as a base OS for appliances. Be it TrueNAS SCALE, or Proxmox. Debian may not have the cool options that Ubuntu does, but it works, and has been around almost as long as Red Hat, so overall going that route isn't a bad choice.
My only minor feature enhancement for Debian, is that Debian would have the option at install time to support TPM unlocking LUKS, with a second LUKS slot for a recovery key. That way, machines can boot automatically after updates.
Re: (Score:2)
My only minor feature enhancement for Debian, is that Debian would have the option at install time to support TPM unlocking LUKS, with a second LUKS slot for a recovery key. That way, machines can boot automatically after updates.
Not sure what this means, are you saying you can load the TMP and when you power up or reboot, no need to type in the LUKS Password ? If so that seems to defeat the idea of encryption.
Re: (Score:1)
Debian does have a way of unlocking LUKS with TPM2. Clevis-TPM2 has been in Debian since Buster. Takes a bit of testing and setup, haven’t done it since, well, buster. clevis luks bind -d /dev/vda3 tpm2 '{"pcr_bank":"sha256","pcr_ids":"7"}'
TPM1 (pre-Intel ~4th gen) doesn’t work well.
Alternatively systemd-cryptenroll is now in Bookworm, this script https://github.com/wmcelderry/... [github.com] should work on most Debian, I would suggest reading the patches to understand what it does so you understand how TPM
Re: (Score:2)
I do agree that this works, but it would be nice if it were a default part of the OS install and didn't require a ton of preparation to do this. Ideally have it able to be done from a kickstart script.
Re: (Score:1)
The preparation is minimal, clevis does all the work, on more than a few distros it works right out of the box, just reset your TPM chip in UEFI and enable secure boot, I’ve automated the activation. I think the more supported way is not to use TPM2 auto but TPM2+PIN or use Tang.
Re:Thank goodness for Debian. (Score:4, Insightful)
What is your issue with CIQ? Did you even hear about them before?
Note: CIQ is the company releasing Rocky Linux and is founded by the same person who founded CentOS many years ago.
Re: Thank goodness for Debian. (Score:1)
Re: (Score:2)
Popular misconception? How? Can you provide proof of that?
Those old mailing lists are still around. Here's Sep 2003 where Greg mentions his initial plans for cAos (which are well established as being the roots for CentOS):
https://www.mail-archive.com/r... [mail-archive.com]
It didn't take long to also find this where Greg and Rocky are doing builds for cAos Nov 2003:
https://www.mail-archive.com/r... [mail-archive.com]
And here's Rocky releasing CentOS 3 tasste build Dec 2003:
https://www.mail-archive.com/r... [mail-archive.com]
So please - your turn, defend your own
NGMI (Score:5, Insightful)
They're trying to make workarounds for business-as-usual but leave IBM in charge of all the important strategic decisions.
They don't seem to realize that IBM will be back with more ways to screw them, in all likelihood.
The baller move would be to announce a cohesive fork of EL at the current public release and dedicate the direction of it to the nonprofit.
Get Amazon, Oracle, SuSE, the CentOS/Scientific/descendants on board and fold in the HPC group's work.
Let IBM keep its customers who have no choice. The other groups can afford to set the evolutionary direction going forward without IBM's judgment. Some og hatters will want to be hired by the group continuing what they used to work towards.
Much of the work can be shared with Debian while maintaining the separate tooling that many people seem to prefer.
Yeah, it's harder than being an IBM downstream but that business model appears to be Mostly Dead at this point.
Re: NGMI (Score:2, Informative)
Re: (Score:3, Informative)
I work at Red Hat, but not in the RHEL space. We are fiercely independent from IBM. This is not an IBM play in any way, shape or form.
From what I can glean (again, I'm not close to the RHEL team), this is an attempt to shift the community upstream of RHEL. Good for the open source community, not so good for businesses that simply re-package and add little value.
For everyone truly passionate about open source (which we are) this creates a more open community involvement.
It saddens me that the community is
Re: NGMI (Score:5, Interesting)
this is an attempt to shift the community upstream of RHEL.
We can clearly see that is what you're doing. That's exactly what we have a problem with. You want the "community" to function as free beta testers and developers for your product but at the same time lock them out from profiting from this work or their expertise. You want to divide the Linux community in two: 1) Enterprise = RHEL and only RHEL 2) "Community" = euphemism for "amateur" and your source of free labor.
You see, before you guys decided to be a bunch of dicks, we had a symbiotic relationship. But you failed to appreciate the value of the community, instead labeling anyone else who dared profit off Linux "leaches." Well, if we're leaches then so are you.
Re: NGMI (Score:4, Insightful)
Sorry as a long long term user and large customer of RHEL I just hate what RH has done here.
As a RHEL customer I used to benefit from Centos later Rocky/Alma, FAQs, bug reports, HOWTO and most importantly third pary repos built with these (and by these people). RHEL is pretty useless without these (certbot, ffmpeg, VLC etc etc).
This makes RHEL so much less useful. And I would always test on Centos and deploy on RHEL (with full subscriptions).
I used to be happy to take the latest Fedora and test and report bugs, knowing it would improve my work RHEL and my home Centos/Rocky setup too. Great symbiotic relationship, sorry that's all gone now. Why should I do anything for Fedora or RHEL. Thanks for the leech comment to customers !
I'm reinstalling my home stuff with Debian now and gaining more experience with that (I haven't run Debian in decades).
I doubt RH is independent of IBM, big companies can't help themselves, but worse the IBM influence may be as simple as "RH you need to increase revnue by xyz and increase sub by etc" and RH looks for a radical (read nasty quick hack) to achieve this.
This also devalues Fedora (Score:2)
Re: (Score:2)
there's no major advantage for most people in using Fedora over an Ubuntu/Debian combo instead.
There hasn't been an advantage for a while. As you've already indicated NextCloud, and other software like it, has aggressive upstream tracking of it's dependencies. Which long lived distros with hard static version requirements simply cannot support. Most software beyond on-prem roles will have at least one of these kinds of dependencies. (Anything webapp based these days) Which makes running EL a no-go for them if you need security patches. (The dependency devs simply declare the next major release to be
Re: (Score:3, Interesting)
The problem with RHEL comes from Oracle Linux. Oracle is basically RHEL, rebranded, recompiled and resold by Oracle. Except with no value added other than forcing customers to pay Oracle instead of RedHat.
Oracle Linux added nothing to the mix other than has a RHEL clone that Oracle is forcing onto its customers to buy for instead of RHEL.
It's effectively basic survival - RedHat is losing customers (and money) to Oracle, but doing all the work. Probably not the business model open-source expects. I mean, eff
Re: (Score:2)
I'm suggesting to my team that they port our system to run inside a Debian-based container, which we can then host on top of more or less anything running a similar version of the kernel.
No more depending on any company outside ourselves, especially not one with a proven history of working against FOSS (EVEN if to some extent they do work on things related to it). That simply defeats the whole point. We're a small team and though we did use RHEL in production, we relied on being able to develop and test a
Re: (Score:1)
Re: NGMI (Score:5, Insightful)
What Hubris!
Redhats entire model is Open Source, and repackaging other peoples work and selling it.
Re: (Score:2)
Re: NGMI (Score:4, Insightful)
If you are indeed working at RH and what you say is true about RH being independent in those decisions, the only conclusion is RH was taken over by evil
Re: (Score:2)
Evil is nothing new for Red Hat. [slashdot.org] Abruptly screwing their customers has been a Red Hat tradition for at least 20 years. They don't need any help from IBM for that.
Not good for the community, No. (Score:2)
this is an attempt to shift the community upstream of RHEL.
This is a huge downgrade, since the community already is both Upstream of RHEL and downstream; Cutting off the downstream source access is anti-Open source. RHEL is repackaging other peoples' work, and in the spirit of open source - RHEL's work as well should be available to repackage.
No it's not good for open source to have a distro hiding its source code.
Re: (Score:2)
Free ( as in beer) software is good for the community in the short term, any ways. If it kills the funding for all of the work that makes it good, then it could be really bad in the long term. This is the argument I've heard fro
Re: (Score:2)
The one thing that people of good will agree with, almost by definition, is that this is NOT a good thing for the community.
Some believe otherwise, but it is not a good thing for IBM/Red Hat either. You have lost the support of the community whose work you redistribute in violation of its license, and the inevitable result is that some of it will be relicensed in such a way as to clarify that you can't misuse it in this fashion any longer.
You basically screwed up, and your only play now is to reverse that
Re: NGMI (Score:4, Insightful)
IBM owns Red Hat. Red Hat is IBM at this point.
This is just fact. It doesn't need defending, or explaining, but it does have to be accepted. If Red Hat does something, whether it's being led by old Red Hatters or old IBM folks, IBM is doing that thing.
Re:NGMI (Score:4, Interesting)
I think this is stage 1. Ensure compatibility with RHEL to make it comfortable for those making the transition. The fork you're talking about is stage 2 for once this standard takes off. Maintaining compatibility will allow all those Red Hat customers to easily transition to one of these other companies.
Amazon, SUSE, and Oracle are going to win a bunch of government contracts over Red Hat when they can go and say, "Hey we're deploying an open standard and when your contract is up with us, we'll have to compete with all these other companies that support this same standard." RHEL, for all intents and purposes, is proprietary.
This was a huge blunder on Red Hat's part. All the major cloud providers will push this new Enterprise Linux and Red Hat will increasingly only serve IBM customers.
Re: (Score:2)
For me (well, my clients) this would make the most sense. I recently shifted them to Rocky Linux, and could stick with that for as long as it's okay. If IBM still keep screwing people, then Rocky will suffer, whereas this collaboration might not - and would be in a better position to fork if they felt it necessary.
In terms of my client, we'll go Rocky 8, 9, and then whatever's after that - by then, all the install and management tooling will have moved over to the new variant, so it'll be minimal hassle. E
Its like watching a fist fight for sure..... (Score:1)
The hope is then; force IBM thus RedHat deeper in to proprietary space? Or; force IBM thus RedHat to reevaluate its GPL interpretation or even the GPL environment itself thus making the industry see GPLv4 necessary?
So with Red Hat turning to the side of darkness! (Score:4, Interesting)
Re: (Score:2)
Re: So with Red Hat turning to the side of darkne (Score:4, Interesting)
Re: (Score:2)
Re: (Score:3)
I don't think too many people want to hang onto init scripts. But systemd ain't the answer. I prefer the attempt by Sun to modernise init: the Service Management Framework (SMF). Just as open and easy to use like Init. None of the drawbacks of systemd.
Re: (Score:2)
I often hear this, and it makes me wonder:
It's still out there. It's in Illumos and so on.
Why doesn't anyone port it to Linux? Go for a date with me
Re: (Score:2)
Why doesn't anyone port it to Linux?
Because at this point much of the lower level user space components expect systemd in most major distros. Anything that replaces it doesn't just need to justify the work for replacing the service manager (again), but also the additional work required to get a functional user-space after ripping systemd back out.
Systemd is a lot of things, which violates the UNIX philosophy, but I can appreciate what it's trying to do. It's trying to unify a whole lot of components that have a need to interoperate in a wa
Re: (Score:2)
> much of the lower level user space components expect systemd
That makes out that it's a done thing. It isn't.
Alpine, Void, Devuan, Gentoo, Slackware, AntiX & MX Linux don't use systemd. Chimaera Linux is developing a whole new init system and user-management daemon system based around the FreeBSD tools.
It's not some global requirement. Even many of the tools that currently "require" systemd actually just require some of its functionality, e.g. Canonical's Snap packaging system. If another init provi
Out of the frying pan into the fire (Score:5, Insightful)
Re: Out of the frying pan into the fire (Score:1)
Re:Out of the frying pan into the fire (Score:4, Insightful)
Just because Oracle is a terrible company doesn't mean this news is bad. Their interests just so happen to align with the community's. It may be a first, but it's not a bad thing. Having a standard enterprise Linux is a good thing and we were fools for all just putting our faith in Red Hat and allowing them to be a de facto standard. There needs to be an industry standard Enterprise Linux supported by all the big players so that no single player can monopolize it.
That doesn't mean I would buy ANYTHING from Oracle. Fuck those guys. But I'm not going to turn my back on something good just because Oracle's involved.
I like that Debian is a true community project, but "Enterprise Debian" = Ubuntu and 1) I dislike Canonical for several reasons, 2) I dislike several of the technological decisions in Ubuntu.
Re:Out of the frying pan into the fire (Score:4, Interesting)
Oracle could easily get a following if they GPL and mainline ZFS into the Linux kernel. There is a lot of good Oracle can do, and they can step in and get some marketshare, maybe even get a positive rep among F/OSS people.
However, what companies buy RHEL for, is the ability to run it offline. No snaps, no flatpaks, the ability to maybe have a Satellite server handle repositories, and have the RHEL machines on an air-gapped network. This is what Oracle, SuSE, and other competitors need to understand, and consider having a patch system, as well as maybe rebrand AWX or Ansible Tower for management.
Don't forget AAA and other things. Rebranding oVirt would give virtualization and companies will pay big money for this, just to get off of VMWare. FreeIPA/ Red Hat IdM could do a lot, especially if it is used as a directory server for IT related stuff, so when AD gets compromised, routers, appliances, consoles, and SAN web UIs are still protected. FreeIPA even allows 2FA auth on its side, so any appliance that supports LDAP is now protected by Google Authenticator style of protection without any changes on the endpoint.
Re: Out of the frying pan into the fire (Score:2)
Oracle Linux has been around since back when big iron UNIX still ruled. Part of the same initiative as Oracle RAC, to save on big money big U Unix by using cheap Intel clusters with a free "unix" OS. (All so you could spend more with Oracle of course)
So it wasn't born yesterday, and now it's outlived CentOS. It's still a completely free vessel by which you can consume Oracle software (or not) on cheap PC clusters. With timely security updates. That hasn't changed. Now it also runs their cloud offering.
I'm n
Batman again... (Score:2)
I think that Batman quote about living long enough to become the enemy applies to RedHat nowadays. Back in the 1990s they were perhaps more responsible for the spread of open source and Linux than anyone.
(No, doesn't apply to Oracle; they were never good)
Re: (Score:1)
I think that Batman quote about living long enough to become the enemy applies to RedHat nowadays. Back in the 1990s they were perhaps more responsible for the spread of open source and Linux than anyone.
(No, doesn't apply to Oracle; they were never good)
I would say that it also doesn't apply to IBM, they were never good either.
So when RedHat was purchased by IBM, this is exactly what was said would happen by everyone with foresight.
Re: (Score:2)
Oracle may have a stigma going against it, but they do build their RHEL-compatible products (Oracle database, Java) on Oracle Linux and not on RHEL.
For a compatibility test suite for an operating system, I can't think of too many that are more comprehensive than building Oracle and Java.
Re: (Score:2)
(No, doesn't apply to Oracle; they were never good)
I think a good analogy is that Oracle is acting like the USSR in WWII. Sure, the allies currently need their help and they're in this fight with us, so we just have to work with them while not trusting those evil fuckers one bit.
Re: (Score:2)
I like it.
Re: (Score:2, Interesting)
The Soviets and their communist allies (e.g., China) ended up murdering far more people than the Nazis.
In hindsight, perhaps we ought to have worked with the Axis to put down the Soviet threat first, and then take on Hitler once by far the more dangerous enemy had been taken care of.
Re: (Score:2)
Re: (Score:2)
IT was a gradual enshittification.
Welp, It Was Fun, SUSE. (Score:2)
Pretty cool distro after running it for a couple of years. But I can't in good mind stay with them if they are getting in bed with Oracle in IBM's house.
I guess it's time to see what all this Slackware noise is about.
Better to support Debian and freedom (Score:3)
Helping your corporate enemy remain popular is HIGHLY questionable.
There is no more Red Hat, just IBM.
Redhat really hates the "RHEL Compatible" part (Score:2)
So, wait until, in response to this, they decline do distribute the source code for the BSD/MIT/apache parts of the distro. Things like NFS4, OpenSHH and OpenSSL (and many more) that are kind of important for an enterprise distro.
Yeah, they will probably contribute upstream to those projects, and yes, they will probably provide the source code for Fedora (as fedora is the alpha and A/B testing for the next major version of RHEL), but they will less forthcoming for CentOS Stream, and will not release any cod
That would make no difference (Score:2)
Re: (Score:2)
The binaries distributed by Red Hat for Red Hat Universal Base Image are fair game to pull from as they're not subject to the Red Hat Enterprise Agreement. They would have to kill CentOS Stream, their free UBI offering and actively prevent Amazon employees (one of the largest third-party contributors to Fedora) from offering ABI-compatible drop-in replacements. Besides, they'd be killing their own business model, which was built upon nerds demonstrating the greater value in paying over and over again for free software vs. paying once for decade-supported proprietary equivalents. Take away the freedom part of the deal and there's little of value left compared to looking elsewhere.
And guess what? The "Red Hat Universal Base Image" WILL NOT have any BSD/MIT/Apache sources (and why should it). That was the whole point of my post.
Re: (Score:2)
The binaries distributed by Red Hat for Red Hat Universal Base Image are fair game to pull from as they're not subject to the Red Hat Enterprise Agreement
In the context of RHEL compatibility, nothing stops anyone from taking the binaries from UBI (minus artwork) and repackaging them for their distro (without source code) for packages where the source code is under a licence which doesn't require Red Hat themselves to publish it. For this reason, Red Hat withholding the source code to those packages makes no difference when it comes to clones wanting to be compatible, since as long as
Re: (Score:2)
I think you've missed the point of my post, so allow me to make it clearer.
The binaries distributed by Red Hat for Red Hat Universal Base Image are fair game to pull from as they're not subject to the Red Hat Enterprise Agreement
In the context of RHEL compatibility, nothing stops anyone from taking the binaries from UBI (minus artwork) and repackaging them for their distro (without source code) for packages where the source code is under a licence which doesn't require Red Hat themselves to publish it. For this reason, Red Hat withholding the source code to those packages makes no difference when it comes to clones wanting to be compatible, since as long as UBI exists, they don't need the source code to do that to begin with (just take the binaries!).
Furthermore, CentOS Stream itself is distributed under GPLv2 (as per the EULA they include with the distro). That means all the sources must be published for all packages (even BSD/MIT/Apache licensed sources) and anything derived from that distro would be subject to the same GPLv2 terms. This would include at least all the RHEL BaseOS packages, as Red Hat refers to CentOS Stream as "a midstream between Fedora Linux and RHEL" making RHEL BaseOS a derivative of it. So Red Hat couldn't stop handing out the source code to all of the included packages (including Apache/BSD/MIT ones) without first killing CentOS Stream. Changing the terms of CentOS Stream to allow for withholding MIT/BSD/Apache sources would allow Oracle and other competitors to make their downstream distros somewhat proprietary too, creating even bigger threats. This means their only option would be to kill Stream off entirely.
Does this all make sense to you now? Source code availability is irrelevant if UBI exists. As long as CentOS Stream exists, they must hand out sources. If they kill both those things entirely: As long as Amazon wants to save boatloads of money by exploiting Red Hat, they will pay existing (major) Fedora contributors already on their payroll a little more to also engineer RHEL-compatible drop-ins (similar to how they already pay them to work on Amazon Linux).
How do you remove Redhat's artwork and copyright notices from the binaries without the source? Remember that OG CentOS had a big problem precisely because, in the very begining, they left all Redhat artwork and copyrights in the SW.
CentOS stream is a property of Redhat. They can dual-license it if so they please, meaning that CentOS stream from Redhat would be distributed under a non GPLv2 License....
Re: (Score:2)
I don't like it and I also don't understand it.
They had to know that there would be a community response, as well as a competitors' response.
The former possibly more dangerous to them since without the community they don't have a product to sell. We come out with GPLv4, which explicitly forbids this kind of f*ckery and every other one we've discovered since GPLv3, and get key FOSS contributors to switch.
Presto bingo. No more Red Hat, at least, not including the GPLv4 bits. Not the outcome I want (b
Re: (Score:2)
I don't like it and I also don't understand it.
They had to know that there would be a community response, as well as a competitors' response.
The former possibly more dangerous to them since without the community they don't have a product to sell. We come out with GPLv4, which explicitly forbids this kind of f*ckery and every other one we've discovered since GPLv3, and get key FOSS contributors to switch.
Presto bingo. No more Red Hat, at least, not including the GPLv4 bits. Not the outcome I want (because Red Hat has been a semi-ok citizen before and I'd far prefer that we incentivize it to become a good one instead.) But it could be done.
I don't see what they were thinking. I'm not sure I even see that they were thinking. In their shoes I would reverse this stupid decision either immediately or sooner, commit to never doing it again, and do everything in their power to demonstrate some degree of good will toward the community that makes their product possible.
When they were a scrappy underdog, yeah, sure, doing a GPLv4 would have worked. Now that they have critical mass? No way! What's stoping them from forking the GPLv3 Version of the code, or moving to suitable alternatives licensed under BSD/MIT/Apache?
Again, they have the critical mass in more than one way. They have a lot of developers (and money to pay them), the largest support organization for linux, lots of software vendors coding against their distro, and lots of semi-captive clients... Yes, that can c
Re: (Score:2)
>What's stoping them from forking the GPLv3 Version of the code, or moving to suitable alternatives licensed under BSD/MIT/Apache?
Hemorrhaging money will stop them. That and the fact that alternatives for many, MANY core components that are GPL don't exactly exist.
The cost of paying even more developers to work on code would be enormous. And hunt bug hunts. And squash the new bugs they introduce when trying to copy changes to a constantly diverging code base. All of those take a shit ton of money.
Losing
Redhat Compatible is a good thing for Redhat (Score:2)
If the competition advertises itself as "Redhat compatible", that establishes Redhat as the standard. And in the Enterprise market, why go for the off-shoot brand that's playing catch up rather than the real deal ?
On top of it, "Redhat compatible" doesn't mean "take Redhat's work", it just means shipping librairies that are API compatible to Redhat, so that whatever is compiled on a Redhat system and dynamically linked still works and has all the needed symbols on your own non-Redhat system. Same for any
Re: (Score:2)
If the competition advertises itself as "Redhat compatible", that establishes Redhat as the standard. And in the Enterprise market, why go for the off-shoot brand that's playing catch up rather than the real deal ?
On top of it, "Redhat compatible" doesn't mean "take Redhat's work", it just means shipping librairies that are API compatible to Redhat, so that whatever is compiled on a Redhat system and dynamically linked still works and has all the needed symbols on your own non-Redhat system. Same for any interpreters you ship.
I don't get the hate for what Redhat is doing. It changes nothing to my daily life and I administer something like 1000 Redhat boxes. If it protects their business, all the better for me.
Precisely, I agree 100% with you. But Redhat rather have you using Redhat Compatible CentOS stream* or a small company's Redhat compatible like Alma or Rocky, than you using a Redhat Compatible from Suze or Oracle and paying them instead of Redhat.
* And therefore, beta testing the next point release of RHEL
Well Done (Score:2)
Well Done, Red Hat!