It may not be much, but I stuck together a small article about how to remotely automate the startup of HP servers. We did this ages, and only now have I gotten around to tidying up the notes!

Over here

Recently I’ve been looking at getting a computing device into the Land Rover. Short of buying a full sized 7″ touch screen, I opted to go for a slightly cheaper £20 4×20 LCD display. This was more to be proof of concept, and give me a starter to work on, before I decide whether or not to put a full sized screen in.

Ultimately, I purchased a SmartieLCD module from Ebay. It arrived, I plugged it into my laptop running Windows at work, and it worked first time. Now it was time to get it working with LCDProc!

Earlier on I had spotted that SmartieLCD in Windows used the Matrix Orbital DLL file. Sadly, when using LCDProc in Linux, Matrix didn’t work at all. It was time to go looking

Enthused by http://lists.omnipotent.net/pipermail/lcdproc/2009-July/013021.html, and manufacturers documentation, I decided to check out the CVS copy of LCDProc. The last ‘release’ was back in 2007, so if I was to get anything recent it would have to be from CVS

cvs -d:pserver:anonymous@lcdproc.cvs.sourceforge.net:/cvsroot/lcdproc login
cvs -z3 -d:pserver:anonymous@lcdproc.cvs.sourceforge.net:/cvsroot/lcdproc co -P lcdproc

Having a look around the source files indicate that Sure Electronics displays were supported, but not enabled by default. A simple ./configure flag would enable them, so it was time to get compiling. Firstly some support files have to be installed first.

sudo apt-get install libusb-dev autogen automake

After that, kick off the build process, and enable Sure Electronics support at configure time.

sh ./autogen.sh
./configure –enable-drivers=SureElec
make
sudo make install

Now that the software is installed, LCDd needs configured in order to send data to the LCD display.

sudo vim /usr/local/etc/LCDd.conf

In here, a few parts need changed -

driver=SureElec
DriverPath=/usr/local/lib/lcdproc/
Edition=3
Contrast=200
Brightness=480

And that’s it! Execute /usr/local/sbin/LCDd, and you should get a Clients: 0 and Screens: 0 on the LCD display.

All is good!

A while back, Alcatel Lucent were flogging off cheap Tikitag readers and tags due to a naming error. They subsequently became Touchatag, and I picked up a cheap RFID reader and 100 tags for about 10 quid. Bonus. Now to get it working on Linux.

Adam Laurie helpfully wrote the RFIDIOt toolset, and a quick download and tar -zxvf had it on the system.

Install various support files…
apt-get install python-pyscard pcscd pcsc-tools python-pycryptopp python-serial

You may see pcscd starting up. If you don’t, check with ps to see if pcscd is running as a background process. If it is, you can fire up pcsc_scan, and then plug in your reader. All being well, something similar to the following will be printed out.

Waiting for the first reader…

found one
Scanning present readers…
0: ACS ACR 38U-CCID 00 00
… followed by a load of data.

The 0: indicates the reader number, so ctrl+c out of pcsc_scan, and open up RFIDIOtconfig.py in your favourite text editor. Jump down to the readernum= directive, and change that from 1 to 0 (or whatever number was indicated in pcsc_scan).

You’re now good to go. In the case of the Touchatag device, just fire up ./multiselect.py, and slide one of the Touchatag tags across the face of it. All being well, something similar to the output below will be displayed.

bagpuss@x300:~/src/RFIDIOt-1.0a$ ./multiselect.py
multiselect v0.1m (using RFIDIOt v1.0a)
Reader: PCSC ACS ACR 38U-CCID 00 00
(Firmware: ACR122U102, SAM Serial: 065441005C162256, SAM ID: 004033)

Tag ID: 04AF1AB9232580
No card present

It always displays “No card present” when nothing is there. That can easily be changed in multiselect.py, and you can edit it to do anything you want now.

Personally, I’ll be using my reader to log when I arrive at work and leave for home, due my inability to get timesheets handed in more than twice a year My boss rocks!

Want to make Zattoo work on Kubuntu 0804? It’ll most likely fail silently, without spitting out any useful error information.

Some chopping up of ldd /usr/bin/zattoo_player output reveals that it’s useful to run sudo apt-get install dbus-x11, at which point zattoo_player will start working.

Recently I acquired a HTC Touch HD, and in order to connect it to my eGroupWare installation, I purchased the Synthesis SyncML client to do the necessary translation. Now, Charlotte’s SonyEricsson has a built in SyncML client (which I’ll be playing with when back in the UK), but Microsoft didn’t see fit to provide SyncML capability on Windows Mobile 6.1. Anyway, life goes on.

Synthesis has trouble passing telephone numbers onto eGroupWare. I think eGW is at fault for this, so I’ve filed a bug. In the meantime, I’ve attached a small patch file that maps the Synthesis fields to what I think are the correect Vcal fields. Just apply it to /addressbook/inc/class.addressbook_vcal.inc.php and things should start working. If they don’t… you know where to edit And before anyone complains, I am neither a PHP programmer or an experienced patcher. This is pretty much my first patch file…

273d272
<                         ‘TEL;CELL;VOICE;X-Synthesis-Ref1′ => array(‘tel_cell_private’), // Private cell
277d275
<                         ‘TEL;HOME;VOICE;X-Synthesis-Ref1′ => array(‘tel_home’), // Home telephone
280d277
<                         ‘TEL;WORK;VOICE;X-Synthesis-Ref1′ => array(‘tel_work’), // Work telephone

Well, it’s nice to see that I’m not alone in my recent decision to change…

Since KDE have ruined Kubuntu with KDE4, it’s time to use Gnome. However Compiz and glitzy pointless effects irritate me no end. A few quick commands will disable them for the current user…

