28 Mar 2009 (Saturday) 

The boiler's died again today. It's made nasty noises and is giving me little error messages on its display when I try to turn it on now. So I've left it turned off. This weekend has so far been incredibly lonely and crap, and I'm staying away from asking the question of whether things could be any worse because I know they can.

Return to top | Comment on the diary

27 Mar 2009 (Friday) 

I've had an awful day today. Goodbyes to my friends; Bruce, Pete, Steve, Mike, Francis, Alex, Toqir, Miah, Christopher and another Steve. I'll miss you all. It'll be lonely going in to the office on my own.

Any similarity to the March 2008 entry is entirely intentional.

What can I say, as if things weren't quite crappy enough as they are, there's now this to make them even crappier.

Oh, and I've got a little bit of a cold as well.

Looking back to a year ago, I'm really far worse now than things were back then. I can't really imagine that things are going to get a lot better though. I keep telling myself I should cut my losses, but that's so hard when you've invested so much over a long period.

After last nights dreams that turned out to be almost exactly right, and failing to sleep for quite a while, it's really not a whole lot better than it was .

Return to top | Comment on the diary

14 Mar 2009 (Saturday) 

Feeling very lost today; not really sure what I'm doing either in general or from step to step. Stuff just seems to be... crappy at the minute and I'm never on top of things. I still forget what I'm doing. I just need someone to show me the way, really.

Return to top | Comment on the diary

13 Mar 2009 (Friday) 

For some reason, the remove rule on my udev rules for eSATA weren't working. The following does, however, seem to do the right job:

# Rules to automatically mount the esata devices once they appear
# on the system.

ACTION=="add", \
        KERNEL=="sd[a-z]1", SUBSYSTEM=="block", \
        ATTRS{vendor}=="0x197b", \
        ATTRS{device}=="0x2360", \
        RUN+="/bin/mount /dev/disk/by-label/$env{ID_FS_LABEL}",
        ENV{REMOVE_CMD}="/bin/umount -f /dev/%k"

Return to top | Comment on the diary

12 Mar 2009 (Thursday) 

My arm's tender today. Not sure why, but it's just being a little tender on the inside of my forearm this evening. Oh well.

Met up with Julian again today, and had another nice meal out.

Return to top | Comment on the diary

11 Mar 2009 (Wednesday) 

Last night was a sort of a continuation of a dream. I was with Mum and Dad and waiting to go somewhere and we saw the entrance to an old train station. Mum wanted to go in there, so we walked over the road through the archway to the station. It was disused, as it had been before, but there were people around living in the building next door - not where I had been. In this version of the dream, the group hadn't just been held there, but the place had been set on fire and they had - presumably - burned. I'd got away in that version.

The fake foam wall had been bricked up, and a proper door placed beside it. I went inside and began looking through things. Although the place looked scorched there wasn't an damage to the boxes of papers. I found some of the papers I was looking for previously (seemingly in this revisionist version, I was looking for something too). There were no bodies, no charred remains of people, and no sign of Jane at all. I left and looked at some of the writing on the wall - people had carved or penned poems in to the wall outside the building. Taking the papers, we left.

That was about it; it was quite sad and lonely really.

A couple of weeks back (ish - it seems like an eternity, but then things have gone really slowly recently) someone pointed me at a RISC OS 'Invaders' application. The author has very nicely left the source up in text format which is great when you don't actually have a RISC OS machine to see the BASIC in. As I do reviews every day at work, I thought I might have a look at it and see whether there was anything useful I could say. What I found has bemused me since then in ways I haven't seen in a long time...

I wasn't looking at it in much detail, but memory allocators are always good to look at and give a good indication of what's going on. If you spin to the end of the code there's a section of functions prefixed with 'ash' which comprise the memory allocator.

