Some notes on Arch Linux
Published on 2008-11-04. Modified on 2009-08-17.
I have been using GNU/Linux, FreeBSD and OpenBSD exclusively since about 1999 and I spend time with Linux and BSD every single day both at home and at work. From time to time I still like to test some of the other Linux distributions to see whats new in the world of Linux. This time I decided to test Arch Linux. Arch Linux is really great, but it is not for people wanting a stable desktop or server system.
I had read a lot of reviews on Arch Linux and I was looking forward to finally trying a new and independent Linux distribution. Besides from being independent Arch Linux is 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".
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 which are also very good tools. All these tools manage dependencies automatically.
Arch Linux has a similar tool called
Besides from package management all BSD's has the ports collection 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.
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: libkrb5.so.22 kdeinit4: symbol lookup error: /usr/lib/libxml2.so.2: 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
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
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.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 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.
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
pacman resemble each other very much and I suspect that pacman was heavly inspired by
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
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 control and knowledge about how the GNU/Linux system is working which is really great.
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 upstream package intended, no helper scripts exists, which is awesome. Contrary to other Linux distributions Arch Linux doesn't change the packages when you install them.
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. This is something that makes Arch Linux extremely attractive to a system administrator.
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 Debian 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. Not only that, the documentation supplied from the upstream developers doesn't match the setup on Debian. This can often cause problems, especially during debugging if you need help from upstream as they do not recognize the setup you're using. The upstream documentation specifies a specific way to setup things up, but it has been changed in Debian.
On Arch Linux there is no such meddling going on, 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 might be some open bugs in the software you install. The Arch Linux developers provides security and bug fixes as soon as they are released from upstream.
I installed KDE version 4.1 with Arch at the moment of writing. KDE 4.1 is filled with bugs and besides 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 the Debian way can come in handy.
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) because nothing gets updated except for security and possible bug fixes. Arch Linux packages are predominantly unpatched, whereas Debian packages continuously gets patches backported.
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 potential problems. If you need to run a stable server system, 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 with new features 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 and understand where each system is best suited.
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 decide 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 release the system. Afterwards you only provide security upgrades and really important bug fixes that wont brake anything on any of the supported architectures (consider that Debian supports a very high number of architectures).
Arch Linux is an amazing rolling release distribution. 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.