Slashdot Mirror
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.
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.
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.
Gnuyen
Isn't the problem that he wouldn't tell the others in the core team about his thoughts on how to improve XFree? Maybe i've misunderstood something, but if I had a guy in a team for any development that didn't disclose his issues with the program, and start working on a fork.. he wouldn't be usefull in that space. (but more than welcome to contribute ;))
But as I said, i probaly misunderstood something.
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!
Trolling is a art,
I've read Mike Harris' log entry and I agree with many of the points he brought up.
... 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?
But the thing is
~ Old Warriors Society
When you signed up to work for our organization, we made a contract. That contract states that you are not allowed to work on any other external project without our permission.
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.
But Keith better be damned sure _why_ he's forking, because the last thing the Linux community needs at this point is for the windowing standards to fall apart.
If this was a "to-be-merged fork" like the sort you always see at the DRI project, I'd be much more sanguine about this. The article makes it sound like it's a full-blown "screw you" fork.
-Erwos
Plausible conjecture should not be misrepresented as proof positive.
KGI FreeBSD project
:).
Just so you know KGI is the Kernel Graphics Interface project that was to be the underlying layer of GGI in Linux.
I used to mess around with this back when Linus was saying how much it was a bad idea. The neat thing about ggi applications is if you compile them once they will run within X as well as at the console without a recompile. At least that used to be a goal... Admittedly I stopped following this project a long time ago but I am glad that it appears to be moving forward elsewhere
XFree is old, should be rewrited from scratch, but the problem is the time. XFree works in a lot of architectures, and a lot of different hardware. Out there there are good alternatives (from a "design" point of view) like DirectFB but they run just on few hardware, and, usually, only 1 architecture. So, the problem is, XFree is too big to make forking a good idea, i think people should just make current X better without any fork. We need some standard for direct hardware access (like DRI) and concentrate work on them. Just an opinion...
If there ever was a open source project in need of a fork, it's this one. Without Keith's work over the last few years feature wise it would be utterly frozen somewhere in the 1980s, rather than sluggishly creeping forward through the 1990s.
...is one that constantly seeks out new talent and includes their efforts in the project. One thing I've learned about managing (FSVO) an open source project is that the worst thing you can do is to ignore people's contributions. Heck, if Mike's diary entry is still the state of affairs, there are more people with commit access to the Hercules CVS repository than there are XFree86, a project that's probably two orders of magnitude bigger!
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.
Disinfect the GNU General Public Virus!
XFree86 seems very poorly managed, especially compaired to somthing like KDE.
The whole project seems to take a black box approach, or at least that's my view from XFree86.org
If I take a look at what's in the next release I get Release Plans
"XFree86 4.x
Our current release is the 4.3.0 release, which was released on 27 February 2003.
A current snapshot of the 4.x code can be checked out of our public CVS repository."
And what's in 4.x? looks like nobody knows.
thank God the internet isn't a human right.
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.
I know that the most important feature of X I rely on is the client/server setup. I enjoy the fact that I can have tens of NCD terminals per low end P3-1Ghz machine.(20 per terminal server in fact.) and it brings maintaince of each office from a whole day job to 20 minutes via SSH and tight-VNC.
What changes are in store? The links to his "talks" are dead.
Do not look at laser with remaining good eye.
I would like to quote Dennis Leary in regards to this:
"Whiny fuckin' maggots"
One only has to examine the Linux distro home page to see over *70* forks of the original Linux idea.
Fork it, fine, but quit being a bitchy "snadbox is mine" baby, this goes for both the team AND the forker.
Moderate this not as a troll, but as flamebait. I'm tired of reading articles like this where one guy with a big ego is torqued off at the rest of the big ego teams and things like this happen.
It's a cult of personality and these people act like they are The Next Big Thing. Get over yourselves. Don't like the project? Resign peacefully and form your own project and start fresh.
So rise up, all ye lost ones, as one, we'll claw the clouds.
Such is the way of open source. Fork, I say! I only hope that Keith's concerns are truly pragmatic and related to the software, rather than ego.
I think the first response on the xfree forum says it all.....
What specifically does the XFree86 bod see as being wrong with the idea of a 'by-invitation-only group' managing X server development? Isn't that exactly what the core team & xfree86 BOD have been doing all along?
Maybe the core team & bod could explain what is being hinted as a new spirit of openness and how that is proposed to effect the XFree86 development process and strategy? Will it mean forinstance an end to the sort of behind-closed-doors discussions that appear to have lead to this announcement?
Presumably, after a fork, both XFree86 and Keith's X11 implementation will continue speaking the X11 protocol, and both will support common extensions. Keith may add more experimental extensions, but that shouldn't be a problem for anyone.
A forked tree would basically kill X as a _standard_ platform. If I write an X app, do I write it for XFree86 or XFree-KiethP? If I'm putting a distribution together, do I package XFree86 or XFree-KiethP? I'm ATI and I want to contribute to driver development. Do I support XFree96 or XFree-KiethP. I'm trying to port an app written for XFree-KiethP to Solaris. What now??
X has survived for this long because it is a _standard_ platform. You can write an X application anywhere and reasonably expect it to display on any X server. If this changes, say goodby to X as a standard.
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.
All those moments will be lost in time, like tears in rain.
I'm not deeply clued in to XFree politics, but my off-the-cuff impression is that this would be a good fork. XFree, for all it's great qualities, could definitely be more forward-looking, especially in the rendering area (i.e., aa, subpixel, alpha etc) Keith's speciality. I don't know how it might work out, but it would be nice to see more competition/openness on the display driver front as well, especially 3D, and especially, 3D used for 2D rendering, which I'm sure Keith has some ideas about.
Have you got your LWN subscription yet?
It's time to move to GNU GPL licensed X server WeirdX.
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
One only has to examine the Linux distro home page to see over *70* forks of the original Linux idea.
Different distributions are not forks of Linux. A fork of Linux would be if some of the core kernel developers decided they didn't like how things were implemented in the Linux kernel and decided to write a new kernel using a different approach.
This is a great laugh.... If you had any idea of the bad blood between XFree and Thomas Roell and XI.
Thomas Roell wrote the original X386 code base which he contributed to the X consortium. He then happily started his own business to sell x86 X-servers. Imagine how pissed off he was when other people took his code base and started undercutting his commerical offering
Until XFree 4.x was released XI's server was arguably the better offering. But I don't think you could make that case now...
D.
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!
XFree is an excellent system. For 80% of desktop work, thin clients etc it's great and I use it every day. But whatever anyone says, it is *slow*.
Try it yourself - open an X application over a browser window and resize it. See the ghosts left behind? The weird way the contents of the window redraw at a different speed to the window resizing? Change workspaces and I can see the windows redrawing.
This happens on even the fastest systems - mine is a 1.53ghz processor with a geforce2 graphics card. I would expect instantaneous redraws on a system that fast. Windows *feels* faster on a much slower machine. Of course, Windows sucks in so many other ways, but at least its graphics code is fast.
If Linux is truly moving onto the desktop, perhaps it really is time for a new look at the graphics situation.
I remember the old days when less expensive "X Terminals" were used to connect to very expensive computers. (Now, which was the client and which was the server?) This model does not apply anymore. Maybe what is needed is to re-think, re-invent and re-do the entire user interface/renderer. And those who believe this is not possible "because every body uses X" - welcome to Microsoft's world. But I don't think this inovation could happen without a major corporate sponser.
Don't flood their new list with all kind of "You st00pids" or anything for either getting rid of one of the core team members, or about what is coming, or about what has been mentioned. There is a nice way to say everything, and there are good, constructive ways to help. So let's use this new list to open the development up, speed it up, etc.
Don't go in there screaming "YOU IDIOTS! YOU DIDN'T APPLY THE [.*] PATCHES! YOU ARE SO l00zers!!!". Think about it, if someone came up to you saying that you didn't apply a set of patches, or something, you would probably look at the patches. If someone comes up yelling, screaming, cursing, and insulting you, you'll ignore them from that point onward, or make up some BS reason. i.e., you'll do more damage than you will help. And if anyone says they have a responsibility to do whatever it is you want, go read that new Bugzilla etiquette book, quick.
Again, read the paragraph over, if you ask why the patches were not commited, or where is this, or why is that, you will probably get a response. If you yell, scream, insult, and kick, well, you lost them at the yelling and you won't get them back now.
And make sure, that if you have time, that you _offer_ _to_ _freaking_ _help_. And let's get a place where those of us who can't help our with time can at least donate. I'd rather end up donating over $100 or $200 over time (I'm far, far, far, far, far from rich) rather than have to pay $100+/year for MS Windows. Hell, I'd rather save up and pay $500 out of the box for X than ever have to use windows again, period. Just because the software has the word free attached doesn't mean the people will happily work for free. Besides, people who donate get their words heard more often. Again, use etiquette. What should be Required CS Reading material for OSS users and some OSS developers.
Just my 2 nuyen.
So, are there any worthwhile implementations of X11 for i386 Linux apart from XFree86?
My brief googling did not turn up much useful information.
my
Quite frankly, the only stuff I have seen go into XFree recently that I thought was worthwhile was Keith's doing. Using X over a slow link is so much better since he added the XRENDER support, and I wait with bated breath for XRANDR support to become ubiquitous. I really like the idea of being able to move my applications from one X server (or client, as they call it) to another.
Judging from the past, if Keith were to start an X11 fork, I would be one to use it, because he adds stuff I find genuinely useful (not to mention ground-breaking in its effects).
Also, a less closed and more friendly development model for XFree would be nice. A fork would keep them honest.
---
Maybe Keith would be more amendable to moving the drives below SDL. XML config files and a JVM embedded into X11. I'd love to see a X project that supported new ideas. XFree is not the place to even try experimenting.
Ok, I've participated in many X "discussions" and the one feature of X that is always trumpeted is the out of the box network transparency.
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?
It's 10 PM. Do you know if you're un-American?
What we actually need is a replacement for X11, redesigned from the ...), which is a shame, but it's
ground up, with compatability libs to allow normal, window-bound
X11 apps to work on it. We'd lose existing "special" apps (window
managers, screensavers, panels,
what needs to be done to allow for future improvements.
Don't get me wrong, I mostly like XFree... but the design is
(gradually) reaching the end of its useful lifespan. There are a
number of improvements I'd like to see that are fairly impractical
for a design based on X11. Resizing windows is nice, but I also
want to be able to scale them. (This implies that bitmapped fonts
should die, among other things.) Being able to grab a bitmap of
the desktop and use it as a window background is one thing, but
I really want a full alpha channel for every window (controlled
by the application for each widget in the window, or for each
pixel in an image canvas widget) plus an overall opacity setting
(controlled by the user) for the whole window. And so on.
Cut that out, or I will ship you to Norilsk in a box.
...it is to just start planning a fork behind the curtains without _first_ venting his concerns with the rest of the XFree86 team first.
After all, it would do no harm to at least start discussing his plans with the rest of the XFree86 team. If no agreement can be reached, then two separate camps are likely to form, and a fork will be made.
If the majority agrees with his opinions problems can be solved, and there's no need for a fork.
XFree86 is one of the core packages in most linux distros, and a fork would only make things even less standard than they are today. Taking this into consideration, Packards "I don't like this, I'm not going to play with you no more" attitude is insanely childish.
Some people here seem to think that forking is unconditionally a good thing about open source development, but if everyone started forking the kernel, glibc, gcc, and XFree among other core packages, where would that leave us?
It might be binary-only, a huge no-no for a lot of the more doctrinaire amongst us, but it's really quite good. It exposes all of the capabilities of the GeForce 4 Ti series, which are formidable indeed.
Installing nvdriver is not for the squeamish...I had to have a guru friend play around a little with my computer to do it. The process needs to be made easier. ATI's binary driver is supplied as an RPM...perhaps it will be easier to install.
Knowledge is power. Knowledge shared is power multiplied.
I'm not sure that's such an issue: X need not be bloated with the way it works. In 1993/1994, I was acceptably running X on a machine similar to the 386 you quote.
X has some superb architectural features (since 1986!) that Windows *still* doesn't have. There's no need to throw them away.
Oolite: Elite-like game. For Mac, Linux and Windows
> win95 runs on a 386 with 8mb ram if you push it.
:-)
I used XFree86 3.0 back in 1994 on my Compaq DeskPro 33 (386dx @ 33mhz).. I forgot how much memory it had, but I suspect either 8 or 12 mb.
It's still sitting in my closet
You always need the server when you have two or more independent applications (=processes) that work on the same screen. And Unix Domain Sockets are not slower than any other IPC mechanism for commands. For large data X11 already uses shared memory.
The only thing that you may change is to put more intelligence into the server, like MacOS X does by having PDF display descriptions and backbuffers. But this is also possible with X11, as display postscript showed.
So far no one came up with a superior concept that convinced a significant number of people. It's quite likely that this won't change unless the requirements change dramatically. All the things that you listed would be possible using X11 extensions. X11 extensions are the reason why X11 survived for such a long time, and why it won't die in the next 10 years.
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.
What a Forking Mess!
But seriously, this is just the kind of stuff we *don't* need in the Open Source community or computing in general. This kind of ego-driven politics is exactly the reason humans get so little done in general, much less in computers.
Granted, the point of Open Source is if you don't like what maintainers of code are doing you are free to take your own direction. And a fork very similar to this one produced one of my favorite operating systems, OpenBSD. But just as in the case of OpenBSD the original project (NetBSD) would have benefitted greatly had the maintaining organization been able to find a way to work with the disgruntled forking developer (Theo de Raadt) I have a feeling we have the same problem here, in that a useful developer is going to leave the Xfree project and take many otehrs with him.
Which is why in this case it is a very very bad thing. Because ultimately the future of Linux GUI development is going to be murky for awhile, there will be more confusion than there already is, and talents will be diverted rather than concerted, which will exacerbate the serious problems we already have with the Linux GUI models.
I hope that somehow a diplomatic solution can be found, and the Xfree team can avert war ;).
I have read almost all of the replies here but none seem to address freedom. If Keith wants to fork xfree86 then he should go ahead and do it. Why, except for political reasons, would the developers at xfree86 with cvs access care about a fork? Why remove Keith's CVS access because he discussed creating a fork with others?
Clearly the xfree86 development group has opened up their development process within the last year but if somebody wishes to fork their project, and this is their reaction, don't we need to question how valid their approach to openness really is?
While a lot of people will disagree with me because their X + KDE runs smooth on their Athlon 2000
I've got a dual-headed dual-333MHz system with a pair of ancient #9 I128 cards, and I'll disagree with you. My system runs X and KDE pretty snappily, with plenty of applications on top. The only thing that repaints or moves slowly is Moz, but that seems to be the fault of Moz (from some other posters in this story).
XFree86 -> XFree
the 86 bit is a bit of historical baggage that no longer reflects reality. Let's take this opportunity to remove it.
As an aside, I think this is a great idea. Between K.P and M. Harris, most of the linux distros will go with the new server. Yay! Real bug tracking! Yay! No long waits for ATI patches! Yay! Sane patch review! Yay! Making XFree development safe for creative ideas!
I hear what you say about drivers, but with Fresco, it's in really early development and uses SDL or GGI depending on your preference. Support from major vendors will be forthcoming when it gains some momentum and starts to look more promising to these people. Fresco is such a good idea and a very well designed system. It may take 10 years to gain acceptance, but it will at some point. It is way ahead of its time. In another year's time, the pace of development of Fresco will have increased by an order of magnitude. I garantee it.
Stick Men
just forking for the sake of it just splits the developer base, and the new fork usually gets bad press and poor support.
:-(
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.
May we never see th
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.
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
I suspect that many of the people post here are not involved in any of the WG's anywhere. I've been involved in several of them. It's not always easy. People disagree in the WG for a variety of reasons - some technical and some not. The non techncial issues include things like financial issues (as in being employed by a major vendor), long standing friendships within the group (you are my friend therefore your ideas must be the best path), etc. My current WG is the IETF PKIX and we recently ran through and incident of threats involving custard and pie throwing. We've had a couple of other incidents that lead me to think that a split of the WG might be imminent. Much to their credit, those involved bucked up and started acting like adults with work to do. They put aside their egos, financial interests, and got to the task at hand. This doesn't seem to be possible for the XFree86 group.
People who participate in WG's do so because they are passionate. They get emotionally invested in their ideas. It's hard not to. I would imagine that any of the open source projects work in much the same way. Kicking out someone who seems have been single-handedly driving their major improvements seems foolish on the part of the XFree86 group to me. This kind of a childish knee-jerk would seem to be a sure signal that he's on the right path. It seems that he will need the latitude to explore some paths and that he wasn't getting much support from the "Core Team" in doing this.
I've taken some time to do some research on this and I would tend to agree. The current "Core Team" seems to be stuck on their own ideas. I suspect that Mike Harris feels the need to chase some of his own ideas and see if they acutally pan out into something useful. That is the best reason to fork a project. If the code base splits temporarily or permanently, then it will be for the best.
Take the long view - say 10 years. Let's play what if with the different scenarios. Will any of us care that Mike Harris stayed with XFree86 project and kept the status quo? Probably not. Will any of care if he left, created a new fork, and smoked the old project? Probably yes. Will any of care if he left, created a new fork, which produced some really good ideas that got rolled back into the main fork? Probably yes.
With the proliferation of video cards, perhaps a trade-off in favor of flexibitiy (aka more cards supported and faster driver release) would be in all of our best interests. Perhaps Linux adoption would increase if I knew that I could run the latest ATI or NVIDIA card as soon as it hit the store shelves. Card makers might be more willing to issue Linux drivers if they didn't have to reveal the inner workings of their cards in an XFree86 patch.
As more and more makes and models of video card continue to be produced, the current XFree86 design will eventually crumble under its own weight anyway. It's like me asking you for a penney today, 2 pennies tomorrow, 4 pennies the next day and continuing to raise the power of 2 each consecutive day. Pretty soon you can't afford to pay me. You cannot continue to add every driver for every card every made as a "patch" the product.
My 2 cents,
Queen BHDGary secures my bank
Both KGI and GGI are alive and kicking at the moment. KGI, the Kernel Graphics Interface is almost rewritten from scratch, and GGI the user level library is developping very well.
Please click the links for more info.
a) is basically what I said with 'more intelligence in the server'. b) is not possible unless the drivers are in the kernel, because only root is allowed to access the graphics device. NVidia's driver works like this, with a kernel module.
I like my window manager seperate thank you very much. The fact that I can select which wm to use at any given moment is very appealing. I'd have a seizure if I had to install multiple versions of X to be able to switch between WMs or if X had to have every WM rolled into it. Plus there are many occasions where i don't run a WM at all, playing movies, games, etc. Who needs a WM for a fragfest or a fullscreen DVD?
Why not fork?
XFork86 ;-)
:-/
Hopefully someone who understands where the
name XFree86 comes from will get a laugh.
Wow, so that's the end of Linux then, is it? Microsoft won in the end. Who'd have thought it?
What nonsense! This is Open Source. KP can create a fork if he wishes. Eventually, either his version will win out, or the original XFree86 will win out, or both will prove to be successful projects, or they'll find some rapprochement and re-merge the projects.
It turns out that it doesn't really matter. The net result will be that in 2004, there will be a better X for Linux than in 2003. And in 2005 X on Linux will be still better. Had there been no fork, the same would have happened. This is just how Open Source / Free Software works.
Reality is defined by the maddest person in the room
This is true of every X extension I have ever seen except Xft. Xft, amazingly enough, is a client-side library that detects itself if the extension is missing from the server and emulates it, so the poor programmer does not have to write two versions of their code! The result is obvious: huge numbers of programs and toolkits support Xft already.
This amazing breakthrough (emulating extensions for you) is almost always done by Microsoft in DirectX, and the fact that the X developers cannot do it should be considered a shameful and embarrassing defeat.
The other problem with extensions is they rarely, if ever, simplify things. The interface to SHM is much more complex than the already agonizingly bad interface to XPutImage. The interface to XRender requires much larger and complex and confusing context objects than normal X drawing. Selecting a font in Xft still cannot be done with a single "name of the font" string. There is no reason why all this complex added code cannot make the programmer's life easier, rather than harder!
The main-line X will be very slightly better (Open Source projects are astonishingly inefficient with time and effort, from my experience in both open and proprietary projects).
The branch may be significantly better. Who knows. The poor guy is clearly too afraid even to discuss his mods.
This all smells like corruption in a communist regime. They're denying the forces of the market and trying to dictate what features users "want".
That it's also a bunch of antisocial losers trying to keep power to supplant their own egos is likely but not relevant.
Lots of whiners will immediatly say "but that will allow window borders to be (horrors) INCONSISTENT and that will CONFUSE the poor stupid users!". To that ancient "inconsistent" argument I say it is totall BS and I challenge anybody to find a real user who is "confused" by the difference between a KDE and Gnome button or menu.
This compatability layer is much more important than anything else, including drivers. Right now it is *impossible* to work with any alternative to X on Linux.
Several responses mention Fresco. However I feel that any attempt to put "toolkit" into the server is a bad idea, and will be rejected. First of all it makes it absolutely impossible to write such an emulation layer. 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. Just take a look at how much code and X messages is used in Qt or GTK to talk to the windowing system, and try to estimate how many times less code would be needed to draw the borders and handle the resizing themselves.
Also Fresco lacks any attempt at the Xlib emulation library, so it is not going to be a viable replacement.
> And how many of them have ACPI or FireWire? Not the majority, thats for certain.
All five of the computers in my lab have FireWire. I don't use it much because the machines that it runs well on, basically, the macs, have lots of disk space internally. Then there's the laptop that has to run kernel 2.2 - I really could use it there. Basically, it's USB 2.0, with several years worth of bugfixes under its belt, and ready for the next few speed-doubling upgrades.
Both of the x86 machines have ACPI. If it worked worth a damn on the tower, I'd keep the machine on all the time instead of powering it down, as I do, in favor of the SunBlade which does manage its power nicely, and stays up for months at a time. If it worked worth a damn on the laptop... don't get me started.
Marketing-driven companies end up over-marketing their products. Engineering-driven companies end up over-engineering
Let's face it: using graphics on Linux means you use Xfree (sure, there are commercial X-servers, but Xfree is the default). They have practically a monopoly on Linux-graphics. And monopolies are BAD for the progress of technology IMO! We need a fork of Xfree. We need a revised and improved Xfree. We need Xfree that loses the tons of legacy-support it carries around. We need Xfree that lean 'n mean.
I like X. But I think Xfree could use some improving. Xfree has served Linux-community well (not to mention *BSD's), but maybe it's time for Xfree: The Next Generation? This kind of thing did wonders to GCC-developement, it could do the same to Xfree.
Lesbian Nazi Hookers Abducted by UFOs and Forced Into Weight Loss Programs - -all next week on Town Talk.
he want's to fork xfree86 huh? well, fork HIM!
I remember the rule of thumb was 4Mb for Linux, 4Mb for x and 4Mb for ea additonal user.
Apocalypse Cancelled, Sorry, No Ticket Refunds
If Kieth's code is removed from XFree86 4.3, then in the one year of intensive development since the release of 4.2 we have...
um...
Some driver updates.
And most of these were written by non "core" XFree86 members. They've been floating around the net as patches for months. And some of them (neomagic) still haven't been applied!
Go Kieth. Either you'll light the fire that gets XFree86 back on track, or your project will take off as XFree86 continues to decay. Either way, everybody wins.
OpenXFree86, and concentrate on proactive security whilst still being easy to use?
>I like my window manager seperate thank you very >much. The fact that I can select which wm to use >at any given moment is very appealing. I'd have a
To you and many other people, others like me would prefer simple small fast in the extreme. Thats why a fork should occur along that line. I'll use my branch, you'll use yours. Better still such functionality could be added optional to the sources.. optionally removing WM support and adding a simple WM compile time. Same for its networking code, keyboard and mouse, and other 'flexibilities' that the average doom-player and opera user couldnt care much about.
>seizure if I had to install multiple versions of >X to be able to switch between WMs or if X had to >have every WM rolled into it. Plus there are many >occasions where i don't run a WM at all, playing >movies, games, etc. Who needs a WM for a fragfest >or a fullscreen DVD
"Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
I saw this link on OSNews and thought it should be reposted here. This is a member of the XFree BOD giving more information on why Keith was expelled and a discussion of how X is governed (i.e. the distinction between BOD and Core). He also argues for LSB taking a much larger role with respect to X (I can't help but think that BSD, Solaris, etc.. would object to that).
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".
the "core developers" just need to reorganize themselves. From what one can see on mharris' diary entry, his major gripe is about patches not being applied quickly enough or never being applied at all. I guess what they need to do is to have several "patch pumpkings". Some of them could manage the patches for the current release, the others can manage patches for older releases. Like what is being done on the Linux kernel. MT is handling the patches for 2.4.x, AC is handling patches for 2.2.x, with LT himself doing the same for 2.5.x. And as it oft happens, patches for the old version still apply to the new version and it propagates up.
The organization of XFree86 as it stands now is just a few head honchos concentrating their efforts on one branch only, with efforts being done on their spare time. The XFree86 source tree is massive in both the physical and logical sense. Not only are they dealing with millions of lines of code, they are also dealing with "subprojects" within the source tree. i.e. Mesa, xterm, freetype. All of these are projects that are and should be separate from the XFree86 source tree. But I guess, the core XF86 developers like to keep their sanity and just have all these subprojects integrated with the main source tree. And having said that, it wouldn't hurt their productivity either if these integrated projects have their own patch pumpkings. It is highly likely that patches submitted to the XF86 core team are for these subprojects than for the XF86 code itself and having a separate, and dedicated group of people handling the patches for these would be good.
By reorganizing and delegating patch management, the core developers are freed from having to deal with patches and their time can be spent more on working on the next release. Ideally, they should also take patches from the old versions and see if it can be integrated into the current development branch.
As for drivers, I guess they should also take hints from how drivers and patches to drivers are being submitted to the Linux kernel. AFAICT, XFree86 shouldn't have the same problem with "kernel hooks" as the Linux kernel does. So other people can write the drivers (presumably the hardware manufacturing people), submit it to the XF86 core team for integration, or better yet have those drivers available for download elsewhere. NVIDIA does it, albeit binary only. That way, these hardware companies can free the XF86 guys from their NDAs. One can't complain if one has a limited set of options.
If the core XF86 team couldn't get their act together on this one, then a fork would be inevitable and probably be a good thing. I personally would use the forked version if it turns out that they can keep up with having the latest device drivers and maybe even coming up with a better and open source device driver than what my hardware manufacturer provides. I really would like to see the Tainted: P from my lsmod print out go away...
creeps slowly back into the gravity well...
So what do other things have that Fresco doesn't? Do you know the whole point of Fresco?
Stick Men
Finally KeithP put out his response .
As usual, News.com trolls Slashdot for interesting comments... You've just been quoted at the end of the article. :)
Not sure if you guys are familiar with picoGUI, but it's goal is to fix all of the current problems with XFree86. I think the url is: www.picogui.org. They have some nice screenshots too.
Don't think that a small group of dedicated individuals can't change the world. It's the only thing that ever has.
I've seen good arguments from both sides, but the thing that annoys me most is there have been a number of allusions to "anyone can contribute!" by the X core team, but that's BS. I can't help but think of Hitchhiker's Guide to the Galaxy, when they're told they should have known their planet was being destroyed, the plans were locked in a basement only a few parsecs away...
The truth is, the XFree86 web page very heavily implies that they don't welcome any outside help. Up until this new mailing list was created, the closest thing to a public technical list was a newbies list. There's no suitable place for non-core members to discuss code, there's no place on the web site saying "here is how you submit code for inclusion in XFree86".
Sure they're not out-and-out saying "we don't want your code", but they did everything they could short of it. The entirety of their patch submission policy is "send an e-mail to fixes@xfree86.org".
It's fine and dandy if they don't want to be a community-run system, but they shouldn't pretend they are when they're basically ignoring the tools that make community participation viable.
WWJD? JWRTFM!!!
Actually, that's not really the case. When we started XFree86 (originally as X386 1.2E), we were in routine and direct discussion with Thomas and Mark at SGCS, working together on fixes, etc. Thomas didn't start to hate us until after we were actually successful. Mark always supported us.
Trust me - I was there. I was on the phone with Mark every few weeks. I even explored going to work with them at one point...
--dwex
Interesting set of messages. One thing not mentioned on that page is that between then and now, DRM (the Direct Rendering Manager stuff) is in the official kernel. I don't follow the kernel list, so I don't know if it had to get stuffed down Linus' throat or if he loves it, but it's in there now. I haven't hacked around with any of this stuff, so unfortunately I can't add anything useful beyond that...
#define X(x,y) x##y
Peter Cordes ; e-mail: X(peter@cordes ,
Metaphor: You are a slow 286.
Simile: You are like a slow 286.
Before you complain, check up on what you're talking about. Try reading some Ray Bradbury, so you can tell whether it's just bad metaphors and similes you hate, or whether it's the figure of speech itself. (Bradbury's metaphors are for the most part good.
#define X(x,y) x##y
Peter Cordes ; e-mail: X(peter@cordes ,
Those dict-protocol URIs didn't come out right, but they don't work with mozilla anyway. They're supposed to be like dict://dict.org/d:metaphor, as in rfc2229.
#define X(x,y) x##y
Peter Cordes ; e-mail: X(peter@cordes ,
And with the potential for them to not be 100% compatible.. ( it will happen in time. z wont have required extention y for application q.. )
There blows the whole concept of a 'unified graphic subsystem'.. will have to have even more versions of everyone's code then they do now for the underlying OS..
Good way to kill off *nix guys. bah
---- Booth was a patriot ----