5 ms·

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 plac

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.
  - deleted 4y ago
    [deleted]
  - gnufx 4y ago
    Well, I can do a mock -r almalinux-8-x86_64 bootstrap build on RHEL7. (I can't remember whether there are currently any problems maintaining for RHEL8 on RHEL7, but it has been impossible to maintain packages for RHEL N+1 on RHEL N in the past. I just moved to a RHEL8 VM rather than prat about with 7 more.)
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.

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.
- deleted 4y ago
  [deleted]
- gnufx 4y ago
  Well, I can do a mock -r almalinux-8-x86_64 bootstrap build on RHEL7. (I can't remember whether there are currently any problems maintaining for RHEL8 on RHEL7, but it has been impossible to maintain packages for RHEL N+1 on RHEL N in the past. I just moved to a RHEL8 VM rather than prat about with 7 more.)

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.