gconftool-2 –set /desktop/gnome/applications/window_manager/current /usr/bin/metacity –type=string

gconftool-2 –set /desktop/gnome/applications/window_manager/default /usr/bin/metacity –type=string

The next time you log in, it will use the default Metacity window manager instead of Compiz. Happiness all round.

*** UPDATE *** See Calum’s response below for the correct method.

A few weeks ago I thought I would take the plunge, and installed KDE 4.1 on my Kubuntu 8.4 laptop. With the recent announcement of Intrepid being launched, I upgraded to Kubuntu 8.10 with KDE4 as the default environment. I figured that I should get an early look at the direction KDE is going. Sadly it would appear to be the wrong direction.

The first daft thing I noticed is the logout method. Click on the K Menu, then Leave, then Logout. It takes you to same menu that you get for shutting down. Complete with all the same options available. What’s the point in the extra menu options and complexity for new users? I use KDE4 at work on OpenSUSE 11, and it doesn’t suffer from this multiplicity.

Maybe the above can be attributed to a bug in Kubuntu, so let’s just carry on using it. Hopefully…

Before the system had even finished logging on, it was as slow as treacle. My poorly laptop had a loadavg of 7,5,5 just to log in. It’s not exactly spritely, but as a 2.33GHz Core2 with 2GB RAM and a GeForce Go 7400, I expected more. A minute or so passed as the system wound itself down, and Plasma graces the screen. Slowly.

Everything is just so slow. It’s unbearable. I worked at it for about a week, and everything KDE related was sloooooow. Kontact crashed with predictable regularity. Amarok hung randomly, Konqueror bailed out whenever the wind blew the wrong way, and kwin would have a fit when you looked away from the monitor. The bugs were supposed to be ironed out during 4.0. This is 4.1, and supposed to be stable enough to ship as a default WM in a  release of Kubuntu. I tried everything, from disabling all effects in kwin, to purging ~/.kde/ and ~/.kde4/. All to no avail. I even formatted and reinstalled a new instance of  Kubuntu ‘just in case’. Sadly that didn’t resolve it either.

The situation would appear to be the same on my reasonably powerful desktop PC at home. Kubuntu 8.10 is unbearably slow and prone to crashing. Admittedly I’ve not tried the absolute most recent version on the desktop, as I managed to embed a hard drive in the LCD panel. Long story, but it involves KDE4…

Kubuntu 8.10 ships with KDE4 and no option to use KDE3.5. It’s with a heavy heart I move to Ubuntu and Gnome. Initial impressions would indicate that it’s far swifter and less prone to random crashing. Maybe I’ll move to KDE 4.5 when Gnome releases 3.0…

A year ago Matthew Dillon went into some detail about the new HAMMER filesystem. It’s now reaching stability, and will hopefully be sent forth in the upcoming v2.0 release of DragonflyBSD. All the interesting bits can be discovered here and here. A few features to note, though, are…

1 Exabyte of storage
Online data migration, replication and evacuation – multi-master disk replication across WANs anyone?
Logical data retention policies – ie you can have block level replication to a remote site with large slow disks, but with a lengthy data retention policy
Inbuilt volume level and file level versioning and snapshotting – just mount up or request a version number, and you get a snapshot from that time. A bit like MS VSS.
Inbuilt reblocker for defragging, expansion and contraction.
PF linked connection state recovery – keep those TCP links alive throughout a router reboot.

These are just a few of the features, read the documentation to find out the rest. It may turn out to be a ZFS killer, but anything with replication like this sounds good to me. Now we just need to wait for it to be ported to Linux, assuming Zumastor and Tux3 don’t rule the roost by then For what it’s worth, there’s some info on Tux3 and HAMMER features and ideas at http://kerneltrap.org/Linux/Comparing_HAMMER_And_Tux3

Recently EVE Online had been playing up. It was still in demo mode, but I quite fancied having a shot at it. The app was having none of it though…

kyleg@CHLP0023:~$ eve
Single-user install…
This is the update checker…
Running /home/kyleg/.cedega/.updater/cedega_updater.py
Running… /home/kyleg/.cedega/.ui/runGUI
kyleg@CHLP0023:~$ err:client:receive_fd FD went missing; attempting recovery
wine client perror:0: write/writev: Bad file descriptor
kyleg@CHLP0023:~$

Some hunting revealed a similar issue for Mac users. It translated to Linux use quite easily though.

kyleg@CHLP0023:~$ rm -rf ~/.cedega/EVE\ Online/c_drive/Documents\ and\ Settings/Local\ Settings/Application\ Data/CCP/EVE/c_program_files_ccp_eve_tranquility/cache/
kyleg@CHLP0023:~$

Sadly the issue still continued, so the settings directory was nuked as well. I also killed off some wineserver apps at the same time, so it could have been down to them at this point…

kyleg@CHLP0023:~$ rm -rf ~/.cedega/EVE\ Online/c_drive/Documents\ and\ Settings/Local\ Settings/Application\ Data/CCP/EVE/c_program_files_ccp_eve_tranquility/settings/
kyleg@CHLP0023:~$ ps waux | grep -i [w]ine
kyleg 21418 0.0 0.0 36552 1728 ? Ss 00:41 0:00 /home/kyleg/.cedega/.winex_ver/winex-eve-000130/winex/bin/wineserver
kyleg 21419 0.0 0.0 36552 1728 ? S 00:41 0:00 /home/kyleg/.cedega/.winex_ver/winex-eve-000130/winex/bin/wineserver
kyleg@CHLP0023:~$ kill 21418
kyleg@CHLP0023:~$ kill 21419
kyleg@CHLP0023:~$

All was pretty by this point, and EVE continued as expected.

[ad]