Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
X GUI Software

Cygwin/XFree86 Leaving 446

An anonymous reader writes "The Cygwin/XFree86 project is leaving 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?"
This discussion has been archived. No new comments can be posted.

Cygwin/XFree86 Leaving

Comments Filter:
  • Re:Unite! (Score:3, Informative)

    by DrWhizBang ( 5333 ) on Monday October 27, 2003 @03:23PM (#7320995) Homepage Journal
    I believe this [] is what you are looking for.
  • by Wakkow ( 52585 ) * on Monday October 27, 2003 @03:26PM (#7321017) Homepage
    He was quoting the announcement:

    "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 /. figure it out."
  • From the Xouvert HOWTO on the very link you posted above:
    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.
  • by Anonymous Coward on Monday October 27, 2003 @03:33PM (#7321082)
    Bloating X is a problem that is handled by the X Consortium, which is very clear about what should be, and what should not be in a X server.
    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).

  • by Anonymous Coward on Monday October 27, 2003 @03:40PM (#7321139)
    Read this [].

    "So, please take this as kindly as possible when I say: Go fuck yourself."

  • by JoeBuck ( 7947 ) on Monday October 27, 2003 @03:55PM (#7321288) Homepage

    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.

  • by isaac ( 2852 ) on Monday October 27, 2003 @03:56PM (#7321302)
    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.

    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.)


  • by Nerant ( 71826 ) on Monday October 27, 2003 @03:56PM (#7321305)
    Actually, this is more like someone submitting a decent patch to Linus, and then Linus refusing to accept the patch and giving a reply like "The weather isn't very good today for that sorta thing", as to a "No, because of blah blah technical reason ".

    The issue here is that Harold requested that the Cygwin/XFree86 project be allowed to commit patches directly to the CVS tree. Instead of a direct yes/no reply, he basically got flim-flammed by David Dawes.

  • by Adolph_Hitler ( 713286 ) on Monday October 27, 2003 @04:01PM (#7321372)
    XUOVERT is that replacement. Let Xfree86 burn in hell and lets make a fork. I'm sick of reading stories about how the Xfree core people are preventing drivers from being commited and closing themselves off to the world, if they dont want developer support we should fork Xfree86 and compete with them, if they are so good at coding that they make a better Xfree86 than the community does well props to them, but if they don't, well they lose. Survival of the fittest. XOUVERT []
  • by csp ( 224831 ) <> on Monday October 27, 2003 @04:05PM (#7321411) Homepage
    How many times does this have to be said? X does not use the network for local display: it uses standard inter-process communication with shared memory. The overhead of remote display is only incurred when using a remote display.
  • Wrong and wrong (Score:5, Informative)

    by Wills ( 242929 ) on Monday October 27, 2003 @04:10PM (#7321450)
    "networking layer ... unnecessary overhead"

    No, the problem you imagine simply does not exist because X already has the "shared memory extension" [] 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.

  • by Wills ( 242929 ) on Monday October 27, 2003 @04:33PM (#7321690)
    Yes, that's right except an X application must be programmed to use the shared memory extension to X [], otherwise it will use the default -- a unix domain socket in /tmp -- which is usually slightly slower than shared memory. However, it's worth noting that unix domain sockets are extremely efficiently implemented on Linux. The overhead in the X server for using domain sockets is so small it is insignificant compared to the graphics overhead in most toolkit libraries. If anyone's interested, it is tedious but possible to confirm the domain socket overhead is small either by analysing the output of strace -T Xserver_pid (on a separate display to avoid deadlock!) or preferably by recompiling X with profiling enabled.

    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)

    by Cee ( 22717 ) on Monday October 27, 2003 @04:38PM (#7321728)
    Mirror of the trouble-starter thread [].
  • by haroldhunt ( 199966 ) on Monday October 27, 2003 @05:48PM (#7322460) Homepage
    No, that is not it at all.

    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.

  • Re:GNU seems cranky (Score:5, Informative)

    by dvdeug ( 5033 ) <dvdeug@em[ ].ro ['ail' in gap]> on Monday October 27, 2003 @06:18PM (#7322795)
    Is their problem with X that they don't release under the GPL?

    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.
  • by Peorth ( 719504 ) on Monday October 27, 2003 @06:27PM (#7322906)
    I think hard-working open-source developers are often neglected, particularly for things like this, which started over adamant refusal of CVS access to someone effectively maintaining a platform.

    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 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'*
  • by black mariah ( 654971 ) on Monday October 27, 2003 @06:54PM (#7323162)
    No, he made the statement to the effect that he didn't want to waste so much of his time trying to get commits into the XFree CVS and if they didn't see fit to give him CVS access, he'd go someplace where he COULD get it. This is obviously a matter he has discussed before with these guys, and their lack of interest in giving the main developer of something like that CVS access is quite childish. I don't blame Hunt for wanting to get away from a bunch of immature assholes.
  • by Fourier ( 60719 ) on Monday October 27, 2003 @07:55PM (#7323695) Journal
    Perhaps if CVS were easier to use, or of development teams more regularly used something other than CVS

    Xouvert is making use of the Arch RCS [], 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.

Today is a good day for information-gathering. Read someone else's mail file.