Rolling Linux one year later
It’s been a little over a year since I switched from Ubuntu to Arch Linux. Both distributions are major players in the Linux world, though Ubuntu clearly has the larger market share. While it may seem like a choice between apple pie and cherry pie to some, these distributions actually have very different characteristics. Ubuntu is targeted at non-technical users and has a 6 months / 2 years release cycle for latest / LTS versions. Arch is targeted at technical users and has a rolling release model. The latter has been the main reason why I made the switch in 2018.
There is a lot to say in favour of Arch. The installation is entirely manual and although it takes much longer than an installation with an automated graphical installer, you get to configure your system exactly as you need it. I consider that a big advantage. Unlike in Ubuntu, you won’t have a bunch of applications and services that you don’t need. These may eat up system resources and could present maintenance issues down the road. Being always up-to-date is likewise an advantage. On Arch, you will never run into a situation where you have to install manual upgrades. It’s always fresh.
Since system updates are performed manually on Arch, you get to decide how often you want to refresh your system. I’d recommend a minimum of monthly updates, so that you can take advantage of the latest security patches. I usually run it every week. The Arch package manager (pacman) is easy enough to use and its dependency management is very reliable. In some rare cases, where you absolutely need an older version of a certain package, pacman allows you to selectively downgrade packages. To that end, the system keeps a cache of previous package versions which facilitates rollbacks.
System configuration and management is largely done via the command line in Arch. As I am using my computer for software development, I have Docker installed, several development platforms, as well as several native web server and database services. Eventually everything will be containerised, but for now I still need some native services, mainly for tooling and testing. Arch Linux offers systemctl and journalctl for system management. The Arch Linux online documentation for these and other Linux tools is of very high quality. I haven’t yet encountered any issues that I wasn’t able to solve with the help of the online documentation.
Despite all that, I would be lying if I said it’s always been plain sailing. Arch can be pretty unforgiving if you make mistakes, or perhaps worse, if you don’t know exactly what you’re doing. This situation will arise, trust me, even if you are an expert Linux user. How many users review each AUR package before download? How many users review possibly deprecated packages or configurations before upgrading dozens or even hundreds of them? It’s simply too time-consuming. You assume that things do work, and if they don’t you either roll back or analyse and fix the issue.
During the past twelve months, I’ve encountered upgrade issues more than once. It could be something benign and easy-to-fix, such as a Gnome shell extension that stops working after the upgrade. It could be a little trickier, such as a service that fails to start up automatically. Or it could be entirely “catastrophic”, such as a kernel module incompatibility or a graphics card driver that stops working. The latter didn’t happen to me yet, but yesterday it was a deprecated Gnome configuration that kept my desktop from starting up. It took me five hours to fix this problem. So far, it was the most time-consuming issue in my short history of Arch Linux computing. It took so long, because the logs didn’t give any indication about what went wrong.
If I add up all the hours that I spent with installing and fixing things in Arch Linux, I get somewhere between 3 and 4 work days. Most of that time went into the tricky dual video card configuration during installation. Part of that were 10 hours of fixing various problematic system upgrades. This is significantly more time than I spent with maintaining other Linux distros. I can probably live with 8-10 hours of maintenance per year if it keeps the system lean, fresh and secure. But if the time demands go up in future, I will have to look for alternatives. After all, I want to spent my time with software development rather than with system maintenance.