Well, after the holed diary last week in which I asked for distro recommendations, I tried five over the last few days. Time was relatively precious so I skipped the source-based distros and tried Slackware, Fedora, Ubuntu, DragonFlyBSD and Arch. I meant to try NetBSD too, but didn't, for reasons which will become apparent. It didn't take that long, actually. Things have developed to the point where most of these will install in under half an hour and I could then do most of the playing-around ssh'd-in from a more comfortable and liquid elsewhere.

Quick impressions: Errr ... they're all pretty good. You can go now.

Slackware is much as I was expecting; an intermediate-to-knowledgeable-level distro of a minimalist but rigorous structure. Using a beer metaphor, it had a "real ale" sort of feel to it. It doesn't pull-in package dependencies by default, which is an issue I'm sort-of torn on. I don't like the way that, with some mainstream distros, you select to install vim, and it pulls-in every possible dependency vim might ever need (Do you want the 'Lemmings' binding?), so I thought I might like Slackware's diffidence, but it irritated more than I thought it might.

I feel vaguely sorry for distro maintainers. It's a really hard balance to pull off. On the one hand, you need to give the user everything they might need for convenience; on the other, you want to keep things lightweight; on the third, you want to leave some of it within the user's power-of-discretion; on the fourth, you don't want them to have to be immediate experts. Finding a happy medium is a hard task and there's no wonder so many distros have sprung up catering to various approaches. The user-friendly distros either install everything and "damn the drivespace", or they offer various different package configurations: vim, vim-light and vim-mini etc. The more experience-required ones tend to bias towards leaving it up to the user.

That's one issue. The second, related, issue is libs and headers. I'm a dev (or at least I play one on TV) and I wants them, precious. I want the libs. I want the headers. No-no-no-no-nooooo; I don't care for your estimations of what I might need; I want the libs. I want the headers. No ifs or buts. Once more, with feeling: If I'm installing a package, I want the libs and I want the headers. I'm aware that this point is being laboured.

There's little more infuriating, tech-wise, than getting ten minutes into a build and it failing because it can't find an APR (Apache run-time) library, for example.

"Oh, but I installed apache.rpm."

"Aha! You need the apache development package, not the binary package."

"OK. I just installed apache-dev.rpm. It's still not working."

"Aha! apache-dev.rpm contains the headers and source; the libraries are in apache-dev-2.rpm."

"Fuck. You. I don't need this in my life."

Again, it's a tricky balancing act. Why would a normal user ever want their hard drive cluttered-up with development cruft that they're never going to use? (When they need to do a configure, make, make install themselves and realize it's not 'all gravy', perchance?) (Hush, you; we'll have no valid points being made here.)

Why am I going through all this again? Because it's where Fedora fails it, and fails it hard. It always did. It always will. Yum, my arse. Beer rating: Carling. Next.

Ubuntu. I've a confession to make: I don't like Ubuntu. I've never liked Ubuntu. I don't want to like Ubuntu.

The reasons for these feelings aren't. Meaning: I don't have good and proper reasons for feeling this way. I just do. It's prejudicial. I don't like the Soft-Corp® presentation. I don't like the whole "An African word meaning 'humanity to others' or 'I am what I am because of who we all are'" line of bull[1]; worthy maybe, but save it for the coffee adverts, eh? I don't like the way Ubuntu has piggy-backed itself on Debian and then claimed kinship because some developers do work for both (the number of Ubuntu-related problems people think it's Debian's business to solve are unbelievable). I don't like sudo systems - or rather, I don't like the 'pitching' of sudo as if it's in any way novel or significant. Lastly, I don't like every fucking grommet with an anarchy badge telling me about how I have to drop Windows and switch to this awesome new OS.

Whew. Aren't you glad I got that off my chest?

Now; here comes the real point: As you will have noticed, none of those are particularly relevant. Some are objections to marketing; some are objections to users (although by no means are all Ubuntu users "fucking grommets"; most are decent human beings who know what they're up to) and some are objections to presentation. sudo aside[2], none of those are objections to the technology, which is the actual good / service being discussed.

Anyway, it turns out that Ubuntu does exactly what it says on the label, and is, perhaps unsurprisingly, pretty good at it.

The install went very smoothly; it detected everything and worked out of the box. As opposed to my normal way of installing (paying attention to everything going on - manual partitioning schemes etc.), I decided to test its claims and just click buttons. It worked. My only real gripe is that, as someone familiar with Debian, I'm not sure exactly what it's offering me as an alternative: i.e. what can I get from it that can't be gotten from Debian? Well, its six-monthly release schedule is more up-to-date. One of my main problems with Debian was that 'stable' was prehistoric and 'unstable' thoroughly lived up to its name. Ubuntu offers more up-to-dateness in that sense. It also offers Debian's more considered approach to packaging; although the must-remember-to-install-development-packages-too aspect is still there to an extent.

If you want a friendly linux distro which is also good to experienced devs, who am I to sail against the wind? Ubuntu's a pretty good choice. Beer rating: Hoegaarden.

Anyway: After I nuked Ubuntu I installed DragonFly BSD. This took the longest to install, even though it now uses the graphical bsdinstaller app, so it doesn't have to be done by hand (note that the guide is slightly out-of-date in suggesting the hand-built method, although it can still be installed that way). The time it took was mostly because I'm not as familiar with BSD conventions (disk naming, slices, different layouts etc.) as I am with Linux ones, so had to spend a little time cross referencing to documentation on another computer.

It's a very interesting project. At this point, it's relatively stable and can just about be used on a server (with a bit of tweaking, I managed to build Apache from source fairly quickly), but it's perched between two stools at the moment. It's trying to get away from its FreeBSD heritage and is about half-way there. The eventual idea is a really slick one; that an elegant Virtual File System sits between userland and a very small kernel, enabling transparent user-level translation of any system calls. In addition it's geared towards massively parallel processing and SMP, with a new lightweight kernel threads implementation and a scheduler-per-processor architecture, and the concurrency design reflects that, even though some of it's not fully implemented yet. The linux compatibility layer will eventually be in the VFS etc., even though it isn't at present. It uses the NetBSD pkgsrc system for its build management (loosely equivalent to FreeBSD's 'ports' or Gentoo's 'portage'), although eventually it will have its own.

This sense of transition pervades everything: The docs aren't quite up-to-date, but the information is available if you look for it; some of the structure has been re-jigged, but other bits haven't; it uses pkgsrc, but eventually won't; some things have been moved out of the kernel, other bits haven't etc. I liked what I saw but was left with a sense of "I'll definitely come back later, when it's a bit more cooked". It doesn't feel like a stagnating project, just a case of too few devs to keep the documentation up-to-date and convenient at present. The mailing lists are fairly active and the software runs well (I didn't really find a problem in the short period I played with it), but didn't really want to be in the position of adjusting to a rapidly-moving target at this point.

