August 25, 2004 Edition

by Jorge Castro (


An interview with Daniel Stone

One of the most difficult ideas for new Linux users to grasp is the seemingly esoteric means by which graphics get displayed on the screen. Indeed, the concept of different window managers and its architecture are utterly foreign to many new users. Terms like X, X11, XFree,, Xwin, and Composite get thrown around, adding to the confusion. As Linux and other free operating systems continue to evolve on the desktop, X continues to be an enigma to new users. While we have looked at how both KDE ( and GNOME ( interact with X during our last reviews, there has not been a real central point of authority that dictates how the "Free Desktop" should take shape.

Enter A conglomeration of developers from multiple vendors, sponsors, and independent desktop developers representing multiple projects, ? spanning nearly 50 projects ? has quickly established itself as the clearinghouse for interoperability in the Open Source landscape.

Earlier this year, a license change in the defacto X project, XFree86, forced developers to look elsewhere for graphical support. Originally based on a fork of the original XFree86 code,'s first "monolithic" release was embraced by many distributions. Version 6.8, which is due next week, will be the last of its kind, as transitions to a more modular architecture.

This new modular architecture will allow the team to release components on a much more independent basis. The impact for end users will be a more robust, and up to date graphical subsystem that will be flexible enough to meet the demands of the modern *nix desktop. Confused yet? Don't worry, we've snagged's Release Manager, Daniel Stone, to break it down for us.

Ars Technica: Who are you and what do you do? How did you get involved?

Daniel Stone: I'm a 18-year old first-year university student from Melbourne, Australia; I'm currently on a break from my Arts/Engineering (Software Engineering) double-degree. To try and balance out all the geek in my life, I'm taking Arts, majoring in Indonesian ? it's good fun, if really hard.

Back in 2002, Trinity College started funding me to work on XFree86 4.3 debs, a while before its release. That took quite some time, and I got involved with the community somewhat then. When started (remember that?), I was one of the admins there, and got involved when we merged with; and thus began my fd.o involvement.

At the conference dinner at 2004, I was asked to do an xlibs release (later to be the fd.o release manager), and was later gently prodded into code. A couple of months later and I'm hacking X servers; it's a slippery slope, seemingly.

Within, my main interest has been modularising X. While I've not had as much time in the last couple of weeks to work on it as I would like, my baby right now is debrix (see below). I've also worked on the modular xlibs distribution a fair bit.

Can you explain how,, and their respective subprojects interact? Who's in charge over there?

While is, in many ways, a fairly loosely organized community project, we're all really minions of Havoc (; he's kind of a guiding hand around the project. Most of the work within the project is done within smaller, unitary project groups, such as X, Cairo, D-BUS, et al; there isn't actually much work here that touches the project as a whole.

The platform comes close to that, but aside from that, it's basically administration-type stuff.

X.Org (, on the other hand, is far more structured; they have a Board of Directors, an Architecture Board, and frequently have conference calls for both these two groups, and a release group. This is also probably a reflection of the fact that X.Org are very much a single group with a single direction. and X.Org have massive overlap in both goals and developer base, so we interact fairly often. However, we're pretty much on the same page on everything, so we rarely come up against one another as organizations.

In addition, we also spend a lot of time coordinating with various projects such as desktop environments. One or all of myself, Havoc, Keith, Jim and others have been present at this year's (myself, Havoc, Keith Packard (, FOSDEM (Keith), GVADEC (Havoc, Jim, Keith), OLS (all), and aKademy ( (myself); that's a fairly good record. We're always looking to get together and get some good communication together with all the desktop guys, and try to discuss moving forward with the desktop.

A while back, you mapped out ( how different X trees related to each other and what was what. Can you update us on the latest developments in each of these areas? What about "new" things like Debrix/glitz/cairo? Can you break down the alphabet soup for us?

Hard ask!

What kind of reception did the X.Org 6.7 release receive among users and developers? How many developers are working on the projects now?

X.Org seemed to receive a very positive reception; if you need evidence, look at the extensive list of distributions using it (or planning to). We're very happy with how the adoption has progressed.

There are roughly 10 active developers on the main X.Org project; between all the X projects, that number expands to 15 or so.

X.Org originally planned on releasing X.Org 6.8 on or around the 25th of August, which slipped by a week. This release intends to include the Xfixes (, Composite (, and XDamage ( extensions. Can you elaborate on what that means for end users? Can we expect this to bring performance improvements?

The most obvious impact of these extensions for end users is that all sort of crazy tricks with windows become possible that weren't before. Window management a la Apple's Expose and, obviously, true transparency are now possible, and we're certainly looking forward to what our best creative minds can do. Because the extension is so wide-ranging: it essentially says to an external program, "Hey, here's a few windows ? go paint them however you like," what you can do is limited only by your imagination.

So, I can't really say what it will bring users ? right now, we have relatively simplistic uses of the extension, but as it starts to be more widely-deployed, we certainly expect lots of crazy blue-sky ideas to come out of the woodwork and be played with. Some of them might crash badly, but some of them will surely be good! I'm personally quite anxious to see what people decide to do with Composite.

Damage is pretty cool, especially as regards network usage: as network proxies (e.g., VNC) begin to become aware of this extension, network usage will potentially fall through the floor, because you only have to transmit areas that you know changed.

Unfortunately, with all this stuff comes a slight performance cost ? if you're dragging around transparent windows with movies playing under them, it's probably not going to be any quicker than non-transparent. That said, we've been pretty conscious of performance, especially with regards to how it plays with the acceleration layer, so the performance impact shouldn't be too bad.

Are there any plans to work closer with vendors like ATI and NVIDIA to bring better hardware support to the platform? How willing are they to cooperate? Are any of their employees working on projects? And if so, how significant are their contributions?

We're always conscious of our relationship with vendors, and are always willing to cooperate with anyone. In particular, Tungsten Graphics released DRI drivers for Intel's i915 chipset before the chipset was even released to the public in any tangible form, and this support was rapidly merged into our mainline branch ? this was a particularly good example of vendor cooperation.

As regards ATI and NVIDIA, both vendors feed us back to us in a timely fashion. For instance, I believe a patch from ATI was merged last week providing support for a whole raft of new cards.

How important is it for X.Org to maintain backwards compatibility with XFree86? Will, for example, a change in Xorg break the interoperability with binary drivers, such as the NVIDIA drivers?

Unfortunately it's very hard to retain backwards compatibility with stuff like the Composite extension, which changes some structures and functions quite radically. That said, we've certainly had a very close eye on backwards compatibility, and have actively worked to keep as compatible as possible with old drivers.

IN conjunction with the X.Org release, it looks like plans to release the Platform 1.0. Can you elaborate on what this is supposed to be? What are the components of the platform? What is the roadmap and schedule? Why is it needed?

The platform release is actually scheduled to happen at the end of this week [August 27] or the start of next week, while the X.Org release will happen as soon as the major release-blocker bugs are resolved ? it's a busy time over at, with nary a developer to spare.

The platform is just a collection of libraries and specifications whose presence developers, distributors and ISVs can rely on when considering the overall free desktop as a platform.

There are a few gaping holes right now: there is no baseline that desktop projects can rely on (e.g., the presence of given libraries), or ISVs (which specifications to target and the same problem with libraries), and also even distribution vendors. By having a baseline to work from, we're hoping to work towards solving these problems.



Are your schedules time or feature-based? Do distributors like Fedora and SUSE have any impact on how and when Xorg and releases software?

The upcoming X.Org release was time-based, and a significant influence on the date chosen was Fedora Core 3's release date; the platform works on a solid six-month release cycle. The release cycle for the next X.Org release hasn't yet been chosen, but it will almost certainly be time-based, rather than feature-based: time-based releases have shown their superiority over feature-based cycles in recent times.

You're also a member of Debian's X Strike Force. Once Sarge is released, what's the plan for Debian?

Once Sarge is out the door, we have a reasonable amount of time before we have to freeze X again (it's already frozen for Sarge), so we have a pretty fair amount of time to think about the future. We're one of the few distributions still back on XFree86, so we're not tied to modular or monolithic, which means we have the luxury of sitting back and evaluating each on their merits.

In the coming weeks, we'll certainly be looking closely at all our options, and deciding where to go from there.

How closely do you work with GNOME and KDE. How have the projects adapted to's initiatives? Who is "upstream", you or them? Is this relationship as successful as it can be? Have developers reacted to the " as an umbrella" idea?

We work closely with anyone who wants to work with us ? it's that simple. As the Linux desktop space is more than just GNOME and KDE, we're conscious of that fact, and anyone, whether they be from GNOME, WindowMaker, XFce, or whatever, is welcome to come and help out, and shape our directions.

So far, we've had a pretty positive reaction across the board, but we would certainly encourage all the projects to continually approach us with things they believe could/should be standardised ? code, specs, or both ? and also to try to make use of emerging technologies such as D-BUS, Cairo, and more, which are not tied to any particular platform.

What about cooperation with individual project kernels? Can you describe the relationship that hackers have with the Linux and BSD (and whoever) hackers? How easy is it for you guys to "get things done" in that space?

We have a pretty good relationship with all the kernel guys, mostly. For example, at the Ottawa Linux Symposium recently (which is quite heavily kernel-oriented), myself, Keith Packard, Jim Gettys, Jon Smirl and Ian Romanick attended. Keith gave a talk at the Kernel Summit which was quite well-received, and kicked off interesting discussion, on dealing with devices in userspace vs kernel space.

The 3D question in particular has long been an interesting exercise in userspace<->kernel cooperation, and we're moving to become more reliant on the kernel for tasks X has traditionally performed. Because of this, I think we'll see a lot of people who will suddenly be hacking on the kernel rather than X, because (one of) their area(s) has moved to the kernel, and this will help even more.

What other areas do you see expanding into in the "Linux desktop" space?

Not so much "Linux desktop" as, well, "free desktop." :) I think with the emerging technologies we have ? D-BUS, Cairo, HAL, X, etc. ? as well as the platform, we have most everything covered.

How can budding X developers get information about contributing to

The easiest answer I can give is, sadly, quite cliched. Join the lists (, get involved, see what needs doing. Even if it's just trivial fixes to the build or something, it's a good way to get involved, and familiar with the code. We also have a Bugzilla (, which has a whole bunch of juicy bugs just waiting to be fixed.

For the less code-inclined, there's always lots of documentation to be written! Manpages need to be written, documentation needs to be released Xorg 6.7. converted from random archaic formats to DocBook, et al. This is one area that really badly needs some love from those with the requisite skills.

* * * * *

To the outside, the entire graphical landscape of X might seem confusing. The and X.Org road maps bring cohesiveness to the Free Desktop. Once a loose conglomeration of separate projects, the recent efforts have unified many aspects of "Linux" that once seemed too diverse to bring together. Linux and BSD users, regardless of their choice of desktop (GNOME, KDE, and others), can now enjoy a unified infrastructure that moves the entire desktop into the modern age, in-line with the recent advances of Mac OS X and Microsoft's upcoming Longhorn release.

It is difficult for users to really judge the difference that a unified platform can bring to the table without trying it themselves. Fedora Core 3, due October 25, will probably be the first major distribution to bring these changes to the masses. As projects continue to align themselves around, we expect that the momentum of the platform will bring improvements to one of Linux's traditionally weak areas. Feel free to join our discussion ( on the upcoming release.