Older blog entries for mjg59 (starting at number 60)

titus - you're on crack. I did a decent amount of comparative genome work using (coincidentally) Emboss and NCBI's BLAST, and (a-ha ha ha) scripted it all in perl. If they'd been GUI applications, I've no idea how I'd have scripted them. The XTest extension, perhaps.

The reasons that scientists write bad code is that scientists are not paid to write good code. Nor are they generally taught what the difference between these two things is. While it would be charming to think that it's obvious that science would benefit from doing it properly in the first place, it's hopelessly naive to believe that funding bodies see it that way. In most cases, they won't buy the "if we spend more time and money on it now, it'll save money on this grant extension that you may or may not give us" argument.

On the other hand, "Survival of the flattest" was a fun paper.

On the other other hand, any conclusion which is something along the lines of "This social and technical problem will be solved by using this language in future" is about as convincing as my Japanese.

Neat evolution hack of the day:

If you want to be able to synchronise your calendars on multiple machines, simply symlink your calendar.ics files into public_html and then add each calendar to the other machines. You'll only be able to add data locally, but this shouldn't matter.

Scott Wheeler explains things well.

The current debian-legal entertainment is about whether the following claim:

"Firmware is software if it's stored on disk, but becomes hardware if it's copied into an eeprom"

is crack or not.

Sun

The CCHPCF had a visit from Sun today (we have a stupifyingly big fuck-off F15K with 900 CPUs, so Sun are nice to us), with lots of juicy information about all sorts of exciting things. Unfortunately, I'm not allowed to tell you about any of them. I can tell you about the free wine, though. It was very nice.

(hic)

Debian

Murray wonders why Debian's so poor at being seen to do stuff. He's not alone, of course. The problem is fairly simple:

We don't talk to each other enough.

It may not be clear to the outsider, but Debian is effectively built up of several groups of people working quite separately. The ftp-masters are a group that deals with the day to day business of accepting new packages into the archive. The security team spend their time dealing with new security announcements, backporting fixes and getting these built and pushed out to users. The buildd maintainers look after the network of machines that build packages for all the supported architectures. Various other groups of people do important tasks. And all of these groups sit in the general sea of developers.

Everyone has one goal - to see Debian released.

Of course, everyone blames a different set of people for it not having happened.

A release can't happen until all of these groups (and yes, that includes the developers in general) believe that a release can happen. But since there's always another group that is plainly holding everything up, there's not all that much incentive to make sure that your group is in a fit state to release. This has predictable consequences.

