Arch Linux: For Good or For Awesome?

Back to the Future with Arch Linux

Back in the day when I was an actual engineer getting my Master's degree from Carnegie Mellon, I had some decent development skills. My thesis was based around a 3Kloc project that got into the internals of the Linux Kernel involving a mandatory access control scheme using the Linux Security Modules infrastructure. At the time (in 2004), the 2.6 kernel was just being released and I was on the bleeding edge of development using the (at the time) new & trendy Gentoo distro. As a source based distro, Gentoo was excellent for my development purposes since I never had to worry about installing "dev" packages that were always missing with other distros, and it was generally easier for me to integrate my own source code since everything had to be compiled anyway. Having a full-blown development environment and all the dependencies was a big help when your day job involves poking with the kernel ad nauseum.

Well.. all good things come to an end. I got out of grad school, still use Linux exclusively, but Gentoo got to be a bit tedious. I didn't have the time to put into maintaining the system, and Gentoo went from being an excellent and dynamic distro to one with community infighting and all sorts of problems with the portage system that broke the distro. I started Law School three years ago, and that meant my free time to mess with a misbehaving Linux machine dropped greatly. So... I went over to the "dark side" and started using Kubuntu, which is the Ubuntu flavor supporting my KDE desktop.

Kubuntu worked well enough, and I've used it throughout Law School with mostly positive results. The Ubuntu guys do make it pretty stupidly simple to get a working machine, and when you want need to concentrate on reading cases, a system that is easy to maintain is ideal. However, as many others have pointed out, despite efforts to the contrary, Ubuntu tends to treat KDE as a second-class citizen compared to GNOME.

On to Arch

I own two PCs, a Lenovo notebook and a custom-built desktop PC. The notebook is mostly for school, and I don't want to make any changes to it until after I graduate in May. The desktop on the other hand is more open to experimentation. I blew away my current Beta of Jaunty Jackalope and replaced it with the current 64 bit Arch release (2009.02). Here are a few thoughts about my experiences....

Installation

Arch's installation is not cutesy and graphical like Ubuntu, but it is straightforward. I particularly enjoyed the fact that the Arch site has images for flash media like SD-cards or USB sticks so on modern systems that can boot from these drives an install does not require a burned CD. Arch also uses a "rolling release" system that updates packages incrementally. Thus, even though I downloaded the 2009.02 release from the Arch download page that download is just a (minimal) snapshot of the basic kernel, networking, and command line utilities that are needed in order to pull & install the rest of the system. Individual packages get updated when they are ready, so there is not a huge point where the entire system is radically upgraded all at once.

My recommendation: If doing things like running cfdisk and editing several files in the /etc directory are old hat to you, or if you want to learn and can follow directions, then you too can install Arch. I REALLY like the /etc/rc.conf file which consolidates a bunch of different system settings into one (well documented) file.

The default system

In 2.5 words: Lean & Mean. After the initial installer runs, you get a system that will boot up to a command prompt with networking support... and that is about it. If you are afraid of the command line, Arch is probably not for you. However, if you are either experienced with the command line, or want to learn how to setup a custom distro, Arch's configuration is not particularly complicated, and there is excellent documentation to help you along.

Things that Rock!

Customization

I REALLY appreciate the customizability that Arch gives you that was missing with Ubuntu. I will use the Networkmanager package as an example of how much better Arch makes things for those of us who like to be able to get the details right. Networkmanager is the popular package for managing network connections on a Linux system. Originally developed by RedHat and used in Fedora, it has spread to become the default way that most distros configure networking, especially on notebooks with wireless connections. I use Networkmanager on my laptop and I'd probably never be able to get onto a wireless network without it, and I do remember the bad-old days of trying to get the Orinoco 802.11b drivers working. Linux wireless networking has come a very long way in a few years and Networkmanager is great. BUT... I really have no need of it on my desktop which has a normal gigabit ethernet connection that just uses DHCP to access my LAN.

The problem with Kubuntu was that it was very difficult to either remove, or just customize Networkmanager: You get the kitchen-sink, or a bunch of broken dependencies. One thing that drove me nuts was that the wpa_supplicant process was running on my desktop machine... the one that does not even have a wireless card installed. I actually manually deleted the wpa_supplicant binary, and then tweaked my logging options so that my log files were not being filled with "error could not run wpa_supplicant" messages from Networkmanager, but this was not an optimal solution.

The Arch solution? Well Arch certainly allows you to install Networkmanager if necessary, but the default is a much simpler setup that allows you to configure an ethernet interface and set it up statically or with dhcp.... done & done! Arch gives me extra flexibility that Ubuntu hides in the name of ease of use.

