The value of middlemen
[Posted August 11, 2004 by corbet]
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.
(
Log in to post comments)