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?"
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.
It can be seen here - http://keithp.com.
how about www.keithp.com
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.
It's time to move to GNU GPL licensed X server WeirdX.
They already have the idea of a core. All they need now is to create a level of developers with commit permission to take the load off the hands of a few committers.
:)
There are established rules to how to be a committer.
Most important are the perks!
Just an idea, but if you're using the latest 1.0.4xxx drivers from nvidia, they have a new (read "broken") 2D acceleration driver. Check out the forums at nvidia.com.
If you need decent 2D response, and you can spare the slight increase in 3D performance, just use the 1.0.3xxx series.
Hope this helps.
-- don't discount flying pigs until you have good air defense
Remember that multiple forks of the linux kernel already exist (e.g. the -ac tree) that are fairly important, and that the gcc 2.9x/3.x series is based on the old egcs fork.
I'm not saying that forking is always good, but forks in major packages do happen, it's not the end of the world, and a lot of good things can come from it. As major packages, the improvements made possible by a fork can have much more effect than forks of small, insignificant packages.
Keith Packard has been denied commit access to the XFree86 CVS for several months now. (BTW, he was responsible for making the repository publically accessible---he had a long struggle with certain XFree86 Core Team members to let him do it.) This is obviously an insane situation: he has been the principal developer (outside of 3D and drivers, although he's worked on the latter a bit) for some time now. IMHO the situation is somewhat like locking Linus out of Bitkeeper: of course he would make alternate arrangements!
In short, this is a fork in name only: the major players in the distro business have committed to work with Keith, and this is the clear successor for realistic X development. Note that this is the third such event in the history of X: the X Consortium was eventually largely dismantled and replaced by x.org, which in turn was essentially superseded by the XFree86 project. A big hope is that a charter and organization can be set up so that the governance of the new organization is democratic (ala Apache Foundation, Gnome Foundation, etc), allowing changes in governance without the need to create a new organization.
As an X developer and heavy user, I personally am looking forward to having an X repository with current bits and sensible organization.
I haven't talked to Keith for more than 10 years and I haven't been involved with X development for at least that long. But, I remember him from when he worked for the X consortium in the '80s and I represented a member of the consortium.
Keith has been actively working on X for longer than many X users have been alive. He knows more about the original design decisions, the history and politics, and the problems with X than just about anyone currently living. I would trust his opinion over any other member of the XFree86 "team". And, let's get the facts straight on the idea of forking the XFree86 code base. XFree86 is a fork of the original X code base. X was designed to be forked by each group that used it. That is why it is under the X license.
If Keith has concerns they are valid concerns.
Personally I think a lot of what has been going on in XFree86 is misguided. Especially the way 3D has been implemented. Not to mention that the lack of a high performance local binding for X is criminal considering that several ways to implement it have been known for at least 10 years. It was IN commercial implementations of X 10 years ago.
Stonewolf
The biggest thing you said that almost everybody else suggesting alternatives ignores is that an Xlib compatability library is needed.[...]
...). Developers can choose the level of abstraction that matches their need. Why should they care wether the Kit is loaded into the server or linked to the client?
I fully agree that Xlib compatibility is very important, but that can't be the driving factor in a project that wants to replace X. Such an evolutionary approach is far better handled by extending X than by writting an replacement IMHO.
Several responses mention Fresco. However I feel that any attempt to put "toolkit" into the server is a bad idea, and will be rejected.
What makes you say it is a bad idea? We are not fixing the look nor feel of any object created, we just define a set of very generic interfaces to request certain kinds of objects (Buttons, lines, text,
First of all it makes it absolutely impossible to write such an emulation layer.
That's wrong.
Also despite claims to the contrary, it actually *increases* the amount of communication Why? Because widgets quickly grow complicated with many many cofiguration options and it gets COMPLICATED.
I absolutly fail to see your point.
You create a tree of graphic-objects that describe the look and feel of your application once. Afterwards there is NO communication between client and server anymore till the applciation updates its look or the user causes a change in the client's state. Usually not even events leave the server!
We tried remote-displaying our demo. Via Fresco the communication needed 1.9kBit/s (alive pings) after an initial burst to create all the necessary graphics, even while moving/resizing/scaling/... the windows. Doing the same using VNC to export the same demo at the same color depth and using the same screen-size up to 800kBit/s were used when doing those operations. We allow that factor of ~400 for unforseen complications;-)
You should further notice that individual graphics do not get complicated. Complex things are build up out of a couple of simpler graphics. This is *very* different from how both GTK and QT work and way more easy once you get used to thinking in terms of small building blocks.
Also Fresco lacks any attempt at the Xlib emulation library, so it is not going to be a viable replacement.
Yes, we are incompatible for now. Nobody is working on an Xlib emulation layer. It can be added and it will be added once Fresco becomes stable enough to hold its own. Nobody can use Fresco for serious work yet, so nobody will miss X compatibility. We'd still have to keep updating the code to keep in sync with the rest of Fresco, thus draining resources that can be put to far better use elsewhere, Doing such an emulation layer now would do more harm than good.
Regards, Tobias
Finally KeithP put out his response .