Slashdot Log In
XFree86 Politics
Posted by
michael
on Thu Mar 20, 2003 07:44 AM
from the he-said-she-said dept.
from the he-said-she-said dept.
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?"
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Mike's diary entry (Score:5, Informative)
Re:Mike's diary entry (Score:4, Insightful)
I'd rather not see a fork of XFree86, but if they can't solve their problems quickly then they may find their hand forced by a fork. That won't be pretty.
Parent
God *DAMN* it (Score:5, Insightful)
I think I'm going to cry. Keith has done the most amazing stuff -- Xft, the modern font architecture -- all the really good features that I've played with recently. If he splits off, XFree86 is going to take a very serious hit.
Please, please, *PLEASE* try to work this out with Keith, XFree core. If you need to maintain more stability, think about a more unstable devel versions, or even a second "really unstable" devel tree that patches can at least enter the tree. Anything, just don't end up hating each other and refusing to share your code with each other.
Either side of such a fork would have a much weaker team. We need XFree86 so much right now, with 3d becoming important to mainstream Linux users. I appreciate all that the XFree folks have done, and asking for more seems ungrateful -- but please try to work it out without ultimatums. *Please*. The mplayer folks hang together, even though A'rpi's abrasive, because he's a really great coder, and everyone would be worse off if he wasn't involved.
Man. I feel almost as bad as when Bungie was purchased by Microsoft. The world *needs* Keith and XFree core being friends, not adversaries.
This and a war in Iraq, and it isn't even 1:00 yet. What a awful day.
Parent
Re:God *DAMN* it (Score:4, Interesting)
Someone asked "even X protocol can be changed ;)?". David (the XFree86 Head) replied "If such a change turns out to be good, then yes".
More, the core team showed itself to be flexible and proved it can be convinced -- they were against bugzilla (which has been set up recently) etc. There is will...
Parent
Re:Mike's diary entry (Score:5, Insightful)
Oh and BTW from http://www.xfree86.org/developer.html
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.
Parent
Re:Mike's diary entry (Score:3, Interesting)
Re:Mike's diary entry (Score:5, Interesting)
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.
Parent
Re:Mike's diary entry (Score:4, Interesting)
Parent
Re:Mike's diary entry (Score:5, Insightful)
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.
Parent
Re:Mike's diary entry (Score:4, Insightful)
g4dget is correct. That is also the reason why Linux is faster than Windows- you are running one program rather than several that hook into each other. But what Windows loses in speed it makes up for in flexibility. Its a trade off, and each made their decision. Since Unix (and hence Linux) is essentially a server OS, graphics display are not its core concern- networking performance is.
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.
Well, for the most part. You still get flaky implimentation. For example, until its influx of 3dfx people, ATI really sucked ass with both hardware and software (and drivers). Now they unified their drivers like nVidia, and are getting some pretty stable performance: they still arent near stability of nVidia tho- nVidia cards are like a tank.
But aside from all that stuff, there are some good some bad with other graphics drivers, especially the farther down the food chain you go. But thats the whole thing- it IS possible to make rock solid third party drivers for Windows, its just some companies generally dont have people skilled enough to do so, or else the product itself is unstable.
Parent
Re:Mike's diary entry (Score:5, Insightful)
Parent
So what? (Score:5, Insightful)
Re:So what? (Score:3, Insightful)
In this case, we'll only know if it's a good thing if we read the facts, and think it through. So that's not about to happen :)
Re:So what? (Score:4, Insightful)
My experience with code forks is that it is often a failure on the forked part. Rarely, the forked project may become more successful than the original project. Most probably, this will increase the work on both projects if they want to be kept in sync.
Before rejoicing about the fork, think of it that way: assume the fork proceeds, and we have a new Xfree86-bis project. As an end-user, which one will you want to run? Do you think forking the project will bring you more freedom of choice, more quality, more robustness, more timely updates?
Just because you CAN fork an open source project does not mean it is a good idea. The fact that it's so easy to proceed with the idea is nothing. The hardest part is managing the "after-fork".
Parent
Re:So what? (Score:5, Insightful)
I disagree. Forks are useful and often necessary. Phoenix and whatever-they're-calling Chimera this week are necessary Mozilla forks. Mozilla is more or less intended to be a test platform, while Netscape, Phoenix and Chimera are designed to be useable applications. Each of these forks are intended to serve a different purpose. Forking the refinement of the UI into different projects allows the main Mozilla trunk to focus on Gecko and other underlying functionality while not neglecting the need entirely for a refined UI.
Another case of different audiences: GNU Emacs vs. XEmacs. XEmacs is designed to be a polished version of Emacs that works well for people who want a nice professional development environment on *nix, while GNU Emacs is geared at being the consumate hacker's editor.
Or the embedded Linux forks. Actually, there are about a bazillion different Linux kernel forks. Everyone has their own kernel...eventually they re-sync with Linus' kernel, but each of these separate kernels are, again, geared at different audiences.
Parent
Re:So what? (Score:4, Insightful)
Parent
Re:So what? (Score:4, Informative)
Phoenix is in many ways a fork.
It uses the gecko renderer and XUL but it also removes a lot of the mozilla code. There used to be a comment on their site about how many lines of code they'd changed or removed (around 300,000 i seem to recall, but I could be wrong).
For example, some of the differences are: JUST a web browser, no IRC, no newsgroups, no e-mail. Different side bar, none of this features-integrated-into-the-sidebar stuff. Slightly cleaner interface (IMO) and slightly faster to run since its missing a lot of mozilla bloat.
Parent
Re:So what? (Score:5, Insightful)
There are many, many forks of the Linux kernel. No, none of them are as popular as Linus' kernel, however it is in these other trees that most of the development of the kernel takes place, and the good changes get accepted back into Linus' tree. The history of the Linux kernel is a twisted map of intertwining forks. The fact that none of the forks has been more successful than Linus' is completely irrelevant. Without all those other forks the kernel wouldn't be where it is today.
Perhaps we have different ideas about what exactly qualifies a "fork".
Parent
Damn! (Score:3, Insightful)
Re:Damn! (Score:5, Insightful)
XFree86 is an old project, based on even old roots so its not suprising its a bit of a dinosaur at times - its taken a very long time to get bugzilla.
The response to Keith is horribly netbsd'ish though, this "you are with us or against us" thing (Actually its terribly George Bush right now). I suspect in the same situation Linus would merely wish the person "good luck" 8)
Alan
Parent
Re:Damn! (Score:4, Interesting)
The fact that AFAICS *all* the new facilities in recent XFree86 versions have come from Keith would suggest that the problem lies with the way the project works rather than with Keith.
Rich.
Parent
Positive Side? (Score:5, Insightful)
Wasn't he working on the Transparency engine? (Score:5, Interesting)
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 (Score:5, Insightful)
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 (Score:5, Interesting)
Not Found
The requested URL
Apache/1.3.26 Server at www.xfree86.org Port 80
He better find a new home for his homepage methinks!
Re:Already begun (Score:5, Funny)
Parent
More open? (Score:5, Insightful)
But the thing is
He broke the contract. (Score:5, Funny)
Not only have you decided to form a competetive product, but you're also trying to steal our people away. We can't have this nonsense at our company.
This organization has to protect it's financial interests. We can't have competition from within. We don't want you to take anything away from our premere product.
You're fired. You'll hear from our lawyers in regards to the anti-compete clause that you agreed to.
The problem of rewriting/forking XFree (Score:3, Insightful)
A vibrant developer comminuty... (Score:5, Insightful)
No wonder people are getting frustrated. Perhaps a fork is in the best interests of the XFree86 project.
I'd be interested to hear Keith's side of the story, especially his concerns. If they're correct, though, and he's only willing to discuss them with a handpicked developer community, I doubt we'll hear anything useful.
Why not? (Score:5, Interesting)
The message posted by "Moulinneuf" actually suggests to me that Keith probably is well-justified in doing this. It makes sense to kick people off an open source project if they don't contribute or do technically the wrong thing, but that's clearly not the case with Keith. OTOH, if a project member wants to test the waters for a fork privately, so what? Moulinneuf's message sounds like Keith was part of the secret service and spying for the enemy. Sounds like wounded pride and politics to me.
Another question one might want to ask, though, is whether it isn't worth starting an X11 server from scratch. X11 isn't as complicated as the XFree86 server makes it appear to be. And the priorities have shifted, too: stuff that used to be really important in X11 could perhaps now be shifted to simple generic implementations.
It's big, it's old, and we're stuck with it (Score:5, Insightful)
Re:It's big, it's old, and we're stuck with it (Score:5, Interesting)
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.
Parent
Possibility of a fork is a necessity (Score:5, Insightful)
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
On network transparency... (Score:4, Interesting)
As the Windows and Mac OS GUIs increase in sophistication, we have seen that they have been able to add in "network transparency" to an extent (ok more like "remote viewing") with things like VNC, and other implementations, that exist entirely seperate from the GUI proper - they basically implement a very very basic bitmap-copying protocol.
Is there a case where THIS IS NOT SUFFICIENT? Is it really that much of a win to burden the entire architecture with a feature that in its common use can be implemented completely seperately and still solve 90% of the problem?
I'm serious here, can some a heavy/long-time user of X illustrate cases where they NEED network transparency built in (besides that it is "elegant" technically)? The only thing I can think of is having remote windows "integrate" with your local X server - but is this a COMMON CASE at all? I would imagine the common case to be temporarily using remote apps (potentially on an entirely seperate desktop instance) in which case it doesn't matter (or is in fact beneficial) that they are visually distinct, OR using an ENTIRE remote desktop (KDE, Gnome, etc.) in which case ALL your apps will be "integrated" visually since they will all be running on the remote machine.
In what circumstances would you WANT disparate remote applications, from potentially multiple remote machines, integrating invisibly in your current desktop ?(I for one would think this would be hell of a confusing! "Shit did I just 'rm' that file on my local machine, or the server!??") What is the benefit here? What is the cost?
Re:On network transparency... (Score:4, Insightful)
Several cases. Personally, I use the network transparency of X daily, to use GUI apps that are being run on more than one computer *without* disturbing the desktop on said computers (and in fact, one of them isn't even running its own X server). I find this feature very useful, and something VNC and its ilk does not replace.
Also, X over a network is quite a bit faster than VNC.
Parent
Re:On network transparency... (Score:4, Insightful)
In other news, it's also easier to write a note with a pencil on a piece of paper than it is to log into a computer, log into a discussion site, and type the note in. There are times when each is the more appropriate choice, depending on the task at hand.
Parent
This is stupid. (Score:4, Insightful)
Keith has come by PSU (I mean Portland State, not Penn.) several times to lecture in Bart Massey's AI classes. I haven't met him, but I do know some of the people involved in some of this "new X stuff." My girlfriend even had lunch with him once. Several of the people I work with were involved in pre-XFree86 X development and have nothing but good things to say about him.
My take on this is, Keith has some pretty radical ideas for changing X. At least, radical in the eyes of the XFree86 "core team." I've seen him on the lists defending his opinions, and he does so maturely and patiently, even when people don't agree with him. I think he's just given up trying to convince the XFree86 team, but he doesn't see that as any reason to abandon his development. Why shouldn't he make a fork if that's what he wants? If XFree86 didn't want this, they should have never made the source open.
For this perceived treachery, the core team whines and boots him out. Pretty stupid considering he was making considerable headway with Xrender, the only major advance in the basic graphical functionality of X in many years (excluding hardware acceleration).
I'm gonna go out on a limb and say that if Keith is successful in what he's doing, there will be plenty of people running his stuff in the future, and XFree86 might become much less relevant.
Happened to me (Score:5, Interesting)
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.
Keithp locked out... (Score:5, Informative)
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.
Xfree86 is the fork, (Score:5, Informative)
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
More infro from OSNews (Score:4, Interesting)
OTOH YMMV as far as this attack since there is no discussion of what specifically are the issues leading to the fork and rather vague comments about "corporate interests".
Keith's POV (Score:4, Informative)
Parent
Re:Open Source development? (Score:5, Informative)
A lot of Open Source projects are controlled by 'elite cliques'. Usually they are the people who found the project. Other people can contribute source, but not everyone has write access to CVS (this would make it far to open to abuse). Often people who have shown that they can make a positive contribution to a project are given write access to CVS.
This doesn't prevent people from modifying their own copy of a piece of software and distributing the modifications, only from adding untested modifications to the main distribution. Even Linux uses this model. Only Linus, Alan and a few others can make modifications to the 'official' kernel. Would you trust Linux if n random Microsoft employee could make unreviewed changes to the kernel you use?
Parent
Re:A fork would be *bad* (Score:5, Informative)
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.
Parent
Re:A fork would be *bad* (Score:4, Interesting)
Its just X is so good at this people don't notice 8)
Parent
Re:X *does* need a change (Score:4, Insightful)
The window resize issue is a known one, and due mostly to a bug in the "smart" scheduling algorithm XFree uses, rather than any inherant slowness of X or XFree.
The lagging of the window contents behind the borders is likewise known, havoc pennington has been playing with XSYNC lately to try and reduce that issue.
Parent
Re:X *does* need a change (Score:4, Funny)
Me: marvels at sudden increase in 2D performance
Anyway, as I was saying, XFree86 is an excellent implementation and I won't hear a word said against it.
Me: attempts to mod own comment down
Parent
Re:How immature of Mr. Packard... (Score:5, Interesting)
if everyone started forking the kernel, glibc, gcc, and XFree among other core packages, where would that leave us?
When this exact thing happened with GCC some time ago. Did you know that GCC 3.0 is based off a fork of GCC 2.7.2 (IIRC) which for a while was known as EGCS? But, as EGCS progressed, it quickly surpassed GCC and, eventually, was adopted as the new GCC 3.0. So, had this fork not occured, GCC wouldn't be where it is today. I'm assuming that answers your question.
Parent
Re:You have the right idea (Score:5, Informative)
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.
Parent