Mind reading

As a spectator to sporting events, there are times when the ability to read a sport(wo)man's mind would be... interesting.

For instance.

Yesterday's woman's 1500m final at the world athletics championships in Daegu was won by Jennifer Simpson. This was a surprise to many, including (apparently) Jennifer herself, as evidenced by the look on her face after the finish. See, for instance, this youtube clip (interesting bits around the 4 minute mark)

Alternatively, I'd love to know what went through Carlos Berlocq when he won his first game in the match against Novak Djokovic in the third set. I mean, obviously nobody expected the world number one to lose from a relatively unknown 74-ranked argentine player, but that doesn't make it less painful.

One day

Went to see One Day yesterday. As I usually do after watching a movie, I next went to wikipedia to read up more about it.

Was shocked to read that it received 'mostly negative' reviews. I thought it was pretty good.

After reading a few of the aforementioned reviews, I understand what the problem is, and though I disagree with the resulting negativity in the review, I can see where it's coming from.

You see, One Day is a novel-turned-movie. As with most movies that were sourced from a novel, the movie is a disappointment to those who read the book, mainly because there's always going to be more material in the book, and therefore some of your favourite passages from the book are going to be removed, or changed so that they'll lose some of their original goodness. This is even true for beyond-feature-length movies sourced from novels; for instance, when I saw the horse whisperer after reading the book, I found it a disappointment too, even if my brother and sister who saw it at the same time as me did like it.

Ignoring that, there's a second problem; while it's a love story, I don't think it qualifies as a 'romantic comedy'. For it to be a romantic comedy, you'd expect 'happily ever after', and you'd expect a story about two people quickly (or slowly, as the case may be) falling in love with eachother, overcoming some problems that stand in the way of their relationship. Most importantly, you'd expect it to be lighthearted and funny—you'd expect it to be a comedy.

One day doesn't deliver that; if you go see it, expecting a romantic comedy, you'll be sorely disappointed. But if you accept the fact that it isn't a romantic comedy, it's still a very interesting film. It's not lighthearted, but that doesn't mean there isn't a laugh or a cry in there. And, without wanting to spoil the plot, while the movie doesn't bring 'happily ever after', it does still come up with a believable, emotional, and very compelling ending.

The plot takes you through the 15th of July in the lives of the two main characters, every year for two decades. Sometimes they're spending that day together, sometimes they're not. Sometimes they're calling, sometimes they're fighting, sometimes they're kissing. The days shown are snapthots of both their lives; this adds an interesting angle to the plot, as much of the story, much of what is going on, can't actually be shown on-screen, since it happened in between the two 15ths of July.

While, as said, I wouldn't describe the movie as a romantic comedy, I think it can be accurately described as a romantic drama. It's not going to be a legendary movie, a must-have-seen, one which you'll grow to hate over watching it on every TV station's prime time over the next few years. But it's a charming, novel, and interesting piece of drama.

Did I like it? Definitely. When I go to the movies, sometimes I want a silly movie, some action flick that I can have a bit fun laughing at; but sometimes I want a movie that touches my heart and makes me reflect on my own life while feeling for the characters. When I went to see The Expendables, I have a lot of fun for one night, and then promptly forgot about it. But 'One Day' rang true with me on an emotional level; and for that alone, I can recommend it.

Even if that wasn't the reason why I chose to pay €8 for this movie rather than anything else. I'll be perfectly honest: Anne Hathaway. Good actress, and sporting the most interesting pair of bright eyes you've ever seen; what more could one want?

A film that allows these two—eyes, and acting talent—to shine, of course. And One Day delivers.

No more MySQL on my machine

I've said it before: I think MySQL is a toy, and I want as little to do with it as possible.

Unfortunately, since the KDE PIM suite depends on akonadi, which depends on a database, which was initially implemented against MySQL, not having MySQL installed on a Debian machine if you want to use the KDE PIM suite, for the longest time, wasn't even possible. Today it is, but it requires some manual steps:

sudo apt-get --purge install akonadi-backend-postgresql akonadi-backend-mysql-
akonadictl stop
rm -rf .config/akonadi
rm -rf .local/share/akonadi
cat > .config/akonadi/akonadiserverrc <<EOF
[%General]
Driver=QPSQL

[QPSQL]
Name=akonadi-wouter
Host=
Options=
StartServer=false
EOF
createdb akonadi-wouter

Change "akonadi-wouter" for a suitable database name.

