Possibly migrating. Rocky or Alma?

[Moonchild]

I'm looking at possibly migrating all of the *nix servers for Pale Moon off of CentOS (because of their policy changes) and have been looking at two stability-focussed Linux releases: Rocky Linux and Almalinux.

I'm wondering if anyone here has experience with either (or both)? Can you share those experiences? What would you recommend for a low-maintenance, stability-first setup on fairly-constrained (but not super minimal specs; think lower-end VPS) hardware in terms of ram/disk space? Are there any philosophy/distro policy snags I should be aware of?

[Night Wing]

Your decision to leave CentOS for Rocky Linux or Almalinux, does this decision have to do with the brouhaha with Red Hat Enterprise Linux and CentOS?

https://www.itworldcanada.com/article/r ... own/543157

I know RHEL is very stable while CentOS, if I'm not mistaken, is a rolling release. When it comes to stability, I do not care for rolling release type of distros.

If I'm not mistaken, isn't Rocky Linux compatible with RHEL? Ditto for Almalinux? But I do not know if RL And AL are rolling releases because I am not familiar enough with them.

[trava90]

A few months ago I moved off all my CentOS servers to a single AlmaLinux 9 Afterburst VPS (using one of their smaller plans). I started with a fresh install of AlmaLinux 9 and manually copied over only what I needed from the old servers (I did not use any kind of migration tool though I know they exist). The installation and setup went very smooth and I had everything installed, configured and running within a couple of hours (if that, even). I would certainly recommend it based on my experiences with it thus far.

I personally chose AlmaLinux primarily because the folks behind it (CloudLinux) have been around for a long time and been active in the Linux server space since 2009 I think. Rocky Linux is a fairly recent startup by one of the original co-founders of CentOS.

[mrnhmath]

I've been using Rocky Linux since the discontinuation of CentOS, but as things are get rockier I might as well go full Debian.

[athenian200]

AlmaLinux won't be targeting full RHEL compatibility anymore, so between the two I would pick Rocky (since that is a continuation of CentOS in spirit and in terms of who is heading it up), but I personally was already using Oracle Linux 7 to build Epyrus, which is not very far off CentOS 7 or RHEL 7 anyway. Mostly because I'm already familiar with Oracle stuff from messing around with Solaris 11 (which kind of mimics RHEL anyway) and it seemed easy enough for me.

https://en.wikipedia.org/wiki/Oracle_Linux

Also, Oracle, SuSE, and CIQ are creating this organization:

https://www.oracle.com/news/announcemen ... 023-08-10/

AlmaLinux is the only one that didn't join, and has stated they won't pursue full RHEL compatibility, which is what gives me pause. It is also worth noting that Oracle has experience dealing with IBM, or at least some people who do... Solaris did have to compete with AIX, after all. And I think it was actually more popular.

EDIT: Another possibility is to just use RHEL itself... apparently it's free as long as you have less than 16 production servers?

https://arstechnica.com/gadgets/2021/01 ... n-servers/

[Moonchild]

The main reason I'm considering either Rocky or Alma is because I don't want to have to re-learn everything by switching to something fundamentally different and outside of the RHEL "family". So I'd rather avoid switching to Debian or other families.
RHEL itself is a no-go because I do not want to be forced to be dependent on a subscription that controls what I can run and for how long, even if the subscription is no-cost:

A Red Hat subscription gives you access to all available versions of Red Hat Enterprise Linux except for those in extended support. This access ends when the subscription ends, as does access to all related documentation, support, services, patches, etc., so it’s important to think about the subscription separately from the platform.

If RH ever decides to change the rules of engagement I'd be stuck with having to do emergency toss&rebuild (if even possible). In addition I cannot in good conscience support or use a distro that did the ugliest bait-and-switch in the Linux corner in history with CentOS 8 being pretty much a rug-pull for community admins.

AlmaLinux is the only one that didn't join, and has stated they won't pursue full RHEL compatibility, which is what gives me pause.

I don't think full RHEL compatibility is needed. In fact it may be advantageous. I mostly just care about practical administration being mostly familiar to me.

