Hacker News Reader

Hacker News

Comment by wooque | Hacker News Reader

Full thread

wooque

What's advantage of Fedora over something like Arch?

View on HN

You get updates every 6 months with a really nice upgrade experience. It is not rolling.

Compared to Ubuntu, more stuff is upstreamed and the package management is nicer (dnf history undo is a lifesaver).

> You get updates every 6 months with a really nice upgrade experience. It is not rolling.

Also worth noting that these updates are optional. A given release has a ~13 months of support:

---

We say maintained for approximately 13 months because the supported period for releases is dependent on the date the release under development goes final. As a result, Release X is supported until one month (4 weeks) after the release of Release X+2.

This translates into:

  - Fedora 34 will be maintained until four weeks after the release of Fedora 36.
  - Fedora 35 will be maintained until four weeks after the release of Fedora 37.

https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Mai...

You get upgrades every 6 months, but updates are rolled out constantly. For example Fedora gets the very newest kernels at the same pace as something like Arch, even for older releases. Fedora 33 currently has the same kernel as Fedora 35.

I would consider it "semi-rolling". It has major releases, and a few packages are pinned for the duration of the release, core stuff like glibc, systemd, GNOME, compilers / toolchains for various languages and so on. But the rest of the system is kept very up to date.

Not specifically about Fedora but Fedora Silverblue for me:

The key value for me is, if an update breaks something, I immediately roll back to the previous image (with just 1 terminal command) and don't have to deal with it unless I actually want to do so.

Recent software just as in Arch while not fearing to upgrade and being unable to boot because you didn't read "edit this config" notice?

Fedora is Red Hat's "flagship" distro, in the sense that it's where all the cool new changes debut. Since Red Hat's pretty involved in core Linux development, Fedora is often one of the first places you can get major changes without having to set it up yourself. Like Pipewire for example: it's been available on Arch and Fedora for a while now but Fedora's the first place you can use it without having to set it up yourself afaik.

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.

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.

Easy installation, tested packages, a lot of proprietary software comes as rpms but not arch packages

I think a big advantage of Fedora (also Ubuntu) is that a lot of its maintainers are being paid by Red Hat to maintain it. A lot of times your bug reports are going to be quickly read, you know it's very likely there is someone who is getting paid to ensure whatever problems you may have, don't happen. I know a lot of other distros have this too, but Red Hat employs a lot of Fedora maintainers.

OTOH, you're kinda subject to Red Hat's will. But then, every project is subject to its controllers. It's not like the Debian people are doing a good job just because they're not subject to a for-profit company.

Personally, I am very thankful for fact that the Fedora project is often the first to adopt certain technologies and inflict in their users the pain of fixing the first bugs and stabilizing the technology. Then a few years later I get it in Debian and it works just fine.

You get SELinux by default if you care about security although it's kinda esoteric and hard to understand.

You get to work on a potentially Red Hat Enterprise Linux like distro. Might come in handy professionally.

Hmm, can't think of anything else. I use Arch.

> SELinux [is] kinda esoteric and hard to understand

I don't totally disagree with you, but a thought suddenly struck me: maybe, exactly like Git, it isn't hard to understand, it's just that the UI, UX, and attendant documentation are not written for the majority of their potential audience. And thus, in the same way that many people fix Git problems by simply blowing away their local repo and starting over, SELinux users simply `setenforce 0` and walk away.

It depends upon what kind of work you do, like if you do music with Bitwig anything but Ubuntu is going to be a nightmare.

Latest packages, little effort

Reply on news.ycombinator.com