Now they can actually be a real distribution and a true member of a community. They can make contributions, fix bugs, and add extras if they choose.
Now they will be “based” on RHEL ( ABI compatible ) but not “identical” per se.
This is what Red Hat wanted to happen. Hopefully this puts an end to all the Red Hat has gone proprietary nonsense as well. Pretty much everything Red Hat does will go into Alma as well. Alma will be built on the back of Red Hat’s efforts but it will be in a proper community way and they will share code and not just directly rip off the whole distro.
I literally love this take, because it can't be more wrong.
Most of the CentOS, Alma and Rocky Linux users used these distributions, because they were able to find their way and fix their problems without asking RedHat's help, and RedHat was explicitly saying that they're selling the "support", not the distribution.
Most of the people managed these systems had the chops to rebuild everything from bottom up, if required, and report the bugs the correct places to support everyone, including Red Hat.
Red Hat changed its stance overnight and decided to sell the distribution instead of support, closed the SRPMS they provided, flipped the table and screamed "Thieves!".
It's funny and sad at the same time. They started this model, lived in a win-win relationship for two decades, and changed their minds overnight like a drunk sailor, because IBM wanted more monies.
This will be very harmful to everyone involved in this in the medium-long term, because RHEL will lose the mind share which supported them on the enterprise space.
IBM's software products may be locked to RHEL in the short term, and a RHEL license have to be bundled with their sales, but it'll be a niche, dark room distro, not a well known one.
We'll see how Fedora will fare from IBM "Community"'s bright ideas like "opt-out before the first send" telemetry.
Being a corp slog nearly my entire life, it's good to stay open to all opinions. With that I say, that I have encountered piles of fraud with organizations in my career. They would buy a couple licenses of RHEL when their fleet was really CentOS and they would just lie on support calls. I think this is what Red Hat was getting at with all the "freeloader" nonsense. Tone deaf, yes. Wrong, not totally.
...continuing to be fair, Red Hat support has literally been the best I have ever used in my career. Hands down. I know I sound like a shill but I'm not. Just a reg ol' engineer. I've since moved on, like most, to cloud and past RHEL but it has it's uses. Cattle not pets for cloud!
Regarding the "freeloaders" comment, Mike McGrath made a follow-up post on LinkedIn that includes the following:
> Finally, I wanted to say something about the term "freeloaders" I've seen many use it. This is a mostly internal term we have at Red Hat, it looks like at some point it slipped out in the public. So what does it mean? A freeloader is when a large enterprise business has 20 RHEL licenses, 150,000 community rebuild systems, and sometimes hundreds of user accounts and hundreds of kbase searches per month. It's not the enthusiasts, it's not the hackers and coders, it's not the academics, and it's not the people that use rebuilders because they can't afford it. We really try not to use the term, but when we do, it's about the large companies that can afford to pay but don't.
Alma and Rocky directly competing with RHEL, undercutting RH's business by rebranding RHEL clones to sell cheaper support (since they don't suffer RHEL development costs) is what changed.
Sorry, no. Red Hat broke the spirit of the GPL. The social contract of FOSS is not that you get guaranteed a viable business model or maximum profit.
Red Hat went as far as they could without breaking the letter of the GPL. They likely would have gone full proprietary if they could have legally done so.
Whether you see a problem with that depends on your values. A new school of thought has arisen, let's call it COSS - capitalist open source software, in which the purpose of open source is for large companies to flood the market with a loss leader to kill off smaller competitors, and for individuals to pad their resumes.
Under COSS, open source is merely another tool to feed the capitalist machinery, so Red Hat's strategy seems only natural. But many of us do not share these values.
Isn’t GPL the HN’s favorite boogeyman? Boooooo, the license is not permissive enough. Boooo, is not true freedom. Boooo, whatever shall my poor startup with millions in funding do if it’s GPL. Booo, but what about all those lost exposure points because Amazon/Google won’t be using it.
But look how are the tables turned if it’s some other guy exercising his rights.
> But look how are the tables turned if it’s some other guy exercising his rights.
If we're talking about IBM/Red Hat here, they are not exercising their rights.
Can they close the SRPMs? Yes they can.
Can they tell "You can't redistribute this GPL licensed source code", haha, no.
They can't even tell you to not redistribute BSD/MIT/Expat/WTFPL[0] code. They can't override these legal texts with EULAs.
GPL is working as intended, and irritating corporations the way it should, and yes, what Red Hat done is treason, not because they closed the SRPMs, but the collective things they did.
Red Hat's customers still have the right to redistribute the GPL-licensed source code from RHEL, but Red Hat may end their business relationship with them if that right is exercised. This is still in line with what the GPL requires of Red Hat.
> I still need to read and see the agreements myself.
See the 'termination' section of the enterprise agreements from the Red Hat licences page.[1] What constitutes a material breach is specified in Appendix I from the Product Appendices section, and it includes the redistribution of software obtained through the subscription (sections 1.2.f and 1.2.g of Appendix I).
> How this is ethical, and allows unimpeded distribution of FOSS code?
It is designed to discourage the distribution of the code while keeping Red Hat in compliance with the GPL. So it cannot prevent the customer from exercising their GPL rights, but a continued business relationship with the software vendor is not something that the GPL protects. PaX/grsecurity had used a similar tactic with their Linux kernel patches.
That's what most are concerned about. For a company that markets themselves as "open" or "the open source company", seeing their original massive OSS project now only achieve what's 'required' and nothing more... that doesn't seem in line with the expectation set over decades of more magnanimous behavior before.
> seeing their original massive OSS project now only achieve what's 'required' and nothing more
If they were only doing "what's required" they would have ditched their upstream first approach to fixes and the only ones seeing their code would be paying customers, or people who the paying customers distributed the code to. The fact that they are still one of the primary contributors not only to the upstream linux kernel but countless other open source projects pretty much by definition means that they are still going well above and beyond "what's required". If you don't like their direction, fine, but pretending like they are entirely freeloading and doing nothing for the broader open source community really weakens your position.
One thing I've been wondering--if a RH customer decides to surreptitiously distribute the source, how is RH going to know which customer did it? I guess they could do something like making each copy of the source unique by slightly varying the non-string white space in the code.
I guess the other issue would be that distributions like Alma or Rocky (and, to varying extents, their users) probably value stability and reliability too highly to be comfortable relying on such a janky form of source distribution.
So AlmaLinux decides to stick to CentOS Stream (which "sits" between RHEL and Fedora in terms of "stability" as I understand). Basically what RHEL wanted these clones to do.
Rocky Linux on the other hand seems to take a more adventurous path by teaming up with SUSE on the new RHEL fork, whenever that comes. In the meantime it's not 100% clear how Rocky will continue working (they referenced some workarounds but not specifically how they'll get the source code from RHEL).
Oracle and Rocky say they will continue to duplicate RHEL exactly ( though Oracle never duplicated the RHEL kernel ).
SUSE says they will “fork” RHEL with it being a bit unclear if this will be a “bug for bug” copy or not.
Alma will base off CentOS Stream to create a distro that is RHEL ABI compatible.
Of all these, I think the Alma path best reflects the community values that everybody has been on about. The others are driven more by commercial interests than “community values”. That is ok, as long as you are honest about it.
> The others are driven more by commercial interests than “community values”.
The first time I read this line, it didn't sit right with me... but after thinking on it, you're not wrong. I don't think Rocky's choice to stay bug-for-bug is necessarily driven by commercial interest, at least not overtly.
One of the big benefits of "bug-for-bug compatibility" with a support-licensed "Enterprise Linux" is the fact that you end up with an incredibly broad user base running the same systems code everywhere, whether or not they're paying for support. This means that non-licensed systems are helping to uncover bugs and incompatibilities, and it also means that issues reported by enterprise customers and fixed by RedHat get filtered out to everyone else as a matter of course.
At the end of the day, yes: commercial interest is the common factor underpinning this mechanism. However in Rocky's case (as with the original CentOS before being EEE'd by RH/IBM) the conscious motivation is to build something that brings a maximum number of people together in pursuit of a stable, production-ready Linux distribution. And even if the result is "we do this because it helps our users make or save money," as you said -- that's okay.
> (which "sits" between RHEL and Fedora in terms of "stability" as I understand).
There is no meaningful upstream link between Fedora and RHEL after a RHEL release has been forked off, so it doesn't make any sense to say that CentOS Stream sits between Fedora and RHEL.
Basically: Red Hat takes a Fedora release, heavily tweaks it, and makes a new version of CentOS Stream. After hardening, that version of CentOS Stream then becomes the basis for a new major version of RHEL. Thereafter, that version of CentOS Stream is the upstream for "minor" releases of RHEL.
Patches which are destined to land in that release of RHEL, go through the standard testing process, and land in CentOS Stream (aside from embargoed security fixes that hit RHEL first, then Stream). It's the one and only "direct" upstream of RHEL, and it's a very close upstream. Closer than, say, Debian Testing and Debian Stable. It's more like if you had Debian Stable and then there was some additional variant of Debian which just ensured that everything apart from security fixes was held back until fixed-interval point releases.
This isn't true. Firstly Fedora is always the start of the next version of RHEL. Secondly even for the current RHEL all changes go upstream first, which means they go into Fedora. Thirdly there are some packages which are rebased to Fedora every minor RHEL release (I know of the mingw packages, and a lot of the virt stack, but there are others too).
Rocky Linux has not teamed up with SUSE. The announcement from SUSE included that CIQ is teaming up with them. CIQ != Rocky Linux. CIQ != the Rocky Enterprise Software Foundation. We might use whatever they come up with to make an additional distro later.
Rocky Linux, as it is, will always be 1:1 with RHEL. We are dedicated to providing 1:1 "bug for bug" Rocky Linux, for both 8 and 9, for the full duration of their life cycles. Broken promises from CentOS are the reason we started Rocky Linux in the first place, we're not going back on anything we've already committed to.
I believe we (Rocky Linux) were pretty specific about how we're getting source in the announcement at <https://rockylinux.org/news/keeping-open-source-open/>. SRPMs from UBIs, cloud instances, etc. The only intentional omission are the additional legal loopholes we've discovered to get source, that we're keeping in our back pocket. We want to keep those backup methods to ourselves so that Red Hat doesn't close off too many at once, should they choose to try to screw over our community again in the future.
Adoption by many large organizations / businesses was also quite fast. And may have even caused us some trouble, I suspect the attention garnered by NASA's use of Rocky Linux had something to do with instigating Red Hat's recent antics.
The charts really look impressive. I didn't expect such an uptake. The funny thing is, people have tried it first (ephemeral instances), then started to migrate.
Fascinating. No wonder why Red Hat got a little irritated.
The difference was painfully obvious about 3-4 months in, this only confirms it. Everyone here keeps asking why would one pick AlmaLinux over literally anything else, while I'm sitting here asking myself how would anyone risk running his business on a distribution built on such a shady foundation, from sources obtained in a metaphorical back alley. Feels like a lawsuit waiting to happen, I wouldn't want to be on the receiving side of that for sure.
We participate in the Enterprise Linux community just fine. Our community members report bugs and throw patches at upstream projects, run SIGs creating value for EL, maintain Fedora and EPEL packages, etc.
You're talking about the users' community (and I have nothing to complain about that) and generic upstream; however I am talking about the builders' community instead.
Can you elaborate how the patches, bug reports, package maintenance, etc, do not benefit the "builders' community"? They all go to the same upstream.
And what exactly do you mean by "builders' community", do you actually mean "Red Hat"?
By "not participate in" do you mean "not pay your employer"? Which we do, actually. Just wired a good chunk of money to Red Hat the other day, ostensibly earmarked for supporting the Fedora project.
The builders community is where the next EL is built. It's Fedora ELN and CentOS Stream. You made your choice to keep focusing on "bug-for-bug" downstream instead, that's fine but I like it less than working together with Red Hat, Alma, Facebook, Intel and others.
Red Hat's action didn't screw over the builders community. It did complicate things in the short term for part of the users community, but at the same time it showed a clear way forward for builders that would not screw over users. Red Hat's intention is to stick to what they have been saying for three years and coalesce builders around Fedora ELN and CentOS Stream; not to screw over users.
Hence my original remark: if you think all Red Hat wants is to screw over communities again and again, your definition of community is not the same as mine.
> ostensibly earmarked for supporting the Fedora project.
Thanks for that. I never said you don't support the rpm-/Fedora-based ecosystem as a whole, and I appreciate that you also do so monetarily.
This is the dichotomy it pains me to see. Users who contribute are builders. That's the open source way. You don't have to be on a SIG or involved in the monthly meetings of an advisory council to contribute value to open source projects.
Maybe this dichotomy prompted the whole "hackers and hobbyists" imagined threat.
By builders I mean specifically those users that work with the full set of RPMs of the distro. It's not a badge of honor, it's a specific and very specialized way to consume what a distro offers.
In the case of EL, Fedora and CentOS Stream are communities that office both users and builders, but the two groups congregate in different places. For example EPEL is targeted at the user community but it is outside the focus of the builder community. ELN is of interest to builders but it is outside the focus of the user community.
All users can choose to contribute (with bug reports, code, whatever) at either the upstream or the distro level; or they can just be users. Builders are a (very small) subset of the people who consume a distro, and like all users they can choose how much to participate in the community and whether to be contributors or not.
But that ship sailed, the good of the downstream users' contributions are not enough to cancel out the negative net value of the builders' bad behavior.
I absolutely haven't said I consider builders bad and I also was careful not to say rebuilders! I am being very careful with my words. Please don't put things I didn't say in my mouth.
However: unfortunately part of what you said is true. Red Hat apparently took this decision because of some new facts that caused the negative from the "rebuilders" to increase, and the decision had the potential of hurting the users of the rebuilds.
Fortunately it's clear now that there are multiple ways for the downstreams to adapt[1]. Users will be able to keep their distros and—if they wish—contribute in a number of ways to the community. And builders and Red Hat will be able to collaborate in a shared place which is ELN for major released and Stream for minor releases. In a sense this removes excuses from Red Hat and should make everyone feel safer.
[1] you could say despite Red Hat's change, and I accept that. But it's also thanks to Red Hat going overall beyond the requirements of the open source licenses, with things such as Stream and the UBI source container.
I know reading is hard, but the Rocky Linux project and SUSE have not teamed up. That is an entirely CIQ endeavor. The project's blog post from some time ago also explains the two avenues they're going down for their clone.
P.S. for other commenters. A fork is NOT a distro. If someone forks a project (as the shape of a fork implies), they go their own way. So if Oracle and SUSE fork RHEL, good luck on standardizing "enterprise" Linux.
Fedora and regular CentOS Stream aren't ABI compatible with RHEL. With AlmaLinux being based on the equivalent upstream RHEL release, most software should work like on RHEL. (That's because small differences in security fixes don't usually impact whether programs work (that's the entire point of them).)
At least that's my understanding fromwhat I've read.
CentOS Stream is ABI compatible with RHEL. It has to be, because RHEL minor releases are produced from CentOS Stream. Nothing can go into Stream that wouldn't go into RHEL.
> In the meantime it's not 100% clear how Rocky will continue working (they referenced some workarounds but not specifically how they'll get the source code from RHEL).
Weren't they spinning up virtual machines on public clouds, running their scripts, and getting the source from those VMs?
This is a good move. And people will figure out that bug-for-bug compatibility doesn't really matter in practice, binary compatibility and long-term support do - if this weren't the case, the whole Debian ecosystem wouldn't exist.
Now, this won't do down well for those who use RHEL-clones for the "free as in beer" aspect. They can choose Rocky Linux instead. At least now there's some identity separation between the two.
The fact that there's a need for such fine-grained compatibility with other linux system goes against quite a few of well-established software principles.
Most linux software is extremely portable and runs on probably all POSIX compatible systems already.
I never understood this need to make "bit-fot-bit" clones of one particular distro - RHEL. I've worked with "enterprise" Linux for a decade now, and I'm totally fine if my stuff is debian-esque or ubunt-esque. Sure, there are libcpp and other shared libraries that need to be compatible if trying to run the same binary of some programs on different distros but it's been a really fringe case.
Many vendors of enterprise software have supported operating systems. Though it seems odd that this is still a thing in the world of containers we now live in.
Meh... there are plenty of (better) fish in the "do your own thing" sea. The thing that actually made CentOS, followed by Rocky+Alma compelling to anyone was the 1:1 bug compatibility with RHEL. Not sure what use-case exists for Alma once they are nothing beyond a mere knock-off of CentOS stream. Like why would you ever pick *that* over literally anything else?
CentOS Stream doesn't do minor releases and I assume AlmaLinux will continue making minor releases as they already do. Not everyone cares about that but some will.
- Provide a maintenance period beyond what CentOS Stream provides.
- Potentially hold back CentOS Stream updates to stay more in sync with RHEL. If RHEL is on X.Y, CentOS Stream is technically on X.(Y+1) - Alma wants to be X.Y compatible.
- Provide ABI compatibility with RHEL which CentOS Stream may not provide.
The AlmaLinux Infra team lead posted on Reddit that they are planning on supporting AlmaLinux for the full 10 year release cycle[1]. Seems like it could be a lot of work, but also maybe an opportunity for Red Hat collaborate and ensure the RHEL sources are continually pushed back upstream for the full maintenance period of a RHEL release (even if point releases are no longer maintained).
From my experience not all enterprise software is designed or packaged with Debian in mind.
Some of the tools I installed and supported are RHEL first and RHEL only software which require exacting ABI and even library versions to run correctly.
Debian is a great server, and has great support, but being one of the best doesn't always cut it.
Doesn't this fragmentation of RHEL clones mean that this exact thing will have to change? Not from Debian perspective, but others ignoring Debian and other distros and treating RHEL as a "linux standard" will have to often be revised.
I don't think so. These are extremely expensive software packages, generally bought by corporations with very big budgets.
These people either pay Red Hat good money for license, or pay good money for a sysadmin who knows what they are doing and install this software on a RHEL downstream distribution.
Sometimes you get a package deal. Hardware + RHEL + software package, which serve a group of engineers or researchers.
IBM is after this revenue. Universities and other research institutions won't care on the long term, because they can migrate piecewise, and group by group. They don't have an official favorite. They use whatever they like and works on their computers generally.
However, bigger research communities like national HPC centers, CERN, NASA, etc. used RHEL and alike, because they get unofficial, sometimes free or almost free support from Red Hat themselves, and they have a sizeable stack built on top of that.
They can and some of them will of course migrate, but it'll take time, and create pain down the road. We'll see.
CentOS Stream has essentially the same release model as Debian. If you're fine with switching from RHEL to Debian, what is the problem with CentOS Stream exactly?
> Almost every major open-source project is actively contributed to by Red Hat, or has been at one point.
That's nice... but Redhat's entire business is also built on the open source software contributed by tens of thousands of others, much of it licensed to them under copyleft terms like the GPL. Yes, RedHat absolutely did contribute immensely to that ecosystem, but once they (or corporate-daddy IBM) decided to take a big fat stinky dump in the collective sandbox and stopped sharing their toys, the rest of us are kinda allowed to be pissed at them, no?
"We will give you the SRPM because we legally have to, but if you actually exercise any of the rights afforded to you by the GPL that software was licensed to us under we will immediately terminate you as a customer" *may* (a court will ultimately decide) fit into some legal loophole that exists in the void between contract vs. copyright law, but it certainly does violate the spirit of term#6 of the GPL, i.e. "You may not impose any further restrictions on the recipients' exercise of the rights granted herein".
RedHat pulled what is commonly known as a "dick-move". Ef them and the horse they rode in on.
> RedHat pulled what is commonly known as a "dick-move"
I'm sorry, but isn't that EXACTLY what CIQ has been doing with Rocky Linux. Taking RHEL, rebranding it and then undercutting Red Hat on support contracts? Sure, it was always completely legal and even to some extend supported by Red Hat, but the support contracts is probably what drove Red Hat to make this move. What the hell would Rocky Linux even do if they where successful enough and Red Hat went out of business?
Just replace Rocky and Alma with Oracle in any of these complaints and all of the sudden people starts having less sympati.
If people are so upset, why didn't they migrate to something like Debian or SuSE when CentOS got axed? I really don't see why people want to stick with a RHEL clone when they're are so upset with the company behind most of the work.
> If people are so upset, why didn't they migrate to something like Debian or SuSE when CentOS got axed?
Many people did. The remainder were too tied up in the RHEL ecosystem (including CentOS) to make the move, but red hat's recent shitcanery will push many more away.
As far as I can see Fedora and Stream still exist. You're basically talking about ~6 months of stable branch work that Red Hat would like to keep confined to their paid product.
> You're basically talking about ~6 months of stable branch work that Red Hat would like to keep confined to their paid product.
Sure. The GPL doesn't have a carve out for "but we'd really like to not be open source for a little while". (And if you threaten your customers for actually exercising their rights, I struggle to believe that you're complying with the license.)
> RedHat pulled what is commonly known as a "dick-move". Ef them and the horse they rode in on.
To be fair, nobody forced you to use RHEL. Nor is RHEL a prerequisite to using the open source software that RHEL depends on.
> That's nice... but Redhat's entire business is also built on the open source software contributed by tens of thousands of others... "We will give you the SRPM because we legally have to, but if you actually exercise any of the rights afforded to you by the GPL that software was licensed to us under we will immediately terminate you as a customer"
I'm sorry but your reasoning doesn't make much sense. We all should have the right to cease to do business with anyone for any reason, whether it's a good reason or not. I don't think that is a right that we should be so quick to abolish.
Your rights to the source are not being infringed. Yet you want to force RedHat to do business with you on your terms, and in so doing deny them their right to cease to do business with you for any reason.
How does their right to cease to do business affect your ability to distribute/modify the source? It does not, not any more than a pizza shop's refusal to continue to do business with you affect your ability to take home and consume a pizza you bought.
If, by analogy, buying one pizza gives you a perpetual and unconditional right to demand that you be served another pizza, I don't see how such a line of reasoning could be implied as a violation of your rights rather than theirs. Put another way, your rights to the source doesn't translate into a right to perpetual service.
>Furthermore, Red Hat is the top commercial contributor to the Linux kernel
This is a little tricky to define. By line count or commit count, it usually isn't, however the "top" contributors by those metrics are often hardware vendors committing large quantities of auto-generated hardware definitions in the form of header files, such as the AMDGPU driver. Red Hat also employs a lot of subsystem maintainers, who don't contribute much code themselves, but whose work is still important.
So there's no perfect way to decide who is "top", exactly. I think top 3 would be fairly uncontroversial.
As I don't like software audits and license key activation, I do not choose it, as these are not a concern with Oracle Linux (unlike some of their other products).
>As I don't like software audits and license key activation, I do not choose it, as these are not a concern with Oracle Linux (unlike some of their other products).
> Simply register and enable the repositories that you need.
Counter offer: nah... how about I just target+deploy on any of the numerous competitors that don't make me jump through ANY licensing hoops whatsoever from here on out.
In about 2007, we bought our first Red Hat to migrate functionality away from HP-UX. We eventually rolled the license that we purchased on a credit card into the corporate account.
In about 2009, "yum update" stopped working, and I called Red Hat, where I learned that corporate had terminated the licensing. Investigating, they advised me to run the Oracle converter, and resume pulling patches.
In 2013, corporate again switched to Red Hat. I did not. Corporate has been audited. I have not.
I'm using some btrfs loopback mounts with the UEK, and sales calls with Red Hat expressed extreme distaste for this.
w/r/t btrfs - I recall when it was deprecated from tech preview in RHEL. I know some users really, really wanted it and it keeps popping up - Fedora is now using it, but I am skeptical that it's going to make it into RHEL anytime soon given that it was in RHEL as a tech preview and then pulled. I know SUSE supports it, I have a NAS that uses it, but seems like it's been found to be wanting by some of the folks who decide what gets into RHEL and doesn't.
Generally speaking, I think people have three choices: One is to pay for what you use and have a direct relationship where you have at least a little influence and stake with the company.
Another is to go with community projects where possible. If they are healthy and well-run, you should be in pretty good shape over the long run that they won't act against your interests. Here I'd look to Debian which has a very strong focus on governance and doing the right thing. (As they define "right thing" and it is well spelled out.)
Finally, do what's convenient and cheap with the realization that you will likely have to come up with a Plan B someday. This is sort of like the undertaker and Don Corleone: Someday, and that day may never come, you're going to have to pay a price and you don't know what that price is going to be.
That would be the appeal. I do not like RHEL anymore but, if I did, CentOS Strean would be a lot more comfortable and familiar than Debian. All the RHEL docs and certifications would be a lot more useful as well.
I've though about building a tool to scrape all of these Linux distro specific package changes and bug reports into a common place. It's always seemed weird to me that critical security patches are managed in obscure repos, bug trackers, internal build systems.
I don't mean every open source project needs to use GitHub but some of these home grown tools are just really hard to use. The PHP bug tracker's main page doesn't even have a link to view 8.1 or 8.2 bugs but has one for 7.2.
Last time I raised this I was told to subscribe to RedHat's notifications.
Now I get 10+ emails a day related to some Openshift module I've never heard of, and the one thing I know for sure is that it a CVSS10.0 comes in nginx out I'll completely miss it in the noise.
Until now, I was basically evenly split between Alma and Rocky Linux as my preferred successor to CentOS. This let me instantly make up my mind: I'm 100% Rocky now. The entire point of me ever using CentOS, Alma, or Rocky was to have bug-for-bug compatibility with RHEL. There are way better distros if you don't care about that.
Unfortunate, but then the question becomes, is a slightly different version of RHEL really needed ? It would make sense for everyone in the RH v/s everyone camp to band together and do one distro instead of everyone creating slightly different versions of RHEL.
And they are stopping this now. That is the question.
Not "why do you need a RHEL copy?" (which you could have asked a year ago) but "why do you need a RHEL mostly but not quite copy?"
Right, and surely there's strictly more value in having a slightly different copy of RHEL than an identical copy of Rocky etc, since now there are strictly more use cases that are being addressed?
I'm fine with not being bug for bug compatible with RHEL. The thing I'm looking for is a well defined upgrade path across major releases. Fedora has it. Debian has it. But centOS stream does not. If Alma does that then I'm happy to stick with Alma
> The most remarkable potential impact of the change is that we will no longer be held to the line of “bug-for-bug compatibility” with Red Hat, and that means that we can now accept bug fixes outside of Red Hat’s release cycle. While that means some AlmaLinux OS users may encounter bugs that are not in Red Hat, we may also accept patches for bugs that have not yet been accepted upstream, or shipped downstream.
They took the same route as Oracle, which honestly doesn't bode well for Almalinux, as I doubt users will have more confidence in Almalinux over Oracle Linux, especially when taking Oracles vast resources into account.
Cloudlinux too will start patching on their own, so Almalinux might be able to source patches from them.
Rocky seems to have some sort of partnership with SUSE, it's not clear yet what they are planning, it might become the community version of the upcoming SUSE distro but that doesn't make much sense when the openSUSE brand already exists.
Overall red hats decision made the RHEL-Like ecosystem much richer with many more active parties than before, though I think Oracle Linux is the one most enterprise software is going to support, maybe SUSEs fork too if that works out well enough.
> We will continue to aim to produce an enterprise-grade, long-term distribution of Linux that is aligned and ABI compatible with RHEL in response to our community’s needs, to the extent it is possible to do, and such that software that runs on RHEL will run the same on AlmaLinux.
I'd be interested to know if there are any cases where RHEL have issued a WONTFIX on a bug due to some software relying on the bugged behaviour. Given how much of it is free software, would they really not merge a fix into their releases to keep the bugged behaviour?
Can't imagine issuing WONTFIX but definitely augmenting the behaviour in cases where a bug becomes a feature, the whole long time support business depends on it.
I do think that use cases for Alma users are slightly different, so not having bug-for-bug compatibility might not be a big deal if most of the installed software runs smoothly.
Research center in universities, that some times need to use software for research that is only officially supported in RHEL but that does not have money to keep RHEL licenses.
One of the original RHEL clones was Scientific Linux that was maintained by those organizations for their use.
They dropped because CentOS better at the time and they were doubling effort for something that was already available.
Probably a different group of people, now. The original purpose was "RHEL clone". Now it is "RHEL-like LTS distribution," somewhere mid-stream between CentOS Stream and RHEL.
I help run a (small) HPC at a research institute and know a lot of groups in our community who run alma on their nodes. We went with rocky because we flipped a coin
This is more nuanced than you think, and probably harder than alma linux thinks.
> "AlmaLinux will no longer be aiming to provide 1:1 compatibility with upstream RHEL but will maintain a commitment to be ABI compatible with Red Hat Enterprise Linux. "
So, ABI (Application Binary Interface) means that the calls to the libraries and syscalls will remain the same. However they have leeway in the behavior between those points.
RHEL already makes this guarantees so it means they can 'build' at any of the patch points or sub-point releases. This is where they can differentiate their value.
AlmaLinux uses "release codenames" such as "Stone Smilodon". Why? What is the point of adding English (or other) release labels in addition to the sequential numeric values?
It served as advertising for Apple and Google. All these newest gadget addicts were thrilled about having "Jellybean" or "Icecream Sandwich", while having no idea what it meant at all.
A place I worked for several years used such release names, which did not actually correlate with releases of the sequential numbers, but were used as catch-all bureaucratic keywords which were applied haphazardly to IT developments.
To be fair we (Rocky Linux) also have codenames, but we only added them because some software bugged out if it wasn't present in /etc/os-release. And that's the only reason it's there, it's not really referred to anywhere else. https://git.rockylinux.org/original/rpms/rocky-release/-/blo...
I'm not sure why Alma does a new one for every minor release though.
RHEL also has codenames for major releases. 8 is called Ootpa and 9 is called Plow. Though these codenames seem to not be too public facing, they are included in /etc/os-release.
In cases like Android, the reason for having an internal codename is that you need a way to refer to the next release before the marketing department has made the final choice of the next version number.
Of course in Android's case this broke down when the marketing department started broadcasting the codenames, and even changing them. But I think they've got bored of that now.
One big shop in the MAANG doesn't plan to switch from CentOS and doesn't care about Rocky or Alma. They recently completed a 7->8 migration. Alma and Rocky primary promises were 1:1 compatibility, 10 years of stability, and supposedly better governance. But when it comes down to it, CentOS is most often first with security updates. Cent(RHEL) pushed back the EOL once, effectively nixing one of the main claims of Alma and Rocky. Both appear to me to be just duplicating effort without specializing. If they're going to innovate, they ought to be 1:1 or something else entirely, not a 95% with a bunch of special case irregularities that opens pandora's can of worms support nightmare no one wants to support.
Now they can actually be a real distribution and a true member of a community. They can make contributions, fix bugs, and add extras if they choose.
Now they will be “based” on RHEL ( ABI compatible ) but not “identical” per se.
This is what Red Hat wanted to happen. Hopefully this puts an end to all the Red Hat has gone proprietary nonsense as well. Pretty much everything Red Hat does will go into Alma as well. Alma will be built on the back of Red Hat’s efforts but it will be in a proper community way and they will share code and not just directly rip off the whole distro.