Who needs Microsoft’s FAT?

Hydrogenated, unsaturated fat and cholesterol are long enemies of the public, but recently a new type of fat has been added: FAT.

Microsoft has filed a patent suit against TomTom about its FAT implementation on their Linux satnavs. This is a bit of a long story and Microsoft is not tired yet. Probably because of the recent losses with patents, they’re trying to get some profit for themselves.

Luckily, there is hope. The guys at End Software Patents can see some light at the end of the tunnel. Looks like the Bilski case can give precedence for rejecting the lawsuit of that (and many other stupid patents they’re claiming) based on the tangibility of mathematical algorithms (software) when they’re not particularly tied to any concrete implementation (hardware).

This was how it was done before in the US until the first case passed through that wasn’t attached to any particular hardware and then with the final revision in 1998 that they could patent even cake recipes.

Why not ditch it for good?

So, FAT is rubbish, 30 years old and close to zero evolution since then, why keep it? It’s true that there are many other filesystems around, much faster, safer, optimized and well designed, but FAT still has its market: on embedded devices. Because it’s simple and stupid, it’s quite easy to support it on very small machines with reduced RAM and CPU power. It’s also light-weight and fits well for small flash cards and USB storage. But the biggest reason to keep it is another: Microsoft supports it since its birth.

Would you buy an SD card that needs to install a driver to make it work? What’d be the point?

Yet again, because of the market domination (and not technical merits), Microsoft forced rubbish down everyone’s throats live for longer that it was expected. And now, they’re trying to get the profits by suing everyone that followed them for decades. What a nice way to say thank you!

Speaking of which, not only they’re happy by suing companies by using Linux (TomTom in this case and many others during the FAT fight), they’re also asking for the open-source community’s help to make Visual Studio 2010 a better product, isn’t that nice? How lovely is the American way of life, I guess the world will never be able to thank them enough.

Happy 1234567890!!

It has just passed the Unix time 1234567890! (or, if you prefer, 0x499602D2, which is not funny at all).

Friday, February 13, 2009 at exactly 23:31:30 (UTC, which I happen to be), is a nice Friday 13th (already spooky).

$ perl -e 'print scalar localtime(1234567890),"\n";'
Fri Feb 13 23:31:30 2009

I suppose you have a Unix at home, of course. Well, you probably do anyway…

Other fancy Unix dates to come:

$ perl -e 'print scalar localtime(2000000000),"\n";'
Wed May 18 04:33:20 2033
Next billionth second…

$ perl -e 'print scalar localtime(0x7FFFFFFF),"\n";'
Tue Jan 19 03:14:07 2038
As far as it can go, with 32bit signed integers…

And some other that passed already:

$ perl -e 'print scalar localtime(1000000000),"\n";'
Sun Sep 9 02:46:40 2001
The first billionth second:

And finally some before the Unix era:

$ perl -e 'print scalar localtime(0xDEADBEEF),"\n";'
Mon Apr 14 15:27:43 1952
Well, 0xD has the sign bit set, doesn’t it? It’s in the past too…

$ perl -e 'print scalar localtime(0x80000000),"\n";'
Fri Dec 13 20:45:52 1901
As far as it can go in the past…

But don’t worry, 64-bit systems can already (and do already) manage times up to 9223372036854775807 seconds back and forth 1st January, 1970. It’s plus and minus 292 million years. It’ll be good to tag even dinosaurs with Unix-time, as well as the Enterprise next-generation.

The only problem is that the two final catastrophes we can’t get rid of: sun becoming a red giant (thus engulfing all planets, or the Milky Way colliding with Andromeda, will happen in no less than 5 billion years from now, which means that we’ll need to change to 128-bit time-stamp eventually.

Happy unix-time 1234567890!!