I found that gSTM has a hardcoded “-o ConnectTimeout=5” inside it, and changing ~/.ssh/config or /etc/ssh/ssh_config doesn’t override it, so I decided to remove it as sometimes my tunnel takes longer than 5secs to start: diff -uNr gstm-1.2.orig/src/fnssht.c gstm-1.2/src/fnssht.c --- gstm-1.2.orig/src/fnssht.c 2006-08-03 10:36:35.000000000 +0200 +++ gstm-1.2/src/fnssht.c 2010-07-22 17:56:15.016430000 +0200 @@ -213,8 +213,6 @@ free(tmp); } hargs->sshargs = gstm_ssht_addssharg(hargs->sshargs, "-o"); - hargs->sshargs = gstm_ssht_addssharg(hargs->sshargs, "ConnectTimeout=5"); - hargs->sshargs = gstm_ssht_addssharg(hargs->sshargs, "-o"); hargs->sshargs = gstm_ssht_addssharg(hargs->sshargs, "NumberOfPasswordPrompts=1"); hargs->sshargs = gstm_ssht_addssharg(hargs->sshargs, NULL); //end list Also it won’t build cleanly on 64-Bit Fedora 13 as the XML2 and X11 libraries cannot be found by the linker.

I just installed my new Intel X25-M, its an 80Gb 2nd-generation SSD drive, and it goes like shit off a shovel – way over twice as fast as my [also new] WD Caviar Black 1Tb, averaging around 280MB/sec for reads. I found the WDC drive had the same problem as the two 500Gb WDC drives, namely these errors in dmesg, leading to inode corruption: ata2: exception Emask 0x10 SAct 0x0 SErr 0x4090000 action 0xe frozen ata2: irq_stat 0x00400040, connection status changed ata2: SError: { PHYRdyChg 10B8B DevExch } ata2: hard resetting link ata2: SATA link up 3.

The WD Caviar Black drive that I bought to replace the dead WDC Blue has died itself now – SMART reported 9 sectors it couldn’t reallocate before the thing just died completely. Oh I love backups! So now I’m sending two drives back to the ebay seller for refund, as WDC’s RMA procedure was too complicated across two continents. The problem now is what drive to buy – I think Western Digital suck these days, Samsung I’ll never touch again, so that leaves Seagate or possibly SSD, but the “economy” SSD drives from OCZ/Kingston are 65ukp for 32Gb, but at least with no moving parts or heat issues there can’t be much to go wrong with them I guess, plus read speeds are faster than HDD.

I’ve been upgrading my CentOS 5.4 VM’s to 5.5 today, it all went well with both 32 and 64-Bit builds. Just do: su - yum clean all yum update yum rpm glibc python yum -y update reboot

Whilst I’m waiting for my new hard disk to arrive for my Core-i5, I needed to use VirtualBox, so I decided to install it on my E5300 fileserver, which luckily has VT-x support, and of course is running a 64-Bit Ubuntu 9.10 install with 4Gb RAM. It actually was easier than I expected, similar to the Fedora method you just add the repository to your /etc/apt/sources.list, import Oracle’s GPG key and run “sudo apt-get install virtualbox-3.