2007

Sat, Nov 17

<23:56 EEST> Life's been exceptionally good for the past few days, or at least until the guy upstairs ruined it again with his inconsiderately loud lifestyle for this cardboard building.

On Thursday I ported Comms to the new version of Audacious, 1.4.0. I'd been thinking of the problem for a few days, and the thought of accessing Audacious' objects via D-Bus instead of the usual way of shared library functions seemed intriguing. That morning I received pointers for some example code, and wrote it up during the day.

In many ways, this D-Bus approach is the easiest and most elegant I've used over the years of maintaining Comms. After mere two lines of connecting to the bus, the functions work pretty much like before, though names and syntaxes have changed somewhat. You also need to be careful with variable types, as the raw binary types are thrown around between different programs. Python has pretty good automatic type conversion, and it's only sending values to Audacious where things get picky. Unfortunately Audacious itself is a little buggy at this stage, and I'll probably have to revert to the old stable version for any upcoming DJ sessions.

Today turned out a kind of culmination point in the joys of teaching I've experienced this autumn. I taught in a nanoscience workshop for teachers, which took place at Norssi. In retrospect the atmosphere reminds me of some Saturday study sessions at Kuopion Lyseo: a small group of dedicated learners gathered in a classroom at an otherwise empty school building. In a sharp contrast to mass lectures, forced social interactions, and the din of unsatisfied schoolkids, today was an energizing and inspiring experience. There was probably an effect similar to what I've noticed at student theatre festivals and other geeky/scientific conventions: everyone is an active participant instead of the audience/performer split.

Fri, Nov 9

<19:02 EEST> Yesterday was one of those nights when things just don't work as they should. A combination of several drawbacks with a memory upgrade for sigmatrix resulted in a kind of geek fatigue. Even though you get it to work in the end, it feels like a loss — at least of common sense and your precious time. And a few megabytes.

I had ordered two SODIMMs of 1 GB DDR333 to max out my laptop for good, on October 2nd. After a few weeks of waiting, I sent the company a complaint email, and another a week after that. Then this week, they apologised for the delays and the package arrived on Thursday. Packaging was messy, with little padding and no electrostatic shielding whatsoever. Similar reports about the company abound, but there seem to be happy customers too.

On a slight plus side, I thought I'd gotten a good deal given this was the cheapest memory of its size. Memory chips were impressive-looking BGAs and the CAS latency was 2.5, though it turned out no different from the laptop's default memory. As the CL ranges from 2 to 3, I'd expected both the default and the cheap upgrade to have it at 3. So I didn't expect any obvious speed improvement.

Dauntingly enough, after a few minutes of succesful memtest86, the bootup turned into molasses (or, as I prefer, malt extract :-P). I recalled reading reports with earlier Linux kernels that warned about slower performance if you upgraded your RAM to something huge like 32 MB. I figured such bugs would have been fixed, but reports with a similar problem were recent as well. Some of them claiming that Windows had no problems on the same hardware.

Playing around with the HIGHMEM option, I first disabled it to get back up to speed, but alas, with only 896 MB of memory. The default limit of low memory for Linux. (High memory support is not needed if you don't have more RAM, but naturally I'd planned for the upgrade with my config.) I started toying with the highmem= kernel boot option just in case, and it turned out all I needed was to limit the total available memory somewhat. The option mem=2016M was the best I could do, with the BIOS reporting 2032M of available RAM.

Similar problems with other people have touched upon the idea that the motherboard can only cache so much RAM, and any extra will cause the slowdown. My laptop is specced to allow 2 gigs, and it would be weird to have a hardware limit that's not a power of two. However, hardware devices need memory addresses too; the total addressable memory space is then limited by the caching ability. As far as I understand.

Of course, at this stage I don't mind losing a few megs of memory. What worries me is that Linux won't boot properly on this hardware without the mem= parameter. The same is needed with the Ubuntu Gutsy LiveCD, so obviously the issue is not particular to my setup.