Why Does Arch Linux Exist?

I love Linux. I’ve been using it since at least 1994 back when Slackware and TAMU were the big boys on the scene, before Red Hat was even a thing. As it matured and developed I began to rely on Linux more and more for real work, moving from just a hobby OS to a real grocery getter. Nowadays, I use it pretty much every day for a wide variety of things, ranging from Internet web servers to office Odoo servers to desktop computers (although I do still use Windows for some things like video editing). Over the course of the last 30 years, I can say that I’ve come in contact with just about every significant Linux distro that has come down the pike.

At one time or another, I’ve claimed Slackware, Red Hat, Mandrake, Debian, Gentoo, Ubuntu, Mint, Arch, and Fedora as my daily drivers. These days, Gentoo and Mint are my distros of choice. When I need things to just work with no muss and no fuss, I use Mint. It’s installed on the desktop PC in my office right now. When I feel like getting my hands dirty or when I’m doing a specialized task like cross-compiling in a qemu environment or using distcc to speed up compiling on a Raspberry Pi, I prefer the power and flexibility of Gentoo. I say all of that not to try and sound pompous about it, but simply to establish that I’ve been around a long time and I’ve seen a lot of things in the *nix world.

With that said, let’s get to the point. I know some people, particularly professional developer types, who swear by Arch Linux and won’t use anything else. But having recently had a string of bad experiences with it in a production environment which I was more or less forced into (it’s a long story, don’t ask), I’ve really been thinking about a question that I just can’t get out of my head. Why does Arch actually exist? Most Linux distributions exist because they fill some particular niche need, so what particular need does Arch fill in the *nix ecosystem? For the life of me, I can’t figure it out. From what I’ve been able to see, there’s nothing it does that other distributions don’t do just as well or better.

In fact, I would go so far as to argue that Arch brings together all the worst aspects of a standard point release distribution and all the worst aspects of a source-based rolling distribution, while providing the benefits of neither. It’s the worst of both worlds in my book. Before you start flaming, allow me to explain.

When binary packages are compiled by the maintainers for inclusion in a Linx distribution, the package maintainers necessarily make certain choices. What processors do we build support for? Do we build the optional X-windows component, or no? What codecs do we build into ffmpeg? On and on. Once you decide to use that particular distribution, you are bound by the choices the maintainer has made in those matters, for better or for worse. However, by making all of those choices for you and selecting the packages and options for inclusion (e.g., a desktop environment), the distribution is able to provide a consistent and highly polished user experience. I would put an out-of-the box Mint installation up against MacOS or Windows in terms of user experience without hesitation.

The alternative to that model is using a source-based distribution like Linux from Scratch or Gentoo in which you can make these choices for yourself. The tradeoff is that because you are making these choices for yourself, everything comes down pretty much bone-stock from upstream and it’s up to you to do all your own customizing. You are also frequently getting either untested or lightly tested packages from upstream, which means that the probability of breakage is fairly high and it’s assumed that because you are using such a distro you have the knowledge to deal with that. That’s fine for people who know how to do it and like doing such things, and the result can often be a more finely tuned installation than is possible with a point release distro.

For me, Arch combines the worst of both. Everything is more or less bone-stock and untested bleeding-edge stuff from upstream AND because it’s a binary distro, you are also stuck with the packaging choices the maintainers have made for you, just like a regular point release. Pacman is a nice package management system, but I don’t see how it’s any nicer than apt, yum, or portage. They all do automatic dependency resolution and have the same basic set of features. AUR is also a nice software resource, but again, I don’t see how it’s any nicer than a portage overlay or an apt repository.

But the biggest problem with Arch from where I sit, and the one which makes it wholly unsuited for pretty much any production use case, is the inability to choose or mask the versions of packages that you install. There is no stable/unstable branch like there is in Gentoo (not that there’s honestly much difference in practice, tbh), and you have to take the latest and greatest of everything whether you want it or not. This is where Arch really falls down for me.

Let’s take the example of nodejs. Before I start, I need to say that I’m fully aware that nodejs versions can be managed with nvm, and that’s exactly what I’ve done where I needed to. I’m just using node as an example because node and npm packages seem to be built on quicksand more than anything else I’ve run across and they seem to break constantly. You can insert whatever package tickles your fancy in its place, because eventually this WILL happen with something, somewhere on your system. Humor me for the purpose of the example.

Let’s say that you have a piece of in-house software that depends specifically on node v15. Node is currently at v17 as of this writing and will break that piece of software. Arch will force you to upgrade to v17 whether you want to or not, necessitating a rewrite of the software you already paid to develop once. At that point you have two options — never update the system, or rewrite your custom software. You can temporarily avoid the issue by telling pacman to skip that particular package if you know there’s going to be a problem (that’s a big “if”), but you’re only treading water by doing that. Eventually your system will break because the libraries that nodejs depends on will be updated to a version that’s incompatible and you’ll really be in a pickle. The response you get from a significant percentage of developers is, “Keep your software current and you won’t have to worry about it.” That’s all well and good from the guy who doesn’t have to stroke the check to keep it updated at all times, but what about the business owner who does? Is that a good answer for her? I think not.

Whatever the faults of point based distros, you can usually be sure that you won’t get a system-breaking update like that unless you consciously choose to do a major version upgrade, at which point I’m going to assume you’ve done some in-house testing to be sure you know what you’re getting. Source-based rolling distros like Gentoo handle this problem the correct way. Just create a mask file for portage that says to mask versions > node15.5.7 or whatever. Or if you want maintenance releases to 15, you can say mask ≥ node16. And because it’s source based, nodejs will always build against whatever version of the libraries you have installed regardless of how old or current they are, meaning that your system won’t break for the foreseeable future.

So to summarize, Arch sticks you with the binary choices made by the maintainer, lacks the polish of point based distros, forces you to take the latest and greatest whether you want it or not, occasionallty sends you broken packages, and generally exhibits unpredictable updates. If somebody wants to mount a defense of Arch and explain what paticular need this serves, I’m seriously all ears. I want to know, because right now I don’t have a clue. I can only assume there is some itch that it scratches somewhere, but I can’t imagine what it is.

Leave comments, and if they are persuasive I’m open to reconsidering my view.