About this time last year, I got a bit of an early “Christmas Present”1: A shiny new work laptop. My work laptop is kind of my “daily driver” machine; I use it to study, code, communicate, and keep up with the latest tech trends, which amounts to the majority of what I use a computer for. I’d had my previous laptop for 5 years or so, and to say it was “lived in” was an understatement.
I’ve been using GNU/Linux in one form or another since around 2004/2005, and for the last several years I’ve been installing a fairly heavily-modified Kubuntu for my main machines. I’d replaced KDE with Awesome WM and rigged up a custom desktop experience; my software was a hodge-podge of repo installs, PPA installs, compiled-from-source software, converted RPMs, a few heaven-knows-where-I-found-them proprietary .debs, etc. etc. The thought of recreating my setup from scratch was just not fun.
I’d been getting the feeling that Ubuntu and I were no longer operating on the same wavelength; I was spending a lot of effort to turn Kubuntu into a bleeding-edge, custom-built, minimalist distro, and using half a dozen different methods to do it. By the time the new laptop arrived I’d decided it was time to give Arch Linux a try.
Why Arch?
Arch Linux is not a newbie-friendly distro. It’s not the one you set up for your computer-challenged relatives or the diehard Windows fan in your life. It’s not corporate-enterprise-approved or retail-ready, and it’s not going to win John C. Dvorak over to Linux. So why would I install it?
- I want to build up my system from a minimal core install – the more minimal, the better.
- I tend to want the latest released versions of software I use, and I use some relatively obscure software. I want a distro that works with me to do this cleanly, and not feel like I’m working outside or against its basic packaging model to do so,
- I guess I’m what you might call a “Power User™”; I know what I want, I know how to get it, and the less the system gets in my way the better. It’s great that there are Linux distros for the “average user”, but I’m not really one of them.
- Finally, I’m kind of just done with having to do a massive system-wide power-upgrade every six months just to stay current. It was fun in the beginning, but now I just want to be current in real-time.
Everything I’d read, heard, and seen of Arch seemed to fit with my wants:
- Arch is built up from a minimal base2. There’s no default setup and no specially-blessed configuration.
- Arch has the AUR (Arch User Repository), where I can get bleeding-edge versions of just about anything and easily build them for my system. The AUR uses the same build system as regular binary packages from the repo, so I’m not using some outside method to create and manage these AUR packages.
- Arch is built for the power user: it gives you tools to easily manage the system, but doesn’t try to restrict you from doing what you want to do.
- Arch is a rolling release, constantly updated with no “big freeze” or “big release”. Packages are just updated in real time after a short testing period.
I’d played around with Arch in the past, and had had some misgivings about the stability of the package management, but I decided the benefits were worth the risk.
The initial setup
As I said, this wasn’t my first foray with Arch; I’d messed with it on spare systems a few times in the past, but never really stuck with it.
When I’d tried it before, the installer was a sort of scripty Slackwarish thing that walked you through the install process with a lot of questions, popping up a config file here and there when it was time to edit something. By the end of 2013, the install process was even more minimal and hands-on. Nowadays Arch is installed using an offline bootstrapping method not unlike the debbootstrap method I’ve described on this blog. Essentially, you:
- boot up to the Arch install media
- create a partition with
cfdisk - run the
pacstrapcommand to download and setup the basic filesystem structure - run a bunch of scripts to generate the necessary config files
- edit a few choice configs by hand
- install a bootloader
- finally, reboot into your minimal CLI system.
At that point, the package installing begins. It’s amazing how many little things you take for granted when you don’t set up a system from scratch: various CLI programs, printing & scanning support, various runtimes and libraries, etc. It took me a day or so to get the basics nailed down, and then for the next couple weeks there were moments of “Oh, I haven’t installed that yet?”.
The setup was probably made far more complicated by the fact that my Awesome 3.4 config file from Ubuntu was utterly broken in Arch’s Awesome 3.5, and by the fact that I’d depended on a lot of Emacs packages from the Ubuntu repos rather than using package.el3. Once this stuff was sorted it was pretty much cake.
How she schoons
I had years of knowledge from the Debian world that I had to unlearn for Arch, particularly in the area of package management. Getting used to pacman, Arch’s package manager, didn’t take too long (though I miss some features from aptitude, like its advanced search & pattern-matching), and over time I’ve learned where to find applications I need (they aren’t packaged quite the same in Arch).
The real adjustment came from being a generation or three ahead of Debian (or even Ubuntu) with all my software. Things I’d relied on regularly (like FreeNX or ifconfig) turned out to be deprecated, and of course there was systemd to deal with. It was a good learning experience, though, and gently forced me to update some of my regular software to modern, supported (and ultimately less-broken) options.
Overall I’m pretty pleased with Arch’s performance, and I absolutely love the AUR. No more hunting down packages in some 3rd-party repo or PPA. If I could wish for anything, it might be a “software center” type of application (with AUR support) for browsing the available packages. I do prefer a CLI tool for routine package management tasks, but it would be nice to have something I could browse to discover new stuff. I’ve seen a few projects trying to do this, but nothing that really hit the mark.
Lessons learned
I have yet to experience a true catastrophe with my Arch install, but I’ve certainly hit rough patches here and there. In the process, I learned a few valuable lessons:
Be careful with the AUR
Coming from a distro like Ubuntu or Debian, you’re tempted to think of the AUR as a big “community repo” that you can just start yanking from willy-nilly and upgrading with carefree aplomb. You’ll be tempted to install an AUR frontend like packer or yaourt and just treat it like your package manager.
Turns out this is not the greatest idea. Nothing wrong with AUR wrappers (fond of packer myself), but you do need to be keenly aware of when you’re installing things from the AUR and be aware of the administrative cost. AUR packages are downloaded as source, compiled against the state of your system when you install them. This can result in subtle problems; for instance, if I install package fizz from the AUR that depends on library buzz, and library buzz subsequently gets updated, fizz may break4. This happened to me a couple times, and it was tricky to hunt down the culprit (especially when fizz is itself a library, and the problem is showing up in one of its dependents).
For that reason, I think the AUR is great for applications and other non-core stuff, but take my advice and stay away from the AUR for important packages that are available in the regular repos.
The WIKI is your friend. No, really!
I’ve been a part of a number of distro communities over the years, and did my fair share of wiki-maintaining; I can say categorically that most distro wikis are a disorganized mess of outdated, inconsistent, and incoherent information5. “Check the wiki” is typically low on my list of problem-solving techniques.
The Arch Wiki, however, is a work of art. I don’t think there is a more complete and accurate compendium of free software knowledge anywhere on the Internet, and it seems like every issue or question I’ve had since starting with Arch is answered clearly and completely in the wiki. Heck, it’s even useful if you don’t use Arch!
I don’t know who’s responsible for the state of the Arch wiki, but I hope they’re all happy, rich, and feeling loved.
Do actually read the website before updating
Just like “Wear a bike helmet”, “Chew your food 20 times”, and “Change your underwear everyday”, “Check the website before you update” is the sort of pat advice that everyone gives you after the disaster but nobody heeds beforehand. This is serious business when you run Arch.
There aren’t a lot of times when you’ll get burned by an update in Arch, but it is a bleeding-edge rolling-release distro, and there are just sometimes when releasing a buggy package is the lesser of two evils, or times when the only way from A to B involves some steps a package manager can’t handle automatically. I’d say once every couple of months, something comes along that requires a caveat or special intervention, so don’t be a stranger to http://archlinux.org.
Keep your system clean and lean
I went through a long “oooh shiny” phase with free software, installing package after package just to check out some new app or tweak my system in some new cool way. This seems to be a bad M.O. with Arch.
First off, Arch is a rolling release. It gets a lot of updates, and the stream of updates is constant. Sometimes it seems like you can pacman -Syu four times a day and still have updates each time. Each package you load on your system is a package you’ll be updating whenever there’s a new upstream release, patch, or packaging tweak, so installing a lot of software you never use becomes a significant liability.
Indulging in the AUR makes the problem even bigger; AUR packages need to be compiled from a fresh copy of the source each time, making a system update even more onerous.
Basically, install what you need, and if you try something and decide you don’t want to use it, remove it. Keep in mind that, as long as you have an Internet connection, installing software in Arch is fairly trivial, so why not leave things off the system until you actually need them?
My conclusions about Arch Linux
Despite some of the caveats I make about packages, I really feel that Arch suits me. I plan to keep using it, though not on every computer. Arch is really great on a computer that you use all the time and want to maintain detailed control over, but I’m not sold on it for my set-and-forget turnkey systems. My multimedia PC, my wife’s laptop, my kid’s computers, and my server will probably continue to run Ubuntu flavors or Debian.
My personal and work systems, though, are going to start migrating to Arch.
Footnotes:
Well, I don’t get to own it, just use it.
To be fair, you can build up just about any distro from a minimal base, and I’ve done so before with Ubuntu, Debian, and others. But with Arch, this approach is the official, recommended approach so it’s very well-supported and tested.
Emacs’s built-in package manager.
The solution in this case is to simply recompile fizz.
Including certain very high-profile distros aimed at “human beings”…
