15 ms·

The future of AlmaLinux

150 points by mroche 3y ago

maria1998zx 3y ago
[dead]
maria1998zx 3y ago
[dead]
geerlingguy 3y ago
> 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.
- msla 3y ago
  Unless that software depends on bugs the AlmaLinux people have fixed, of course.
  - bexsella 3y ago
    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?
    - type0 3y ago
      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.
- mighmi 3y ago
  What's the purpose exactly? Who uses AlmaLinux exactly?
  - hackerbrother 3y ago
    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.
  - zincfingers 3y ago
    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
  - tmottabr 3y ago
    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.
  - lockhouse 3y ago
    Alma Linux was much faster at releasing updates than Rocky. Alma also had secure boot working on their first release, whereas Rocky didn’t. That’s why I favored it. Alma seemed to have more robust infrastructure and processes in place looking from the outside.
    - passthejoe 3y ago
      Alma also has a live ISO.
      - bclemens 3y ago
        Rocky Linux has a large selection of live ISOs in different flavor desktop environments / etc at https://rockylinux.org/alternative-images https://rockylinux.org/alternative-images
deleted 3y ago
[deleted]
WiSaGaN 3y ago
> 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.
bubblethink 3y ago
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.
- deleted 3y ago
  [deleted]
- shawnz 3y ago
  Why does this announcement make that question any more relevant than it already was a year ago for example? Regardless, I think the answer is basically that you'd face an "xkcd 927" (i.e. "15 competing standards") problem
  - LeFantome 3y ago
    Until recently, Alma was exactly RHEL but for free. Now they will be CentOS which is already free. I think it is a fair question if the new model adds value or not.
    - shawnz 3y ago
      But even before this, Alma was using the same model as Rocky, Oracle, etc, weren't they?
      - diffeomorphism 3y ago
        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?"
        shawnz 3y ago
        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?
photonbeam 3y ago
If its not the same as RHEL, may as well just move to Debian
- CameronNemo 3y ago
  All third party vendors would then have to build against all the versions of Debian, rather than just "Enterprise Linux 7/8/9". They are still locking things like glibc, gcc, OpenSSL, LLVM, et cetera versions.
- dralley 3y ago
  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?
  - barneygale 3y ago
    CentOS Stream is also affiliated with Red Hat
    - jzb 3y ago
      If “affiliated with Red Hat” is a problem, why run something based on their code at all?
      - chasil 3y ago
        My job currently demands Oracle Linux. I could choose Red Hat if I wanted to. 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).
        dralley 3y ago
        >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). Good news https://access.redhat.com/articles/simple-content-access https://access.redhat.com/articles/simple-content-access
behnamoh 3y ago
“the future of <community based project > is bright” says chair of the board. isn’t that ironic?
- yazzku 3y ago
  It's the new wave of corporate wokeness. Now the oligarchy is a "community". I mean just look how open we are; it's gotta be good, right?
- wmf 3y ago
  In this case there is a specific bullet that they dodged.
thresh 3y ago
> We will also start asking anyone who reports bugs in AlmaLinux OS to attempt to test and replicate the problem in CentOS Stream as well So what's the point of running Alma then?
- NewJazz 3y ago
  Buffer the stream.
- justinclift 3y ago
  Don't cross the streams? ;)
- keeperofdakeys 3y ago
  - 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.
  - mroche 3y ago
    * Provide ABI compatibility with RHEL which CentOS Stream may not provide.* CentOS Stream by definition is ABI compatible with RHEL, and is required to be as such.
type0 3y ago
Is the Future of Rocky bright? As far as I'm aware they are choosing a different approach and it's unclear how well that would work.
- CameronNemo 3y ago
  Finally, a meaningful way to tell the two projects apart!
- rurban 3y ago
  They are trying to exploit a legal loophole how to get the sources, which redhat will certainly close in the next years.
jzb 3y ago
Good on them! I think this is a great decision.
totallywrong 3y ago
Good on AlmaLinux. This is more what I'd expect from a fork which is healthy for the ecosystem. Now they're esentially building their own thing.
- cvadict 3y ago
  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?
  - acrispino 3y ago
    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.
    - jonathanspw 3y ago
      Correct we will continue with minor releases every ~6 months.
