Why CentOS Stream is Important
A bit of time has passed since Red Hat infamously killed off CentOS, and people often ask if my advice has changed. The problem is... I can't make that video without at least part of it being about why I don't consider CentOS Stream to be a proper replacement for CentOS; but that's all I'd have time to cram in. Which means I'd be giving you reasons not to like it without talking about why Stream is really, really important; and why if you liked CentOS you should really like Stream. So that's what I'm doing here. It's time for Stream to step out from the shadow of CentOS... which would be a lot easier if they hadn't given it the same bloomin' name!
First up: the basics. What is CentOS Stream, how does it relate to CentOS, and why do people start twitching when you mention it? CentOS is (or was) a free rebuild of Red Hat Enterprise Linux. It was built from the RHEL source code and to all intents and purposes it was the same thing. It was like the official free version and RHEL was the paid version that came with enterprise support. When CentOS 8 was released it was joined by a new distribution called CentOS Stream.
To differentiate, original CentOS adopted the name CentOS Linux. Unlike the original CentOS, Stream was not downstream of Red Hat. It was upstream, meaning it was earlier in the development process and its code would make its way into an official RHEL release later on. New versions were released daily and Red Hat development was out in the open. This was good. Everyone was happy. They had a paid version, a free version, and a preview version.
Listen to Destination Linux podcast online.
Then Red Hat (the company) pulled the plug on CentOS AKA CentOS Linux. They announced this just one year into its promised 10-year lifespan and said "You've got one year left, then we're done." To users of CentOS they basically said "Feel free to play with CentOS Stream, but move your production workloads to RHEL - the paid version." This wasn't popular. People were understandably annoyed at Red Hat for promising 10 years of stable CentOS 8 and then suddenly ripping it out and telling them to buy RHEL, instead. You can imagine the scenarios. There were lots of them. Red Hat was asked for answers. What do we do? Red Hat said... "Yeah, that's a good point. Um... give us a couple of months and we'll get back to you." Seriously. It seemed like they hadn't thought it through before announcing it and then went to make a plan after the fact. In the meantime they left a communications vacuum and into that vacuum stepped some well-intentioned people (including some Red Hat employees) who started telling others they should just use CentOS Stream. The problem is that CentOS users didn't pick CentOS for fast iterations.
They picked it for long-term stability. It's meant to be boring and reliable. They're not the type to take risks with their production systems and now you're telling them to run production off a rolling beta distro? Which it's not... but practically speaking to CentOS users it may as well be. As I'm sure you're furiously typing in the comments: it's not a beta, it's continuous integration. OK. Stream is basically just the live state of RHEL. Take RHEL 9. As I record this it's at version 9.0. The next version will be 9.1. CentOS Stream 9 is at this moment the equivalent of something like RHEL nine dot a half, and tomorrow it will be nine dot a little bit more than a half. The thing is: when you read about continuous integration it's often referenced in the context of CI/CD, where "CI" is Continuous Integration, and the "CD" is either Continuous Delivery or Continuous Deployment.
That's the fly in the ointment. CentOS Stream might be continuous integration from a development perspective, but traditional CentOS users are not doing continuous deployment on their operating system. If your drop-in CentOS replacement expects them to change the lifecycle within which they manage their datacentre then it's not a drop-in replacement. If they use it like CentOS they're deploying it periodically and they want version numbers to validate and test against. They want to know which versions their software vendors have approved. CentOS Stream doesn't do this.
There are no point releases. It changes every day. Throw in the fact that it hasn#t been approved for official deployment in RHEL yet and Red Hat will not support it... What do you call software that is available to the community now in unsupported form but won't be supported by the vendor for a few more months, whereupon it gets re-released as an official new version after there's been time for community feedback and maybe some tweaking? It may not be developed as a beta, but the CentOS users this certainly looks like one. I know some of you will disagree. Some of you will be running it in production. That's cool.
My take on this is very simple. Red Hat creates CentOS Stream. Red Hat provides paid support for Linux. Linux that is built from CentOS Stream. Red Hat will not support CentOS Stream, even if you pay them. They are literally the best-placed people in the world to do so, and delivering this support is a core business activity for them, but they won't do it. They tell you to use RHEL. If they're not willing to support it in production I'm not going to flog that horse. There are plenty of other options, including Red Hat Enterprise Linux. CentOS wasn't supported directly but it was the same code as RHEL, which was supported, and many vendors accepted that. CentOS Stream has no supported equivalent. If someday they decide they'll support both releases then I'll recommend both releases for production. That's my take. It's a shame I'm even having to say this to be honest.
I'm only saying it because Red Hat made me. By not communicating, by appearing to not have a plan Red Hat allowed CentOS Stream to be positioned as a replacement for CentOS by default - causing these conversations. It was a square peg that people tried to wedge into a round hole and its reputation took a beating because of it. But what if you took a square peg and you put it into a square hole? Let's go back to the start. CentOS Stream did not suddenly appear in the gap left by CentOS Linux. Remember, they co-existed for a time. Clearly it had a purpose and replacing a downstream distro wasn't it. That purpose hasn't gone anywhere. In fact it is now more important than ever.
CentOS Stream did a couple of things. One is it brought Red Hat development into the open so you can see what's coming down the pipeline. This is really useful if you're developing for Red Hat Enterprise Linux because you've got a preview of what your software will be running on. It's useful to test your business systems against for issues so you can spot them before they reach production, and potentially get those issues fixed before the final release; whether it be a Red Hat issue or an application issue. If you want to build your own Red Hat spin-off you can now take code from CentOS Stream if you feel it's ready, rather than waiting for Red Hat to approve the next Enterprise Linux release; which means you can get bug fixes faster than Red Hat's own customers.
Remember, this is not untested. It's being tested by the community... sure. It hasn't had as much testing as Red Hat enterprise Linux and its CentOS-like derivatives will have had... OK. But if it's in Stream it has already cleared Red Hat's internal testing. So if anything they think it should have fewer bugs than the current RHEL release. It might just have different bugs, is the risk. But here's the really, really important bit. CentOS Stream provides a way to contribute upstream to RHEL. If you're not sure how that applies to you, let's jump forward in time again and you'll see why this matters. We're back in the future now and CentOS is gone. In its place we have community-focused alternatives in the form of AlmaLinux and Rocky Linux.
We also have Oracle Linux, which already existed but seems to want to compete more with Red Hat than fill the community gap left by CentOS. And we have Red Hat Enterprise Linux itself which now has a limited-use free licence because Red hat eventually came up with a plan. Some look at this and see fragmentation. I see resilience. If I deploy Rocky Linux and suddenly the plug gets pulled I can switch my workloads to AlmaLinux in minutes using a script. They are all compatible and interchangeable. The ecosystem is now more resilient than ever before. It also brings diversity... such as it is with a bunch of clones.
Read also: 4K Gaming on a Thin Laptop
Red Hat have an extensive ecosystem of enterprise products that would require several videos to cover. Oracle have an alternative kernel tuned for their cloud and database workloads. AlmaLinux can be paired with live patching services from TuxCare from their corporate sponsor, CloudLinux. Rocky Linux can be paired with containerisation and security services from their corporate sponsor, CIQ. You've got this really interesting dynamic where they're all the same but each party has a unique take on the Enterprise Linux platform and different special interest groups. But with all of the others stemming from RHEL, what happens when there's a problem? Let's say a Rocky user finds a bug. They raise a support call with CIQ. They see the bug. They understand how to fix it... but they can't.
If they fix it in Rocky they break compatibility. They can't be the same as RHEL if they're making changes to the code. It's not bug-for-bug compatible if they're fixing the bugs. Sometimes software relies on these bugs. It's weird, but true. There could be an application that assumes the presence of that bug which means it would work on Red Hat but fall over on Rocky. In times gone by Rocky would have had to jump up and down and try to get Red hat's attention, then try to convince them to drop what they were doing for their own customers in order to fix a problem that was affecting someone else's customer. This would not have been ideal for Rocky. Now, though; we have CentOS Stream. Rocky doesn't need to beg Red Hat. If they've got the fix they can submit it to CentOS Stream. From CentOS Stream it will flow into RHEL and from RHEL it will flow into Rocky.
So they get their fix and everyone's happy. And when I say "everyone"... I mean "everyone"; because that same fix is going to flow into Oracle and AlmaLinux as well. And when an AlmaLinux user finds a bug and they get help from TuxCare and they find a fix they can submit it to CentOS Stream and Rocky gets it, too. Same for Oracle. Same for RHEL. This is why CentOS Stream is important. If you use any distribution on the screen or if you use any distribution based on any distribution on the screen then CentOS Stream is the glue that holds it all together.
It's not a part-baked free version of Red Hat. It's the conduit through which the entire ecosystem grows and improves. Every user of every distro is benefiting all the others and strengthening the collective because of CentOS Stream. I don't use CentOS Stream in production, but it's not because I think it sucks. I just think the other ones derived from it are better options for that particular use; but they wouldn't be as good as they are without CentOS Stream... and this channel wouldn't be as good as it is without your support! Every like and every comment is appreciated. If you're interested in learning more about the services that I mentioned that sit nicely alongside AlmaLinux and Rocky Linux then click here to learn about one of TuxCare's live patching products, and click here to learn about CIQ's vision for Enterprise Linux security with Rocky. See you there!
Read More:
https://techtips.theobloggers.com/17780833/why-centos-stream-is-important
https://telegra.ph/An-Affordable-Managed-Switch-to-Learn-Networking-09-05