I know RHEL is very stable while CentOS, if I'm not mistaken, is a rolling release. When it comes to stability, I do not care for rolling release type of distros.

CentOS was made into a rolling release with CentOS Stream -- and that is exactly why I never went for it and instead stuck to the super stable prior releases. CentOS was historically a community version of RHEL and as such as stable and focused on enterprise/production use as RHEL itself which is why I decided to teach myself its ins and outs and use it on the project's servers, even taking to drawback of having old default package sets because of the stability focus. They tossed all that out when Red Hat made the decision to suddenly toss CentOS 8 out after 2 years, a full 10 years before the expected EoL and push people to either use a perpetual beta rolling release (CentOS Stream) OR go subscription for RHEL.
Stability means I also don't want something bleeding edge.

[athenian200]

Well, based on the above, I would say it sounds like what you're really looking for is a community-based Enterprise Linux distro that continues in the spirit of the original CentOS, and in that case I would have to recommend Rocky Linux.

The thing worth noting is that AlmaLinux was released in 2021, same as Rocky Linux. So if it is between the two distros created to replace the original CentOS, then I would say Rocky Linux is the one I'd trust because most of the community moved to the Rocky Linux project due to the guy heading it up being a CentOS co-founder. That is, I believe it's more or less the same people that worked on CentOS that are working on Rocky Linux. It's true, Rocky Linux hasn't been around as an organization quite as long as CloudLinux (which was founded in 2010), but I would be willing to be lot of the people contributing to Rocky Linux now also likely worked on CentOS before Red Hat acquired it.

As far as Epyrus, I've been using Oracle Linux (which is also a RHEL rebuild like Alma/CentOS/Rocky) and see no reason to switch to anything else at the moment. It's stable, it's been around since 2006, and as much as I would have preferred Oracle to focus on Solaris, it's probably not going anywhere.

[Moonchild]

TIL: IBM/Red Hat has apparently started to paywall the corresponding source code for their RHEL core releases...
So that means both Alma and Rocky will have a hard time remaining RHEL downstreams because they are facing the situation that the source they need is (1) paywalled and (2) redistributing it would apparently be a violation of the subscription agreement terms?

Off-topic:
... So how does that rhyme with the GNU GPL anyway? Aren't they required to make the full corresponding source of their work available under the GPL? Even if it pertains to things they wrote, the GPL requires release of it as a "larger work" since it's integral to RHEL to have the published source code be included to function.

Maybe I should find a different enterprise-level distro after all...

[athenian200]

Off-topic:
... So how does that rhyme with the GNU GPL anyway? Aren't they required to make the full corresponding source of their work available under the GPL? Even if it pertains to things they wrote, the GPL requires release of it as a "larger work" since it's integral to RHEL to have the published source code be included to function.

Off-topic:
Actually, it's a pretty simple idea. They will distribute the source code to anyone who has a licensed copy of RHEL binaries, for that specific version of them. But if they redistribute the source code RHEL gives them, then RHEL will terminate their license to future binary releases and updates, and then will receive no further source code. In other words, RHEL is saying that you can get the source code if you obtain the RHEL binaries legitimately, but if you redistribute it, they revoke your rights to obtain future binaries and therefore source code releases. Presumably if you obtain the binaries in an illegitimate manner, they could not only not send you source code, but also regard that as piracy. So they do still have to give the source code to anyone who has a legitimate copy of RHEL, but if that person redistributes it further, their license is revoked and they do not get further source code.

So in theory, someone could keep the stream of RHEL source code flowing by having different individuals and organizations obtain RHEL licenses, get the source code, violate the subscription agreement by redistributing it, lose their subscription, and then have the next person in line violate their subscription agreement for the next release, etc. All RHEL could do is keep playing whack-a-mole by canceling subscriptions every time a subscriber is caught leaking the RHEL source code, since the GNU license itself doesn't prohibit redistribution. The source itself is not illegal to distribute, it is only a violation of a subscriber agreement, with RHEL's only recourse being to terminate the contract. An organization with deep pockets could easily afford to do this while keeping IBM tied up in court, if they wanted.

