Slashdot Mirror
The XFree86 Fork() Saga Continues
Mortimer.CA writes "An article up on OSNews about the XFree story
mentioned earlier. Included is: replacing fontconfig with Sun's stsf; XFree86 co-founder David Wexelblat saying that XFree is today obsolete and should be changed; Keith Packard replying, and more."
Attack of the Spoons
Time for Fresco?
I can't help myself...
;^)
"The saga continues..."
"Use the fork() David"
(BTW, expect to bring about introduction of new post-rating: +5 Lame!
I have a bad feling that this is goint to be one of those situations where *every* party involved is both right and wrong on some level. Even uglier is the possibility that this could occur on the *same* level. The fact that situations like this could arise in the first place tells me that maybe the architecture of XFree86 (the ideas underlying the code itself) is overly complex for today's needs.
Or another possibility: maybe the way XFree86 is currently implemented by the major *nix vendors is overly complex by default.
Either way, both the situation and the implementation are starting to look really messy.
C|N>K
Now, that was an interesting reading in the XFree86 forum mailing list. We get individuals, companies like Sun, SciTechSoft, Red Hat etc. 'fighting' for issues varying from what XFree86 really needs, down to replacing fontconfig with Sun's stsf, XFree86 co-founder David Wexelblat saying that XFree is today obsolete and that needs to be replaced with a direct-rendered model (by retaining backwards compatibility), Keith Packard replying as to why a new organization to handle X is needed, and more.
Our Take: One thing is clear after reading all these messages: a lot of people are not happy with what's happening with the development of XFree86. It is obvious that more discussion is needed to decide what's going to be implemented and what not, and from these emails there, it seems that there was no real/common direction discussed between the interested parties until yesterday. No real communication seemed to exist!
Let's hope that this open forum list will show what people want and need and will 'open' the XFree86 organization in a way that will allow more CVS commits, as the project seems kind of stagnant and doesn't move as fast as it should have, as some Red Hat employees also noted (for example, direct changing of resolution was introduced just a few months ago with RandR extension, while Windows 95 could do that in 1995).
The XFree86 project always looked a bit conservative to me while more development and openess is needed. There is no need for a "new XFree", but there is a need for more development and 'fixing' on the existing codebase.
--------
Free your mind.
Psssshht! I mean really! Who wants to setup a thin-client model at their business anyway? I mean saving millions of dollars? What's up with that?!
and it has ugly ass fonts....
Damn straight! Anyone who has zero knowledge about X knows that the fonts are hard coded into the display manager. And that there's no way you can add new fonts to it.
and it has shit write to hardware through TCP ports...
Like, I'm saying, yo! There ain't no client/server interface. When you be sending them X packets to the other computer, you're talking directly to the hardware! That's why every X command is "add ax,bx" and sh*t like that! It's pure assembly, bro!
Everyone knows that the only way to do it is to build a gigantic motherf*cking graphics subsystem into the kernel so that your system resources are halved and your OS crashes every week. Like, that's the ONLY way it should be.
I looked at some of the screenshots for stsf and I think that it's pretty sweet. The standard Motif font menu labels are hilarious though, the selectable fonts look awesome and the old motif fonts in the menus look terrible.
Here's some links to the screenshots of stsf running on Solaris 9:
xclock -digital -fg yellow -bgpixmap SolarisLogo.pm -fga 0.5
LANG=zh_CN.UTF-8 xclock -digital -bgpixmap RicePaper.pm
My blog
The concept of the community voting for membership in the leadership of the project is an almost, if not totally, non-existant concept in the Open Source world (feel free to show me examples). I'm not talking about advocacy groups, like Linux International. I'm talking about development projects. XFree86 has no interest in this, as far as I can tell.
I can think of one right now. So can he, since he mentions it a few paraghraphs later. The FreeBSD Core team is elected. To be core on FreeBSD you have to be an active developer, and have not pissed too many other developers off recently (or at least pissed them off less than most other people). Sounds like a good idea to me...
Oh. Wait. Sorry, I forgot. FreeBSD is dead. I really should stop using it sometimes soon. Can't be using a dead OS on my desktop...
I am TheRaven on Soylent News
Whatever happened to choice in this debate?
We can choose between various window managers, various linux flavors, and even office suites. Why don't we have a choice with our window system?
Why would it be any different for a fork of X for a choice between client/server and direct rendering, if backwards compatability was kept?
Would that not help the the people who only use Linux on their desktop, while allowing people with networks to use the tool, as it is now, that works for them?
How this got modded up is beyond me. Not only is it not insightful, it's downright wrong!
When communicating to local hardware, there is no TCP/IP anywhere. It communicates over a local socket. It has been implemented with shared memory, and guess what? It didn't perform any better than over a local socket! That's why you don't see shared memory in XFree today.
And i dunno about you, but my fonts look just fine. They're probably the same TrueType fonts you've seen a million times on Windows.
b.c
I recently saw somebody try to contribute a new driver to XFree86. He was told that he was welcome to contribute the driver, but that he wouldn't be allowed write access to it once he had handed it over. What a ridiculous policy!
The thing is, drivers can be released independently of X itself. For ATI Radeons, for example, there are at least 3 different drivers they can use. It would be nice if somebody set up a website with a page for each video card (or family of cards) that had links to all of the available video drivers for that card. Even better would be if such a website could act as a catalyst for uniting these independent driver developers so that, for example, the GATOS radeon driver developers and the DRI radeon driver developers could combine the best aspects of their drivers. This could possibly help route around the blockage that the XFree86 project too often represents.
Actually, I think that such "hardware-centric clearing houses" would be useful for all kinds of hardware, not just video cards. Look at linuxprinting.org to see how well it can work.
-DA
As David W points out, XFree86 is around 11 years old. I was around when the project was started and was a low-key member (my name was all over the documentation for many years afterwards and may still be, I haven't checked for a long time).
Anyway, one thing that rarely gets mentioned is how XFree86 itself was a fork. A fork from a recalcitrant developer, namely Thomas Roell. Roell went on to be a principal (probably founding) engineer at Xinside, later renamed Xi Graphics. Roell was the primary author of X386 which was the only freely available X server for x86 systems (typically SVR3 and SVR4 unices from a handful of companies like AT&T and Dell - yes Dell actually had their own Unix distribution and it was pretty kickass too). X386 had limited chipset support (IRC, Tseng Labs ET4000 was the faster chipset it supported) and little if any support for hardware acceleration.
Anyway, the story gets a little murky here, because I wasn't in on all the background machinations, but a couple of developers who are now in the core group (DavidW for one, and I'm thinking David Dawes and Tsilias, but don't quote me) got together and forked their version of X386 to add support for more chipsets and more OSes, kinda leaving Roell (unhappily) in the dust. It didn't help that Roell's got an ego (which he *mostly* deserves) and that DavidW had a kind of angry-young-man online persona at the time either.
It appears that Roell eventually got over it, but never enough to join in the fun. Instead he went on to do commercial X server development, ultimately at XiG.
But, the moral of the story here is that XFree86 itself (even before it had a name, I remember the vote on the mailing list, I didn't vote for it, thought it was kinda dorky, but I guess my own suggestion was even dorkier since it didn't win) is a fork of code that was floundering and not being developed fast enough for the tastes of some people. People who were willing to put their code where their mouthes were and to improve the situation, and who didn't really care too much who they pissed off in the process as long as the end result was a big improvement - and that it definitely was.
I've been out of the loop on XFree86 for many years, but from the outside looking in, this current spat has the ring of history repeating itself to me. It is just more public since the userbase is a couple of orders of magntitude larger than it was the first time around, and there was no slashdot back then either...
I still remember the transition from X10 to X11.
However, version 11 is almost 15 years old and we
never saw any version 12 (not that I beleive version numbering is any important).
Although I saw some nice extensions being added to the X protocol, there are many parts of the X window system that are now obsolete.
For instance the standard X11 font rendering system looks like it has been kept in the stone age (only recently the Xft extension solved part of the problem).
I really like the network transparency of X and the client-server model, because of all it's advantages and, if you look at it in detail, you will be surprised that it doesn't impose any performance penalty: because of the way the X protocol is implemented, commands are queued by the client and are sent to the server in batches, in order to minimize client/server context switching.
However, in the last 12 years we have seen the graphics hardware improove a lotm but the core X system didn't improove almost anything.
Now we have hardware capable of displaying full motion video, hardware video decompressing, anti-aliasing, alhpa-blending and transparency, 3D, etc.
Meanwhile, X got some extensions to support some of these features, but there are no "standard" APIs and the evolution has been very slow.
X is great, and many of the complaints about X that I regularly read here in
I spent a brief time working as a contractor for a Linux distributor (now defunct). During that time, I was given the task of maintaining portions of XFree86's XInput and DRI code. What I saw, I didn't like.
Efforts to extend XFree86 to support modern graphics capabilities (XRender, Xft, R&R) are floundering because the level of skill needed to develop and maintain them is simply too high. The XFree86 codebase reinvents many wheels, is difficult to maintain and really does carry a lot of legacy footwork that makes it difficult to work with.
That said, XFree86 works amazingly well for what it is. I just don't think XFree86 development is sustainable. The same effects can be achieved with a thin layer like DirectFB without the overhead. You get the same functionality, usually better performant and with far less code necessary in the implementation. Network transparency can easily be provided by modern component object models like GNOME's Bonobo and KDE's Kparts, with the added bonus that clients are thin and so still usable over a high-latency network.
I wouldn't go so far as to call XFree86 obsolete, but the technologies upon which it's based certainly are.
you put the graphics close to the metal and then abstract that instead. That's why DirectX is the darling of game developers.
>>>>>>>>>
That's hilarious. Graphics hardware has gotten so advanced, that direct access actually *hinders* performance because it prevents the graphics card from optimizing things as well (a developer for the BeOS Radeon driver once told me this). DirectDraw has been getting significantly more abstracted, to the point where it was put on top of Direct3D which, like OpenGL, is a quite high-level abstraction. Look at the way current graphics cards are designed to run:
Making individual calls to the graphics hardware (over the AGP bus) to draw each element is hideously slow. Instead, graphics hardware is designed to take a pointer to a memory region containing a big batch of drawing commands. The CPU fills the command buffer, sets up a DMA on the graphics card, and waits for an interrupt for the GPU to finish processing. As a result of this, OpenGL implementations work the following way: the OpenGL library (in userspace) creates a command buffer from the OpenGL calls the application makes. When the command buffer is large enough (or the application does a flush), it makes a (expensive) call into the kernel driver, which sets up the DMA and drawing operation and returns control back to the app. Notice, that because of the batch-orientation, the performance bottleneck is not in the communication between the application and the hardware. Even if having a client server model makes the flush stage 10 times slower (it's more like 2x or 3x in reality) there won't be a significant performance difference. Given that OpenGL libraries live entirely in userspace, with a small kernel driver responsible for setting up DMA operations and responding to interrupts, there is no reason to believe that putting things "close to the metal" will make things appreciably faster.
A deep unwavering belief is a sure sign you're missing something...
The key issue here, as far as I can tell, is whether the XFree86 guys were correct to kick Keith Packard out.
On the one hand, David Wexelblat has strong words about Keith Packard's actions:
What Keith has done is among the most low-class, unprofessional, and tactless things I have ever experienced in my professional career.
For Keith to blatantly lie to the Core Team about what he was doing is utterly unacceptable.
But what Keith is doing, at least how he's handled it, is just flat out wrong. It's literally dishonest, and morally repugnant. Doesn't mean that there aren't some valid issues to work, or that there is no need for branching, but (a) it remains to be proven, and (b) I'll be damned if I'll quietly accept it being done by someone who is lying to my face.
Whew. On the other hand, here's what Keith Packard has to say:
Some have suggested that this was a secret attempt to undermine the XFree86 project: this was not my intent. I have tried as hard as I can to work within the existing XFree86 structure.
It's hard to think that this is some kind of misunderstanding. Either Keith has been lying, or else he hasn't. It's impossible for us to really decide for ourselves, since the emails containing the alleged lying are not public.
David Wexelblat said:
There is an email thread documenting this. Some members of the BOD wanted to post the email, or quotes therefrom, with the announcement. I and some of the others were utterly uncomfortable doing that. I don't think anyone on the BOD or Core Team would have any issues with an independent audit of this email thread, if there are concerns about the veracity of what I say, but airing that in public isn't appropriate, IMHO.
I'd like to see someone I trust given the job of auditing those emails, and judging whether Keith Packard has in fact been lying.
P.S. A fork might be a good thing, in the end. Keith Packard says he believes his fork can attract more developers and improve more quickly than the status quo. If he can pull that off, we will all be better off. But unless he can clear his name, he may have trouble attracting developers.
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
Please know that with the next coming XFree86 version you get a lot of GNOME components without even knowing it. code like, GNOME-XML, pkgconfig, fontconfig, xcursor and xft2 were mainly written by people who're heavily involved into GNOME development
Oh, dear God! People who know what a modern desktop system needs are making XFree86 a better platform for such! They're even going so far as making it possible to use the X font system for something besides western European and east Asian languages!
If KDE people want to work on XFree86, they should go for it. But don't bitch because desperately needed new features get implemented by Gnome people if you don't.
There was a design decision made when creating X that displaying windows on a local workstation should be as easy as displaying windows on a remote workstation. This decision affected several things about X, and made the X API's extremely difficult to learn (pick up an X book, you'll see), but extremely powerful.
Basically, what some people are saying is that that decision was wrong - that it's not correct to design an entire graphics API around the concept of displaying windows locally and remotely.
Really, the most objective way to analyze that claim is to look at how many windows users open on their own workstation, versus how many remoted X applications they run. Compare that percentage. Then take a look at how much more complex X was made to handle the eventuality of having to handle remote windows, etc, etc. Is it worth it?
Me personally, I don't think so. The only real use I've had for remote X applications was in terms of systems administration - but this is stuff I could have done as easily with something like ssh, or, if I needed some kind of graphics, PC Anywhere, or Timbuktu. And for applications to be faster, better behaved, and less bloatey, I'd be willing to install some PC anywhere-style application on the occasional remotely-controlled server. For the most part, people would be able to leave it out.
That being said, I've never used X in a thin-client environment - it's possible that it could perform quite well - and I've heard that the X protocols are very good at keeping network use down. It still strikes me as not the right distribution of power between server and client, but what the hell do I know?
The reality of it is that NT's graphics system and X11 are not all that different. It's just that at a higher level, there is no support for remoting applications in NT.
Yes, it is true that if people wanted to, we could move X11 into the kernel, in analogy to what NT did. We have moved the NFS server into the kernel for the same reason. X11 is probably leaner than the NT graphics subsystem that got moved into the kernel, so this wouldn't be a big deal. However, we really don't need the maintenance nightmare. Keeping X11 in user mode is a sensible choice, even if it costs some performance.
Heck, most of the time even Terminal Services on Windows 2000 (running over a 10mbit network) is more responsive than my Linux box.
There are many possible reasons for that. Maybe you are running Gnome or KDE, for example. But X11 isn't at fault.
Get rid of X and you have a desktop OS that can actually compete. You DO NOT abstract the windowing system first and then tack stuff to it (say "OpenGL") - you put the graphics close to the metal and then abstract that instead.
The graphics is close to the metal in X11: you send the server a bunch of high-level operations you want it to execute and it does it for you, using hardware acceleration and highly optimized drawing routines. X11 is really like Apple's Quartz in that regard, only that X11 uses a more efficient binary protocol (server-retained vector graphics is an extension for X11).
By your argument, we should all be programming in framebuffer libraries running in user mode. We had that. It's slow, it's unsafe, and it's very inconvenient. Trust me, I have been there.
That's why DirectX is the darling of game developers.
And how many application developers do you know who program in DirectX? There is a reason why we have DirectX/DRI on the one hand and GDI+/X11 on the other.
I don't agree with Havoc Pennington on many things (like usability matters), but I do agree with this. Keep the client-server model, it's virtually free (wrt resource costs). The real performance sink is in the rendering of fonts, opengl, window managing, redrawing et al. X11 just needs to catch up with the capabilities of current graphics hardware. There's really not much wrong with it, besides that it lags behind somewhat.
This fork might be just the kick in the arse XFree86 needs to get it up to speed again. Nothing like a little ruckus amongst the developers to get the creative blood flowing again. Go Keith!
The notion that there is anything "direct" about Windows GUI rendering is silly. And for the Mac, it's even sillier, given that it uses a PDF-based system derived from DisplayPostscript. The world has moved to an X11 model, it's just that most application programmers haven't figured out yet that the world has shifted under their feet.
X11 needs major work, things like transparency, rendering, server-side vector graphics, etc.--and that is happening. But one thing it doesn't need is turn into a pretend-frame-buffer library. The other thing it doesn't need is to have a lot of junk and policy hard-coded into the server (widgets, window management, etc.), like some would-be competitors are trying to do.
Something that David Wexelblat posted bothers me. I'm sort of confused by his stance, because while he admittedly does not use X, he is at the same time airing his criticisms of it, yet refusing to let Keith Packard fork gracefully. Anyway the bit that bothers me:
"- There is no reason for Core Team matters to be public. This is the
leadership forum, not a public forum."
What is the difference between Core Team members keeping their plans secret and not allowing the public to participate, and Keith Packard keeping *his* plans secret and not letting the Core Team know about them, which he is getting lambasted for? Sort of hypocritical. If the X license is an Open Source license, the Core Team doesn't have any special rights with regard to modification and distribution than Joe Hacker who wants to fork it does. X (X11R6) hasn't changed in a hell of a lot of time (relative to most opens source projects), so what is the purpose of shielding XFree from the public? Some panties need to be untied.
It's 10 PM. Do you know if you're un-American?
...after reading your long message, and also reading David Wexelblat's message, and reading all the stuff that came before, it's pretty clear to me: the X Core Team doesn't want to talk. They don't want outside input, they've deluded themselves into thinking that other Open Source projects are just as closed as they are, and they really don't see where all these outsiders get the right to have an opinion. They ask why you (Keith) didn't open a discussion with them, but then act hostile to nearly everything that is discussed.
I don't know how to write a driver for X, but I do know people. And you're banging your head against a wall as long as you try to work within their system. Good luck with whatever you decide.
My Greasemonkey scripts for Digg &
- pluggable implementations (on Linux alone, there's XFree86, MetroX, Accelerated-X,
...)
- better opportunity for security (though I grant it's not often taken)
- cleaner interaction between applications displaying on the same desktop-- most of the "hacks" won't let applications running in different places share a desktop transparently
For that matter, most desktops released within the last 8 years are so slow and bloaty themselves they can't afford a wire protocol abstraction layer between them and the display driver! Try something truly lightweight, like twm or one of the early incarnations of fvwm with something better than those miserable default configurations, and watch your desktop scream, even with X's supposed weight....when you're writing a game...tweak the difficulty of "Easy" to something [your mother] can cope with. -- onion2k
I was appalled at how many folks jumped on Keith after the initial /. article. I mean, they were basing their responses on a one-sided tale.
I knew Keith back in the X Consortium days, before anyone was even attempting a serious port to X86 boxes - because they were just too pathetic. Keith has always had an excellent attitude, and cared deeply about the technology, the developers, and the user community.
If Keith has problems with the way something is being handled, only a *fool* would refuse to listen. And that doesn't say much for the folks at Xfree86 who kicked him out, with essentially no notice.
If you've paid any attention at all, XFree86 has been slowing down. Releases get slower and provide less. The driver issue is well documented already.
The X Consortium did far more with far less than XFree86 has been doing the last couple of years, and (IMO) did it much better.
I haven't been involved in XFree86 (I haven't even tried to for several years), so I don't know what the underlying problem is. But I would definitely listen to Keith, and to David Wexelblat, as well.
Maybe, just maybe, we'll get something that works.
[And for those who want to chuck X, well, go use Windows, or suggest a better alternative. To date, I haven't seen anything close. And if you didn't have to live in the pre-X11 world, you have *no* idea what you're proposing - unles syou have that alternative handy.]
i was optimizing my mandrake system for audio use, which meant installing a pre-emptible and low-latency patched kernel source package and recompiling it for my specific cpu / architecture
and that meant X turned from snappy enough to blisteringly fast
what is the problem with X then?
the problem is that the linux kernel is optimized on most distibutions NOT for low latency but for high throughput, due to its being used mostly for server boxes.
so if you actually take the time to either pick a kernel that is suitable for desktop use or compile one yourself (which I duly recommend, I learned a LOT from doing so) you have a high-latency/high-througput server kernel. X being slow has nothing to do with X itself, but on the kernel that is running underneath.
your comment about kernel tweaking is sort of like playing quake 3 on a p66 and complaining that its slow and ID software told you to (gasp) TWEAK YOUR COMPUTER! Unthinkable!
Jag pratar lite svenska.
Just because YOU don't, that doesn't mean that OTHER PEOPLE don't.
There's certainly some cruft in X11. Hardware has progressed to the point that forcing applications to notice details of the graphics card's colour model no longer really makes sense. And I'll be happy when TrueType is ubiquitous in X apps (it's getting there). But you can have my network transparency when you pry it out of my cold, dead fingers.
Everytime I hear someone say "X really needs to die", they blame the wire protocol. Well, the first step in optimization is to prove that the optimization you plan to do is actually necessary.
I have seen a large number of projects where "blind optimization" involves reworking large chunks of code only to find out that they haven't really solved the real problem.
As one doctor put it to us a few months ago: "If you think your baby is colicky, she isn't."
Misconceptions. Flexibility and modularity do not imply performance costs. In fact, they imply the possibility to optimize performance. If something is inflexible, you get what you get, even if you don't need all of it's superflous features. That's an unnecessary performance hit. If something is modular, you're free to mix and match parts to choose the best performing ones.
I think alot of people have the misconception that having more layers between applications and the hardware slows things down. That is not the case. Those formal layers (as introduced by the X11 protocol) are just abstractions of what would have to be there anyway. They end up reducing bloat and memory consumption, as well as saving programmers time, so that every programmer who wants to make a 3D visualization program doesn't have to reinvent the wheel by recoding into his application how to access and manipulate the graphics-card/monitor.
social sciences can never use experience to verify their statemen
It's wrong to blame X for slowness. The real problem is the incredibly bloated and slow GUI apps and window managers, and possibly the modern GUI toolkits. Blackbox/Fluxbox/IceWM are very fast. Properly made X applications like xfig are very fast. The Mozilla family of apps has something pathologically wrong with it - nothing should be that slow. The Gnome/KDE stuff seems to me just barely acceptable on a fast machine, but clearly it's bloated and inefficient.
Quit blaming X. That's not where the speed problem is. As for difficult and complicated - your right. But mature technologies that properly handle a wide variety of cases tend to be that way.
I'd like to see DirectFB take off. ... ha! I don't know what most people are whinging about. X is incredibly fast on my computer. I run Enlightenment-0.16.5 and Enlightenment-0.17. And yeah I use network transparency a little. That's cool too. And my games run swift as lightning. Direct Rendering is sure working. Is X really that bad that people need to dump it and start again? I'm not convinced.
It looks pretty cool and is quite fast.
Don't know how practical it is or what issues are involved, but anyway if the X ship is sinking, I'm voting for DirectFB.
Of course the X boat is not sinking though.
All those who are sick of X can just stop using X, and see how you go
Quite frankly, the whole stink with XFree86 reminds me very much of ICANN. Technological snobs who won't listen to anyone else, have closed off public participation, aren't transparent, and now are defaming someone who rightly criticizes them. Furthermore, they are blundering. Why should Xfree86 drivers not be modularized? I only have one fucking video card. I don't need to download the drivers for every video-card Xfree86 supports. Xfree86 has also done an atrocious job of integrating the latest drivers from graphics chip corporations, like ATI. Their failure to promptly incorporate these drivers has alienated hardware developers. Why should ATI spend millions of dollars to make drivers for XFree86, if it takes them so long to incorporate them?
The actions of XFree86.org convince me that they want to restrict user choice in the GNU/Linux world, and prevent anyone else from running any X11-implementations other than XFree86. Their refusal to modularize drivers is one thing convincing me of this.
I can not think of any major projects which are as poor as XFree86 in regards to including the community and being accountable to the community. Many of the people within that "organization" are in fact figureheads who don't even believe in XFree86, like one of the founders linked to. If you don't use XFree86 at all, and only use Windows, then imo, you have no business being part of an XFree86 team.
Keith is right to fork off XFree86. He has tried to address his concerns from within the organization, and has been unable to do so. Just like Auerbach. There is only so much one crusader within an organization can do when the rest of the organization is bent on corruption.
XFree86 is proof that even a project covered under a license approved by the OSI and the FSF can be corrupt and non-transparent.
social sciences can never use experience to verify their statemen
Reading Wexelblats email where he basically tells people that this is none of their business, is like hearing an echo of the argumentation launched against new bylaws in the FreeBSD project.
If David is not actively contributing to XFree86, he has no business telling anyone how to run the project.
I think the active developers of XFree86, both committer and non-committers, should grab a copy of the FreeBSD bylaws and elect a new core team.
The FreeBSD bylaws are far from perfect, but it would be enough to get started and once the dust has settled, a revision to more closely match the needs of the new project can be made.
Poul-Henning Kamp -- FreeBSD since before it was called that...
I use it extensively almost every day I sit down in front of a computer to do anything more than check my e-mail. I think most anyone who has to do a fair amount of work on multiple UNIX machines also uses it frequently.
When I'm working remotely on Windows boxen using Terminal Services, I often find myself sighing wistfully and wishing Windows had a wire protocol. Terminal Services and similar solutions at their best are generally ill-concieved hacks and at their worst are just plain evil and rude.
David Wexelblat is in the Xfree BoD. He's also a core-developer. He flamed Keith Packard because of what he has done. What has Keith Packard done for Xfree recently? Among others:
a) Fontconfig
b) RENDER-extension
c) Xft
d) Work on transparency
What has Wexelblat done recently? According to his owns words:
a) He hasn't hacked Xfree in years
b) He uses Windows these days
c) If he will code something (unlikely), it will be for Windows
d) Only thing he does related to Xfree is to lurk in the core-devel mailing-list
And here we have Wexelblat flaming Packard! Hello!?! Of the two, it seems that Packard cares ALOT more about Xfree than Wexelblat does! He actually works on it and improves Xfree, while Wexelblat plays Myst on Windows! Looking at their recent activities, Wexelblat should just shut the hell up. He hasn't done a thing, who the hell is he criticizing Packard!?
Wexelblat should be kicked out of the BoD and Core and replaced by someone who wants to work on the project and improve it! It's no wonder Xfree has stagnated if there are core-members like Wexelblat who haven't contributed to the project in years! Ironically, it was he (if I remember correctly, could have been someone else as well) who kept reminding that "Xfree is a meritocracy". If it's a meritocracy, why are there useless deadbeats like Wexelblat in Core? Because of their past accomplishments? Maybe Wexelblat was an uber-hacker 10 years ago, but TODAY, he contributes nothing to the project.
Lesbian Nazi Hookers Abducted by UFOs and Forced Into Weight Loss Programs - -all next week on Town Talk.