A Weekend With Arch
Within a few months of beginning with Linux, it became obvious that I was one of those who have severe difficulties settling on a distribution. This situation presents some unique challenges, but generally, I've found there are more benefits than drawbacks. While I may have favorites, or be more familiar with some distributions than others, they all offer a little something different.
A few months ago, I wrote about Gentoo. It's been one of my favorites, as it's a learning experience and exceedingly stable when it's been successfully configured. A few commenters suggested Arch Linux as an alternative.
This weekend, I finally got a chance to take Arch for a spin. A basic installation isn't a huge time investment, and while it isn't quite as "under the hood" as Gentoo is, it's a clear canvas for those needing specific tasks and control on their system.
By nature, Arch Linux is barebones. It is optimized for i686 and x86-64 architecture chips, and official and community repositories offer the full range of applications you'd expect from any of the "larger" distributions. Of course, the idea behind Arch is that you choose the included applications, development and desktop environments, daemons and services.
Arch does a very respectable job making this simple. I opted for a network install of an i686 image via flash drive on my AMD Athlon X2 desktop. I chose this method for a few reasons: Arch recommends network installs to save time updating after the fact, 64-bit operating systems aren't without quirks (nor is booting some 32-bits on 64-bit systems), and a flash drive was handy.
Downloading the network install image and getting it on to my USB drive was straightforward, and the initial boot was uneventful (save the not unexpected need for adding 'noapic' to the kernel line in GRUB). Indeed, the common installation guide and efficient approach to the installer made it seem, in many ways, less confusing (if not quite as visually appealing) than some graphical installers.
Somewhere in the process, I made a mistake, though. Let me be clear on this: I am one hundred percent sure I made the mistake. It wasn't catastrophic, it was merely annoying. I'm still puzzled exactly where I went wrong, but I have a good guess.
It may be that a few configuration files need modification prior to Arch's first boot. This can vary from system to system, depending on hardware and desired use. Most configuration files that Arch throws out here need minimal editing, and are listed to make specific edits simpler and to verify particulars. For whatever reason (likely clumsy keyboard work), my /etc/fstab had duplicate hard disk information, which ended up causing GRUB some confusion (made all too obvious when the splash screen kernel image boot command was punctuated with line breaks).
That's the beauty in a system such as Arch, however. Because I had partitioned my drives, and explicitly told GRUB to install on the MBR, the odd appearance of the kernel boot parameters gave me a tip off where things were amiss, and I knew quite well where root was located. Editing from the splash screen had me back in business shortly.
Arch boots into a terminal, and that's where the fun begins. Generally adding users and any necessary processes or services that will be required to run applications is suggested at this point.
Arch Linux uses Pacman for its package management system. I told Arch to use the Pacman repository I used during install for any updates, but like other package managers, repositories can be changed or added as required.
First on the agenda for me was to get a desktop environment on the system. I refreshed and updated Pacman, then issued the command:
pacman -S gnome
Pacman modestly states it does some basic dependency resolving and handling tasks. It likely has a lot to do with the command line nature and the attention it draws to certain messages, but sometimes basic really is best. Any suggested or questionable issues were explained thoroughly with pertinent information to getting the packages in question to behave as desired.
For instance, I was prompted to add fuse to my modules in /etc/rc.conf should I want it to load on boot, otherwise I would need to load it as needed manually with modprobe. In the same vein, Arch doesn't by default use abstraction layers to manage and administer software added to the system. This makes things generally easier for your system to interact with different levels of applications (and ideally keeps extraneous processes out of the picture).
It is something to be aware of, however. Where my keyboard would function perfectly with the terminal, changing my runlevel, rebooting, and starting the display manager would give me a log in screen, a blinking cursor, and a completely immobile mouse and keyboard. This was due to the HAL (Hardware Abstraction Layer) daemon not being called when my graphical interface was looking for the hardware needed to interact with it. While it may seem foreign at first to not automatically start such processes, the idea is to have a system that behaves in exactly the manner you'd expect. As more components interact, knowing exactly what's running, why, and how these pieces have behaved previously keeps the system running faster, and with more stability.
It's hard to explain what Arch Linux, when it's up and running, really is. The idea, of course, is that it's what you make it. After installing the GNOME meta-package, and a few extras, I had a "core" system -- with a GNOME desktop. It's up to me to take it where I need it go next, and it pledges to keep a step back, and not try to be something I don't need it to be. It's not something that will appeal to everyone, and that's fine (and as it should be). Arch's power is ironically both in its quick and dirty optimized core system and its completely blank slate approach to making it what you want it to be.
Arch isn't for those completely new to Linux -- nor does it claim to be. There is a definite appeal, though, for those interested in a customized system without the "heavier" extras found on some Linuxes -- and who haven't quite the time needed to get other "bare" distributions working to their liking. Those needing a no frills distribution for quirky hardware, or looking to streamline tasks from systems administration and development to advanced desktop computing might find that Arch is exactly what they've had in mind.