2009-12-30

Arch vs. Slackware, a friendly comparison

As you might know, there are about a hundred thousand million billion Linux distributions. (For those who don't know, the "Linux" core is an operating system kernel, and people take it and build collections of software around it called "distributions", and people install these distributions, and then, in casual conversation, call the distribution "Linux". All this adds up to confusion for people who don't already know it all.)

Which distro you choose depends a lot on what type of user you are, and how dirty you want your hands to get. For many people, this is, "I'm a normal user, and I don't want to get my hands dirty." (I recommend the Ubuntu distribution for these folks.) Some people might want to run a server; in that case Red Hat (or CentOS) is a good one. Of course, there are many, many good ones (I'll put a nod here in for BSD.)

But that's not what this post is about.

If you're a user who does want dirty hands, you might consider the following two comparable distros. Both support 32 and 64-bit, and both adhere to the KISS principle. They are the relative newcomer Arch Linux (created in 2002) and venerable battle-tested Slackware Linux (created in 1993 and currently the oldest actively-maintained Linux distro—kids who were born when Slackware was released are driving cars today). By "getting your hands dirty", I mean there's a lot of manual configuration file editing, not a lot of GUI friendliness, and lots of terminals. Eventually you'll get the system set up with a nice GUI; both Slack and Arch officially support KDE—Arch also officially supports GNOME which is easily available for Slack via third parties.

Why would you subject yourself to this? Answer: because you'll learn a lot about how the system works, and when it breaks, you'll be much better-prepared to fix it.

The irony of the user-friendly systems is that the layers of user-friendliness are by necessity layers of complexity. The systems are offloading the tasks of system management from the relatively smart super-powerful human brains and moving it onto a relatively stupid piece of complex and fragile system management software. (I'd argue that the reason these pieces of management software are fragile and complex is that historically Unix systems were administered by humans, and they weren't built with "fire-and-forget" machine administration in mind, but that's a story for another time.)

So we get rid of the layers of complexity, and put humans back in charge, and you end up with a simpler system at the expense of the human needing to know more about how to configure and maintain it.

(If you really wanted to get a feel for how a Linux distro works, you can build your own with Linux From Scratch, but I won't take you that far today.)

So back to the two distros in question: Arch and Slackware. Both install in text mode (with text-based GUI widgets) and don't fire up X until you tell them to. Slackware's installer will handhold you through the configuration process, while Arch's actually puts you into an editor to hand-edit /etc/rc.conf (which is a pretty simple file).

Arch's install is a little bit different in that it doesn't actually come with X—you have to install it with the package manager (which downloads it) before you can use it.

With both, once the install is done, you'll get a login prompt and can go from there.

Both systems include package management software, and both use a tarball-based format. Arch's custom tool called "pacman" is faster than Slack's, but I never found that to be a practical concern. One major difference is that Arch uses a package dependency system, while Slack does not. Slackers don't care for dependencies, which they feel lead to "dependency hell". Can a system be stable without explicit dependencies? Yes, it can, as Slackware shows in practice. Users just upgrade packages as needed. On the flipside of dependency hell is dependency heaven, where everything works properly and you upgrade and it pulls in the necessary packages and that's that!—Arch pulls this off quite well.

Speaking of stability, Slackware is known for it. Packages are well-tested tried-and-true versions of the software and non-security updates between major releases are rare. You set up a system and it "just works" forever.

Arch doesn't make a stability claim, mostly due to the fact that all the software on the system is basically cutting-edge (generally it's the non-development versions of the software, though). As new software is released, it comes out for Arch very very soon thereafter. (There is often a delay while the packages move through Arch's "testing" repository, which users don't normally access, but can access if they want to help test.) Arch users upgrade their systems early and often by running pacman -Syu to upgrade all packages. Usually several packages get updates each day as new versions are released. Arch packages them all, whether they are security-related updates or not.

While that sounds like some kind of stability nightmare which would result in a broken system more often than not, in practice the upgrades work without a hitch virtually all the time. I had one breakage where an Arch maintainer forgot to push a KDE package out that was part of a major update, but that was soon fixed. Another breakage occurred when nVidia moved my video card's driver into another package and the old package wasn't compatible with the latest Xorg server—installing the proper Arch driver package fixed it. These were the only two upgrade failures I'd seen in eight months of near-daily upgrades, and I can't really blame the second one on anything fundamental to Arch's system.

If you want to push Slackware a bit and get access to more up-to-date packages, you can update against Slackware's "-current" repository. This stuff isn't well-tested (because its users are the testers!), but eventually -current will be blessed into the next official version when it's rock-solid.

Speaking of updates, what of security updates? Slackware is good with security updates, and provides them for the current release, plus several back-releases. You can be assured of security support for a long time, and I never once had a security update break the system. Arch, by comparison, does not have "security" updates, per se; their security updates just happen as a matter of course when you update the whole system to the latest. Arch doesn't provide separate security issue tracking.

One place where that makes a real difference is if you want to run a server. With Slack, you know that updates you make are going to be for security purposes, so that's OK. But you might not want to update to the latest version of postfix "just because", since it might be a disruption to the users. As such, I'd not recommend Arch as a server, though there are people who run it as one. (One concession Arch has made in this regard is the "stable longtime supported kernel", a kernel package that is not frequently updated and is thus more suitable for long-uptime machines.)

You might be thinking, "If Arch constantly updates to the latest, why would you ever get 'latest release' DVD?" You wouldn't! Once you install it, you'll never do a reinstall or big upgrade every six-months or so. You just keep updating to the latest over the net. Arch calls this the "rolling release" model. Slackware uses a standard version number-based release model.

Which distro comes with more packages? The answer, to be short, is Arch. Quite a few more. Let's not beat around the bush: it's a lot more. Slack 13.0 has about 1000 packages, while Arch has about 4000. What this means is that things like Inkscape will be in Arch's official distro, but not in Slack's. Don't get me wrong—1000 is a lot, but you might find that something you want isn't there. (You can always build and package things yourself, of course.)

When you want some software that's not in the repo for either distro, you can step outside the official channels. For Slackware, this often means going to slackbuilds.org (SBo). SBo has about 1700 user-submitted "build scripts" (which are sh scripts you just run) that will build Slack packages for you that you can install. For instance, there is an Inkscape Slackbuild script there so you can install the latest Inkscape without figuring out how to build it yourself. Also provided is usually a README file that describes which dependencies you also need to install. In the spirit of Slackware's legendary stability, all the SBo scripts are examined and tested by (and, to a certain extent, vouched for by) the site admins.

By comparison, Arch has the "Arch User Repository" (AUR), which contains some 18,000 (!) user-submitted build scripts. Arch makes no warranty for or vouches for these build scripts in any way, stating, "Unsupported packages are user produced content. Any use of the provided files is at your own risk." AUR users ruthlessly flag PKGBUILD scripts out of date the moment a new version of the software is released, and the volunteer package maintainer is expected to either update the build script, or "orphan" the package so someone else can maintain it. The system runs itself and AUR admins don't tend to interfere with, vet, or verify uploaded build scripts. Though the build scripts could absolutely be malicious, I haven't seen this happen, and such a script would be removed by the admins.

Compared to Slack's standalone build scripts, Arch build scripts are bash-based, and are executed by Arch's makepkg program. These build scripts are cleaner than Slack's, since much of the grunt work is moved into the makepkg software, and the scripts can take advantage of bash-isms, like arrays. The loss is that an Arch package build is dependent on both bash and makepkg, whereas with Slack, the only dependency is sh. But the user process is the same on both: run the script and then install the resultant package.

In summary, the similar aspects are:

Slack and Arch: KISS principle, 32 and 64-bit, tarball-based package management, text install, config file editing is expected in administration, KDE.

Notable points to help decide between the two:

Slackware: total stability, good for servers and not-bad for desktops, relatively small (but reasonable) amount of well-tested stable software, security updates provided, GNOME from a third-party, standard release schedule, i486 build officially distributed, admin tools depend on sh.

Arch: good (but not guaranteed) stability, huge amount of cutting-edge software, good for desktops but not-as-good for servers, update everything continuously, GNOME officially supported, "rolling release" schedule, i686 build officially distributed, admin tools depend on bash.

Which one is truly better? That's up to you!