LWN.net Weekly Edition for May 22, 2008

Blame Fedora. Again.

As your editor writes, the Fedora development list is the scene of an extended, heated discussion about Fedora 9. One might think that some users would be unhappy about the inclusion of KDE 4, say, or maybe it's an issue with Firefox 3, with its refusal to run older extensions and persistent fsync() bug. It would not be hard to imagine users being upset by the continued presence of Codeina. In fact, nobody seems to have much to say about those issues. Instead, a small group of very vocal users is complaining about the X Window System.

That, too, might not be completely beyond imagination. Your editor can certainly attest that Rawhide users had more than their share of X-related fun over the course of the Fedora 9 development cycle. The interesting thing, though, is that just about all of the problems reported by Rawhide users got fixed before the final release. So, while Fedora 9 has a lot of very new X infrastructure, it seems to be fairly solid infrastructure.

The problem, instead, is that NVIDIA has not shipped a version of its binary-only graphics driver which works on Fedora 9. These vocal users feel that the Fedora Project has done them a major disservice by shipping a release without an NVIDIA-compatible X server. Instead, they say, Fedora should either have declined to ship a "pre-release" server, or it should provide a separate set of packages with an older server for NVIDIA users. NVIDIA seems to agree:

There are a few responses to be made to this set of claims, starting with the "pre-release" bit. The server is only "pre-release" by a relatively short period of time, and, more importantly, the ABI for this server release has been frozen for a few months now. The X developers have made it clear that the ABI will not change before the 1.5 release ships. So there's no real reason why NVIDIA could not release a driver if it chose to do so.

But NVIDIA has not so chosen. More to the point, NVIDIA has implemented a clear policy of not releasing drivers for a given X version until that version appears in a stable release by a major distribution. This is a policy which forces some distributor to ship a version of X which is not supported by NVIDIA. Criticizing a distribution like Fedora for being the first one out with a new X version seems misplaced; if one is averse to the use of new software, there are probably better distributions to be running.

But what about the compatibility packages request? Beyond the inconvenient fact that putting resources into supporting proprietary software is contrary to Fedora's policies, that sort of support is expensive to provide. See Adam Jackson's response for a blunt summary of just how expensive. If Fedora developers start putting their time into that sort of project, they will be putting less time into making Fedora itself better. This does not seem like a good tradeoff for Fedora users who, after all, have chosen a distribution with a "100% free software" policy.

And, certainly, some Fedora users appreciate the priorities that the developers have taken:

In fact, X has gotten significantly better, and it has gotten better more quickly as a result of Fedora's decision to go with the upcoming release. Any attempt to maintain compatibility with proprietary drivers would, at best, slow that progress down significantly.

Users unquestionably have the right to hook binary-only drivers into their systems. But ensuring that those drivers work with current free software is their problem - not the free software developers' problem. The use of proprietary software may have some advantages for some people, but it does put users at the mercy of the only people who can fix or update that software: the software's owner. Most developers (most!) do not overtly wish to make life difficult for users of binary drivers. But asking them to go out of their way to shield binary driver users from the decisions made by their vendors is not just excessive; it actively risks making things worse for free software users.

Anybody who wants to criticize Fedora can certainly find any number of valid things to gripe about. Your editor would start with the two obnoxious PackageKit icons which materialized on the GNOME panel, and which, it seems, cannot be made to go away without the application of a fair amount of dynamite. Why does a Rawhide user need a constant reminder that there are updates available? But the failure to provide an NVIDIA-compatible X server does not seem like an appropriate thing to complain about. One should not blame Fedora for being free software.

Comments (23 posted)

Mozilla looks to simplify embedding

There has been a longstanding complaint about the difficulty in embedding Mozilla into other applications, but an effort is underway to change that. Mozilla evangelist Christopher Blizzard is coordinating a group of interested developers to redefine the application programming interfaces (APIs), libraries, and embedding "story" to try to make it easier for other applications. Mozilla is leading the way, but they want to build a community around embedding, so they are reaching out to developers that wish to help guide the effort.

Embedding the Gecko rendering engine—the guts of Mozilla's web content handling—will allow separate programs to deal with and use the web without writing the code themselves. New applications can leverage all of the work done by Mozilla to handle HTML, CSS, Javascript, etc. to concentrate on their specific task. There are several embedding use cases cited on the Mozilla wiki, but the focus of this new effort has been on applications where handling web content is just part of the task at hand.

To some extent, this effort is probably being driven by the rise of WebKit, which has a specific focus on being embeddable. WebKit is derived from the KHTML rendering engine—which underlies Konqueror—as modified by Apple for their Safari browser. There has been a fair amount of press about WebKit lately, which, along with the defection of the Epiphany browser from Gecko to WebKit, may have given Mozilla more motivation to make Gecko more embeddable.

