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, X.org, 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 freedesktop.org. A conglomeration of developers from multiple vendors, sponsors, and independent desktop developers representing multiple projects, freedesktop.org ? 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, X.org’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 X.org transitions to a more modular architecture.
This new modular architecture will allow the X.org 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 freedesktop.org’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 xwin.org started (remember that?), I was one of the admins there, and got involved when we merged with freedesktop.org; and thus began my fd.o involvement.
At the conference dinner at linux.conf.au 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 freedesktop.org, 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 freedesktop.org, X.org, and their respective subprojects interact? Who’s in charge over there?
While freedesktop.org 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.
freedesktop.org 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 linux.conf.au (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?
xlibs: No change, except for the fact that more libraries have been
modularized.Xizzle: This is now dead code. The DIX used in fd.o’s xserver project
and the DIX used in the X.Org codebase was quite radically
different, so building a X.Org server on top of the xserver DIX was
deemed too difficult. Thus was born…debrix: debrix is an autotooled X.Org server, using the X.Org DIX as
well as DDX. As well as having made the server modular, we’ve
also thrown out the old ELF loader, which was a horror to
maintain, and replaced it with a more simplistic wrapper around
libdl. For approximately zero loss in functionality, we were
able to throw away 12,200 lines of code. debrix is also
maintained in tla (Tom Lord’s Arch) instead of CVS.tla: Arch is a distributed source code management system. While projects
like Subversion aim to be a “better CVS,” arch has a different
model (arch is the “protocol” as such, and tla is an implementation
of a client). tla’s models revolve around many developer branches
diverging and later being merged back into a single canonical
branch, rather than many developers working off the same branch.
See http://www.gnuarch.org for more information (as well as
http://debrix.freedesktop.org).Cairo: Cairo is a backend-independent, 2D vector graphics library.Glitz: Glitz is a backend for Cairo based on OpenGL, which means that
all Cairo apps can be drawn as GL textures.XGL: XGL is a server which renders to an OpenGL library; unfortunately
X on GL is not my area of expertise, so I don’t know too much more
about the status.