LWN.net Weekly Edition for December 15, 2005

"Just works with Linux"

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 is supported.

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 major task.

• 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 Qualification Administrator."

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.

Comments (57 posted)

GStreamer to support DRM

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.

Comments (62 posted)

GNOME v. KDE, December 2005 edition

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, Linus made his desktop preference clear:

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.

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.

Next page: Security>>