LWN.net Weekly Edition for May 18, 2006

The Novell Partner Linux Driver Process

Every so often, somebody shows up on the linux-kernel list with the same bright idea: separate the device drivers from the rest of the kernel and release them independently. Then drivers could be installed or updated without having to change the entire kernel. This idea never gets very far; among other things, it implies the creation of a stable driver API, which is just not in the plans. But the idea keeps coming back anyway.

When Novell's breathless press release, describing a "device driver breakthrough" which "solves Linux device driver compatibility issues," your editor's first thought was that this old idea had returned yet again. This breakthrough process "allows customers to obtain drivers independently of Novell kernel updates," after all, and is said to make life easier for vendors. As it turns out, however, Novell has no plans for defining any sort of stable kernel API; instead, it has created a mechanism making it easier for vendors to cope with the existing, dynamic API.

Essentially, a vendor with a driver for its hardware can approach Novell, pay whatever fee is required to become a "partner," and have its driver distributed through the SUSE YaST mechanism. If the partner supplies versions of the driver which work with distributed SUSE kernels, Novell will make sure that each user gets the right version. Novell will provide API change notifications, helping vendors to keep their drivers working with current kernels. If the vendor becomes an Extra Special partner, Novell will take care of much of the driver updating work themselves.

To some, this program looks for a way for Novell to help vendors who ship proprietary drivers. And there may be some truth to that view. But the real customer base may be elsewhere. Imagine that you are a vendor selling products into a highly competitive market. When your new widget comes out, you do the right thing and contribute a driver to the mainline tree. Even if the driver is accepted on the same day (a relatively unlikely course of events), it will not appear in a released kernel for a month or two, and it will not show up in released distributions for some months (or years) after that. By the time normal users can install the driver, the device is already obsolete and being replaced by something newer, shinier, and faster. And, in any case, having the driver in new distributions is of little help to customers who are running older kernels and don't want to change that.

The Novell program will make it easy for this vendor to make drivers available for the range of currently installed SUSE systems, without forcing a kernel upgrade on their customers. If the program is done right, it could change the landscape for the better: vendors would have an easier time supporting the range of distributor kernels, and users would get current drivers, even on older systems. If done wrong, it could lead to more out-of-tree drivers, but Novell appears to have anticipated that concern. From the driver partner FAQ:

As long as vendors use this program as a backporting mechanism, it will do nothing but good for everybody involved. If they use it as a way to avoid the kernel development process or the need to release their code, the benefits will be rather less. The initial signs are good enough, however, that it is worth wishing Novell luck in this endeavor.

Comments (15 posted)

Java becomes more distributable

With a great deal of fanfare, Sun Microsystems used its podium at JavaOne to announce a change in the Java licensing terms intended to make it easier for distributors to ship Sun's Java implementation. To this point, the terms have been so difficult that few distributors bother; those wanting to run Java code must either install Sun's implementation themselves, or go with one of the free alternatives. Sun, perhaps seeing that said free alternatives are rapidly improving, has tried to reestablish its own dominance by way of a small licensing tweak. It is a half measure at best.

Sun's new terms go under the name "Operating System Distributor License for Java," or "DLJ" for short. As always, when pondering licenses, one must go to the actual text. So, for the curious, a look at the text of the DLJ (v1.1) is warranted. The core of the DLJ is this:

So distributors can now ship the Java code as part of the operating system, assuming they meet all the conditions - and there are several of those. They include some obvious ones, such as indemnification of Sun from liability, and some that one would expect, such as the requirement that the software be distributed without modifications. Some of the other conditions are interesting, though. Consider:

So the license only applies to operating system distributors. This clause would appear to make it impossible for a third party to distribute Java packages for somebody else's distribution. So this license may not improve the lives of people who run distributions from organizations which will not distribute non-free code at all.

Next condition:

So Sun's Java remains incompatible with any free Java implementations and, presumably, a fair amount of related code. How this term might affect the combination of Sun's Java and Eclipse is an interesting question.

Finally, there is a term stating that if any compatibility issues arise "caused by the interaction of the Software with your Operating System", the distributor has 90 days to fix the problem or stop distributing Java. It is unlikely - but not inconceivable - that such a term could be used to pressure a distributor to change Linux system call semantics which could be deemed to cause incompatibilities.

This license can be advantageous for distributors with mechanisms for distributing non-free software. Some of them may now be able to ship Sun's Java code for the first time. Thus, for example, Java has just landed in Debian's non-free repository; Ubuntu and Gentoo seem interested as well. But the new license will not help Fedora users, since there is no place in Fedora for non-free code (though what Red Hat does with RHEL could be different). For all the hints made at JavaOne regarding the eventual open-sourcing of Java, this code remains resolutely non-free at this time. Sun's slightly more friendly license has not changed that fundamental fact.