[Moonchild]

Off-topic:

So they do still have to give the source code to anyone who has a legitimate copy of RHEL, but if that person redistributes it further, their license is revoked and they do not get further source code.

But that flies right into the face of the GPL that explicitly states you must always have the freedom to redistribute the source code. It explicitly forbids restricting that.

4. Conveying Verbatim Copies.

You may convey verbatim copies of the Program's source code as you
receive it, in any medium

5. Conveying Modified Source Versions.

You may convey a work based on the Program, or the modifications to
produce it from the Program, in the form of source code under the
terms of section 4, provided that you also meet all of these conditions: {conditions snipped for brevity}

and also, more importantly, section 7 gives you freedom to add additional permissions (but not restrictions) to the license that do not have to be granted downstream if you want, so it doesn't apply here because it's an additional restriction, not a permission.
Then additional restrictions are prohibited in section 10 (emphasis added):

10. Automatic Licensing of Downstream Recipients.

Each time you convey a covered work, the recipient automatically
receives a license from the original licensors, to run, modify and
propagate that work, subject to this License.
{...}
You may not impose any further restrictions on the exercise of the
rights granted or affirmed under this License. For example, you may
not impose a license fee, royalty, or other charge for exercise of
rights granted under this License,{...}

So even if they make the initial offering of source code dependent on whether you are licensed to receive their binaries through a licensing agreement, they cannot restrict what you do with that source code once you have it, including making it available to others either modified or verbatim.
The intent of the GPL is clear; the preamble even states:

To protect your rights, we need to prevent others from denying you
these rights or asking you to surrender the rights. Therefore, you have
certain responsibilities if you distribute copies of the software, or if
you modify it: responsibilities to respect the freedom of others.

so... I really don't see how they can legally do this under the GPL? but maybe I'm missing something.

[BenFenner]

Off-topic:
They've been hashing this out on Slashdot for weeks of articles and others have made the same convincing argument as to the GPL preventing this kind of Ferrari* retaliation. Maybe we'll just have to eventually see how it unravels in court.

*The auto maker famous for controlling what buyers/owners do with their cars by refusing to sell them new ones if they don't toe the line during their ownership.

[athenian200]

But that flies right into the face of the GPL that explicitly states you must always have the freedom to redistribute the source code. It explicitly forbids restricting that.

Off-topic:
They do in fact have that freedom. The thing that's making it confusing is that there are actually two licenses at work here. Red Hat's EULA covering the binaries, and the GPL covering the source code. By legal precedent, regardless of what the GPL's drafters may want, the GPL doesn't really kick in until someone has either the source code or the software built against it in-hand. This means, that you can deny someone source code as long as you make sure they cannot legally get the binaries built against your source code in the first place. But you can require someone to sign an EULA, separate from the license governing the source code, before binaries are conveyed. Red Hat is doing a bit of an end-run around the GPL by requiring users to agree their EULA as a condition of getting and using the binaries in the first place. Once they have the binaries, then Red Hat must provide source code, and cannot really control what they do with it. They can't sue them for redistributing it, they can't do anything to them... other than revoke their rights to future binaries by saying they broke the EULA. Which effectively means they can't get the source code to future versions. It is legal and they are not technically restricting anything, they are just putting those who receive Red Hat source code in the awkward position of either never releasing any binaries based on that source code in order to remain in compliance with the Red Hat EULA on the binaries, or breaking the EULA in order to comply with the GPL.

The irony is that if the covered code was not under the GPL (like it were BSD license or something), then they would be able to distribute the software based on Red Hat source code in binary form without sharing the source to comply with Red Hat's EULA. But since the GPL requires them to do that if they modify the source code and redistribute, they are effectively forbidden from modifying or redistributing the software to non-subscribers at all if you combine the restrictions of the EULA and the GPL. That is, they violate the GPL if they don't share modified source code, and they violate the EULA if they do share it. So in theory, once they have the source code, they are free to do as they wish with it, it's just that if Red Hat finds out that you exercised your rights under the GPL, they will terminate your subscription and make sure you don't get that chance again. And if you share binaries built against RHEL sources without sharing the source code, then you are violating the GPL, and they can get you that way.

