Closed PITA

I’m going nuts! I have a piece of software here, that segfaults somewhere in a proprietary video driver (but runs fine on all free drivers I tried). I still think it could be a fault on my side (after all it runs fine with Sun’s JDK on that same video driver). However, it is really hard to find out because that driver doesn’t ship with source code, nor does it have debug symbols in it (at least, that’s how it appears in GDB). The world would be so much easier when the source code would be there. Not that I would try to fix the driver (ok maybe I would), but it would be nice to know _what_ is going wrong here.

That makes me think that (I heard that) there are software developers who are stuck developing mostly with closed software and libraries and things like that. I wonder how they can reasonably get anything done? What are they doing in such a case? Calling some hotline and tell them to please fix the segfault?

Ubuntu Feisty released

Today the release of Ubuntu 7.04 was released. I’ve been using the beta for a couple of days and must say it’s a nice release. I won’t repeat the highlights, those are described in the release notes.

There are some interesting and surprising moves:

  1. A complete Java stack is available in the multiverse (aka non-free) repository, consisting of JDK6, Glassfish and Netbeans packaged up and ready to use. According to the announcement, all this is considered to be included in the core as soon as JDK6 is completely available as OpenJDK. Nice move IMO.
  2. The next release will spawn a new ultra-orthodox Free Software only flavor of Ubuntu, apparently based on GNewSense. Another nice move. Although for the time beeing it’s relatively easy to remove all repositories except main and universe..

Congratulations to the Ubuntu community!


I’m now officially Dipl Inf. Not that this means anything to anybody except me maybe… 😉

Sleeps With Angels

I’d like to write up a little review and background to this marvellous album, for a couple of reasons: It was the first Neil Young album that I bought back when I was 16, and it’s still getting better each time I listen to it. It changed how I listened to music and it started my Neil Young addiction ;-). Kurt Cobain’s death was 13 years ago some days ago on april, 8th. And I heard, Mario bought this CD, so I better give him some hints on how great it is …

Sleeps With Angels

Read more of this post

My first JDK bug

Hopefully, in a month or do, I’ll be able to do something about it. Like fixing it. 😉

In the meantime I created a Mauve test that covers this and fixed up the GNU Classpath implementation (which didn’t fail in this particular case, but screwed on a much higher level).

Escher ideas

During the last couple of weeks I worked on Escher only every now and then. I re-architectured the protocol implementation so that the object creation is minimized. Before this change Escher created one small array per request, which can have a pretty noticable impact when rendering. Now there is only one buffer into which all requests are written. This brings a pretty nice performance gain. I’m finishing this step off now (this will take another couple of days or weeks even). However, I’m happy that I have a little more spare time now (finished the study, yay!) and can continue on Escher with more drive now. Here’s a bunch of ideas what I could do in the future:

  • Avoid even more potential copies by using NIO channels. A socket implementation might require copying the passed-in byte[] on the native side. NIO channels allow to pass in a ByteBuffer which can be backed by the correct native data structure already, thus avoiding the need to copy the buffer from a Java array to a native array. Going the NIO route seems to have a couple of other advantages too (e.g. avoid polling for inbound traffic).
  • Right now, Escher is made to be completely thread safe. This is basically the same mistake as was designed into AWT. The problem is that many applications don’t need this thread safety at all and could rather implement single threaded rendering and avoid acquiring locks altogether. Another point here is that applications that do render using multiple threads usually can do the locking much more efficient, e.g. acquire a lock once, render a complete frame (or some other logical unit) and release the lock once, rather than acquiring and releasing the lock on each little graphics primitive. The plan here is to drop thread safety on outbound X traffic (e.g. rendering) and only protect inbound traffic (because this is most often handled by a separate (event) thread anyway AND the main thread (for X replies).
  • Make Escher implement the JOGL interfaces ( This way, Escher could be used as a direct replacement for the standard JOGL implementation on X based systems. It is my hope that this implementation is at least as efficient as the original JOGL one, or even more efficient because native calls are avoided altogether (or at least, performed more seldomly, that is when the buffer runs full and is flushed to the network).
  • Add tesselation (and other utilities). Without tesselation, OpenGL isn’t able to render complex shapes at all. This feature can most likely be provided by the plain JOGL classes and don’t need to be rewritten. This would go hand in hand with the previous point.

Furthermore, I hope I can put more work into the Escher based AWT peers and polish them up for real use. Most importantly, this requires better TrueType font support (by the Java font impl in GNU Classpath), better AWT widget support (by the Swing backed AWT widget set) and a shitload of bug fixes in the peers and Escher itself.


free software story. Read for yourself.