Can there ever be too much choice? Is that a bad thing? Well, to me in recent months it feels that way as I seem to have installed more Linux distributions than you can shake a stick at! Serial installers are a common phenomenon within the Linux community, but I say to you all, alas, I am cured!!! So, what makes Arch Linux
all that? Well read on…
ArchLinux quotes itself as being “an i686-optimized linux distribution targeted at competent linux users.” Part of its philosophy is that by not providing you with lots of configuration utilities, you are forced to “learn the ropes” and you will benefit from the additional knowledge acquired. A sensible approach you may think, and is fine for experienced and/or fearless techies. You know that this isn’t going to be the distro to recommend to your mother! But, I wouldn’t say ArchLinux is elitist as some readers may fear. Sure, you will be frowned upon (to put it mildly) if you ask questions in the forums that are blatantly answered in the main documentation.
However, expecting users to actually edit the appropriate config files manually isn’t a bad thing in my opinion.
Obviously, the choice of one’s operating system is subjective. I
know a lot of people who are using the “perfect” OS, but
each system is different. Perfection, I suppose, is therefore
relative to your past experience and current/future needs. Let’s be
clear, I like ArchLinux, so I feel it best to give some background
and discuss my OS requirements.
Nowadays, I’m studying towards a PhD within the School
of Computing at the University
of Leeds, UK. I spend a lot of time programming in Java
and Python. Browsing the web and
emailing are surely a given. I write my documents in Latex
or OpenOffice and in the
background I normally have an instant messaging client running plus
an mp3 player.
I’ve been running Linux in some form for about 8 years. If my
memory serves me correctly, Red Hat 5.2 was the first distro I
installed on my PC. My switch to Linux being my primary OS came
shortly after I started my computer science degree back in 1999.
Since then, I have played with many versions from mainstream Linux
vendors, namely Red Hat/Fedora,
Suse and Mandrake.
A year or so ago, I tried Gentoo.
Admittedly, I was worried about getting the thing on my PC as I
didn’t have a pretty graphical installer to walk me through. But it
turned out not to be that bad at all! And once up and running, I
thought I had found the perfect Linux distro. The Portage
package management system was great (and still is fantastic), yet my
poor old Athlon 600 was showing its age, and having to compile all
the entire OS (plus updates) tried my patience a little too much. I
had stuck with Gentoo for a while, but eventually, it had to go, and
Suse took over.
A few months ago, I bought myself a shiny new laptop, with plenty
of processing power and more than my fair share of RAM. Yet, Gentoo
was no longer on the cards. Sure, Gentoo has some pre-compiled
binaries for popular packages, but to be honest, I still believed
that all the compiling was too much of a hassle. So, over the past
few months, I have embarked on a mini-mission to find my New
Favourite Linux Distro.
So, what were my requirements? Basically, all I want is good
package management. Naturally, a good selection of packages need
to be available too. What my experience with Gentoo taught me was
that being able to easily maintain the software was the
killer-feature that I had been missing all that time with the
RPM-based systems. But, no compiling, unless I want to!
Speed and stability are also secondary factors. Although, I’m willing
to take some risks with the stability side of things by running
relatively up-to-date packages.
I feel pretty comfortable installing Linux nowadays. I’m not
saying that I could install Linux from the command line with my eyes
closed or anything, but as long as there is some half-decent
documentation, I feel that I could get by. I am in fact happy to
invest the time with a more “hands on” install as long
the the resulting system is what I want.
At this point, I expect many readers are thinking “Debian”
or “Slackware”. Both are well-established distros and I
was tempted by both. I had heard anecdotally that Slackware’s package
management is rather simplistic, e.g., no dependency resolution. (I
love how the Slackware
entry in Wikipedia
describes this as a “unique” feature!) Naturally, 3rd
party tools like Swaret
came into existence to remedy this, but I was still put off. I did
try a Debian-based system in the shape of SimplyMepis.
I was very impressed with the simplicity of installation. It begins
as a liveCD that you boot from and a fully functional KDE desktop is
loaded. If you wish, you can then click an icon and you follow a
little wizard, and before you know it, Mepis is installed! It was the
easiest and quickest install I had performed and I expect this
approach will become increasingly common in the near future. However,
the main attraction with Mepis (for me) is that you have access to
the vast Debian repositories, accessible through the well-known
apt-get tool. Things ran smoothly with Mepis. The Apt
system wasn’t as great as I had expected, although admittedly I
wasn’t overly familiar. Debian
has a reputation for being a tad too safe with packages it considers
‘stable’. So trying to update KDE 3.2 to 3.3 wasn’t as
straightforward. Anyway, there was nothing really wrong with
Mepis, but I just had this little itch as I recalled a review
I read ages ago about ArchLinux. I thought, “right, I’ll give
it a try, and if it doesn’t work out, then I quickly stick Mepis back
on.” Well, I’ve not had that urge yet!
NB, before anyone exclaims “But what about FreeBSD?”,
my answer is that it’s not Linux, is it?!
For this review I’ll be discussing ArchLinux 0.7 beta (Wombat). To
be fair, version numbers don’t really play a significant role like
they do with other distributions. I recall as a Red Hat user, I would
always be looking forward to the next release so that I could benefit
from updated packages. Unless I’m very much mistaken, ArchLinux
releases are little more than snapshots of the current and extra
repositories. Of course, you get the installer to with the release,
which I expect is improved for each iteration. Otherwise, once you
have it installed, its package management utility will keep you
The first thing to do is make sure you have read the installation
documentation. You’ll quickly discover that there are two
possible CD images. One is a base install, which provides you with
all the basic components to give a basic ArchLinux system. The other
is a larger image that comes with many additional packages. I opted
for the base installation, as intended to go for an FTP install. So,
download and burn. And whilst that is going on, read the rest of the
I booted up my laptop with the freshly burned disc. Incidentally,
my laptop is a Dell Inspiron 8600. No fancy hardware so I didn’t
anticipate and problems. The specs are: Intel 735 M processor
(1.7GHz), 1Gb RAM, 80Gb HD, CD/DVD writer, ATI Radeon 9600 128MB
graphics card,1280×1024 LCD screen. ArchLinux booted and a command
prompt beckoned. You then need to type /arch/setup to get
the show on the road. And then, what do you know, a curses-based text
installer! See, they don’t expect you to do everything at the
You are first asked for your installation method. I wanted the FTP
install. This takes you to network setup screen where it
automatically loaded my network card module and configured my network
via DHCP. You’ll then be expected to prepare the hard drive. For me,
that wasn’t difficult as it has already been set up from previous
Linux installations. So, I simply re-used my old partitions. There is
an “Automatically partition your hard drive” option – I’m
sure it would have done a fine job. Next was to then select the
filesystem types and mount points. This led my first head-scratching
moment. I am used to the /dev/hda* approach of the old
school /dev device tree. ArchLinux does use DevFS but it
apparently sticks to the ‘default’ device tree. This means /dev/hda1
is instead represented as /dev/discs/disc0/part1. Ok, it’s
not the hardest thing to get your head around, but at the time, I was
unfamiliar and so just hoped that part1 was hda1,
part2 was hda2, etc (which it is!)
Next is the simple task of selecting packages. I selected the base
system only. The following step is to explicitly install them, which
is composed of selecting a mirror, then the packages are downloaded
and installed. Choosing your kernel is the next step in the setup
program. You can choose either the 2.4 or 2.6 version. And within,
you are offered IDE, SCSI or build from source. It’s recommended in
the documentation to leave your tweaking until after the basic system
is up and running, which seems sensible to me. I choose the 2.6 IDE
“Configure System” is the next option on the setup
menu. Within is a list of various config files that are free to edit.
You could skip this section, but you will probably need to come back
to these files at some point, so you may as well get it over and done
with! I edited the rc.conf file, specifying my timezone,
keymap, and various network related things, such as hostname and
enabled DHCP. I also removed a couple of daemons that I know I don’t
need at the moment. I then looked at my Grub configuration in
menu.lst. I added an additional entry so I could boot my
Windows partition. Finally I added an entry in the fstab
file to automatically mount my media partition. This is a
large vfat (fat32) partition consisting largely of mp3s so that I can
listen to music regardless of which OS I’m currently in.
Happy with my configuration files, the final step was to install
the boot loader. You do get a choice of Grub
or Lilo, but as you will
have guessed I use the former. Pick where you want to install –
I always go for the MBR on the primary drive, which translates to
/dev/discs/disc0/disc. Done! Exit setup and reboot.
The OS booted with no obvious problems and was greeted with a
command-line login-prompt. Logged in as root which required no
password. Quickly rectified that with passwd. I then added
my first user account. It’s worth mentioning from the outset that if
you’re setting up a desktop PC where you want to listen to music and
watch DVDs, then it’s worth making sure that you add necessary users
to the audio and optical groups too.
Thought I may as well stay as root as I need to add a
whole load of packages so that I can have my typical desktop
workstation. This is where I get to experiment with the infamous
pacman – the heart of ArchLinux’s package management.
Unfortunately, at this point it became apparent that I had no network
connection to my router. The module for my network card hadn’t been
loaded. So, back to the /etc/rc.conf file and added by
network module “b44” to the MODULES
section. Rebooted and all was well.
Now, back to pacman. The first thing to do is sync
yourself with the current package database, pacman -Sy. If
you were installing packages from the CD, you may be better with a
pacman -Syu which will also upgrade any packages which have
inevitably become outdated since the CD was compiled.
Getting X installed was my first task. pacman -S xorg
went without a hitch. Running xorgconfig helps to produce a
working xorg.conf. (Make sure you know your monitor vertical
and horizontal refresh settings!) There was another DevFS trap here
which I fell into. I forgot that the mouse (well, touchpad in this
instance) was no longer on the default /dev/mouse but mapped
to /dev/input/mice. X would completely freeze whilst loading
until I figured that one out! Installing KDE 3.3 with the British
locale files was straightforward though (pacman -S kdebase
kde-i18n-en_gb), only needing to edit ~/.xinitrc to set
KDE as my WM.
As far as I can tell, the only modifications to KDE that ArchLinux
packagers have made are the default wallpaper which is a custom
ArchLinux background, and they have also added a menu set within
KMenu containing hyperlinks to various ArchLinux web pages. The
anti-aliased fonts option is not enabled by default, so I promptly
changed that (I can’t imagine anyone who would prefer jagged fonts to
anti-aliased fonts.) I also downloaded the MS fonts package (pacman
-S ttf-ms-fonts). The Bitstream Vera fonts were already there. I’m
not sure what package they were part of as there doesn’t appear to be
a ttf-bitstream-vera package as expected.
I’m happy using KMail and KNode that come with KDE, so no extra
effort required there. For instant messaging, once again I opt for
the KDE supplied package, Kopete, which allows me to log in to
multiple IM protocols all within the same application. The main
difference between Kopete and Gaim that I have noticed is that Kopete
obviously integrates better with KDE. The KDE web browser, Konqueror
is pretty good and is improving all the time. However, for pure web
browsing, Mozilla Firefox is my favourite. pacman -S
mozilla-firefox will sort that out. (Kitting out my browser with
the various multimedia plugins is discussed in the next section.) IRC
is supported by Kopete, but I find the interface to be rather
awkward. Pacman had no problem downloading and installing Xchat.
Additionally, I need an ssh client so that I can remotely log into my
Linux account at university to read email, grab files, etc. (pacman
Unfortunately, you are not spoilt choice when it comes to
BitTorrent clients. Not there is anything significantly wrong with
the standard BitTorrent client,
but there are some alternatives that are increasingly popular such as
BitTornado or Azureus
that offer additional functionality. The bittorrent package
was fine for me though (CTorrent
is the only alternative) – but don’t expect the installation to
automagically configure your browser so that clicking a torrent link
will open the BitTorrent client!
Finally, for the P2P enthusiasts out there, once again you are
hardly in for a dilemma over which of the available packages to
install. I normally use Limewire
but this doesn’t exist as an official ArchLinux package. So, for the
first time I put pacman to one side and installed Limewire
myself using its perfectly adequate installer. aMule,
and xMule are the officially
My preference for media players is Amarok.
This took a little bit of time to get going though. pacman -S
amarok will grab the package plus its gstreamer package
dependency. What it doesn’t do is install any of the gStreamer
plugins needed to decode various music formats. Amarok would load,
and it would show you all your MP3s, but try adding to the playlist
and nothing would happen. I had a feeling it had something to do with
gStreamer and discovered a package called gst-plugins. This
sounded important, so off I went and installed. No difference! I
looked again at more gStreamer related packages and found
gst-plugins-mad which is the MP3 decoder for gStreamer. I
installed it and then MP3 playing worked.
I occasionally like to watch one of my DVDs on my laptop. To grab
Xine, pacman -S xine-lib xine-ui
was the route I took. The libdvdcss package needs installing
if you want to watch encrypted DVDs – which I did.
Unfortunately, every time I tried to play my disc an error popped up
about not being able to read the source. This transpired to be a
simple problem of Xine’s default path for the DVD device being
/dev/dvd. For my system, under the ‘default’ device scheme,
it is in fact /dev/cdroms/cdrom0.
Finally, to complete my multimedia setup, I installed MPlayer.
All the non-Linux native codecs (Windows Media, Real, QuickTime, etc)
are found in the codecs package, and had already been
installed as a dependency of xine-libs. Although Mplayer is
effectively duplicating Xine, I like it because it is easy to combine
with my browser so that I can view media files over the web. This is
achieved by installing the mplayer-plugin package that
integrates MPlayer as a plugin to any Mozilla-based browser.
One aspect I always fear with the more “do it yourself”
distros is CD burning. It’s the one thing that I always hope that it
simply works out of the box. With no disrespect to ArchLinux, I was
anticipating problems in this area: the wiki had a CD burning section
that was empty except for “This tutorial has been removed
because it does no longer work”. A browse through the forums
will also yield tales of CD burning woe. And I did experience
problems, but they were all my fault! The short version of the story
(excluding details of broken media!), I installed my preferred
burning software, k3b (pacman
-S k3b) and burned a disc as easily as you expect. This, by the
way, was under my standard user name and not as root.
As I mentioned, Latex is my preferred system for producing
documents, which is made available via the tetex package. I
sometimes use Lyx which is a Latex
GUI frontend. Pacman -S lyx grabbed that, but also installed
tetex as well since it’s obviously a dependency. To view output, I
needed a Postscript viewer (pacman -S gv) and a PDF viewer
(pacman -S acroread). Ok, I know that gv will view PDF files
too, but I like Acroread, so I may as well install it. In hindsight,
I was glad I did because it installed the PDF browser plugin which is
useful as my research means I read many online publications.
I occasionally have the need for various office applications –
of which OpenOffice fits the bill. Because I require British
localisation and spell-checking, I require a couple of extra
packages, and pacman openoffice-base openoffice-en
openoffice-spell-en did the job. For those who like to live life
on the edge, the OpenOffice2 development packages are in the
ArchLinux unstable repository.
By this stage, my current favourite language, Python (v2.4) was
already installed – I reckon it probably got dragged in with
the KDE install. Java is the other main language I use. pacman -S
j2sdk will install the Java SDK (v1.5) for you. Vim has been my
editor of choice for the past 5 years and I needed the X version
adding (pacman -S gvim). I sometimes use Eclipse for larger
Java projects (pacman -S eclipse).
So far I have only really described package management in terms of
installing new packages. There is a lot more to it, and since Pacman
is such an intrinsic component of ArchLinux, I thought I ought to
discuss package management a little more deeply.
Like most package management systems, there exist some package
repositories that are hosted somewhere on the net. Arch Linux has
current, extra, testing and unstable.
According to the documentation, by default, Pacman only knows about
current which provides your basic system components. If you want a
graphical desktop and multimedia functionality, etc., you’ll need to
configure Pacman to use extra too. I must confess, I don’t
recall having to change anything in /etc/pacman.conf to
achieve this. Of course, if I did then it was only a matter of
uncommenting one line, which is maybe why my memory is failing me.
Alternatively, maybe the Pacman developers have stopped being so
conservative and are now providing extra by default too, but
the documentation team haven’t kept up! Testing and unstable
are pretty obvious in their purpose, and I must admit that I’m not
that interested in experimenting with their contents just yet! The
first job you must do is get in sync with your chosen repositories
should you choose to download from them, which is done with pacman
Before you can commence installing, you have to know the package
names as they are stored in the repositories, otherwise Pacman won’t
know what you’re asking for. The basic approach is using the -Ss
<string> argument which will return any packages that
contain the string in their names or descriptions, e.g.,
$ pacman -Ss p2p
aMule is a eMule-like client for ed2k p2p network
A bridge between P2P protocols and front-ends.
A complete, fully featured Gnutella P2P client
An easy to use, multi-platform clone of the eMule P2P filesharing client
Within a repository, packages are often divided into categories, such
as daemons, editors, games, etc. ArchLinux packages follow such a
scheme, but I have yet to find a way, via pacman to get
access to this information. So, for example, you want to search to
see all the possible editors available in the current repository.
This type of query is only available via the ArchLinux
package search web page. Still, maybe it’s not the sort of
feature Pacman developers thought you need since you are supposed to
be a competent user, and therefore know the names of the packages you
want to install, rather than just browse. Maybe my browsing habits
stem from my Gentoo days which had a fairly fine-grain package tree
stored locally in /usr/portage. I used to look through and
when I’d see something that looked interesting that I never heard of
before, I would emerge it and play with it for a while.
Anyway, once who know what you want, you have seen how easy it is
to install, and all dependencies will be satisfied. It’s worth noting
that systems such as apt-get with Debian have a reputation
for being a little over-zealous and installing masses of packages,
some of which seem to have no relevance. ArchLinux has been praised
for being more streamlined in this respect, however, is equally at
risk. This is because this issue is not the really down to the
dependency checking algorithms, it is due to the package maintainer
going overboard on specifying more dependencies than are actually
needed. ArchLinux package maintainers do have a nice system for
specifying runtime dependencies and compilation dependencies to help
ensure that only the necessary packages are installed.
Removing packages is also a doddle. You get a variety of options.
pacman -R foo will remove the package foo, but
leave any configuration files associated with it. pacman -Rn foo
will remove package and config files. Of course, the package that you
wish to remove may have installed dependencies that are no longer
required by any other package. The command pacman -Rs foo
removes recursively, and will remove any dependencies if they are not
required. There is another option, the “cascade” option,
which as far as I can gather will remove target package, plus
dependencies, regardless of whether they are required by other
packages! Of course, I could be wrong – but I’ve not had the
guts to try it in fear it’ll mess something up!
It’s worth noting that by default, if and when a new version of
the Linux kernel is released and uploaded to the current
repository, the next time you run the update command (pacman
-Syu), this version will be installed and overwrite your current
kernel. Now, in theory, I like this idea. I personally like to keep
up-to-date with the Linux kernel, so how handy is it that Pacman just
upgrades you with very little effort. However, in practise, you can
see it really opens itself up for problems. I seem to recall how
kernel 2.6.8 seemed to break CD burning for non-root users. You can
prevent prevent any package being upgraded if you explicitly add it
to your /etc/pacman.conf file (in this instance:
IgnorePkg=kernel26), although I personally think this should
be the default, and for users who know what they are doing, can
comment out that line if they are happy with the consequences.
Additionally, perhaps the ArchLinux developers who maintain the
kernel package could write a script that backs up the old kernel so
that it would be easier to recover should a serious problem occur
with the upgraded kernel.
The other aspect of package management is the Arch
Build System. It is this system that allows users to build new
packages that can be installed with Pacman. It is also possible to
recompile existing packages to amend the configure arguments, or to
use alternative compiler flags. This is a substantial topic on its
own and so I won’t cover it any further – I simply wanted to
highlight that these features do exist.
Speaking for myself – although I doubt I’m alone –
when I am thinking about switching distros, I like to know what the
support is like. I typically look for two things: installation
documentation and forums. This is important – I recall spending
ages deliberating over whether to install SimplyMepis because its
documentation was so sparse. The ArchLinux Installation
Guide was a decent guide. I imagine its difficult to get the
balance right between providing all the information you could
possibly require, verses the need to make it actually readable! I was
impressed on how good a job the documenters had done producing a
relatively concise guide covering a lot of detail (32 pages if
printed compared to Gentoo’s 113!). Perhaps they were lucky in being
able to expect a high level of competency from their readers. The
guide could be even shorter as in my opinion the introduction to
compiling your own packages using the Arch Build System doesn’t
really need to be included with installation material. This could
easily be made into a separate document.
The forums are very good. At the time of writing there are almost
2800 registered users who have read/contributed to some 58,000
articles. The groups are divided into 4 main sections: General
for security advisories, announcements and off-topic discussions;
Arch Linux section has the typical boards for installation,
Arch Linux general discussion, desktop environments, etc; A Pacman
section for boards discussing how to make packages, package requests,
etc; and finally a general GNU/Linux section for general
Linux discussion. I must admit, I think the boards could be tweaked a
bit, for example I have already made a request for a multimedia board
since non-hardware related sound/video issues are scattered around in
Installation or Workstation User boards – whatever that means.
That aside, the forums are now well packed with a wealth of
information which should answer most questions already.
There is an additional wiki
which I used frequently during the post-install period as it provides
lots of handy guides on how to get most aspects of your system up and
running, such as X, window managers, sound, compiling your own
kernel, etc. There is a general discussion mailing-list, which is
archived. There are ArchLinux channels on IRC (in 4 languages) and
finally a weekly newsletter to keep you up-to-date with the latest
When I started using Linux I initially found it difficult. The
only way to become knowledgeable was to study the man pages, but the
only way you could understand them was to be knowledgeable! And
perhaps this ‘chicken or egg’ situation arises here with ArchLinux
(and any distro that expects experienced users).
One thing I think ArchLinux needs to do is spend a bit of time
defining what they mean by a “competent linux user”. I
would not consider myself as such, but do I become competent by
starting off with Linspire, then Knoppix, then Suse and slowly keep
graduating towards more ‘serious’ distributions? Or do you just jump
in to the deep end, and get straight on with learning about
partitioning, bootloaders and kernels?
It’s at this point that I find myself confused as to whether I
wholeheartedly support the ArchWay.
Let me first start by saying that I do admire ArchLinux. It’s not
trying to be the perfect distro that appeals to everyone. It’s not
trying to be the #1 most popular system. It is the result of a
dedicated team working from scratch to make their ideal
Yet, ArchLinux will always have a get-out clause should users ever
have difficulties/issues, e.g., automatic upgrading of kernels. The
competence prerequisite means that users have to deal with it
themselves, because they’re competent, right? I think I’d be happier
if the ArchWay was (openly) a little more encouraging towards helping
novice users become “competent”, rather than the less
appealing ‘come back when you’re more experienced’ vibe that it still
So after that install-athon, what is ArchLinux like to use? And is
it worth all the hassle? Well, from my experience, ArchLinux is
fantastic! It’s streamlined, it’s fast and it’s robust. If you think
about it, most Linux distros are essentially the same core
components/libraries/tools and applications. What differentiates
distros is how easy it is to get those bits onto your hardware, and
then how to maintain and extend your system from then on. And it’s
the latter where ArchLinux exceeds. Installing new packages is a
doddle and takes very little time.
Naturally, the ArchLinux system install will be off-putting to
those new to Linux. But, in many respects, despite using Linux for
many years, until I took the plunge with Gentoo last year, I was new
to installing Linux without the safety net of a GUI installer doing
most of the leg-work. I personally found it not to be too difficult
at all – providing you follow the documentation. The likes of
Fedora/Suse/Xandros are always working towards making Linux simpler,
(which is not a bad thing) but it’s very unlikely that a similar
trend will grip ArchLinux development. It’s not anti-GUI per se,
merely anti- anything that takes too much control away from the user,
and I dare say that this will be their philosophy for a long time.
At the end of the day, the ArchLinux developers have produced a
system that I really enjoy. It all works! The package management is
simple yet effective. The community is friendly and knowledgeable. I
do hope to learn more about Linux and I like that ArchLinux
effectively forces me to learn.
About the author
Andrew Roberts is a computer science graduate from the University of Leeds, UK. He remained at Leeds to study further towards a PhD in Natural Language Processing. He has been using Linux for almost 8 years.
If you would like to see your thoughts or experiences with technology published, please consider writing an article for OSNews.