And now it should work. Note that this requires you run PostgreSQL system-wide and create a system-wide database in that server. It should, in theory, be possible to have akonadi run its own private PostgreSQL instance, much like how the MySQL backend does things, but a) I couldn't get that to work, and b) I don't think having each user run their own database server instance is a good idea to start with, so honestly I didn't try very hard.

And there, pronto! I now no longer have toy databases on my laptop. Word.

Why I think MySQL is a toy.

A commentor on my previous post asked why I think MySQL is a toy.

I've actually blogged about that a number of times, but when wanting to point that out, I found that most of those posts point out just one thing, rather than having one post that enumerates them all. So let's remedy that, shall we?

There are many things wrong with MySQL, including, but not limited to:

• In my personal opinion, the whole storage engine thing is a bad idea. It leads to dilution of effort (the MySQL developers need to implement stuff more than once), and makes users choose between disjoint feature sets, which will almost always result in suboptimal results. It also neatly allows PR people to claim that MySQL is 'fast' and 'ACID compliant', without mentioning that you can't combine both.
• One of MySQL's default settings is to truncate string values if they are longer than the field in which they're supposed to fit. This eats data. Hint: it's a database. While truncating strings might be appropriate in extreme corner cases, making it the default is so wrong it's not even funny.
• One of MySQL's default settings is to use MyISAM as a storage engine, which doesn't do transactions. This means you don't have atomicity, which eats data. Hint: it's a database. While telling a user "if the system crashes, I might write your entire data set to disk, or I might write just half of it, or I might corrupt the data set and I'm not going to tell you until you try to read again" might be appropriate in extreme corner cases, making it the default is so wrong it's not even funny. Update: as many people pointed out to me in the comments, apparently one of the first things Oracle did when they took over MySQL is to change the default from MyISAM to InnoDB, making this point no longer valid. I still think the replaceable storage engine thing is a bad idea, but with InnoDB as default, it's not as much of a pain anymore.
• If those two weren't enough 'mysql eats your data' arguments, note that most distributions routinely run a data recovery tool at MySQL startup, because not doing so caused problems in the past.
• I've seen MySQL crash and burn and segfault reproducibly when it encountered a corrupt table. Now I'm not saying that the database should be able to read data as if nothing happened from a corrupt file, but it should not crash and burn and segfault; instead, it should produce an error message.
• Fetching a result set can be done in two ways: either you call mysql_use_result() before calling mysql_fetch_row() which tells MySQL you'll be fetching the result one row at a time, or you call mysql_store_result(), which will read the entire result set into memory. So far so good. The problem, however, is that if you use mysql_use_result(), you're locking the tables from which you're fetching data, and no other client will be able to update any data in those tables until you're finished. On the other hand, if you need to process a large amount of data that can't be processed on the server for some reason, you may need to run a query that returns more data than you have memory. In that case, running mysql_store_result() is plain impossible. This isn't just a theoretical thing; I've seen cases in data warehouse situations where a database client needed to process multi-gigabyte query results. Trying this on MySQL is a pain.
• When compared to PostgreSQL, the MySQL feature set is immature. For instance, here's a number of useful[1] features which PostgreSQL has but MySQL, to the best of my knowledge, does not (corrections are welcome):
  • table inheritance
  • asynchronous notification
  • full ACID compliance, in all cases. (MySQL only offers full ACID compliance if you pick a particular storage engine)
  • asynchronous command processing.
  • Very flexible authentication system, and real actual users. For instance, PostgreSQL supports Kerberos authentication, and understands that users may actually log in from different hosts (gasp!)
  • SELinux extensions, called SE-PostgreSQL.
  • Server-side languages are implemented using a plugin scheme, allowing stored procedures to be written bascially in any possible language. Someone wrote a PL/LOLCODE which, while not very useful, shows the flexibility; MySQL only supports one language for stored procedures and triggers—if the storage engine supports triggers, which not all do.
  • Sequences (an AUTO_INCREMENT column is a reasonable workaround, but still not a sequence)
  • window functions
  • extensible data type system; of those, MySQL only supports enumerated types.

Against that list, MySQL can only pit "multi-master clustering". While I'm sure that's useful for some use cases, I remain unconvinced that it's a useful enough feature to have to deal with the administrative overhead that MySQL's multi-master clustering imposes upon you, or that it is worth losing all the above over.

So it's my opinion that any database which fails to store data correctly in its default settings can't be anything but a toy; or that a database which has a comparatively small feature set can't be anything but a toy. But maybe that's just me.

