The bits of the IT world that apply to me right now. Blogged in the hope that someone (even me) will find them useful.
Wednesday, April 30, 2008
Perl Best Practices, live!
Whack your dodgey Perl code in here and get the the bad news right away!
Labels:
code,
lint,
Perl,
Perl Best Practice,
programming
Thursday, April 24, 2008
Quick product review
I got a new laptop recently, an M1330 from Dell. I'd thought I throw out a few quick comments on the process.
Up to the minute technology says that the Penryn family of processors are excellent for laptops, with The Register suggesting that, alone, they can increase battery life significantly. In terms of graphics, the world of little laptops revolves around Intel's X3100 or nVidia's 8400M. The M1330 can have either - I went for the nVidia option as I like playing games now and again.
That left a choice of screen. I plumped for the more expensive OLED option after The Register's review. I noted that Dell seems to have responded to the review by raising the price of this option. RAM - 4GB (I could have saved £50 and blown my warranty by adding this myself, but out of £1000, why?). Hard disk - 250GB (it's enough for me).
The laptop runs nicely. Vista's a dog, but it's Vista. The graphics performance is better than I expected (TF2 runs well, except for the water effects). And the number crunching power is all I'd hoped for.
I tried Ubuntu 7.10 for a bit, and it ran well, but I hit issues with wireless networking and my home network, so restored Vista. I may try again once the new release settles back down. I have no love for Vista.
In a nutshell:
Dell M1330 8/10 - Solid.
Microsoft Vista 3/10 - Soft.
Up to the minute technology says that the Penryn family of processors are excellent for laptops, with The Register suggesting that, alone, they can increase battery life significantly. In terms of graphics, the world of little laptops revolves around Intel's X3100 or nVidia's 8400M. The M1330 can have either - I went for the nVidia option as I like playing games now and again.
That left a choice of screen. I plumped for the more expensive OLED option after The Register's review. I noted that Dell seems to have responded to the review by raising the price of this option. RAM - 4GB (I could have saved £50 and blown my warranty by adding this myself, but out of £1000, why?). Hard disk - 250GB (it's enough for me).
The laptop runs nicely. Vista's a dog, but it's Vista. The graphics performance is better than I expected (TF2 runs well, except for the water effects). And the number crunching power is all I'd hoped for.
I tried Ubuntu 7.10 for a bit, and it ran well, but I hit issues with wireless networking and my home network, so restored Vista. I may try again once the new release settles back down. I have no love for Vista.
In a nutshell:
Dell M1330 8/10 - Solid.
Microsoft Vista 3/10 - Soft.
Friday, April 18, 2008
USB dead device fix
I have a slug (NSLU2) at home, serving out a big USB hard disk. I like my slug. It's small, and it runs Debian, and so long as I remember that it's really small, it runs really well.
It looks like USB drives suffer from lots of issues with dodgey firmware and drivers. Certainly, I haven't escaped them. Every few months I lose the USB drive:
kern.log:
...
This can cause filesystem corruption as well, and is generally "A Bad Thing". Fixing this issue is (for me) a case of remounting the filesystem. I recall once I also had to cycle the power too. Fortunately, I found this page: http://www.mail-archive.com/linux-usb-users@lists.sourceforge.net/msg16510.html which has a very nifty technique for coaxing the USB stack back to life.
I've written a script to pull out the sysfs name of the USB device for a given mount point. At some point I'll add this in to my slug so that it "just works". That just leaves a log scraper to pick up each mount and get the sysfs name, wait for a failure, unmount the dead file system, rebind the USB device, check the file system for damage, and remount the filesystem. Easy!
It looks like USB drives suffer from lots of issues with dodgey firmware and drivers. Certainly, I haven't escaped them. Every few months I lose the USB drive:
kern.log:
Apr 12 20:32:54 slug kernel: scsi 1:0:0:0: rejecting I/O to dead device
...
This can cause filesystem corruption as well, and is generally "A Bad Thing". Fixing this issue is (for me) a case of remounting the filesystem. I recall once I also had to cycle the power too. Fortunately, I found this page: http://www.mail-archive.com/linux-usb-users@lists.sourceforge.net/msg16510.html which has a very nifty technique for coaxing the USB stack back to life.
I've written a script to pull out the sysfs name of the USB device for a given mount point. At some point I'll add this in to my slug so that it "just works". That just leaves a log scraper to pick up each mount and get the sysfs name, wait for a failure, unmount the dead file system, rebind the USB device, check the file system for damage, and remount the filesystem. Easy!
#!/bin/bash
# get_usb_name.sh
# e.g.: ./get_usb_name.sh /media/usb2
USB_DEV=$(mount | grep ${1} | cut -f 1 -d ' ' | sed -e 's/[0-9]$//' -e 's(^/dev/((')
USB_ADDR=$(ls -l /sys/block/${USB_DEV}/device | sed -e 's(/host.*$((' -e 's(^.*/((')
if [ -e /sys/bus/usb/drivers/usb-storage/${USB_ADDR} ]
then
echo $USB_ADDR
else
echo "could not verify usb address of ${USB_ADDR} for device ${USB_DEV}" >&2
fi
Subscribe to:
Posts (Atom)