I get asked from time to time which distribution I’m currently running whenever I make videos. My answer to that question will usually depend on which distribution is my “flavor of the week,” but from now on my answer will most likely not be Arch Linux. I figured I would write this article not to bash Arch Linux or disparage their developers, but rather to talk about my experiences and what has led to this decision.
I began using Arch on August 16th, 2009. I remember that date, since it was my birthday, and I see my “join date” in the Arch Linux forums as that date every time I log in, and at the time, I thought it was an amazing gift to myself. In a lot of ways, it still is. Arch Linux is simply an amazing distribution. There’s nothing greater than being given a bunch of pieces, that you can assemble in any way that you want. Your install is literally yours – you’re given the tools to create an awesome desktop experience just the way you like it. I created some videos on my Youtube channel, to help others with installing this distribution, and I’ve even done a video on the best ways of maintaining it.
Unfortunately, my experience has not been very stable, even when I take my own advice. It seems that I constantly run into one problem after another. Granted, I’ve read comments on my Youtube channel from viewers that have written to let me know that their installation has gone smooth, and they have never run into any problems at all. That’s awesome for them, but when it comes to Arch, your mileage may vary. Perhaps you’ll never have issues, or perhaps you will, and those issues will give you an opportunity to dive deeper into your system, fix it, and learn valuable lessons from the experience. In my case, I’ve learned A LOT from Arch about Linux in general, that has served me well with other distributions. Even with issues, it’s been a wonderful experience, and I still feel that Arch is an amazing distribution, even while I type this blog post about how I’m not going to use it anymore.
So, what led to this decision? As I mentioned, I’ve experienced one issue after another. And while I can certainly fix these issues and move on, it’s getting old fixing one issue, just to update and experience additional issues. You’re probably wanting specifics, though. So I’ll go through some of the issues I’ve experienced, but I’ve not really done a good job keeping track of the time-frames, so I’ll just provide some examples in no particular order.
First, I’ve experienced a couple of times where a kernel update ended up being incompatible with my machine, causing it not to be able to boot. To recover, I can use the Arch live CD to boot my system, chroot into my install, then downgrade my kernel. The reason this is required is due to the fact that Arch doesn’t stack kernel updates. When you install a new version of the base kernel, you’re replacing your existing one. It’s not like Debian, where new kernels are installed in addition to your current one, giving you an opportunity to select a different one during the next boot. With Arch, you’re replacing your only kernel each time you update.
Later, I’ve learned that I can also install the LTS kernel with the kernel-lts package. With this method, you can have both your base and LTS kernels installed, and switch between them at boot. If one doesn’t boot, the other likely will. In addition, you can install additional kernels from the AUR. However, even with being able to install an LTS kernel, I still feel that Arch replacing your base kernel instead of stacking kernels is an absolutely horrible design decision, such that I cannot fathom how anyone could have designed a distribution that way with a straight face. Don’t get me wrong, the developers of Arch are very intelligent and competent at their craft, so my point is not to insult anyone. But I’ll call it like I see it – not stacking kernels is a mistake.
Although I complained about the way kernels are updated, I did also mention a valid work-around (installing both the base and LTS kernels). But my next problem is relates to the instability of the display server in Arch, specifically Xorg. More often than I can count, I’ve had updates that would sometimes cause my X server to randomly drop back to the login screen. when this happens, I lose everything that I’m working on (that I’m not hosting in a tmux session). Most recently, this was due to an incompatibility between xscreensaver and Xorg, that I later found out by trial and error over the course of several days. I basically noticed a pattern that X would only drop when left idle, and screensavers typically appear when your session is idle. Although I never caught my machine in the process of X crashing, it would only happen when I stepped away and then returned to my machine. I disabled Xscreensaver, and then no more crashes. Later on, this bug was fixed with updates, but then after a while, this bug returned out of nowhere with other updates. I could simply just never use screensavers anymore and find an alternative to locking my screen, but other distributions allow me to use xscreensaver with no issues, so I don’t see why Arch has to be a pain in this regard.
Another annoying issue that has come up (this one is more recent) is that a recent update would cause GDM (the GNOME display manager) to break whenever I log out of my session. Basically, the GDM screen would appear when I start my machine, and I would log in as normal. When I logged out, GDM would fail and show nothing but a blank gray window. Restarting my machine would solve it, but this was an annoying problem. It happened every time I logged out. My work-around was to disable GDM, and switch to LightDM, which worked. But with LightDM, I also lost GNOME’s ability to do screen locking, since the GNOME desktop requires GDM for that purpose. I could use xscreensaver to lock my screen instead, but by doing so, I’d make X unstable again. This is another situation I’d run into with Arch, where I would end up in a Kobayashi Maru (no-win) situation.
Although I mentioned problems with GNOME and GDM, I also use Openbox quite a bit as well. Recently though, I’ve run into a problem there as well. You would think that Openbox would be more stable (less moving parts) and it is, but only to an extent. With Openbox, you can use a program called obmenu to update your right-click menu (which is the Openbox equivalent to an application menu). With a recent update, updating the Openbox right-click menu with this app crashes X and drops me back to a login screen. Every single time. All I have to do is click the save icon, and bam, I lost all my work and am taken back to the login screen (which given my recent GDM problem, may or may not work).
Today, though, was the last straw for me. On all my workstations, servers, and even my Raspberry Pi’s, I use Ansible to keep everything consistent and updated. I’ve even created a very neat Ansible setup, that takes an Arch Linux installation from nothing but the command-line, to a full-featured desktop. No manual configuration needed – I just install Arch’s base, then run Ansible against it, and everything is set up for me. This took a lot of work, but it also saved me a lot of work since each time I needed to bring up an Arch install, there was no work required. This has worked fine, until today. For some reason, Ansible no longer works properly with Arch. To illustrate this, here’s an example of one of my Arch playbooks. This is just an excerpt of the Ansible playbook I created that installs Syncthing.
- name: install syncthing (arch)
pacman: name=syncthing state=latest
when: ansible_distribution in ['Archlinux', 'Manjaro Linux']
- name: enable syncthing
command: systemctl enable firstname.lastname@example.org
WordPress disrupts the spacing in the example code, but you get the idea. Basically, when the syncthing package is installed, it should register the syncthing variable, except it doesn’t. The next block should execute, since the preceding one did make a change. However, what happens is that Ansible will install the package, but then something with Arch blocks the variable from being registered. This playbook works fine on all other distributions I’ve tried it with, which include (but are not limited to) Ubuntu MATE, Debian, Linux Mint, and Fedora. In fact, this playbook worked fine with Arch as well. But as of today, it doesn’t, for some reason.
There are many other issues I’ve run into, but I’ll stop there.
So, that brings me today, where I’ve decided that I will not be using Arch Linux anymore. It pains me to say this, because Arch is (as I’ve mentioned) a fantastic distribution, developed by some awesome engineers. But when it all comes down to it, it’s too much work to keep it going. I’m 100% certain that with some additional research I could overcome all the issues I’ve mentioned in this post. But I’m also 100% certain that if I did, I would run into additional problems I would need to fix with some update or another that comes down the pipe. Yes, that was certainly a pessimistic statement. But then again, encountering and fixing problems with Arch has been a constant way of life for the past seven years I’ve been using it. I’m tired of it, and it’s not for me.
Arch fans would most likely remind me of the fact that if Arch breaks, you get to keep both pieces, and all I would need to do is Google and look up fixes and work-arounds (as I have been doing). They would remind me that since I was provided the tools to create my own installation, I’m ultimately responsible for my own concoction. All of those statements would be valid, and true. However, I really have to think about how much my time is worth, and whether or not fixing issue after issue is a good use of my time, even if I was able to recover from them.
Now, this wouldn’t be a post about the downfalls of Arch if I didn’t bring up their community. Sometimes the Arch Linux community can be downright hostile. When you post at the Arch Linux forums and there’s any inclination that you may have missed any step during your research, you will likely be flamed and told to “RTFM.” It doesn’t matter if you have done a lot of research, if there’s any loophole in your post, forum posters will find it, and flame you for it, and accuse you of not doing research or not reading the Wiki. I’ve generally learned to avoid the Arch forums as often as I can. I can certainly understand the frustration that comes from users not even attempting a Google search before posting a question. Since helping users in a forum is an unpaid community donation of your time, it’s disrespectful for people to not do their own research before they post. I get it. But regardless, flaming people and telling them to RTFM is NEVER acceptable. Sometimes, in the community, you deal with people that are lazy and don’t want to do research, and expect answers handed to them. This is a problem with all of society. But if someone is the type to search for weaknesses, constantly pick apart users, or be otherwise disrespectful of them when they post, they need to excuse themselves from the community as they are doing no one any good. I know it’s frustrating when users don’t do their own research, but this is human nature. Either deal with it, or stop posting responses in forums. This mentality is ruining not just the Arch community, but the Linux community as a whole.
Although Arch makes wonderful tools available to me (and their wiki is quite possibly the best Linux wiki of all time) I still think that some further effort by the developers should be put into stability. Don’t get me wrong, I get it – developer resources are spread thin, and it’s hard enough to maintain a distribution let alone make everyone happy. The latter is probably an impossible goal for any distribution or operating system. But given the issues I constantly run across, I have to wonder if there’s a better way, a way of having a rolling distribution but also have some sort of expected level of stability. I’m not a fan of non-rolling releases to be completely honest. If I want the latest version of a package, why shouldn’t I be able to have it, without compiling from source or using an unsupported repository? After-all, Windows and Mac OSX users don’t have to wait for the next version of their operating system in order to be able to install the latest version of software such as LibreOffice. That’s the main benefit of Arch (beyond the AUR and its awesome Wiki): the mentality that you shouldn’t have to wait for the latest stable versions of your favorite applications. I also think that having the latest apps available from day-one is the future, even on Linux, and will be the reality before we know it. But as it stands, literally no one offers a truly stable rolling distribution. Arch has come close in many ways, but when it comes to me, the instability defeats it.
So, that’s it, I’m done with Arch. I’ve removed it from my Fabric scripts and Ansible playbooks. It’s been a wonderful experience outside of the issues I experienced, as I’ve learned a lot and otherwise enjoyed my time with Arch. And as I’ve mentioned, I don’t want to disparage any of the Arch developers since they’ve been wonderful, and I don’t want to persuade anyone to stop using Arch, since it is a fun platform to use. From here, I’ve decided that the best way to have a (somewhat) current distribution is to switch between Ubuntu MATE LTS and Debian. Basically, I’ll always use either the latest release of Debian or the latest release of Ubuntu MATE LTS (whichever is newer at the time). This means that I’ve installed Ubuntu MATE 15.10, which I will upgrade to Ubuntu MATE 16.04 LTS when it comes out. When Debian 9 is released, I’ll switch to that, since it will come out after Ubuntu MATE 16.04 LTS and will therefore be more current. Then, I’ll switch back to Ubuntu MATE with 18.04 LTS, and so on. I think this is a good way to have a stable Debian (or Debian-based) system and keep it relatively current, since Ubuntu LTS and Debian stable seem to be released during alternating years.