Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Open Source Operating Systems Red Hat Software Linux

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."

This discussion has been archived. No new comments can be posted.

AlmaLinux Stays Red Hat Enterprise Linux Compatible Without Red Hat Code

Comments Filter:
  • The path beyond CentOS is getting paved. Thank you.
    • by ls671 ( 1122017 )

      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.

  • by sjames ( 1099 ) on Wednesday October 18, 2023 @08:33PM (#63935935) Homepage Journal

    That is all.

  • by bill_mcgonigle ( 4333 ) * on Wednesday October 18, 2023 @08:33PM (#63935937) Homepage Journal

    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.

  • by MIPSPro ( 10156657 ) on Wednesday October 18, 2023 @08:38PM (#63935949)
    I used to love Red Hat. I still have a tee shirt, a set of original boxed set of Red Hat 7.0 CDROMs, a literal embroidered red hat that I got when I passed my RHCE and RHCSA exams. Then, I worked with them a few years and they did the following: 1. Gave Lennart Pottering and forced fetch/PulseAudio to happen 2. System==D rugpull 3. CentOS rugpull. 4. IBM acquisition. Fuck IBM. They are mostly just a big offshoring firm like Tata, Wipro, now. 5. Many shitty changes to the OS that's made it much worse since RHEL6, not better. 6. Hella bad attitudes from salespeople and threats from legal when I ditched them for Oracle EL.

    No big deal. Those machines came out with ksplice at least. :-) Now most are FreeBSD servers and that's been great, too. Kthxbye Red Hat.
    • by 93 Escort Wagon ( 326346 ) on Wednesday October 18, 2023 @08:42PM (#63935953)

      It says a lot when someone decides they'd rather do business with Oracle than with IBM.

      • by MIPSPro ( 10156657 ) on Wednesday October 18, 2023 @08:51PM (#63935959)
        Hehe, you got me there. However, we transitioned to OEL because they have this set of scripts and RPMs that allow one to convert RHEL to OEL in-situ. This absolutely infuriated RH who we'd previously (the year before) been renewing support for 1200 Red Hat instances. They threatened legal action if we converted them and refused any renewals. The deal with OEL is that they do not do the "any instance must be at least minimally licensed" like RHEL requires. This got us out of IBM's clutches. Then we proceeded the next year to covert them all to FreeBSD. Been doing rolling upgrades and living happily ever after, since.
        • by paugq ( 443696 )
          Where are you getting enterprise FreeBSD support and patches from?
          • by omnichad ( 1198475 ) on Thursday October 19, 2023 @08:58AM (#63936807) Homepage

            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.

            • by sheph ( 955019 )
              It depends on where you are. Here there is intense fear from management of anything that does not have enterprise support (critical infrastructure). Without an agreement complete with SLAs, patching contracts, and expedited support a manager could lose his/her job if something breaks. There's a very low tolerance for outages and tons of redundancy. It's why we're locked in with RHL / Microsoft Windows and can't go elsewhere.
          • Well, if we needed that, we'd probably choose from one of the dozens of vendors [freebsd.org] already listed on FreeBSD.org. However, what one finds is that when dealing with an organization that's giving you upgrade paths between major revisions (freebsd-update [freebsd.org]), great documentation [freebsd.org], public [wikipedia.org] repositories for software, and helpful IRC channels and mailing lists, then you rarely need "enterprise support". If you do, like I said, then you can buy some. Let's examine Red Hat in this light. They have no public software repos
      • by jmccue ( 834797 )
        Undoing a twitch bad mod, was aiming for Funny but missed.
    • 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.

  • by christoban ( 3028573 ) on Wednesday October 18, 2023 @09:43PM (#63936031)

    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!

    • by caseih ( 160668 ) on Wednesday October 18, 2023 @10:18PM (#63936057)

      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.

      • by Kernel Kurtz ( 182424 ) on Wednesday October 18, 2023 @10:52PM (#63936077)

        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.

      • by cowdung ( 702933 )

        I thought such behavior is forbidden by the GPL.

        • by omnichad ( 1198475 ) on Wednesday October 18, 2023 @11:36PM (#63936125) Homepage

          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.

        • 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

    • 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.

      • 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

    • 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!

      • by caseih ( 160668 )

        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

        • This is grey area. When GPL binaries are delivered via private channel, there is no explicit requirement that the source code must be released publicly and not via the same closed channel. RHEL distributes patches binaries and source code via private endpoint which requires license to access and they can cut off that access at any time. So it is not the software that is licensed, but rather the distribution service and GPL explicitly allows paid distribution.
  • by williamyf ( 227051 ) on Wednesday October 18, 2023 @10:07PM (#63936043)

    Red Hat, when they were a scrappy underdog did their thing with RHEL.
    Suse, when they were a scrappy underdog did their own thing with SLES.
    Debian did (and still does) their own thing with ... well ... debian
    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

    • by ls671 ( 1122017 )

      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.

      • by sheph ( 955019 )
        I've done this at home. Just to see what it would look like. Maintenance is not trivial. Slackpkg helps, but that doesn't cover everything.
    • by sodul ( 833177 )

      FYI the company behind Ubuntu is called Canonical: https://en.wikipedia.org/wiki/... [wikipedia.org]

    • by lordlod ( 458156 )

      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)

    by MSG ( 12810 ) on Thursday October 19, 2023 @12:51AM (#63936177)

    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.

    • by zdzichu ( 100333 )

      And the CentOS Stream they mention IS RHEL source code.

    • 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

    • Steve gets paid to write for CIQ, the organisation ultimately behind Rocky Linux. It's in his financial interest to crap all over red hat (rightly or wrongly) so he can continue get money from his client. The fact that he neglects to disclose this clearly tells you just how unprofessional he is as a journalist.

"Show me a good loser, and I'll show you a loser." -- Vince Lombardi, football coach

Working...