Slashdot Mirror
Cygwin/XFree86 Leaving XFree86.org
An anonymous reader writes "The Cygwin/XFree86 project is leaving XFree86.org. For those that don't know, Cygwin/XFree86 is a port of the X Window System to Cygwin (which provides a *nix-like API on Windows). Here is the announcement and the start of the trouble. The XFree86 project has pushed away more developers than most projects ever have - is this the beginning of the end for XFree86?"
If developers are leaving the XFree86 arena, where are they flocking to? Is there a replacement readily available or is one in the works?
I'll certainly say that Xfree86 isn't going anywhere for a while, as it is all over the place now. But I do feel (and others probably do too) that it's about time we 'started again' with something like X but a whole lot neater and simpler.
slashdot story on the topic.
how many XFree86 users are using Cygwin port? 1 percent? Let us face it, it is not the "beginning of the end" but is rather the "end of the beginning of the end".
Don't get me wrong, XFree86 is great and all, but I wish there was a replacement. I would be willing to wager that >75% of those of us who run a Linux desktop don't need hardly *any* of the advanced features in the X Windows server. I would like to see a completely modular, X-windows core-compatible windowing system for Linux. Want to use some of the advanced features? Add in the module, recompile, and go!
The XFree86 project has pushed away more developers than most projects ever have - is this the beginning of the end for XFree86?
I think not and here's why: I've been working as a consultant for one of the top banks in the US for the last 10 years. One of my roles is to maintain the COBOL-emulator for the VAX systems that we store customer data in. One of the integral pieces, as you may guess, is CygWin. We actively add elements and integrate third-party products with CygWin since it is the best at what it does.
The greatest challenge for our team is to enhance the Win32 abstraction layer so that it no longer interferes with the HAL on a multi-processor layer. We've made some progress and thanks to CygWin we're close to completion.
Which is nice.
I've been trying to figure out how to get this fullscreen patch for Cygwin/X into the dist, but the xfree86 dev list tells me to submit to bugzilla. So what, I'm supposed to invent a bug and then solve it? Its a new feature and it would be nice to have a real place to discuss and enhance it (the xfree86 dev list is very aloof and hasn't been kind to me at all as a newbie x developer). I think it's a good move for Cygwin...
std::disclaimer<std::legalese> sig=new std::disclaimer; sig->dump(); delete sig;
I can understand their decision. XFree has matured to be a really broken pile of software which is badly maintained after all. There is a known CMS and XLIB locking problem in XFree 4.3.0 and upwards which they reject to fix (and this is known for many months now). Even patches and fixes exist for it and they still reject to fix it. When you use GTK+ 2.3.0 on it then it heavily crashes.
Read here the fixes
I can imagine that there are to many trouble but I think that the remaining people working on XFree are fucking dumbasses and the primary troublemakers here. They threw the major leading developers out, those that liked to bring XFree up to new roots, fix many bugs, make it modern. And what do we have now ?
Xouvert as lame fork with people who may not be able to deal with it.
XFree as a lameass project full of bugs they not gonna fix, full of people who slowly develop it and who use old versions of xcursor, freetype, fontconfig and stuff like this. Ignore bugreports and fixes
FreeDesktop org as last bastion for people like Keith Packard and Jim Gettys to fix all the stuff.
I think we should start to boycott XFree.
I like Xfree. But it's still basically X. The problem I have with X is that it's overkill for most client desktops. It's nice that X allows remote windowing. But how many users actually need that? (I'm ignoring the security implications this has as well.) The reality is that 99.9% of X applications have both the client application and X server on the same machine. So why have such a complicated networking layer to draw a window on a screen? Seems like a lot of unnecessary overhead to me.
I seem to remember there was a move to streamline X given this new reality. But I don't know what it's called. Could someone fill me in?
When all else fails, run.
Among XFree86's other problems is the apparent lack of any sort of regression testing. I only upgrade XFree86 when I'm forced to because of upgrading my Linux distribution, and over the years, about half the time this has caused something to break that used to work, causing me to lose many hours and days over the course of weeks trying to fix the problem.
Yeah, guys like Keith Packard were just bloating Xfree!
In fact, it seems that KP was just about the only guy who was passionate about Xfree and REALLY worked on it. I didn't know whether I should laugh or cry when I saw KP being flamed by David Wexelblat (one of the founder of Xfree) in Xfree mailinglist. It was sad/funny because while Wexelblat was busy flaming KP, he also mentioned that he does not even use Xfree there days, let alone hack it! He uses Windows these days!
So, Guys like Keith Packard get kicked out, while useless deadbeats like David Wexelblat are members of the core-team. What's wrong with this picture?
Lesbian Nazi Hookers Abducted by UFOs and Forced Into Weight Loss Programs - -all next week on Town Talk.
X has lots of problems, but the network transparency is NOT one of them. This is a myth that comes up all the time, by amateurs that somehow picture it calling a central server at MIT for every graphics call.
On a mondern system (with security) there HAS to be a context switch some time between a user program producing the graphics and the system drawing on the screen. The network transparency adds zero overhead on any modern system, in fact it encourages reduction of overhead by forcing the batching of requests into single context switches. When anybody says that Windows can do each call in 1 context switch, I have to point out that X (if it was properly designed to not require so damn many syncrhonous calls) can do tens of thousands of calls in 2 context switches.
X's #1 problem is the bad graphics model which means that drawing anything more complicated that 1985 graphics (such as anti-aliased shapes) requires you to draw an image and send it, which is going to be slow even if the app could draw directly into the on-screen image buffer.
X's #2 problem, and really the cause of perceived slowness, is that seperate window manager, and people are going to have to face reality and move the window borders and resizing and all other drawing into the app's toolkit, so that synchronization between that and the rest of the app's display can be preserved. Notice that nobody complains that moving things inside the apps is slow.
Fresco has been bogged down in Alpha status for the last 5 years. Some people think that the only reason it is so slow in development is because no-one knows about it.
But the real reason is because Fresco sucks and no one wants to touch it with a 10 foot pole. If you think X is bloated, Fresco is 10 times worse. Its an over-engineered solution heavily reliant on C++, CORBA, GGI, and other crap.
X does suck, but 90% of the basic design of X is excellent. A new windowing system should focus on keeping the basic design, while (a) eliminating legacy crap that no one needs anymore, and (b) adding the stuff we DO need like Drag and Drop, Transparency, AA fonts, 3D, etc.
-- LD