This page was written to provide some help to people who're looking for a high quality modern PC (date: end of 2002) which will run well under Linux. It is written primarily for people who, like me, have worked with Unix systems for quite a while but don't have experience with PC hardware. I did it, and so can you.
Having used RISC OS exclusively at home for many years, I recently decided it really was time to get a Unix machine and some serious processing power at home -- not to replace the RiscPC, but just to be able to do all the things the RiscPC is too weak for: fast compilers and development tools, efficient handling of large volumes of data and, of course, mindless fun like MAME. Since I hate Microsoft's guts, it was clear from the beginning that whatever PC I'll buy would have to come without any MS software preinstalled and would end up with some Unix variant as OS. Initially I wanted to go for BSD exclusively, but the driver situation is worse than it is on Linux and since I wanted to get reasonably modern hardware I decided in favour of Linux after all. Since I'm a traditionalist, however, only one choice was possible: Debian.
Now for the biggest problem: which hardware to get. Of course you could just buy one of those PCs you can get practically anywhere these days, but do you really want that? The vast majority of these PCs are optimized for the usual three figures even the computer-illiterate can understand: MHz of the CPU, amount of main memory and hard disk space. The rest is typically pure garbage, though; and comes with Windows pre-installed, so totally out of the question for me. Unfortunately it's gotten pretty hard to get anything out of the ordinary these days, and since I wanted a PC that was powerful, reasonably silent and didn't come bundled with any Redmond bloatware, we're talking much out of the ordinary here. And since the hardware had to work well with Linux, where you have to take care of all the tedious driver problems yourself, things were getting extremely tricky. It looked like I had to build my own system from scratch.
What kind of PC did I want? A powerful, silent one; this is like saying you'd like something huge, yet light, so you'll have to compromise to a certain extent, but not as much as you'd expect provided you choose quality components and aren't afraid to pay the extra 100 Euro here and there for the privilege. The CPU was easy: an up-to-date AMD Athlon, which at the time of writing was the XP2200+. The CPU cooler was harder; initially I decided on the Alpha PAL 8045T, then I had a look at some allegedly better alternatives presented in C't magazine and in the end (and after some hardware website reviews) I decided the Alpha PAL was the better choice anyway. As far as the graphics card went, I wanted a GeForce 4 Ti card in anticipation of Doom III. Sure, ATI have open source drivers whereas NVidia are constantly accused of keeping drivers proprietary, but if you look around a little you'll see that by and large the ATI drivers just aren't up to par quality-wise with the NVidia ones, so a GeForce it was. The rest of the core components was tricky, though. In particular choosing the motherboard turned out to be quite a task, since there's little alternative to VIA if you want an Athlon system, but VIA chipsets have had some serious bugs in the past, e.g. the KT133 had PCI bugs that could actually cause data corruption; other Athlon boards were reported to be downright unstable. Bad Karma! Another thing is that when choosing the Alpha PAL cooler you also need a motherboard that has holes around the CPU socket because the Alpha PAL is screwed onto the board rather than being clipped on it. I wanted a KT333 chipset, so after looking around I initially coveted the GigaByte GA-7VRXP, but by the time I was ready to buy the PC, that board was no longer available from the dealer I wanted to buy all components from; it was replaced by the GA-7VAXP (a KT400 board), which lacked the holes for the CPU cooler, though. Back to the drawing board...
After some more brainstorming and searching on the net, also pondering KT400 boards despite the higher likelihood of driver problems for these brand new boards, I decided the Asus A7V333 was the one for me, also because it has a passive heatsink on the northbridge (i.e. less noise and one less component to worry about dying). Another question was the case and its fans, where I considered Chieftek or Thermaltake (the Thermaltake Xaser was attractive because it already came with silent fans pre-installed). Frankly, I had no idea what influence exactly the case would have on noise and stability (due to cooling) of the system, so I decided I'd rather spend a little more on a good case than take a risk. The peripherals were quite straightforward for a change and just when I was about to order the components and build my first PC from the ground up, I came across HIQ Computer (german dealer, sorry in case you're from abroad).
HIQ Computer sold a system very similar to what I wanted to build, for less than the components would have cost me, without any OS, and best of all: allowing modifications at the price difference of the components being swapped. We're talking their Black Thunder XP2200+ model. I asked for the changes I wanted and got them with no fuss, so here's the machine I ended up with (and which is currently sitting smugly under my desk and so far turned out to be exactly what I wanted):
This system cost 1330 Euro at the time of writing. This is somewhat more than you'll pay for a standard PC, especially considering that it doesn't include an OS yet, but given the quality of the components this is a perfectly reasonable price and you have to be prepared to pay it if you want something that is noticeably better than the average department store crap. In addition, I got from other sources an IBM Buckling Spring keyboard 42H1292 with US Layout and a Logitech Pilot Mouse (no wheel, one of the last real 3 button mice). I share the monitor with my RiscPC: the Belinea 106080 is a very nice 19" monitor with a completely flat Diamondtron tube and scan rates of 30-110kHz horizontally and 50-160Hz vertically. I think that pretty much covers the hardware. For the impatient: that hardware works fine on Linux as far as I can tell so far and you needn't be concerned buying a system like this. There are some pitfalls when installing Linux drivers for the various peripherals, though, which will be covered in the next section.
So I had this shining new PC sitting in front of me, a set of Debian 3.0 CDs from Lin24 and a free weekend -- let the games begin. First I read through the Debian installation guide that came on the first CD and made notes about important system parameters and also decided on a partitioning scheme to use. Then I opened the case and had a look whether everything was still in place after the transport. I strongly advise doing this, in particular regarding the CPU cooler. The Alpha PAL has the big advantage of being screwed onto the motherboard, so it's highly unlikely it'll come lose during transport, but I wouldn't be so sure with clipped coolers and if the CPU cooler doesn't fit tightly you can kiss your CPU goodbye in no time. In my case everything was OK, so I just switched this baby on and browsed through the BIOS settings. Short of the current date and time I didn't have to change anything, not even boot order. So I put in the first Debian CD and rebooted.
Debian booted OK right away and asked me to partition the hard disk. This confused me at first, because the harddisk was already formatted to FAT32 and I couldn't create any new partitions. OK, delete the FAT partition, there won't ever be a Windows on this machine anyway, then create a large primary partition. Wrong again, although extended partitions are logically part of the primary partition, this doesn't mean the primary partition has to be large enough to hold the extended partitions. So the next try finally got me the partitioning I wanted: 8GB root (primary partition), 1GB Swap, 10GB opt, 45GB home and the remaining 16GB I reserved for OpenBSD (all partitions but root extended). I used ext3 on all save the Swap and the OpenBSD partitions -- not because I had to have a journaling FS but because I read somewhere that ext2 partitions larger than 6GB mean trouble. Looking back, an additional small boot partition (50-100MB) of ext2 probably wouldn't have hurt, but all in all I'm happy with the partitioning I did. If I had done a predominantly multiuser server, I would have spent more time on the partitioning and added more partitions (in particular separate partitions for mail etc), but I intended this as a desktop machine and the partitioning is good enough for that.
Installing the rest is pretty much self-explanatory. Sometimes you have list boxes where neither Return nor Space will let you proceed to the next screen; use F12 in this case (I don't think this is documented clear enough anywhere). I installed the bf2.4 kernel, which in hindsight probably wasn't the smartest thing to do, but I lacked decent documentation on what the exact difference between the four kernel images was, and since I wanted a 2.4 kernel I chose the one that looked most like one ;-). Looking back I'd advise you to use the vanilla kernel, although the standard kernel didn't stay long on my machine anyway because I just couldn't get the XFree86 drivers to work with it. Which brings us to the first reboot off the newly installed root partition.
This went well until Linux tried starting up X complaining that the NV driver couldn't detect any devices -- not particularily surprising considering the NV driver I had chosen in the XFree86 configuration only supports graphics cards up to GeoForce 3, whereas I have a GeForce 4 in my machine. OK, so I downloaded the latest tarballs from NVidia's driver site and tried installing them. This failed, unfortunately, due to missing symbols in the resulting NVdriver module. I neither managed to use the frame buffer device (fbdev) for X11, which complained about not supporting planes or something along those lines. After looking around on the web a little, all sources suggested compiling my own kernel and continuing from there. Oh great, I had planned to postpone that for a while and now I had to do it without even having started up X11 for the first time.
So I took a deep breath, read the short kernel compiling chapter in the Debian installation guide, installed the kernel source archive with apt-get install kernel-source (it'll end up as tar.gz archive in /usr/src; unpack it using something like gunzip -c kernel.tar.gz | tar fx -) and started configuring my kernel by going over each and every option (using make menuconfig; remember to install ncurses first). If you know your basics and read the help text whenever you're not entirely sure, you should manage to configure everything without problems, it just takes a long time to deal with everything. Just remember to you compile the filing systems you're going to boot from into the kernel (no modules). I'll have more to say on kernel builds below, but for now I configured the kernel to the best of my knowledge back then. Next you should make sure the source tree is clean by typing make-kpkg clean, then you can build the kernel package with make-kpkg --revision=custom1.0 --append-to-version=x kernel_image modules_image. The revision is basically a sub-version number of your kernel build and should be incremented with every new build you plan to install. --append-to-version=x should be used when you're compiling the same kernel version you already have installed; in this case, the string x will be appended to the kernel image version number (e.g. "2.4.18foobar"), which will prevent the modules of the installed version from being overwritten. Note that you need the correct rights for compiling. The simple but ugly (IMHO) way is to prefix the above command line with fakeroot; the more elegant one is to add your regular user to the group src by typing (as root) adduser login src (and logging in again with the user to activate the new group membership). This allows you to compile the kernel, but unfortunately not build the kernel and module images, so you'll still need fakeroot for that (make sure you use the same parameters for --revision and --append-to-version); but at least the compile job works as regular user. Once that is done you should have the kernel package in /usr/src and a package for each module found under /usr/src/modules at the time of compiling the kernel modules. Note that the modules you configured in the kernel itself will be part of the kernel image, only the stuff under /usr/src/modules will end up in separate packages. Now for the moment of truth: install the kernel with dpkg -i kernel-package and read carefully what you see on screen. Leave the modules alone for now, just reboot the system (shutdown -r now) with the new kernel. This should work and now you can install the modules packages using dpkg -i module-package.
With this new kernel, the NVidia archives (kernel and GLX driver) installed fine right away. So just do a modprobe NVdriver (for driver version 3123), followed by startx and you should finally get a working X11 environment. You'll want to automate this procedure, however, so you have to tell the system when to load the NVidia driver module. On most Linux distributions you'll have to add the corresponding commands to the file /etc/modules.conf, but on Debian this is done a little differently: the directory /etc/modutils contains files whose contents will be concatenated to /etc/modules.conf with the command update-modules. This allows you to keep the configurations for unrelated modules in separate files. For the NVidia driver, you just write the line
alias char-major-195 NVdriver (for driver version 3123)
respectively
alias char-major-195 nvidia (for driver version 4191)
to /etc/modutils/nvidia and do update-modules, which will ensure that the driver is loaded whenever the graphics card (= char-major-195) is accessed. You could try rebooting the system now and it should automatically start the display manager login screen after the boot has finished. In case things go wrong, remember that modprobe drivername followed by startx should allow you to start the X server manually.
Now for OpenGL (the GLX package which you also downloaded from NVidia's website): the package should compile and install OK, but you may not have the links set correctly the first time around. Go to /usr/lib and do ls -l libGL* which should show you amongst other things the libs you just installed (check the libraries' version numbers and date stamps if you're not sure which are the new ones). Make sure the symbolic links with the same base name as your new libs (e.g. libGL.so) point to these newly installed libraries or you'll use the slow software emulation which certainly is not why you got a shiny GeForce 4 Ti card. Note that since NVidia's driver package doesn't conform to Debian package rules, your libraries may get overwritten in case you install other OpenGL components. This can be a bit annoying, but it only happens very rarely and will drop in frequency as you'll install a lot less components as your system approaches perfection. Just remember to look at the symbolic links mentioned above if Quake runs unbearably slowly all of a sudden.
One more note to developers (this includes compiling packages requiring OpenGL yourself): NVidia's drivers also come with up-to-date OpenGL include files which you should also install, because the ones that come with Debian 3.0 (or rather the XFree86 version it ships with) are pretty old (1.1, IIRC) and won't be any good even for something simple like MAME's OpenGL backend. I wrote a small script that makes sure that the correct GL libraries and includes are referenced via symbolic links, which you can download here. Note that you have to call this script with the driver version as the first parameter (e.g. ensure-nvidia 3123).
So now I had X11 working, a big step forward since this allowed me to work comfortably with the machine, in particular handling documentation in formats other than plain text. The downside, of course, is that the drivers for the ethernet and sound cards as well as the CD Burner still had to be done. Since you often have to download drivers for newer hardware directly from the internet, it is imperative to get the network running first (I have DSL, so the ethernet card is not only for my small LAN, but also my gateway to the internet). Unfortunately I had no idea what model it was (didn't show up on the invoice nor HIQ's webpage), so I removed it from the case and checked: D-Link DFE-530TX, and a little searching on the net revealed that I needed the VIA Rhine driver for this card (be careful, though: D-Link also have cards named DE-530TX and DFE-530TX+, and all three of them need different drivers). So this basically called for the next kernel build. Note that if you just increment the revision number, installing the new kernel package will overwrite the old kernel's modules, which is extremely dangerous in case the new kernel doesn't work. dkpg warns you about this and you should move the old modules in /lib/modules/version out of the way before proceeding with the installation of the new package, e.g. by appending the revision number to this directory's name. Back to the ethernet card: you can configure it by installing the package etherconf; if this package is already installed and you want to change the settings, use dpkg-reconfigure etherconf. You can also toy around with the settings manually: the commands ifconfig eth0 192.168.32.10; route add -net 0.0.0.0 gw 192.168.32.1 will configure your machine to the IP address 192.168.32.10 and tell it to use 192.168.32.1 as gateway for all external addresses.
Now for the big one: sound. This one nearly drove me nuts, I just couldn't get it to work for ages. Looking around on the net I found I needed the emu10k1 emulation for a Soundblaster Live card; someone suggested I should use Alsa, so I installed the corresponding module source (version 0.5 came with the Debian 3.0 distribution) and built the kernel modules. I just couldn't get anything to work that way, though, so I looked for a simpler solution first. You can find an introduction to Soundblaster Live drivers on Linux here, so I did as suggested and downloaded the latest emu10k1 driver from the sourceforge link on this page, configured the kernel with emu10k1 emulation as module (so I could replace the kernel module with the more up-to-date sourceforge version) and made a new kernel. The emu10k1 driver module loaded successfully, but I still couldn't get it to work, I always got device errors. Looking around the net some more, I found several people suggesting to try whether sound worked as root, so I did that and much to my surprise found out that the device errors were gone when playing sound as root. After some fiddling around with the sound jacks on my machine (3 sets: front panel, motherboard panel, soundcard panel) I found out which one to plug into and lo and behold, there was sound. A quick look at the sound devices in /dev/dsp* also revealed why there were device errors as normal user: these devices are by default only writable by root or the audio group. I wasn't used to this, but it definitely makes sense, as that way you can easily set any regular user's rights via the groups he belongs to. So the best way to get sound as a regular user is not to change the access rights of the sound devices, but simply add the regular user to the audio group by typing (as root) adduser login audio. While you're at it: it is very likely that you'll also want most regular users in the floppy and cdrom groups, so repeat this command for these groups, then log out and back in with your regular account to activate the group settings. You will find that now sound works as regular user, and also the floppy mysteriously doesn't require root to function any more either. Groovy -- but still no Alsa. Never mind, rejoice in having sound at all and see what this machine can do with MAME. Wow! Compiling the entire 0.56 source code in 8:30 minutes already hinted at great things to come, and believe me this thing really delivers the goods. Uncanny!
But what about Alsa? Well, I downloaded the latest version from Debian's package server, which is version 0.9, and compiled and installed this (again use the emu10k1 driver). This still didn't work, however, I always got errors about bad parm_snd* parameters when trying to install the modules. Hunting for some answers on the net, I finally learned that this is due to me using an old alsa config file (the only alsaconf package currently available for Debian appears to be for version 0.5) and some of the module names changed. So remove the snd_ prefix from all parameters and try to modprobe one of the alsa driver modules, removing any parameters still unknown after this procedure until you don't get errors anymore. Here's my /etc/modutils/alsa config file for Alsa 0.9:
alias char-major-116 snd
alias snd-card-0 snd-emu10k1
alias char-major-14 soundcore
alias sound-slot-0 snd-card-0
alias sound-service-0-0 snd-mixer-oss
alias sound-service-0-1 snd-seq-oss
alias sound-service-0-3 snd-pcm-oss
alias sound-service-0-8 snd-seq-oss
alias sound-service-0-12 snd-pcm-oss
options snd major=116 cards_limit=1 device_mode=0660 device_gid=29 device_uid=0
options snd-emu10k1 index=0 id=CARD_0
There's just one problem: still no sound. That's easy to fix, though: start up alsamixer and increase the volume for all channels and make sure the channels aren't muted (a muted channel is shown with mm at the top, you can toggle it by pressing the m key). Once that is taken care of you should finally have sound with Alsa. Another hurdle taken, leaving basically only the CD-Burner.
With video, network and sound taken care of, this just left the CD burner. In order to use ATAPI CD writers under Linux, you must have ide-scsi emulation enabled in the kernel. This encompasses various settings in you kernel config, which you should read up in the CD-Writing HOWTO under /usr/share/doc/HOWTO/CD-Writing*, section 2.1.3 (in version 2.9.3 of this document). Note that one side-effect of this is that your CD-Writer (which you probably used as a regular CD-ROM drive so far) can no longer be accessed via IDE but via SCSI-emulation only. You should turn as many drivers as possible into modules to facilitate updates later on; putting ide-scsi into a module also has the advantage that you don't have to tell LILO that IDE should ignore your CD-Writer. Also take care you enable the loop device in your kernel, since that will allow you to mount CD images created with mkisofs for testing (i.e. you can navigate and read the image file like you would the final CD). After building and installing the new kernel, make sure the symbolic link /dev/cdrom points to your SCSI device (typically /dev/scd0) rather than the IDE device it's physically connected to (e.g. /dev/hdc0); also take care the ide-scsi module handling is added to /etc/modutils; if your CD-Writer is device hdc, you need something like this in /etc/modules.conf:
options ide-cd ignore=hdc
alias scd0 sr_mod
pre-install sg modprobe ide-scsi
pre-install sr_mod modprobe ide-scsi
pre-install ide-scsi modprobe ide-cd
Unfortunately, on my machine this wasn't enough to automatically load the required ide-scsi modules, I had to do modprobe ide-scsi manually, then everything worked fine. Solution: add ide-scsi to /etc/modules, which will load the module while booting, so the CD-Writer can be accessed without having to do another modprobe.
Now everything should work as far as the CD-Writer goes. Note that some programs (e.g. cdrecord) can only be used by root by default, but this can be overcome by installing these programs with superuser ID, as described in the CD-Writing HOWTO (section 4.22):
chown root.root /usr/bin/cdrecord
chmod 4111 /usr/bin/cdrecord
The preferred solution is using sudo, however, first because of security and second because real time scheduling mode can't be activated for cdrecord with the superuser ID. Essentially, you define a sudo group of users which are allowed to burn CDs on your system in /etc/sudoers and allow these to run cdrecord (and maybe some other tools) as root. Consult the sudo manual pages on how exactly to do this.
You should not try to make your /dev/sg* files writable for any user, since that may allow just about anyone screwing around with not just your CD-Writer but your SCSI-card and all devices connected to it (provided you have one; if you have a pure IDE system, the worst that can happen as far as I can see is someone screwing up your CD-Writer, but I can give no guarantees). If your rights are OK, cdrecord -scanbus should list your CD-Writer, typically as 0,0,0. If this works, decide what to burn to test the writer, or just do a simulation to check whether everything works. Here are some useful command line programs for reading and writing CDs:
Naturally, there are also GUI applications for burning CDs, all of which are frontends to one or more of the programs above. So far I only tried xcdroast and truly hated it! As far as I'm concerned, the command line tools are easier to understand and far more efficient than this monstrosity. If I find an app I really like, I'll post it here, but for the time being I'll stick to the command line.
You can download my latest kernel configuration file here.