[1] No, I haven't used all those features; but I have used asynchronous notification, sequences (other than for primary keys), kerberos auth, custom data types, and (obviously) I have enjoyed the extra peace of mind of knowing that my database is ACID compliant, meaning that it will either accept my transaction as a whole, or reject it as a whole (but usually the former). In addition, I've seen customers use the table inheritance feature.

SSL and CAs

The CA model of SSL has always bothered me. The idea of a trusted third party feels eerily close to maffia security: you believe this person, whom you don't know, is who he claims he is on nothing more than the word of this other person, whom you also don't know.

The DigiNotar story proves how problematic this model is, but you don't really need that to understand its problems.

For the longest time, however, there simply was no better way to properly do these things. But now that we have DNSSEC, do we really still need CAs? Really? Can't we just store a fingerprint of a per-domain signing key in the forward (and, possibly, reverse) DNS zone of the host in question, have that signed by DNSSEC, and have the browser check the full DNS chain of the zones in question in addition to the signature on the certificate instead?

I'm sure the CA business people would hate to see that happening, but really, paying someone so they say whatever you tell them to say? Try that in court, and they'd lock you up.

Update: It's called the DANE protocol. No, that has nothing to do with Denmark: DANE stands for "DNS-based Authentication of Named Entities".

"Yoe" or "wouter"?

For the longest time, I went by the nick "Yoe" when I went on IRC. When I chose this nick for myself, I was sixteen, and the Internet computer at the local public library had an IRC client installed that I tried out. Obviously, my first choice of nick -- "wouter", a fairly common first name in Dutch-speaking regions -- was already chosen, so I had to come up with something else. If I'd realized that I'd still be using this nick today, seventeen years later, I might have chosen that nick with a bit more care...

Over the years, some people have asked me what the nickname meant, where it came from. I've never really told anyone the entire story, mainly because it was somewhat embarrasing. But hey, we've all been 16, right?

In the early nineties, there was a show on TV called "Het huis van wantrouwen". On this show, they had a running joke involving a short clip of Belgian members of parliament informally voting on a subject by raising hands (literally); the joke was that this clip was dubbed with a bunch of people saying "Yoe, de manne" -- which is dutch for something along the lines of "Yo, guys".

As a young geeky teenager, I found this joke way more funny than it actually was; and as such, a few years later, during one of the more weird episodes of my life, I started pranking people by sneaking up to them from behind and shouting "Yoe, de manne" right next to their ears. I even managed to do this to one of our teachers who was walking on the playground.

This was just around the time when I first tried out this "IRC" thing. It didn't take me too long to realize I was the only person who thought this "joke" was funny; but somehow the nick stuck, and here we are, 17 years later, I'm still using it.

Or, well, I was. As of today, if you want to catch me on IRC, you'll find me going by "wouter" instead of "Yoe". Of course someone had registered that nick several years ago, but then he hadn't been using it in years, and so after a quick request to the OFTC admins they made it available for me.

Whee.

Dear lazyweb,

Is there a syscall to ask the system whether a file is sparse in a particular region? I.e., if I say dd if=/dev/zero of=./foo seek=10 count=10, then I should get a "yes" for the first half of the file, but a "no" for the second half.

Case in point: I need to write a test for the newly-implemented NBD_CMD_TRIM which uses fallocate with the FALLOC_FL_PUNCH_HOLE option to sparsify a file.

kthxbye,

Youtube music

There's loads of music on YouTube. However, when I want to listen to music, I'm not necessarily interested in slideshows. And yes, that's a euphemism.

Luckily, extracting the video and audio from a youtube clip isn't very hard.

• First, download the clip. Yes, that's possible. This will get you a movie clip, by default in the highest quality format available for the particular clip you're trying to download.
• You want to know which codecs the clip is using. Mplayer to the rescue:

  wouter@carillon:~$ mplayer -frames 1 -v <file> 2>&1|grep -i 'stream.*audio'
  [lavf] stream 1: audio (vorbis), -aid 0
  

  meaning, this particular file has Vorbis audio.
• Next, extract the audio:

ffmpeg -i <file> -vn -acodec copy <output>.ogg

The critical bit is the '-vn' part, which tells ffmpeg not to encode the video to the output file. The 'mplayer' step isn't strictly required; but since youtube only uses lossy audio codecs, re-encoding the audio to a different codec will cost you audio quality. You may not want to do that; hence the mplayer step (to figure out which codec the source file is using), and the '-acodec copy' argument to ffmpeg's command line (which tells ffmpeg to not re-encode the audio, but just store the unmodified original audio stream in a different container file).

Tadaa, music without video.