Comments (43 posted)

Waiting for Rockbox 3.0

Frequent LWN readers will be well aware that your editor has had some real fun playing with Rockbox, a set of GPL-licensed firmware for digital music players. So the Rockbox 3.0 release, originally scheduled for March 15, is of more than passing interest. This release will offer a number of new features:

• The addition of the iRiver H1xx and H3xx players as fully-supported targets. Rockbox works on a number of other players as well (notably iPods and the iAudio X5), but those platforms are not quite ready for a stable release yet.

• Several new games, including Jewels, Brickmania, Chessbox, Bubbles, and others. Players with suitable displays can even run Doom.

• Support for Unicode and translations to 28 languages.

• New codecs, including WAV playback on Archos models and AIFF.

• The Tag Cache music database, allowing the user to browse through the collection based on several attributes.

• A built-in five-band parametric equalizer.

• High-quality, lossless recording on platforms which support it.

There are, of course, many other improvements to the code which help to make it more robust and maintainable, but which tend not to show up on feature lists. Your editor has been running the occasional daily build with good results. This looks to be a release which exposes Rockbox to a wider user base and, in general, draws more attention to the project.

Only one problem remains: it doesn't all work yet. There are a number of codec issues, such as confusion when the user skips around too much. A number of trouble reports with the H1xx models have been posted. Battery life on the H3xx is still far less than with the iRiver firmware. In general, the list of open bugs is on the long side for a project on the verge of a stable release.

The Rockbox developers thus find themselves in a place familiar to many projects: trying to decide when to make a major release. Putting out a buggy system would not endear Rockbox to many of its users, and could set the project back severely. Meanwhile, however, the ongoing feature freeze has brought development to a stop and is creating a fair amount of patch pressure. The developers would very much like to get this release out of the way and move on to working on the new, fun stuff.

Getting releases out is one of the biggest challenges faced by many free software projects. There is a natural tension between the creation of truly stable releases and going on to develop the Next Cool Thing. A number of techniques have evolved as a way of resolving this conflict:

• Strict time-based releases, as characterized by projects like GNOME or OpenBSD. Some projects would appear to employ a low-stratum network time protocol server to time their releases to the millisecond. This approach solves the "when do we release?" question, but it will not be suitable for all projects. It would appear to work best when the project is made up of many independent components, any of which can be dropped (or kept at an older version) if they are not ready at release time.

  Interestingly, the Linux kernel has moved slowly toward this mode over time with its 6-8 week process.

• The "when it's ready" approach. Waiting until no (known) critical-level bugs remain can lead to stable releases, but on an indeterminate schedule. Debian's stable releases highlight both aspects of this approach. The older (2.4 and prior) kernel model also worked this way.

• Separate stable and development branches. In theory, this approach allows development to go forward without disturbing the branch intended for the stable release. The pre-2.6 kernel sort of used this approach, except that the development branch was not created until a number of stable releases and updates had gone out. The Mozilla Foundation has used an approach like this as well. The problems here include a certain tendency for developers to go play in the unstable branch and not work on fixing bugs and difficulties in propagating important fixes between the two branches.

The Rockbox developers do not appear to welcome the idea of creating a separate development branch. So some sort of compromise between a timely release and a bug-free release will have to be found. There is some sentiment for putting out 3.0 on Monday the 22nd, with known bugs if need be. The worst of those bugs might subsequently be fixed in an update release shortly thereafter. So, while Rockbox 3.0 will doubtless make many users entirely happy, it may well be a true "dot-zero" release for others.

Comments (7 posted)

Open Content III: the code

As the previous article in this series pointed out, one of the key developments in the rise of open content was the drafting of suitable licenses to codify the freedom to use these materials in various ways. One important licensing option is that of modifying open content to create new works. Licenses may open up the possibility of such collaborative ventures, but on their own are not enough. Practical tools are needed to help people to work together on open content. For that, software code is required alongside the legal code, and application development has played just as important role in the rise of open content as the refining of appropriate licenses.

The catalytic effect of tools can be seen in the sphere of blogs, which represent a very popular, if coarse-grained, kind of online collaboration. Several online Web diaries were around as early as 1995, the same year that the authors of Suck's mordant posts first stepped onto the punishing daily treadmill that has become a hallmark of top blogs. But the term “weblog” only appeared in December 1997, and was shortened to “blog” in 1999, by which time there were just 23 of them according to one count.

