Some notes on Arch Linux

Posted on 17.08.2009 by Kim N. Lesmer. Last updated on 23.07.2016.
I have been using GNU/Linux, FreeBSD and OpenBSD exclusively since about 1999. I am running Debian on my laptop and on one of my desktops. I am running FreeBSD on my other desktop. I also have a couple of servers where I run Debian and OpenBSD. I spend time with Linux and BSD every day, and I am very happy with the quality of Debian, FreeBSD and OpenBSD. From time to time I still test different Linux distributions to see whats new in the world of Linux, but in eight years I have never shifted to another Linux distribution and I don't think I ever will (thanks SystemD!). Arch Linux is really great, but it is not for people wanting a stable desktop or server system.

This small review was first published on 04.11.2008, but I have now re-tested Arch Linux and revisited this review (2009).


When I test new Linux distributions I always find that Debian is so much better in every way and this time there is (almost) no exception.

I had read a lot of reviews of Arch Linux and I was looking forward to finally trying a Linux distribution that was independent.

Besides from being independent Arch Linux was also following a principle very well known in the world of the BSD's especially in OpenBSD, the principle is KISS, "Keep It Simple, Stupid".

From Wikipedia:

The KISS principle (backronymed to "Keep It Simple, Stupid") states that design simplicity should be a key goal and unnecessary complexity avoided. It serves as a useful principle in a wide array of disciplines, such as software development, animation, journalism, photography, engineering, and strategic planning. Common variants of the acronym include: "Keep It Sweet and Simple", and "Keep It Short and Simple".

This is a principle I really like and the principle makes OpenBSD an absolute joy to work with. I have found no other BSD or Linux distribution keeping up to that principle on the same level as OpenBSD.

Coming from both Debian and BSD I am used to some of the best package management tools ever build. On Debian there is apt-get. And on OpenBSD and FreeBSD there is pkg_add and pkg which are also very good tools. All these tools manage dependencies automatically.

Arch Linux has a similar tool called pacman.

Besides from package management tools all BSD's has the ports system that allows you to build software from source in a very easy three step process, always using the very latest bleeding edge software. I was also happy when I read that Arch Linux had something similar called ABS.

Installing a package on Debian is as easy as:

# apt-get install gimp

Doing the same on FreeBSD:

# pkg install gimp

And on Arch Linux:

# pacman -S gimp

Coming from the above systems I am used to setting up my systems without any kind of GUI tools and I am quite happy with that. I find that both Debian, FreeBSD and OpenBSD are very easy to install and I am very used to text based installations. Since Arch Linux only has a text based installation I felt right at home.

My impressions

If a person is coming from a distribution like Fedora, Mandriva or Gentoo, I can understand why that person would be ecstatic about the simplicity of Arch Linux and it is my guess that's the reason why so many reviews are only speaking good of Arch Linux.

Update: The problems described in this section is prior to the release of Arch Linux 2009.08. In the 2009.08 release I had no problems at all except some minor problems getting sound working with a Sound Blaster Audigy 2 card and a minor problem getting GRUB to understand how to boot the drive using a non-default partition scheme.

I downloaded the FTP installer CD, because I prefer to install via FTP, but that just didn't work. No matter what I did, I couldn't get the mirrors for pacman set up. I double checked that my network card was configured correctly, which it was, and I could ping out of the box. When I selected the mirrors, and then wanted to select which packages to install, I never got an actual package list. What I got was an array of errors that didn't make any sense.

Seeing something like that in the installer rather than some kind of usable error message always tells me that I am about to engage myself into something horribly time consuming.

Now, I downloaded the core CD instead and installed that version without problems.

When I finished I wanted to install my favorite desktop system. I also installed the Nvidia driver and Xorg.

I set up Xorg and wanted to start X, but the system couldn't start.

After messing around a little with the Nvidia kernel module I got this error message from Xorg:

error while loading shared libraries:
kdeinit4: symbol lookup error: /usr/lib/ undefined symbol: gzopen64

After some searching on the Internet and a visit to the Arch Linux IRC channel I understood that the pacman mirrors wasn't in sync. Some mirrors was updated much more frequent than others. I had to change my mirror and update libxml2, next I had to install zlib.

Errors with repos not being in sync is just awful. I haven't looked deeper into the issue but a package management tools must make sure that all dependencies are met correctly, which it didn't in this case.

After fixing the above error I had to re-update my entire base system.

When it was finished I could finally start up X.

Then a lot of small errors started to emerge.

I noticed that each time my test machine had rebooted the clock needed to be reset. This wasn't due to a problem with the battery, but somehow something kept setting my time forward about five hours.

At this time I didn't want to investigate the cause of the clock problem because other problems was adding to my frustration. The clock problem might be a problem with my desktop and not a problem with Arch Linux itself. Using bleeding edge software often result in many small bugs merging to the surface.

In several of the reviews of Arch Linux on the Internet people are surprised at how simple configuration is, because even if it is purely text based, you set almost everything up in /etc/rc.conf.

This way of handling configuration is copied from the world of BSD. FreeBSD has the exact same rc.conf file for setup, and OpenBSD is using a local version for users to edit. OpenBSD has rc.conf and rc.conf.local, so in case the rc.conf file gets updated nothing of your setup is lost.

From the Arch Linux wiki page:

Arch's simple init system (thanks SystemD!) is heavily inspired by the *BSD way of incorporating calls from a single file, (etc/rc.conf), rather than a convoluted directory structure containing symlinks for each runlevel. System configuration is achieved through editing simple text files.

Update: Arch Linux has since unfortunatly changed its init system to SystemD

