XFree86 Politics

Pivot writes "Keith Packard wants to fork the XFree86 effort. 'It has been brought to the attention of the XFree86 Core Team that one of its members, Keith Packard, has been actively (but privately) seeking out support for a fork of XFree86 that would be led by himself. He is also in the process of forming a by-invitation-only group of vested interests to discuss privately concerns he has about XFree86 and the future of X. He has consistently refused to even disclose these concerns within the context of the XFree86 Core Team, which makes his membership of that team unviable. As a consequence, Keith Packard is no longer a member of the XFree86 Core Team.' The XFree86 team is trying to become more open, to combat the fork. Keith is a capable developer, having worked on FontConfig, Xft, the X render extension etc. Meanwhile, All is not good in how XFree86 drivers are being developed. Anyone remember the GGI initiative a few years back, and the uproar it caused?"

Comments

Mike's diary entry

[dd]

Mike Harris is a bright guy, as anyone who has followed the various Red Hat mailing lists over the last few years will know. When he speaks out like this about the inadequacies of the development process of XFree86 we should all stand up and take notice. Be sure to take the time to read the advocago link in this story.

Re:Mike's diary entry

[n1ywb]

I'll admit, Mike Harris' comments are slightly disturbing. But perhaps the real solution isn't to fork XFree86. Why do XFree drivers have to be released by XFree with the core release? Can't they be developed and released indipendantly? Can't ATI just release their drivers themselves? If XFree is slow on the uptake then let the distributions package them. It's not like everybody forgoes the latest Windows video drivers until they're included with a major release of Windows, christ you'd never get them then. It sounds like XFree needs to modularize their development efforts. And if XFree isn't willing to do so then there is nothing stopping anybody from standing up and releaseing their own XFree drivers pack.

Oh and BTW from http://www.xfree86.org/developer.html

How to Become an XFree86 Developer
Get and build the latest XFree86 code from the CVS repository, and subscribe to the XFree86 developer list (see above).

I don't know if Mike's quote from that page is old or just innaccurate.

It sounds like XFree could use some new blood. It's too bad there aren't just more active developers as it would help to steer it in the right direction. The Linux kernel is a good example of a piece of software which is ultimately controlled by Linus' inner circle, but which is really driven by the hundreds (thousands?) of other people who hack on it and release their own trees, etc. Maybe writing GUI code is boring by comparison, or something.

Re:Mike's diary entry

[g4dget]

The Linux kernel is a good example of a piece of software which is ultimately controlled by Linus' inner circle, but which is really driven by the hundreds (thousands?) of other people who hack on it and release their own trees, etc.

But from the user's point of view, the problems are quite similar. For example, you still can't get a 2.4 Linux kernel with decent ACPI support, reasonably complete FireWire support, or lots of other features that have been out individually for months or years. And the 2.5 kernels do not even come close to compiling cleanly in most configurations (at least the half dozen I have tried).

Both the Linux kernel and XFree86 suffer from similar problems: they are very well-written and well-tuned C programs, but there is only so much magic even the best C wizard using the best tools can work on huge C source trees.

Re:Mike's diary entry

[g4dget]

Again, there's nothing stopping anybody from releasing these drivers indipendantly of Linus' releases.

Sure there is: the hooks just aren't in the kernel. And that's the point: the kernel is not designed as a set of software components that people can assemble into a system, it's a monolithic piece of software that often needs to be patched in order to support some new piece of hardware or functionality.

And how many of them have ACPI or FireWire?

Most of the new ones have ACPI. In fact, my two year old desktop has ACPI. I suspect the majority of new laptops being shipped can't be suspended under Linux, even though the code has been donated by Intel a long time ago and works.

Linux is so much more stable than Windows because Linus is so picky and doesn't just cobble stuff into the kernel before it's ready.

This isn't about Windows vs. Linux. The Windows kernel seems to suffer from the same problem, although for Windows, they at least have figured out how to make third party drivers work a bit better. But just because everybody suffers doesn't mean that there isn't a problem.

Linus is doing a great job at what he is doing. But there is only so much any group of developers can do with a software system that is millions of lines of code and for which new components are often distributed as patches. We will have to move to a different architecture at some point; the only question is when and how.

Wasn't he working on the Transparency engine?

[Anonymous Coward]

Maybe he is holding it back. I say fork!

Actually to be honest, I would like the transparency server but more importantly things like the Mach64 driver need to be integrated so I can get XVideo and DRI w/o having to download binaries. The stuff in question has not been updated in ages and I am concerned that the 4.3 release will go unnoticed and I'll be stuck w/o dri.

XFree86

[pajor]

