Live data from Hacker News

June 30th, 2024, will bring the End of Life (EOL) of CentOS Linux (2023)

redhat.com

81–90 of 228 posts

Re: June 30th, 2024, will bring the End of Life (EOL) of CentOS Linux (2023)

#81
post #69

For better or for worse, this has caused a lot of software vendors to drop RHEL/CentOS support. Many have started to offer Ubuntu support in it's place. Most of them didn't even try to support stream. I'm not sure what the process behind that was. CentOS was free, which is why we used it. Sure, our SAP boxes run RHEL but the other stuff doesn't. We started moving a lot of stuff to Ubuntu as well. Now, Ubuntu is by no…

I am always baffled by people using ubuntu because "free". I get the desire if you want the paid stream. EG, an alternative to Redhat or SuSE as a paid stream. But if you're going to use Ubuntu, why put up with the snaps, the commercialism, the app store, when you can just use debian? Every time I hear a reason why, it makes little sense to me. Even though 95% of Ubuntu is Debian, and Ubuntu wouldn't exist without De…

If I'm not running a desktop, why would I consider running Ubuntu at all? I feel the same about people offering a kneejerk suggestion of Ubuntu as when I'm told to use Docker without actually knowing anything about my needs. Just because I'm wanting to use Linux does not mean I need Ubuntu. Just because I'm deploying code doesn't mean Docker is the solution. But 99% of the time I talk to people, it's all Docker this Docker that.

Re: June 30th, 2024, will bring the End of Life (EOL) of CentOS Linux (2023)

#82
post #47

Rocky Linux is a fine successor to CentOS and was created by one of the original founders of CentOS, Gregory Kurtzer. https://rockylinux.org/ https://rockylinux.org/about/ If you need enterprise support RHEL tends to be a default choice. If you cannot afford RHEL or do not need enterprise support, Rocky Linux fills the role that CentOS once did.

Personally it would not be my first choice since I am somewhat allergic to anything with the word Oracle in it, but another option for those in the enterprise space might be Oracle Linux: https://www.oracle.com/linux/ They claim full compatibility with RHEL and don't require a licence/login to download and install. And they offer paid support if you need it.

They also add btrfs and a bunch of drivers back into their custom kernel that RHEL explicitly removes, so it runs on a lot more hardware.

Re: June 30th, 2024, will bring the End of Life (EOL) of CentOS Linux (2023)

#83
post #15
post #8

Earlier quoted context omitted.

CentOS 8 already reached its EOL in December 31st, 2021.

If you moved from CentOS 8 to CentOS Stream 8, Stream 8 is basically EOL on May 31st 2024.

Okay, but RHEL Beta- er, sorry, "CentOS Stream" isn't CentOS.

Re: June 30th, 2024, will bring the End of Life (EOL) of CentOS Linux (2023)

#84
It's interesting to see the different strategies people are adopting. I recently came across TuxCare's Extended Support for CentOS 7, an interesting stopgap for those not ready for an immediate RHEL shift.

https://tuxcare.com/extended-lifecycle-support/centos-7-exte...

Somewhat surprisingly, it's also pretty affordable. It's one of the few options like this I've seen, though I'm curious if there are others that are around this same price.

Re: June 30th, 2024, will bring the End of Life (EOL) of CentOS Linux (2023)

#85

Earlier quoted context omitted.

Accusing Red Hat of not contributing to the wider free software community is so off-base I’m not sure how to respond. Is there a single large FOSS project who’s git history isn’t filled with @redhat.com ?

Oh, so is it okay to share RHEL sources back with the original project communities or not? If you share RHEL sources with the original project communities, what happens? >> Is there a single large FOSS project who’s git history isn’t filled with @redhat.com ? Does this give Red Hat the right to effectively "close source" the code for RHEL despite contributions from the rest of the community?

Yes, you can. This is something everyone gets mixed up.

RHEL is built from CentOS Stream sources. The changes Red Hat made to RHEL source distribution mostly just make it more challenging to reconstruct an entire build of RHEL from CentOS Stream - because you would have to map backwards from all of the different versions of sources available in CentOS Stream to the exact versions that a particular version of RHEL happens to use. But at the scale of any individual project, it's trivial for any upstream community to just look at the latest CentOS Stream sources for one particular package, if they want to look at which patches Red Hat is applying. There are no legal or contractual restrictions on this whatsoever.

This is setting aside the fact that most patches are backports from one upstream version to another, and bugfixes that get submitted "upstream first" to begin with, which makes the whole discussion kind of moot. The typical scenario for a net-new bugfix would be that a Red Hat employee submits the fix upstream and gets it reviewed and merged by said upstream months before it ever sees the light of day in RHEL, so upstream maintainers would never need to look at the RHEL sources in the first place.