Two meetings have occurred so far to discuss and plan a strategy for providing better embedding support. Blizzard has a lengthy report from the first which goes into some detail about the direction they are headed. The other was held in early May, but there are no reports from that as yet. This a young project that is looking for more interested folks to get involved.

One of the larger complaints about trying to embed Gecko into other applications is that there are multiple ways to do it. It is difficult for a developer to know which is right for their application. Blizzard says:

Another area that needs work is providing a stable API. One of the downsides to not having stability at the API or application binary interface (ABI) is that security holes in Gecko tend to cascade throughout all the other applications that use it. But Blizzard does not expect to nail down the API right away:

The diagram at right gives an overview of how the new API will fit. There is existing code at both the top and bottom of the diagram, while most the of the middle is new. Applications will be able to use some of the embedded functionality through platform-specific APIs—for GNOME, Windows, or OS X—or write directly to the new embedding APIs for more capabilities. One of the more interesting decisions is to use the existing APIs as a model, but not for creating a fully compatible implementation. Blizzard explains:

The project has started on a roadmap of features that need to be worked on, beginning with the basics. Reorganizing the libraries and header files to create a software development kit (SDK) is high on that list. One of the bigger issues that needs to be addressed is how to handle profiles—the directory (i.e. $HOME/.mozilla) that Mozilla uses for user-specific data storage. Some use cases will want to run without a profile, but the current code expects to always have one available. The full list in the meeting report is worth a read.

This is an interesting project that should lead to more interesting applications down the road. The barriers to working with Gecko today are fairly high, but the advantages to using a well-tested, well-supported, and reasonably fast rendering engine for applications that need it are compelling. Those barriers look to be lowering in the not-too-distant future.

Comments (2 posted)

Debian contemplates patch management

Developers in the Debian project had a busy week cleaning up after the openssl vulnerability was disclosed. Once that was taken care of, they moved on to process-related issues. Clearly, some shortcomings in how Debian handles patches to the programs it ships have been revealed; now the project would like to face those problems and make things work better in the future. The resulting discussion shows Debian at its introspective best, and may well have results that other distributors will want to pay attention to. As a Fedora developer noted: "This bug could easily have been us on the receiving end." All distributors make changes to their packages, so all of them are potentially exposed to this kind of failure.

Debian's packaging policy resembles that of most other distributions. A Debian source package is supposed to contain a tarball of the upstream source distribution, without changes. Any distribution-specific patches are included separately and applied when the source package is prepared for building. There are couple of Debian-specific issues to be faced, though:

• From the discussion, it seems that the "pristine upstream tarball" rule is occasionally bent by developers. Sometimes there is no alternative: some upstream source distributions contain material which, due to its licensing, cannot be shipped by Debian. The justification for other cases is not always quite as clear.

• Debian's patches are all mashed together and included as a single diff file. So there is no metadata describing the patches, and they are difficult to separate from each other. In this regard, Debian differs from RPM-based distributions, which generally keep each patch separate.

The end result of all this is that Debian's patches are hard for others to review, hard for upstream projects to consider, and even hard for other Debian developers to get a handle on.

Raphaël Hertzog started a discussion on how to improve this situation. A key part of his approach (and an idea which others have been pursuing as well) is to make changes to the Debian source package format which would make the nature of each patch explicit. At a minimum, packagers would include a debian/patches directory with the source; that directory would contain each patch, broken out into a separate file. Some Debian packages are built this way already, though the practice is far from universal.

Beyond that, though, it would be nice to have the source package itself understand the patch stream and its associated metadata. There are a few proposals for this; Raphaël favors the "3.0 (quilt)" format, which keeps the patches (in a separate tarball) as a quilt series. This format seems to have a certain amount of support; among other things, its simplicity would make it easy for Debian developers to create packages in this format without having to learn new tools. The quilt series file - like the spec file used with RPM packages - makes it clear which patches must be applied, and in which order.

There are other variants of the 3.0 source package format, though. The "3.0 (git)" format contains a git repository containing the upstream source and a series of patches to it. This approach has the advantage of including the history of the patches along with the other metadata; it could also, arguably, make it easier for other distributors (and upstream) to cherry-pick patches of interest. On the other hand, a git-based package format requires the availability of git and has the potential to make those packages larger. The GitSrc FAQ has some more information on this format; there's also a "3.0 (bzr)" format variant out there.

