3 ms·

Two thoughts: > The process of replicating RHEL is so much easier today than ever before. Doing so bug-for-bug requires more effort than it did a few weeks ag

Two thoughts: > The process of replicating RHEL is so much easier today than ever before. Doing so bug-for-bug requires more effort than it did a few weeks ago. And they're basically doing that work in parallel with Red Hat itself (duplication of effort). Also, making a change like this (forcing Rocky and AlmaLinux to change in the middle of the 9.x release cycle), when the previous change (killing CentOS) was _also_ in the middle of the 8.x release cycle, with not even 24 hours warning... makes me feel this change was not _only_ made "to make CentOS and RHEL development better." If that were the case, the changes would be announced with at _least_ weeks (if not months) of warning, so the community could plan for it instead of getting blind-sided... now twice in a row.

CrLf 3y ago
Why do bug-for-bug with RHEL at all? Why not turn Alma and Rocky into stable distributions in their own right? If this pushes RHEL into oblivion, why should anyone care? The Debian ecosystem isn't centered on Ubuntu, it's centered on Debian. Comparisons between the two ecosystems are invalid because of this simple fact. It would be nice to see the "Red Hat" ecosystem recenter around something which isn't a direct source release of a commercial product. Alma and Rocky should rebase on CentOS Stream for starters, and then try to get closer to Fedora as an upstream. (BTW, I speak as someone who did corporate systems administration for years and understands the use case of replacing RHEL licenses with free CentOS installs perfectly.)
- bluedino 3y ago
  > Why do bug-for-bug with RHEL at all? Why not turn Alma and Rocky into stable distributions in their own right? Because the whole point is for them to be 'compatible'. Many of the users are running software that needs to be on RHEL/CentOS/Rocky/etc or it won't be supported. Sure, there are users who just want a stable OS, but the real point of Rocky/Alma is to have a 100% RHEL-compatible, but free distro.
  - bonzini 3y ago
    There are many levels of compatibility. ABI compatibility is perhaps the least stringent, bug compatibility is the most picky.
chasil 3y ago
I'm not certain that much more effort is required. Untraceable uploads with Onionshare over a Tor browser would conceal the origin of source RPMs that did not bear fingerprints. Once captured, all that is really required is the updated SPEC file, and any modified sources or patches (if I remember my RPM internals correctly). Alma could maintain such an Onionshare instance. If the SPEC and patch files are specifically GPL, I'm not sure that Alma could be compelled to forego them.

CrLf 3y ago

Why do bug-for-bug with RHEL at all? Why not turn Alma and Rocky into stable distributions in their own right? If this pushes RHEL into oblivion, why should anyone care? The Debian ecosystem isn't centered on Ubuntu, it's centered on Debian. Comparisons between the two ecosystems are invalid because of this simple fact. It would be nice to see the "Red Hat" ecosystem recenter around something which isn't a direct source release of a commercial product. Alma and Rocky should rebase on CentOS Stream for starters, and then try to get closer to Fedora as an upstream. (BTW, I speak as someone who did corporate systems administration for years and understands the use case of replacing RHEL licenses with free CentOS installs perfectly.)

bluedino 3y ago
> Why do bug-for-bug with RHEL at all? Why not turn Alma and Rocky into stable distributions in their own right? Because the whole point is for them to be 'compatible'. Many of the users are running software that needs to be on RHEL/CentOS/Rocky/etc or it won't be supported. Sure, there are users who just want a stable OS, but the real point of Rocky/Alma is to have a 100% RHEL-compatible, but free distro.
- bonzini 3y ago
  There are many levels of compatibility. ABI compatibility is perhaps the least stringent, bug compatibility is the most picky.

chasil 3y ago

I'm not certain that much more effort is required. Untraceable uploads with Onionshare over a Tor browser would conceal the origin of source RPMs that did not bear fingerprints. Once captured, all that is really required is the updated SPEC file, and any modified sources or patches (if I remember my RPM internals correctly). Alma could maintain such an Onionshare instance. If the SPEC and patch files are specifically GPL, I'm not sure that Alma could be compelled to forego them.