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…
June 30th, 2024, will bring the End of Life (EOL) of CentOS Linux (2023)
81–90 of 228 posts
Re: June 30th, 2024, will bring the End of Life (EOL) of CentOS Linux (2023)
#82Rocky 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.
Re: June 30th, 2024, will bring the End of Life (EOL) of CentOS Linux (2023)
#83Re: June 30th, 2024, will bring the End of Life (EOL) of CentOS Linux (2023)
#84https://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)
#85Earlier 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?
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)
#86This 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.
Re: June 30th, 2024, will bring the End of Life (EOL) of CentOS Linux (2023)
#87Earlier 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.
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)
#88Earlier 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 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)
#89I 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.
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)
#90Earlier 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