For a fair amount of years now, I've been using Mutt as my primary email client. It's a very nice text-based email client that is permanently running on my server (named drsnuggles). This allows me to connect to my server from anywhere, connect to the running Screen and always get exactly the same, highly customized, mail interface (some people will say that their webmail interfaces will allow for exactly the same, but in my experience webmail is always clumsy and slow compared to a decent, well-customized text-based client when processing a couple of hundreds of emails per day).

Attachment troubles

So I like my mutt / screen setup. However, there has been one particular issue that didn't work quite as efficient: attachments. Whenever I wanted to open an email attachment, I needed to save the attachment within mutt to some place that was shared through HTTP, make the file world-readable (mutt insists on not making your saved attachments world-readable), browse to some url on the local machine and open the attachment. Not quite efficient at all.

Yesterday evening I was finally fed up with all this stuff and decided to hack up a fix. It took a bit of fiddling to get it right (and I had nearly started to spend the day coding a patch for mutt when the folks in #mutt pointed out an easier, albeit less elegant "solution"), but it works now: I can select an attachment in mutt, press "x" and it gets opened on my laptop. Coolness.

How does it work?

Just in case anyone else is interested in this solution, I'll document how it works. The big picture is as follows: When I press "x", a mutt macro is invoked that copies the attachment to my laptop and opens the attachment there. There's a bunch of different steps involved here, which I'll detail below.

See more ...

Only recently, Adobe has started to (finally) support 64 bit Linux with its Flash plugin. I could finally watch Youtube movies (and more importantly, do some Flash development work for Brevidius).

However, this month Adobe has announced that it drops support for 64 bit Linux again. Apparently they "are making significant architectural changes to the 64-bit Linux Flash Player and additional security enhancements" and they can't do that while keeping the old architecture around for stable releases, apparently.

This is particularly nasty, because the latest 10.0 version (which still has amd64 support) has a couple of dozens (!) of security vulnerabilities which are fixed in a 10.1 version only (which does not have Linux amd64 support anymore).

So Adobe is effectively encouraging people on amd64 Linux to either not use their product, or use a version with critical security flaws. Right.

Recently I've been fixing up some critical defects in my MSI S270 notebook: My display stopped working due to a broken inverter cable and my power adapter switched on and off all the time due to a broken cable as well.

The inverter cable goes from the laptop mainboard to the inverter, which is below the display. On its way it passes the left hinge, which is exactly where it was broken. Apparently I'm not the only one having these kinds of problems with the S270. Some people suggest that the hinges are badly made causing these problems.

I've looked closely at the inverter cable and it even seems the cable breaks are caused by a tiny thread that is wrapped around the inverter cable to keep it together. Three of the six (IIRC) wires has broken and a few more had cuts in the insulation. The breaks were very clean and seemed to be exactly at the spot where the wrapping thread had cut into the insulation...

Anyway, I managed to solder the tiny wires back together again (using some extra wire to fill the gap). The cable did become bigger from this, so I had to remove the speakers and their cable to make a bit room in the hinge to fit the soldered cable in.

It has been working for a few weeks now, but I'm afraid the solder connection will break eventually again. In the meanwhile I've been trying to get a new cable, but it's pretty impossible to get at and MSI Netherlands refuses to sell me a cable. They say the want to use all cables they have for repairs, meaning I have to send my entire laptop to them and pay €80 - €150 for a repair I could have done myself (the part alone is usually €20 - €30...).

I'm still happy with the laptop, while it is working, but I won't be buying another MSI when this one finally breaks down for good...

My power adapter cable had also broken, switching on and off when I wiggled with the cable. The cable used to have two round "blocks" at the start and the end (ferrite rings to prevent interference). Over a year ago the cable broke near one, now it broke near the other one. I've removed both of them now and soldered the stuff back together, making it work again.

Recently, I've been setting up awstats, a webserver log analyzer, to parse my Lighttpd logs. When I'm done, I might post some details on my setup and the glue scripts used, but for now, I just want to comment on the right LogFormat configuration value to use for lighttpd.

When googling around, a lot of people either not mention LogFormat at all, or suggest to use LogFormat=1, which means the Combined Log Format (CLF). However, lighttpd use a different log format!

In fact, the CLF is very similar to Lighttpd's log format, but it differs in the second field. In CLF, the second field is the identd username, which is ignored by awstats. In Lighttpd's format, this is the virtual host of the current request, which is very relevant if you're logging multiple virtual hosts to the same logfile. This similarity is th reason that LogFormat=1 does work for most people, but it's better to use the proper configuration:

LogFormat="%host %virtualname %logname %time1 %methodurl %code %bytesd %refererquot %uaquot"

I've taken this format string from the only correct posting I found online, but the forum of that posting seems to interpret the %ua in the last field as a newline (probably u for unicode and a for 0x0a, which is the ASCII code for a newline...), so it took me a while to realize that it was correct.

I've recently been hacking a bit with Flash (or rather, with Adobe's Flex compiler. This is a freely available commandline compiler, which actually works on Linux as well.

However, out of the box the commandline compiler, mxmlc, is obnoxiously slow. It takes nearly 10 seconds to compile a simple Hello, world! example, and compiling the video player I'm working on takes over 30 seconds. Not quite productive.

This is a documented "flaw" in the mxmlc compiler, caused by the fact that it has to start up a big java program everytime, loading thousands of classes and because it always recompiles the entire source.

The official solution to get faster compile times is to use the Flex Compiler Shell (fcsh), which is included with the Flex SDK. Basically, it's a caching version of the mxmlc compiler, that keeps running in the background and caches compiled files.

fcsh is intended to be used by IDEs. The IDE starts fcsh and then communicates with it through its stdin/stdout. This means fcsh is really a simple thing, without any support for listing on sockets or properly daemonizing.

Using fcsh speeds up the build time from nearly 40 seconds to just a few seconds (depending on how many changes were made). The first compilation run is still slow, of course.

I've been trying to use fcsh with the ant build system, which makes things a bit tricky. Since there is no long-running process (like an IDE) which can keep fcsh running, this needs some way for fcsh to be run in the background, connected to some fifo or network socket so we can start it on the first compilation run and then connect to it in subsequent compilation runs.

A quick google shows that there are already a few fcsh wrappers to do this, some of which intended to work with ant as well. At a quick glance, it seems that the flex-shell-script-daemonizer seems the most useful one. It is created in Java and runs as a daemon (unlike the alternatives I saw, which were Windows-only due to some useless GUI). It has two modes: In server mode it starts fcsh and connects it to a TCP network socket and in client mode it takes a command to run and passes it over the netowrk to the running server.

There is also some stuff to integrate make ant use fcsh for compiling actionscript files. However, this requires changing the build methods and stuff in build.xml, which I don't want to do (I'm trying to minimize my changes to the sources, since I'm modifiying someone else's project).

