The state of rolling release Linux distribution

Written on 2020-04-25

I have been using Debian (stable, then testing as well as unstable for a brief period) for years and although I've had experience with many other distributions through friends, family and work, I do not condone distro hopping.

With that being said, a few weeks ago, I have considered switching to a different distribution. My issues with Debian were the following:

Debian testing is not meant to be an up to date distribution. While it receives frequent updates, waiting for a new major release can feel a little to long sometimes. This is especially annoying when trying to build a project from source when the system libraries are too outdated.
Although the Debian repositories are huge, it takes a long time for newer programs to be packaged and land in the repositories, if it ever happens. For instance, it took over 3 years for the polybar package to enter Debian, despite being available for dozens of other distributions and BSD variants. I was frustrated to have to manually manage build/runtime dependencies for otherwise popular packages.
I dislike the complexity of the Debian packaging system.
I do not agree with the priorities of the Debian project.
I do not agree with the ideology of a large portion of the Debian community.

These issues started bothering me enough that I decided to list what I wanted from a distribution, which might warrant a switch:

A rolling release, as up to date as possible without sacrificing stability. I prefer manually managing or waiting for a package for a few weeks rather than encountering issues with my system.
Stability as a project. I need to know that the distribution will remain be healthy for many years as I intend to not switch away from it.
Support for most of the packages that I use, preferably in the official repositories.
A way to setup a minimal and lightweight system.
A low maintenance system.
Good support for third party software, either because of its ubiquity or via the community.
A pragmatic approach to software freedom, meaning that the distribution should be fully free with opt-in, controlled support for using proprietary software.
A simple package format would be nice under the condition that it would be widespread enough to be useful.

With that being said, here is list of the distributions that I considered using:

Void Linux

Void Linux has many things going for it and the options for using a non-standard libc and init as well as the support for source packages are nice. However, I was concerned about the stability of the project, which had already lost one of its main domains while its leader went missing for months. I was proven right a few weeks later.
Although I respect the efforts of the Void team to restructure the project's leadership and wish them success, I do not have enough trust in its longevity at this point.

Solus

On top of suffering from the same issues as Void, I have seen it break for no reason too often and it is a bloated system. The software selection is also very restricted.

OpenSUSE Tumbleweed

While great on paper, Tumbleweed suffers from stability issues when non-official packages are involved and it seems to suffer from cognitive dissonance, suggesting users to use OBS to get software missing from the main repositories, but telling them that their use is discouraged for stability reasons.

NixOS

I find NixOS to be amazing on paper, as managing a system in a declarative way sounds fantastic. In practice however, it takes a lot of work to get new things working on it, especially from third parties. For instance, one cannot just write simple scripts without adding a layer of indirection to even find the right binaries, making it too heavyweight as a personal system for my taste.

Gentoo

It simply is too much of a maintenance burden and the compile times are not justified.

Arch Linux

In the end I decided to go for Arch, after mocking it heavily for years. I could also have picked Manjaro for the delayed updates, but it has a drastically smaller user base and going downstream increases the points of failures and potential complications.

The idea was simple: I would get up to date software, despite hearing horror stories about it from friends, it seemed stable enough and I could use the AUR to easily manage software that wouldn't be present in the main repositories, so I ended up biting the bullet.

I will first talk about the things that I liked about Arch Linux as it will be short:

The AUR is a convenient tool. Being able to git clone, review a script and makepkg -sirc is a much more comfortable experience than having to manually figure out how to build and install a package and which dependencies can then safely be removed.
The packaging format that Arch uses is very straightforward and simple, which I appreciate.
While the community is mostly toxic and a brilliant display of the Dunning–Kruger effect, it at least isn't an anarcho-activist group.
pacman is a very fast package manager. While this is not an important feature, it is nice to have.
Packages are indeed up to date.

Unfortunately, I realized that Arch also has big issues that I had not anticipated.
First of all, it simply isn't as stable as Debian is. For instance, I have had audio issues: some ALSA tools wouldn't work where their PulseAudio counterparts and most importantly, the kernel would have huge CPU spikes. In these moments, I couldn't elevate privileges or even power the system off. This kept happening with different kernels as well and is not acceptable in terms of stability. In my few weeks of using Arch conservatively, I've probably had more issues than in years of tinkering with Debian testing and unstable.
Although Arch's packaging format is nice, the quality of the packages in the Arch repos often isn't. For instance, while pacman supports changelogs, this feature is never used in practice. This means that the users have to blindly trust whatever updates are spoonfed to them without knowing what they are about. Although the changelogs for Debian packages are often imperfect, they at least always mention what an update is about and upstream changelogs are often included if available. On Arch, there is no way of knowing whether it makes sense to wait a little bit before updating or not.
On the subject of package quality, the way dependencies are specified are all over the place. Sometimes it is necessary to manually install dependencies to get a package to actually work, sometimes they bring the whole world for no good reason. It makes no sense that some GUI programs are installable without either X or Wayland while others have both of them as hard dependencies!
Another issue that I've had with the Arch packaging system is that it does not clearly distinguish between free and proprietary packages the way Debian does. For instance, Discord is in the main repositories and the package does not indicate that it contains proprietary software.
But these complaints only apply if you can find the package that you are looking for to begin with. My plan with Arch was that I would install the same packages as on Debian, except that I would use the AUR to install the packages that I previously manually built from source. However, I do not trust the AUR, so I would review the build scripts before installing packages from there, which would still save me a lot of time and hassle. Unfortunately, I realized that the official Arch repositories lack a lot of software that I depend on, which are even in the Debian repositories! Reviewing all of them, especially the ones that I want to keep up to date, would cost me much more time than on Debian, where I only need to maintain a few programs.
Finally, while I don't personally care much about extreme minimalism, I find it pathetic that Arch is touted as a "minimal" distribution. When first installed, it is barely lighter than an Ubuntu minimal install, but by the time key programs are installed, the Arch system will be much more bloated because the packages are much more bloated. A great example of that is the TeX Live distribution. A user that doesn't care about linguistics or publishing will only be presented with the texlive-core and texlive-latexextra packages, which contain the entire distribution. In comparison, users of Debian-based distributions can pick only what they need, resulting in a much more minimal system despite a higher package count.

In the end, even though I had very low expectations of Arch, it has still massively disappointed me in the last few weeks, to the point that I couldn't bring myself to just ignore it's warts. As a matter of fact, typing this article is the last thing that I'll do before wiping it from my system and replacing it with my trusty Debian. Even though I disagree with its direction, it is in a better place than the alternatives. At least, Arch has taught me something for good: distro hopping is indeed a meme.