Recently I have been asked (again) why to use Arch Linux when choosing a linux distribution. Because my fellow inhabitants of the IRC channel affected are always very pleased by the wall of text awaiting them after such a question when they return to the keyboard, I decided to write down my thoughts on that matter so that in the future I can simply link to this post.

I use Archlinux as my main distribution and will lay out why I personally like it. Afterwards I will also line out why you might not want to use Arch Linux. This is merely a collection of arguments and is certainly neither exhaustive nor do I claim to be unbiased in this matter, as I personally like the distro a lot. Ultimately you will have to decide on your own which distribution is best suited for you.

This post is about the specifics of Arch Linux in the family of Linux distributions. It is not about comparing Linux to Windows or OSX or other operating system families. But enough of the chitchat, let’s get to the matter at hand:

Why to use Arch Linux

Simplicity

Arch is developed under the KISS-principle (“Keep It Simple, Stupid”). This does not mean that Arch is necessarily easy but the system and its inherent structure is simple in many various aspects:

Few abstraction layers

Arch generally has very few abstraction layers. Instead of having a tool to autoconfigure things for you, for example, configuration is usually done manually in Arch. This does not mean that something like Network Manager is not available in the package repos, but that the basic system configuration is usually done without additional tooling by editing the respective configuration files. This means that one has a good feeling for what’s going on in one’s own system and how it is structured, because one has made those configurations oneself.

This also includes no automagical merging or changes when an update requires a change in a configuration file. The way it is handled in Arch is that pacman, the distribution’s packacke manager notices if a configfile was changed from the packet’s default and will then install the changed version in the packacke with the extension .pacnew while telling you about this so that you can merge those files on your own after finishing all the upgrades.

Easy, yet powerful system to build packages

Speaking of packages, it is very easy to build packages in Arch. You simply write your shell commands that you would use to compile/install/whatever the software you want to use into a special function in a so called PKGBUILD-file, which is effectively something like a buildscript, call makepkg and you end up with a package to install your software package-manager-controlled. The packet itself is nothing more than a mirroring of the file system tree relevant for that package plus a little metadata for the packet manager.

It is also very simple to rebuild packages from the official repositories, e.g. if one wants to have features compiled in that the default configuration in Arch has disabled (think of a kernel with custom options). asp, packaged in the official repos, provides you with tooling to checkout the sources you need for that purpose. Edit one or two simple files and you are ready to go.

No unnecessary packet splitting

Software in Arch is usually packaged as it is organized by the upstream-developers. This means that if upstream provides one software, this software will end up being one package in Arch and is not splitted into multiple packages, like for splitting out plugins or data files or something like that. This reduces the amount of packages present and increases overview.

Getting rid of old

If a technology used in Arch turns out to have better alternatives and the developers decide to transition to the new technology, then this transfer is done in one strong cut. This means no legacy-tech lying around in the system, but the new technology will be fully integrated without having to make compromises because old technology must still be supported.

One example for this is the sysVinit-to-systemd-transition: instead of using systemd’s capabilities to also be compatible with sysVinit the transition was made en bloc. This makes the integration of systemd very smooth and without compromises to backwards compatibility, which simplifys usage a lot as one gets rid of a lot of cornercases that would have otherwise needed to be considered.

Getting rid of old in general

Generally, getting rid of old tech is one of the major things I like about arch. If there is something new that is better than the old solutions or will eventually be adopted, those things will consequently adopted.

Another example is the restructuring of the file system hirarchy, namely the unification of /usr/bin, /usr/sbin, /usr/lib, /bin, /sbin directories /lib into /usr/bin and /usr/lib. Several distributions have announced to perform that unificaton eventually, but instead of doing this successively one after the other (which other distributions even spread out over several major-releases) and dealing with this issue over an extended period of time, the Arch Devs decided to unify all of it en bloc, being done with it once and for all.

Also, instead of trying to be convenient on updates and providing compatibility when something changes, the Arch package manager will tell you that manual intervention is required, you do the necessary changes and your system is migrated to the new, compatibility-layer-free new configuration. Such interventions are, however, rather rare and are prominently announced on the arch-announce-mailinglist, the news feed on the website and the website itself, so just subscribe somewhere and you get notified if manual intervention is required on the next update and what to do. This also means, though, that in Arch you should not do automated updates, but manual ones and read the upgrade log, just in case something comes up.

Documentation

Arch has excellent documentation. The Arch-wiki, especially the english one, is usually an excellent, very detailed source of information to the point that I tend to look up problems that I have in other distributions in the Arch-wiki, because chances are good that the problem is covered in the Arch-documentation. This reaches the point where for me the Arch-wiki sometimes even surpassed project-internal documentation in its usefulness.

Learning

Arch is a quite hand-curated hand-curated distro compared to other distributions out there. One is exposed to the internals of the system as a lot of things in Arch are simply done by hand instead of having a tool that does that (see above). And while I would not claim that Arch is necessarily easy (although simple), in combination with the excellent documentation it can be a very fruitful learning experience. However, it is learning the hard way, so if that is your goal, Arch is in my opinion very suited for that, but you have to be willing to (depending on your previous experience) climb a steep mountain. Nevertheless, I can fully recommend Arch for that purpose if you are willing to do. Especially as, once you are at the top, you get to enjoy all the other benefits mentioned.

Software and Updates

Rolling Release

Arch is not a fixed-point-release-based distro as many others, but a rolling release distro. This means instead of having a new release with new features every couple of weeks, months or years, Arch ships new software more or less as soon as it gets released. Therefore instead of having certain ponts in time where a lot of new stuff is coming in (possibly a lot, possibly requiring migrating to new software versions), new stuff is coming piece by piece spread out in time. This is primary a thing of personal preference, but I find it more convenient to have regular feature updates (99.5% of cases without the need to intervene at all) instead of having to apply and test large updates with a new point-release.

Bleeding Edge

Arch’s rolling-release-model not just ensures that softare comes in spread out over time, but it also allows for software to be shipped once it is released, and Arch makes use of that. This means that Arch is one of the distros with usually the most recent versions of software, getting new stuff as soon as there is a new upstream release.

Vanilla Software

Another thing I really like about software in Arch is that it is shipped as upstream intended, which means the software compiled is usually precisely the code that upstream released, there are, no distribution-specific patches applied. Exceptions to this rule are extremely rare, for example a stability fix in the kernel that was already upstream but not yet released. That patch lived for a short while in the linux-package in Arch, but was removed again once upstream shipped the fix.

AUR

The official package repositories are filled with most of the software one needs for daily business. However, if a software is not in those repositories, one can easily package it oneself, as mentioned above, and a lot of people might have already done exactly that. There exists the Arch User Repository, which is a collection of the PKGBUILDs used for that, along the lines of “hey, I needed that software and packaged it for myself, anyone has a need for the PKGBUILD-file I used?” So if one needs a software that is not in the official repositories, chances are fairly large that someone else already did package that software and one can use that buildscript as a base for the own package. This even applies to a lot of niche-packages you might never have expected to have been packaged at all.

Things to consider

I have pointed out why I like Arch Linux very much and why I definitely can recommend it.

However, be aware of a couple of things:

• If you just want a distribution that is fire-and-forget and just works out of the box without manual configuration, Arch is not what you are looking for.
• If you want a rocksolid distribution that is guaranteed to never break in any minor detail, then you are better served with something like a Debian (and its stable-release), as the fact that Arch ships bleeding edge software bears a certain remaining risk of running into bugs no one has run into before and that slipped through upstream’s and the Arch’s testing-procedures.

If none of those are an issue for you (or negligible compared to the advantages), Arch might be a distro very well suited for you.