Leading items

The value of middlemen

Creators of Linux distributions perform a number of useful functions. They go out and find useful free software for their users. They put together a nice packaging system so that all that free software can be managed without going nuts. They ensure that the programs all fit together in a coherent design of the system as a whole. They create nice CD images for the distribution of their work, and installer programs so that all that software can be loaded onto your systems. Distributors run online repositories, create security updates, and, sometimes, even answer questions from users who are having difficulties.

Users may not fully appreciate another role filled by Linux distributors, however: they serve as middlemen between the producers and consumers of free software. This work goes beyond packaging programs and feeding back bug reports; Linux distributors also serve as crucial advocates for their users. When developers fail to act in the interest of the people using their software, the distributors can come in with their advocacy and patching skills to improve the situation.

A good example of how this process works was brought to light via a long and unpleasant linux-kernel discussion involving Jörg Schilling, the maintainer of the much-used cdrecord program. For the curious, the thread starts with this message. There are several issues discussed, but much of it comes down to some fundamental disagreements between Mr. Schilling and the Linux distributors on how cdrecord should work.

For example: in the 2.6 kernel the preferred way of performing raw SCSI operations on a device (which is how CD burning is done) is to simply open the device directly and issue the right ioctl() calls. So, if your drive is /dev/hdc (or, better, /dev/cdwriter), you run cdrecord with dev=/dev/cdwriter and be done with it. Mr. Schilling swears that the only proper way to specify the output device is via SCSI bus, target, and unit numbers - despite the fact that most of these devices do not sit on a SCSI bus and have no such numbers. And despite the fact that figuring out that, say, dev=0,2,0 is the right magic sequence to type is not something many users want to do. So cdrecord issues a set of scary warnings with the "open by device" mode is used, despite the fact that it is the best way to do things.

Another example: some users have a strange idea that they might actually like to write DVDs on their DVD-capable drives. The official version of cdrecord has no such capability, and Mr. Schilling has refused to add it. Some of the more cynical observers have noted that the fact that Mr. Schilling offers a proprietary version of cdrecord with DVD support may have something to do with this refusal.

Users of cdrecord could try to address these issues directly with its author. Experience has shown, however, that this can be an unpleasant and unrewarding process.

This is where the distributors step in. A quick check in the latest Fedora source RPM for cdrtools shows a good dozen patches; these vary from small documentation tweaks through to DVD support and the removal of unnecessary, scary warnings. Other distributors have done similar things. The end result is that users get a version of cdrecord which works as they would expect, while the distributors take the heat (and there is some heat) for the changes that they make.

Mr. Schilling has given us a true gift: the cdrecord program embodies a great deal of knowledge of just what is required to make a wide variety of CD writers work on numerous operating systems. We get to make use of that knowledge because Mr. Schilling has released his work under the GPL. Before criticizing him too much, it is good to reflect on the value of that gift. But this is also a good place to appreciate the extra value added by the Linux distributors. Sometimes a middleman is just what is needed to make the whole process work.

Comments (31 posted)

Sarge is coming

Sarge is, finally, approaching. Last week, Steve Langasek announced a proposed timeline for Sarge and that Anthony Towns had stepped down as release manager for Debian. Langasek and Colin Watson are filling the post for the Sarge release. According to Watson's follow-up on Saturday, the release target for Sarge is now September 19. Joey Hess also announced release candidate 1 of the new Debian-Installer for Sarge on Saturday.

With the release so close at hand, we decided to take a look at the state of Sarge. We touched base with Langasek on the status of the release, and also asked Towns for comment on his decision to step down. In Langasek's announcement, he alluded to "the recrimination and hostility towards some of our most dedicated developers" as a possible reason for Towns' departure from the release manager post. Towns declined to elaborate on his decision to step down from the release manager position, but said that Sarge is in good hands:

We also asked Langasek about the statement, and whether he feels that the internal conflicts in Debian have gotten worse.

With that unpleasant topic behind us, we also asked Langasek about the release schedule, and whether the schedule was realistic.

Our brief tests of the RC1 of the Debian installer were quite positive. The installer is still a text-based system, but consists of a fairly easy set of choices for the average Linux user to follow. We tested RC1 on a dual-PIII Xeon system, and tried out both the normal and "expert" installer modes. Users have the choice of installing the 2.4 or 2.6 kernel in either mode. The "expert" mode is largely unnecessary unless one wants (or needs) to dabble more directly with the kernel modules that are loaded or if one wishes to experiment with installer modules that are not part of the default installation.

The new installer also offers to partition the disk for the user, no doubt a welcome addition for many Linux users who aren't familiar with disk partitioning. The user has a choice between an all-in-one partition, a separate /home partition, or a multi-user partitioning scheme if they choose to let the installer do the work for them. Both the /home and multi-user schemes provided sane partition layouts on a 40GB disk, using the Ext3 filesystem. We might have chosen more swap space (the installer opted for 512MB on a system with 1GB of RAM), but both partition layouts were quite usable.

The hardware detection worked fine for the test system, though the system admittedly contained a sparse selection of components -- an add-on IDE controller, network card and generic video card, PS/2 keyboard and mouse, no sound card. This writer found it very nice not to have to know which module is appropriate for the system's network card while in the middle of an install.

Users have the option of choosing packages manually, or selecting from seven pre-selected groups of packages like "desktop," "Web server," and "DNS." These can be mixed and matched, so users who want a print server and desktop in one machine can choose both at install time. The desktop set of packages provided both the KDE and GNOME desktops, and a fair selection of desktop apps and games.

