Today I found this gem on /. (must be the needle in the hay). This is simply ridiculous: Having an XML tag (or attribute, whatever) named autoSpaceLikeWord95 with the explanation: To faithfully replicate this behavior, applications must imitate the behavior of that application, which involves many possible behaviors and cannot be faithfully placed into narrative for this Office Open XML Standard. If applications wish to match this behavior, they must utilize and duplicate the output of those applications. Eh what? This is about to go into some kind of ‘official standard’? WTF?
And that is not the only one. This (6000 pages) spec seems to be full of it. I agree with the above article: This is not a specification; this is a DNA sequence.

*Laughing my ass off*. Oh wait, this is actually not funny. :-/

One Laptop Per Child revisited

In my latest rant about OLPC I probably sounded a little extremistic. I’d like to add that I don’t think that computers are generally bad for children. Especially in the developing countries there is probably good use for them, especially when it is not possible to have schools or something similar. I think I got a little annoyed because many discussions that I’ve seen take the OLPC as a cure for many problems that it can’t be, and the focus is mostly on technical issues, on 3rd world issues and others, but not on the children. When done right, the OLPC is surely a nice opportunity to help the developing countries. For this to work we would have to include the children and the special needs of 3rd world countries into our focus. And that doesn’t (only) mean childish themes and desktops. That means reasonable and sustainable pedagogic concepts that are tailored to these children in these countries. If there’s documents about this please point me to them, I am really interested.

A better comparison

I did a run of GNU Classpath’s AWT and J2D benchmarks. The results are more fair now (JDK6 vs Cairo vs X/Escher). Cairo now beats the X peers, but the overall speed is still impressive given that it’s done all in java. I guess my own small benchmark was a nuance too artificial 😉

Need for speed

Some more numbers for you as followup to my last measurements:

  • jdk6: ~750ms
  • my latest improved Escher/Java peers on Cacao: ~200ms

I wonder what Sun did to the shape renderer in jdk6. It’s quite slow compared to JDK5 and even much slower than the Escher peers. And that is without antialiasing just like the Java renderer. Probably this has to do with their work on the text renderer (which is even slower – ~1600ms – as it uses AA by default now).

It would be interesting to see how fast the Escher peers would run on hotspot. I’m thinking that a significant part of the performance gap between jdk5 and the escher peers is due to the performance of the VM itself as the escher peers and the shape renderer run comletely in java. Unfortunately it’s not trivial to port the peers to Sun’s JDK due to the few differences on the peer API. I’m still hoping that somebody will get hotspot running with GNU Classpath.