Moving To Arch Linux: Humanity is Overrated

“Ubuntu” comes from an ancient African word meaning: “I can’t configure Debian.”

Anonymous, 4chan /prog/

It’s been a long time coming, but I’ve finally decided to move to Arch Linux, after using Ubuntu for basically my whole professional life.

I originally switched to Ubuntu from Debian, for no better reason than back then, getting things like sound cards and printing running smoothly was a clusterfuck, and Ubuntu at least made those things easy. The default Ubuntu UI was always garbage, but I didn’t care. I’ve been using heavily-tweaked notion as my window manager for years (I’ve tried xmonad, wmii, i3, stumpwm, and others I can’t remember; I always come back to notion). I would hear occasionally some controversy about the latest shitty desktop environment Canonical was forcing on its userbase, but it was another world to me. My standard practice was to install Ubuntu, get a few things working, rip out the Ubuntu garbage, and replace it with a real UI. For the most part, it worked.

But as the years have gone by, I’ve found Ubuntu more of a hinderance than a help. The basic problem is that the more you try to make your distro idiot-proof, the more you make it expert-proof too. I didn’t want a distro that made me spend shitloads of time mucking around with unix guts just because I could. But since I can, I want a distro that gets out of my way and lets me.

I always liked Arch from the beginning. It seemed like the right thing. Hacker friendly without the disagreeable aspect of, say, Gentoo. If it weren’t for the fact that multimedia was inconvenient back then, I’d probably have always used Arch.

Fast forward to today, the advantages of Ubuntu (for an expert) have all but disappeared. I no longer find it easy to make things work. In fact, I spend a great deal of my configuration time translating Arch Wiki instructions into Ubuntu. And multimedia is trivial everywhere. Getting sound working on my Arch install required installing alsa, and nothing else.^[1]

The biggest strike against Ubuntu is the difficulty of keeping up-to-date, even with the most bleeding-edge version available. The fact that the current standard version of Python is 3.6.1 is of no account the Ubuntu package maintainers, who serve up 3.4.3 as if nothing had or possibly could change. One can always use the PPAs, if it weren’t almost impossible to find a suitable PPA for your particular purpose.^[2] There’s also the fact that once you switch to PPAs, your package download speed drops by 2 orders of magnitude (or more, if you’re installing for a cloud server), which is a bit annoying when one is using PPAs to install 100mb packages,^[3] but I could put up with that if everything else was decent. I’m currently running rvm and nvm on this machine, not because I really need them, but because it’s the most convenient way to keep my versions of Ruby and Nodejs up-to-date. Sure, my xterms & screen sessions start noticably slower, but I can just buy faster cpus!

Clearly, the thing to do would be to build my own binary debs. After all, I’m a fairly sophisticated unix person, the tools are freely available and documented. Should be no problem, right?

I’ve tried building my own debs. God knows, I’ve tried. It shouldn’t be hard to say “I have a git repo, it builds. I want to change the build a bit, add some metadata, build it, and tarball the build.” Yet somehow it is. The deb tools apparently designed to do this appear to violently resist the process. I assume, on the Principle of Charity, that the underlying deb tools are heavily optimized for a world of software distribution that no longer exists, rather than being some kind of clever prank to annoy me.^[4]

There’s also Jordan Sissel’s fpm. I like Sissel a lot; I use his keynav every day. But I do think that as a way to easily package anything for anywhere, it’s got some ways to go. I wish him luck though.

Or you can build from source. I remember using Slackware back in 2003 or so. I didn’t like it.

Still, I continue to build uwsgi from source for my production servers (it’s the easiest way around the python/uwsgi/uwsgi-plugin-python dependency clusterfuck). I also have to install Nodejs from tarball binaries and several other key packages in ugly, manual ways. At least they’re programmatically-provisioned, semi-disposable cloud servers, so you can sort of pretend it’s not happening. Doing this on one’s own dev machine feels horrible. Canonical should just announce on their website “We give up, use vagrant.”

When I got my first Arch environment up and running, I was happy to see that they’d included my xkb-config change to turn the PrtSc key on my Thinkpad into a second Windows key (or META4 or whatever). I’d given up hope of that ever being included in Ubuntu, and given the difficulty of building and switching to a build of xkb-config, I’d given up hope of using it in subsequent dev machines for the forseeable future. It may be a small thing, but the fact that I can just install X and then do setxkbmap -options altwin:prtsc^[5] somehow means a lot to me.

So far, I’ve not had occasion to use any of the more advanced Arch packaging approaches, such as AUR or making my own custom PKGBUILDs. Given the how well plain old pacman works, it hardly seems worth considering. However, a friend^[6] who shares my opinion of the Debian packaging process says that in contrast, Arch just works. I know that on the few occasions I’ve had to look at PKGBUILD files, they seem super-straightforward.

So I’m stepping into the brave new world of real linux distros. I also plan to use more of it on cloud machines. I always thought “Ubuntu Server” was a bizarre concept. The only reason it ever made sense was lots of Linux people use Ubuntu, so Ubuntu Server would be familiar to them. But the problems of Ubuntu are even more problematic for servers. The only real way to configure servers is the ugly old unix guts way, And the Arch guts are way nicer. The fact that, in theory, I don’t know where anything is on arch is hardly a problem because everything is so much more straightforward. If I was a unix hepatoscoper, I know which one would make me feel good about the future of software.

Of course, now that I’m a more sophisticated developer, it’s going to go somewhat more nicely. I’m still waiting for my new Thinkpad to arrive, but I’ve got an ansible setup all ready to go, which I’ve tested on some recycling-grade laptop lying around the office. After booting arch, I install ssh, python2, and set sshd to allow root login. The first Ansible playbook logs in, creates my user, authorizes my keys, and disables root login. The second playbook actually sets up my environment. It’s pretty sweet.

Now I just need Arch stickers.

---

1. I might have had to log out & back in again too; I can’t remember. ↩︎

2. You can’t filter PPA search results according to Ubuntu release, for instance, let alone by version-which-is-packaged. You end up manually looking through the contents of dozens of abandoned PPAs trying to find one which will work for you. One day I sat down and tried to use the launchpad api to make it easier to find usable PPAs. Then I said, “What the fuck am I doing?” ↩︎

3. There’s actually a PPA which serves up daily builds of Chromium, at a staggering 80kbps download speed. I’m not totally sure who this is aimed at. ↩︎

4. I picture the Debian technical committee, having hacked my webcam, watching me try to build my NodeJS deb and laughing uproarously. ↩︎

5. I don’t actually know if that’s the exact command; I’m typing this on my old Ubuntu machine and don’t have the code or the Arch machine handy. ↩︎

6. He (very sensibly) doesn’t want his name associated with this blog. ↩︎