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
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
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.
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
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