Summary: Workaround created to dodge FAT patents, but why is Mono learning nothing from all this?

FAT Lessons

FOR THOSE who have not seen the details yet, Groklaw published "Tridge -- Subject: [PATCH] Add CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES option"

It is already covered bt Heise.

A new patch to the VFAT filing system in the Linux kernel adds an option to disable the creation of files with long file names.

This is all happening whilst OIN at al attempt to invalidate those patents (e.g. using prior art), which directly refer to something Microsoft implemented. That initiative is still on.

We're all familiar with the MS vs TomTom case regarding FAT patents. While that has settled, there appears to be some consequential action from this case...

From this whole thing we not only learned but were also given evidence to show that Microsoft is not interested in "interoperability"; it's all about what we previously called "taxoperability" [1, 2, 3, 4, 5, 6]. A few days ago, a Microsoft-loving Seattle-based Web site wrote about Ray Ozzie's spiel on "devices, startups, IP and open source."

"IP and open source..."

Where Microsoft assumes that open source (not Free software) is all fine and dandy with software patents and apathetic towards Microsoft products/protocols that are plagued by this. As long as this "open source" thing only enriches and helps sell more copies of Windows, then Microsoft won't go hostile. It's attacking Linux for the most part. As Steve Ballmer put it in 2007, "I would love to see all open source innovation happen on top of Windows."

That's why they specifically attack GNU/Linux, which Ballmer compared to "cancer". And that's why it's foolish to put a hopeless copy of .NET inside GNU/Linux. It might not be long before Microsoft uses that too as an excuse to knock on people's doors and demand patent tax (or otherwise force Mono-built applications to change, which would not resolve the API riddle).

Jonathan Corbet Likes Gnote?

Gnote is still receiving quite a lot of press. The editor of LWN.net is offering a good word to Gnote for technical merit, but he is almost totally ignoring the problems with Mono itself.

Some people have complained about its faults for a while; Hubert Figuiere, instead, chose to do something about it in the form of the Gnote utility.

[...]

So what are the problems with Tomboy? For your editor, at least, the biggest issue is the simple sluggishness of the tool. It is a large program which takes quite some time to start up. If one tries to bring up a note on a system which has been used for other things, there can be a lengthy delay before the menu from the taskbar icon appears. Rightly or wrongly, users blame this fundamental slowness on Tomboy's use of the Mono platform. Now, of course, use of Mono brings in a whole host of other complaints, but we need not consider those here. The simple fact is that Mono adds a great deal of baggage to what should be a small and simple application. A basic note-taking tool should not be a heavyweight program.

Gnote is a reimplementation of Tomboy's functionality using C++ and GTK+. In a sense, though, it is not an independently-developed application. Instead, Gnote is a straightforward port of the original C# code to C++.

The point to be added is that it's not about performance, which too is an advantage. There is a recurring theme in the pro-Mono blogs which portrays Gnote as just a matter of changing programming languages for the sake of it. Regardless of the real motivation, these people conveniently hide what matters to us a lot more: the issue of programmer control and legal control. If this is not a simple concept for Mono enthusiasts to grasp, then previous posts about Gnote and the Mono/FAT issue might be required reading [1, 2, 3, 4, 5, 6]. ⬆

"I saw that internally inside Microsoft many times when I was told to stay away from supporting Mono in public. They reserve the right to sue"

--Robert Scoble, former Microsoft evangelist