Update: The USBUIRT works perfectly with lirc-0.8.1. There is a setup.sh script in the lirc sources distribution for easy install.
Extract the source files.
tar -xjvf lirc-0.8.1.tar.bz2
Run the setup.sh.
cd lirc-0.8.1 ./setup.sh
Select Driver Configuration, then USB Devices. Select the USBUIRT driver. Select Exit and Run Configure.
After you "make", and "make install" you may need to add the folloowing to /etc/modules.d/lirc:
alias char-major-61 lirc_usb-uirt2_raw
If you havent already, enable the CONFIG_USB_SERIAL_FTDI_SIO setting in the kernel config. I am using 188.8.131.52. The setting is under Device Drivers, USB Support, USB Serial Converter Support, when using "make menuconfig" to configure your kernel.
If you already have an lircd.conf made for your remote(s) and blaster, then you don't need to do anything else. My blaster and remote codes (captured with serial devices) worked fine on the USBURIT.
If you are building for the first time, test lirc is working by using "/usr/local/bin/irrecord test.conf" and try to capture some IR codes. RTFM from lirc from here on.
Waking from suspend-to-ram
I've noted on the article page that using the remote to wake from suspend to ram doesn't appear to function properly under linux. I've been unable to get this to work, and in my searching I've yet to find any evidence that anyone else has either. I'm currently using lirc 0.8.2
I've configured the USB-UIRT with the wake codes via the windows utility. I've managed to actually get it to wake a linux machine from suspend-to-ram as long is lirc is never loaded. However, once lirc is loaded and any lirc application accesses the USB-UIRT, the device appears to become corrupted. From that point forward, the wake-from suspend functionality doesn't work anymore. Unloading lirc doesn't fix it. Even a full reboot doesn't restore it. The only solution is to remove power by physically unplugging the device from the USB port.
Effectively, you have your choice of using the USB-UIRT as either a wake-from-suspend device or as a lirc device, but not both.