The CentOS Project Just Committed Suicide
fosspost.org
fosspost.org
The core CentOS devs who were "acquired", along with the people from other RHEL-clone projects like Scientific Linux who merged with CentOS, are being stiffed here; but arguably they should have known they were making this kind of a risk when they agreed to be acquired with a governance structure that allowed RH to overrule whatever the CentOS Board did.
The users of CentOS have no right to be upset whatsoever. They've been benefitting from millions of man-hours of engineering time RedHat have spent making RHEL without paying a penny for it. Granted this all benefitted RedHat, but that's beside the point -- if you don't have a two-way relationship with someone, you don't have any right to be upset when they change direction.
Pre-2014, all of those users should have recognized that the group making CentOS might disappear at any time, leaving them having to switch away from their current setup; post-2014, all of those users should have recognized that RedHat might change their attitude at any time, leaving them having to switch away from their current setup. They chose to take that risk because it was free. Now it's time to pay the piper.
Prior to this announcement, Red Hat promised to support CentOS 8 until 2029 (the same life cycle as RHEL 8), and I have no doubt that many organizations made the decision to invest in and deploy CentOS 8 based on that promised lifetime. With CentOS 8 effectively dead at the end of 2021, that leaves those organizations less than a year to find another solution. The fact that CentOS 7 will remain supported until 2024 (which was Red Hat's initial commitment) makes this situation even more awkward for the engineers that advocated for CentOS 8.
Now, you could argue that these organizations have been free-loading off of Red Hat and got what they paid for, but it's understandable why people are upset. If Red Hat had made this decision earlier (i.e., making CentOS 7 the last version), or made good on their promise to support CentOS 8, I doubt there would be anywhere near as much outrage.
Yes, they certainly broke their public commitment; I totally agree that they should have either announced that there would be no CentOS 8 from the beginning, or announced that CentOS 8 would be the last such beast, and after that CentOS would be stream-only. And it would be totally reasonable for the rest of us to take RedHat's other public commitments with a grain of salt from now on.
But that doesn't rise to the level of "betrayal" to me. To me, betrayal implies a stronger sense of obligation -- generally from mutual dependence. I just don't think that organizations have that much obligation to people who are consuming their loss-leader. (See also Travis-ci.)
In the public documentation describing CentOS's life cycle, CentOS 8 was described as being supported until May 31st, 2029. Upon the announcement of CentOS's change of direction, this was changed to December 31st, 2021.
You can see the commit diff here: https://wiki.centos.org/About/Product?action=diff&rev1=123&r...
If a corporation goes back on their 'word', who else can you believe? Honestly, what is this world coming to.
> it's understandable why people are upset
... because they have to pay for a product they use. very understandable, yes.
so what?
To illustrate what I mean, and this is ofcourse very subjective and dependent on my use case etc: I work on and manage hosting for RoR applications. I have a linux laptop I cannot develop on because I cannot install a recent version of ruby. Yes I can compile it manually or whatever, but that defeats the point of having distros etc.
On our hosting platform we use AWS linux, which is based of Centos. The latest version of Ruby on AWS linux is 7 years old. Our app probably wouldn't even run on it.
So we use containers. Special custom ruby images with recent versions build in a stable debian base. Now I have the problem that a.o nginx and nodejs have no recent versions available; versions that we either need for features or just because random dependecies.
So maybe the market for stable == 5+ years behind is simply not that viable anymore. Other distro's fill that demand and now centos can offer a distro for situations where you need a bit more recent versions.
It may be that your application benefits greatly from always running the latest versions of whatever technologies you use, but there are tons of use-cases for a more slow-moving platform as well.
For this use, I'd say one should use a disto focused only on running containers. Everything else is overkill and subject to "feature" creep on the server.
There is also the issue that all the container stuff is still a moving target feature-wise.
You are missing the point that it's a desired feature of CentOS distro that is targeted at servers - stability is valued more over running the latest versions of some software that isn't tested over a long period of time and may or may not have bugs.
Most people use CentOS in servers because it provided a very easy migration "upgrade" in the future to Red Hat Enterprise Linux (CentOS is a near clone of RHEL, without the Red Hat branding). Now nobody will consider it anymore because the new CentOS is not tested for stability (using tried and tested bug-free softwares) and won't provide an easy migration path to RHEL anymore.
So you would install a newer Ruby, maybe even JRuby?, and a newer Rails, but you're probably not interested in time-consumingly maintaining postfix. Or systemd. Or gcc. Or the GNU userland.
On RHEL 6 and 7, Software Collections are supposed to help with this: https://developers.redhat.com/products/softwarecollections/h...
You can install rh-ruby26 which doesn't sound too bad to me.
On RHEL 8 there are modules/appstreams (according to https://access.redhat.com/support/policy/updates/rhel8-app-s..., you can use the ruby 2.7 appstream today which will be maintained until March 2023).
Red Hat also produce container images for those who want to go that way. Of course you can use any container image you want... I'm only mentioning this because the ubi8/nginx-118 and ubi8/nodejs-14 container images seem pretty up to date to me... ;)
Are you using Amazon Linux extras? That’s what I use for current Python releases and it seems to have more recent Ruby versions:
https://aws.amazon.com/premiumsupport/knowledge-center/ec2-i...
It can if you want it to. Just like with free beer, if you doN't want to drink that beer you have to go find other beer.
Of course, Debian will not sell you support but you have places that will. I've never worked with a truly giant fleet, so I'm sure I'm missing something, but I also feel very fortunate at the moment to have always had the choice to work with Debian both personally and professionally.
In many respects I'd rather have a slow trickle of updates than the current flood of each point release. We've had lots of experience of dealing with all those changes landing at the same time breaking things.
But with CentOS 8 slated to continue in line with RHEL 8 support dates, at least there's plenty of time to see how the stream side of things goes, and to test it thoroughly.
CentOS's key attribute, and what separated it from other enterprise-focused Linux distributions, was that it is (well... was) a binary-compatible clone of RHEL, and was supported for as long as its RHEL counterpart. This allowed the user to use CentOS as a free drop-in replacement when the requirements called for RHEL (e.g., when running proprietary enterprise software that only supports RHEL).
CentOS Streams is not a binary-compatible clone of RHEL, which makes it unsuitable for people who need that specific feature.
CentOS Streams may be perfectly reliable (note that this isn't the same as being stable), but there are already many reliable and well-established Linux distributions to choose from if RHEL compatibility and length of support isn't important, and few reasons remaining to choose CentOS.
The change is CS Stream is literally the same change our (Red Hat) customers have been absorbing for years.
CentOS users have this perception that they were getting stability by being behind paying RHEL users. Think about how ridiculous that logic is.
RHEL users weren't being bombarded by ridiculous instability. RHEL Betas were never that unstable and besides Stream literally passes the RHEL hatting tests.
See more #6/#7 here: http://crunchtools.com/before-you-get-mad-about-the-centos-s...
So many people were consuming CentOS without a fuzzy clue to how RHEL works. Makes it all the more frautrsting for people who get a paycheck from RHEL.
I really hope these stable OS just die. Some debt could be avoided if RHEL/CentOS didn't exist.
Edit: There's also Rocky Linux already : https://news.itsfoss.com/rocky-linux-announcement/
However the problem has always been that between RHEL being branched from Fedora and the first RHEL GA being released there was a gap - a really huge gap actually of about 18 months or more. During this time we released to the public one alpha, and one beta to partners, but essentially development was closed off to anyone outside Red Hat. During this time we are writing documentation, QA-ing extensively, fixing bugs found by partners. Plus partners and ISVs actually ask for a 6 month delay before GA which they spend porting their software and device drivers.
CentOS Stream is probably a poor name, but it fills that huge gap. Now CentOS Stream releases between Fedora and RHEL, and in front of every RHEL minor release, will be available to everyone, and we'll be accepting contributions from everyone too.
Dropping CentOS Linux (the rebuild) is kind of separate from all this. It looks like it's going to continue as a community project as it was before 2014 (https://rockylinux.org/) which may be better in the end because the community will be more aligned to the success of the rebuild.
Disclosure: I work at Red Hat.
If it's some common LAMP stack thing duplicating exactly the same thing on debian+nginx(or apache2)+php7.3+mariadb could be trivially easy.
For organizations that have things like ansible set up to auto provision things where the configuration files live on a centos system, obviously locations and naming will need to be changed.
there are also certain weird (usually closed source binary) applications shipped by software vendors for specific vertical industries, which ONLY exist in a form for RHEL or CentOS. It'll be interesting to see how that works out. The vendor won't support running it on debian or ubuntu server or anything else.
I would say that out of all the possible distros of Linux, RHEL is by far the one that I see with the most rare, weird, expensive paid software that gets developed for it, due to its extensive use in government and fortune 100 type environments. In which case I don't think much will really change since the same customers will go right on buying RHEL paid yearly licenses.
which is in no way redhat's, or centos's fault.
The actual install of linux is generally pretty straight forward but to do it minimum downtime you need spare boxes to build with the new distro (preferably 1 for each old box, but you can get away with less, its just takes more time), install your software on, and then test. You also need sysadmins and testers to do the work, and developers to fix any issues (normally around library versions etc). Then you have the risk that something was missed in the install & testing and causes issues in prod a new distro will not be 100% bug compatible with your old one so you will find problems.
And thats assuming you have the skills to install the new distro, how to set it up as required, how to reinstall the software (its amazing how much in house software doesn't have install docs or even source code), and the skills to run it 24/7. If not factor in training and self-learning time for everyone.
Its all doable, but its probably months of work and a bunch of risk just to get back to where you were on a new distro, which makes no difference to your customers at all.
Theres a reason companies tend not to switch very often.