AlmaLinux Stays Red Hat Enterprise Linux Compatible Without Red Hat Code (zdnet.com) 34
AlmaLinux is creating a Red Hat Enterprise Linux (RHEL) without any Red Hat code. Instead, AlmaLinux OS will aim to be Application Binary Interface (ABI) compatible and use the CentOS Stream source code that Red Hat continues to offer. Additional code is pulled from Red Hat Universal Base Images, and upstream Linux code. Benny Vasquez, chairperson of the AlmaLinux OF Foundation, explained how all this works at the open-source community convention All Things Open. ZDNet's Steven Vaughan-Nichols reports: The hardest part is Red Hat's Linux kernel updates because, added Vasquez, "you can't get those kernel updates without violating Red Hat's licensing agreements." Therefore, she continued, "What we do is we pull the security patches from various other sources, and, if nothing else, we can find them when Oracle releases them." Vasquez did note one blessing from this change in production: "AlmaLinux, no longer bound to Red Hat's releases, has been able to release upstream security fixes faster than Red Hat. "For example, the AMD microcode exploits were patched before Red Hat because they took a little bit of extra time to get out the door. We then pulled in, tested, and out the door about a week ahead of them." The overall goal remains to maintain RHEL compatibility. "Any breaking changes between RHEL and AlmaLinux, any application that stops working, is a bug and must be fixed."
That's not to say AlmaLinux will be simply an excellent RHEL clone going forward. It plans to add features of its own. For instance, Red Hat users who want programs not bundled in RHEL often turn to Extra Packages for Enterprise Linux (EPEL). These typically are programs included in Fedora Linux. Besides supporting EPEL software, AlmaLinux has its own extra software package -- called Synergy -- which holds programs that the AlmaLinux community wants but are not available in either EPEL or RHEL. If one such program is subsequently added to EPEL or RHEL, AlmaLinux drops it from Synergy to prevent confusion and duplication of effort.
This has not been an easy road for AlmaLinux. Even a 1% code difference is a lot to write and maintain. For example, when AlmaLinux tried to patch CentOS Stream code to fix a problem, Red Hat was downright grumpy about AlmaLinux's attempt to fix a security hole. Vasquez acknowledged it was tough sledding at first, but noted: "The good news is that they have been improving the process, and things will look a little bit smoother." AlmaLinux, she noted, is also not so much worried as aware that Red Hat may throw a monkey wrench into their efforts. Vasquez added: "Internally, we're working on stopgap things we'd need to do to anticipate Red Hat changing everything terribly." She doesn't think Red Hat will do it, but "we want to be as prepared as possible."
That's not to say AlmaLinux will be simply an excellent RHEL clone going forward. It plans to add features of its own. For instance, Red Hat users who want programs not bundled in RHEL often turn to Extra Packages for Enterprise Linux (EPEL). These typically are programs included in Fedora Linux. Besides supporting EPEL software, AlmaLinux has its own extra software package -- called Synergy -- which holds programs that the AlmaLinux community wants but are not available in either EPEL or RHEL. If one such program is subsequently added to EPEL or RHEL, AlmaLinux drops it from Synergy to prevent confusion and duplication of effort.
This has not been an easy road for AlmaLinux. Even a 1% code difference is a lot to write and maintain. For example, when AlmaLinux tried to patch CentOS Stream code to fix a problem, Red Hat was downright grumpy about AlmaLinux's attempt to fix a security hole. Vasquez acknowledged it was tough sledding at first, but noted: "The good news is that they have been improving the process, and things will look a little bit smoother." AlmaLinux, she noted, is also not so much worried as aware that Red Hat may throw a monkey wrench into their efforts. Vasquez added: "Internally, we're working on stopgap things we'd need to do to anticipate Red Hat changing everything terribly." She doesn't think Red Hat will do it, but "we want to be as prepared as possible."
Thank You (Score:2)
Re: (Score:2)
Yeah, although DOS was simpler, msdos vs ibmdos where pretty compatible, I can't remember a single issue. I even used IBM technical DOS manual to customize MS-DOS and write low level utilities in assembly.
Redhat has jumped the shark (Score:4, Informative)
That is all.
Single Point of Failure (Score:4, Interesting)
The EL community is realizing being 100% reliant on IBM is no longer viable in the long term.
Alma is doing what's reasonable in the short term.
Good, but many of us are donezo wif RH (Score:5, Interesting)
No big deal. Those machines came out with ksplice at least.
Re:Good, but many of us are donezo wif RH (Score:5, Insightful)
It says a lot when someone decides they'd rather do business with Oracle than with IBM.
Re:Good, but many of us are donezo wif RH (Score:5, Interesting)
Re: (Score:2)
Re:Good, but many of us are donezo wif RH (Score:4, Interesting)
Enterprise support was never really the reason for RHEL's success (except for some of the very largest organizations who were mostly incompetent to run their own infrastructure in the first place). CentOS was extremely popular because it was put out in LTS releases where you could count on compatibility not changing with whatever you were running for long periods of time while still being able to patch vulnerabilities. Desktop Linux or general distros were notoriously bad at jumping to new versions of packages on a whim so you constantly had to swat things as they came up whenever updates had to be installed.
Whether there's an enterprise behind it is not as important as whether patches are available that address known CVEs.
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
Awesome! I have long felt that Red Hat is making Linux just another corporate OS, the freedom does not seem to be what it used to be.
I like FreeBSD much better, but it seems that nobody uses it.
How does RH do this? (Score:3)
I don't follow Linux or RedHat drama much, so I don't know exactly what they've done so that they can make kernel changes like that such that others have to 'license' them, as the article implies.
I thought since the Linux kernel was GPL those had to be GPL and therefore available to all without additional licensing! What is going on here? Can someone help me understand please?
Thanks!
Re:How does RH do this? (Score:4, Informative)
They do release all the source code and patches to the kernel to their customers. So they do follow the letter of the law when it comes to the gpl. The problem is their service agreements essentially prohibit their customers from exercising their rights and redistributing this code to others by threatening to cancel their support contacts. This has been going on for years.
Re:How does RH do this? (Score:4, Insightful)
They do release all the source code and patches to the kernel to their customers. So they do follow the letter of the law when it comes to the gpl. The problem is their service agreements essentially prohibit their customers from exercising their rights and redistributing this code to others by threatening to cancel their support contacts. This has been going on for years.
Yes. They basically follow the douchebag's guide to the GNU public license.
Re: (Score:2)
I thought such behavior is forbidden by the GPL.
Re:How does RH do this? (Score:4, Informative)
They give all of their source code publicly. But I think the issue is that they don't tell you which source code is included in which RHEL release. They give all the code via CentOS stream, which is rolling release. So only bits and pieces of the current CentOS are part of RHEL at any given time and you would have to find a way to piece together the right code from many CentOS revisions for each bit of the OS to match RHEL.
Re: How does RH do this? (Score:2)
There's debate centered around "without further restrictions", with red hat lawyers taking the stance that refers to restriction on the specific source code and binary code given to user and nothing about updates.
So when red hat hypothetically penalizes someone for sharing source by denying them future binary and source, well the user still has unrestricted rights to the software already given to them.
Others argue that a threat of loss of access to updates is a "further restriction", even if technically the
Re: How does RH do this? (Score:2)
Some good info here https://thenewstack.io/how-red... [thenewstack.io]
RedHat's license agreement asks you not to exercise rights the GPL gives you. So I guess you could download all the source and give it away but they'd stop taking your money and cut you off from future updates.
I'm not sure what they can do if someone finds a way to cheat and leak the source discretely, because they shouldn't be able to go after people using the source that makes it out. So I bet they're watching for leakers very closely.
Re: (Score:3)
Sort of. Everyone's after a teaspoon of salt from RedHat. Enterprise customers are given their salt in a convenient teaspoon. Everyone else gets the GPL-compliant firehose that is CentOS Stream. Technically the same teaspoon of salt is there, but it's mixed with hundreds of gallons of water. Enterprise customers are told not to show secrets on how to extract the salt. This isn't in violation of the GPL by the letter of the law, but certainly in some aspects of the spirit of the license.
If you leak sou
Re: (Score:2)
To all who replied, thank you for the informative answers. Sounds like RH is letting lawyers and BAs enshittify their entire reputation among those they need to impress the most. Sounds like their CEO needs to go before those nerds ruin their business model long term!
Re: (Score:2)
This sort of end-run around the GPL (at least in the opinion of some) through service contracts has been happening for far longer than the current CEO. The software freedom conservancy has expressed concern going back nearly 15 years, perhaps longer.
There was a time when Red Hat just sold support contracts on free software, but that nearly bankrupted them, so they switched to a licensing model, and that has enabled them to become the largest Linux company on the planet, and made them a lot of money. Plus
Re: (Score:2)
ORACLE: Forge your own path, instead of copying (Score:5, Interesting)
Red Hat, when they were a scrappy underdog did their thing with RHEL. ... well ... debian
Suse, when they were a scrappy underdog did their own thing with SLES.
Debian did (and still does) their own thing with
Ubuntu did their own thing with Ubuntu server.
Gentoo and Arch (good enough for the steamdeck, may I add) did their own things too.
Then, Oracle, a multi-Billion dollar company, decided in 2006 (Oracle Valuation in 2006: 33.09 Milliards) to COPY the distro of one of the scrappy underdogs (Redhat's market valuation in 2006 3.4 Milliards, so 10 times smaller). Yes, many (but not all) of the FOSS licenes allowed this, but come on! That was/is a dick move.
Instead (with very few exceptions) of getting the Upstream sources and work from there to do their own integration, compatibility and compilation/optimization work, Oracle took RedHat's sources, strip the RedHat copywrithed contend and recompiled, and called themselves "Bug for Bug compatible with RedHat". If Suse, Debian, and Ubuntu, being smaller than Oracle could do their own thing and forge their own (relatively sucessfull) paths: Why could not Mighty Oracle do it?
What we are seeing now is a (belated, IMHO) reaction from RedHat to Oracle's antics... CentOS, Alma and Rocky are just "collateral Damage".
Wait unti RedHat decides to stop providing sources for components under BSD, MIT, APACHE and MPLcand see the "Game Over" Sign for Oracle's "Bug for Bug compatible with RedHat" claim...
JM2C, YMMV
Re: (Score:3)
You may use Slackware which just use stock and standard kernel.org kernel. Upgrade source code from kernel.org compile and you're good to go.
Re: (Score:2)
Re: (Score:2)
FYI the company behind Ubuntu is called Canonical: https://en.wikipedia.org/wiki/... [wikipedia.org]
Re: (Score:3)
Ubuntu clones Debian testing with a few additions and patches, the patches also get fed back to Debian.
It seems like a mutually beneficial arrangement, but I certainly wouldn't characterise Ubuntu as starting from scratch or doing their own thing.
silly premise (Score:5, Interesting)
The premise of Steve's article is preposterous. AlmaLinux isn't staying compatible "without RHEL's code", they're compatible because they have it. RHEL is entirely Open Source software, and its main git branch is published to the public.
Re: (Score:3)
And the CentOS Stream they mention IS RHEL source code.
Re: (Score:2)
It's not silly. The idea behind it is sound. They are simply talking about skirting the issue of Redhat yanking the license for anyone distributing the code intended for customers.
This is actually a fairly significant thing to understand, in my opinion. It turns Alma into a "best effort" RHEL clone. They are pulling code from the CentOS stream which is essentially the BETA version of RHEL. Which is fine if it's all vetted and validated. But, if I have a piece of commercial software that's supported/a
Re: silly premise (Score:1)