$ sudo apt-get install libmysqlclient-dev

The package also requires setuptools, which is available here. Download it (I’m running Python 2.6.5, so I downloaded setuptools-0.6c11-py2.6.egg) and run it as a shell script.

$ sh ~/Downloads/setuptools-0.6c11-py2.6.egg 

A second error — i.e. gcc could not find python.h — was resolved by installing the Python development package.

$ sudo apt-get install python-dev

Back to it …

> install.packages(c('Rcompression', 'XML'))
> install.packages(c('ROOXML', 'RExcelXML'), repos = 'http://www.omegahat.org/R', type = 'source')

Back to the grind …

C:\Documents and Settings\All Users\Application Data\Microsoft\PlayReady\mspr.hds

I was back to cackling irreverently at Archer in no time.

So, I installed VirtualBox OSE from the Lucid repo (a few versions behind current, but no worries) and installed my XP Pro SP3 image on a small virtual hard disk. It took entirely too long, although I had shortcut the process by ripping the CD to my hard disk using dd (+1 for GNU!):

$ dd if=/dev/cdrom of=~/home/captivus/win_xp.iso

(Seriously … dd is bloody brilliant. One of the most useful tools in the GNU suite.) Anyway, it works like a charm and I’m not without my new love, Archer, despite no longer running Windows.

Yesterday I finally made the move to upgrade to Lucid LTS on one of my servers on my home network. The automatic upgrade apps downloaded and executed without a hitch, so I was optimistic upon reboot. For reasons which surpass understanding, however, I received an error indicating that the hard disk upon which I had installed the OS refused to mount at boot time — although, to Lucid’s credit, I was given an option to skip this mounting and continue with the boot.

The whole episode was absurd, as the disk was clearly mounted and booting — how else was the OS loading at all if the disk upon which it resides would not boot? Upon logging in, a quick cat /var/log/boot.log suggested that there was, indeed, an error in mounting /dev/sda1. cat /etc/fstab made clear what the problem was — somehow there were additional entries in the fstab file which tried to mount the partitions on /dev/sda subsequent to their initial mounting. I’ve not the slightest idea how these entries made their way into the file. I am, however, confident that they were not there prior to the upgrade as this error was entirely new. A few keystrokes in vim and I had commented-out the offending entries. Upon reboot, all was well with the server.

Most perplexing …

The solution to my predicament? Sun’s brilliant VirtualBox open source virtualization package running the latest Ubuntu release — currently 9.04 (or “Jaunty Jackelope,” as they call it). The installation of VirtualBox took a bit on my lappy, but it went fairly seamlessly. The only hitch was that the installation of the VirtualBox Host-Only Network adapter in Windows XP SP3 broke my wireless networking. (It may well have broken all networking, but I didn’t try plugging a cable in to check.) The solution to this was fairly simple — disable the newly installed adapter! It seems that VirtualBox doesn’t need this adapter enabled in order to provide the virtual OS networking. (I’ve no idea what this adapter is used for at the moment. Perhaps I’ll figure this out as I work with VBox a bit more.)

The only Ubuntu image I had lying around was a Hardy (8.04) disc I burned some time ago. I added a new machine to VBox, installed Ubuntu from the disc, updated to Jaunty using apt, and installed Skype from the Medibuntu repository. So, I’ve got a virtual Jaunty up and running and, I must say, it is bloody fantastic! Good show, Sun!

Previously, I have endured spectacular failure when trying to flash version 8 devices. <The sound of bricks dropping rings out in the distance.> (My devices are all version 2. The Wikipedia article I linked to above explains the differences in the hardware versions.) It turns out, the critical misunderstanding I had related to flashing the stock firmware with vxWorksKiller (prior to transferring the DD-WRT image to the router via TFTP). I did not realize that the upload of vxWorksKiller needed to be done from a special management screen that is only accessible after unplugging the router, holding down the reset button while plugging the router back in, and continuing to hold the reset button for 20 seconds. This implies that the upload should not be done from the default firmware’s upgrade page. This understanding was gained this week when building a PC, and flashing two routers, for a friend of mine.

Given that the preponderance of WRT54Gs on shelves now are version 8.x, this realization bodes well for me in future purchases.

bash$ ulimit -c 100

In this case I have enabled core dumps and given them a limit of 100 blocks. Problem solved! Hopefully this makes it into the search engines and helps someone else frustrated by this same issue.

I read the knowledgebase article at HostGator Support on setting up addon domains which warns at the top of the article:

“Before you can add an addon domain you must change the name servers for the domain name to the ones provided for your hosting account. You cannot create an addon domain if your DNS for the site you are trying to add hasn’t propagated yet.”

I was exact in following these instructions and waited 3 days for the DNS changes I had made at GoDaddy (where I purchased and manage the domains) to propagate. Ultimately, they did not.

The solution to the problem was to setup the addon domain at HostGator, via the cPanel, immediately after making the DNS changes to the domain. I’m not sure if this is an issue unique to GoDaddy domains — I imagine it is not. It seems that the documentation provided by HostGator is inaccurate in this regard.

