For better or for worse, this has caused a lot of software vendors to drop RHEL/CentOS support. Many have started to offer Ubuntu support in it's place.
Most of them didn't even try to support stream. I'm not sure what the process behind that was.
CentOS was free, which is why we used it. Sure, our SAP boxes run RHEL but the other stuff doesn't. We started moving a lot of stuff to Ubuntu as well.
Now, Ubuntu is by no means perfect, snaps are annoying, etc. But Red Hat really angers me with their decisions during the last few years.
One example is removing OpenLDAP:
The openldap-servers package was removed in Red Hat Enterprise Linux 8. The openldap-clients package is still shipped though.
If you use openldap-servers in Red Hat Enterprise Linux 7 (RHEL7), you need to consider to change your LDAP server from OpenLDAP to Red Hat Directory Server (RHDS) in Red Hat Enterprise Linux 8 (RHEL8).
RHDS is provided as an add-on subscription in RHEL8, so you need buy the subscriptions in addition to RHEL subscription.
Additionally, Red Hat support is so bad these days. It almost reminds me of Microsoft Technet forums of the past. Random 'techs' offering copy-paste solutions and the same bad information.
> Additionally, Red Hat support is so bad these days. It almost reminds me of Microsoft Technet forums of the past. Random 'techs' offering copy-paste solutions and the same bad information.
Yeah, that's been my experience. We had a bad driver package from them completely hose one of our prod systems.
It took 3 days and multiple calls from our CTO to get anyone to seriously look at the issue despite being on the top level support level and it being a Severity 1 issue. The whole "Responses within X hours" thing is a joke when all they give you is "Have you tried rebooting?" or "We're still looking into it" (technically those are response!).
Well that explains a lot. Historically, the basic idea as I understood it was that you could have the software for free (CentOS) and they didn't really mind because they knew they were selling support. If the support is worthless, then they have to try and squeeze money out of the software, which explains their behavior.
Dumping? This is IBM we're talking about. They'll ratchet up the price to fewer and fewer customers, trying to keep themselves in that pocket where they're too useful and expensive to move away from, but still able to hold the irons to their customers.
The SLA is to respond within X hours, not resolve. So when the SE sends an email that says: "I'm the owner of the case and will reach out after looking at the notes." They have complied with the SLA.
It is revolting to be blocked and not get any help, everyone is anxious, specially when your main product is down (money), but seriously, I just think nobody reads their SLAs and just complains until someone resolves. I suppose it’s a rule of life no one reads terms (yet try to enforce them somehow), but usually their attitude give me the creeps.
I am always baffled by people using ubuntu because "free".
I get the desire if you want the paid stream. EG, an alternative to Redhat or SuSE as a paid stream.
But if you're going to use Ubuntu, why put up with the snaps, the commercialism, the app store, when you can just use debian?
Every time I hear a reason why, it makes little sense to me. Even though 95% of Ubuntu is Debian, and Ubuntu wouldn't exist without Debian.... people use it.
As a long time Ubuntu user, I figured I'd try Debian a month ago for the same reasons you listed. It's supposed to be 95% the same, so why not. Fresh install, my bluetooth headphones didn't work. Reverted back to Ubuntu and they worked right away.
That's my reason for using Ubuntu instead of Debian - I simply don't care enough to bother with these small things.
Yes, Debian prioritizes software freedom, and Ubuntu starts from Debian but prioritizes having the hardware actually work, so while Debian might be just fine and quite stable for servers, probably not the best choice on laptops for most.
Edit: perhaps this situation has improved for Debian now that non-free firmware support isn't hidden, but it's been a while since I installed Debian on a new machine.
Except Ubuntu did what Fedora/RH didn't used to do - break my shit.
Everything would work great, then bam giant updates, everything broken (bluetooth, wifi, video, graphics cards, audio), have to start from scratch learning some new fad Ubuntu folk had invented.
When I want to tinker or try out cool-new-tech, then sure, a platform like Ubuntu is great - semi-stable, half-working software.
When I don't, Debian/CentOS are hands down just better. Sure, I have to configure my bluetooth, but I have to do it just once _and it never breaks_.
Fedora used to be pretty great, then some personalities with inflated opinions of themselves started ruining the relative stability.
This isn't wrong, really. Canonical, for all its flaws, correctly identified a lot of problems with Linux early on -- distribution, usability, application availability -- and then solved them. (Or made strides, anyway.)
It also wasn't shy about marketing and made an effort to have a welcoming community whereas other communities were much less friendly to outsiders.
The free CDs and Canonical's "ground game" in the face of the Red Hat Linux diaspora made it much more successful than other "Debian, but easier" efforts before it.
If I'm not running a desktop, why would I consider running Ubuntu at all? I feel the same about people offering a kneejerk suggestion of Ubuntu as when I'm told to use Docker without actually knowing anything about my needs. Just because I'm wanting to use Linux does not mean I need Ubuntu. Just because I'm deploying code doesn't mean Docker is the solution. But 99% of the time I talk to people, it's all Docker this Docker that.
There is a certain practicality in running the same thing on the server as on your developers' laptops.
Ubuntu and Debian are pretty similar, and using Debian gets rid of things like snap, which I'm glad to be rid of - but it adds an extra level of "well it works on my machine" which I'm not glad for.
If it's going to be hard to get that special different version of Java to work on the server, it should be hard to get it to work on the desktop too :)
Of course the rise of containers has made a lot of this stuff less relevant.
If the headless server has a UI process running that is absolutely wasted resources. Having the same environment for the dev's laptop and the server seems like such a waste of resources. The two things are not the same, so don't try to fit the square peg in the round hole. Whatever these differences are, they should be able to be determined and accounted for in the deployment.
To me, we've gotten a bit lazy and a bit too focused on the wrong things. I feel like this happened when we started running javascript on the server. That was such a shock to the system and all sorts of things had to be done since it just was not the normal way of doing things. Someone decided it'd just be easier to clone the dev's system and deploy that as a server. Like what the actual... I also totally feel the same way about running a Windows Server. Like why on gawds good earth would you ever think that was a good idea?
I've found the Docker discussion is seen through a better lense when you talk about the tech it's running.
For polygot/hybrid cases where you have a smattering of different languages and supporting technologies/services, docker makes a lot of sense.
If you're all in (for example) on nodejs with a monorepo, it probably doesn't - you're just an "npm install" away from deployment.
Whenever I really dig into the docker passion, I usually find devs who are frustrated by having to manage a million little details to get the dev environment going.
If the language/stack takes that pain away, docker loses most of its value.
my issue is when my process can utilize 100% of CPU available, it makes no sense to have the ability to run several on the same VM. my VM is already one of several on the host. my software stack is already available on the AMI. I don't need the additional time to wait for my AMI to warm up and then warm up Docker. Once my AMI is up, I'm running
There are many reasons, LTS, security kernel patches etc ... Ubuntu is not 95% Debian, as a matter of fact Debian got LTS only recently, before that you were out of luck.
I still have bad memories of going to the DC with a USB stick with network driver on them because the Dell server with Debian on it would not ship with non proprietary firmware / drivers.
"The Debian project took the decision in October 2022 to create a new repository component non-free-firmware, and include its content on installation media for the upcoming Debian 12 release (bookworm) to make things easier for our users. This change was implemented in time for the bookworm alpha 2 release of debian-installer in February 2023, and all d-i releases and daily and weekly images since then all include firmware."
Previously one had to either download the needed firmware separately, or a bootable image containing it so that it was accessible during install.
Many users having problems with proprietary hardware didn't know they could just grab the install image with included firmware at https://cdimage.debian.org/cdimage/unofficial/non-free/cd-in...
But I blame Debian for this because their site historically has been excellent at hiding stuff.
Veeam doesn't support CentOS stream or 9, there's been a bunch of things here and there. I notice many are moving to Ubuntu. I had to go through all of our vendors last year, and the nice thing about CentOS was almost everyone supported it. Now there's no 'gold standard'.
Part of it was that CentOS Stream reversed the CentOS stability level vs. Fedora; a lot of the vendors targeting CentOS/RHEL were looking for something fairly fixed. CentOS made sure they could also support folks who didn't want to pay for RHEL.
Yep unity too, they only support up to centos 7 and Ubuntu.
I don't really like using snaps for everything so this is a bit annoying. But at the moment I'm mainly devving for VR so i need to be on Windows anyway.
Similar goal, but is working more directly upstream with Red Hat[2] as opposed to the (as I last had read) undisclosed and non-open approach that Rocky Linux has taken.
Yeah Alma is a much better option if you care about the behavior and attitudes of the people behind the project.
The Rocky people are antagonistic toward Red Hat and view them as somewhat an enemy (which seems so weird to me as without Red Hat, they couldn't possibly exist). They strictly want to take what Red Hat sells and rebuild and distribute it for free.
The Alma people on the other hand view themselves as partners and contributors to Red Hat's ecosystem. They want to make their product available for free, but they upstream as much as possible and add actual value to the ecosystem.
If you don't care about any of that, it's still better to choose Alma IMHO because their approach (following the letter and spirit of "the law") is a lot more sustainable than Rocky's exploit-the-system approach.
> They strictly want to take what Red Hat sells and rebuild and distribute it for free.
I think this is an unfair framing. Rather, they want to take all the GPL source code that Red Hat is obligated to make available, and distribute it freely. They believe this is in accordance with both the law and the software license that Red Hat agreed to, when using it as a basis for their business in the first place.
Personally, I don't have a dog in the fight, or a strong opinion on the matter. But we should at least fairly represent each parties position.
All of the source code is already available, in CentOS Stream, from which RHEL is built in the first place.
What they want to do, is do an exact rebuild of RHEL without having to go through the effort of putting the distribution together themselves, matching the versions that are used in a particular version of RHEL against what is available via CentOS Stream.
The RHEL subscription license comes with a stipulation that the recipient does not distribute the RHEL sources further, under pain of license termination. I'd call that unjustly locked down by Red Hat.
But that is pretty much exactly the contention of Rocky Linux. Well actually, they don't explicitly accuse Red Hat of unjustly locking down the source code, just that there are now some extra hurdles required to legally obtain it.
They do contend, that they are exercising their legal rights as enumerated in the software license that Red Hat agreed to, when it started to use and freely redistribute the work of others.
If you are denying they have this legal right, then I believe it's on you to explain and justify this legal position, rather than just asserting it as fact.
What I am saying is that the code is not "locked down" in any meaningful sense, that it is already open source, and therefore that Rocky Linux isn't "freeing" it. I'm not making any statement about their legal rights.
As I commented elsewhere, "RHEL" isn't GPL licensed, the kernel is, and glibc is, and systemd is, etc. Individually.
The sources for all of those packages, individually, are available via CentOS Stream just as they ever were - alongside the sources for packages that aren't GPL licensed, for which there is not actually a legal requirement to distribute sources.
What Red Hat has stopped doing is providing a git repo containing the exact combination of package sources which collectively make up one particular version of RHEL. Instead, all of the sources are still available, but if you want to rebuild the entire distro you need to match up the particular versions with RHEL. And that's exactly what Alma Linux does.
Okay, so the source is 100% freely available. And with that source, and nothing else, you are able to regenerate RHEL binaries.
Rocky Linux contends they are not doing anything illegal in the methods used to obtain the source code (ie. legally renting an RHEL VM from any number of providers, and downloading the SRPMS).
Maybe Red Hat wishes this was illegal, but I still haven't heard anyone claim that it is.
I'm not claiming that either, so what's your point. I'm just saying that the way Rocky presents it is mostly marketing. The cleverness is to save themselves effort, not to do something they weren't being allowed to do previously.
I'm not sure why you weighed in on the subject then, other than to advance your own personal preference. At least, I mistook it as an objection to Rocky Linux's very existence. As long as what they're doing is legal, then let them be. Each distribution will rise and fall based on the value it provides.
> which seems so weird to me as without Red Hat, they couldn't possibly exist
If Red Hat didn't exist, they wouldn't need to exist. Nobody would need to test their stuff against RH, and nobody would need to run garbage that the upstream vendors only bothered to test against RH.
> which is slightly upstream and less stable than RHEL
As a user who almost exclusively uses rolling release OS-es, is this actually something people care about? CentOS Stream is downstream of Fedora -- and Fedora is a rock solid base. It's not like CentOS Stream is riddled with bugs, broken features, etc.
If you wanted a distro that was similar to but not exactly the same as RHEL, then Fedora itself would be a way better choice. And if you care that it's exactly the same as RHEL, then CentOS Stream doesn't cut it.
This is absurd. CentOS Stream isn't just "similar", it has ABI compatibility with RHEL, it's waaaaay more stable than Fedora because the most it can be different from RHEL in general terms is the difference between two Y-releases (e.g. 9.Y -> 9.Y+1)
This is the first time I have heard of SUSE Liberty Linux as an alternative to RHEL... when I went searching for information on it, all I could find was the product page and some press releases.
It's hard to read between the lines of the marketing speak but it sounds like it's just a suite of paid support options for existing RHEL/CentOS deployments and not a RHEL derivative that one can just download and use. Unless I am missing something?
No it is actually a RHEL derivative, but personally I wouldn't go that direction unless you intend to eventually move to other SUSE stuff. They committed a chunk of budget initially to maintain it, but I'm sure they view it as a stepping stone or bridge SLE.
Personally it would not be my first choice since I am somewhat allergic to anything with the word Oracle in it, but another option for those in the enterprise space might be Oracle Linux:
My understanding is that since Red Hat restricted the source availability for RHEL, Rocky is using the following loopholes to gain binary compatibility with RHEL:
1. Using OCI images of RHEL (i.e. on Docker Hub)
2. Using cloud server images of RHEL
They outlined their plans for this in June of 2023[0].
Red Hat’s official stance is that downstream distros like Rocky or AlmaLinux should be basing off of CentOS Stream — that would allow all the EL distributions to contribute and use the same OS base[1]. AlmaLinux pivoted to this method[2] — which seems like a more sustainable approach to me.
My opinion: blows my mind that people who value Enterprise Linux would be willing to continue to use a distro like Rocky that actively works against/around the supported route its upstream provider suggests.
(Personally, I don’t find value in the EL ecosystem, I prefer rolling releases everywhere when possible)
I fail to see what separates Alma from CentOS Stream at this point
The entire Propose of CentOS was Binary Compatibility with RHEL, largely for Vendor compliance reasons, if a vendor of a commercial software product validated RHEL 7 for their software running CentOS 7 was also supported
Running CentOS Stream, or now Alma Linux would not be as their are no longer binary compatible with RHEL.
the Hostility of IBM and Redhat here has lead me to transition 100% of the CentOS Server I managed to Ubuntu Last year... The software vendors that i use all quickly validated Ubuntu as an alternative to CentOS after the original CentOS Stream announcement which made is a easy choice for me..
I will never use RHEL or RHEL based distribution again at this point so I really do not care about the future of Alma or Rocky either
>Personally, I don’t find value in the EL ecosystem, I prefer rolling releases everywhere when possible
if you are running ERP Systems, LOB Apps, or other critical functions that measure their code life in decades not weeks then EL systems are required. I do not want the system to change as the app i am running has not changed. I want Stability, and security not new features or more performance or even new hardware
> if you are running ERP Systems, LOB Apps, or other critical functions that measure their code life in decades
That's really what confuses me about the people who use CentOS or Rocky, they want or need the stability of RHEL, so that they can run these crucial applications, that mostly aren't cheap, yet they refuse to pay for the development of the operating system they run it them?
I really don't see the point in any of these clones, other than as an educational tool. I see the point in RHEL and while expensive, that's the price of developing this platform. You can buy SuSE, Ubuntu Pro or Oracle Linux, if you feel that RedHat is to expensive (perhaps not Oracle), but that's not what some people want, they specifically want RHEL, but for free.
The theory that Red Hat users are supposed to be paying for development of the system is a recent one. What Red Hat used to say is that the software is free and their users are paying for support.
That made a great deal of sense, as of course Red Hat themselves were shipping a great deal of software written by other people without paying for its development.
There's nothing confusing about people declining to go along with this change.
> There's nothing confusing about people declining to go along with this change.
No, but why stay on a platform from a vendor that has a business model you find hostile? I can see the need for a transition period, but I'd start looking for another vendor that has value and pricing that aligns more with my ideals. People seem hellbent on staying on a RHEL-like platform.
Also, CentOS isn't/wasn't exactly new, the current pricing model from Redhat isn't nearly as old as CentOS.
>> but that's not what some people want, they specifically want RHEL, but for free.
Well in my world we used to run many Dev/Training/Non-Prod servers with CentOS and then Run the Prod Servers with Licensed RHEL
Similar to having a MSDN License for Windows vs Production licenses
Then with the announcement of CentOS Stream they tried to sell their Dev program, but that program was TERRIBLE for enterprise use, it was built for individual developers, and not at all compatible with the model many organizations where using. They have since tweaked the terms to make is somewhat more compatible but it still IMO, not very useful for many of the scenarios I found myself in over my life
And frankly I have enough problem keeping track with MS Licensing I do not need the additional headache I might as well just use windows at that point.
Red Hat was able to become a billion dollar company by providing great support, and being easy to do business with, even before IBM buyout and accelerating after their support was becoming less and less quality, and they became more and more hostile / harder to do business with
Many organizations where already questioning their continued use of Licensed RHEL because of this, this like played a part in them killing CENTOS (and yes they killed CentOS, CentOS Stream is not a compatible replacement) as that was easier that fixing the systemic internal issues around support and business processed.
> That's really what confuses me about the people who use CentOS or Rocky, they want or need the stability of RHEL, so that they can run these crucial applications, that mostly aren't cheap, yet they refuse to pay for the development of the operating system they run it them?
Yes. Non-prod (or even prod and non-critical) servers usually outnumber critical prod servers, and it makes sense to not run RHEL on them and pay for support, but to run a 100% compatible distro.
> the people who use CentOS or Rocky, they want or need the stability of RHEL, so that they can run these crucial applications
No, the people who need the stability of RHEL were already paying for it. The people who used CentOS were doing so to be able to develop and test software that would eventually be used by people running RHEL.
> I fail to see what separates Alma from CentOS Stream at this point
I believe that AlmaLinux's approach is in-line with Red Hat's vision for downstream OS-es. Rocky's is not.
I think a potential benefit to aligning with Red Hat's approach is that both AlmaLinux and Red Hat will be contributing fixes, improvements, etc. to CentOS Stream -- and any other OS-es that base off of CentOS Stream. And, nothing is preventing AlmaLinux from snapshotting their own stable releases -- which allows the AlmaLinux team to test and release stable releases to their users.
> the Hostility of IBM and Redhat here has lead me to transition 100% of the CentOS Server I managed to Ubuntu
I completely agree with this perspective. This is why Rocky's decisions really baffle me: why use an upstream OS like RHEL if you absolutely do not align with its objectives? I feel like it would have made much more sense for Rocky to make Fedora their upstream instead of implementing workarounds to copy RHEL.
> I will never use RHEL or RHEL based distribution again at this point so I really do not care about the future of Alma or Rocky either
I also do not use any Fedora based distribution (typically just running NixOS or Ubuntu), however, I find that I do care about these shifts because Red Hat has tremendous impact on the trajectory of most Linux distributions. And the downstream OS-es' responses have been interesting to observe to me. :)
>I believe that AlmaLinux's approach is in-line with Red Hat's vision for downstream OS-es.
As far as I can tell this is logically incorrect CentOS/Alma are upstream not downstream and red hat's vision of downstream OSes is they don't exist because that takes a nickel out of IBM's pocket.
You're correct, I was referring to AlmaLinux's former status of being downstream of RHEL. Additionally, from Red Hat's perspective, AlmaLinux is still downstream of CentOS Stream (and thus a participant of Red Hat's vision for CentOS Stream[0]).
> red hat's vision of downstream OSes is they don't exist because that takes a nickel out of IBM's pocket
I think CentOS Stream actually contradicts this because (I would imagine) it's a lot of work to maintain and greatly benefits the community -- and Red Hat still makes it freely available for other distributions to base off of.
Technically code-wise we're a downstream of CentOS Stream for the most part, but the end result is more of a hybrid because we're targeting RHEL and can match commits to RHEL commits from stream for a lot of it...so yeah.
Formerly we were just 100% downstream RHEL with none of this nuance, as you mentioned.
At this point, I'm not sure why end users who care about Red Hat stability don't just use RHEL directly. Red Hat has multiple ways to take advantage of RHEL that involve no cost (that weren't available when the original CentOS project was conceived):
- Free developer licenses[0] (great if you're a home-labber, IIRC you can get up to 16, I think?)
- Red Hat UBI images[1]
I feel like most users of AlmaLinux won't see a huge difference between just using AlmaLinux's release cycle vs RHEL -- especially since AlmaLinux will be ABI compatible with RHEL. I.E. apps that work for RHEL should work for AlmaLinux.
So, back to your original question, I don't know what end-users want more of other than as was said by mrweasel in a different comment: "that's not what some people want, they specifically want RHEL, but for free".
> I fail to see what separates Alma from CentOS Stream at this point
Alma is getting their source packages from CentoOS Stream, but they are using the specific versions that are in the Redhat releases they are targetting. They aren't just rebuilding Stream sources from HEAD.
> For a typical user, this will mean very little change in your use of AlmaLinux. Red Hat-compatible applications will still be able to run on AlmaLinux OS, and your installs of AlmaLinux will continue to receive timely security updates. The most remarkable potential impact of the change is that we will no longer be held to the line of “bug-for-bug compatibility” with Red Hat, and that means that we can now accept bug fixes outside of Red Hat’s release cycle. While that means some AlmaLinux OS users may encounter bugs that are not in Red Hat, we may also accept patches for bugs that have not yet been accepted upstream, or shipped downstream.
Incorrect, according to their FAQ[0] and the original article I linked[1]:
> What does ABI/binary compatible with RHEL mean?
> In July of 2023, we announced (opens new window) that we were shifting our goal from being a downstream rebuild of RHEL to maintaining ABI compatibility with RHEL. For the AlmaLinux team that means that everything from software applications to kernel modules that work on RHEL will work on AlmaLinux, and if they don't we would consider that a bug.
TL;DR: they are using CentOS Stream as their upstream.
EDIT: Sorry, you're correct -- I was thinking you meant their original goal of "bug-for-bug" compatibility with RHEL.
IBM's official route results in a distro that is not bug-for-bug compatible with RHEL, at least not without a lot of unnecessary work. The route Rocky is taking results in a distro that is bug-for-bug compatible.
> The route Rocky is taking results in a distro that is bug-for-bug compatible.
Point taken.
From my perspective, it seems like a short-sighted approach to rely on loopholes to obtain bug-for-bug compatibility. I know I wouldn't be comfortable running anything production-grade on Rocky Linux with their current approach.
I believe if Red Hat had legal grounds to sue Rocky, they would have done so already. And there's no possible way for RH to obfuscate their sources so Rocky will continue releasing an exact RHEL clone unless Red Hat sunsets RHEL.
So what? Doesn't matter how convoluted the "loophole" is. There will always be a loophole because Red Hat must leave one open, because this is open-source software and it's impossible for them to truly close all avenues to using your RIGHTS under the license.
We should he celebrating people working around DRM, not being fearful of it.
Fair enough! As I stated, I have no personal stake in Rocky's approach as I am not a user interested in the Enterprise Linux ecosystem. That being said, if I was, I would be concerned with the approach as I can't see it being sustainable long-term to rely on the workarounds.
(I'd be happy if the Rocky Linux folks prove me wrong -- the more variety there is with Linux, the better!)
>> Red Hat’s official stance is that downstream distros like Rocky or AlmaLinux should be basing off of CentOS Stream — that would allow all the EL distributions to contribute and use the same OS base
That stance goes contrary to the "everyone benefits" nature of free and open source software. It turns "everyone benefits" into "Red Hat / IBM profits". Why should the community contribute to Red Hat's bottom line if Red Hat refuses to contribute back to the community?
Rocky Linux's "going around Red Hat's back" is only necessary because of Red Hat's choice to not contribute back to the community.
Your analysis seems to be ignoring all of the work required to create and maintain the CentOS Stream / RHEL distribution in the first place, which is substantial.
Prior to CentOS Stream, if you were a CentOS user or maintainer who experienced a bug, your only option was to file a bug on the RHEL bug tracker and wait for a Red Hat employee to fix it for you. It was the Android-esque "throw the code over the wall" model of open source.
Post CentOS Stream, a CentOS user or maintainer files the bug in the CentOS Stream bug tracker, can write a patch and have it reviewed by other users/maintainers/Red Hat employees tracking the issue, and then benefit from Red Hat QA'ing the fix.
So counter to your claim, I would argue that the CentOS Stream model provides more bidirectional / mutual benefits.
>> Your analysis seems to be ignoring all of the work required to create and maintain the CentOS Stream / RHEL distribution in the first place, which is substantial.
Substantial enough to effectively "close source" RHEL?
The changes are effectively a violation of the GPL by prohibiting customers from distributing RHEL sources through Red Hat's Terms of Service and EULAs:
RHEL is not "effectively closed source" by any stretch of the imagination. The sources are available as CentOS Stream -- from which RHEL is built in the first place!! It is true that, in order to put together an exact copy of RHEL, you would need to do a bit of work to figure out exactly what versions RHEL uses, and specifically pick those versions out of CentOS Stream. It isn't as simple as downloading the entire tree of sources from a single git repository anymore. But that's not the same as "effectively closed source", either.
If you provide GPL software to your customers, you have to provide everything they need to build this exact version yourself, not point them at a repo and tell them to figure it out.
Red Hat does provide all of that to RHEL customers. This is a discussion about what non-RHEL customers get.
Even non-customers are provided with all of the sources they they could use to build RHEL, given some additional effort. It's less trivial than it used to be, but not particularly difficult.
Alma takes the approach of reconstructing RHEL using these public sources, Rocky takes the approach of buying AWS VMs running RHEL for a few minutes at a time so that they can download RHEL sources as a "customer" while only paying a few dollars a month to do so.
The point is, even non-customers can rebuild RHEL using sources made publicly available by Red Hat if they so desire. It's not "effectively closed source", even to them.
You'd still have to wait for someone at Red Hat to backport the fix themselves. There wasn't really a way to actually participate in the engineering of CentOS itself.
You'd have to wait on it to be QA'd before it would get into Stream officially, but once it's in Stream the process of it getting into RHEL is mostly automatic. It would just be a matter of waiting, since RHEL only does releases every 6 months whereas Stream releases constantly.
With CentOS you would have the same problem, except that there's no way to make the engineering part happen any faster than Red Hat's staffing and priorities allowed.
Yes, you can. This is something everyone gets mixed up.
RHEL is built from CentOS Stream sources. The changes Red Hat made to RHEL source distribution mostly just make it more challenging to reconstruct an entire build of RHEL from CentOS Stream - because you would have to map backwards from all of the different versions of sources available in CentOS Stream to the exact versions that a particular version of RHEL happens to use. But at the scale of any individual project, it's trivial for any upstream community to just look at the latest CentOS Stream sources for one particular package, if they want to look at which patches Red Hat is applying. There are no legal or contractual restrictions on this whatsoever.
This is setting aside the fact that most patches are backports from one upstream version to another, and bugfixes that get submitted "upstream first" to begin with, which makes the whole discussion kind of moot. The typical scenario for a net-new bugfix would be that a Red Hat employee submits the fix upstream and gets it reviewed and merged by said upstream months before it ever sees the light of day in RHEL, so upstream maintainers would never need to look at the RHEL sources in the first place.
> Does this give Red Hat the right to effectively "close source" the code for RHEL despite contributions from the rest of the community?
Legally, yes. Not sure what the point is you're trying to make.
I'm not sure why anyone would want to use a downstream distribution of Red Hat if they don't like Red Hat's trajectory. If you don't like Red Hat's current objectives with RHEL, it should be as simple as: stop using something downstream of RHEL.
> Legally, yes. Not sure what the point is you're trying to make.
Legally, no; unless RH is the only copyright holder, they get to follow the same rules as everybody else, and for GPL packages that means not imposing additional restrictions on redistribution of source code.
> If you don't like Red Hat's current objectives with RHEL, it should be as simple as: stop using something downstream of RHEL.
People are fine with being a downstream of RHEL. It's being upstream of RHEL that's the problem; Stream is RHEL Beta by another name.
>Legally, no; unless RH is the only copyright holder, they get to follow the same rules as everybody else, and for GPL packages that means not imposing additional restrictions on redistribution of source code.
And there aren't any. "RHEL Linux" isn't GPL licensed, the kernel is, and glibc is, and systemd is, etc. Individually.
The sources for all of those packages (and ones that aren't GPL licensed, for which there is not actually a legal requirement to distribute sources), individually, are available via CentOS Stream just as they ever were.
What Red Hat has stopped doing is providing a git repo containing the exact combination of package sources which collectively make up one particular version of RHEL. Instead, all of the sources are still available, but if you want to rebuild the entire distro you need to figure out which particular versions to use. And that's exactly what Alma Linux does.
> "RHEL Linux" isn't GPL licensed, the kernel is, and glibc is, and systemd is, etc. Individually.
That is why I said "GPL packages", yes.
Okay, so if I buy RHEL, and I download the SRPM for the kernel, and I publish it - which I'm legally entitled to do, what with the kernel package being GPLv2 - is RH not going to terminate my RHEL license?
If you can't justify the cost of RHEL for your use case, I believe Fedora would be the best alternative at this time since its development has not been affected by the changes recently made to CentOS, and it provides a near identical feature set.
The leading features of CentOS were 1. Absurdly stable; keep updating the same version in place for a decade without changing it. 2. Drop-in compatible with proprietary drivers and applications published for RHEL.
I love fedora, it's been my daily driver for a long time.. but it's not designed to be stable. Things break. Usually nothing you can't work past, but you don't want to spend that kind of effort to maintain stable servers.
Big thanks to the CentOS project, which probably did as much to improve the size and health of the EL ecosystem as any other single factor, and did much of that work long before any official association with Red Hat.
Much respect for the tenacity required to figure out how to bootstrap RHEL without its build system.
(Shout out to White Box Enterprise Linux as well!)
Scientific Linux was one of my favorites for a while. I stumbled onto it back when some important CentOS leader went missing and the future of the whole project looked uncertain.
SL7 is still supported until June 2024. The maintainers decided not to do SL8 and are now contributing to AlmaLinux instead.
That was the real rug-pull. Had they supported CentOS 8 for the full 10 years, and announced that starting with 9 it would be this useless rolling release, people would have been much more calm about the whole thing.
It would've been disappointing, but it wouldn't have knocked the bee hive off the tree, so to speak. The announcement came right after I had switched over all my stuff to target CentOS 8. If they had given me the runway to make it feel like all that work wasn't for nothing, I would've been okay taking a few years to slowly roll to something else.
Same. I mostly support what Red Hat has done (after many hours of listening to arguments and thinking about them. Not the prima facie arguments that they made which were PR BS and spin, but the real reasons that were only gotten to by podcast hosts that pushed back a bit. But the CentOS 8 rug pull was a bad move and IMHO is really hard to defend because it came down to a short-term profit grab to try to force people to buy RHEL. I think long-term profit motive is a good thing (within reason and without compromising the open source principles) as it keeps RHEL sustainable, but the rug pull of CentOS 8 was wrong.
I can't say I wouldn't have done a similar pull on the rug, but having a plan before-hand for open source users, home users, and even "small business" users would have gone a long way to making the pill easier to swallow.
I know for myself, where I could fit into all three of those, I just won't use RedHat anything anymore. Whereas if there had been a "pay one-time fee of $500" or whatever to get "ten years of self-support/no-support" our server would be RedHat today.
This is really the time to make a decision, do you really need support..ehm sorry insurance? Then RedHat/Suse/Oracle if not, choose a trusted community distribution like Debian.
We moved everything to debian when Centos moved to a stretch release for 8, no regrets whatsoever, zero difference in stability, solved some niche hardware support issues.
Writing was on the wall back then tbh. Redhat can enjoy it's legacy bubble, I'll continue to enjoy not paying for free software.
>I'll continue to enjoy not paying for free software.
Well we pay for it (the project and different other software projects..and even a completely different os) but in donations instead to pay stakeholders and "managers". ;)
Same here... we were already running lots of Debian and Ubuntu, and have made the decision to use Debian by default for everything new, and migrate to Debian everything that still has to be around in a couple of months. The rest can be killed of when it hits the EOL for CentOS of Ubuntu 20.x
My understanding is that the real problem is twofold:
First, some proprietary software only supports a subset of distributions. Debian is rarely on that list. RHEL, for some time, has been a safe default.
Second, IT organizations only want to support one distribution when at all possible.. As such, RHEL and CentOS made a lot of sense. RHEL and Debian means twice the work.
That said, it's going to have to change. $349 for every 2 VMWare images (as I understand it) plus $2499 for every 2 processor sockets adds up.
I thought you just meant insurance as in it's a huge profit center, so it's pushed knowingly that the vast majority of people will never use it. Notice the word use instead of need.
You need insurance in some businesses, or sht will fall exclusively on you...even if it's not your fault (cover your as), insurance/financial sectors etc...
Bad comparison, no one will pay for your downtime/leak, but you can blame redhat/suse/oracle for it. Aka you don't loose your job, but the house is still burned down.
It's interesting to see the different strategies people are adopting. I recently came across TuxCare's Extended Support for CentOS 7, an interesting stopgap for those not ready for an immediate RHEL shift.
Somewhat surprisingly, it's also pretty affordable. It's one of the few options like this I've seen, though I'm curious if there are others that are around this same price.
It will not automatically remove dependencies that were installed along with a package when that package is removed. I'm guessing this is due to some historical ideology about how `apt-get` was intended to function. I just typically run `apt remove foobar && apt -y autoremove`.
aptitude also auto removes dependent packages and is in Debian stable.
It has also a useful 'aptitude why package' to say why a package is installed and a nice TUI (which is optional; for the most part it works very similar to apt).
Yes, that's what 'apt autoremove' does... remove packages that were installed as a dependancy, but are no longer needed because packages using it have been removed.
However, the package could of course still be used by unpackaged software or local scripts.
Apt purge cleans up user config files after a package, but not package dependencies. For complete package removal, apt autoremove is needed even after apt purge.
Indeed. So it not only doesn't do a complete job, it "takes prisoners" too. Taking no prisoners would mean it's aggressive, relentless, thorough, and apt is neither of these, it's a solid, professional tool, with some legacy baggage, but at least it's friendly and discoverable about it.
In the current thread, I'm only nit-picky about this, because OP said "Last time I tried `apt`, it would uninstall apps without cleaning after itself". To which to suggest that apt-purge does clean up after itself is incorrect. It does some additional cleaning-up, but it doesn't do a complete cleaning-up.
That being said, of all the package managers I tried, I still like apt the best. I feel like it's the most straightforward and user-friendly of all of them.
> Our research has identified numerous critical and high-risk vulnerabilities that your vendor hasn’t patched.
This sort of language strikes me as fear-mongering. I can't tell which issues they have patched in CentOS7 that otherwise remain unpatched. Anyone know what they are talking about?
Too late Red Hat, we already have dumped our CentOS fleet (thousands of hosts) for another distro. Will never trust IBM/RedHat.
I was real annoyed as I did a tun of work prepping for a migration to CentOS 8 and then got rug-pulled by IBM with CentOS Stream. They lost all the goodwill just to make a tiny bit more money.
Now I am doing everything possible to eliminate RHEL servers. What next will they pull? The longer you depend on them, they more they can charge you later.
This is a very important milestone for us since we have a lot of Centos 7 servers and can't go to RHEL. From my point of view, there are more or less three solutions:
a. Go to Debian (or ubuntu server etc); probably the most difficult since everything will be different
b. Go to a fresh Almalinux or Rocky 9 installation; also very difficult since there's a lot of stuff to be moved
c. Try to use in-place upgrade using Leapp or something. There are some guides for this (https://wiki.almalinux.org/elevate/ELevating-CentOS7-to-Alma...) but I'm really not sure how good this would work on a live production system.
I'd definitely prefer the solution c, if I can confirm that it works of course. Has anybody tried using leapp to upgrade Centos 7 to Rocky/Alma ? What was your experience? Do you feel that it's worth researching that path or it's probably better to move to a greenfield installation?
For what it's worth, we're trying to do a lot of our server upgrades with the Elevate scripting to Almalinux, but man can it be a pain. We have a 30% success rate in testing, and even when it goes right it tends to be 2-3 hours of downtime. The alternative though is to rebuild every server on spare hardware and manually migrate data and configurations over. So it's still a better option once we can figure it out. I'm hoping to get downtime <1hr and >90% success rate before we start really pushing through these by April.
That's a bummer! I know there's a few places that have used it on the 50k+ scale, so once the kinks for your environment, it should be great. If there's anything that can be done to improve the script, we'd love to help! Feel free to join the chat and share what's up in ~migrations.
We briefly looked at it. We decided to just move everything to Ubuntu. It's been a lot of work, and taken a lot of time, but ultimately we feel that it's been worth it. Ubuntu isn't without it's own problems but we're much happier today and feel that we're more future-proof for it.
Well, Redhat has to make money somehow, so this decision is understandable.
To me, open-source is about the open, transparent "culture" in which you commit to develop, not about putting things out there for free (as in free beer). Too many companies already benefiting from open-source packages (e.g., OpenCV) without giving anything back to the community.
> Well, Redhat has to make money somehow, so this decision is understandable.
RedHat has been making money for decades. The Centos rug pull was just a way to make more money at the expense of their users and the larger open source community.
It is impossible to justify a rug pull. By definition, it is a hostile, one-sided, trust-destroying, and underhanded move.
Apparently not an equivalent amount of money to the value they feel they’ve provided. And honestly given the communities response, I think they’re probably right. I mean if you think about it there’s no reason someone using Centos for a proper use case wouldn’t be fine moving to Centos Stream, unless they were getting some value out of Centos production-friendly releases. Vendor compatibility and LTS patches and updates take a big team to maintain, someone has to pay for that and I feel like many were just using Centos when really they should be using a supported enterprise distro.
The question I’m trying to answer is who promised what, where was that published, and when was it published. If a squirrel promised me 10 years of support, that’s different than a CentOS maintainer making that same promise on the wiki.
Red Hat's explanation was something along the lines that it was a wiki and not guaranteed to be accurate? I don't think editing was open to to people outside of the CentOS org.
I could completely see how one could make decisions based on that date, but I can also see how doing that could backfire. As always, a plan b is valuable.
Frankly, I think this kind of thinking is short-sighted quarterly corporate bullshit almost certainly done by IBM and Redhat itself would never have done it (and most of the people who were Redhat in those days left to work somewhere else). How many corporate environments the world over are running on Redhat, paid Redhat, because the engineers there came up in the Linux world learning free Redhat and were able to continue using CentOS at home or in their dev environments? That sort of cradle-to-grave brand identity with people who eventually become high-level decision-makers and money controllers is invaluable, but the value is also impossible to quantify, accountants never se it, and instead just see people trying to use all of their hard work for free.
Yet somehow even Pablo Escobar understood this and threw away billions just giving money to poor people to keep cities on his side. I'm not even going to say IBM's basic business model of making shit that works, doing at least some complex things reliably and well back when that was very difficult, is invalid. But it is fundamentally different to Redhat's business model, which was simply cultivating a lifelong love of their product in the minds of its users. It's like the Army acquiring the Red Cross. They work in a lot of the same places doing overlapping work and no doubt a lot of corporate synergy could be achieved and administrative overhead eliminated, but it would irreparably destroy a century and a half of goodwill and brand identity. Exactly the kind of strategy you'd expect from people whose decision consequence horizon extends no further than the next three reporting periods.
"Acquire competitor, just to shut down competitor" is a pretty gross (and monopolistic) business practice. So that's a relatively crass way of looking at it.
Agree and wish there was something that could be done against such business practices, but it is indeed difficult to regulate.
Over the years I became aware that the acquire-extinguish pattern was definitely not just a coincidence, specifically i remember disney bought up some 'IP' just to litigate against some adjacently-related online fan game in the UK in order to shut it down and 'acquire' its captives, over to a similar product they already owned. Sorry I looked for the exact reference but cant find. There are countless other stories if you look though.
This all came full circle when I was 'enlightening' a young relative who had just finished business school, or rather she 'learned' me. Turns out this acquire/extinguish game is like a whole 100-level course in <pick-your-business-school-of-america>. Who knew.
Perhaps if you need to acquire and shutdown your competitors, you should shut down your own firm, or at least pursue a different strategy. Monopolistic business strategies are crass.
because having CentOS lead to Oracle Linux being a thing which allowed big competitor to offer what was essentially 100% compatible product to your own while undercutting your support costs.
I don't think RHEL/IBM cares about the small losses on CentOS/Rocky/Alma/etc what they found was hurting them was companies like Oracle
I don't think that's correct; AFAIK OEL has always pulled directly from RHEL sources. That is, they were a sibling, not a downstream of CentOS. I am open to the idea that CentOS was basically collateral damage as Red Hat attempted to block Oracle, but that's not the same thing.
This EOL date is a generous one. Like my organization, most others I know have already completed their migration from CentOS to RHEL/Fedora/Rocky/Alma/etc during the early part of 2023. Thus, these 6 months are mainly for the few outliers who have not.
> This EOL date is a generous one. Like my organization, most others I know have already completed their migration from CentOS to RHEL/Fedora/Rocky/Alma/etc during the early part of 2023. Thus, these 6 months are mainly for the few outliers who have not.
I can't disprove your anecdote but do you think this is really true? Orgs who ran CentOS likely did so with the idea that they'd have a very long time to migrate to something different. CentOS 8 nominally had support until something like 2032, so it seems like a really major change to go from almost a decade to a little over a year to migrate away.
That company had few load-bearing CentOS 6 machines that barely anyone knew how to operate (as in "where are the SSH keys, passwords, where shit is stored on them") and docs were in disarray.
The replacement project for remaining CentOS 6 machines was going glacially, but at least didn't endanger compliance. The replacement project for CentOS 7 got sabotaged by management, few people got run out of the company, last I heard the replacement project for the replacement project was going to just end up with few multimillion cheques to OpenLogic so that certain big fat client group doesn't drop them like hot potato on EOL day.
I'm taking this opportunity to migrate a few k8s clusters from CentOS 7 to CoreOS instead. Which is a big move because it means that instead of using Ansible to setup the k8s services we put everything into Terraform and Ignition. Or cloud-init if you want to use Talos or Flatcar.
Other than those big clusters we have some CentOS systems spread out for minor services and those we're migrating to either RHEL or Fedora, depending on circumstances and requirements.
I don't know much about CentOS, but I've seen a lot of anger about the end of CentOS Linux, regardless of CentOS stream, Rocky, etc. . Can someone explain the history of this, why CentOS is going away, why it's being replaced with these new alternatives, and why many seem quite mad about it? Just curious to understand the state of it.
>RedHat acquired CentOS, saying that it would be good for CentOS[1].
>RedHat shut CentOS down.
It should be noted that six years passed between point A and point B, during which time Red Hat did invest quite a lot of additional resources in CentOS. Red Hat did not acquire CentOS and then immediately shut it down.
CentOS Stream is also not a wholly different thing from CentOS, although it is obviously not exactly the same thing.
Red Hat had given a lifecycle for CentOS 8 with an EOL in 2029. IBM acquired Red Hat, and promptly announced they were reneging on this schedule. Given that the primary draw of CentOS/RHEL are long-term, reliable, well-supported, stable operating systems, users were... displeased.
CentOS stream is primarily intended to onboard users onto RHEL, which is undesirable when nobody trusts Red Hat to keep their word now.
Thanks! Can we see who updated the wiki? If it’s some random person, then I’m not sure it’s quite the smoking gun I’m looking for. If they are someone more closely associated with the project you’d expect to made decisions about this stuff, then that is very useful to know. Thank you!
I suppose people are trying to claim this wasn't actual CentOS policy, but it was, and when the project abruptly decided to truncate eight years of announced support, at no point did anyone involved deny this was a change.
One of the biggest issue is that they pulled the rug on the support window. The last release started out with 10 years of support, but they walked back on that when they announced the end of regular CentOS and reduced it by more than half.
> The last release started out with 10 years of support, but they walked back on that when they announced the end of regular CentOS and reduced it by more than half.
I thought that the "10 years of support" which was customary w/ CentOS wasn't applied, but neither Red Hat nor CentOS made specific announcements that CentOS 8 would have 10 years of support. People believed that CentOS 8 would have 10 years of support because of what was done in the past, but that's always subject to change.
If, however, there were direct statements from Red Hat or CentOS that CentOS 8 would have 10 years of support and then they changed that - that's moving the cheese for sure.
I think you are right. I haven't been able to find any direct EOL date from RH even at launch. It seems like it was mostly people just assuming (for good reasons, but still just assuming) that it had the same EOL.
Though there are some gaps on the Wayback machine that makes it hard to find some centos8 related posts at the time it launched, but I'd be surprised if the eol wouldn't have been announced elsewhere too.
It was customary to be 10 years, but I don’t even know if anyone announced that. I guess I’d compare it to cancelling a pretty good sitcom in the level of consternation. Frustrated that I have to find something else to do on Tuesday night, but I really should read a book instead (use less proprietary Linux).
Was reneging on CentOS 8's support cycle what led to that Red Hat developer for individuals license that allows 16 hosts? I haven't gotten a good sense of if they introduced that to placate some people or if they had planned on it.
I believe the CentOS EoL will impact the re-builders albeit this complex. Not everything is GPL, they need the sources that may be a huge issue. To a lesser extent, probably the build script in the source rpem helps.
A lot of package managers that distribute binaries (e.g. conda-forge) rely on CentOS 7 because of the relatively old glibc version available, I wonder what all of these projects are planning on moving on to
i really liked CentOS - it was definitely my goto distro for spinning up a server. Yum is so much saner than what ubuntu is up to. Thankfully now, not something i have to do with as much - i run a website with DB and don't even know what the distro is - a detail i'm glad to leave to abstractions and platforms to manage.
Technically EOL of CentOS 7. Guessing 8 will be supported for a while, then one must decide to switch to CentOS Stream, RHEL proper, or an alternative like Rocky.
Most of them didn't even try to support stream. I'm not sure what the process behind that was.
CentOS was free, which is why we used it. Sure, our SAP boxes run RHEL but the other stuff doesn't. We started moving a lot of stuff to Ubuntu as well.
Now, Ubuntu is by no means perfect, snaps are annoying, etc. But Red Hat really angers me with their decisions during the last few years.
One example is removing OpenLDAP:
The openldap-servers package was removed in Red Hat Enterprise Linux 8. The openldap-clients package is still shipped though.
If you use openldap-servers in Red Hat Enterprise Linux 7 (RHEL7), you need to consider to change your LDAP server from OpenLDAP to Red Hat Directory Server (RHDS) in Red Hat Enterprise Linux 8 (RHEL8).
RHDS is provided as an add-on subscription in RHEL8, so you need buy the subscriptions in addition to RHEL subscription.
https://access.redhat.com/solutions/3816971
Additionally, Red Hat support is so bad these days. It almost reminds me of Microsoft Technet forums of the past. Random 'techs' offering copy-paste solutions and the same bad information.