Much to my surprise, my essay of a few months ago on Why Arch Linux Rocks is quickly becoming one of my most popular posts. Who would have thunk? In any case, while I’ve written a few additional bits here and there about using Arch, I thought it would be good to write some more concrete and practical reflections on what I’ve learned from Arch and hopefully someone out there will find this useful.

The thing about arch, is that it’s by nature a very minimal operating system, and it doesn’t shy away from the command line. There’s this peculiar logic amongst GNU/Linux Distribution Developers that says: we want people to use our operating system and to use Free Software, and since most people are scared off by command line interfaces and editing config files, lets try and obscure the command lines and the config files as much as possible. That’s a good idea.

Right. Not really.

And for some distributions, this really works. Arch says, rather, that while command line interfaces and config files can be confusing they’re not “bad,” and it’s possible to teach people how to interact with the command line and edit their config files. Furthermore, while command lines and config files might be different and unfamiliar to users who are used to checkboxes and menus, they are extraordinarily simple.

Back to the minimal part.

When you install Arch, you get a prompt, the basic GNU tool chain (install base-devel during the install process, it’s worth it,) the Kernel (of course), the GRUB boot loader, and that’s about it. Everything else you have to install yourself. While you might thing “this is a huge bother” the first time you install Arch, the when you get to the end of the process you have a system that does exactly what you want it to and nothing more. Having a computer system so tailored to your needs and workflows is actually, sort of a unique and wonderful experience. Rarely, I think, in this day and age do we get work with a computer in this way.

Nevertheless, having a system that is this minimalist means that setup can be a bit… intense. Once things are installed the right way it works great, but I found that the first few times I ran an Arch install, it was like I spent the next two weeks installing little things over and over because I couldn’t keep track of what I needed. And then I installed a second system, and it was the same thing over again. The third time I did it, I’d wised up and managed to have a better time with it. A few weeks ago I created and redeployed a virtual machine (in virtual box) that I use as my primary work computer (long story), and it was painless.

What remains of this post are a collection of lessons that I’ve learned and some suggestions I have for having the best arch experience possible.

  1. Save your /home directory and copy it to the new machine. I used the following command over the local network from the home server: :

    rsync -azrv /home/tychoish tychoish@192.168.256.1:/home

    Changing the paths, usernames, and IP address to their relevant and valid values. This way all your configuration files and data end up on the new machine, with permissions preserved. This typically takes the longest time of any setup operation.

  2. Run system updates as soon as possible. Arch is a rolling release distribution. The longest you’ll typically go between updates is the time between when the installation media was created and when you install your machine. The longer the divide between current status and when you run an update the greater the chance of breakage happening.

  3. Use ABS, the “Arch Build System,” to compile any software that isn’t in the main arch repositories. Save the PKGBUILD scripts (if not the packages you’ve made with them,) in your `~/abs/`` directory. This makes installing all of the weird and tedious software much easier.

  4. Avoid getting a machine with weird or uncommon wireless or video drivers. At this point, I’m choosy enough about my hardware that I won’t get a computer (much less install Linux on it,) if it’s not “Intel everything:” wireless card, video card, chipset, etc. Sure a fancy NVidia card might be more sexy, and there are a lot of good reasons to use AMD and ATI silicone. But, one can be very sure that Intel hardware is going to work with Linux; and with other gear, it’s much more hit and miss. Or it can be. And my time and serenity is not without value.

  5. Maintain a list of what packages you want to install on your system:

    • X11 Dependencies

      Lets not talk about how long it’s taken for me to remember to install the X11 keyboard and mouse drivers:

      xf86-input-keyboard xf86-input-mouse

    • Additional package management tools

      The abs tool provides a BSD-ports like interface for building packages, while the ‘yaourttool makes it easy to make and build packages from the [Arch User Repository][aur] (AUR.) Typically I use [yaourt][] to download a package and then build it in theabsdirectory. Make sure you've installedbase-devel` as well, because you’ll want to eventually.

  • Music Applications

    I use the music player daemon and a number of additional applications to play music. And I install these packages as a matter of course.

    mpd mpc gmpc alsa-utils jack-audio-connection-kit

  • The tychoish Tool Chain

    Your specific list of “tools that you must have in order to function properly,” probably varies a bit. Here’s mine (some packages are from AUR):

    git emacs emacs-org-mode emacs-w3m-cvs rxvt-unicode
screen wcalc sudo htop urxvtcd zsh swiftfox-i686

    To explain quickly those packages which aren’t obvious from their title: wcalc is a command line calculator tool; swiftfox-i686 is an optimized build of Firefox, except it runs more smoothly in my experience and is compatible with the FF plugins that I depend upon. urxvtcd is a shell wrapper for urxvt that opens a client of the urxvt-daemon (urxvtc) if there’s a daemon already running, and starts a daemon and opens a window if there isn’t. htop is a system process monitor.

  • Email Tool Chain

    I use the following packages to manage my email:

    procmail msmtp fetchmail gnugpg

    From AUR I also use:

    lbdb mutt-sidebar

    lbdb is an address book database tool, and I use my build to get the best mail-reading client in the world.

  • Window Management

    Arch is great for having pretty good support and inclusion of up-to-date packages for esoteric window managers. The sequence for installing StumpWM is a bit non intuitive. First, install the following packages from the normal repositories:

    sbcl nitrogen gtk-chtheme

    The last two are tools for changing the look and feel the desktop and GTK applications (respectively). Now from AUR, install (in the following sequence):

    clx cl-ppre stumpwm-git

    Put the following code in your ~/.sbcl file:

    (require 'asdf)
(pushnew #p"/usr/share/common-lisp/systems/" asdf:*central-registry* :test #'equal)
(asdf:operate 'asdf:load-op 'cl-ppcre)
(push #p"/usr/share/common-lisp/systems/" asdf:*central-registry*)
(asdf:operate 'asdf:load-op 'cl-ppcre)

    And you should be good. Configure your .xinitrc to your liking, and make sure your have a .stumpwmrc.

  • Networking Tools

    To manage my own connections and connect to the OpenVPN I use netcfg and OpenVPN. This requires the following packages:

    netcfg netcfg-auto zsh-netcfg netcfg-openvpn openvpn

    There are also a suite of network diagnostic tools that I always install, but seem to forget for various parts of a week.

    mtr whois dnsutils

    Also, I’m always befuddled by this for a few moments, but ssh isn’t installed by default. I, as a result install the following tools:

    openssh sshfs

    And add the following line to /etc/hosts.allow to permit inbound SSH connections.

    sshd: ALL

  • Spelling Correction

    This always frustrates me, though I understand the logic. Install the following three packages to get spelling support thought the system:

    aspell ispell aspell-en

    If you need spelling correction for a non-English language, replace aspel-en with that language, or add that language to the end of this list.