Slashdot Mirror

← Back to Stories (view on slashdot.org)

Cygwin/XFree86 Leaving XFree86.org

Posted by simoniker on from the oh-the-shenanigans dept.

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?"

7 of 446 comments (clear)

  1. Re:Thanks for your "insight" by Wakkow · · Score: 4, Informative

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

  2. Re:"beginning of the end"? Maybe not! by Pope+Raymond+Lama · · Score: 4, Informative

    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.

    --
    -><- no .sig is good sig.
  3. Re:Maybe XFree has had its day by isaac · · Score: 4, Informative
    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.)

    -Isaac

    --
    I am not a lawyer, and this is not legal advice. For Entertainment Purposes Only.
  4. Yes there is a replacement. by Adolph_Hitler · · Score: 5, Informative

    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

    --
    People don't exist to serve systems, systems exist to serve people.
  5. Wrong and wrong by Wills · · Score: 4, Informative
    "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.

    --
    Scroogle
  6. Re:Maybe XFree has had its day by Wills · · Score: 4, Informative
    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).

    --
    Scroogle
  7. Re:GNU seems cranky by dvdeug · · Score: 4, Informative

    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.