The ELI5 is Red Hat had publicly accessible source code for RHEL. They’ve removed that and only thing you see is their upstream contributions to CentOS Stream. So you can’t build a RHEL counter part at this point, because their source isn’t available.
This affects projects like Rocky Linux, Alma Linux, even Oracle Linux.
Fedora runs basically future code for CentOS Stream which is basically RHEL Next really.
Some folks, like I just read Jeff Geerling, are now deciding their code, he makes Ansible stuff, won’t be guaranteed on RHEL because they can’t publicly test it.
Red Hat is a corporate entity that justifies locking down open sources to satisfy the bottom line. I’m a disgruntled former employee though.
Edit: It’s “ELI5” not “TIL”. Changed to be “ELI5” from “TIL”.
So Fedora is an “upstream” linux. So what that means is developers push their code directly into Fedora. Every 6 months, approximately, Fedora releases a new release. People on Fedora get that and file bugs and features to the next code.
CentOS Stream pulls from that. So they’re more stable. They don’t have the bugs that the Fedora folks hit (in theory), because it’s been solved upstream. By the time it gets to them, down stream, it’s been smoothed out.
Red Hat Enterprise Linux every once in a while will put a stake in the ground and say THIS is the code we’re going with from CentOS Stream. Make sure THIS version works, and pull in any bug fixes.
To give you a “real” kind of idea. Let’s say you have an application. We’ll call it the hiya 0.2 version. Fedora pulls in hiya 0.2. Then you keep upgrading until you get to 1.0 then 2.0 then 3.0. Fedora pulls each of those in.
CentOS Stream slowly pulls those in.
Eventually Red Hat says Hiya is what we need in RHEL! Except you’re going too fast. We want Hiya 1.0. BAM! Hiya 1.0 is going into RHEL 10. HOWEVER, since you’re faster, you’ve solved bugs in Hiya in 2.0 and 3.0. So RHEL will say well we don’t need that feature or that feature or that feature. But we DO need THAT bug fix in 2.0. So we take that bug fix and we backport it into OUR Hiya 1.1 code base. We do need THAT security fix in 3.0 to our code. So we make Hiya 1.2.
This is a VERY simplified version. And I’m not certain anymore on the interaction between CentOS Stream and RHEL. But that’s generally how it works.
IDK if I fully answered WHAT CentOS is. CentOS WAS a completely 1 to 1 compatible RHEL operating system that was started by the community and given fully 100% free. Years ago, idk maybe 5-10 at this point, Red Hat went to the CentOS devs and said, come work WITH us. Not FOR us, but WITH, but we’d pay you (somehow I’m not sure on the financial details), us so we can help you make this better. Because they saw CentOS as a good onboarding ramp to sales of subscriptions for RHEL.
Myself, and others, worried that this was the end CentOS, but they kept moving forward.
A couple years ago while I was at Red Hat, Red Hat decided that the gap between Fedora and Red Hat was too large. So they were going to pivot CentOS into CentOS Stream so that developers could build against CentOS Stream and expect it to work in RHEL. Myself and many others inside of Red Hat were VERY vocal this was a bad idea, but we didn’t matter and even my mentor told me this was a good thing for RHEL. I didn’t care, RHEL was fine, I cared about CentOS going away. So now they’re turned CentOS into their play thing. And they’re forcing people to build against CentOS Stream, which IS NOT stable RHEL.
It used to be that Fedora was upstream for RHEL and centos was compatible with it.
Then it got changed to centOS stream which is now upstream from RHEL and and downstream from Fedora. However not every feature from CentOS Stream makes it to RHEL, but most bug fixes are, even sometimes having to backport bug fixes to older versions of the software.
Now however (since centOS no longer exists) there’s no publicly available option that’s binary compatible with RHEL without access to the RHEL Source which is now locked behind a developer account and is not licensed for redistribution.
The only caveat being that Rocky and Alma have stated they’re attempting to figure things out. Something similar, though I can’t remember the exact change, happened like 10 years ago and everyone thought CentOS would die.
If there’s one thing I have faith in is that open source always finds a way. It’s not just you figuring something out. It’s entire communities of insanely brilliant and PASSIONATE folks. Never underestimate the passion that drives these folks. Red Hat does.
Can you explain to me what happened with CentOS some 2-5 years back? I thought it was depreciated which is why Rocky Linux and Alma Linux came to fruition, but I don’t think I understand what CentOS Stream is. Thanks for all the information you’ve provided.
So Red Hat was getting closer and closer to CentOS. Then a few years ago, instead of being in partiy, Red Hat, and supposedly CentOS council, agreed it’d be better for CentOS to lead RHEL. This became CentOS Stream. And then the original creator of CentOS started Rocky. Alma was another distro that moved in to fill the niche of CentOS. I believe there are others as well.
CentOS Stream is closer to RHEL, but if I remember correctly, it’s rolling. So supposedly you as a developer could target CentOS Stream for RHEL’s NEXT major release and be ready when RHEL’s next major release gets to beta and you should be good to go.
I’ve never heard of ANYONE actually using or targetting CentOS Stream personally, but maybe there are folks. Pretty much everyone I know that was using CentOS in any kind of unofficial capacity has pivoted to Rocky or Alma or something else.
That makes complete sense, swapping CentOS to a rolling distro ruined its use case as being a parity distro with RHEL for testing, education, and stability. I can understand it making more sense for the RHEL pipeline but it’s definitely worse for the end users who were using CentOS. Thanks for the help!
Fedora I’d guess shouldn’t be affected at all. They’re fully upstream. They work on upstream, and then CentOS pulls from them. I will say that Red Hat management sometimes forces them into new code that isn’t ready for RHEL. Best example if I remember ride would be the upgrader they have. I can’t remember the name atm, but 6 months before RHEL’s 8 release we found out about it and Fedora scrambled to get it in and get it tested.
I think the application was LEAPP. I think it was this app they forced in. Kind of like they forced Docker into RHEL 7 before it was ready. LEAPP (pronounced lay-app) was going to help in place upgrades. I basically put the devs feet under the fire, because my team members were going to be the ones supporting it, and they couldn’t answer a LOT of question. Just kept saying “Well we tell customers to have to have backups.” Which yes we did, but we’d still be forced to support shit that broke, because managers didn’t understand a thing and would just tell us to fix it.
The ELI5 is Red Hat had publicly accessible source code for RHEL. They’ve removed that and only thing you see is their upstream contributions to CentOS Stream. So you can’t build a RHEL counter part at this point, because their source isn’t available.
This affects projects like Rocky Linux, Alma Linux, even Oracle Linux.
Fedora runs basically future code for CentOS Stream which is basically RHEL Next really.
Some folks, like I just read Jeff Geerling, are now deciding their code, he makes Ansible stuff, won’t be guaranteed on RHEL because they can’t publicly test it.
Red Hat is a corporate entity that justifies locking down open sources to satisfy the bottom line. I’m a disgruntled former employee though.
Edit: It’s “ELI5” not “TIL”. Changed to be “ELI5” from “TIL”.
Okay what is centOS and how does it have a RHEL counterpart.
I’m not a total Linux noob but I mostly use arch and Debian based distros, I know almost nothing about the dynamics of centOS
So Fedora is an “upstream” linux. So what that means is developers push their code directly into Fedora. Every 6 months, approximately, Fedora releases a new release. People on Fedora get that and file bugs and features to the next code.
CentOS Stream pulls from that. So they’re more stable. They don’t have the bugs that the Fedora folks hit (in theory), because it’s been solved upstream. By the time it gets to them, down stream, it’s been smoothed out.
Red Hat Enterprise Linux every once in a while will put a stake in the ground and say THIS is the code we’re going with from CentOS Stream. Make sure THIS version works, and pull in any bug fixes.
To give you a “real” kind of idea. Let’s say you have an application. We’ll call it the hiya 0.2 version. Fedora pulls in hiya 0.2. Then you keep upgrading until you get to 1.0 then 2.0 then 3.0. Fedora pulls each of those in.
CentOS Stream slowly pulls those in.
Eventually Red Hat says Hiya is what we need in RHEL! Except you’re going too fast. We want Hiya 1.0. BAM! Hiya 1.0 is going into RHEL 10. HOWEVER, since you’re faster, you’ve solved bugs in Hiya in 2.0 and 3.0. So RHEL will say well we don’t need that feature or that feature or that feature. But we DO need THAT bug fix in 2.0. So we take that bug fix and we backport it into OUR Hiya 1.1 code base. We do need THAT security fix in 3.0 to our code. So we make Hiya 1.2.
This is a VERY simplified version. And I’m not certain anymore on the interaction between CentOS Stream and RHEL. But that’s generally how it works.
IDK if I fully answered WHAT CentOS is. CentOS WAS a completely 1 to 1 compatible RHEL operating system that was started by the community and given fully 100% free. Years ago, idk maybe 5-10 at this point, Red Hat went to the CentOS devs and said, come work WITH us. Not FOR us, but WITH, but we’d pay you (somehow I’m not sure on the financial details), us so we can help you make this better. Because they saw CentOS as a good onboarding ramp to sales of subscriptions for RHEL.
Myself, and others, worried that this was the end CentOS, but they kept moving forward.
A couple years ago while I was at Red Hat, Red Hat decided that the gap between Fedora and Red Hat was too large. So they were going to pivot CentOS into CentOS Stream so that developers could build against CentOS Stream and expect it to work in RHEL. Myself and many others inside of Red Hat were VERY vocal this was a bad idea, but we didn’t matter and even my mentor told me this was a good thing for RHEL. I didn’t care, RHEL was fine, I cared about CentOS going away. So now they’re turned CentOS into their play thing. And they’re forcing people to build against CentOS Stream, which IS NOT stable RHEL.
So if I’m understanding this righf( from your explanation combined with this hackaday article i found)
https://hackaday.com/2023/06/23/et-tu-red-hat/
It used to be that Fedora was upstream for RHEL and centos was compatible with it.
Then it got changed to centOS stream which is now upstream from RHEL and and downstream from Fedora. However not every feature from CentOS Stream makes it to RHEL, but most bug fixes are, even sometimes having to backport bug fixes to older versions of the software.
Now however (since centOS no longer exists) there’s no publicly available option that’s binary compatible with RHEL without access to the RHEL Source which is now locked behind a developer account and is not licensed for redistribution.
Am I getting that right?
That’s my understanding.
The only caveat being that Rocky and Alma have stated they’re attempting to figure things out. Something similar, though I can’t remember the exact change, happened like 10 years ago and everyone thought CentOS would die.
If there’s one thing I have faith in is that open source always finds a way. It’s not just you figuring something out. It’s entire communities of insanely brilliant and PASSIONATE folks. Never underestimate the passion that drives these folks. Red Hat does.
Can you explain to me what happened with CentOS some 2-5 years back? I thought it was depreciated which is why Rocky Linux and Alma Linux came to fruition, but I don’t think I understand what CentOS Stream is. Thanks for all the information you’ve provided.
So Red Hat was getting closer and closer to CentOS. Then a few years ago, instead of being in partiy, Red Hat, and supposedly CentOS council, agreed it’d be better for CentOS to lead RHEL. This became CentOS Stream. And then the original creator of CentOS started Rocky. Alma was another distro that moved in to fill the niche of CentOS. I believe there are others as well.
CentOS Stream is closer to RHEL, but if I remember correctly, it’s rolling. So supposedly you as a developer could target CentOS Stream for RHEL’s NEXT major release and be ready when RHEL’s next major release gets to beta and you should be good to go.
I’ve never heard of ANYONE actually using or targetting CentOS Stream personally, but maybe there are folks. Pretty much everyone I know that was using CentOS in any kind of unofficial capacity has pivoted to Rocky or Alma or something else.
That makes complete sense, swapping CentOS to a rolling distro ruined its use case as being a parity distro with RHEL for testing, education, and stability. I can understand it making more sense for the RHEL pipeline but it’s definitely worse for the end users who were using CentOS. Thanks for the help!
Very nice explanation
How does this affect Fedora?
Fedora I’d guess shouldn’t be affected at all. They’re fully upstream. They work on upstream, and then CentOS pulls from them. I will say that Red Hat management sometimes forces them into new code that isn’t ready for RHEL. Best example if I remember ride would be the upgrader they have. I can’t remember the name atm, but 6 months before RHEL’s 8 release we found out about it and Fedora scrambled to get it in and get it tested.
I think the application was LEAPP. I think it was this app they forced in. Kind of like they forced Docker into RHEL 7 before it was ready. LEAPP (pronounced lay-app) was going to help in place upgrades. I basically put the devs feet under the fire, because my team members were going to be the ones supporting it, and they couldn’t answer a LOT of question. Just kept saying “Well we tell customers to have to have backups.” Which yes we did, but we’d still be forced to support shit that broke, because managers didn’t understand a thing and would just tell us to fix it.