So, I created a small shell script that can be used as a drop in replacement for mxmlc. It simply takes joins together all its arguments to a single command and passes that to the flex-shell-script-daemonize command. If the fcsh daemon is not yet running, it automatically starts it (and does some half-baked daemonization, since neither fcsh nor flex-shell-script-daemonizer does that...)

While writing the script, I also found out that the fcsh "shell", doesn't have any way to quote spaces in arguments in the command (at least, I couldn't find any and there was no documentation about it). This means that, AFAICS, there is no way to support spaces in paths. How braindead is that... I guess FlexBuilder, the official IDE from Adobe doesn't use fcsh after all and instead just includes the compiler classes directly...

Of course, just as I finished the script, I encountered flexcompile, which basically does the same thing (and includes the network features of flex-shell-script-daemonizer as well). It's written in python. However, it does require the path to flex and the mxmlc part of the path to be passed in as arguments, so it's not a 100% drop-in replacement (which I needed due to the way the build system I was using was defined). Perhaps it might be useful to you.

Anyway, here's my script. Point the JAR variable at the jar generated by flex-shell-script-daemonizer and FCSH to the fcsh binary included with the Flex SDK.

#!/bin/sh

# (Another) wrapper around FlexShellScript.jar to provide a mxmlc-like
# interface (so we can just replace the call to mxmlc with this script).

