Hacker News Reader

Comment by kunagi7 | Hacker News Reader

First of all, I used to be a Fedora user. The experience most of the time was excellent. Updating was a breeze and via external repos most packages were readily available. Most desktops/spins are well supported like sway, i3, xfce.

Nowadays I use Arch which I also think it's a great distro. The only thing I miss are delta RPMs.

Also, since CentOS was shut down, Fedora is a good way to learn how Red Hat based distros internals work.

View on HN

CentOS wasn't "shut down"... it's still out there, just as CentOS Stream now. The changes for most users are minimal to not even noticeable.

And there is Rocky Linux for the rest.

I've heard great things about Alma

CentOS Linux is end of life at the end of this year, so in that respect, it was shut down: https://www.centos.org/cl-vs-cs/

CentOS Stream isn't geared towards production environments according to the CentOS website.

CentOS most certainly was shut down, and replaced with CentOS Stream, which is a similar product that went from at least as stable as RHEL and not having ABI breakage, to the beta for the next RHEL and having ABI breakage. Close enough for many uses, but not the same thing.

> went from at least as stable as RHEL and not having ABI breakage, to the beta for the next RHEL and having ABI breakage.

Please review the following resources before making statements about RHEL ABI compatibility in Stream:

---

RHEL ABI: https://access.redhat.com/articles/rhel8-abi-compatibility

RHEL Kernel ABI: https://access.redhat.com/solutions/444773

Kernel Sources (Module.kabi_<arch>):

  - RHEL 9: https://gitlab.com/redhat/centos-stream/rpms/kernel
  - RHEL 8: https://git.centos.org/rpms/kernel/blob/c8s/f/SOURCES

Pat Riehecky - Thinking About Binary Compatibility and CentOS Stream: https://www.youtube.com/watch?v=pVZuvoVau-0

---

As a future version of RHEL, CentOS Stream is bound by the RHEL Application Compatibility Guidelines and kABI stablelist. I'll say it again:

CentOS Stream is bound by the RHEL Application Compatibility Guidelines and kABI stablelist.

All packages that exist in Stream repos have passed the same internal gating test suites that RHEL has.

I'm sorry if this comes off as rough but it is very annoying seeing this "ABI incompatibility" statement be thrown around constantly without people fully understanding what it actually means in the context of RHEL. It is _not_ an all-encompassing policy that applies to the every part of the distribution the same like it would be implied for a library strictly following semver. There are levels and nuance, and some packages don't even make the list (which is why there are packages without a -devel subpackage).

It is okay to say that Stream may not be bug-for-bug identical to released versions of RHEL, but it will be ABI compatible.

I was thinking specifically in the context of ZFS, which break on minor releases because kernel-internal symbols are not fully stable (unless I've seriously misunderstood https://github.com/openzfs/zfs/issues/11320). And since Stream is a rolling release, users will therefore experience breakage unless they specifically pin their kernel version (or possibly use DKMS). That's ABI breakage, and RH explicitly saying that it doesn't count doesn't stop it breaking stuff that would work in a non-rolling release.

Again, please review the Kernel ABI knowledge base resource I provided, specifically the last two bullet points in the article.

If OpenZFS happens to work throughout an entire RHEL minor release and they are using non-kABI symbols (which they are), that is not ABI compatibility: that's _luck_. It is in no-way-shape-or-form any kind of ABI compatibility the way it is defined for RHEL. You can't call RHEL kABI/ABI compatibility something it's not, it has an explicit meaning and definition.

Per the GH issue you provided the project explicitly stated they did their best to reduce as much as possible their reliance on non-kABI symbols. This was accomplished through symbols being added to the RHEL stablelist and OpenZFS reducing the symbols they actually use. If they didn't have to use non-kABI symbols there wouldn't be a problem. I've had NVIDIA kmod's from ELRepo fail _multiple_ times in a single minor release because non-kABI symbols changed, not to mention between minor releases. This is still not an example of RHEL kABI/ABI breakage.

> The only thing I miss are delta RPMs.

Delta RPMs just aren't worth the pain. They were a nice idea at the time but the utility of them has not kept up with the cost of supporting them.

Reply on news.ycombinator.com