I had a request for some comments on Arch Linux, now that I've been using it a few days, and in particular the question of whether it is easy to install.
Well, I don't know. I found it reasonably easy to install. However, I know a lot about Linux installation in general and Slackware in particular, and Arch's installation process is similar to Slackware's. It is driven by a terminal-based menu system (probably the same library of scripts that Slackware uses). My own installation was a little unusual because I was installing on a machine that already had a live Linux installation on it; I wanted to first install to a dual-boot configuration between my old installation and a small testing partition of Arch, then if I liked that, do the full install which would preserve only the home directories and some data files from the old system.
I used a USB image and a net install. Because I already had a working Linux installation I could use that to download the USB image (185 megs) and put it on a key. I didn't consult the documentation for how to do that and am not sure whether it's any good - I already know off the top of my head how to write an image to a USB key. Booting the USB key and running the installer went smoothly. Disk partitioning was tricky in my case because I was doing something complicated - a mixture of old and new partitions, and leaving alone several existing partitions from the old system, all of it in LVM logical volumes on top of a RAID. I did it all manually (on the old system before I started, in fact) and then carefully told the installer where to put each part of the system. That would be less of an issue for someone installing onto a new system or wiping out the existing operating system on a machine. There is an automatic partitioning option; I don't know whether it's any good.
The net install went slowly because I have a slow DSL connection, but was otherwise uncomplicated. (One can also get and burn a DVD image.) There were some issues with the boot installation because of my partition configuration: LVM, RAID, and having /usr in a separate partition from the root, each require their own manual changes to the configuration for the init-ramdisk generator, and the user is not clearly warned that these changes are necessary. I don't know how well the installer does with creating a dual-boot system; on my first installation I was using the existing system's LILO instead of putting on a new boot loader, and on my second installation I found that GRUB can only handle installing to a RAID mirror from its own interactive installer, not a config file, and so I had to do that one by hand as well.
I'm not too concerned about LVM or RAID being issues for boot, because they always are, and tend to only be used by people who are comfortable doing it by hand anyway, but I am displeased by the fact that having /usr in a separate partition is an issue. I think it's good practice to have /usr in a separate partition, the developer in charge of this part of Arch evidently doesn't, and even with the right incantation to mkinitcpio, what is actually being done is a less-than-good workaround. Someone who wasn't trying to use LVM, RAID, or separate /usr wouldn't face those issues; and it's not really a big enough deal to stop me from using the distribution.
More detail on the /usr thing: I think it should be possible to bring up a system without /usr. Arch has trouble booting on a system that has separate /usr because it needs things from /usr early in the boot. I think it shouldn't need things from /usr early in the boot. I'm told to configure mkinitcpio so that it mounts /usr earlier than other filesystems, in order to have the things from /usr available early in the boot. That means it can boot with a separate /usr, but it still can't boot without any /usr, which defeats the main purpose of having a separate partition for /usr and indeed the reason for existence of /usr at all. In fairness, however, while I was working on this I discovered that even my old Slackware system which had separate /usr and I thought could boot without it, nonetheless wasn't willing to unmount the /usr partition in single-user recovery mode once it had been mounted, because of locale files opened by the shell. So maybe "can't boot without /usr" is not as big a departure as I thought.
Once the system was up: it seems to work pretty well. Package installation with the command-line "pacman" program works. I installed another package manager called "pcurses," which is not part of the main distribution and had to be downloaded and compiled semi-manually from a separate "Arch User Repository" of source code packages. The advantage to pcurses is that it gives a terminal-graphics browser of available packages and allows making up a list of desired packages and then installing them all in one go (nice when doing it over a slow network connection). I'm sure GUI package management programs exist too.
Basic networking was easy (good thing, because I needed it to run the installer). I had some difficulties getting the smaller details right, and ended up having to hack some of the scripts manually while guided by poor documentation. I am using a DHCP address provided by my
cable DSL modem but want my computer to also listen, on the same interface, to a static private IP address assigned by me, for networking with other machines on my home network. That configuration isn't supported by the default installation at all, and is supported by the more advanced set of network configuration scripts in the package I downloaded, only with manual modifications to the scripts. I don't know how wide the range of networking options that are easily supported actually is. There were some similar issues with configuration of networking demons and the default settings not really being sensible or what I expected: fetchmail wants to run as its own unprivileged user, which may be good for security but wasn't what I'd been doing before and that meant my old configuration of it broke in unexpected ways; I'm not sure the SSH demon disables root logins by default; you can install PHP, Apache, and SSL with the package manager but making them work together requires manually adding extra stanzas to the Apache config; you can install sendmail with the package manager but they try to discourage you from doing it and you must deal with the notorious sendmail.cf all by yourself; and so on. There's a nice interface for starting and stopping demons and it's easy to add your own if you're not afraid of shell scripts.
I'd certainly recommend the XFCE lightweight desktop environment; that's not really a feature of Arch, since it runs on Linux in general rather than any specific distribution, but I switched from KDE to XFCE at the same time as the switch from Slackware to Arch. XFCE fixes most of my annoyances with recent versions of KDE and introduces only a few new ones of its own. Time was when GNOME and KDE were basically the desktop choices and if you didn't like one you'd use the other; but the big new excitement in the GNOME world is that they're going all Semantic Desktop, and that's what drove me away from KDE, so it seems unlikely that I'd be pleased with current GNOME. Getting my keyboard set up the way I wanted it in XFCE (to allow Japanese typing with the Anthy input method; a compose key; and Unicode hexadecimal including non-BMP characters) required some tricky manual configuration but was no worse than doing the same thing in other environments.