CentOS Reminds Everyone End-Of-Life Is Coming For CentOS Linux 7, CentOS Stream 8

[mSparks]

you may not get the latest and greatest from the community depending on how often they update those repos (I genuinely don't know their cadence, I don't admin any Oracle platforms [yet]).

"latest and greatest" is pretty much tangential to shooting for maximum uptime and compatibility, like RHEL 9.1 is still back on kernel version 5.14 isnt it?

wish i had an easier way to check that, especially glibc versions which is what tends to explode stuff, every now and again I try and find a quick reference for what glibc versions distributions are based on, I regularly get hit by support requests from people on older glibc than OL8.

[mroche]

Their servers have always been responsive for updates (perhaps more so than centos ever was tbh), their artwork is clear and unobtrusive. other than its just a reasonably well supported redhat clone, in fact they go one further, because they also have an "Unbreakable Enterprise Kernel" build.

I actually suspect OL may have played a role in IBM ending up canning centos, if behind the scenes they were losing to Oracle anyway.

Oracle does add their own kernel, but I can't remember if they also modify/patch some other packages separately from RHEL. So there may not be 1:1 compatibility. They also host their own copies of EPEL IIRC, so you may not get the latest and greatest from the community depending on how often they update those repos (I genuinely don't know their cadence, I don't admin any Oracle platforms [yet]).

As for OL... I had a number of customer calls that were looking to replace OL with RHEL even for their Oracle workloads because they were tired of dealing with two different distributions and they preferred going to the source deliverer. Among other internal and project requirements they may have had. CentOS didn't really come up in conversation a whole lot because if you're getting OL for free, why use a second free rebuild?

Cheers,
Mike

[elatllat]

I'm betting on Alma.

[ClosedSource]

The point I was making was that for a resource constrained company of our size it's a massive undertaking that ultimately steals a lot of effort from revenue generation. Yes we have been working on this, fyi we are moving everything to debian,but it's no small feat.
Rocky is still unproven, RHEL licenses will liquidate us.

I suppose there is always oracle.

[Chugworth]

Then you're gonna hub fun seeing how Canonical is phasing out ZFS for desktop (and, let me predict, soon for servers as well)

No, I expect they'll keep providing the ZFS module for both the desktop and server releases for the foreseeable future. It takes very little effort for them to compile the module along with the kernel, and it provides a major feature that lots of people use. What they are removing is the option to install Ubuntu Desktop on ZFS. That takes quite a bit of effort for them to maintain, and it always confused me why they went that route to begin with. ZFS is excellent for large storage devices but I wouldn't consider it to be ideal for a desktop OS.

Besides, even if Ubuntu was to stop distributing the pre-compiled ZFS module for their future versions then it would just be a matter of using the ZFS DKMS module instead.

[jorgepl]

I'm glad I never standardized my systems around CentOS. I've always preferred Debian over Red Hat. For years I used Debian, but within the past several years I gradually switched over to Ubuntu Server since that's the best way to get ZFS. These days my standard work server runs Ubuntu on two mirrored drives, and the additional drives are ZFS. The host OS does very little, and most of the work takes place in either LXC or KVM containers which all live on the ZFS drives. Backups are just a matter of taking a snapshot and using ZFS send/receive.

Then you're gonna hub fun seeing how Canonical is phasing out ZFS for desktop (and, let me predict, soon for servers as well)

[jorgepl]

Migrating from CentOS 7 to CentOS 8 would be as hard as migrating to RHEL, AlmaLinux, Rocky Linux. Those who are surprised by the end of life of CentOS 7 simply didn't get ready for any migration.
Not sure if suggesting Debian with 3+2 years of support to someone who has difficulties to timely upgrade an OS with 10 years of support makes sense, but why not.

Debian would actually be worse than CentOS Stream in this regard...

[jorgepl]

I went with AlmaLinux as I have a better feeling with it then with Rocky and migration worked well.

Alma seems to better play with the community and also seems to be faster in releasing the stuff.

[jorgepl]

The point I was making was that for a resource constrained company of our size it's a massive undertaking that ultimately steals a lot of effort from revenue generation. Yes we have been working on this, fyi we are moving everything to debian,but it's no small feat.
Rocky is still unproven, RHEL licenses will liquidate us.

What? You're moving to Debian that has full support for just 3 years, lts for 5 years for a limited set of packages and architectures, and only for a really small set of packages, 10 years of updates with no further ABI compatibility guarantees instead of switching to Alma/Rocky or CentOS Stream 9?

That's probably not the smartest move. You gain nothing.

[slalomsk8er]

For the record upgrading every 3 years is about in line with our current schedules. And allows a nice long period of stability with enough time to test and make changes to support newer OS's and all the runtime versions and quirks they come with.

I will say I do appreciate the recommendations on AlmaLinux, thank you for that.

The big changes are things like orchestration, which needs to have a LOT of changes, and obviously build pipelines which are also tedious, but once it's done then it becomes business as usual.

In my experience the Debian upgrades are way easier then ELevate from CentOS7 to AlmaLinux8 so I don't care if I have to do them 3 times as often and stay more "current" on Debian.

I switched to Ansible with lfops/debops for orchestration and this way we can abstract away the OS differences.