FNash_alloc allocates code from the heap (and we'll ignore the fact that the return from this routine as failing is not handled by most of the code - my own BASIC is far worse in this respect). To do this is uses the OS_Heap routines - well I'm assuming it's OS_Heap; you can't really tell. It actually calls FNswi_get(13). There's a magic number that should have been a constant really. But we'll overlook this because it gets crazier the deeper we go...

I had assumed that FNswi_get was a SWI number lookup. But I follow it, and find that this is just a wrappers for FNcore_get looking up to a special array that has a magic '108' value. This in itself searches, *linearly* through an array to find the number associated with the value that was being searched for (13 in this case). It turns out that the 108 value is the message number of the error to use on failure. On finding the value in the table (this is effectively a hash-lookup implemented as an linear search of an array), we have a string.

Not just any string, oh no. It's encrypted. Using an Exclusive OR of every character with 131.

This string then, is the the SWI name to call. So the OS_Heap is finally called. If we look, momentarily, at the initialisation of this hash lookup, we find that it's held in a file, which is loaded by PROCstring_load. This file contains a magic key to ensure that it's not written badly, followed by the number-string tuples.

Basic file I/O writes out strings in a PASCAL-ish format - type, length, string-bytes-in-reverse-order.

So what we have here is compete insanity.

We have a magic value being used to look up a hash key by a linear search of an array, to find an encoded string which was originally stored backwards on disc. All in order to find the system call name. Which BASIC will then go and lookup through the OS to get a number to call.

Wouldn't it have been easier to have defined 'SWI_OS_Heap = &1D' and used that variable in the code in the first place ?

I had a little bit of a discussion with the author about this, and apparently it's ok to do things this way, because it's just example code. And as we know, inefficient, perverse, encrypted strings are just what you want in your examples because you want people to do that kind of thing. Oh yes.

Julian's also been helping me understand some things about how to read accounts and things to look for. He's obviously far better placed to do this . So, I'm still not understanding a lot of stuff, but I have a better idea about other things.

Tonight was also going to be the penultimate stage in diagnosing the external drive box resetting problems I've been having recently. But I got distracted by Caroline calling, so I didn't get around to that. I'll probably do it tomorrow after tea.

Still not sleeping all that well. Waking up a lot, and the occassions that I dream are now far less common. Plus I've also got less nails, from not eating enough and being stressed over stuff.

Return to top | Comment on the diary

4 Mar 2009 (Wednesday) 

Bridge Scene, from Michel Vaillant, by Archive is quite similar in form to Angel, from Mezzanine, by Massive Attack. So similar in fact that when I heard the latter on an advert earlier today I thought it was Archive. I keep meaning to listen to Massive Attack more.

Return to top | Comment on the diary

1 Mar 2009 (Sunday) 

I added some udev rules to automagically mount my discs once they're available off the eSATA port multiplier box - ie if the box is plugged in. They're pretty simple. Firstly the discs are all labelled individually with where they should go - that's because if the box can appear later then you don't want to assign the disc to the wrong mount point, and the label makes a good example of how to differentiate them. So because of this the labels should be specified in fstab. And the entries should be marked as noauto, and 0 as the pass for fscking.

The only other thing that you need to know is the vendor and device id for the interface they're on - ie which interfaces we're interested in dealing with this auto-mount on.

The rule is pretty simple, and goes in /etc/udev/rules.d/esata.rules.

# Rules to automatically mount the esata devices once they appear
# on the system.

ACTION=="add", \
        KERNEL=="sd[a-z]1", SUBSYSTEM=="block", \
        ATTRS{vendor}=="0x197b", \
        ATTRS{device}=="0x2360", \
        RUN+="/bin/mount LABEL=$env{ID_FS_LABEL}"

ACTION=="remove", \
        KERNEL=="sd[a-z]1", SUBSYSTEM=="block", \
        ATTRS{vendor}=="0x197b", \
        ATTRS{device}=="0x2360", \
        RUN+="/bin/umount /dev/%k"

Return to top | Comment on the diary