Any of these new formats, if widely adopted, would bring a new level of transparency to Debian's patching activities. It would enable the creation of a "patches.debian.org" site (clearly inspired by patches.ubuntu.com) where anybody could quickly look at the changes which have been made to any given package. There are some developers who doubt the utility of this; they worry that upstream developers won't want to poll a site to see what changes have been made to their code. One developer at least (GNOME hacker Vincent Untz) thinks that a patches.debian.org site would be a step in the right direction, though.

Another quibble which has been heard is that Debian does not need any new infrastructure for patch management. The right place for patch tracking, it is said, is with the upstream project. Nobody seems to challenge the claim that more patches need to go back upstream, but there is also the fact that quite a few patches will never get there. The upstream developers for a number of projects seem to have different goals and are seen by the distribution maintainers as being overtly uncooperative. And some patches - such as those removing non-free material - may not be something that even cooperative upstream maintainers want. So there will always be a need for distribution-specific patches; the "track it upstream" approach will not solve the whole problem.

Meanwhile, Joey Hess brought a completely different idea to the discussion: just treat every divergence from upstream as a bug. Each patch would have a corresponding entry in the Debian bug tracking system (BTS) with a special tag. Anybody could then query the list of outstanding bugs, view the patches, and participate in the associated discussion. Using the BTS brings some real technical advantages, in that the system already exists. But, Joey says, the real benefit is elsewhere:

A separate patch tracking mechanism, instead, would be a mostly automatic subsystem on the side which might not bring the same sort of pressure to bear on developers.

The BTS approach is not universally acclaimed either. Some developers claim that most Debian-specific patches are not really Debian bugs - they are, instead, upstream bugs. Regardless of whether that is really true, distribution bug trackers generally carry a great many entries which, in the end, describe bugs in upstream packages. Another complaint is that creating and maintaining BTS entries would be just another bit of bureaucratic work imposed on Debian developers. Beyond any doubt, some developers would see it that way.

But this may be a place where a bit more bureaucracy makes some sense. The Linux distributors of the world (certainly not just Debian) are carrying thousands of patches against the free programs they distribute. Making the nature and extent of those patches more readily apparent can only be beneficial for users, reviewers, distributors, and upstream maintainers. One clear conclusion from recent events is that all distributors could do more to let the rest of the community know about the changes they are making.

A distributor's ability to patch a program is a crucial part of the whole ecosystem - it's the distributors' way of balancing their users' needs against the upstream maintainer's policies. But distributors should be clear about the changes they are making, willing to merge those changes upstream whenever possible, and wanting feedback on those patches. Any "bureaucracy" which helps to make that happen can only help our community as a whole in ways that go far beyond the avoidance of another openssl disaster.

One final note: the existence of source package formats which incorporate distributed version control system repositories shows that developers have been thinking about this problem for a while; it's not just a response to recent events. There is an effort underway to think about what the intersection of version control and packaging can really achieve for all distributors; the folks working on this project can be found at vcs-pkg.org. They are working on organizing a gathering this September in Extremadura. Vcs-pkg is worth watching; it has the potential to make things work better for developers and users of all distributions.

Comments (31 posted)

Page editor: Jonathan Corbet

Inside this week's LWN.net Weekly Edition

• Security: Session cookies for web applications; New vulnerabilities in Django, gnutls, kernel, setroubleshoot,...
• Kernel: Appropriate sources of entropy; Kill BKL Vol. 2; Barriers and journaling filesystems.
• Distributions: Exherbo announced. Sort of...; rPath Linux 2.0; SLE 10 SP2; openSUSE 11.0 Beta 3; Fedora 9 Everything Spin; Gentoo Foundation officially reinstated; GKLinuxOS 2008
• Development: Use Rakarrack for Electric Guitar Effects, Firefox 3-rc, new versions of ALE Server, Unbound, nfsreplay, Putty Terminal Deployer, pyftpdlib, DistrPeer, Django, OpenPanel, NASPRO, GNOME, pdfposter, jack-keyboard, jack-smf-utils, ll-plugins, NtEd, MDP, OpenSwing, GCC, CMUCL, GNU CLISP, Parrot, Pyrex, Urwid.
• Press: Guidelines for Free System Distributions, Splashtop on Asus motherboards, Verizon joins LiMo, Fedora soccer playing robots, Red Hat Linux at NYSE, Demystifying KDE and GNOME.
• Announcements: Digistan Hague Declaration, Seneca College to work on Fedora, OLPC and Microsoft, Sugar Labs launched, Open Source Security Report, Python and Plone Boot Camps, Hack.lu cfp, Netfilter Workshop, Open Source City - Liverpool, Collaboration Summit videos.

Next page: Security>>