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
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
Fedora 9 is shipping a pre-release X server. If you can't wait for
an updated NVIDIA graphics driver and the limited support provided
in 173.08 graphics driver release is insufficient for your
purposes, please use the X.Org nv driver or fall back to a
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
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"
And, certainly, some Fedora users appreciate the priorities that the developers
Well I'm an Intel & Radeon user and Xorg in F9 is dramatically
better better for all my machines. So, yes, if new code improves
life for the open source drivers, lets do this again & again in
future releases. I don't want my desktop experience held hostage by
one company with binary drivers.
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
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)
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
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
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
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:
Sometimes you use libxul, sometimes you use the win32 embedding widget,
sometimes you use the gtk embedding widget, sometimes you have to reach
down into internal interfaces to change things and some times you
don't. Having a single story around how to make use of the embedding APIs
on your platform and in your environment is one of our goals.
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:
So we will have some iteration during early development and will start
locking things down once we have a better sense of what people [want] and what
we'll need to change internally once we understand about our user's
specific use cases. Stable API is a goal, but it's a longer goal. The more
that we have people help us understand and contribute code out of the gate
the faster we will get here.
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
Note that trying to be a drop in replacement to WebKit or MSHTML/WebBrowser
Control is not on the table. Therein lies madness. You end up chasing
compatibility instead of just trying to make something that works really
really well. But we can learn what works well from them and what doesn't
and hopefully apply that to our new embedding interfaces.
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)
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:
The biggest reason for using the BTS is not technical. It's that,
if we decide that the project will treat divergence from upstream
as a bug, then we've effectively decided that maintainers will be
responsible for both minimising unnecessary divergence,
communicating about it to upstream, and for keeping track of what
divergence exists. Because developers are responsible for their
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
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
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.