Various discussions on the problems associated with binary-only kernel
modules have turned, sooner or later, to the same idea: the world needs a
database of hardware which "just works" with Linux. With this database,
consumers (that's us) could look up potential hardware purchases and know,
immediately, whether it would function with our Linux systems or not.
Vendors would eventually see the value of being listed in this database
and, as a result, have a greater motivation to ensure that their hardware
It's a nice idea, but not a particularly new one. Your editor has seen a
fair number of these databases come and go over the last ten years.
Starting a "just works" database is easy, but keeping it current and
relevant is hard, for a number of reasons:
- The variety of hardware out there is huge. Simply testing and
creating entries for a meaningful subset of the available gadgets is a
- Vendors feel free to change the internal makeup of their gadgets
without telling anybody - or changing the model number. The changes
in the LinkSys WRT54G router are a recent example. This behavior
complicates the database (which must now have information on telling
working hardware from paperweights) - and its maintenance.
- Nobody can actually have all that hardware around, so information must
come from a wide community. Most of us only buy hardware
sporadically, so we tend to have little motivation to help with the
ongoing maintenance of a hardware database. Some of the information
which is contributed may also be of dubious reliability.
- Companies which might help with the maintenance of such a database
have their own incentives to deal with. Red Hat maintains a hardware
list, for example, but it (1) is small, and (2) talks
about RHEL, not about Linux in general. The company once known as
Linuxcare had the proper motivation to maintain a good list, but,
well, Linuxcare didn't weather the dotcom bust very well.
- Weird factors come into play. The BlueZ project used to have a very
nice list of working hardware, but that list
was pulled down as a result of objections from the "Bluetooth
Any future attempt to build a Linux hardware compatibility database will
have to find a way to overcome the problems listed above. The task is not
impossible, but it may well beyond what a volunteer project can sustain.
It looks, instead, like the kind of work which can be helped by the
addition of a stream of money. Perhaps an industry group (OSDL, say) would
like to serve the community by taking this task on.
Meanwhile, your editor notes with dismay an increase in the number of
Linux-installed hardware vendors who are shipping systems with proprietary
drivers. Once upon a time, the purchase of a system with Linux
pre-installed was worth the extra cost just because the running Linux
instance was a positive proof that the hardware was, indeed, supported.
When these vendors ship non-free "Linux" systems, they violate that
guarantee - and destroy much of the value of their product. Unfortunately,
"buyer beware" remains necessary advice for those buying hardware to work
Comments (57 posted)
is an extensive
support library for the creation of multimedia applications. Audio and
video applications can be constructed as a series of pipelines; there are
graphical tools which can be used to help put all of the pieces together in
the right order. GStreamer has been used as the back end for a number of
common applications, including Totem, Amarok, Banshee, and many others.
The project recently celebrated the release of GStreamer 0.10
which improves the system in a number of ways.
According to GStreamer hacker Christian Schaller, future releases of
GStreamer may contain a feature which is less welcome to many: digital restrictions
management (DRM) support. There are, says Mr. Schaller, clear
reasons why one might want to support DRM-enabled GStreamer modules:
Because they give you access to playback things you wouldn't
otherwise. Many music stores only offers DRM'ed WMA files for
download, and without a system supporting Windows DRM these files
are useless on your Linux system. DRM also includes stuff such as
the protection mechanism on the upcoming high-definition DVD's.
It appears that any DRM features would be packaged into separate modules,
making it easy to install a DRM-free GStreamer in the future.
Distributions could put the DRM modules into a separate package - or leave
them out entirely. So, it is claimed, the implementation of DRM in
GStreamer would not place any restrictions on current or future uses of the
Some skepticism on this claim would appear to be warranted. Any DRM module
which is to gain the trust of the entertainment industry (much less avoid
DMCA suits) will have to prevent the user from capturing an unencrypted
stream. To that end, GStreamer will have to be able to create "secure
pipelines"; DRM modules will then refuse to connect to modules which cannot
be "trusted" with protected content. If GStreamer is to retain its current
power and flexibility, many of its standard modules - and certainly those
concerned with the actual playing and display of media - will have to be
reworked to participate in secure pipelines. Either that, or significant
parts of the GStreamer will have to be duplicated in a "secure" mode. It
is hard to see how the entire GStreamer pipeline could be made to be secure
without affecting people who have no interest in DRM-enabled content.
There is also the obvious question of how DRM can be done securely in an
environment where source is available. Mr. Schaller points at Sun's "Opera" project as a
possible example of how things could be done, and notes:
There might be some ramifications of being free software which will
make the resulting system have conditions for use that makes it
painful, like a requirement for being online when playing back as
an example, but its definitely not impossible.
Still, anybody who can hack on the source can obtain an unencrypted stream
from a GStreamer DRM module. So it seems clear that such modules are
expected to be shipped in a binary-only mode. Even then, though, one
should remember that the Linux kernel is free software too. So even if the
GStreamer pipeline is entirely secure and uncrackable, a quick kernel hack
will still make the capturing of unrestricted streams easy. That suggests,
in turn, that the people looking to put DRM code into GStreamer envision
operating in environments where users cannot install their own kernels.
The TPM chips being put into an increasing number of computers may make
that kind of restriction possible, but the real target is probably
elsewhere: embedded systems.
The use of GStreamer to make non-hackable, Linux-based media gadgets will
be nothing new; various companies are creating such devices now. But the
incorporation of DRM capabilities into our free system seems like a step in
the wrong direction. Features like secure pipelines represent a loss of
control over our own systems - the very control that drives many of use to
use free software in the first place. So users and distributors may want
to think long and hard before allowing DRM-enabled GStreamer near their
Comments (62 posted)
Heated battles between supporters of the GNOME and KDE desktops are a
longstanding tradition in the free software world. This tradition has
somewhat fallen into neglect in recent years; the relicensing of the Qt
libraries took away the most readily available flame fuel. Still, one
needs to have a good desktop fight every now and then, if just for old
times' sake. It's traditional, after all.
The end of the year is approaching, and work is slowing down on a number of
fronts. The 2.6.15 kernel is well into the stabilization phase, so there
is relatively little work to be done on that front. As a result, it seems
that Linus Torvalds had a bit of spare time to engage in a nostalgic flame
exercise. In response to a question on printer configuration dialogs,
his desktop preference clear:
I personally just encourage people to switch to KDE.
This "users are idiots, and are confused by functionality"
mentality of Gnome is a disease. If you think your users are
idiots, only idiots will use it. I don't use Gnome, because in
striving to be simple, it has long since reached the point where it
simply doesn't do what I need it to do.
Those who are interested in the discussion that resulted can read the
full thread. Some of it contains language which is not necessarily
work- or family-safe.
GNOME developers often complain that their approach to user interface
design is misunderstood. But the fact is that they have, indeed, left
behind a certain subset of their user base which has grown tired of seeing
features and options disappear in the name of usability. The low point for
the de-featuring of GNOME applications was probably early in the 2.x
series, but the fact remains: GNOME does not allow things which certain
types of users want to do.
This gap is there explicitly by design; Jeff Waugh put
it this way:
We're not aiming for "powerfully extensible". We're aiming for
"Just Works". Some people will hate that. Some will love
it. Personally, I'd rather have passionate users, lovers and
haters, than be than average and ignored, and I think you'll find
most GNOME developers feel the same way.
Havoc Pennington also compared
the implementation of one often-requested feature (the ability to
arbitrarily rebind mouse buttons in Metacity) to selling maternity clothes
for men. One can only assume he is not implying that people who want to
rebind buttons are, in fact, pot-bellied transvestites.
Havoc notes that he has never encountered anybody wanting to rebind
mouse buttons who was not a "historical Unix user." Whether that is
because these "historical Unix users" are, in addition to possessing
questionable taste in clothing, just unusually fussy about mouse buttons,
or whether the rest of the user base simply is not used to the idea that
this sort of behavior can be changed is not clear. What is clear is that
the GNOME project has chosen to target the subset of users who are content
to have a number of user interface choices made for them as long as the
result "just works."
Flaming the GNOME developers for this decision is a mistake. There is
clearly a user base for the GNOME desktop, and who can say that it is wrong
for the GNOME developers to create a system which works for those users?
Over time, these developers may also figure out how to support both the
"just works" crowd and the small minority of dress-wearing Unix relics;
there is some evidence that this might be happening. In the mean time, the
"just works" users may become hooked on the free software experience, and,
eventually, discover the power of being able to optimize the desktop for
their own needs and workload.
But, even if GNOME truly becomes the "desktop for idiots," there are other
desktop alternatives out there, including (but not limited to) KDE. One
might well ask why we should have multiple desktop projects if their end
projects are indistinguishable. Let them, instead, choose their user bases
and provide those users with the best desktop they can. If the desktops
diverge from each other, the result will be more choice for users - and
plenty of material to feed our GNOME/KDE flame war tradition well into the
Comments (225 posted)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: Community help as an attack vector; New vulnerabilities in courier, curl, ethereal, kernel, phpMyAdmin and poppler.
- Kernel: Reworking semaphores; The end of gcc 2.95 support; SMP alternatives.
- Distributions: Distributions in 2005; 64 Studio 0.6.0; Ark Linux 2005.2; Ubuntu Server Project Unleashed; QiLinux Docet
- Development: Ruby on Rails, new versions of
JACK, Linux-HA, MySQL, Xynth, EVMS, Beehive, Geronimo, Booh,
Linux-Vserver, MadJACK, Sailcut CAD, GARNOME, Synfig, Wine, GStreamer,
fluxus, GCC, iText, Jameleon, Free Pascal, Maven, STAF.
- Press: Linux Desktop Developers Find Common Ground, KDE Quality Assurance Meeting,
LISA coverage, IT-Director spreads FUD, UK IP review, Red Flag interview,
bug trackers reviewed, Linux certification programs.
- Announcements: Alcatel Selects MySQL, Sugar Suite 4.0, Swiss pick SUSE, VMware Player,
Online Rights Canada, EU adopts data retention, GNOME Foundation election,
KDE India, BrainShare 2006, Open Source Rendezvous.
- Letters: Another journalist corrected.