The BSD way of doing things are something all Linux distributions could learn a lot from and on this point Arch Linux has hit the nail right on the head. This is one of the things that make Arch Linux great.

The package management tool pacman is great. Compared to both apt-get from Debian and pkg from FreeBSD I find that the tools resemble each other a lot, but especially apt-get and pacman resemble each other very much and I suspect that pacman was heavly inspired by apt-get.

If you want bleeding edge binary packages you could choose Arch Linux but then again you might as well choose Debian Testing or Debian Unstable.

Arch Linux has of the moment of writing a little over 4000 packages to offer whereas FreeBSD has more that 19000 packages and the Debian based distributions has more than 22000 packages.

From all the systems I have ever tested Arch Linux resembles FreeBSD most and it doesn't really resemble any other Linux distribution. FreeBSD is a far more stable and well documented system than Arch Linux, but Arch Linux is also fairly new. Arch Linux is a very impressive system. Coming from the world of BSD I often miss the extremely well designed systems when I use Linux. And even though I find Debian great, both FreeBSD and OpenBSD still offers a much cleaner design. Arch Linux has that as well and it is my guess that Arch Linux will become a very popular distribution once more packages are ported and once the system becomes more known to people.

One thing that disappointed me was that a lot of well known packages hasn't been ported yet, but again this is a matter of work-force.

From the Arch FAQ

Update: Arch Linux has since unfortunatly changed its init system to SystemD

Question: What exactly is this 'BSD-style' init framework I keep hearing about?

Answer: Part of BSD's 30+ year heritage is the simple init framework that it has incorporated and which has remained largely unchanged. (The SysV init was implemented in GNU/Linux systems much later.) The main difference is that Arch's BSD-style init uses a single file (/etc/rc.conf) to point to scripts within a single directory (etc/rc.d/) for all system services, regardless of runlevel. A sysV init on the other hand would use a directory for each runlevel:/etc/rc.0,1,2,3,4,5,6, with a convoluted array of symlinks within the directory; one for each service, and each symlink pointing to a corresponding script in the /etc/init.d/ directory. Needless to say, the SysV method is much more complex; it could easily contain dozens of symlinks in each /etc/rc. directory.


Arch Linux is kinda like Linux done the BSD way.

Arch Linux is clean like FreeBSD and you have to set things up yourself. This gives you a lot of power and knowledge about how the GNU/Linux system is working.

In most other distributions things are setup on advance and while this makes those distributions very easy to use, you also lack basic knowledge of how the system actually works.

For example setting up an OpenSSH server on most distributions are as easy as installing the package. The install script will automatically create the necessary keys and it will work more or less out of the box. On Arch Linux on the other hand you have to set things up the way the author of the package intended - no helper scripts exists. You generate the keys yourself and you have to allow people access to your system by editing the hosts.allow file.

Contrary to other Linux distributions Arch Linux doesn't change the packages when you install them.

Even though helper scripts can be great, the way Arch Linux does things are great from another perspective: In Arch Linux you can expect nothing more than what is promised from the original package, nothing is changed, and you can thus expect that things work the way they are supposed too.

On Debian there is "The Debian way" and on Fedora there is "The Fedora way", specific ways to do things on those specific systems. If you use the same distribution for a long time you get used to that specific way, but when you work with another system you have to re-learn how things are done on that particular distribution. On Arch Linux there is no such thing, there is only "the original way" that a package is supposed to work, the way the author has designed the package. You can thus go directly to the website of a particular product and then trust the installation information - nothing has been changed on Arch Linux.

Arch Linux feels a bit like running FreeBSD with a Linux kernel.

Because Arch Linux is using the latest bleeding edge software there are some open bugs. I installed KDE version 4.1 with Arch at the moment of writing. KDE 4.1 is filled with bugs and besides for the problems with the clock, which I later got fixed, I kept missing my "K" in the panel. Each time I booted up the computer and started KDE, the "K" was gone.

A lot of other things didn't work right in KDE and I also experienced KDE crashing.

These problems has nothing to do with Arch Linux, but this is where I really like the way Debian do things regarding packages.

If you are running Debian stable you know that you have got an extremely stable system where all known bugs has been fixed and you wont experience any problems (except for problems that perhaps haven't been discovered). Arch Linux packages are predominantly unpatched, whereas Debian packages are patches.

Arch Linux has no stable snapshots it's a rolling release. The rolling release model allows one-time installation and continuous seamless upgrades, without ever having to reinstall or perform elaborate system upgrades from one version to the next.

A rolling release system has many benefits, but it also has many problems. If you need to run a stable workstation, where you need your software to work, all the time and every time, then a rolling release can cause you a lot of problems and wasted time, because every once in a while an update will break your system.

This is why Debian has a stable branch. Many people complain about Debian's stable branch containing packages that are too old, but you really have to weigh the pro and cons.

A stable branch in the world of Debian (and many other systems) roughly means that at some point in time you freeze everything up and decides what packages goes into the stable branch. Once that is decided, often the decision is based upon tests of stability, you make sure that every dependency is met correctly and without errors, and you make sure that every security problem is fixed in each package, then you provide some patches to make everything play nicely together, and you then release the system. Afterwards you only provide security upgrades and really important upgrades that wont brake anything on any of the supported architectures (please do consider that Debian supports a high number of architectures).

Arch Linux is a really great system, but IMHO it needs a stable branch. The main benefit of Arch Linux is the BSD way of doing things, and especially the BSD-style init framework is fantastic - other Linux distributions should really consider adopting this.


A comparison of Arch Linux against other BSD's and GNU/Linux's: [Arch compared to other distributions]

More information on Arch Linux: The Arch Way