[HN Gopher] CentOS Linux 8 Reaches End-of-Life
___________________________________________________________________
CentOS Linux 8 Reaches End-of-Life
Author : kungfudoi
Score : 45 points
Date : 2021-12-31 16:29 UTC (6 hours ago)
(HTM) web link (www.phoronix.com)
(TXT) w3m dump (www.phoronix.com)
| sh4un wrote:
| What a rug pull. This is something expected from one man distros
| but it suck for everyone to be tossed into what now pile.
| rubyist5eva wrote:
| It was announced a year in advance, if that's a rug pull your
| org has bigger problems.
| pfranz wrote:
| 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.
| rubyist5eva wrote:
| 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.
| wolverine876 wrote:
| Many organizations, especially larger ones, have investments
| with much longer time cycles than 1 year.
| rubyist5eva wrote:
| Then the probably have the budget to pay for RHEL. Sorry
| not sorry.
| redis_mlc wrote:
| yjftsjthsd-h wrote:
| 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.
| JKCalhoun wrote:
| Was that kind of fast?
| chasil wrote:
| 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.
| bityard wrote:
| > 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 wrote:
| > 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 wrote:
| I can vouch for Alma linux personally, we switched and it
| was painless.
| josephcsible wrote:
| 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.
| rubyist5eva wrote:
| 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.
| yjftsjthsd-h wrote:
| > Saw it coming a mile away when CentOS was acquired.
|
| That was 2014; if this was the original plan, they took
| their sweet time with it.
| rubyist5eva wrote:
| 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.
| 5e92cb50239222b wrote:
| And they got at least two new competitors, three if you
| count Oracle. You really think they did not foresee that?
| rubyist5eva wrote:
| 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.
| agsnu wrote:
| 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.
| defanor wrote:
| 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.
| sheepdestroyer wrote:
| 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.
| throw0101a wrote:
| > _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(r)._
|
| * https://rockylinux.org
|
| * 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'.
| 5e92cb50239222b wrote:
| 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...)
| sheepdestroyer wrote:
| 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.
|
| What am I missing?
| someperson wrote:
| 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.
| sheepdestroyer wrote:
| But this is not the case as I understand it.
|
| 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.
| mroche wrote:
| > 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.
| someperson wrote:
| 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.
| gertrunde wrote:
| 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.)
| 5e92cb50239222b wrote:
| 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.
| bastardoperator wrote:
| 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.
| someperson wrote:
| 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.
| deadbunny wrote:
| s/RedHat/IBM
| yjftsjthsd-h wrote:
| 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.
| [deleted]
| don-code wrote:
| 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.
|
| What have others been migrating to?
| csdvrx wrote:
| 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
| tehbeard wrote:
| > (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.
| InvaderFizz wrote:
| 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.
|
| 0: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/amazon
| -l...
|
| 1: https://docs.aws.amazon.com/vm-
| import/latest/userguide/vmexp...
| Kostic wrote:
| Kubernetes and managed AWS services for production workloads.
| Fedora Workstation for everything else.
| second--shift wrote:
| I'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.
| SkipperCat wrote:
| 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.
| JohnTHaller wrote:
| For the affected, you can move to the free, open source, non-
| profit Alma Linux. It's 1:1 with RHEL. https://almalinux.org/
|
| You can also get extended support for CentOS 7 and 8 from
| CloudLinux.
| [deleted]
| rootbear wrote:
| 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.
| mulmen wrote:
| 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?
___________________________________________________________________
(page generated 2021-12-31 23:02 UTC)