8 ms·
CentOS Linux 8 Reaches End-of-Life
- Art9681 5y agoRed 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.
- mroche 5y agoSlight correction: The Developer Subscription for Individuals provides 16 system entitlements to RHEL for use in development and production. https://developers.redhat.com/register https://developers.redhat.com/register https://developers.redhat.com/terms-and-conditions https://developers.redhat.com/terms-and-conditions
- JohnTHaller 5y agoFor the affected, you can move to the free, open source, non-profit Alma Linux. It's 1:1 with RHEL. https://almalinux.org/ https://almalinux.org/ You can also get extended support for CentOS 7 and 8 from CloudLinux.
- deleted 5y ago[deleted]
- sh4un 5y agoWhat a rug pull. This is something expected from one man distros but it suck for everyone to be tossed into what now pile.
- JKCalhoun 5y agoWas that kind of fast?
- agsnu 5y agoNormally 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.
- chasil 5y agoConverting 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.
- rubyist5eva 5y agoI can vouch for Alma linux personally, we switched and it was painless.
- bityard 5y ago> 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.
- yjftsjthsd-h 5y ago> 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.
- rubyist5eva 5y agoIt was announced a year in advance, if that’s a rug pull your org has bigger problems.
- yjftsjthsd-h 5y agoEL 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.
- pfranz 5y agoMaybe 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.
- rubyist5eva 5y agoIf 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.
- wolverine876 5y agoMany organizations, especially larger ones, have investments with much longer time cycles than 1 year.
- sheepdestroyer 5y agoIt 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.
- throw0101a 5y ago> The argument made is that, overall, there should be less bug in Centos Stream than in Centos of old […] The bug level or not of CentOS was not its selling point, but compatibility: > Rocky Linux is an open-source enterprise operating system designed to be 100% bug-for-bug compatible with Red Hat Enterprise Linux®. * https://rockylinux.org https://rockylinux.org * https://en.wikipedia.org/wiki/Bug_compatibility https://en.wikipedia.org/wiki/Bug_compatibility 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'.
- sheepdestroyer 5y agoCan 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. What am I missing?
- someperson 5y agoCentOS 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.
- defanor 5y agoSuch 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.
- someperson 5y agoFor 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.
- deadbunny 5y agos/RedHat/IBM
- yjftsjthsd-h 5y agoWhen 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.
- deleted 5y ago[deleted]
- don-code 5y agoHaving 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. What have others been migrating to?
- second--shift 5y agoI’ve been using Fedora server to good success. 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.
- Kostic 5y agoKubernetes and managed AWS services for production workloads. Fedora Workstation for everything else.
- csdvrx 5y agoFunny, 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
- tehbeard 5y ago> (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.
- rootbear 5y agoMy 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.
- orev 5y agoAlmaLinux also offers support, and if you’re in really dire need so does Oracle.
- SkipperCat 5y agoThis 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.
- dralley 5y ago> 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.
- bastardoperator 5y agoThis 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.
- mulmen 5y agoWriting 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?