Re: June 30th, 2024, will bring the End of Life (EOL) of CentOS Linux (2023)

#86

This is really the time to make a decision, do you really need support..ehm sorry insurance? Then RedHat/Suse/Oracle if not, choose a trusted community distribution like Debian.

I am curious about what the expense of support gets you that a typical IT person could not find on some forum somewhere online.

Re: June 30th, 2024, will bring the End of Life (EOL) of CentOS Linux (2023)

#87
post #44
post #9

Earlier quoted context omitted.

Another suitable option, which has handled the situation of Red Hat source RPM releases[1] quite a bit better imo, is Alma Linux. https://almalinux.org/ Similar goal, but is working more directly upstream with Red Hat[2] as opposed to the (as I last had read) undisclosed and non-open approach that Rocky Linux has taken. 1: https://www.redhat.com/en/blog/furthering-evolution-centos-s... 2: https://almalinux.org/blog/f…

As I understand it, Alma is following the stream release, which is slightly upstream and less stable than RHEL. https://linux.slashdot.org/story/23/07/29/0214234/almalinux-... Rocky and SUSE Liberty Linux aim to be bug-for-bug compatible with RHEL, which has become more difficult.

> which is slightly upstream and less stable than RHEL

As a user who almost exclusively uses rolling release OS-es, is this actually something people care about? CentOS Stream is downstream of Fedora -- and Fedora is a rock solid base. It's not like CentOS Stream is riddled with bugs, broken features, etc.

Re: June 30th, 2024, will bring the End of Life (EOL) of CentOS Linux (2023)

#88

Earlier quoted context omitted.

Yep. It would've been disappointing, but it wouldn't have knocked the bee hive off the tree, so to speak. The announcement came right after I had switched over all my stuff to target CentOS 8. If they had given me the runway to make it feel like all that work wasn't for nothing, I would've been okay taking a few years to slowly roll to something else.

Same. I mostly support what Red Hat has done (after many hours of listening to arguments and thinking about them. Not the prima facie arguments that they made which were PR BS and spin, but the real reasons that were only gotten to by podcast hosts that pushed back a bit. But the CentOS 8 rug pull was a bad move and IMHO is really hard to defend because it came down to a short-term profit grab to try to force people…

I can't say I wouldn't have done a similar pull on the rug, but having a plan before-hand for open source users, home users, and even "small business" users would have gone a long way to making the pill easier to swallow.

I know for myself, where I could fit into all three of those, I just won't use RedHat anything anymore. Whereas if there had been a "pay one-time fee of $500" or whatever to get "ten years of self-support/no-support" our server would be RedHat today.

As it is ....

5.4.0-169-generic #187-Ubuntu SMP

Re: June 30th, 2024, will bring the End of Life (EOL) of CentOS Linux (2023)

#89
post #16

I don't know much about CentOS, but I've seen a lot of anger about the end of CentOS Linux, regardless of CentOS stream, Rocky, etc. . Can someone explain the history of this, why CentOS is going away, why it's being replaced with these new alternatives, and why many seem quite mad about it? Just curious to understand the state of it.

One of the biggest issue is that they pulled the rug on the support window. The last release started out with 10 years of support, but they walked back on that when they announced the end of regular CentOS and reduced it by more than half.

> The last release started out with 10 years of support, but they walked back on that when they announced the end of regular CentOS and reduced it by more than half.

I thought that the "10 years of support" which was customary w/ CentOS wasn't applied, but neither Red Hat nor CentOS made specific announcements that CentOS 8 would have 10 years of support. People believed that CentOS 8 would have 10 years of support because of what was done in the past, but that's always subject to change.

If, however, there were direct statements from Red Hat or CentOS that CentOS 8 would have 10 years of support and then they changed that - that's moving the cheese for sure.

Re: June 30th, 2024, will bring the End of Life (EOL) of CentOS Linux (2023)

#90
post #70

Earlier quoted context omitted.

Does `apt` handle packages as cleanly as `dnf` and `yum`? Last time I tried `apt`, it would uninstall apps without cleaning after itself.

It will not automatically remove dependencies that were installed along with a package when that package is removed. I'm guessing this is due to some historical ideology about how `apt-get` was intended to function. I just typically run `apt remove foobar && apt -y autoremove`. There is also nala, which _does_ automatically remove dependencies when you remove a package: https://github.com/volitank/nala

Is it aware if another package is using the same dependency, so it only removes the dependency if it is not being used by anything else?
Post reply on HN