6 ms·

It's been close to 1.5 years. I've been using both since the beginning and can see pretty well how quickly both systems pick up updates. But let's just look at

It's been close to 1.5 years. I've been using both since the beginning and can see pretty well how quickly both systems pick up updates. But let's just look at release delays (in days since the official RHEL is shipped): ver Alm Rocky 8.4 8 34 8.5 3 6 8.6 2 6 9.0 9 58 Not seeing any patterns here? One of them is being done by a team that's been shipping another Linux distribution for a decade and has the whole process streamlined and automated. The other started by loud release announcements, creating Slack groups and marketing materials, only then going for solving the technical stuff. I think I've made my choice pretty much right then and there. Seeing how Rocky guys behaved towards the community (like their refusal to go to a popular Linux podcast unless the host was willing to forego any comparisons with other Linux distributions), and these release delays proved that.

stonogo 4y ago
It's amusing that you're presenting Alma as the veterans, seeing as how several founding members of Rocky were responsible for starting CentOS in the first place. But you're right, they're both RHEL clones, so it's only worth differentiating based on externalities. Rocky is backed by industry veterans and part of the 9.0 delay was so they could dogfood Peridot. Alma is backed by a web company who spent the majority of the past couple years Valley-washing their Russian origins. A while back I watched their CEO beg their executive team to cut ties with Russian media sites. Rockey had a community governance model first, they had a distro-dedicated SecureBoot solution first (Alma 'borrowed' CloudLinux's), and so forth. If your metric is 'get package releases to my AWS fleet first' then Alma is winning. For all the rest of the provisioning and longevity issues, Rocky is the winner. It's all a matter of priorities.
- awill 4y ago
  I don't quite understand "provisioning and longevity issues, Rocky is winning." As a user of CentOS looking for a replacement, Alma and Rocky should be 100% identical. The _only_ difference is delay after RHEL launches.
  - CamJN 4y ago
    Alma is not as RHEL-compatible as rocky, they use subkeys for signing whereas rocky just uses their signing keys. This is enough that I can’t use alma for building my rpm’s using mock.
    - awill 4y ago
      I'd love to see a technical writeup of the differences. If Rocky genuinely were better, a 5-week delay vs Alma would probably be ok, at least for the original release, as long as the dot releases are faster. No one wants security vulnerabilities delayed by 5 weeks.
    - jaboutboul 4y ago
      This is not correct. The issue is trying to use Alma 8’s mock chroot on a CentOS 7 host. The (older) versions of yum and rpm there don’t support subkeys. There is a Red Hat BZ issue here: https://bugzilla.redhat.com/show_bug.cgi?id=2017069 https://bugzilla.redhat.com/show_bug.cgi?id=2017069
      - josephcsible 4y ago
        Do RHEL/Rocky/CentOS Stream 8's mock chroots work on CentOS 7 hosts? If so, then this does seem like a legitimate binary incompatibility.
        mroche 4y ago
        That is not what binary compatibility means when talking about RHEL. It refers to the actual package ABIs and the compatibility levels we assign them: https://access.redhat.com/articles/rhel-abi-compatibility https://access.redhat.com/articles/rhel-abi-compatibility https://access.redhat.com/articles/rhel8-abi-compatibility https://access.redhat.com/articles/rhel8-abi-compatibility https://access.redhat.com/articles/rhel9-abi-compatibility https://access.redhat.com/articles/rhel9-abi-compatibility This would be closer to a bug-for-bug compatibility issue, as a result of an implementation change on the infra side of things. It's not due to the OS which is bug-for-bug compatible with its origin, RHEL 8. While it would be nice if EL7 stacks are considered by the rebuild distributions, it's not a requirement and they are free to use features supported by the platforms they're building.
