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:
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 with Linux.GStreamer 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:
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 system.
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:
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 systems.
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, Linus made his desktop preference clear:
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:
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 future.
Page editor: Jonathan Corbet
Copyright © 2005, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds