Recently my eeePc 900’s battery has been struggling, so I figured it was time to actually test how dead it is. I charged it up fully and ran a script to log the battery’s charge every 15 seconds. I then unplugged the power and left it downloading files over a wireless network. 36 minutes later it ran out of power.

I then plugged in the power turned it back on and once it had booted up I ran the same script to log the battery levels as it charged up. Turns out it took about 90 minutes to charge up again.

As it now only last half an hour I decided that a new battery was due. So I replaced it with the same spec battery and reran the tests. With the new battery it can run for 3 hours, though it does still take a long time to charge.

As I had the data to hand I decided to run it through gnuplot to produce a nice graph to visualise the differences.

Back when I first started using computers (Oric Atmos and ZX Spectrum) everything was stored on cassette tapes (C15, C60, C90, etc). They weren’t the most reliable way to store data and there was a definite black art involved in retrieving data stored on them, though a volume of 7 is a good place to start.

When I started using computers at school (BBC Micros) their data was stored on 5.25 inch floppy disks and later on a network drive (50 machines all sharing a 10MB hard disk). They were easier to retrieve data from, though don’t leave the 5.25 floppy disks in the sun for too long or they wouldn’t stay flat.

Later on in life I started using PCs (286,386,486 and pentiums) at school/college which used a 3.5 inch floppy disk to store 720KB, which later on increased to 1.44MB. At home I moved onto an Amiga 500 and later an Amiga 1200 (A1200), both of which used 3.5 inch floppy disks (880KB), and a 120MB Hard disk in the case of the A1200. These were again more reliable and I have actually still got a large collection of 3.5 inch disks to use with my A1200.

From then on I used 3.5 inch floppy disks until USB flash drives came along. OK, sometimes I would use CDs but not for storing files I was working on, just for archiving data onto.

So why am I talking about the history of my data storage. Well I haven’t had any storage medium in the past that would have survived what I put one of my flash drives through the other day. It was an old one that I use to write ISOs to for booting rather than writing a CD, just 1GB of storage. I had put MemTest86+ on it to test the memory of my new media center PC. Needless to say that afterwards it ended up in my trouser pocket and the next night I put those trousers into the washing machine and gave them a hot wash. When I was taking out the washing there was my flash drive sat in the drum having been washed and spun.

Personally I had at that point written the drive off, I know they are tough but I didn’t expect it to survive that. I let it dry then plugged it into my computer and rebooted, the boot menu had the flash drive as an option so I selected it. MemTest86+ started up and started running. It looks like that flash drive is a lot tougher than I thought.

Last year I purchased a Dane-Elec SoSmart media player. It has 1TB disc in it and numerous outputs, including HDMI. As a media player I can’t really fault it. The only problem that I had was that it uses the NDAS protocol to share the disc, it doesn’t use SMB or any other sane protocol.

For those that don’t know what the NDAS is, and I didn’t until I got this, rather than using a protocol to share/transfer files it uses the NDAS protocol to share the physical disc. There are drivers for Linux as well as Windows, but the speeds it got were terrible. Was there a solution?

Kind of, Sir Dekonass had produced a custom firmware build that would let you access the device using both telnet and ftp. Not exactly secure but on my little home network not much of a problem. Great, except I didn’t have write access to the disc, I only had read only access. I telnet in, root didn’t have a password and I couldn’t set one either.

I then tried to unmount the drive and remount it, but it came back as read only again. I assumed this was due to it being ntfs and the driver being used. I connected to the device using a USB cable and I found that I could use fdisk to recreate the partition on the disk as a Linux partition and then use mkfs.ext3 to create a new file system on this. Restarting it I then discovered that it had mounted it as read only again even though it was now an ext3 partition. I tried unmounting it and mounting it again and this time I could write to the disc. Great except I had to log in each time I turned it on and remount the disk, which I really didn’t want to do.

It took a while of digging through the start up scripts on the SoSmart but I discovered that in the startup sequence it looks at each disc it has mounted for a file called mvix_init_script and if it exists execute it. I knew I couldn’t easily put it on the disc in the machine as I wanted to unmount it. To get around this problem I got an old USB flash drive and repartitioned it into two new partitions and formated them both as ext3.

On the first partition I created my custom mvix_init_script. On the second I copied the contents of the /etc directory. Inside my mvix_init_script I effectively have 3 sections.

The first unmounts the second partition on the USB and remounts it over /etc. This lets me add passwords and new users to the setup, so I now only have a passwordless root account for a very short period on startup.

The second section unmounts the internal hard disk and remounts it, making sure it is writeable. This lets me use ftp to transfer files over to the disk, which is a lot faster and easier than maintaining the NDAS setup.

The thrid section kills the shttpd processes and restarts them with a document root of just the internal hard disk. This stops people viewing things like /etc/passwd with it which really wouldn’t be a good thing.

Is this a perfect setup? Not really I would like to have SSH on it rather than telnet but then copying files over SSH would take longer than the simple ftp method.

It turns out that after googling “mvix_init_script”, the system is actually the mvix built for the sosmart and a lot of good information it available at http://mvixcommunity.com/.

Today I started up my eeepc 900 and it just didn’t want to work. I managed to work out that the control (CTRL) key seemed to be permanently pressed, even though the key wasn’t stuck down. No matter how much I poked and prodded the key it just didn’t make a difference. So next port of call was removing the keyboard and trying to clean it, as I didn’t want to spend the money on a replacement.

Previous laptop keyboards I have removed have been a real faff, with some requiring me to take the entire laptop apart. With the eeepc 900 though I just had to use a terminal screwdriver to push in 3 springy clips on the side of the keyboard by the screen and then I could lift the keyboard up and then slide it out. There is a connector cable near the touch pad that needs to be unplugged but there is enough cable to easily get at it.

Having removed the keyboard I then attacked it with a can of compressed air. Then I plugged the cable back in and slid the keyboard back into place and pushed it gently down and it just clicked into place again.

It is little things like this that really make be impressed by the eeepc 900 and why I don’t think I will be changing it for a long time to come. It isn’t as fast as a brand new netbook, but then running Debian with a custom build of Enlightenment v17 means that it is still fast enough for what I do with it. The screen isn’t as big as some new ones, but then it does increase it’s portability. It isn’t as nice looking as new ones but as I just throw it in my backpack then rugged is probably better for me than stylish.