fevangelou 3y ago
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). And Oracle will also work on their own fork. Right...
- liamnal 3y ago
  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.
  - fevangelou 3y ago
    Tomayto, tomahto. 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.
- dralley 3y ago
  > (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.
10g1k 3y ago
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. Just stop it.
- bclemens 3y ago
  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/-/blob/r8/code https://git.rockylinux.org/original/rpms/rocky-release/-/blo... I'm not sure why Alma does a new one for every minor release though.
  - jonathanspw 3y ago
    Because, why not? :)
- _cenw 3y ago
  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.
- bonzini 3y ago
  Software looks for them. Fedora code names are like "Thirty Eight".
- deleted 3y ago
  [deleted]
- mjw1007 3y ago
  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.
lxe 3y ago
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.
- brazzledazzle 3y ago
  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.
LeFantome 3y ago
I am happy to see Alma takes this path. 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.
- bayindirh 3y ago
  > 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.
  - deleted 3y ago
    [deleted]
  - OCASMv2 3y ago
    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. Why should RH help bad faith competitors?
geerlingguy 3y ago
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). [1] https://www.reddit.com/r/redhat/comments/14yyf0k/the_future_of_almalinux_is_bright/jrvs2bb/?context=3 https://www.reddit.com/r/redhat/comments/14yyf0k/the_future_...
- noizejoy 3y ago
  additional threads: [2] https://old.reddit.com/r/AlmaLinux/comments/14yyg3i/the_future_of_almalinux_is_bright/ https://old.reddit.com/r/AlmaLinux/comments/14yyg3i/the_futu... [3] https://old.reddit.com/r/linux/comments/14yyf6y/the_future_of_almalinux_is_bright/ https://old.reddit.com/r/linux/comments/14yyf6y/the_future_o...
- iso8859-1 3y ago
  What's the point of replicating issues in CentOS Stream if it has moved on to much more recent releases, say, after 9 years?
1letterunixname 3y ago
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.
- cozzyd 3y ago
  I think there is value in basically CentOS stream but slower...
  - chasil 3y ago
    They are also taking updates from Oracle Linux. Oracle obviously certifies its database on the Red Hat platform, and has licensed access to immediate source. Until a grand rupture where Red Hat is decertified, Alma can combine updates from Oracle and CentOS stream.
josephcsible 3y ago
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.
- RadixDLT 3y ago
  I believe Fedora Linux is the predecessor to centos
- WesolyKubeczek 3y ago
  [flagged]
KingMachiavelli 3y ago
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.
- technion 3y ago
  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.
- bclemens 3y ago
  For the security part at least, there are a few efforts to combine all the errata in one place, for example https://osv.dev/list?ecosystem=Rocky+Linux https://osv.dev/list?ecosystem=Rocky+Linux
- pabs3 3y ago
  repology.org already scrapes all the versions, so it would be good to add bugs and patches there too. The service is open source too.
worthless-trash 3y ago
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.
not_your_vase 3y ago
Doesn't it make AlmaLinux kind of pointless going forward? What's the benefit of AlmaLinux over CentOS Stream, which offers pretty much the same?
- javitury 3y ago
  Well, AlmaLinux has a support cycle of 10 years while CentOS Stream is 5 years
- deleted 3y ago
  [deleted]
- bonzini 3y ago
  The main benefit is periodic releases.
sumanthvepa 3y ago
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
- keeperofdakeys 3y ago
  Alma has had this for some time now - https://almalinux.org/elevate/ https://almalinux.org/elevate/ - and I see no reason why it would stop working after this announcement.
RadixDLT 3y ago
just pick one of the top 10 on https://distrowatch.com/ https://distrowatch.com/
pmatilai 3y ago
Kudos for AlmaLinux for doing the right thing.
lakomen 3y ago
Good job IBM for creating more fear, uncertainty and doubt in the Linux ecosystem than Microsoft ever could
- Mikhail_K 3y ago
  We see how Red Hat's (or, really, IBM's) drive for profitability fragments its ecosystem and therefore reduces its value.