Once upon a time, this was less of a problem. We had far fewer people involved in the project, and it was practical for everyone to talk to each other and let everyone know what they were up to. This doesn't scale desperately well - Debian now has around a thousand developers, which is getting beyond the point where you can even vaguely recognise the names of all of them. The fact that Debian achieves anything is probably due to the fact that there's some overlap between some of these groups (the fact that it's this overlap that seems to come in for the largest degree of criticism is interesting, and probably significant).

Enhanced communication between everyone involved would probably make life massively better. We just need to work out how to do that.

While I'm at it, though:

Matthew's big list of myths about why Debian hasn't released

• The installer isn't finished: It probably would be if more of us contributed usefully.
• There are too many RC bugs: There wouldn't be if we fixed them.
• Our users don't like short release cycles: Rubbish. Our users don't like stuff becoming unsupported shortly after they install it, which is different. We don't actually fulfil that, in any case - the length of time that we supported Potato after Woody was released was sufficiently short and announced a sufficiently small period in advance that companies would have been screwed. It's more important to know when something is going to be unsupported than it is for it to be supported for a massively long period of time, and it's entirely possible to support something without it being the current release. What version of Debian would you recommend to a corporation at the moment?
• You can't expect volunteers to do stuff on any sort of rigid timescale: Gnome sort of disproves that. But yes, it's true that you can't oblige volunteers to do stuff - what you can do is make it clear that if they're not interested in helping achieve the desired goal that their assistance is not required.
• It's Ubuntu's fault: If all the people employed by Ubuntu had been hit by a big bus, would we sit around bitching that the bus driver has prevented Debian from releasing, or would we get on and do it?

  Actually, don't answer that.

• It's their fault: No, it's our fault. All of us. Well, nearly all. There's a small set of people who care sufficiently about Debian that they put the rest of us to shame - people who will put themselves through immense pain and unhappiness to see Debian get closer to a release. The rest of us sit around and bikeshed at length, then complain that the people building the core of the atomic reactor haven't got everything done yet and are holding up the building of the bikeshed. Frankly, we should be ashamed of ourselves. I'm as guilty as anyone.

If Debian is going to continue to be relevant, we need users. If we're more concerned about casting blame, we won't have any. So go on. Get out there and fix some bugs. Show the world that it's possible for a group of a thousand volunteers to produce a world-class OS. Just stop spending so much time claiming that the release will never happen and it's all someone else's fault.

Beagle makes me happy

Sven: Recent 2.6 kernels seem to have xfs issues, independent of the distribution. I'm not quite sure what's going on there.

Released a newer (working!) version of Culchie. If you've ever wondered how well your GTK application would stand up against a horde of drug-crazed maniacs with no concept of how to use a computer but a very well-formed desire to use it as much as possible, here's your answer.

I've written a small application that uses the GTK accessibility layer to do brute force stress testing of other programs.

1. Get http://www.codon.org.uk/~mjg59/tmp/culchie-0.0.1.tar.gz
2. Extract and make
3. Ensure that accessibility is switched on
4. Run it and focus the target application
5. Watch it (potentially) explode

Once upon a time, there was a license. It was intended to be a free software license. It would allow people who received software licensed under it to know that they could modify and redistribute that software without that right suddenly being removed by the copyright holder. However, in contrast to other licenses at the time, it would make one very specific limitation on the freedoms that you had. Rather than allowing you to modify software and then distribute your modified (and potentially better) software without source, any derived work of the original software had to include all of its source code. This license deliberately limited your freedoms in order to ensure that other people had the freedom to modify your derived works.

The license was the Emacs General Public License, and it was released in 1985. In 1989, a generalised version that could be applied to any software was released. This was version 1 of the GNU General Public License. By 1991, it had been tidied up and clauses 7 and 8 added. Version 2 of the GPL is still in use today.

Unfortunately, it's difficult to tell what the immediate reaction to this style of license was. Usenet seems to have been less important back in 1985 - Google Groups has a surprisingly small amount of discussion. What there is suggests that people had much the same opinion as now - various people disliked the removal of their freedom not to supply source, some disliked the idea because they wanted those they redistributed it to to be able to distribute without providing source, and some people loved the idea that copyright could be used to protect people's access to the source code.

It's now the best part of 20 years later. Nobody seriously suggests that the GPL is anything other than a free software license nowadays - at least, nobody within the free software community. But the world has changed since then. Patents are now used in ways that restrict the usage and availability of free software. In an analagous way to the GPL's use of copyright to protect against one threat, people are now writing licenses that attempt to use copyright to discourage patent suits. The Open Source License and Mozilla Public License both attempt this by removing some or all of your rights in response to a patent suit.

Of course, this is another restriction on people's freedoms. Those in favour of these clauses would argue that the right to sue someone over a software patent is like the right to provide software without source - permitting that right reduces the rights of others to utilise free software so much that the world is a better place without that right. Others argue that allowing further rights to be removed results in the software no longer being free - why should someone lose the right to use a piece of software just because they want recognition of their legally held patent?

Where do we draw the line between allowing and protecting freedoms?

Hacked on netapplet, that fine and outstanding piece of work from Rob Love and Joe Shaw. For code that's touted as being Suse specific, there are only three functions that need any amount of hacking at all. I've put a Debian compatible version here. It seems to work well for me - it'd be nice to know how well it works for others.

Frankly, with code like this it's easy to see why Rob's book broke so many sales records, and why Joe is not only Novell employee of the year but tipped as the outside chance in the US presidential race. Regardless of the outcome, I look forward to seeing him on the Gnome foundation board next year.

Debian-legal continues to fascinate me. On the one hand, it's done a massive amount of good work - large sets of software have been relicensed under Free licenses, and in some cases licenses themselves have been rewritten in order to avoid unintended reductions of freedom.

On the other hand, many of the regulars seem unhappy with the makeup of the Debian Free Sofware Guidelines. One thing that's often overlooked about the DFSG is that they aren't purely a list of freedoms that Debian considers necessary. The document also contains a set of explicit compromises - points which we can look at and say "Yes, it would be nice if that weren't the case, but that level of freedom is good enough anyway". Clause 4 is an explicit compromise based on the fact that patch clauses make life awkward but don't really prevent you from doing anything (anyone who claims that they do isn't being imaginative enough when it comes to build systems). Clause 1 has a fudge for the Artistic license.

Now, oddly, while it would obviously be socially unacceptable to say things like "I think DFSG 3 should be removed", the same doesn't apply to DFSG 4. I find this interesting. I agreed to the DFSG because I believe they strike the right balance between freedom and pragmatism. And, fundamentally, as an operating system Debian depends on both of these things equally. Until the point where there is a clear consensus that the DFSG's line is drawn in the wrong place, we should reject efforts to compromise these practicalities to the same extent as we would reject efforts to compromise the freedoms that we consider so important.

There are already signs that this is a problem. It's been suggested that copyleft licenses (such as the GPL) are only free because they're explicitly mentioned in DFSG 10. While I see the DFSG as defining a fairly straight line, others see that line as being somewhere further out to the side with clauses 4 and 10 being bulges that stick out to grab certain items that were considered strategically useful at one point.

Part of the problem is that it's not clear where the majority of developers do see the DFSG's free/non-free line as being. I'm inclined to think most would be closer to my viewpoint, but I have no way of telling. When Debian was smaller, it was more practical to establish this - the original Social Contract discussion only generated a couple of hundred or so emails. Nowadays people don't want to talk about it, which is fairly unsurprising given that any mention of the DFSG nowadays is fairly doomed to spark a few hundred mails with approximately no information content. I'm not sure how to solve this. Bruce's attitude would probably have been to just write a policy statement and get people to agree to it - is that sort of thing still possible? Is Debian too big for us to get a majority of people to say "The line is here, even if I don't necessarily think it should be"?