There were only two things we didn't like, overall and neither can rightly be considered a bug -- though there is a bug report for our first complaint. Though the machine in question is a dual-CPU machine, neither the normal or expert install gave the option of an SMP-enabled kernel. Though it's not at all difficult to download a suitable SMP kernel (or compile your own) it's an additional step that should be unnecessary.

Likewise, it seems to this writer that OpenSSH should be installed by default on any network-connected system. While not difficult to do after the fact, one would think that including OpenSSH is a no-brainer on almost any Linux system. It is certainly as likely to be used as wget or nano, which are installed by default.

Those are extremely minor grumbles, however. It appears that Sarge is just about ready to make its debut. The schedule is a bit ambitious, but it doesn't seem unrealistic based on our tests of the RC1 of the installer and packages now in testing. Langasek asks that users start banging on the new installer and install manual to help the process along:

And, of course, Langasek asks that users report bugs wherever they find them "particularly if they're using testing or unstable". As users are trying out the new Debian installer, they might wish to read the d-i retrospective, which recounts the history of d-i and gives perspective on the work that went into the installer. Langasek says that the work has paid off:

Indeed, this writer is enthusiastic about the installer as well. Though the old installer was usable enough (as evidenced by the enormous Debian user base), the new installer is much improved. The final Sarge release should do a great deal to help Debian's popularity with newer Linux users.

Comments (11 posted)

Munich and software patents

As was covered here last week, the high-profile Linux deployment in the city of Munich has been put on a temporary hold while a legal review of possible patent threats. This hold is a direct result of two motions filed recently by a Green Party alderman in the city. The motions, and their aftermath, have created a small storm, both in the city of Munich itself, and among free software advocates and anti-software patent activists. Those who oppose the transition from proprietary to free software in Munich took the opportunity to put a spanner in the works, and that prompted swift reactions from free software advocates; the events seem to have created some stress between the free software and anti-software patent communities.

The motivation behind the alderman's motions was simple: to persuade the city of Munich to put more pressure on German and European politicians to stop the EU's directive on the patentability of computer-implemented inventions. And insofar as they aimed to raise the problems associated with software patents among German politicians, they have met with some success. The city of Munich does appear to remain committed to its free software project, and despite speculation in the press, the only thing about which we can be certain is that, as LWN commented previously, the process will be slowed down while the lawyers do their thing. The latest word is that the delay may not last more than a few weeks.

So why, then, did the Free Software Foundation Europe feel compelled to issue a press release emphasizing that free software is no special case, and that the dangers posed by software patents affect all small and medium enterprises and projects, regardless of their licensing? I asked FSFE President Georg Greve whether he felt that the Green party should be condemned for its actions, and whether the FFII, which could be accused of spreading the flames with a widely-reported press release of its own, should be included in that as well. Mr. Greve described "condemnation" as "too strong a term," but it is clear that they aren't too happy, especially given that they have been actively campaigning against software patents for four years without jeopardizing free software deployments. He asked:

In response, the Green Party in Munich notes that it is software patents which threaten free software, and not anybody's attempts to fight the imposition of patents. Ignoring the patent directive, they say, would be far more dangerous than forcing this sort of confrontation.

As Tim Bray noted in his weblog, almost all software in the market probably infringes on some existing software patents, and the issue is one of financial resources (i.e. the ability to defend a case in court), not one of licensing. Greve claims that "[the] link is entirely artificial".

Bizarrely, part of the explanation of events lies in a mistake within the FFII. The study that lists the patents that affect the Munich project was never released as an FFII study; rather, it was a personal document on an FFII member's homepage. Harmut Pilch, the President of the FFII, wrote that he was "surprised by the announcement of Wilhelm Hoegner and the mayor", and that he "learnt from both only through the media". Nevertheless he goes on to defend the message given out by the Green Party, if not the exact methods they used, pointing out that the city of Munich had to assess the risk caused to its project by software patents.

The fallout of all of this is difficult to predict. We can be fairly sure that, barring an extraordinary risk assessment by the city of Munich's lawyers, their Linux project will go ahead. But it's impossible to judge the impact that the news will have on the vote in European Parliament later this year, and on other government projects involving free software. However, if the EU says "no" to software patents, the free software community in Europe could be saved from, possibly, the most damaging legal framework seriously considered to date. The knock-on effect in other countries and trade areas also can't be underestimated. So if steps like those taken by the Green Party in Munich can derail software patents in Europe at the expense of delaying, or even stopping, various free software deployments in government, would it not be worth the sacrifice? In this light the Green Party's actions seem like fine political ju jitsu.

An implicit assumption in that question is that the Green Party's initiative can be followed elsewhere. The only other example of a major deployment of free software in government in Europe is in Extremadura, where local politicians are already firmly against software patents. Employing this sort of technique elsewhere must be done carefully: emphasizing the software patent risk to free software could end up turning politicians against free software, rather than patents. A compromise approach, as Greve suggested, would be:

It may be too late for effective damage control in Munich, so we will have to wait for the outcome there. But in the future, it would seem wise for anti-software patent activists to be mindful of Greve's suggestion. Free Software advocates must fight software patents, and we must recognize that they are more important than individual deployments of free software. But all the same, we mustn't unnecessarily prejudice politicians and those who make technology decisions against free software for the sake of gains in the fight against software patents.

Comments (5 posted)