6 ms·

They are both new. So, this may be a one time thing due to tooling changes or whatever. Too early to jump to conclusions.

5e92cb50239222b 4y ago
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.
- 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).
freedomben 4y ago
You're not wrong, but CentOS (from inception) has always been really slow to release. When RHEL 7 dropped it took months to get the first CentOS build. CentOS having the same found, it isn't terribly surprising to me to see them be a little slower. When Alma launched, speed of updates was a specific goal of theirs because CentOS had been so painful in that area. Most of the time I think it's fine. Mainly it hurts when there are security updates you need.
- Twirrim 4y ago
  There's reasons why it takes time. The perspective that it's "just produce rebranded RPMs" really undersells even something as significant as the amount of server power required to recompile all the packages. You couldn't get the packages until the distribution upstream had released, so no way to get ahead of the build time. You just had to suck it up at release time. You used to be able to track the build process for CentOS when it was a RHEL clone, see how many packages were left to go as the days crawled past. Things are a little better with the way that development happens more recently. 6 was a massive delay for distributions because RedHat had overhauled a lot around the build process and distributions needed to completely overhaul their stuff too, in ways that weren't that obvious.
  - freedomben 4y ago
    > The perspective that it's "just produce rebranded RPMs" really undersells even something as significant as the amount of server power required to recompile all the packages. Just wanted to clarify, I agree with you completely. I didn't anywhere perpetuate the unfair "it's just produce rebranded RPMs" (which is actually accurate, but trivializes the significant process involved in rebranding and rebuilding, hence IMO misleading). It's a significant amount of work. The time it takes is not unreasonable given the effort involved. That said, the amount of time was painful. I've never complained about it because I'm grateful for anything and everything they do, and I'm not complaining about it now. I'm recognizing the facts around speed of delivery, but in no way suggesting they aren't for a good reason.
rubyist5eva 4y ago
Alma Linux has always been faster for releases since the beginning. I believe their first release was 8.3 and was very ahead of Rocky and they've maintained that pace to this day. Security updates are within a day or two, point releases are within 7 days and I think the 9.0 release was less than a month. This is probably because the project was initially founded by Cloud Linux, which I believe already had the expertise to do RedHat clones and basically donated the setup - whereas Rocky started from scratch from what I can tell.
- jonathanspw 4y ago
  point releases are usually within 3 days and 9.0 release was within 10 days :)
  - rubyist5eva 4y ago
    The Alma Linux team does incredible work, it's my goto distro since it was first released :)

5e92cb50239222b 4y ago

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

freedomben 4y ago

You're not wrong, but CentOS (from inception) has always been really slow to release. When RHEL 7 dropped it took months to get the first CentOS build. CentOS having the same found, it isn't terribly surprising to me to see them be a little slower. When Alma launched, speed of updates was a specific goal of theirs because CentOS had been so painful in that area. Most of the time I think it's fine. Mainly it hurts when there are security updates you need.

Twirrim 4y ago
There's reasons why it takes time. The perspective that it's "just produce rebranded RPMs" really undersells even something as significant as the amount of server power required to recompile all the packages. You couldn't get the packages until the distribution upstream had released, so no way to get ahead of the build time. You just had to suck it up at release time. You used to be able to track the build process for CentOS when it was a RHEL clone, see how many packages were left to go as the days crawled past. Things are a little better with the way that development happens more recently. 6 was a massive delay for distributions because RedHat had overhauled a lot around the build process and distributions needed to completely overhaul their stuff too, in ways that weren't that obvious.
- freedomben 4y ago
  > The perspective that it's "just produce rebranded RPMs" really undersells even something as significant as the amount of server power required to recompile all the packages. Just wanted to clarify, I agree with you completely. I didn't anywhere perpetuate the unfair "it's just produce rebranded RPMs" (which is actually accurate, but trivializes the significant process involved in rebranding and rebuilding, hence IMO misleading). It's a significant amount of work. The time it takes is not unreasonable given the effort involved. That said, the amount of time was painful. I've never complained about it because I'm grateful for anything and everything they do, and I'm not complaining about it now. I'm recognizing the facts around speed of delivery, but in no way suggesting they aren't for a good reason.

rubyist5eva 4y ago

Alma Linux has always been faster for releases since the beginning. I believe their first release was 8.3 and was very ahead of Rocky and they've maintained that pace to this day. Security updates are within a day or two, point releases are within 7 days and I think the 9.0 release was less than a month. This is probably because the project was initially founded by Cloud Linux, which I believe already had the expertise to do RedHat clones and basically donated the setup - whereas Rocky started from scratch from what I can tell.

jonathanspw 4y ago
point releases are usually within 3 days and 9.0 release was within 10 days :)
- rubyist5eva 4y ago
  The Alma Linux team does incredible work, it's my goto distro since it was first released :)