Masayuki Hatta's Friends

6:27AM - Simple conference organisation suggestion

If you find the comments discussed here unacceptable, don't invite RMS to keynote at your conference without an explicit apology and expression of understanding from him beforehand. I'm seriously at the end of my patience with people being unwilling to call others on behaviour they perceive as unacceptable. Either make it obvious or accept that people will treat your failure to do so as implicit support.

Edited to clarify that I think the apology should be from RMS, not from people who invite him to keynote

4:17PM - Chrome OS

It turns out that I was entertainingly wrong a while ago, though I persist in claiming that this is an utterly ridiculous idea and I should be forgiven for thinking that Google were sane. The whole thing really still doesn't make sense to me. Worthwhile support of hardware is difficult. I'm going to take it as a given that Google aren't going to claim to support arbitrary hardware. People who would never otherwise try Linux will install it, and the state of many Linux drivers is sufficiently poor that it'd do a great deal to damage their brand. The logical assumption is that it'll be available pre-installed on devices where Google have worked closely with the hardware vendors.

Which concerns me somewhat. History isn't filled with compelling examples of this. Xandros's low-level support for the Eee mostly seemed to consist of a pile of shell scripts made of cheese and failure. The bizarro-Linux on the hilariously dodgy MIPS-based netbook I have is about as functional as my wisdom teeth. The best example of a Linux vendor working with OEMs is probably Canonical, and their enthusiasm for merging hardware support code in their OEM-specific distributions has led to things like touchpad gesture support based on using a known security hole or drivers that reimplement one that's already mainline.

What I'm trying to say here is that pretty much every desktop Linux product based on cooperation between OEMs and an existing Linux vendor has been built on top of a tower of shit. That's partly because it's a hard problem, but it's also because most OEMs produce dreadful Linux code and the Linux vendors don't have the resources to rewrite it in a clean way in the timescale permitted between hardware being finalised and shipping product. I haven't seen Google recruiting a larger than normal number of people with Linux distribution experience lately, so I suspect that the situation may be the same there. This is probably fine if the number of products is relatively small - there's an opportunity to QA them sufficiently to ensure that the rough edges underneath don't accidentally take someone's hand off. But otherwise there is a genuine risk that poor-quality devices will appear with Chrome OS and people will blame Google for the poor user experience.

So it seems like a risk for Google. Either there'll be a small number of devices and the same vague level of discontent that surrounds the fact that the number of shipping Android devices doesn't seem to have reached expectations, or a large number of potentially crappy devices. What's the payoff? It's pretty clear that this is going to be based heavily around Google's web apps, possibly with disconnected operation. That gets Google a lot of lockin. It also neatly sidesteps the entire disaster that has been providing application add-ons and updates for netbook Linux distributions. But it seems that Google could have achieved that by partnering with a distribution that already has experience in this field rather than going it alone.

I remain unconvinced that this is a sensible decision for Google. But then, I've already demonstrated that I don't have the faintest idea what's going on. Which probably puts me in the same field as most of the analysts I was bitching about before. Zounds. The irony.

12:54AM - Even Microsoft can turn out more clever

Maybe this will make the anti-Mono religious zealots shut their mouth.