It's not within the spirit of the GPL, but I think this is the way the law works at least in the US. Your right to a copy of the source code under the GPL only begins once you have the binaries built against that source in hand, and only those to whom it has been "conveyed" have a claim. By limiting who they convey binary files to, to those licensed to receive them, they also limit their own legal liability for providing source code. However, this may actually not be enforceable in other countries. It's mostly US law and US precedent at work here, and some other countries might say that the GPL grants rights to all, regardless of whether they have the software in hand, and regard Red Hat's EULA as interfering with that.

But for the moment? Red Hat's EULA acknowledges that the GPL will grant you the rights to redistribute the RHEL sources upon receipt of the RHEL binaries, and that they will honor the GPL by giving you, the subscriber, access to the source code... but also tells you that if you are caught exercising your right to redistribute that source code, your license agreement will be terminated, and you will not get updated binary files (or sources) from them. So as it stands, the user has the freedom under the GPL to redistribute the source code (after receiving binary files), and Red Hat has the freedom to deny you access to future binaries (and therefore source code) if you exercise that freedom. It's like the old adage, "You are free to exercise your rights, but you're not free from the consequences of doing so." Like for instance, if you work for a company and you speak negatively about them on social media... they can fire you for it. You still had a right to free speech, but they also had the right to fire you for exercising it in a way they didn't like. You cannot be imprisoned or face legal consequences, the only consequence was it adversely impacted your contractual relationship with a private company. And yet that still has a chilling effect on free speech.

Each time you convey a covered work, the recipient automatically
receives a license from the original licensors, to run, modify and
propagate that work, subject to this License.
{...}
You may not impose any further restrictions on the exercise of the
rights granted or affirmed under this License. For example, you may
not impose a license fee, royalty, or other charge for exercise of
rights granted under this License,{...}

To protect your rights, we need to prevent others from denying you
these rights or asking you to surrender the rights. Therefore, you have
certain responsibilities if you distribute copies of the software, or if
you modify it: responsibilities to respect the freedom of others.

Off-topic:
My understanding of this, is that Red Hat would be in violation of the GPL if they tried to charge a fee to those who violate their EULA. Just terminating the EULA because they don't like that you exercised your rights under the GPL doesn't legally count as a restriction. So yes, they cannot restrict what someone does with the source code once they get their hands on it. Once it is leaked, it's out there and they have no control. All they can do is make it really inconvenient for downstream rebuilders to keep up with RHEL development and try to keep source code for security updates under lockdown for as long as possible. The code WILL eventually leak, no doubt about it, but by that point RHEL would have had the security updates for a few days or so, and downstream rebuilders might have had to wait a few days for that code to leak. That's a big deal in the enterprise space, they won't like these delays in getting security updates. Red Hat's main goal here is to make things as painful as possible for downstream rebuilders of RHEL, not to prevent the source code from getting out at all. All the source code that goes into RHEL has to pass through Fedora anyway, so it's only a matter of time before people figure out which commits to Fedora made their way into RHEL, but in the mean time RHEL moves ahead faster than the competition that has been given a handicap.

[Moonchild]

Off-topic:
I see, that clarifies things a bit. So, it's a matter of treating it like a petty revenge, by basically blacklisting anyone who exercises their right to distribute the source code to others once the have it. Really makes me wonder how many customers they want to lose...
Strictly speaking, that isn't black and white a violation, but it does go directly against the responsibility to not restrict freedom that is in the actual license. It's definitely something that could be litigated as a result since they may not be breaching individual points by "cutting people off from future releases" but they are effectively breaching the license in a general sense in that they are not adhering to the overall intent and interpretation of the GPL. Also, denying access to releases for exercising one's clearly stated rights is probably a form of coercion that's likely covered by consumer protection laws as well... Tricky, tricky. I hope they know what they are doing.

So, given all that and how difficult Red Hat/IBM can (and will) make it to properly release derivative works by the looks of it, should I consider other alternatives?

[athenian200]