- carlwgeorge 4y ago
  > several founding members of Rocky were responsible for starting CentOS in the first place. The "several" part is false. Greg is the only one with any claim at all to the early days of CentOS. He created the Caos Foundation, which is where CentOS was started. He believes that makes him the CentOS founder, despite others disputing that claim. None of the other early CentOS folks are working on Rocky.
- Galanwe 4y ago
  > several founding members of Rocky were responsible for starting CentOS in the first place Hum, that's a subjective view of the history of "CentOS" told by Greg Kurtzer... In practical terms, Greg just helped setup the legal structure around the distribution that Rocky McGough created. In the 20 years history of CentOS, Greg Kurtzer stayed 2 years at the beginning, doing mainly PR/legal/community stuff, then left when Lance Davis inherited the ownership of the project after Rocky committed suicide. I'm not sure anyone is calling Greg a "CentOS founding member" except himself, everywhere.
  - justinclift 4y ago
    > doing mainly PR/legal/community stuff Why are you not considering PR/legal/community stuff as being worthy?
    - gnufx 4y ago
      It would frighten me having Kurtzer doing legalities, given his bizarre legal theory on copyright specifically (no longer recorded in the issues of a deleted github repo for me to reference).
      - realgmk 4y ago
        Can you elaborate on my bizarre legal theory on copyrights? Thanks.
        gnufx 4y ago
        Sorry, I don't know why I missed off the sentence. The statement was that putting something under the Berkeley licence used by Singularity made it public domain, i.e. they could strip my employer's copyright, specifically. No answer to whether that was speaking for LBL legal.
        realgmk 4y ago
        Sorry, I don't remember the specific instance of what happened there, but specifically Singularity was never technically "public domain". It was always copyrighted and licensed (firstly with the DOE/LBL license based on the 3-clause BSD license, then just BSD3). Was the issue on the project copyright, or was it the copyright in the source files? While I have some experience in open source and copyright, I'm certainly no expert nor do I claim to be. Luckily I have people I can rely on for advice and guidance (e.g. back then, it was probably LBL/UCOP's Tech Transfer), but sometimes things still get mucked up. Sorry if there was a miscommunication or an error on my part back then.
- gnufx 4y ago
  I wonder what is the issue if the company "borrowed" its own stuff to use in a different context. Alma always looked like the more serious operation and, if nothing else, the company supplying kernelcare might be considered useful, even if it's proprietary, unfortunately.
mattewgm 4y ago
Faster like Springdale? This is an endurance race. CentOS is the survivor of several clones. "The best reason we have is our speed. If we assume all RHEL clones are equal in terms of software, people tend to then weigh speed and community size/support very heavily. We get new packages out very very quickly because nearly all the rebuilds can be automated. We had PUIAS 6 out over a month before CentOS 6 came out. The same is true of minor revisions - of CentOS, SL, and PUIAS, we had a 5.8 release out first." - "IAmA Developer for the PUIAS Linux distribution - AMA"
liamnal 4y ago
Rocky made it clear they have a new build system which lead to their delay. I think it's called peridot. I would imagine that it's not easy to start fresh in two places at once. Alma has an advantage with a process from CloudLinux already in place and now they've rebranded that build system as Alma and so on. Credit to Alma for keeping up and doing their thing; hopefully they'll be fully decoupled from CL in the future. CentOS had historically fell behind in release times, but we all of a sudden want to paint others in a bad light for being behind. Did everyone forget about CentOS 7 having average of 30 days delay behind each point release? 7.4 being the most at 43 days. What about CentOS 6.0, with 242 days? As for their behavior, it takes two to tango. I usually like to thank carlwshill and "conan_kudo" (who should pick a better name since he thinks he's from the anime his picture is from) for being true stars in the open source community and really bringing out not only the best in others, but the best in themselves day in and day out. I'm not sure how anyone can put up with them, regardless of which community you're in (CentOS/Fedora EPEL/others), but who am I to judge, I'm just a user.
groovybits 4y ago
I don't have exceptional experience with either Alma or Rocky, but I've been administering enterprise Red Hat and CentOS for years. 1.5 years in enterprise time is hardly any time at all. Heck, it takes that time to approve a budget in some enterprises. Yeah, time-to-release is an important metric, but software compatibility and industry support is really the magic sauce. In my industry, we'll be using current CentOS 7 installs until EOL, and watch all derivatives with interest over the long term - given they provide anything over current RH ecosystem (RHEL, CentOS Stream, Fedora).

stonogo 4y ago

It's amusing that you're presenting Alma as the veterans, seeing as how several founding members of Rocky were responsible for starting CentOS in the first place. But you're right, they're both RHEL clones, so it's only worth differentiating based on externalities. Rocky is backed by industry veterans and part of the 9.0 delay was so they could dogfood Peridot. Alma is backed by a web company who spent the majority of the past couple years Valley-washing their Russian origins. A while back I watched their CEO beg their executive team to cut ties with Russian media sites. Rockey had a community governance model first, they had a distro-dedicated SecureBoot solution first (Alma 'borrowed' CloudLinux's), and so forth. If your metric is 'get package releases to my AWS fleet first' then Alma is winning. For all the rest of the provisioning and longevity issues, Rocky is the winner. It's all a matter of priorities.

awill 4y ago
I don't quite understand "provisioning and longevity issues, Rocky is winning." As a user of CentOS looking for a replacement, Alma and Rocky should be 100% identical. The _only_ difference is delay after RHEL launches.
- CamJN 4y ago
  Alma is not as RHEL-compatible as rocky, they use subkeys for signing whereas rocky just uses their signing keys. This is enough that I can’t use alma for building my rpm’s using mock.
  - awill 4y ago
    I'd love to see a technical writeup of the differences. If Rocky genuinely were better, a 5-week delay vs Alma would probably be ok, at least for the original release, as long as the dot releases are faster. No one wants security vulnerabilities delayed by 5 weeks.
  - jaboutboul 4y ago
    This is not correct. The issue is trying to use Alma 8’s mock chroot on a CentOS 7 host. The (older) versions of yum and rpm there don’t support subkeys. There is a Red Hat BZ issue here: https://bugzilla.redhat.com/show_bug.cgi?id=2017069 https://bugzilla.redhat.com/show_bug.cgi?id=2017069
    - josephcsible 4y ago
      Do RHEL/Rocky/CentOS Stream 8's mock chroots work on CentOS 7 hosts? If so, then this does seem like a legitimate binary incompatibility.
      - mroche 4y ago
        That is not what binary compatibility means when talking about RHEL. It refers to the actual package ABIs and the compatibility levels we assign them: https://access.redhat.com/articles/rhel-abi-compatibility https://access.redhat.com/articles/rhel-abi-compatibility https://access.redhat.com/articles/rhel8-abi-compatibility https://access.redhat.com/articles/rhel8-abi-compatibility https://access.redhat.com/articles/rhel9-abi-compatibility https://access.redhat.com/articles/rhel9-abi-compatibility This would be closer to a bug-for-bug compatibility issue, as a result of an implementation change on the infra side of things. It's not due to the OS which is bug-for-bug compatible with its origin, RHEL 8. While it would be nice if EL7 stacks are considered by the rebuild distributions, it's not a requirement and they are free to use features supported by the platforms they're building.
carlwgeorge 4y ago
> several founding members of Rocky were responsible for starting CentOS in the first place. The "several" part is false. Greg is the only one with any claim at all to the early days of CentOS. He created the Caos Foundation, which is where CentOS was started. He believes that makes him the CentOS founder, despite others disputing that claim. None of the other early CentOS folks are working on Rocky.
Galanwe 4y ago
> several founding members of Rocky were responsible for starting CentOS in the first place Hum, that's a subjective view of the history of "CentOS" told by Greg Kurtzer... In practical terms, Greg just helped setup the legal structure around the distribution that Rocky McGough created. In the 20 years history of CentOS, Greg Kurtzer stayed 2 years at the beginning, doing mainly PR/legal/community stuff, then left when Lance Davis inherited the ownership of the project after Rocky committed suicide. I'm not sure anyone is calling Greg a "CentOS founding member" except himself, everywhere.
- justinclift 4y ago
  > doing mainly PR/legal/community stuff Why are you not considering PR/legal/community stuff as being worthy?
  - gnufx 4y ago
    It would frighten me having Kurtzer doing legalities, given his bizarre legal theory on copyright specifically (no longer recorded in the issues of a deleted github repo for me to reference).
    - realgmk 4y ago
      Can you elaborate on my bizarre legal theory on copyrights? Thanks.
      - gnufx 4y ago
        Sorry, I don't know why I missed off the sentence. The statement was that putting something under the Berkeley licence used by Singularity made it public domain, i.e. they could strip my employer's copyright, specifically. No answer to whether that was speaking for LBL legal.
        realgmk 4y ago
        Sorry, I don't remember the specific instance of what happened there, but specifically Singularity was never technically "public domain". It was always copyrighted and licensed (firstly with the DOE/LBL license based on the 3-clause BSD license, then just BSD3). Was the issue on the project copyright, or was it the copyright in the source files? While I have some experience in open source and copyright, I'm certainly no expert nor do I claim to be. Luckily I have people I can rely on for advice and guidance (e.g. back then, it was probably LBL/UCOP's Tech Transfer), but sometimes things still get mucked up. Sorry if there was a miscommunication or an error on my part back then.
gnufx 4y ago
I wonder what is the issue if the company "borrowed" its own stuff to use in a different context. Alma always looked like the more serious operation and, if nothing else, the company supplying kernelcare might be considered useful, even if it's proprietary, unfortunately.

mattewgm 4y ago

Faster like Springdale? This is an endurance race. CentOS is the survivor of several clones. "The best reason we have is our speed. If we assume all RHEL clones are equal in terms of software, people tend to then weigh speed and community size/support very heavily. We get new packages out very very quickly because nearly all the rebuilds can be automated. We had PUIAS 6 out over a month before CentOS 6 came out. The same is true of minor revisions - of CentOS, SL, and PUIAS, we had a 5.8 release out first." - "IAmA Developer for the PUIAS Linux distribution - AMA"

liamnal 4y ago

Rocky made it clear they have a new build system which lead to their delay. I think it's called peridot. I would imagine that it's not easy to start fresh in two places at once. Alma has an advantage with a process from CloudLinux already in place and now they've rebranded that build system as Alma and so on. Credit to Alma for keeping up and doing their thing; hopefully they'll be fully decoupled from CL in the future. CentOS had historically fell behind in release times, but we all of a sudden want to paint others in a bad light for being behind. Did everyone forget about CentOS 7 having average of 30 days delay behind each point release? 7.4 being the most at 43 days. What about CentOS 6.0, with 242 days? As for their behavior, it takes two to tango. I usually like to thank carlwshill and "conan_kudo" (who should pick a better name since he thinks he's from the anime his picture is from) for being true stars in the open source community and really bringing out not only the best in others, but the best in themselves day in and day out. I'm not sure how anyone can put up with them, regardless of which community you're in (CentOS/Fedora EPEL/others), but who am I to judge, I'm just a user.

groovybits 4y ago

I don't have exceptional experience with either Alma or Rocky, but I've been administering enterprise Red Hat and CentOS for years. 1.5 years in enterprise time is hardly any time at all. Heck, it takes that time to approve a budget in some enterprises. Yeah, time-to-release is an important metric, but software compatibility and industry support is really the magic sauce. In my industry, we'll be using current CentOS 7 installs until EOL, and watch all derivatives with interest over the long term - given they provide anything over current RH ecosystem (RHEL, CentOS Stream, Fedora).