Summary: there won’t be any patent claims filed against implementations of ECMA 334 (C# language specification) and ECMA 335 (CLI specification) from Microsoft. Now, the whole movie-plot scenario boycottnovell imagined collapses like a house of cards.

7:04PM - What does the desktop want from the kernel?

I'll be running a session on Wednesday at GCDS to find out what desktop developers would like to see from the kernel. There's a lot of interest in making things easier for file indexers, but if anyone has other problems that could be made easier with some level of kernel support then please turn up. No precise time or location yet, but probably around 3PM at the university. More details forthcoming.

5:00PM

One of the strengths of the open source community is that so much happens in the open. It's generally easy to find out what's happening in a project and directly interact with the developers. Code is out in the public. People frown upon closed discussion and implementation. But there's also a cost. Personality conflicts get hidden in the corporate world. We air them in public. And while in some ways that's arguably an advantage, it also results in things like this.

Now, to be fair, I've never been an especially big fan of Sam's work. His journalism generally leans towards lazy sensationalism rather than any attempt to actually understand the issues. He's not especially well versed on the basis of free software (see his assertion that the difference between the cathedral and bazaar development models is about project leadership rather than source code availablity and how people participate). He's managed to mischaracterise my opinions in the past, which means trusting his characterisation of anyone else is somewhat difficult. But that's not the point. Sam's article isn't about facts or analysis. It's about crucifying someone for expressing an opinion that Sam disagreed with.

I don't know Anirudh. From his website, he sounds like a pretty typical young hacker. He's contributing to a project that interests him. He's self taught. He holds strong opinions. And, last week, he published a rant on a topic he cared about - specifically his feeling that the patent concerns about Mono shouldn't prevent people from developing in it, and that RMS's statements about not using Mono harm the free software community more than they help it. I don't agree with all of his arguments. I don't think it was a hugely well structured rant. And, shockingly, telling RMS to fuck off isn't going to achieve a great deal.

But the point wasn't to change the world. People like voicing their opinions. I've done so several times on several occasions on a wide range of topics. People have disagreed with me. People have voiced concerns about the way I've expressed myself. People have flat out told me to stop being a cock. But nobody has attempted to tell me that I haven't earned the right to express that opinion. Nobody has expended four pages to tear me apart for daring to criticise another member of the community. Nobody has dared to call me a coward for deciding that I'd gone too far and modifying or retracting something I've written.

Yet that is precisely what Sam Varghese has done here. And let's be clear here - the use of the word "fuck" is a red herring. Sam is publically humiliating someone because he has his own agenda. He's picking on someone smaller than him because he can. He's explicitly stating that anyone arguing in favour of Mono can expect to be thoroughly abused in front of a large audience. In Sam's world I don't get to criticise the shockingly distasteful sexist remarks RMS made during his GCDS keynote because I didn't write emacs. I don't get to point out that ESR's understanding of racial genetics and natural selection are fundamentally flawed because I don't maintain the jargon file. I don't get to say that I think Ted Tso was wrong about ext4's semantic changes because I've never written a filesystem. And if I do any of these things, I can expect Sam to pop up and do his best to destroy my reputation.

Of course, he won't. Because in Sam's world, it's not actually about whether anyone has achieved great things. It's about whether the targets of his vitriol will be able to stand up for themselves or not. And while the truth is that nobody in the community is above criticism and nobody needs to earn their right to disagree, I doubt that Sam is ever going to show the courage that Anirudh did and publish a public retraction of his astonishing attack.

Shame on you, Sam Varghese.

12:09PM - Mono and GNOME/Debian Q&A

So many wrong statements were made in the insane troll about Mono, I feel that somehow I need to write some explanations about the current situation. So far the closest post to the reality was made by Tolimar but there are still some inaccuracies in it.

Q: Will Debian squeeze include Mono and Tomboy in the default install?

A: Short answer: yes. Long answer: in the current state of affairs, the GNOME installation media (which, remember, are far from being the only ones) will install tomboy if it is available. This might change depending on the feedback of the installer team and the CD team, but currently there isn’t a compelling reason to change this.

Q: Wasn’t it excluded from lenny because of problems with Mono?

A: There were two reasons to exclude Tomboy from lenny: the size, and the lack of support for some of our architectures. It has nothing to do with anything specific to Mono.

Q: What has changed since lenny that makes this situation evolve?

A: First, the size of Mono packages and of Tomboy itself was considerably reduced, thanks to awesome work from the Debian CLI team. Second, the availability of GNote means that architectures without Mono support can have a stripped down version (although this makes the situation far from ideal for these architectures, see next question).

Q: Why not ship GNote instead by default?

A: GNote was written for bad reasons, without even respecting the GPL copyright requirements. But more importantly, its maintenance model is going to make it only follow behind the Tomboy lead, as any code changes in Tomboy will need to be translated to C++. It also supports less languages and less features. Furthermore, it was introduced in Debian for political reasons, by a maintainer who doesn’t use it and isn’t involved in GNOME maintenance.

Q: Isn’t GNote much smaller?

A: Not really. C++ bindings are larger than CLI bindings, so the only real differences are the size of the Mono interpreter, and the size of translations. In the end, Tomboy with all its dependencies is only 10 MiB larger; that includes 3 times as many translations, and some important functionality.

Q: I disagree with this decision. What can I do to change this?

A: Get yourself seriously involved in either of Tomboy development, GNOME development, Debian GNOME packaging, or the Debian installer. Then, maybe your opinion will mean more than a troll on your pet free software news site.

Q: Tomboy should use Python / Vala / Java / Parrot / Lisp / (insert here your favorite pet language).

A: The developers prefer C#. While I’d personally appreciate if they could switch to a less controversial language like Vala (mainly because it would avoid trolls), I have no right to tell them to do so.

Q: Why is there a difference of treatment between Mono and Java?

A: Because there are about 30 applications using Gtk# in Debian, several of which are among the most popular in their category, while there is exactly 0 useful application using java-gnome.

Q: Is Mono free software?

A: Yes, it is 100% free software. Just as everything in Debian, it was scrutinized by FTP masters who found it is free. Most of the code is under the GPL, LGPL or MIT licenses.

Q: Are there patent issues with Mono?

A: Just like any other software, Mono certainly infringes on thousands of stupid software patents. However the Debian policy with patents is to put them in a trash and pee on them, unless they are actively enforced with reasonable chances to win. The situation of Mono is much more comfortable than (for example) that of MP3 decoders, for which patents are actively enforced; it’s just that they are so lame that we choose to ignore them.

Q: Are there specific dangers coming from Microsoft regarding Mono?

A: Microsoft has claimed to possess patents on some Mono compatibility layers with non-standard Microsoft APIs. Not only this is completely irrelevant to GNOME, since nothing in Gtk# and related stuff uses these compatibility layers, but if you know how things work in the patent world, you already understand this is merely FUD. Microsoft has nothing, but claims to have something in order to scare consumers away from Mono. Actually, not enforcing the patents, while knowing they are violated, would make their case very weak in a patent suit. What their behavior shows is that they are very afraid of Mono. It is stealing customers from their best and most advanced product, their lead development framework. There is absolutely zero chance that they are sustaining Mono from behind, since its very existence is going to make them lose a large amount of money.

Q: Would it make Debian uncomfortable if these patents were starting to be enforced?

A: In the very unlikely situation where Mono would be found to infringe on valid Microsoft patents, we would simply have to remove it from the Debian archive. We are not short from alternatives, and it wouldn’t be long before we had drop-in replacements in Vala or Python.

Q: What is the agenda of Roy Schestowitz, Sam Varghese, Robert Millan and their friends?

A: What they are doing is giving credit to the Microsoft FUD in order to also scare consumers and developers away from Mono. They want to scare them away to other free software environments, but what they achieve is scaring people away to buy Microsoft products instead. It is tempting to conclude, because of the result, that they are employed by Microsoft underhand, but applying Hanlon’s razor, I think they are just incredibly incompetent, to the point where they are dangerous. These people are toxic to the community, and we really need them to shut up. If they ever reach their goal and destroy a great piece of free software like Mono, they will go on and find something else to destroy. Remember, their goal is to SDD: scare, disrupt and destroy. You cannot build anything useful or interesting with such goals.

Q: But Richard Stallman says they are right!

A: RMS is also the guy who wants us to ship non-free documentation. I don’t think RMS has enough connection left to the real world for his opinion to be considered relevant.

2:41PM - Advisory Board Election Winners

And the Winner Is . . .

The votes have been tallied, the results are in, and we have a winner (two, actually). Congratulations to the newly elected user representatives to the LJ Advisory Board: from lj_election_en, it's kylecassidy, and from lj_election_ru, it's nekbke! You can see the full breakdown of results for lj_election_en here and for lj_election_ru here. Thanks to everyone for your participation.

7:19PM - Introducing dh_devlibs

Ever noticed how the dependency fields of development library packages are tedious to maintain? They are often:

• out of sync with the build dependencies,
• outdated regarding the actual requirements of pkg-config files,
• and of course incorrect whenever libtool decides to add tons of unneeded dependencies.

In order to improve the situation a bit, I have written a debhelper script to handle development libraries and generate automatically these dependencies in a ${dev:Depends} variable, using the pkg-config information. I have requested its inclusion in debhelper, but in the meantime, I’d appreciate if people could test it against various library packages so that its potential bugs can be fixed; this could surely convince Joey to accept it faster.

Here you go: dh_devlibs.

The next step in this direction is to do some automatic validation of build-dependencies. The first approach I thought of requires some improvements in pkg-config, but given how this package is maintained, I’m afraid it will require some time. There are other possibilities involving diversions, so it is still possible that something good comes out of this.