CrLf 3y ago
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.
- niutech 3y ago
  Sometimes b4b compatibility matters, especially in critical infrastructure.
fariszr 3y ago
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.

150 points by mroche 3y ago

maria1998zx 3y ago

[dead]

maria1998zx 3y ago

[dead]

geerlingguy 3y ago

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

msla 3y ago
Unless that software depends on bugs the AlmaLinux people have fixed, of course.
- bexsella 3y ago
  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?
  - type0 3y ago
    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.
mighmi 3y ago
What's the purpose exactly? Who uses AlmaLinux exactly?
- hackerbrother 3y ago
  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.
- zincfingers 3y ago
  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
- tmottabr 3y ago
  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.
- lockhouse 3y ago
  Alma Linux was much faster at releasing updates than Rocky. Alma also had secure boot working on their first release, whereas Rocky didn’t. That’s why I favored it. Alma seemed to have more robust infrastructure and processes in place looking from the outside.
  - passthejoe 3y ago
    Alma also has a live ISO.
    - bclemens 3y ago
      Rocky Linux has a large selection of live ISOs in different flavor desktop environments / etc at https://rockylinux.org/alternative-images https://rockylinux.org/alternative-images

deleted 3y ago

[deleted]

WiSaGaN 3y ago

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

bubblethink 3y ago

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.

deleted 3y ago
[deleted]
shawnz 3y ago
Why does this announcement make that question any more relevant than it already was a year ago for example? Regardless, I think the answer is basically that you'd face an "xkcd 927" (i.e. "15 competing standards") problem
- LeFantome 3y ago
  Until recently, Alma was exactly RHEL but for free. Now they will be CentOS which is already free. I think it is a fair question if the new model adds value or not.
  - shawnz 3y ago
    But even before this, Alma was using the same model as Rocky, Oracle, etc, weren't they?
    - diffeomorphism 3y ago
      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?"
      - shawnz 3y ago
        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?

photonbeam 3y ago

If its not the same as RHEL, may as well just move to Debian

CameronNemo 3y ago
All third party vendors would then have to build against all the versions of Debian, rather than just "Enterprise Linux 7/8/9". They are still locking things like glibc, gcc, OpenSSL, LLVM, et cetera versions.
dralley 3y ago
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?
- barneygale 3y ago
  CentOS Stream is also affiliated with Red Hat
  - jzb 3y ago
    If “affiliated with Red Hat” is a problem, why run something based on their code at all?
    - chasil 3y ago
      My job currently demands Oracle Linux. I could choose Red Hat if I wanted to. 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).
      - dralley 3y ago
        >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). Good news https://access.redhat.com/articles/simple-content-access https://access.redhat.com/articles/simple-content-access

behnamoh 3y ago

“the future of <community based project > is bright” says chair of the board. isn’t that ironic?

yazzku 3y ago
It's the new wave of corporate wokeness. Now the oligarchy is a "community". I mean just look how open we are; it's gotta be good, right?
wmf 3y ago
In this case there is a specific bullet that they dodged.

thresh 3y ago

> We will also start asking anyone who reports bugs in AlmaLinux OS to attempt to test and replicate the problem in CentOS Stream as well So what's the point of running Alma then?

NewJazz 3y ago
Buffer the stream.
justinclift 3y ago
Don't cross the streams? ;)
keeperofdakeys 3y ago
- 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.
- mroche 3y ago
  * Provide ABI compatibility with RHEL which CentOS Stream may not provide.* CentOS Stream by definition is ABI compatible with RHEL, and is required to be as such.

type0 3y ago

Is the Future of Rocky bright? As far as I'm aware they are choosing a different approach and it's unclear how well that would work.

CameronNemo 3y ago
Finally, a meaningful way to tell the two projects apart!
rurban 3y ago
They are trying to exploit a legal loophole how to get the sources, which redhat will certainly close in the next years.

jzb 3y ago

Good on them! I think this is a great decision.

totallywrong 3y ago

Good on AlmaLinux. This is more what I'd expect from a fork which is healthy for the ecosystem. Now they're esentially building their own thing.

cvadict 3y ago
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?
- acrispino 3y ago
  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.
  - jonathanspw 3y ago
    Correct we will continue with minor releases every ~6 months.

