For those that missed it: When CentOS8 was released in September 2019 it had an end-of-life on May 31st 2029. So maintenance/security updates until that date, and regular updates until May 1st 2024.
Then in December 2020, RedHat announced the end-of-life was moved back to December 2021.
Yes: changing the support lifetime of the operating system from 10 years to 1 year.
When this was announced, it was loudly claimed by everyone involved that Red Hat had been planning this before the IBM acquisition. Obviously I have no way of verifying that, but I also have no particular reason to disbelieve them either. Take with grain of salt.
Having unified my work and homelab environments on RHEL/CentOS for north of ten years, I took the opportunity to try out some new options.
We've begun the process of switching out from CentOS to Amazon Linux at work, and the jump actually hasn't been difficult - the tooling is largely the same, boot times are vastly improved (I don't really know what Amazon does under the hood to their Linux distro, but it does show), and with minor changes to some Ansible bootstrap code, we're up and running. Besides, most everything is containers nowadays.
My homelab has come full circle - it started out on Debian back in the 2000s (it was the only distro left with a floppy installer, and I had a few Pentium-class laptops). These days it's a shelf full of single-board computers, and I've found the support for Debian types like Raspbian/Armbian to be _much_ improved over CentOS, whose ARM32 special interest group was but a handful of people volunteering their spare time.
> (I don't really know what Amazon does under the hood to their Linux distro, but it does show)
If it's on AWS hardware I assume they've extremely trimmed down any and all kernel gubbins that isn't related to the hardware they run on?
As for our migration plans... Well luckily we're on CentOS 7, so I have a year or so more to figure that one out and see what way the wind blows. Timings good enough to do a hardware refresh at the same time.
Kinda worried for Ansible to be completely honest. I've grown to love it for automating a bunch of sysadmin tasks and managing some stuff at work and my own kit, It's been a nice way to spin up dev boxes w/o going down the whole Kube/Container stack when a VM suffices. Don't really trust RedHat anymore with it if IBM is pushing it's corporate culture down on them.
I'm sure it trims many things down to a general VM baseline, but they can't trim all the different hypervisor hardware support.
Unbeknownst to many, you can run AmazonLinux on-prem[0], AWS distributes their image on a public pages (we use this to allow developers to have the same image locally and on the cloud).
Additionally, you can export any AMI to a S3 bucket[1] and download that for local use.
For Amazon Linux, the recipes are slightly different for the AMI versus on-Prem. For the AMI we cut out a bunch of things from the initramfs that you don’t typically need in a cloud environment saving a further second (ish) of launch time. This config is in the Dracula-config-ec2 package.
For on-Prem you may actually use this, so we don’t build it in there.
My home servers only last about a year or two before i need to tinker & change things. I don’t need 5 yrs of lts support in the OS - 2 yrs of fedora is fine.
We use rhel at work & have always paid for the licenses.
My home lab is on mostly Fedora CoreOS, with a few Fedora Server.
I've been using Fedora for years with good success and these days everything runs in a container, so rpm-ostree and a mostly read-only filesystem simplifies maintenance.
If Fedora is too "bleeding edge", but you want to stay in the RHEL ecosystem, you might try CentOS Stream for yourself to decide whether it feels solid enough to rollout, it is the direction Red Hat wants folks to lean toward, though not necessarily the one many are interested in taking.
Funny, I went the other way with debian and ubuntu as they are close-ish enough to have a similar setup in prod and on my laptop with wsl (and now I'm evaluating PopOS)
Your homelab experiences with SBC seems to validate my position.
The only use I have for CentOS is to compile Ventoy
My group at NASA/Goddard, which was almost all CentOS 7, is moving to a mix of RHEL and Ubuntu (with paid support). This has, of course, increased our costs, but the agency was under some pressure to only run OSs that had formal corporate support.
This whole process was a little chaotic, but I'm happy with it. I like that CentOS will be a closer downstream from Fedora. CentOS was always too far behind in Kernel and package version compared to other distros.
We tried using Fedora as our main distro, but it just moved too fast. We never got on the Ubuntu wagon, mostly because we were so comfortable in the RedHat world.
> This whole process was a little chaotic, but I'm happy with it. I like that CentOS will be a closer downstream from Fedora. CentOS was always too far behind in Kernel and package version compared to other distros.
To be clear, CentOS Stream won't get any updates that RHEL doesn't get (including kernel updates), it'll just get them a few months sooner.
But the more streamlined and open development process may allow RHEL (+derivatives) to move a little faster, and get bugs fixed sooner. It's still too early to tell though.
It was announced a while back and there is an easy migration procedure to Centos Stream 8.
The argument made is that, overall, there should be less bugs in Centos Stream than in Centos of old because bug fixes are there first now and coming faster than ever was possible.
If I want a better balance between stability and longevity I run Ubuntu/Debian, which have LTS releases every two years: code that isn't too old, nor 'too new'.
Please reconsider recommending Rocky. If you dive in a bit you'd probably find their attitude towards the community and community participation really weird. They seem to have pushed most of their resources towards better marketing instead of making a better distribution.
Here's an example: about a half year ago the host of linuxunplugged.com (a pretty popular podcast IMO) invited representatives both from Alma Linux and from Rocky Linux. The Alma guy was happy to be on the show and showed up a few hours before it started to chat with community members. The Rocky guy asked if any other distributions will be there, and then sent a passive-aggressive email where he declined to participate because "we're not interested in being compared against other distributions", or something to that extent.
This small example pretty much sums up their entire attitude.
FWIW, I've been using https://almalinux.org for the past few months on a couple of dozen servers and it's been smooth sailing.
(I've also been using Oracle Linux and it too worked fine. If only it were not Oracle…)
Can you explain in what case being exactly bug for bug compatible with a given set of RedHat rpms (which are also in flux all the time with regular updates) is actually more important to you than having less bugs in total?
I understand that if your goal was to use CentOS to validate a specific and highly critical workload for eventually running in production on Redhat systems (taking into account the version lock dance to make sure that you indeed have the exact same package versions on both environments, meaning a lot more hassle and delays in bug fixes and security updates that simply following the regulars updates), then Rocky/Alma/AnyRebuild will be better for you.
If your goal was already to run production on CentOS, with frequent updates for security, the theory would be that you will be even better served by CentOS Stream. My take is that it is the most popular case.
CentOS Stream is a "rolling release" that's serves a specific purpose of being bleeding-edge test environment to test new changes for future integration into RedHat's stable releases.
Many high-availability workloads require a fixed operating-system baseline, where the only changes are security updates and high-priority bug fixes.
And even these changes may need to be triaged to determine if the updates are even worth risking uptime.
One example would be a hospital network with medical equipment workstations and backend servers. You don't want your ultrasound or key-hole surgery not working because a CentOS Stream update bug. Fixed operating baselines are important for many users.
On the linux front, I've used a mixture of RHEL/CentOS/Ubuntu for about the last 10-15 years, so the whole CentOS thing was a bit of an annoyance, but I gave the CentOS Stream side of things a go.
And I'd probably describe it as less of a "bleeding-edge" rolling release, more a "boring-edge" rolling release. Yes it's a rolling release, but packages are going in as a final shakedown before release into RHEL, so it's really quite far away from experimental.
And I've not really noticed any material difference from pre-stream. I'm still able to use my CentOS boxes in the same way as I did before - in some cases as build boxes for things to be deployed onto RHEL boxes.
(And, to be honest, those example use cases are probably places where I would be seeking to use a commercially supported distribution, rather than a community supported one. Albeit a community supported distribution that copies/replicates a commercially supported distribution.)
From RedHat's announcement blog and Centos website: CentOS Stream "a continuously delivered distribution that tracks just ahead of Red Hat Enterprise Linux".
And indeed, I have read that all packages currently going into Stream 8 follow exactly the same testing and validation procedures than for entering Redhat Proper.
But of course, this holds true only for released RedHat versions.
Meaning that Stream 8, is currently just ahead of RedHat 8.5 and will soon start to incorporate changes planned for 8.6 (so nothing like a "bleeding-edge test environment to test new changes" as you put it).
As for Stream 9 which was release recently, it is indeed the stabilisation socle based on fedora 34 that will eventually become RedHat 9. Once RedHat 9 released, Stream 9 branch will be stabilized and once again be "just ahead" of the impending RedHat 9 rpms.
In any case, I am not sure that hospitals should be running/updating self supported OS on surgical equipments without proper testing anyway.
> As for Stream 9 which was release recently, it is indeed the stabilisation socle based on fedora 34 that will eventually become RedHat 9. Once RedHat 9 released, Stream 9 branch will be stabilized and once again be "just ahead" of the impending RedHat 9 rpms.
Stream 9 is currently tracking RHEL 9.0, it shifted from the 9.0 Beta back around August. As we approach the ~May release for RHEL 9.0 GA, Stream 9 will start tracking RHEL 9.1 changes.
A key difference between Stream 8 and Stream 9 is the way the distribution is built. Stream 8 is a technically another rebuild project by the CentOS team, but one that rebuilds newer branch packages from RHEL engineering. In Stream 9, RHEL engineers are doing the builds themselves and are directly involved in the entire process.
There's a possibility that Stream 8 may adopt the Stream 9 workflow, but I'm not certain. With an EOL of 2024, it might not be considered a priority.
It would be the medical equipment manufacturer who would choose CentOS. And I'd argue CentOS was a fine choice given its track record and RedHat sponsorship.
Don't those installations tend to use a commercially supported distribution (RHEL in this particular case)? I've never worked on anything similar but find it really hard to believe you'd go around installing a "community enterprise" distribution on critical infrastructure.
Such expectations depend on heuristics; to me it didn't look good after RedHat started slowly eating CentOS in 2014, and was eaten by IBM in 2018. Actually even before that, dependence on a single commercial company was a red flag: cancelling products is something that commercial companies do regularly.
It was a little fast, but that's not why it was a rug pull. It was a rug pull because IBM retroactively shortened its lifespan after a bunch of people had already started using it in production.
Saw it coming a mile away when CentOS was acquired. You don’t acquire your free competitor to keep them around exactly as is simply out of the goodness of one’s heart.
Maybe it wasn’t but I don’t see how any business acquires their free competitor and then keeps it around to cannibalize their own potential market. Just doesn’t make any sense. It was inevitable - initially intentional or not. It’s just capitalism.
They probably didn’t expect as much backlash to Stream and expected people to just use that or buy RHEL. I’m sure the amount of users they expected to lose to new forks was part of their risk analysis, they just blew it IMO.
Converting to Rocky, Alma, or Oracle Linux will extend support to 2029 with minimal changes to the installed system. Most CentOS 8 users would likely have done this by now.
Red Hat also offered a conversion procedure the last time I looked, but it replaced every installed RPM with equivalents from its own repositories. This is quite violent, and it would be far from my first choice for a critical system.
> but it replaced every installed RPM with equivalents from its own repositories. This is quite violent
The whole point of CentOS was to be 100% compatible with RHEL, right down to the packages and binaries. For literally this kind of scenario. I don't see how that's "violent." I'm also not sure how you can expect to convert from one distro to the other without replacing all (or at least most) of the packages.
The code is the same, yes. The "binaries" are not, necessarily. The build environment isn't exactly the same and there have been bugs experienced in CentOS that weren't in RHEL and vice versa.
So it was never 100% compatible, more like 99.5%. The exceptions are rare edge cases but they do exist.
> I'm also not sure how you can expect to convert from one distro to the other without replacing all (or at least most) of the packages.
The thing is, they were almost exactly the same distro, so in any meaningful sense you could switch from one to the other by switching the release files, some yum support stuff, I think the kernel?, and some miscellaneous branding if you cared. But 99% of packages were functionally the same, so yeah I don't see replacement being a problem per se, but it also didn't seem very necessary.
Normally RHEL/CentOS releases are supported for 10y - CentOS 6 was 2010-2020, CentOS 7 is 2014-2024. 8 was released in 2019 so you might expect it to be supported through 2029, a year ago they announced it would be brought forward by 8 years.
EL variants are most popular in companies that consider project turn around to start at the six-month mark for fast work. It's popular precisely because you can settle on one version of one distribution and use it for literally a decade. So yes, one year is a rug pull.
Maybe I've always worked at larger employers than most, but a one year surprise to reevaluate and transition your operating system sounds incredibly disruptive when the original promise was support through 2029 and the "successor" is very different.
In my experience major updates like this are discussed annually with eval, testing, and milestones set weeks and months apart. The transitions are often pushed a year or more when issues come up. Resources are dedicated to all of this.
It sounds like there are a lot of similar options with relatively easy transitions (away from Red Hat), but you still have to choose who you trust going forward and carryout the transition.
If you’re relying on the free offering that’s competitive directly with their enterprise offering and your organization is so large that it’s going to take over a year to switch - you should have probably been paying for RHEL to begin with. My midsize outfit that was running from top to bottom on centos did everything you described over the course of about 2 months to switch to Alma Linux. Hundreds of servers managed by an amount of guys I can count on one hand.
Sorry not sorry, but large outfits expecting to coast on a free offering don’t get sympathy from me.
In SV it's rare to pay for commercial OS or other support due to the scale. I have never worked anywhere that paid for anything, whether it's RHEL or Cloudera or whatever, unless it's only available as SaaS/Cloud.
That's why working at FB or Google is like going back in time as far as monitoring UIs, etc.
Some of the clever large companies took advantage of "site-wide support licenses." For example, Netflix paid MySQL AB $40,000/year for MySQL site support so they didn't have to hire any MySQL DBAs. Just keep filing support tickets. :)
Writing was on the wall in 2014 when Red Hat acquired CentOS. If Red Hat wanted there to be a free self-supported RHEL they would just offer RHEL without support. Does anyone remember the huge delays in CentOS releases while they stripped out RHEL branding and updated build infrastructure? I think CentOS 6 was like a year behind RHEL 6? Red Hat hasn’t wanted a free RHEL since what, 4.0?
This is why I switched to Debian for production a long time ago. I'm not dealing with RH/IBM shenanigans let alone having to migrate everything to a new OS.
Red Hat gives up to 10 free licenses of RHEL for personal use. If you have a home lab or want to learn an enterprise distro of Linux its a pretty good deal.
Then in December 2020, RedHat announced the end-of-life was moved back to December 2021.
Yes: changing the support lifetime of the operating system from 10 years to 1 year.