# For this, we'll have to call FlexShellScript.jar with the "client"
# argument, and then the entire mxmlc command as a single argument
# (whereas we will be called with a bunch of separate arguments)

JAR=/home/matthijs/docs/src/upstream/fcsh-daemonizer/FlexShellScript.jar
FCSH=/usr/local/flex/bin/fcsh
PORT=53000

# Check if fcsh is running
if ! nc -z localhost "$PORT"; then
    echo "fcsh not running, trying to start..."
    # fcsh not running yet? Start it (and do some poor-man's
    # daemonizing, since the jar doesn't do that..)
    java -jar "$JAR" server "$FCSH" "$PORT" > /dev/null 2> /dev/null <
/dev/null &

    # Wait for the server to have started
    while ! nc -z localhost "$PORT"; do
    echo "Waiting for fcsh to start..."
    sleep 1
    done
fi

# Run the client. Note that this does no quoting of parameters, since I
# can't find any documentation that fcsh actually supports that. Seems
# like spaces in path just won't work...
# We use $* instead of $@ for building the command, since that will
# expand to a single word, instead of multiple words.
java -jar "$JAR" client "mxmlc $*" "$PORT"

Considering that the long-running live roleplaying series by Evolution Events are coming to a close, we've had some time to consider the future. There are still some (financial) details to work out, but we are proud to present our newest LARP event: Extraterrestrial.

Recently I have been doing some Flash debugging for my work at Brevidius. In a video player we have been developing (based on work done by Jeroen Wijering) we needed to escape some url parameter, since our flash code could not be certain what would be in the value (and characters like & and = could cause problems). The obvious way to do this is of course the escape function in ActionScript. This function promises to escape all "non-alphanumeric characters", which would solve all our problems.