So, given all that and how difficult Red Hat/IBM can (and will) make it to properly release derivative works by the looks of it, should I consider other alternatives?

Well, do you mean other RHEL clones, or different distros all together?

If you mean distros that aren't based on RHEL at all, there really aren't many good alternatives that don't cost money. The most promising is openSUSE Leap, which is free and is not a rolling release, but only gets 3 years of support at a time. While SuSE Enterprise Linux (the good one that gets 10+ years of support) costs money just like RHEL. Which is a shame, because otherwise I would think SuSE Enterprise Linux Server was a perfect drop-in replacement for RHEL, filling a similar niche. And Debian-based distros are just something I wouldn't want to trust for production use in servers. Ignoring ideology and price, and just focusing on what I'd consider most stable, I'd want RHEL or SuSE Enterprise if I could get it.

My opinion is... more than likely there will be multiple forks of RHEL that slowly diverge from RHEL, and the hard part is predicting which one will get the most backing and trust from the FOSS community in light of Red Hat's fall from grace, because that one will effectively become the new RHEL over time, to the point that RHEL itself will have to worry about compatibility with it. My bets are on Rocky... if Rocky can't do it, I really doubt any of the others have much of a chance. I really don't get why people are excited about AlmaLinux, given that the company behind it produces Cloud Linux and has their own premium Linux server offerings and is probably just trying to capitalize on Red Hat's bad PR.

The fact that there is no good, stable alternative to RHEL and its clones for Linux right now, is precisely why so many companies are throwing their hat in the ring to preserve something compatible with the free RHEL clone ecosystem that previously existed, even if they charge for their own Linux distros. For instance, CloudLinux and SuSE both charge for their own premium offerings but have free forks of RHEL (AlmaLinux and SUSE Liberty Linux). This is probably to generate goodwill but also as an enticement to get people interested in their own enterprise offerings. IBM have created a vacuum in the market that there is a big incentive to fill. I believe the end goal for AlmaLinux is to get people to migrate to CloudLinux after they see that the RHEL clone ecosystem is busted, and the end goal for SUSE Liberty Linux is probably get to people onto SUSE Enterprise Linux.

So I guess my last word on the subject would be, within the RHEL clone space, I'm looking at Rocky Linux and Oracle Linux, because both of them have a lot to lose if that ecosystem dies entirely. And outside of RHEL, the only alternative I see as worthy of consideration is SUSE Enterprise Linux, which is pretty much European Red Hat. SUSE does offer a better deal with openSUSE Leap, than Red Hat does with Fedora. Fedora releases only get about 1 year of support, while OpenSUSE Leap gives more than that. CentOS Stream gets about 5 years of support, but is a rolling release only.

I don't know if any of that was helpful, but it's all I really have to offer, since I have been following what's been going on in this space for a while.

[andyprough]

And Debian-based distros are just something I wouldn't want to trust for production use in servers.

I'm sure you have your reasons for saying that, but from my understanding Debian has been picking up more CentOS refugees than Alma or Rocky. And I personally know of nothing that would make one not trust Debian for production use in servers, given that it is legendary for its server uptime over the past 30 years - but again, I'm sure you have your reasons.

[athenian200]

I'm sure you have your reasons for saying that, but from my understanding Debian has been picking up more CentOS refugees than Alma or Rocky. And I personally know of nothing that would make one not trust Debian for production use in servers, given that it is legendary for its server uptime over the past 30 years - but again, I'm sure you have your reasons.

Yeah, the thing is, Debian has historically been far more focused on purity than on practicality. I would say it's a fine choice for some servers if they are advanced Linux users, but I don't think it's anything like the level of polish something like RHEL or even SLES has. Like, I wouldn't go so far as to say Debian is a bad distro overall if you are just an individual user or developer, but RHEL is pretty much the reason why Linux was able to replace Big Iron Unix systems like Solaris, HP-UX, and AIX. It was highly standardized, polished, and focused on the needs of enterprise, and was at the forefront of the first attempt Linux made to create its own equivalent of POSIX or SUS, the LSB.