I think XFree86 needs a good fork. It seems to suffer from a sort of PHP-Nuke meglomania. Vendor support is massively important; if ATI is nice enough to supply patches to add support for their latest cards and latest features, it would help linux and unix in general to be nice enough to check in the patches ASAP. If vendors look upon Xfree86 as worthless to support drivers for because of inability to delegate responsibility, then X and linux in general will never reach the usability levels that we strive for.

That being said, forks are dangerous and should only be done by talented contributing people with people skills. Keith Packard is a good coder, I hope he's as good with politics.

Already begun

[grub]

Not Found
The requested URL /~keithp/talks was not found on this server.

Apache/1.3.26 Server at www.xfree86.org Port 80


He better find a new home for his homepage methinks!

More open?

[moriya]

I've read Mike Harris' log entry and I agree with many of the points he brought up.

But the thing is ... if XFree86 wants to be more open, why did they remove Keith Packard from the core team in the first place? I know he has contributed in XFree86 that is beneficial but still, despite that he wants to fork off his own XFree86 tree, does the people at XFree86 require to know what he (Keith) intends to do with it?

It's big, it's old, and we're stuck with it

[BlackHawk-666]

The binaries for XFree86 are over 70MB in size, what on earth are they putting in there? Maybe it is time to fork this project or start again from scratch and apply modern design techniques. How about modularising the engine? Why do you have to download every driver for every stinking card out there when you only have 1 video card in your machine? This thing's bigger than early versions of Windows, and it's only a display driver. With a modular design the individual companies could produce their own driver which could simply drop into the main X engine. That would free up the developers from worrying about approving all the patches from each of the major vendors, and they could concentrate on writing some useful core software.

Re:It's big, it's old, and we're stuck with it

[Alan Cox]

Actually Keith has been working on this for some time. Take a look at the hw/kdrive tree in XFree86, that produces very small Xservers and supports a few chips so far (notably things like the iPaq use it).

Also a lot of the rest of the XFree binary package set is fonts, weird prehistoric applications (wtf uses xsetpointer, xkbbell,
xstdcmap...) and ancient unused (but important for back compatibility libraries) like Xaw.

Re:A fork would be *bad*

[Alan Cox]

Thats crap to put it midly. You write an X application right and it works everywhere. Please already run a huge range of X servers, including WeirdX, MetroX, Accelerated X, eXceed and the like all of which are different codebases, and WeirdX is even in a different language.

Its like arguing that you can't write a tcp/ip application if NetBSD and OpenBSD forked. The truth is that since both speak the same protocol it doesn't matter at all.

Possibility of a fork is a necessity

[akc]

The whole strength of the open source concept is that the many hands in a community can make complex problems shallow. If forks can't happen, then a monopoly on the supply of software develops. However, within there already seems a situation in which the threat of a fork is forcing a previously partially closed community to consider how to open up more.

Don't forget that forks are considered by Linus to be essential elements of a successful project. They allow the opportunity for alternative approaches to be tried, and if successful to be adopted. The trick in the kernel is that Linus recognises this and is prepared to merge again when a fork shows its worth

This hasn't worked through yet - it may well be that the threat that it might happen allows the situation to improve such that the natural progression is to bring the two sides together again. This is an opportunity not a threat and we should encourage it

Happened to me

[ElMiguel]

About three years ago I was a happy user of XFree86 3.3.6; then XFree86 4.0 was released and my Matrox Mystique stopped working. After carefully determining that the cause was almost certainly a bug in the XFree86 4.0 driver, I decided to send a bug report to XFree86. I read all the relevant instructions on the web site, collected the required data, and sent a polite and detailed bug report to the appropriate mailing lists.

After some weeks I had received no answer. Bad luck, I thought, so I rechecked I had done everything as indicated in the XFree86 site and reposted my bug report. Zero feedback again. I sent about eight bug reports along three months more or less, and got no answer from any XFree86 developer.

I did get mails from some people with the same problem as me, wanting to know if I had found the solution. I had tried to debug the driver myself, but I don't really had the necessary skills and experience, not to talk about the technical specifications. So there was nothing users who suffered this problem could do; we had to stay with 3.3.6.

Finally, I got some explanation from the last bug report I sent. It was from another user who was frustrated with the way XFree86 was developed. He explained that the public mailing lists I had sent my bug reports to (as I was supposed to do) were only occasionaly browsed by a couple XFree86 developers. Real communication among developers happened in private, closed mailing lists that only people with CVS access could post to or even read.

So the problem went unfixed. Some months later I upgraded my computer and forgot about this. Probably, to this day, owners of Matrox Mystiques with a certain chipset can't use XFree86 4.0.x, and I bet the maintainers of the mga driver don't even know. I couldn't tell them.