However, afters implementing this, we find that there are spaces magically appearing in our GET parameters. Upon investigation, it turns out that there are plus signs in our actual values (it's Base64 encoded data, which uses the plus sign). However, the escape function apparently thinks a plus sign is alphanumeric, since it does not escape it (note that the flash 10 documentation documents this fact). Which shouldn't be a problem, since a plus sign isn't special in an url according to RFC1738:

Thus, only alphanumerics, the special characters "$-_.+!*'(),", and reserved characters used for their reserved purposes may be used unencoded within a URL.

(Note that RFC3986 does recommend escaping plus signs, since they might be used to separate variables, but that's not the case here).

However, the urls we generate in flash point to PHP scripts and thus pass their variables to PHP. Unfortunately, PHP does not adhere to the RFC's strictly: It interprets plus signs in an url as spaces. Historically, spaces in an url were replaced by plus signs, while spaces should really be encoded as %20 nowadays. There is of course a simple way get Flash (or any other url-generating piece of code) work properly with PHP: Simply encode plus signs in your data as %2B (which is the "official" way). This makes sure you get a real plus in your $_GET array in PHP, and the problem is resolved.

After some searching, and asking around in ##swf on Freenode, I found the encodeURIComponent function, which is similar to escape, but does encode the plus sign. If we use this function, we can again send data with spaces to PHP! And since encoding more than needed is still fine according to the specs, there are no downsides (except that you need Flash >= 9.0).

So, if you're developing in Flash, please stop using escape, and use encodeURIComponent instead.

Since a while, I've been using git-buildpackage to manage the Debian packaging for OpenTTD. This offers the option to sign the tags created by git-buildpackage, which is of course cool. However, I've found that I always need to load my GPG key into my gpg-agent first to make that work. If I didn't, I'd see the following:

You need a passphrase to unlock the secret key for
user: "Matthijs Kooijman <matthijs@stdin.nl>"
1024-bit DSA key, ID 8A2FAFBC, created 2005-05-27

gpg: cancelled by user
gpg: skipped "Matthijs Kooijman <matthijs@stdin.nl>": bad passphrase
gpg: signing failed: bad passphrase
error: gpg failed to sign the tag
error: unable to sign the tag

This also occurs when calling git tag directly, but not when calling gpg --sign.

I've finally done some research to this, and found that this can be solved by setting the GPG_TTY variable in every shell. According to the gpg-agent manual, you should add the following to your ~/.bashrc:

GPG_TTY=$(tty)
export GPG_TTY

And whaddayaknow, it works! Sounded pretty silly to me (why not just use $tty directly?), but it actually makes some sense. First of all, $(tty) is not an evironment variable, but an invocation of the tty command.

Secondly, it seems of course silly to put this in the environment when the passphrase-asking code could just find out the current tty by itself. However, it seems that it is actually gpg-agent itself that initiates the passphrase dialog. When I unset $GPG_AGENT_INFO in my terminal, git tag asks for a passhprase normally (but just with an "Enter passphrase:" prompt, instead of the full-screen curses-based prompt I get normally).

This probably means that whatever code is calling gpg-agent from within git tag, is sending along the value of the GPG_TTY variable (or perhaps simple all of the environment?). I guess the gpg command automatically sets the GPG_TTY variable internally, which is why using gpg directly just worked.

This also explains why, after entering my passphrase, my key was added to the agent as well.

This morning I've entered the next stage of my car mechanic career: I've stopped by the junkyard to get some spare parts for Brenda's car. About a year ago, I broke off one of the door handles from the car (the door was frozen shut, and I underestimated my own strength...). The KIA dealer was happy to replace the handle, for EUR 150 or something silly like that. Considering there was enough of the handle left to operate the door perfectly (after being pointed out which part to hold, mostly), we just left it broken for a year.

A few weeks back, we found a crack in one of the outer mirrors. There was no clue how this happened, but perhaps it got hit by some stray snowball or the winter's cold made it snap. Since the outer mirrors are a failure point for the APK (yearly checkup), we really needed to replace those.

So, this morning I went to a local junkyard, that had an old Kia Pride. It was a ghostly sight, all those half disassembled cars. Some missing wheels, hoods, doors, etc. They had a spare mirror on the shelf, but the door handle was still on the car. I found a blue Kia Pride out back, and after some fiddling disassembled the door handle. I actually quite like this junkyard thing: Not only do you get to do stuff with your own car, you can find out how its done on some other car first, without the risk that you break more stuff while prying something loose.

Just now, Brenda and me put on the "new" parts, so the car is as good as new again (if you ignore the occasional squeeking and creaking, of course), for just EUR 25.

Next up is finally fixing up some rusty spots on the paint of the car, but I'd really like to have some place to put the car inside for a few days for that (lest my fingers freeze off and the new paint won't dry).

As everybody in Holland knows, the Dutch train service has been "huilen met de pet op" lately. Due to all the snow and frozen junctions, we've seen a few days with next to no train service a while back, and even now when all the snow is gone, there is still an "adapted schedule", due to "logistic problems". In other words, they don't have enough (working) trains to serve all of the schedule, so some routes have reduced service.

On the plus side, because of this the Dutch Railways is giving every subscription holder (which includes also includes the "Voordeelurenkaart" and the "OV Studentenkaart") free coffee, tea or hot chocolate at the Kiosks. This is at least the case in Utrecht, probably in more places. However, even though the announcement there said ns.nl would contain more details about the offer, I can't find it, so I can't tell for sure.

So, if you've got a few minutes to spare on a station this week, get your free drink at the Kiosk!

And, on a related note: The NS is refunding tickets from the dreaded december 20th, 21st and 22nd railway mayhem, so if you had a delay then (or didn't arrive at all) and still have the ticket, go claim a refund!