June 30th, 2024, will bring the End of Life (EOL) of CentOS Linux (2023)
redhat.com
redhat.com
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 means perfect, snaps are annoying, etc. But Red Hat really angers me with their decisions during the last few years.
One example is removing OpenLDAP:
The openldap-servers package was removed in Red Hat Enterprise Linux 8. The openldap-clients package is still shipped though.
If you use openldap-servers in Red Hat Enterprise Linux 7 (RHEL7), you need to consider to change your LDAP server from OpenLDAP to Red Hat Directory Server (RHDS) in Red Hat Enterprise Linux 8 (RHEL8).
RHDS is provided as an add-on subscription in RHEL8, so you need buy the subscriptions in addition to RHEL subscription.
https://access.redhat.com/solutions/3816971
Additionally, Red Hat support is so bad these days. It almost reminds me of Microsoft Technet forums of the past. Random 'techs' offering copy-paste solutions and the same bad information.
Probably because Red Hat is no longer making those decisions
Can you list a few? It's good to keep up to date on how this is changing. Thanks!
https://www.ansys.com/content/dam/it-solutions/platform-supp...
Veeam doesn't support CentOS stream or 9, there's been a bunch of things here and there. I notice many are moving to Ubuntu. I had to go through all of our vendors last year, and the nice thing about CentOS was almost everyone supported it. Now there's no 'gold standard'.
"Red Hat Enterprise Linux (RHEL) 7.8, 7.9, 8.1, 8.2, 8.3, 8.4, 8.5, and 8.6 (64-bit)"
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 Debian.... people use it.
Ah well.
Ubuntu and Debian are pretty similar, and using Debian gets rid of things like snap, which I'm glad to be rid of - but it adds an extra level of "well it works on my machine" which I'm not glad for.
If it's going to be hard to get that special different version of Java to work on the server, it should be hard to get it to work on the desktop too :)
Of course the rise of containers has made a lot of this stuff less relevant.
To me, we've gotten a bit lazy and a bit too focused on the wrong things. I feel like this happened when we started running javascript on the server. That was such a shock to the system and all sorts of things had to be done since it just was not the normal way of doing things. Someone decided it'd just be easier to clone the dev's system and deploy that as a server. Like what the actual... I also totally feel the same way about running a Windows Server. Like why on gawds good earth would you ever think that was a good idea?
For polygot/hybrid cases where you have a smattering of different languages and supporting technologies/services, docker makes a lot of sense.
If you're all in (for example) on nodejs with a monorepo, it probably doesn't - you're just an "npm install" away from deployment.
Whenever I really dig into the docker passion, I usually find devs who are frustrated by having to manage a million little details to get the dev environment going.
If the language/stack takes that pain away, docker loses most of its value.
Their more clever friends were compiling Arch, but who has time for that?
I say this tongue in cheek, as a personal lived experience.
It also wasn't shy about marketing and made an effort to have a welcoming community whereas other communities were much less friendly to outsiders.
The free CDs and Canonical's "ground game" in the face of the Red Hat Linux diaspora made it much more successful than other "Debian, but easier" efforts before it.
That's my reason for using Ubuntu instead of Debian - I simply don't care enough to bother with these small things.
Edit: perhaps this situation has improved for Debian now that non-free firmware support isn't hidden, but it's been a while since I installed Debian on a new machine.
Everything would work great, then bam giant updates, everything broken (bluetooth, wifi, video, graphics cards, audio), have to start from scratch learning some new fad Ubuntu folk had invented.
When I want to tinker or try out cool-new-tech, then sure, a platform like Ubuntu is great - semi-stable, half-working software.
When I don't, Debian/CentOS are hands down just better. Sure, I have to configure my bluetooth, but I have to do it just once _and it never breaks_.
Fedora used to be pretty great, then some personalities with inflated opinions of themselves started ruining the relative stability.
I still have bad memories of going to the DC with a USB stick with network driver on them because the Dell server with Debian on it would not ship with non proprietary firmware / drivers.
From the firmware wiki at debian.org:
"The Debian project took the decision in October 2022 to create a new repository component non-free-firmware, and include its content on installation media for the upcoming Debian 12 release (bookworm) to make things easier for our users. This change was implemented in time for the bookworm alpha 2 release of debian-installer in February 2023, and all d-i releases and daily and weekly images since then all include firmware."
Previously one had to either download the needed firmware separately, or a bootable image containing it so that it was accessible during install. Many users having problems with proprietary hardware didn't know they could just grab the install image with included firmware at https://cdimage.debian.org/cdimage/unofficial/non-free/cd-in... But I blame Debian for this because their site historically has been excellent at hiding stuff.
Ubuntu = Linux for a lot of people these days, kind of like Red Hat was to us old guys.
Yeah, that's been my experience. We had a bad driver package from them completely hose one of our prod systems.
It took 3 days and multiple calls from our CTO to get anyone to seriously look at the issue despite being on the top level support level and it being a Severity 1 issue. The whole "Responses within X hours" thing is a joke when all they give you is "Have you tried rebooting?" or "We're still looking into it" (technically those are response!).
Sounds like someone is trying to get their investment back before dumping the whole thing.
They bought it, now they’re sucking the marrow out.
I don't really like using snaps for everything so this is a bit annoying. But at the moment I'm mainly devving for VR so i need to be on Windows anyway.
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.
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...
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.
It's hard to read between the lines of the marketing speak but it sounds like it's just a suite of paid support options for existing RHEL/CentOS deployments and not a RHEL derivative that one can just download and use. Unless I am missing something?
Beware the Freudian slip.
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.
The Rocky people are antagonistic toward Red Hat and view them as somewhat an enemy (which seems so weird to me as without Red Hat, they couldn't possibly exist). They strictly want to take what Red Hat sells and rebuild and distribute it for free.
The Alma people on the other hand view themselves as partners and contributors to Red Hat's ecosystem. They want to make their product available for free, but they upstream as much as possible and add actual value to the ecosystem.
If you don't care about any of that, it's still better to choose Alma IMHO because their approach (following the letter and spirit of "the law") is a lot more sustainable than Rocky's exploit-the-system approach.
I think this is an unfair framing. Rather, they want to take all the GPL source code that Red Hat is obligated to make available, and distribute it freely. They believe this is in accordance with both the law and the software license that Red Hat agreed to, when using it as a basis for their business in the first place.
Personally, I don't have a dog in the fight, or a strong opinion on the matter. But we should at least fairly represent each parties position.
What they want to do, is do an exact rebuild of RHEL without having to go through the effort of putting the distribution together themselves, matching the versions that are used in a particular version of RHEL against what is available via CentOS Stream.
That's both spirit and letter. Don't fall for people making up additional terms that aren't in the license.
They do contend, that they are exercising their legal rights as enumerated in the software license that Red Hat agreed to, when it started to use and freely redistribute the work of others.
If you are denying they have this legal right, then I believe it's on you to explain and justify this legal position, rather than just asserting it as fact.
As I commented elsewhere, "RHEL" isn't GPL licensed, the kernel is, and glibc is, and systemd is, etc. Individually.
The sources for all of those packages, individually, are available via CentOS Stream just as they ever were - alongside the sources for packages that aren't GPL licensed, for which there is not actually a legal requirement to distribute sources.
What Red Hat has stopped doing is providing a git repo containing the exact combination of package sources which collectively make up one particular version of RHEL. Instead, all of the sources are still available, but if you want to rebuild the entire distro you need to match up the particular versions with RHEL. And that's exactly what Alma Linux does.
Rocky Linux contends they are not doing anything illegal in the methods used to obtain the source code (ie. legally renting an RHEL VM from any number of providers, and downloading the SRPMS).
Maybe Red Hat wishes this was illegal, but I still haven't heard anyone claim that it is.
> which seems so weird to me as without Red Hat, they couldn't possibly exist
If Red Hat didn't exist, they wouldn't need to exist. Nobody would need to test their stuff against RH, and nobody would need to run garbage that the upstream vendors only bothered to test against RH.
1. Using OCI images of RHEL (i.e. on Docker Hub)
2. Using cloud server images of RHEL
They outlined their plans for this in June of 2023[0].
Red Hat’s official stance is that downstream distros like Rocky or AlmaLinux should be basing off of CentOS Stream — that would allow all the EL distributions to contribute and use the same OS base[1]. AlmaLinux pivoted to this method[2] — which seems like a more sustainable approach to me.
My opinion: blows my mind that people who value Enterprise Linux would be willing to continue to use a distro like Rocky that actively works against/around the supported route its upstream provider suggests.
(Personally, I don’t find value in the EL ecosystem, I prefer rolling releases everywhere when possible)
[0] https://rockylinux.org/news/keeping-open-source-open/
[1] https://www.redhat.com/en/blog/furthering-evolution-centos-s...
The entire Propose of CentOS was Binary Compatibility with RHEL, largely for Vendor compliance reasons, if a vendor of a commercial software product validated RHEL 7 for their software running CentOS 7 was also supported
Running CentOS Stream, or now Alma Linux would not be as their are no longer binary compatible with RHEL.
the Hostility of IBM and Redhat here has lead me to transition 100% of the CentOS Server I managed to Ubuntu Last year... The software vendors that i use all quickly validated Ubuntu as an alternative to CentOS after the original CentOS Stream announcement which made is a easy choice for me..
I will never use RHEL or RHEL based distribution again at this point so I really do not care about the future of Alma or Rocky either
>Personally, I don’t find value in the EL ecosystem, I prefer rolling releases everywhere when possible
if you are running ERP Systems, LOB Apps, or other critical functions that measure their code life in decades not weeks then EL systems are required. I do not want the system to change as the app i am running has not changed. I want Stability, and security not new features or more performance or even new hardware
> What does ABI/binary compatible with RHEL mean?
> In July of 2023, we announced (opens new window) that we were shifting our goal from being a downstream rebuild of RHEL to maintaining ABI compatibility with RHEL. For the AlmaLinux team that means that everything from software applications to kernel modules that work on RHEL will work on AlmaLinux, and if they don't we would consider that a bug.
TL;DR: they are using CentOS Stream as their upstream.
EDIT: Sorry, you're correct -- I was thinking you meant their original goal of "bug-for-bug" compatibility with RHEL.
[0] https://wiki.almalinux.org/FAQ.html#what-does-abi-binary-com...
I'd say that your use case for CentOS might have been vendor compliance, but our user base doesn't agree that's the only use case.
I'd recommend listening to this podcast with Neal Gompa about Red Hat vs IBM at this point:
https://hackaday.com/2023/12/27/floss-weekly-episode-763-fed...
I believe that AlmaLinux's approach is in-line with Red Hat's vision for downstream OS-es. Rocky's is not.
I think a potential benefit to aligning with Red Hat's approach is that both AlmaLinux and Red Hat will be contributing fixes, improvements, etc. to CentOS Stream -- and any other OS-es that base off of CentOS Stream. And, nothing is preventing AlmaLinux from snapshotting their own stable releases -- which allows the AlmaLinux team to test and release stable releases to their users.
> the Hostility of IBM and Redhat here has lead me to transition 100% of the CentOS Server I managed to Ubuntu
I completely agree with this perspective. This is why Rocky's decisions really baffle me: why use an upstream OS like RHEL if you absolutely do not align with its objectives? I feel like it would have made much more sense for Rocky to make Fedora their upstream instead of implementing workarounds to copy RHEL.
> I will never use RHEL or RHEL based distribution again at this point so I really do not care about the future of Alma or Rocky either
I also do not use any Fedora based distribution (typically just running NixOS or Ubuntu), however, I find that I do care about these shifts because Red Hat has tremendous impact on the trajectory of most Linux distributions. And the downstream OS-es' responses have been interesting to observe to me. :)
What is in-line with users' vision?
- Free developer licenses[0] (great if you're a home-labber, IIRC you can get up to 16, I think?)
- Red Hat UBI images[1]
I feel like most users of AlmaLinux won't see a huge difference between just using AlmaLinux's release cycle vs RHEL -- especially since AlmaLinux will be ABI compatible with RHEL. I.E. apps that work for RHEL should work for AlmaLinux.
So, back to your original question, I don't know what end-users want more of other than as was said by mrweasel in a different comment: "that's not what some people want, they specifically want RHEL, but for free".
[0] https://developers.redhat.com/blog/2021/02/10/how-to-activat...
As far as I can tell this is logically incorrect CentOS/Alma are upstream not downstream and red hat's vision of downstream OSes is they don't exist because that takes a nickel out of IBM's pocket.
> red hat's vision of downstream OSes is they don't exist because that takes a nickel out of IBM's pocket
I think CentOS Stream actually contradicts this because (I would imagine) it's a lot of work to maintain and greatly benefits the community -- and Red Hat still makes it freely available for other distributions to base off of.
[0] https://www.redhat.com/en/blog/furthering-evolution-centos-s...
EDIT: clarified RH's vision for CentOS Stream and added my thoughts on CentOS Stream
Formerly we were just 100% downstream RHEL with none of this nuance, as you mentioned.
That's really what confuses me about the people who use CentOS or Rocky, they want or need the stability of RHEL, so that they can run these crucial applications, that mostly aren't cheap, yet they refuse to pay for the development of the operating system they run it them?
I really don't see the point in any of these clones, other than as an educational tool. I see the point in RHEL and while expensive, that's the price of developing this platform. You can buy SuSE, Ubuntu Pro or Oracle Linux, if you feel that RedHat is to expensive (perhaps not Oracle), but that's not what some people want, they specifically want RHEL, but for free.
That made a great deal of sense, as of course Red Hat themselves were shipping a great deal of software written by other people without paying for its development.
There's nothing confusing about people declining to go along with this change.
No, but why stay on a platform from a vendor that has a business model you find hostile? I can see the need for a transition period, but I'd start looking for another vendor that has value and pricing that aligns more with my ideals. People seem hellbent on staying on a RHEL-like platform.
Also, CentOS isn't/wasn't exactly new, the current pricing model from Redhat isn't nearly as old as CentOS.
Not really, Ubuntu Server has surged in popularity.
Yes. Non-prod (or even prod and non-critical) servers usually outnumber critical prod servers, and it makes sense to not run RHEL on them and pay for support, but to run a 100% compatible distro.
No, the people who need the stability of RHEL were already paying for it. The people who used CentOS were doing so to be able to develop and test software that would eventually be used by people running RHEL.
Well in my world we used to run many Dev/Training/Non-Prod servers with CentOS and then Run the Prod Servers with Licensed RHEL
Similar to having a MSDN License for Windows vs Production licenses
Then with the announcement of CentOS Stream they tried to sell their Dev program, but that program was TERRIBLE for enterprise use, it was built for individual developers, and not at all compatible with the model many organizations where using. They have since tweaked the terms to make is somewhat more compatible but it still IMO, not very useful for many of the scenarios I found myself in over my life
And frankly I have enough problem keeping track with MS Licensing I do not need the additional headache I might as well just use windows at that point.
Red Hat was able to become a billion dollar company by providing great support, and being easy to do business with, even before IBM buyout and accelerating after their support was becoming less and less quality, and they became more and more hostile / harder to do business with
Many organizations where already questioning their continued use of Licensed RHEL because of this, this like played a part in them killing CENTOS (and yes they killed CentOS, CentOS Stream is not a compatible replacement) as that was easier that fixing the systemic internal issues around support and business processed.
Alma is getting their source packages from CentoOS Stream, but they are using the specific versions that are in the Redhat releases they are targetting. They aren't just rebuilding Stream sources from HEAD.
That stance goes contrary to the "everyone benefits" nature of free and open source software. It turns "everyone benefits" into "Red Hat / IBM profits". Why should the community contribute to Red Hat's bottom line if Red Hat refuses to contribute back to the community?
Rocky Linux's "going around Red Hat's back" is only necessary because of Red Hat's choice to not contribute back to the community.
If IBM wants to expand its AIX (https://en.wikipedia.org/wiki/IBM_AIX) business, it can do so without tainting Red Hat.
Is there a single large FOSS project who’s git history isn’t filled with @redhat.com ?
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?
Legally, yes. Not sure what the point is you're trying to make.
I'm not sure why anyone would want to use a downstream distribution of Red Hat if they don't like Red Hat's trajectory. If you don't like Red Hat's current objectives with RHEL, it should be as simple as: stop using something downstream of RHEL.
Legally, no; unless RH is the only copyright holder, they get to follow the same rules as everybody else, and for GPL packages that means not imposing additional restrictions on redistribution of source code.
> If you don't like Red Hat's current objectives with RHEL, it should be as simple as: stop using something downstream of RHEL.
People are fine with being a downstream of RHEL. It's being upstream of RHEL that's the problem; Stream is RHEL Beta by another name.
And there aren't any. "RHEL Linux" isn't GPL licensed, the kernel is, and glibc is, and systemd is, etc. Individually.
The sources for all of those packages (and ones that aren't GPL licensed, for which there is not actually a legal requirement to distribute sources), individually, are available via CentOS Stream just as they ever were.
What Red Hat has stopped doing is providing a git repo containing the exact combination of package sources which collectively make up one particular version of RHEL. Instead, all of the sources are still available, but if you want to rebuild the entire distro you need to figure out which particular versions to use. And that's exactly what Alma Linux does.
That is why I said "GPL packages", yes.
Okay, so if I buy RHEL, and I download the SRPM for the kernel, and I publish it - which I'm legally entitled to do, what with the kernel package being GPLv2 - is RH not going to terminate my RHEL license?
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.
Prior to CentOS Stream, if you were a CentOS user or maintainer who experienced a bug, your only option was to file a bug on the RHEL bug tracker and wait for a Red Hat employee to fix it for you. It was the Android-esque "throw the code over the wall" model of open source.
Post CentOS Stream, a CentOS user or maintainer files the bug in the CentOS Stream bug tracker, can write a patch and have it reviewed by other users/maintainers/Red Hat employees tracking the issue, and then benefit from Red Hat QA'ing the fix.
So counter to your claim, I would argue that the CentOS Stream model provides more bidirectional / mutual benefits.
Substantial enough to effectively "close source" RHEL?
Red Hat's changes (https://www.redhat.com/en/blog/red-hats-commitment-open-sour...) effectively converted RHEL from a fully open source Linux distribution to "source available to paying customers only" proprietary product.
The changes are effectively a violation of the GPL by prohibiting customers from distributing RHEL sources through Red Hat's Terms of Service and EULAs:
Even non-customers are provided with all of the sources they they could use to build RHEL, given some additional effort. It's less trivial than it used to be, but not particularly difficult.
Alma takes the approach of reconstructing RHEL using these public sources, Rocky takes the approach of buying AWS VMs running RHEL for a few minutes at a time so that they can download RHEL sources as a "customer" while only paying a few dollars a month to do so.
The point is, even non-customers can rebuild RHEL using sources made publicly available by Red Hat if they so desire. It's not "effectively closed source", even to them.
With CentOS you would have the same problem, except that there's no way to make the engineering part happen any faster than Red Hat's staffing and priorities allowed.
We should he celebrating people working around DRM, not being fearful of it.
(I'd be happy if the Rocky Linux folks prove me wrong -- the more variety there is with Linux, the better!)
Point taken.
From my perspective, it seems like a short-sighted approach to rely on loopholes to obtain bug-for-bug compatibility. I know I wouldn't be comfortable running anything production-grade on Rocky Linux with their current approach.
The leading features of CentOS were 1. Absurdly stable; keep updating the same version in place for a decade without changing it. 2. Drop-in compatible with proprietary drivers and applications published for RHEL.
Fedora is not a replacement for CentOS.
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.
Much respect for the tenacity required to figure out how to bootstrap RHEL without its build system.
(Shout out to White Box Enterprise Linux as well!)
SL7 is still supported until June 2024. The maintainers decided not to do SL8 and are now contributing to AlmaLinux instead.
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.
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
Writing was on the wall back then tbh. Redhat can enjoy it's legacy bubble, I'll continue to enjoy not paying for free software.
Well we pay for it (the project and different other software projects..and even a completely different os) but in donations instead to pay stakeholders and "managers". ;)
Same as: No one gets fired for buying IBM (if your really old...like me)
First, some proprietary software only supports a subset of distributions. Debian is rarely on that list. RHEL, for some time, has been a safe default.
Second, IT organizations only want to support one distribution when at all possible.. As such, RHEL and CentOS made a lot of sense. RHEL and Debian means twice the work.
That said, it's going to have to change. $349 for every 2 VMWare images (as I understand it) plus $2499 for every 2 processor sockets adds up.
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.
In the current thread, I'm only nit-picky about this, because OP said "Last time I tried `apt`, it would uninstall apps without cleaning after itself". To which to suggest that apt-purge does clean up after itself is incorrect. It does some additional cleaning-up, but it doesn't do a complete cleaning-up.
That being said, of all the package managers I tried, I still like apt the best. I feel like it's the most straightforward and user-friendly of all of them.
That looks like an unnecessarily long process to safely remove a package. Why isn't that the default behavior on Debian?
And aptitude (alternative package manager) automatically removes dependent but not required anymore packages when removing/purging a package.
Do you have a use-case where packages are regularly uninstalled? I usually only install.
There is also nala, which _does_ automatically remove dependencies when you remove a package: https://github.com/volitank/nala
However, the package could of course still be used by unpackaged software or local scripts.
It has also a useful 'aptitude why package' to say why a package is installed and a nice TUI (which is optional; for the most part it works very similar to apt).
This sort of language strikes me as fear-mongering. I can't tell which issues they have patched in CentOS7 that otherwise remain unpatched. Anyone know what they are talking about?
I was real annoyed as I did a tun of work prepping for a migration to CentOS 8 and then got rug-pulled by IBM with CentOS Stream. They lost all the goodwill just to make a tiny bit more money.
Now I am doing everything possible to eliminate RHEL servers. What next will they pull? The longer you depend on them, they more they can charge you later.
a. Go to Debian (or ubuntu server etc); probably the most difficult since everything will be different b. Go to a fresh Almalinux or Rocky 9 installation; also very difficult since there's a lot of stuff to be moved c. Try to use in-place upgrade using Leapp or something. There are some guides for this (https://wiki.almalinux.org/elevate/ELevating-CentOS7-to-Alma...) but I'm really not sure how good this would work on a live production system.
I'd definitely prefer the solution c, if I can confirm that it works of course. Has anybody tried using leapp to upgrade Centos 7 to Rocky/Alma ? What was your experience? Do you feel that it's worth researching that path or it's probably better to move to a greenfield installation?
Thank you for any insights!
To me, open-source is about the open, transparent "culture" in which you commit to develop, not about putting things out there for free (as in free beer). Too many companies already benefiting from open-source packages (e.g., OpenCV) without giving anything back to the community.
I don't think RHEL/IBM cares about the small losses on CentOS/Rocky/Alma/etc what they found was hurting them was companies like Oracle
There was 6 years in between those two events, and by all accounts CentOS got much better post-acquisition.
There is no "just" here. Originally it was considered a good idea, and (years) later they changed their minds.
Over the years I became aware that the acquire-extinguish pattern was definitely not just a coincidence, specifically i remember disney bought up some 'IP' just to litigate against some adjacently-related online fan game in the UK in order to shut it down and 'acquire' its captives, over to a similar product they already owned. Sorry I looked for the exact reference but cant find. There are countless other stories if you look though.
This all came full circle when I was 'enlightening' a young relative who had just finished business school, or rather she 'learned' me. Turns out this acquire/extinguish game is like a whole 100-level course in <pick-your-business-school-of-america>. Who knew.
RedHat has been making money for decades. The Centos rug pull was just a way to make more money at the expense of their users and the larger open source community.
It is impossible to justify a rug pull. By definition, it is a hostile, one-sided, trust-destroying, and underhanded move.
https://web.archive.org/web/20201101131417/https://wiki.cent...
Red Hat's explanation was something along the lines that it was a wiki and not guaranteed to be accurate? I don't think editing was open to to people outside of the CentOS org.
Yet somehow even Pablo Escobar understood this and threw away billions just giving money to poor people to keep cities on his side. I'm not even going to say IBM's basic business model of making shit that works, doing at least some complex things reliably and well back when that was very difficult, is invalid. But it is fundamentally different to Redhat's business model, which was simply cultivating a lifelong love of their product in the minds of its users. It's like the Army acquiring the Red Cross. They work in a lot of the same places doing overlapping work and no doubt a lot of corporate synergy could be achieved and administrative overhead eliminated, but it would irreparably destroy a century and a half of goodwill and brand identity. Exactly the kind of strategy you'd expect from people whose decision consequence horizon extends no further than the next three reporting periods.
ahahahahaha....
OTOH, I no longer work there, I get to watch the fireworks
The replacement project for remaining CentOS 6 machines was going glacially, but at least didn't endanger compliance. The replacement project for CentOS 7 got sabotaged by management, few people got run out of the company, last I heard the replacement project for the replacement project was going to just end up with few multimillion cheques to OpenLogic so that certain big fat client group doesn't drop them like hot potato on EOL day.
had to compile git and tcpdump from source.
all in all, a pleasant experience. vi is the same.
I can't disprove your anecdote but do you think this is really true? Orgs who ran CentOS likely did so with the idea that they'd have a very long time to migrate to something different. CentOS 8 nominally had support until something like 2032, so it seems like a really major change to go from almost a decade to a little over a year to migrate away.
That being said, I've recently completed moving entirely over to Debian and there's just something about it I love so much more...
That's likely the best possible outcome.
> in glibc version 2.28, released 2018-08-01, a major update to the locale data has been included, which can potentially affect the data of many users
Migrating to rhel8 was being considered, but since locale changes are inevitable, it made an opportunity to have us pivot to ubuntu
Other than those big clusters we have some CentOS systems spread out for minor services and those we're migrating to either RHEL or Fedora, depending on circumstances and requirements.
It was successful as it gave most of the benefits of RHEL without the expense.
RedHat acquired CentOS, saying that it would be good for CentOS[1].
RedHat shut CentOS down.
New alternatives are coming along to take the role of a free distribution compatible with RHEL.
[1]: https://www.redhat.com/en/about/press-releases/red-hat-and-c...
>RedHat shut CentOS down.
It should be noted that six years passed between point A and point B, during which time Red Hat did invest quite a lot of additional resources in CentOS. Red Hat did not acquire CentOS and then immediately shut it down.
CentOS Stream is also not a wholly different thing from CentOS, although it is obviously not exactly the same thing.
CentOS stream is primarily intended to onboard users onto RHEL, which is undesirable when nobody trusts Red Hat to keep their word now.
I thought that neither Red Hat nor CentOS foundation gave a lifecycle date for CentOS 8. Can you help me find that lifecycle statement?
I suppose people are trying to claim this wasn't actual CentOS policy, but it was, and when the project abruptly decided to truncate eight years of announced support, at no point did anyone involved deny this was a change.
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.
Though there are some gaps on the Wayback machine that makes it hard to find some centos8 related posts at the time it launched, but I'd be surprised if the eol wouldn't have been announced elsewhere too.