But I think that without RHEL as a stabilizing force, there is a real risk of Linux returning to form as the chaotic mess that simply isn't suitable for enterprise needs that it was before, unless enough other organizations come together and build an open standard based on what RHEL was doing up until recently. The loss of Red Hat's credibility is a bigger deal for the broader Linux community than I think a lot of people realize. Maybe it's the circles I run in, but a lot of sysadmins I know are so disgusted with this CentOS drama that it became their excuse to convince their bosses to pay the cost of going back to paying for Windows Server/Enterprise licenses. A lot of people have no idea what to do now, a lot are seriously trying to convince their bosses to buy RHEL licenses to avoid downtime and retraining costs, some of them are looking at CentOS Stream seriously, some of them are considering just using Fedora, some of them are considering migrating back to Windows, some of them are looking at SLES, some of them are looking at Oracle Linux, etc. Some are just so sick of the Linux community's fragmentation they are talking about FreeBSD. But I haven't heard anyone I know say they want to switch from CentOS to Debian. That said, I'm sure you are correct there are a lot of people out there who would, since Debian was always the other big distro besides Red Hat.

Like, if you look at this TechRepublic article, this is a good example of where most people's heads are that I know regarding the CentOS debacle:

https://www.techrepublic.com/article/ce ... ernatives/