fevangelou 3y ago

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). And Oracle will also work on their own fork. Right...

liamnal 3y ago
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.
- fevangelou 3y ago
  Tomayto, tomahto. 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.
dralley 3y ago
> (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.

10g1k 3y ago

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. Just stop it.

bclemens 3y ago
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/-/blob/r8/code https://git.rockylinux.org/original/rpms/rocky-release/-/blo... I'm not sure why Alma does a new one for every minor release though.
- jonathanspw 3y ago
  Because, why not? :)
_cenw 3y ago
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.
bonzini 3y ago
Software looks for them. Fedora code names are like "Thirty Eight".
deleted 3y ago
[deleted]
mjw1007 3y ago
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.

lxe 3y ago

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.

brazzledazzle 3y ago
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.

LeFantome 3y ago

I am happy to see Alma takes this path. 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.

bayindirh 3y ago
> 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.
- deleted 3y ago
  [deleted]
- OCASMv2 3y ago
  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. Why should RH help bad faith competitors?

geerlingguy 3y ago

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). [1] https://www.reddit.com/r/redhat/comments/14yyf0k/the_future_of_almalinux_is_bright/jrvs2bb/?context=3 https://www.reddit.com/r/redhat/comments/14yyf0k/the_future_...

noizejoy 3y ago
additional threads: [2] https://old.reddit.com/r/AlmaLinux/comments/14yyg3i/the_future_of_almalinux_is_bright/ https://old.reddit.com/r/AlmaLinux/comments/14yyg3i/the_futu... [3] https://old.reddit.com/r/linux/comments/14yyf6y/the_future_of_almalinux_is_bright/ https://old.reddit.com/r/linux/comments/14yyf6y/the_future_o...
iso8859-1 3y ago
What's the point of replicating issues in CentOS Stream if it has moved on to much more recent releases, say, after 9 years?

1letterunixname 3y ago

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.

cozzyd 3y ago
I think there is value in basically CentOS stream but slower...
- chasil 3y ago
  They are also taking updates from Oracle Linux. Oracle obviously certifies its database on the Red Hat platform, and has licensed access to immediate source. Until a grand rupture where Red Hat is decertified, Alma can combine updates from Oracle and CentOS stream.

josephcsible 3y ago

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.

RadixDLT 3y ago
I believe Fedora Linux is the predecessor to centos
WesolyKubeczek 3y ago
[flagged]

KingMachiavelli 3y ago

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.

technion 3y ago
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.
bclemens 3y ago
For the security part at least, there are a few efforts to combine all the errata in one place, for example https://osv.dev/list?ecosystem=Rocky+Linux https://osv.dev/list?ecosystem=Rocky+Linux
pabs3 3y ago
repology.org already scrapes all the versions, so it would be good to add bugs and patches there too. The service is open source too.

worthless-trash 3y ago

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.

not_your_vase 3y ago

Doesn't it make AlmaLinux kind of pointless going forward? What's the benefit of AlmaLinux over CentOS Stream, which offers pretty much the same?

javitury 3y ago
Well, AlmaLinux has a support cycle of 10 years while CentOS Stream is 5 years
deleted 3y ago
[deleted]
bonzini 3y ago
The main benefit is periodic releases.

sumanthvepa 3y ago

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

keeperofdakeys 3y ago
Alma has had this for some time now - https://almalinux.org/elevate/ https://almalinux.org/elevate/ - and I see no reason why it would stop working after this announcement.

RadixDLT 3y ago

just pick one of the top 10 on https://distrowatch.com/ https://distrowatch.com/

pmatilai 3y ago

Kudos for AlmaLinux for doing the right thing.

lakomen 3y ago

Good job IBM for creating more fear, uncertainty and doubt in the Linux ecosystem than Microsoft ever could

Mikhail_K 3y ago
We see how Red Hat's (or, really, IBM's) drive for profitability fragments its ecosystem and therefore reduces its value.

CrLf 3y ago

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.

niutech 3y ago
Sometimes b4b compatibility matters, especially in critical infrastructure.

fariszr 3y ago

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.