Yay, easter

Four days off work does wonders. I hope. Been busy last couple of weeks. With mind numbed by J2EE/WebSphere pain, haven't had any energy to work on Straw or do much else with the computer, I've just spent most of my free time at the gym or cooking and doing home stuff. Or playing FFX2. I hope I'll squeeze off a few hours today and tomorrow for Straw. First thing on the agenda: sync up with Gnome CVS, last few times I tried I got a weird complaint about a conflict I couldn't locate. Second: make the configuration writer write into a temp file and copy that over the old configuration when it's done; I just lost my Straw config due to a crash. I wish I knew what piece of hardware is causing those.

At least my Gnome 2.6 setup is starting to work, slowly. I used to have a ~/.Xsession file that set up some locale variables and stuff, but apparently that isn't a good idea anymore. With it around, the normal Gnome session refused to work. Possibly I should have exec'd gnome-session or something there, I have no idea. Oh well, I nuked it, at least the thing starts now. I wonder what's the approved location for that kind of stuff… Another thing that still has to be figured out is why my ~/.Xmodmap no longer works, now I have to call xmodmap manually to get my keyboard configuration. Maybe one of these years I should really look into that new-fangled xkb thing.

But now, I think, is time to go out running, the weather is beautiful and relatively warm at +7 degrees celcius. Here's hoping it won't be as painful as the first time in the spring usually is. I at least should be in a slightly better condition than I usually am this time of year.

Downtime brought to you by stupidity

I've had this problem with random crashes with my new-ish computer which I haven't managed (or bothered) to pinpoint. It's something hardware related, but that's all I know. Last saturday the thing crashed once again and after I rebooted it, it wouldn't start. There was, on the console, some complaint about missing modules for INPUT products and a last line with nothing on but "pci", then nothing happened. I pressed enter a couple of times, decided it was broken and shut it down frustrated. Reiserfs3 has gotten some files confused when the system has crashed a few times (hooray for journaling... I should really try ext3/XFS/JFS/Reiser4), so I thought that it had finally screwed up something vital.

At the beginning of the week I downloaded a CD image of Knoppix, burnt it to a CD and and booted my computer with it. Worked like a charm (first time I used KDE in a while. Still not to my taste.) I wasn't feeling much like doing forensics on the piece of junk so I didn't properly get to it before today; fscking my HDs found nothing strange so I just reinstalled the kernel and rebooted the machine. The same problem. Then I started reading the boot process output a bit better; among other things I noticed it had already loaded pretty much everything including sound card and network adapter drivers and the error messages were about hotplug. Oh boy. The first thought was to again reboot with Knoppix and tinker with the boot process; the second one was to press Ctrl C.

Next time I'll try that first, not a week afterwards.

Lessons learned

We're working on dropping the mxDateTime dependency from Straw for version 0.22. It's proving to be a bit more difficult than expected, and exposes two design blunders made early in the development. The other is easy to circumvent, the other one isn't.

First, you should store a version identifier in all files you create that you expect to read back. Including the data store. That's easy enough to deal with later on, luckily, just assume that in the case of absent version identifier, it's version 1.

The other is the result of too eager use of Python's pickle mechanism and a total brain-fart. For whatever reason, I've been storing mxDateTime instances in the database. Duh. Now to get rid of those, we can't drop the mxDateTime dependency completely. Luckily we can restrict it to the conversion function called, if necessary, on start up, but still, that's something I should have seen coming. It's not as if it's difficult to serialize a date object independently of the object format.

I'll just close this with a quote from Franklin P. Jones, whoever he is: Experience is that marvelous thing that enables you recognize a mistake when you make it again.

© Juri Pakaste 2024