Cygwin/XFree86 Leaving XFree86.org 446
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?"
Leaving? (Score:3, Interesting)
Not for a while.. (Score:3, Interesting)
"beginning of the end"? (Score:5, Interesting)
slashdot story [slashdot.org] on the topic.
Thanks for your "insight" (Score:5, Interesting)
Re:Not for a while.. (Score:5, Interesting)
beginning of the end? (Score:3, Interesting)
I wish. (Score:5, Interesting)
Perseverance (Score:4, Interesting)
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.
good move - their whole patch system is whacked (Score:5, Interesting)
XFree are really stupid people ... read why! (Score:2, Interesting)
Read here the fixes [freedesktop.org]
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.
Re:Not for a while.. (Score:3, Interesting)
However, some people are bound to complain at its integrated standard toolkit. I like the idea of a standard toolkit for consistency across applications, but to keep everybody happy (and for ultimate flexibility, which is what Linux is about, right?), it would be good for the choice of toolkit to be pluggable... Not based on top, as current toolkits are, but just swappable by Y. That way, we could all be using the same API and have things just the (consistent) way we want them.
Some native OpenGL and SVG support might prove useful too..
Maybe XFree has had its day (Score:3, Interesting)
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?
Re:Maybe XFree has had its day (Score:2, Interesting)
If more open source programmers actually read and understood the bloody X programming manuals, you'd see MUCH better performance. Instead of idiots creating and deleting entire GTK image buttons each frame to animate or something.
Regression tests, anyone? (Score:2, Interesting)
Re:beginning of the end? (Score:5, Interesting)
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?
You are totally mistaken (Score:3, Interesting)
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.
Yeah right (Score:4, Interesting)
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