It seems that in those circles at least, paying for RHEL is seen as the safest option, switching to Oracle Linux is seen as the second-safest option, Alma and Rocky are both seen as unproven (though I am thinking that's more because of the support contract issue than anything else), and a lot of them are seriously considering just using Fedora to stay with something familiar even if it means they are stuck being beta testers for IBM. And this obviously doesn't take into account the people who are considering switching to SLES, going back to Windows Server, or trying FreeBSD. I'm sure Debian is up there too, but I think for every former CentOS user that goes to Debian, there could be another that's giving up on Linux as a reliable server OS altogether.

[andyprough]

Yeah, the thing is, Debian has historically been far more focused...

Those are interesting comments, I did not know there were still places in the world that held RedHat support in such high regard, I've heard mostly complaints about lack of support. That was one reason so many were using CentOS - why pay RedHat for nonexistent support? I also haven't talked to any sysadmin in ages that wasn't already running numerous Debian boxes in their mix. I guess your world of Big Iron is a very different crowd.

Anyway, sorry to interrupt, I haven't used Debian or RedHat myself in a long time so this is nothing to do with me.

[Moonchild]

some of them are looking at CentOS Stream seriously

I really don't think CentOS Stream is suitable for anything but dev machines. It's basically alpha testing/running master branch builds. I do not believe it's stable enough for actual production use on servers that serve the public.

this is a good example of where most people's heads are that I know regarding the CentOS debacle

Informative, and thanks for reminding me to keep Oracle Linux in my mind as an alternative, as well. I had all but forgotten about their free-to-use offering.

I'm aware of the Debian alternative but as said in my opening post I'd prefer avoiding retraining myself on Debian or Debian-based setups. While Debian is stable if you designed your workflow around it, it's not as accommodating as RH based distros otherwise, I'm afraid. I've worked with it on production servers in the past so I am familiar with it (at least with past versions), and would consider it as a fallback if the RH-based ecosystems completely fall apart, but not right now.

Things are a bit rocky at the moment (pun intended), so I'll probably wait out a few more months at least to see where Rocky and Alma land in terms of development stability and inherent risk; the RHEL lockdown is a recent development and things are still quite turbulent.

Feel free to continue discussing alternatives, I'll certainly keep an eye on this thread.

[athenian200]

Those are interesting comments, I did not know there were still places in the world that held RedHat support in such high regard, I've heard mostly complaints about lack of support. That was one reason so many were using CentOS - why pay RedHat for nonexistent support? I also haven't talked to any sysadmin in ages that wasn't already running numerous Debian boxes in their mix. I guess your world of Big Iron is a very different crowd.

Off-topic:
Oh, they don't necessarily hold Red Hat support in high regard. The reason they want RHEL is because they want a very standardized, polished product that gets security updates regularly, and that large numbers of people are trained on. The fact that RHEL and its clones were so ubiquitous and were kind of becoming a proto-standard for enterprise Linux meant that you could turn to a lot of places for support. And if CentOS was available for free and could benefit from the large number of people trained on RHEL, then all the better. The reason they are seriously considering paying for RHEL now is because they fear IBM is going to cut them off from critical security updates and introduce delays or potential incompatibilities into the process if they don't, and a lot of them are shrugging seeing this as basically going back to having to pay for site licenses to stay on something familiar, rather than as paying for support. Normal Linux users/admins would just balk at this and switch to another distro, but that is just not how these people in enterprise think. For them, Linux is RHEL and its clones, and this standardized Enterprise Linux thing people are trained on and for which support is easy to obtain from multiple sources. Switching to a distro that's not identical to RHEL, would be a very a big deal, almost at the level of switching to a new OS for a normal person.

I really don't think CentOS Stream is suitable for anything but dev machines. It's basically alpha testing/running master branch builds. I do not believe it's stable enough for actual production use on servers that serve the public.

I would agree, even though I know people doing it, I can't say I recommend it.

Informative, and thanks for reminding me to keep Oracle Linux in my mind as an alternative, as well. I had all but forgotten about their free-to-use offering.

Yeah, no problem. I just happened to be familiar with it due to my background, and am finding that it is becoming oddly more relevant now that CentOS is off the table. My only real experience with it is using it to build Epyrus, admittedly, but it seems to pretty much work the same way as CentOS in that regard.

I'm aware of the Debian alternative but as said in my opening post I'd prefer avoiding retraining myself on Debian or Debian-based setups. While Debian is stable if you designed your workflow around it, it's not as accommodating as RH based distros otherwise, I'm afraid. I've worked with it on production servers in the past so I am familiar with it (at least with past versions), and would consider it as a fallback if the RH-based ecosystems completely fall apart, but not right now.

Off-topic:
Yeah, this is exactly the issue people have with Debian. RHEL became the standard, and CentOS only accelerated that trend. Debian is absolutely fine for people that were already trained on it, but the problem is that we have so many IT people in the world trained only on RHEL/CentOS that switching to something like Debian would be more expensive for a big corporation than paying for RHEL, and IBM knows it.

Things are a bit rocky at the moment (pun intended), so I'll probably wait out a few more months at least to see where Rocky and Alma land in terms of development stability and inherent risk; the RHEL lockdown is a recent development and things are still quite turbulent.

Feel free to continue discussing alternatives, I'll certainly keep an eye on this thread.

That's probably for the best. CentOS 7 will be supported until next year, and I think the end of support for CentOS 7 will be when we see a lot of people make their final decision on what alternative to support. I don't actually see a total collapse of the RH-based ecosystem as very likely, but right now there are a bunch of alternatives and it isn't clear which one the community will place their faith in. There are a lot of enterprise-oriented Linux players who would love to become the new upstream for something like Rocky and thereby establish themselves as the new standard and take over the position Red Hat once enjoyed. It's why you're seeing the CloudLinux people release AlmaLinux, Oracle reminding everyone Oracle Linux existed before CentOS and has now outlasted it, and SUSE going private and putting a lot of money into SUSE Liberty Linux. All of Red Hat's competitors now have a reason to work together and establish a standard for enterprise Linux.

Off-topic:
This wouldn't be the first time IBM managed to unify all their competitors around a standardized architecture, by attempting to kill off clones of a popular product they made, though. Remember the battle between MCA and EISA? https://en.wikipedia.org/wiki/Extended_ ... ng_of_Nine

[andyprough]

Normal Linux users/admins would just balk at this and switch to another distro, but that is just not how these people in enterprise think.

Ahh, I get it, I'm talking to people who live and breath GNU/Linux and have been for decades. The folks you are talking to mainly know it in terms of their job and job training. Makes sense now.

Seems like Canonical should be in this conversation. They offered me a setup through Ubuntu Pro (or whatever they call it) recently that had eye watering enterprise tools and very lengthy extended support. I was quite intrigued as the setup has one killer feature I could really use and advertise to customers, but I've been doing OS minimalism for so long that it would be a significant paradigm change for me.