Beer rating: Weston's Organic Cider.

It was after the diversion of BSD Unix that I returned to more-familiar realms of Linuxdom. Arch is a distribution I'd been meaning to try for while. It was the flavour-of-the-month before MEPIS, which too has now faded from hype.

About fifteen months ago, I tried to install it on a fairly run-down PII, but had no success getting it to even install. It's a fairly aggressive distro, tuned heavily to the i686 instruction set so it won't work on anything else (In normal language: If it's an Intel pentium II or later, or a clone thereof, it should work, but my old PII didn't).

The new hardware upon which all these messing-arounds were performed was centred around a p4 chip and mobo. In contrast to my previous attempt, it worked just fine this time. The installer is similar to Debian's, so if you've ever used that, you'll know what it's like. If you don't, it can be confusing as you have the option to go back and redo things, and hop between command-line and graphical (ncurses) mode, although the sequence isn't immediately obvious to the newcomer.

The install was very, very quick; less than twenty minutes. This is one of those distros where, if you know what you're doing (and how certain kinds of linux installer software tend to work), things can get done very rapidly; if you don't, though, you might need to take a little longer. As with Ubuntu, the hardware was detected perfectly (probably easier to do when you're targeting just the one platform) and the choice of kernel and modules was excellent. After installation, I usually build and install a static custom kernel manually, just to trim the fat, but it chose exactly what was needed and, quite frankly, I couldn't be bothered with a rebuild just for the net effect of moving some modules into the kernel.

A WARNING: Anyone installing Arch should be aware that the default grub configuration contains a slight flaw. The grub.conf / menu.lst file is generated for you, but in my case it failed to locate the correct boot partition. All the other configuration information was correct, but I missed the one error when checking it over. This meant that, when I rebooted, it froze as it couldn't find the initial ram disk or the kernel. Some quick patching with a live CD and all was well (the good thing about the boot sequence breaking that early is that the problem can only be one of a couple of things).

It uses a package management system called pacman, which is minimal, but does almost everything it needs to do. The dependencies it pulls in are, like Debian's and Ubuntu's, nicely balanced. It's predominantly a binary system, but can be used in conjunction with Arch's ABS (the Arch build system - a ports / portage equivalent) to build from-source packages. It's very much as if apt and emerge had a very skinny child and I can see why other distros are using it (someone's even using it with DragonFly). Updating is a piece of the proverbial. Like apt and portage, it can self-bootstrap in situ, and sync to network repositories, so you can constantly stay up-to-date with no reinstall requirements.

As you've probably gathered, I liked it. It seemed to have the best elements of Gentoo and Debian in a skinned-down binary distribution, with the up-to-date-ness Debian sometimes lacks and the stability Gentoo's bleeding edge sometimes drips on.

I did have some concerns about using such a rapidly-updated distribution on a server, even though I was using the 'current' branch, but some research revealed that others do use it that way. I'm not sure I would use it as a server distro for anything important just yet, but four factors have led me to stick with it for the time being. Firstly, it seemed stable enough; secondly, I'm not using it for a particularly important service - it's the home hackery server - it can go down once in a while with relatively little bother; thirdly, on servers, I tend to install a fairly spartan base and then install the rest (databases, web servers, modules etc.) from source, having developed by this point a set of procedures and scripts to make this simple. Fourthly, I was getting tired of distro-hopping by now and felt I'd found a decent enough point to "stick", however temporarily it may yet prove to be. Beer rating: Cobra beer.

At this point I was going to give you a link to a proto-site and let people hack away, but I'm still in the process of pissing about. Thanks to theantix's patch, some grepping and hackery, I managed to get Scoop running on Apache 2.2.3, although some stuff doesn't work.

[1] - The thought occurs that the first sentiment is meaningless gibberish as made plain by Nietzsche's argument to the stoics, and the second sentiment could just as well apply to genocidal maniacs as anyone else, but that's a tangential issue ...

[2] - And note that I wouldn't even claim sudo was technologically bad, or worse in any way; it's a fairly neutral technology - use it or don't. It's just that I don't particularly like it, and like even less the proselytising of its innate greatness.