One bonus to all of the customization I've mentioned is that the boot time on my desktop is... fast. After the BIOS finally clears out of the way, it about 14 seconds to having a KDM prompt running for login. The boot time is now spending more time running the BIOS checks than actually loading the OS... not too bad.

Pacman System for Package Management

While it isn't perfect (see below) the Pacman system is the fastest & leanest package management system I've found. Pacman does the standard dependency tracking and even has some features I haven't seen in other package systems, even apt-get. For example, installing a larger "meta package" like pacman -S kde where "kde" is just an alias for many sub-packages is a very common thing across many Linux distros and package management systems. Where Pacman improves upon the others is that it will actually allow you to pick & choose which elements of the meta-build you actually want to install, and then only install those elements (along with necessary dependencies). For example, when I installed KDE after I got to my initial command line, I was able to avoid installing certain parts of KDE that I don't use, like kdeedu, while still getting a fully-functional KDE desktop.

Pacman gets even better with the AUR system that allows you to build packages from source. As somebody who has installed compiled packages on Ubuntu, I am a real fan of this process. The reason is that you still have the flexibility of compiling software from source, but the end result is a package that pacman will install, check dependencies for, and also allow you to remove easily. This process is usually pretty easy, and it has already allowed me to (for example) get the newest versions of WINE running on my x86-64 box even though Arch does not officially package wine for 64 bit machines.

Pacman is also comparable to apt-get and other package management systems in that you can add extra package repositories to your system. For example, there are separate repositories for the specialized Kdemod4 packages that tweak KDE4. The repositories can be added to /etc/pacman.conf to use the new repositories:

[kdemod-core]
Server = http://chakra-project.org/repo/core/x86_64

[kdemod-extragear]
Server = http://chakra-project.org/repo/extragear/x86_64

[kdemod-playground]
Server = http://chakra-project.org/repo/playground/x86_64

Things that Lack Rock:

You can have my .vimrc when you pry it from my cold, dead hands!

So nothing is perfect, and Arch is no exception. While I think I like the ability to tweak items, this comes at the expense of having some packages not simply "just work" as you might expect them to. The worst offender here was the vi package. Yes kids, I fight for truth, justice, and lean & mean text editors, so I'm a vi (specifically vim) guy. Like many other distros, the arch-linux default install includes what I call a "quasi-vim" editor that looks like vim, but doesn't have all the features. The real vim needs to be installed later, which is not my major problem. Instead, the major problem was that my carefully crafted .vimrc files were not respected when I ran vi. Instead, the system default files in /etc/virc and /etc/vimrc were used, and they did not allow my personal ~/.vimrc settings to take precedence (as had been done on earlier distros from Ubuntu and Gentoo). This led to bad highlighting, no autowrap, and (even worse) the middle mouse button could no longer be used to paste text into a vim session in insert mode!!! OK, that rant may sound a little over the top to outsiders, but you vim users out there know what I'm talkin' bout: you don't mess with a man's vimrc! Fortunately I was able to fix the problem by completely removing the system files and then all of the sudden my normal .vimrc was respected.... I'm glad I figured out a solution or Arch might have had a short shelf-life.

SSH-Agent: Double Oh Configuration

Another issue I had was with the ssh-agent program, which is a nifty service that allows you to cache the keys used for authenticating with other systems if you have RSA keys configured. Ubuntu has a nifty system that starts one (and only one) ssh-agent instance running when you login, and from there is was easy for me to add startup scripts that added in my ssh keys so I could login to my backup system (provided by rsync.net) without needing passwords.

Arch does not have the same feature, but fortunately I was able to add a small shellscript to ~/.kde/env/ that runs ssh-agent in a way where all programs in my KDE startup will be able to use it. See here for more details. It would be nice if more stuff worked "out of the box", but Arch's support forums helped me fix the problem without too much trouble.

I'm liking Arch Right Now

I've been running Arch for just under a month, and so far I think I'm sold. The distro itself is well put together and I've enjoyed having a system that conforms to what I want. I really appreciate the Arch user community which is friendly and also shares knowledge well, particularly through the Arch wiki.

Over the years I've used Mandrake, Suse, Debian, Gentoo, Ubuntu/Kubuntu, and now Arch. I'm getting good at figuring out what I want and I'm still amazed at how much better Linux is today than it was when I started on it back in 2000. There's always more to learn, which is where all the fun is. For right now Arch is where I'm most comfortable, so Arch is for AWESOME.