The RocketRaid 1740 (rr174x) is a  4-channel PCI to Serial ATA II RAID controller, which according to the documentation is "ideal for small business home and office servers, NAS storage, workgroup and web servers". In this case it is being used in a generic PC to create and manage a RAID5 array of 4 1TB disks for a simple data storage facility.

The 174x (and other HighPoint products) have good and well-documented driver support for a range of operating systems including diverse Linux distributions and FreeBSD, see here for details:

http://www.highpoint-tech.com/BIOS_Driver/page/rr1740.htm

It appears the most reliable way to install the driver is to use the "Open Source Driver" provided at the bottom of the drivers page. Follow a fresh installation the following packages need to be installed to do this:

• gcc
• make
• linux-headers-$(uname -r)

Download the .tgz file to a suitable directory, and in the directory product/rr1740pm/linux/ execute "make install". (No need for a prior "make").

Following a reboot the rr174x kernel module should be successfully installed and issuing dmesg | grep rr174x  should produce output like this:

[   27.757987] rr174x: module license 'Proprietary' taints kernel.
[   27.766618] rr174x:RocketRAID 174x controller driver v2.4 (Nov 28 2009 17:49:58)
[   27.766694] rr174x:adapter at PCI 2:4:0, IRQ 18
[   28.342352] rr174x:start channel [0,0]
[   28.343802] rr174x:start channel [0,1]
[   28.345248] rr174x:start channel [0,2]
[   28.346694] rr174x:start channel [0,3]
[   28.556067] rr174x:[0 0] Start channel soft reset.
[   28.556094] rr174x:[0 1] Start channel soft reset.
[   28.556115] rr174x:[0 2] Start channel soft reset.
[   28.556134] rr174x:[0 3] Start channel soft reset.
[   28.956572] rr174x:channel [0,0] started successfully
[   29.088461] rr174x:channel [0,1] started successfully
[   29.210253] rr174x:channel [0,2] started successfully
[   29.322073] rr174x:channel [0,3] started successfully
[   29.416168] scsi2 : rr174x

Update: this works in exactly the same way in Ubuntu 10.4 LTS, so presumably all recent Ubuntu versions, and probably most recent Linux distributions.

When it comes to the great vi versus Emacs debate, I am firmly on both sides of the fence, using vi (or vim) for smaller, command-line based editing tasks (particularly when working on remote servers); and Emacs for software development. Unfortunately, the default Emacs installation in Linux is, to put it mildly, butt-ugly:

(Click for full-sized version... it doesn't look quite so bad when scaled down).

Playing around with the standard font selection settings doesn't help much as the standard Emacs package does not support antialiased fonts in Linux (or more precisely X.org). However since version 23.1 XFT is supported, albeit experimentially, which provides much nicer font display:

In Ubuntu the package emacs-snapshot provides antialiased font support and seems to work without any problems.

More details on XFT-enabled Emacs are here: http://www.emacswiki.org/emacs/XftGnuEmacs

Over the last couple of years I've been leading a somewhat itinerant lifestyle and have been mainly relying on products from the House of Jobs for my UNIXoid computing needs. Consequently I haven't been keeping up with the latest developments in desktop Linux, and having just had the opportunity to set up a brand-new PC with Xubuntu, I'm suffering a little bit of culture shock: for some reason everything "just worked". It basically installed itself with no manual editing of configuration files necessary.

However, in Xubuntu there doesn't seem to be a simple, mouse-based way of mapping the goddam awful CAPSLOCK key to CTRL. No problem, I thought. Just let me get at /etc/X11/XF86Config /etc/X11/xorg.conf with a handy text editor, just like in the good old days. Weird. Not much in there, is there? A bit of poking around online reveals that HAL appears to have taken over, and my PC is trying to eject me from the pod bays into the vacuum of space. No, scratch that, HAL stands for "Hardware Abstraction Layer" and is something nifty which takes care of the nasty business of different sorts of hardware devices being plugged in. It also provides the capability to create XML configuration files modifying the behaviour of attached devices, such as the keyboard. The place to do this is in the directory /etc/hal/fdi/policy/ and the file can have any name, provided it ends in .fdi. 

For setting the caps lock key to CTRL the following appears to work:

X.org needs to be restarted for the configuration to take effect. (Some sources indicated restarting the hal daemon will cause the new settings to be registered, but this didn't work for me.)

Note that HAL is scheduled for replacement (which might explain repeated "I can't let you do that, Dave" entries in /var/log/messages) by something called DeviceKit, which will be even niftier (though quite possibly requiring a totally different style of configuration.

I recently purchased an HP 2133 mini-notebook, and while it's quite a nice piece of equipment it does have some annoyances. One of which is the Synaptics touchpad, which appears to simulate a left-click of the mouse if the cursor hovers over certain GUI elements for more than a second or two - this makes working without a proper mouse a right royal pain in the posterior. This appears to be the default hardware behaviour, as the same thing happened in the pre-installed Windows Vista.

After some trawling through Google it appears the solution is to add the following line to the relevant InputDevice section of xorg.conf:

    Option "TapButton1" "0" 

After restarting X this seems to solve the problem.

Useful options for dpkg and co, the package management system used by Debian and derivatives such as Ubuntu:

• List all installed packages: dpkg -l
• List files contained in a particular package: dpkg -L package-name

Some relatives, for whom I provide email aliases fromone of my domains, have been complaining about increasing amounts of spam. Well, don't we all. Unfortunately the relatives in question live in a sort of telecommunicational black hole which apparently has at least some telephone wires made from aluminium and which date from the immediate post-war period (Second World War, that is). DSL won't be available until the whole village is rewired, and even dialup can't max out a 56k modem. Understandably even a few spams make email access a torture.