The trigger for their rapid growth was the arrival of tools such as LiveJournal, Pita, Blogger and Groksoup in 1999 that made creating blog posts as easy as sending an email. Once the medium began to take off, keeping up with all the postings became a problem. Technology provided the solution through the Really Simple Syndication (RSS) standard, which grew out of earlier work by Dave Winer and Netscape. Once in place, this apparently obscure XML standard allowed blog readers to subscribe to a blog feed – vastly easier than going to a blog and reading posts one by one.

The availability of this technical solution drove the readership of blogs to even higher levels. Now the problem became not so much reading the posts you had subscribed to, but finding blogs of interest among the millions out there. The solution – dedicated blog search engines like Technorati – flowed from another of Dave Winer's technical innovations: the blog ping. Each time someone made a post to a blog created with Winer's software, the program pinged his site weblogs.com, which held a record of all such postings. Blog search engines like Technorati could therefore use the pings as a signal to refresh their indexes for the site in question, ensuring that they were always up-to-date. By contrast, conventional search engines tend to be days or even weeks behind the rapid posting rhythm that distinguishes blogs from traditional Web pages.

Blogs are clearly collaborative – their essence is the intellectual give-and-take between those posting, quoting and linking, and those commenting, which together create a kind of patchwork communal document. But to allow a more thoroughgoing and fine-grained collaboration, where texts could be modified right down to the level of individual words, a new kind of software had to be developed, what came to be called the wiki.

Significantly, it was in the world of coding that this solution emerged. Ward Cunningham, now employed by the Eclipse Foundation, is well-known for his work on areas like agile development and extreme programming. Many of agile development's principles read as if they were referring to open source and open content, notably in valuing “individuals and interactions over processes and tools,” and “customer collaboration over contracts negotiation”.

Another important field that Cunningham has been associated with is design patterns, notably through his Portland Pattern Repository. It was for the latter that Cunningham created WikiWikiWeb in 1995 as a way of facilitating the exchange of ideas between programmers. The name “wiki” comes from a Hawaiian term meaning “quick”, and was chosen in part for its alliteration with the word “Web”, mimicking “WorldWideWeb”. The “quickness” refers to the ease with which Wiki pages can be added or edited, allowing content to be worked on in a true collaborative fashion.

This apparently minor modification of previous Web technologies has led to a proliferation of large-scale collaborative open content, both on the public Web and, increasingly, on corporate intranets. Perhaps the most famous example is Wikipedia, which grew out of Nupedia, an earlier online encyclopedia. Nupedia did not employ the wiki's completely open approach for content creation, and never got beyond producing a handful of articles, whereas Wikipedia has already passed the one million article mark for the English language alone.

Alongside Wikipedia there is Wikimedia Commons, which offers non-textual open content – images, sounds and videos. But unlike the main Wikipedia articles, these are rarely edited or modified, even though many are released under licenses that would permit this. Similarly, the huge holdings of open content images on Flickr tend to be used as they are, rather than as the basis for derived works. As well as these consolidated collections, there is Yotophoto, a dedicated open content search engine for images, and similar facilities on Google, Yahoo and the open source Nutch (all available from the Creative Commons search page, included by default among the Firefox search engines), which allow material to be found across the Web.

The ready availability of graphical open content raises the question of what might be done with it. Tools like GIMP have been around for years, but so far there does not seem to be the same kind of broad collaborative tradition for graphics as there is for texts. An interesting first attempt can be found in Kollabor8, and recently the film “Elephant's Dream”, produced using the 3D graphics creation package Blender, has been released under a Creative Commons license.

One area of non-textual open content where collaboration does seem to be thriving is that of music. This is probably for both historical and technical reasons. Musicians have always used the work of others as springboards for their own music, often incorporating tunes, motifs or chord progressions directly. In addition, the well-defined time-based nature of music (beats/bars/phrases) provides an easily-grasped framework within which fragments/samples from various sources can be placed either sequentially or simultaneously – something lacking for graphical images, where spatial relationships are not so formally defined. The abundance of high-quality open source music creation, editing and mixing software may be another contributory factor.

Whatever the reason, open content music is flourishing, as the existence of a number of music sites offering material for remixing indicates. One recent commercial example is My Life in the Bush of Ghosts [Flash], by David Byrne and Brian Eno, while, on the non-commercial side, the Creative Commons site has a flourishing audio/music section. Past and present projects found there include the Wired CD, which offered tracks from major artists that were made freely available for remixing (though usually only for non-commercial purposes), and the ccMixter site. The latter encourages musicians to upload samples, and to take each other's music for use as the basis of new open content works which can then be added to the pool of raw materials for others to work on. An alternative approach is offered by MyVirtualBand, which enables collaboration to take place even earlier in the creative process.

Glyn Moody writes about open source and open content at opendotdotdot.

Comments (1 posted)