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?"
Re:Unite! (Score:3, Informative)
Re:Thanks for your "insight" (Score:5, Informative)
"What this means for XFree86
Some will say nothing. Some will say good riddance. Some will say this is the beginning of the end. Who knows? Who cares? Let
Re:"beginning of the end"? Maybe not! (Score:5, Informative)
--
1.1 What is Xouvert?
Contrary to popular opinion, Xouvert is not a fork of the XFree86 project.
Xouvert wishes to provide a development branch of XFree86. What this means is, Xouvert is an attempt to create, implement, test, and bring new features and ideas to XFree86 sooner.
Xouvert has now just started. Currently, Xouvert simply is XFree86. The purpose of this document is to help people get to a point where they can help contribute to Xouvert.
Re:beginning of the end? (Score:1, Informative)
Problems with X Free are the following : they do not care about quite a lot of feature in X at all (such as a 32 bits mode allowing transparencies, and no, this is not a bloat). They refuse to accept pretty good set of drivers for no apparent reason (DRI anyone). And they often radically change the way they implement this or that without telling anyone who is not a close friend. Leading to quite a lot of fun if you are in a low level project(such as LibXCB for example, but DRI people are having fun too).
Kha
Cygwin rules, but asking people to fuck... (Score:1, Informative)
"So, please take this as kindly as possible when I say: Go fuck yourself."
Re:"beginning of the end"? (Score:3, Informative)
That's almost exactly what we said about egcs versus gcc when egcs started, to keep the FSF from flipping out. However, the result was that egcs ended up replacing GCC (what was originally planned as egcs 1.2 became gcc 2.95). This is good strategy for those who wish to avoid a fork: arrange that the fork can eventually become the main branch.
Whether xouvert will replace or take over Xfree86 depends on whether the majority of developers abandon the xfree86 ship and work on the xouvert branch.
Re:Maybe XFree has had its day (Score:5, Informative)
That's not the reality at all. Real environments where X is widely deployed (i.e. not a few boxen on a geek's home lan) frequently use the remote display capabilities of X. Indeed, those capabilities are the among the main reasons X gets deployed in the first place. Only niche markets use X clients and servers exclusively on the same machine (notably the visual effects industry where SGI once ruled and Linux has taken over.) Even in these environments, the overhead of a networking layer is minimal. (And these are among the most graphics-performance-sensitive environments that exist.)
-Isaac
Re:Just like Gnome was the end of KDE (Score:3, Informative)
The issue here is that Harold requested that the Cygwin/XFree86 project be allowed to commit patches directly to the XFree86.org CVS tree. Instead of a direct yes/no reply, he basically got flim-flammed by David Dawes.
Yes there is a replacement. (Score:5, Informative)
Re:Maybe XFree has had its day (Score:2, Informative)
Wrong and wrong (Score:5, Informative)
No, the problem you imagine simply does not exist because X already has the "shared memory extension" [hp.com] to make it possible to write directly into the X-server's graphics memory bypassing the socket communications. In any case, XFree86 uses domain sockets for all local communications. Domain sockets are implemented extremely efficient on Linux. It is definitely not sockets that are causing any delays you may see on your user-interface. It is likely you are using a GNOME or KDE application which is badly implemented whether in itself or in the toolkit on which it is based.
"security implications this has as well"
No, there is no security problem. X defaults to have closed network access. Every PC should also use a firewall which provides a separate stronger access control mechanism. Nobody should be able to access your X-server remotely unless you have explicitly given them permission.
Re:Maybe XFree has had its day (Score:5, Informative)
It's also worth noting the slowest part of X applications is in the badly implemented toolkits they commonly use which do their X event handling clumsily and sub-optimally (graphics exposures).
Mirror of thread (Score:3, Informative)
Re:Maybe the real motivation is license zealotry. (Score:3, Informative)
The xoncygwin project on SourceForge is unrelated to the current discussion. That was setup in 2001, if you noticed the "Registered" date.
SourceForge makes you pick licenses used by the project, so I picked GPL (which Cygwin uses) and MIT for the X Window System portion of the project.
The current issue is not a fork, nor is it anything that Cygwin or Cygnus had anything to do with. I am Harold Hunt. I am not Cygnus, nor amy I affiliated with Cygnus: I made this decision on my own. Licensing is not part of the current issue at all.
Just wanted to clear that up.
Harold
Re:GNU seems cranky (Score:5, Informative)
Their problem is probably exactly what they said.
Why is it that GNU sees the need to fork *everything*?
Like what? Cygwin is not a particularly GNU project, and XFree86 has always explicitly been given support under its current license by RMS.
And who are these myriad other developers that have been turned off by the X group?
How many times does Xouvert need to be mentioned in this thread?
I can see arguments that X is unwieldy and archaic, fine
RTFA. That has nothing to do with it; it's a management problem, not codebase problem.
Open Source Developers (Score:2, Informative)
CVS access is like giving someone the keys to the T-Bird. Everyone's excited to get it, but the parents are always terrified the kid will crash into a tree...and wreck the T-Bird (aww, don't worry, the kid will be FINE...). But CVS has this marvelous feature. You can create tags, and still quickly get around botched commits.
I work on an open-source game (I'm not going to plug it), and most of my commits revolve around a particular area, but occasionally I go over and revamp the configure.in/Makefile.am system and rip out all of the cruft. Ah, there's something nice about that efficiency, but...I could just as easily make it unusable if I made a large commit and didn't check everything first.
But that comes to my other point. You have to appreciate HOW much time each developer puts in. Some will only put in an hour every month or two, while some will simply stay and work on something, a dozen hours a day (or equivilent for their busy life), until it's done, even if small, like autoconf/automake files. Even a relatively unnoticable change from a user's perspective can have huge developer benefits, and people often forget that. Some developers will go for every last user-noticable feature, and some, perhaps like me, will often help out the other developers as much as they can, so that they can be more productive. Project leads often don't realize what a difference that makes until six months after a commit. *grins sheepishly at her 'boss'*
Re:After reading the thread... (Score:3, Informative)
Re:After reading the thread... (Score:3, Informative)
Xouvert is making use of the Arch RCS [gnu.org], which seamlessly handles distributed repositories (each developer generally has his own local repository). There is no single point of failure; if the owner of the "master repository" isn't doing his job, any other repository can be used just as easily.
Of course, Arch also properly handles file moves and renames. That will enable Xouvert to make rather sweeping changes to the XF86 source organization, without losing the ability to sync with XF86 CVS.