Openmoko [again] loosing some of their key engineers

I did not want to blog about it due to my intricate knowledge of Openmoko internals and my own past within the organization. But the news has made it to the various mailing lists now anyway: Andy e.g. is now longer working for Openmoko. He has been the main Openmoko kernel and bootloader developer (and maintainer) ever since I left in November 2007.

This is really sad news. There used to be really great engineers at Openmoko some time ago, but at least a number of good, senior folks are no longer working there at this point in time, or are working on a much smaller scope for Openmoko Inc.

Sure, it is not the right way to discuss the details of every HR matter in a public way. But I would have at least expected Openmoko to use the power they have to publish a statement on what this means _before_ the news get released in an out-of-control way by rumors and hearsay. If you allow this to happen, then you subject yourself to somebody else presenting their [distorted?] view of what he believes as reality first, and you (Openmoko Inc.) get into a defensive position.

OpenBSC:Work in handling incoming SMS

After returning from my holidays, I've spent the last couple of days hacking on improving the SMS support of OpenBSC. In order to facilitate the intended store-and-forward model, we now store all incoming SMS in a SQL table. Things like validity period or even more esoteric things like SMS compression as per GSM 03.42 is obviously still missing. I try to get it working fist, and leave the gaps to be filled later.

Next will be the code for sending a SMS from an entry in the SQL table, and invoking that code every so often, based on timers and/or events such as a phone registering to the network.

The trickiest part here is how to handle the paging code. We could have a phone call and a SMS, or even more events that all want to page a phone at the same time. There needs to be some kind of arbitration and a queue, deciding what kind of event will first get access to the SDCCH that we have after paging succeeded.

There have also been suggestions to split the SMS processing into a separate process, much like in a traditional GSM network. Sounds reasonable to me, but I am not very familiar with the existing protocols (like UCP) and implementations (like Kannel). So I'll probably leave that as a second step, making the OpenBSC internal SMS handling optional at some later point. UCP would obviously also ease the integration with existing SMS operators (vSMSC and the like).

FOSS.in/2009 event / venue / date announcement

Much earlier than in previous years, FOSS.in has announced the date + venue for the 2009 incarnation of the event.

The CfP is not out yet, but I hope it will also be out sooner rather than later, as scheduling long-distance travelling is something that most speakers prefer to do rather sooner than later. And you won't book your ticket before you know your paper has been accepted, etc.

I'm definitely looking forward to it. As the frequent follower of my blog will know, I've been there every year since 2003, which probably makes it the only conference (next to the Chaos Communication Congress) that I've been visiting that often in a row.

TomTom settles with Microsoft on patent dispute

They were acting quick. TomTom and Microsoft have settled their patent dispute. Of course, it's business as usual. They have to protect the interest of their shareholders, and a lengthy patent lawsuit is probably creating too much uncertainty for business partners.

I don't particularly mind them settling their [sometimes ridiculously trivial] claims on car navigation systems. But the settlement also includes the long-filename-patent that e.g. has been dismissed by Germany's Federal Patent Court about one year ago on the grounds of being too trivial and ISO9660 RockRidge constituting prior art. So given that the highest patent court in Germany has already issued such a judgement, I would be quite surprised to see a completely different verdict in the US. Either ISO9660 is prior art or not. I doubt there's much to debate on it.

So well, MS will still uphold their implicit threat against anyone who uses Linux + VFAT filesystem in a commercial product. In the end, I hope, this will simply drive people away from using FAT or VFAT altogether. It's not that they are particularly great filesystems anyway... and vendors just want to make it convenient for _windows_ users to use their products by enabling them with VFAT.