With the recent “controversies” in Arch Linux – such as the move to /lib being a symlink, parts of the rc.conf file moving into separate files and the installation becoming command line based – I started thinking about what really defined Arch Linux in the early days and what make it what it is currently. To assess this, I read through all the news and interviews about Arch up until the 0.8 release. That covers about the first five years of the Arch Linux existence. Here is what I took from those articles, in no particular order:

Pacman

This is probably the most unique thing about Arch Linux and it is the reason I started using Arch in the first place. I may be ever so slightly biased here… but I still find this one of the best package managers around. This is not necessarily for the pacman manager itself, but the package building system is so incredibly simple. Let me be clear in pointing out that there are a lot of areas that I think could be substantially improved, but the major things I want implemented are gradually being crossed off my TODO list.

The Arch Build System (ABS)

Being able to readily customize packages is always touted as on of Arch’s best features in any review I see. I never use it… Well, not entirely true – I have 1 customized package out of the 626 currently on my system. I wonder if it is the packaging system rather than ABS that is being highlighted by not well informed reviewers there, because maintaining a custom package is really not a pleasant task in Arch.

Rolling release

Having packages available in our repos very quickly after the upstream release is a major attraction to Arch Linux. While Arch is far from the only rolling release distribution, the updates tend to be damn fast!

Optimized for i686

Ten years ago, most distributions were compiled for i486. So back then, compiling for i686 was a big feature. Now 64-bit has overtaken the world and and most 32-bit distribution offerings are built for i686, so this is not an advantage anymore. We should probably drop i686 and crank up the optimization of the x86_64 port!

Simple filesystem layout

I found this an interesting feature to be mentioned by Judd… Especially given all sorts of packages in Arch used to be shoved in /opt . But he was referring to the lack of things like /usr/doc . Years ago, Arch used to ship packages without documentation – including info pages. Now we do ship info pages (they are treated identically to man pages by the packaging system) and documentation is also shipped (in /usr/share/doc , not /usr/doc ).

Simple configuration

The rc.conf file was highlighted by many reviews as being the one stop for all your configuration. In fact, one review suggested that it should also include “wi-fi profiles, printer, scanners, bluetooth etc” given there were not GUI tools to do this. The lack of distro specific tools for configuration was also highlighted, although that is a bit weird given our rc.conf is ditro specific.

Support

The help on the IRC channel, and to a lesser extent the forums, was often mentioned. Also the excellent documentation in the wiki was beginning to make its appearance.

Rapid adoption of new features

Having the latest an greatest software was often considered a highlight. For the initial five years of Arch Linux, that included things like the Ext3 and Reiser filesystems, udev support and Linux 2.6.

One thing I did not see mentioned anywhere was Arch’s use of vanilla packages. The minimal patching is one of my favorite features of Arch Linux, but I guess that is not something that would be readily seen by a reviewer.

So… lets take a look at the current controversies in Arch Linux land with respect to the foundations of Arch Linux.

Controversy #1 – Symlinking /lib to /usr/lib

People were not particularly happy about this. And they are really going to hate when /bin , /sbin and /usr/sbin all point to /usr/bin … Note there were quite a few other things that have become symlinks recently too (think about what points at the /run directory). The difficulties of the /lib change were exasperated by the rolling release model and limitations in pacman in performing the upgrade. But I think this fits in directly with the “simple filesystem layout” above. As discussed above, we have slowly moved away from this principle to provide packages closer to what their developers intended (by not removing documentation), so this is really a return to original Arch principles!

Controversy #2 – The demise of /etc/rc.conf

While the single rc.conf is highlighted as major feature of Arch Linux, reading the reviews makes you notice that configuration of an Arch install was never down to a single file. Other files mentioned included…

/etc/conf.d/wireless

/etc/fstab

/etc/group

/etc/grub.conf

/etc/hosts

/etc/inittab

/etc/lilo.conf

/etc/locale.gen

/etc/mkinitrd.conf

/etc/modules.conf

/etc/modprobe.conf

/etc/rc.local

/etc/resolv.conf

/etc/pacman.conf

/etc/X11/XF86config

~/.xinitrc

And that is just the configuration files mentioned in what were quite superficial reviews of Arch Linux. So a single configuration file was really just a myth.

But lets take a step back here… How about some quotes from Judd, the founder of Arch Linux:

“In Arch “simple” is different what other distros are considering. The learning is more important than getting something easily done.” “Relying on GUIs to build/use your system is just going to hurt a user in the end. At some point in time a user will need to know all that some GUIs hide.”

What does a single configuration file get us? Is it “simple” in terms of the definition above? Not really… It requires that we write our own tools to deal with it and convert these into the appropriate commands during boot-up. For example, instead of configuring modules in /etc/rc.conf , we should directly use the configuration files that the module loading software reads. How is putting the settings in rc.conf and having software interpret them any different than using a GUI to do the same thing? It does not give us any actual understanding of the system. Also using the same configuration files as other distributions do (and this is becoming more standardized) means the learning done in Arch Linux will apply to many other distributions.

Controversy #3 – The move towards systemd

I think it is plainly obvious that systemd will become the primary system initialization method for Arch Linux in the not to distant future (not that this has been formally decided, so take that statement as unofficial…). Having not used systemd at all, I really can not comment directly on if it is any good or not. But what do we lose by moving to systemd in Arch? I have seen the following criticisms:

Users are being forced to use systemd. This argument really does not hold water. How many initialization systems are currently in use on Arch systems? Just the one currently “forced” on you…

The module control is more complex. Right… because “ rc.d start foo ” is much simplier than “ systemctl start foo “. I think the real criticism people are trying to express is that the rc.d way of doing things is more traditional Arch. But have you looked at the quality of scripts in /etc/rc.d ? It is generally poor. Moving to systemd unit files instead will be an advantage as they are much more simple to write and can be pushed to the upstream packages.

The initialization process will no longer be controlled by a bash script so it will be harder to skip a broken section. This is probably somewhat valid. I do not know enough about systemd to really comment beyond a couple of points. Firstly, systemd is (or will be) used by many distributions so will be less likely to break than our current initscripts. Also, systemd is quite modular, so it appears that stopping particular modules should be achievable.

It is written by Lennart Poettering. I have no idea how this ever became a “genuine” argument against systemd, but almost any discussion involving systemd ends up being about Lennart also writing pulseaudio. Maybe we need an updated version of Godwin’s Law for this situation… Any time an argument reaches this point, I know all things technical are out the door and I stop following.

When I was reading the old reviews, every time I saw mention of Arch Linux using the latest innovations in the Linux world, I started wondering why we are not using systemd already? Here I have only (partially) refuted the downsides of systemd, not pointed out what I can see are some quite substantial benefits. I personally think the historic rapid adoption of new features should continue in Arch Linux.

This has been a much longer post than I initially intended, but I hope this makes people think about what makes Arch Linux what it is. Or at least reconsider whether changes being made are really going against historical Arch principles. It has made me consider why I have not tried systemd yet, so I will do so in the next couple of weeks. Being on the bleeding edge is not much fun without the occasional cut…