Older blog entries for mjg59 (starting at number 66)

The Apple Public Source License is a GPL-incompatible file-level copyleft license. That's mostly irrelevant - what actually matters is that both the FSF and OSI regard it as free or open source.

So no problem, right?

Except that the APSL hasn't really caught on. Freshmean lists two whole pieces of APSL software. Both of them are derived from Apple code released under the APSL. That is, nobody other than Apple has chosen to start a project based on APSL code.

It's actually worse than that. Section 12.1(c) of the license automatically terminates your right to use or distribute the software if you sue Apple for patent infringement. Any patent infringement. Apple have infringed your new chip process patent? Better hope you don't rely on any APSL code. Apple's new TFT design copies yours? Better work on a replacement for Howl. Apple have stolen your entire motherboard design? Bad luck - using this code made it awkward for you to defend your IP.

As a result of this, the only significant APSL project (Howl) has effectively been entirely replaced by Avahi. Both Gnome and KDE adopted Avahi once it became stable. In other words, the only community projects using APSL code rejected it the moment there was an alternative - and the reason for developing Avahi in the first place was that several projects refused to ship APSLed code.

It's hard to claim that the APSL is regarded as an adequately free or open source license if almost nobody is willing to depend on code under it. In other words, the community has rejected the idea that it's really an open source license. But both OSI and the FSF lack any obvious mechanism of discussing decisions they've made.

Both OSI and the FSF have claims to representing the community. How does the community let them know that their views are at odds with it?

Joey:

While the public statements may seem oddly contradictory, you may be able to draw conclusions from the fact that I was recently contacted to help get the Ubuntu laptop support stuff into DCC...

Ubuntu in Iraq. His livejournal is pretty fascinating, too.

Userlinux is a Linux distribution derived from Debian[1]. It is headed by Bruce Perens, an ex-leader of the Debian project who resigned from Debian in 1998 because he didn't believe that Debian was going to be able to bring free software to the masses. Userlinux is intended to "Bring free software to businesses of all sizes" - the main argument here seems to be that Debian is a bit too anarchic for business to like, and so a rebranded and stripped down version with some sort of commercial backing would probably appeal rather more[2].

It's not an inherently bad idea. The problem is that Userlinux hasn't actually released anything since a beta some time ago. That's ok, though - it's because Debian hasn't got round to releasing yet, and they want to be based on a subset of a stable release of Debian. Fair enough.

Now, Userlinux aims to be a not-for-profit enterprise, but it also aims to sell certification, support and provide glossy boxed sets. This is all going to involve money, and the earlier Debian releases the sooner that money can be put in and start turning into more money that can in turn be used to make things even better. So you'd think that Userlinux would be busily investing in making sure that Debian releases in a timely manner.

But no.

In fact, Bruce has claimed that the contribution they've made to Debian has been limited to a few bug reports against d-i that were sent to Joey Hess, and the work of some volunteers who may or may not be doing anything useful[3]. In terms of code, the total Userlinux contribution to Debian has been pretty insignificant.

So, to break things down a bit:

• Userlinux aims to obtain certifications to allow it to enter the business market. These certifications are unlikely to apply to Debian
• Userlinux depends on Debian for its existence, but so far has not spent any money on supporting Debian
• Userlinux has so far not contributed any significant code to Debian
• Userlinux will provide support for Userlinux, but not for Debian

Or, in other words: Userlinux has, 18 months after it was first announced, taken from Debian and given nothing back.

One of the fundamental freedoms of free software is the freedom to be able to fork. Xandros, Linspire, Progeny, Ubuntu and others have all forked off Debian. The degree to which they've given things back varies, but that's not really the point. In free software, the freedom to take without compensation is important. That's not something I have an issue with.

My issue with Userlinux is Bruce's repeated insinuations that Userlinux is giving back ("We're trying to help"), while at the same time blaming Debian for Userlinux's failure to release ("There is nothing else but the Debian release on the critical path."). There's also the slightly odd situation where all development is going to take place within Debian, even though most of the people working on Userlinux aren't actually Debian developers. Given Debian's current model (maintainers have final say over anything that goes into their packages, unless they're overruled by the technical committee), this is plainly not going to work.

Userlinux currently does nothing to benefit Debian, and its stated aims suggest that that's not going to change in the future. It's another distribution that's based on Debian. Claiming it's anything more is simply dishonest.

[1] For some values of "Distribution" - the idea is that it would just be a subset of Debian with some extra branding, rather than a separate codebase

[2] Some would argue that this has already happened, and is called Ubuntu

[3] There are three entires in the Debian bug tracking system that mention Userlinux. Two of them are from the same person, and turn out to have been due to a VMWare bug. The third is a request to add some extra entries to the default Samba config file. It doesn't include a patch.

ACPI is often regarded as an evil pustule of ghastlyness, with some justification. On the other hand, it's got some good points. I've recently been playing with an HP nc6120. I found that pressing the lid switch would only generate a single event. After that, no more lid switch. Digging through the ACPI tables, I was able to find the method that notifies the OS that the lid switch has been pressed. Just before doing that, it cleared a bit in a PCI configuration register on the ISA bridge. Some more digging revealed that this was the bit that controlled GPE event delivery. Simple workaround: setpci the bit back on after every lid switch event. Problem solved. The bit also gets set if you query the display state, so I'm guessing that Windows does that on a lid switch event.

Given my previous adventures in biosland, I'm much happier digging around in aml than x86 assembler. So hurray for ACPI, which effectively opens the source to large parts of your BIOS. Now, if they'd just start licensing the tables under a free license...

Scott wants a Debian Project Leader who's more radical than any of the candidates. He's probably got something of a point. None of the platforms posted promise to overhaul the entire project, fire legions of delegates and damn well ensure that everything works.

So, why is this?

I can't speak for any of the others, but for me it's because I don't want Debian's future to be determined by a single person, no matter how much personality they have. I don't want a Bruce-style "This is how things are going to be" situation. I want the DPL to be able to act quickly and decisively, but in a way that reflects the views of the project. The DPL's opinions on whether a piece of software is free or not should be unimportant, with the same applying to whether a specific delegate is behaving acceptably or not or what the name of a new architecture should be. The DPL's job should be to recognise that there is a problem and ensure that it is solved, even if they don't agree with that solution. And yes, I am willing to make people unhappy to ensure that a solution is reached, even if the people I personally agree with are the ones that end up miserable.

So, the reason I haven't said how I'm going to solve specific problems inside Debian is because I don't know how they should be solved yet. In order to know how the specific problems should be solved, we need to fix the general ones. And while Scott may disagree, I think improving communication is by far the most important step in fixing things. Until people know why things are the way they are, it's difficult to work out what the solution is.

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.