I spent last week in San Francisco, attending DrupalCon. Like many geeks, I prefer to have a laptop with me at conferences, so I can take notes, check email and work on stuff if I need or want to.

My laptop is a rather lovely HP 6730b with a lot of RAM that does a whopping 1680 x 1050 as native resolution. Great for graphics and having lots of terminals open - less great for portability. HP also seems to have taken the 12 cell add-on battery for it off the market, so it only gives me about 2½ to 3 hours of run-time (with wi-fi enabled) as well.

At DrupalCon I developed netbook envy, so upon arriving home I decided I needed something a lot more portable and with far better battery life.

I did a bit of research and found that all manufacturers offer virtually identically spec'd netbooks that contain an Atom N450, 1GB RAM, 250GB HDD and a 10.1" screen. The only point of difference seems to be the battery size, which ranges from 3 cell to 6 cell Li-ion.

A friend told me he'd just bought an Eeepc 1005P for just over $400, which is actually much cheaper than the competition. Sadly that was with a 10% discount campaign, which is no longer running. Still, the 1005P was at least $30 cheaper than the closest competitor and it does come with a 6 cell battery.

Well, I finally got a revision 1.0 out the door for one of my Drupal modules.  A fact I thought I'd celebrate with a blog.

The module with this honour is the most recent one I started, userpoints_evaporate, just over a week ago.

I guess it's a nice example of why open source is cool. Someone on the #drupal-support channel on Freenode asked if anyone knew whether an existing module could do what he wanted, which was essentially use the UserPoints module (which works kind of like karma on Launchpad) to automatically expire a set number of points for all users every hour or day (again, kind of like karma on Launchpad).

I managed to get hold of a Leadtek DTV2000H of the revision J persuasion ages ago. It works flawlessly for recording under mythtv, but I never really tried to get the remote control working.

Since I started doing the occasional consulting job for Open Query, I've seen a lot of MySQL servers that have been installed once and then forgotten about. This gave me the idea to do a short presentation about some basic MySQL server configuration. The first go was at DrupalCampMelbourne and I recently tried (and failed) to cram it into a three minute lightning talk slot at the LUV September meeting.

The title of the talk is (now) MySQL > YourSQL. I chose this not because I think that MySQL is better than the $other_database you use or because I may or may not run a newer version of MySQL on better hardware, but because I use InnoDB and not MyISAM as the default table format. More importantly, I do not run the server with the shipped default configuration.

These configuration tips are also included in the MySQL section of Pro Linux System Administration.

Most distributions ship MySQL with a configuration file that sees you running a server optimised for a system with 32MB of RAM. That was great in 1996, but these days your Nike+ shoes have more capacity than that, so it makes sense to optimise the configuration - or at least to make it not suck quite as badly.

I chose InnoDB as the default storage engine not because it gives me a magic increase in performance or transaction support, but due to the  improved reliability that comes from its ability to automatically recover from crashes better than MyISAM does.

All the following settings go in the [mysqld] section of your my.cnf file.