CentOS: Why the shift to CentOS Stream is a big mistake

CentOS: Why the shift to CentOS Stream is a big mistake

Jack Wallen offers up his take on the death of CentOS as we know it.

centoshero.jpg

Image: CentOS

More about Open Source

If you follow open source enough, you might have heard the latest grumblings from the belly of the sleeping beast–Red Hat has announced it was killing CentOS as we currently know it and is replacing that beloved, highly stable server distribution with CentOS Stream. What is CentOS Stream? Put simply, it’s a rolling release version of CentOS. If you’re following along, you understand why this is a big mistake. If you’re not quite sure of that path from A to Z, let me explain.

First, a bit of education.

SEE: CentOS: A how-to guide (free PDF) (TechRepublic)

What is a rolling release?

A rolling release is a Linux distribution that is continuously updated, from top to bottom. The user-space software, the kernel, the daemons–everything is in a constant state of new. This type of release does away with the standard releases, where major updates might happen once a year and minor releases polish up after six months or so, in favor of simply keeping an installed distribution up to date at all times. 

That sounds like a pretty good idea, right? For some use cases, it might be. If you’re on a desktop, and you want to always have the most recent releases of the software you use, a rolling release might not be such a bad way to go–with a caveat.

The inherent issue with rolling releases is that the software doesn’t get nearly the testing time it would with a point release. That could lead to a lack of stability (“could” being the operative term).

Before anyone knocks an arrow and takes aim, let me explain.

I’ve used rolling releases, but only on desktops. I don’t mind having to fix the occasional issue caused by having the latest release of software. In fact, I quite like always having the latest release, so long as they’re stable releases. That’s typically what you’re getting with a rolling distribution–the latest stable release of software. Don’t let that stable tag fool you, because sometimes the newest release isn’t always the most stable. 

To that end, there are certain tools I work with where I prefer to use a version that might be a point release old. That piece of software might be crucial to my day to day production. For instance, take Audacity. I use Audacity every day. I’ve gone through periods where I’ve employed the most up-to-date version and found myself fighting against crashes and data loss. After about a year of fighting that, I decided to hang back on that release a bit and haven’t regretted that decision yet. I don’t have time to battle twitchy software–I have a lot of work to do.

Again, that battle is mostly an inconvenience on the desktop.

When dealing with a server, that battle could wind up being a war, especially if it’s a production server that your company relies on for business. 

Don’t cross the streams

There’s another, less obvious, issue to consider. At the moment, the “stream” of the CentOS lineage looks like this:

Fedora > Red Hat Enterprise Linux > CentOS

In other words, Fedora was upstream of RHEL, which was upstream of CentOS. That means CentOS benefited from changes introduced by RHEL. Fedora creates > RHEL polishes > CentOS benefits.

The end result is that CentOS was a community version of RHEL–it was RHEL without the cost.

The new lineage, however, looks more like this:

Fedora > RHEL/CentOS

In other words, both RHEL and CentOS are now downstream of Fedora, so CentOS might no longer receive changes introduced by RHEL.

Can you read between those lines? I certainly can.

From my perspective (and I could be wrong), this is a money grab by IBM. IBM no longer wants businesses to see CentOS as a viable option for servers. IBM wants Red Hat to strip away the “enterprise-ness” from CentOS. You want RHEL, you buy RHEL. 

What about smaller businesses that can’t afford a RHEL license? Are those businesses going to be okay opting for a rolling release server distribution that no longer benefits from enterprise-level additions? No. What those businesses will do is turn to the likes of Ubuntu Server.

This move will backfire for both Red Hat and IBM as both are forgetting one simple thing: Many people use CentOS as a springboard for RHEL. I’ve advised so many companies to kick the tires of CentOS before dropping the coin for RHEL. Now, I’m not so sure I’d be willing to offer that same advice.

There’s no guarantee that CentOS Stream will be the equivalent of the current release of RHEL. No one is going to waste their time using a server distribution that can’t be trusted. Although I will continue covering CentOS, chances are very slim I’ll actually use CentOS Stream as a server OS. That’s fine with me, as I tend to prefer Ubuntu Server anyway. However, at the same time, the likelihood of me suggesting CentOS as a server distribution has fallen dramatically because of this move. Although I might suggest a rolling release for a desktop, I wouldn’t dream of doing so for a server–especially one that no longer benefitted from the enterprise goodness found in RHEL. 

The future of CentOS

If IBM/Red Hat sticks to this new platform, the future of CentOS is bleak–this isn’t a case where it could benefit from a fork. Although someone could fork CentOS Stream to create a server distro with the same stability as CentOS 8, they won’t be able to inject that special flavor found in Red Hat Enterprise Linux. 

From my perspective, this is a death knell for CentOS. That might sound a bit apocalyptic, but the two main reasons why CentOS is chosen is because it’s rock solid and it benefits from RHEL–both of those are lost with CentOS Stream. 

In the end, I suspect the fallout from this decision will be a mass exodus from CentOS to Ubuntu Server. This was a big mistake. Hopefully, IBM/Red Hat will reverse course, before CentOS drowns in the stream.

Subscribe to TechRepublic’s How To Make Tech Work on YouTube for all the latest tech advice for business pros from Jack Wallen.

Also see

Source of Article