As a christmas present for you I uploaded a new version of "enigma" to experimental. For those who don't know it yet: enigma is a nice puzzle game requiring a great mixture of mouse skill and puzzle thinking. Enjoy!

After someone on IRC told me, that gnome-terminal appeared to be a lot faster with X.org, I decided to try it out.

As a Debian user, probably the easiest way to get X.org currently is to get the packages from Ubuntu Hoary. When you pin hoary to be below unstable, packages won't be automatically upgraded to hoary. Then you can search in aptitude for the Xfree packages (serch string: ~V6.8.1-ubuntu or so) and upgrade only these. Dependency tracking will do its share.

After upgrading to X.org, my gdm did not work any more. Upgrading to gdm from ubuntu and in turn pulling in gnome-panel from ubuntu, helped.

So I was able to log in to my new X.org based Desktop. Gnome-Terminal was a lot faster - apparently there has been much improvements with Xft. Other apps fealt faster too.

Then I tired to run glxgears, and my new X.org was dead.

Apparently there is a problem with OpenGL on Hoarys X.org. I don't know if this is upstream or Hoary only. Even without DRI, glxgears locks up my machine; pure Ubuntu hoary users experice the same with ATI, while nVidia users have glxgears segfault. Interestingly, other OpenGL apps worked - for example the skyrockets screensaver, or scorched3d (apart from the water still totally hosing up display on ATI).

Well, since screensavers sometimes locked up my system, I decided to downgrade to good old reliable XFree again. And to gdm from unstable, too, getting rid of all Ubuntu packages on my system. That came to be more difficult than I had expected... First, gdm would start a xserver, then complain that there is already a xserver running. Seems like it didn't find the xserver it just started... (the same problem why I upgraded to Ubuntus gdm in first place) the second problem is Xkb, which didn't work properly any more, causing segfaults in gnome-settings-daemon (Gnome developers might want to investigate this).

After rebooting, gdm worked again (this reminds me of windows times... running the xfree-common init script hadn't helped, btw.) and after manually removing some xkb files gnome became usable again...

I have a nice idea for optimizing the readahead behaviour of a system: why not "learn" this behaviour during boot, incrementally improving it each run?

Now you'd probably say: do you want to run all your processes with a LD_PRELOAD, modify your libc or your kernel. ;-)

Well, the last certainly is the easiest way, and you do not need to modify recent kernels actually. There is a tiny audit system included that you can easily use to attach to "open" and "execve" ioctls. Each time these are called, a message is sent over netlink. Supposedly this is very efficient. It is included in recent 2.6 kernels.

Now what I'd like to do is have a daemon record the first time a file is opened or run using this hook. I had a look at "auditd", the tool written by the author of that kernel extension. I log into a ramdisk, and stop logging after 60 seconds (when my system certainly is up; if you are running sysvinit you can stop it at S99 of course)

Well, so far for the theory. Practise is a bit different, unfortunately. Somehow, auditd is missing a couple of events and I get quite some "lost audits" logged to the console. I'm not really sure how they fit together - according to these lost events the queue is far from its maximum, so auditd seems to be processing events quite okay.

The other problem is the amount of events logged - a lot of accesses to /proc are logged (fortunately I havn't tried combining this with bootchart...) that play absolutely no role for readahead, but occur in big numbers.

While the audit framework and auditd should allow me to put a filter onto the device id, all open and execve calls are somehow logged with device=00:00 so no way in filtering there. :-(

But this is a problem I probably can fix quite easily by filtering myself in auditd. It's opensource, after all. The first problem is more difficult.

I wanted a fast way to backup and store additional data for my Laptop. Since my Laptop only has USB 1, Firewire sounded good (USB 1 is 12 mbit, my firewire port can run at 400 mbit). So I bought an external drive.

While it appeared to work fine at first, it randomly shuts down sometimes. Forget Prolific-Based solutions. Mine has a Prolific PL3507 chipset, C revision. I also tried newer firmwares that float around the net (while the manufacturer has removed them from his site) - no success.

At first I thought it was either a problem with the WD hard disc, or some idle timeout, but I can rule these two out: A badblocks scan on the drive over IDE did not reveal any problems, and recently the drive disconnected while I was creating a .tar file on it and once while writing a DVD off it.

Being that unreliable, the drive is getting to my nerves...

Error recovery of the Linux ieee1394 stack was also bad - after the drive had gone down once, I needed to reboot the machine to be able to re-add the drive. With the latest drivers from svn, this seems to have improved. Last time the driver restarted the drive in ro mode directly.

I also found a way of working around this: With the fake pci hotplug driver (fakephp, sweet module name ;-) ) I can have the driver reinitialize my ieee1394 controller without a reboot.