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
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, finally, approaching. Last week, Steve Langasek
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
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:
I've got complete confidence that Colin and Steve can do a better job
getting sarge out than I could, and are doing so. They might think
differently, but if so, the resolution to that little quandary is quite
simple: they're wrong. :)
We also asked Langasek about the statement, and whether he feels that the
internal conflicts in Debian have gotten worse.
For my part, I'm well aware that there's always a certain amount of
off-topic digression and conflict on the mailing lists -- this is nothing
new in Debian, it's part and parcel of the kind of rough-and-tumble
development model that's always been in effect in this community. One thing
that *has* changed recently, however, is that the General Resolution
process... has become unstuck in the past year, after having been held up
for quite some time by a committee charged with fixing some subtle bugs in
our constitution. Suddenly, the GR process seems like a good way to address
lots of problems in the project, and lots of changes are being proposed
without necessarily considering the full effects in the context of Debian,
or sometimes without much consideration of whether this is something that
*can* be legislated in Debian.
It's also true that as the project has grown, it has tended to become more
politicized as it's harder for everyone to know everyone else personally.
I don't think this is inevitable, though; it's simply something we need to
learn to deal with as we grow. Since Debian has essentially been growing
for its entire existence, we have a fair amount of experience with learning
to address growing pains.
In any case, I definitely don't think AJ's decision represents any sort of
crisis in Debian. The release manager's job is a hard one even when
everything seems to be going right, so it's perfectly understandable that
he would decide to step down.
With that unpleasant topic behind us, we also asked Langasek about the
release schedule, and whether the schedule was realistic.
The important message to bring away from the announced release schedule is
that we're close enough now to being able to release that it's time for
developers to change focus. The schedule may slip a few days here or there,
but the truth is that's something we have to contend with no matter how
aggressive our proposed schedule is. So we might as well be ambitious!
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
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
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:
Now that the first release candidate of the debian-installer is available,
we also need users to help test this new installer, and to also help review
the installation manual to check for omissions and accuracy.
We hope to soon have security support available for testing, at which point
we will also send out a general call for users to test the upgrade path
from woody to sarge.
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:
Debian-installer stands head and shoulders above the boot-floppies system
we used for woody, and we owe a lot of thanks to the developers responsible
for giving us an installer that people can actually be enthusiastic about
contributing to. :-)
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)
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
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:
Why did the FFII and Green Party target
the currently most prominent Free Software migration and not some
proprietary software projects?
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
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:
Software advocates to always raise the point that their opposition against
SWPATs is not on the grounds of Free Software alone, but on the grounds of
the entire local hardware and software industry.
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)
Page editor: Jonathan Corbet
Next page: Security>>