I typically wash scratched or otherwise unreadable DVDs or CDs in warm, soapy water and then dry them with a soft, non-abrasive cloth. Discs which are not readable after this washing can be repaired in another manner. Scratched — even significantly scratched — DVDs and CDs can be “repaired” by rubbing conditioner into the surface of the data-side of the disc. I met success in this endeavor by pouring conditioner liberally onto the surface of the DVD — I used a blob roughly the size of a quarter — and then rubbing it all over the surface until most of it disappeared. There was some residual conditioner left on the disc so I wiped it off with a tissue, being careful to not leave tissue particles behind.

The DVD was really in bad shape when I got it — the movie hardly played at all — but I managed to play through the entire movie with only a few skips after the conditioner-fix.

I’m certainly open to hearing other methods of fixing scratches on optical discs!

(Note: Before following the procedures outlined below, I had downloaded a tested driver — as per the ndiswrapper wiki — for the Dell Truemobile 1300 MPCI card. The recommended driver can be found here.)

(Additional note: This process was followed in Fedora Core 6 — I can only vouch for it working in this environment, although I imagine it will work in most distributions.)

Solution 1: bcm43xx-fwcutter
Today I found a fantastic little program called bcm43xx-fwcutter. In essence, it extracts the driver from the Windows driver file, and incorporates it into Linux’ native support for the bcm43xx controller. After finding this gem, the entire process — including download and installation — took about 5 minutes.

Here is what I did:

1.) Download bcm43xx-fwcutter from BerliOS.de. (Note: be sure to get the correct file for your version of the controller!)

2.) Unarchive and compile the tool:
tar -xvf bcm43xx-fwcutter-006.tar.bz2
cd ./bcm43xx-fwcutter-006
make

3.) Run the tool to extract the driver from the Windows driver file and install it in Linux:
bcm43xx-fwcutter -w /lib/firmware bcmwl5.sys

4.) Remove the bcm43xx module from the kernel then add it back with the new driver:
rmmod bcm43xx
modprobe bcm43xx

5.) Configure the wireless card (substituting your interface name where appropriate):
iwlist eth1 scan
iwconfig eth1 essid (SSID here)
iwconfig eth1 key restricted (WEP key here)
dhclient eth1

Voila! It was a truly effortless process after having extracted the driver using bcm43xx-fwcutter. My hat goes off to the developers — you lot have truly made Linux life much easier for owners of BCM43xx controller-based wireless cards!

Drawback to solution 1: The bcm43xx driver — the driver used in the process above — will limit the wireless card to 11mbps. GRRR!!

Solution 2: ndiswrapper
Ndiswrapper — available at SourceForge here — is a linux-based wrapper for Windows wireless card drivers. To quote the project page, “Some vendors do not release specifications of the hardware or provide a Linux driver for their wireless network cards. This project implements Windows kernel API and NDIS (Network Driver Interface Specification) API within Linux kernel. A Windows driver for wireless network card is then linked to this implementation so that the driver runs natively, as though it is in Windows, without binary emulation.”

Ndiswrapper can be a bit of a pain to implement, but I have managed to pare down the myriad instructions I found in various forums into several easy-to-follow steps.

1.) Download ndiswrapper from its SourceForge project page. (As of this posting, the current version is 1.37)

2.) Unarchive and compile ndiswrapper:
tar -zxvf ndiswrapper-1.37.tar.gz
cd ./ndiswrapper-1.37
make distclean
make
(As root) make install

3.) Ensure that the native bcm43xx driver is unloaded and add it to the module blacklist:
rmmod bcm43xx
vi /etc/modprobe.d/blacklist
Add a line: blacklist bcm43xx

4.) Install the Windows driver:
ndiswrapper -i bcmwl5.inf

5.) Run depmod and ensure that there are no errors:
depmod -a

6.) Add the ndiswrapper module to the kernel:
modprobe ndiswrapper

7.) Configure the wireless adapter (substituting your interface name where appropriate):
iwlist eth1 scan
iwconfig eth1 essid (SSID here)
iwconfig eth1 key restricted (WEP key here)
dhclient eth1

8.) Finally, to prevent having to reconfigure the card the next time I reboot, I edit /etc/sysconfig/network-scripts/ifcfg-eth1 and add the following configuration strings:
ESSID=(your SSID here)
KEY=(your WEP key here)

Additionally, add the following line to /etc/modprobe.conf:
options ndiswrapper if_name=eth1
alias eth1 ndiswrapper

Ndiswrapper is a much better solution for operating BCM43xx controller-based wireless cards in Linux, in my opinion. This is largely due to the wrapper’s ability to enable 802.11g (i.e. 54mbps) transfer rates for the card. The bcm43xx driver limits the card to 802.11b rates (i.e. <= 11mbps). (Note: Because ndiswrapper creates a kernel module, if you upgrade your kernel you will have to rebuild the module for the new kernel. Just recompile ndiswrapper and reinsert the kernel module.)

There it is! I hope that my documentation of this process will help others who find themselves in a similar bind.