Slashdot Mirror


Y: A Successor to the X Window System

impto writes "Whenever someone brings up the topic of replacing X, everyone always says that's nice, but where's the code? Well, Mark Thomas put his money where his mouth is and produced a replacement that maintains network transparency while adding many of the features that people desire from X such as alpha blending and a built-in toolkit. It still needs a bit of work to be as featureful as X but it's a fresh start that takes advantage of current technology and ideas. Read the paper here in PDF (1.7MB) or PS or grab the source and start hacking."

3 of 666 comments (clear)

  1. Re:Depends. by Leffe · · Score: 5, Informative

    ./configure --without-x

  2. Re:A pointless endeavour... by sgarrity · · Score: 5, Informative
    "1. If it can't run existing X windows applications it's useless. Additionally if it can't run anywhere it's useless."

    The document covers this with the obvious solution:

    "Legacy X Protocol Handler

    In order to support the wealth of X applications that already exist, and to ease the transition from X to Y, an interpretation layer will need to be built. This is an excellent example of the elegance of the design of Y. The X layer can be implemented as an in-server driver module. This module would, upon initialisation, create an appropriate socket to pretend to act as an X server. When X applications connect to this socket, the X module would translate the requests into equivalent Y requests. One drawback of supporting the X protocol is that many of the advantages of Y, in particular the lightweight protocol and server-side objects, will be lost."
  3. This whole story is a waste of time by 0x0d0a · · Score: 5, Informative

    Thank you *very* much for pointing this out.

    For some reason, people (generally folks new to X) consistently manage to completely misunderstand how X works, and happily rant about it. Among the issues:

    Problem: X has bad 3d support.

    Answer: No, it doesn't. Manufacturers have just barely put out drivers, and still don't have great install procedures. Starting with a new system would make this problem orders of magnitude worse.

    Problem: X uses lots of memory.

    Answer: No, it doesn't. Try running pixmap_mem (and the analyze script that comes in the same package) on your system. Unlike Windows apps, X11 apps store pixmaps in the server. X11 newbies frequently confuse this with X using a lot of memory. Combine this with the fact that Unix memory utils multiple-report memory usage of shared libraries, and report device mapping as memory usage, and people look at X and say ("Oh, it's blowing 30MB of memory in overhead."). No, it isn't. Trust me.

    Problem: X11 is inefficient.

    Answer: No, it isn't. X11 is pretty damned efficient. Today's pixmap-laden interfaces can run much more slowly over a network than the original interfaces, whicch were mostly big, flat-color rectangles, but the same is true of VNC and similar.

    Problem: X's multiple-widget set system is a bad idea.

    Answer: No, it isn't. People look at X and think "Gosh, I don't want to use Athena apps." The thing is, the widget-independent design of X has been a huge boon. X11 dates to 1987. If we had been unable to advance through widget sets, we'd still be using ugly, grotty Athena. But, you say, this ignores the fact that Windows and Mac OS have advanced through the years! Nope. First, Windows widget sets *have* broken user-level compatibility on a regular basis. Menus in Office XP now work a lot differently than menus in 1987 did. Second, some widget sets are hamstrung by initial design flaws. The classic MacOS widget set does not include a slider widget, for example. As a result, years of application developers misued the scrollbar widget, made up their own widget (which led to even worse user interface problems), or just went without. The ability of X11 to evolve has let things like KDE's tearable panes come to the fore. Also, when it comes to APIs...the modern, easy-to-use APIs of GTK and Qt blow away the horrific Macintosh Toolbox API (note: I am not a Cocoa developer, so things may have improved) or the almost-as-grotty Win32.

    Problem: X11 is hard to use.

    Answer: No, it really isn't. Occasionally, piss-poor setup on the part of distro makers has made things more of a pain than it should be. If a user isn't interested in remote windowing, he shouldn't have to worry about xauth or xhost. This is largely a problem of the past.

    The main "problem" with X11 is actually newbies to it making a bunch of claims about software that they haven't used and don't understand. They've frequently just come off of a decade of Windows use, and expect things to work in precisely the same way, and are horrified when there are differences.

    The majority of people I've seen complaining about X11 are Johnny-come-lately types. Most of the older folks who have been using it for a while just don't care enough to respond to the complaints, which they see as pretty uninformed.

    Now, there are things about X11 that aren't that great. X11 supports an *extremely* rich color model. If you're using Xlib (which you shouldn't be doing unless you're writing a widget set), it is a royal pain in the butt to support every color model available. This was done to handle the vast array of hardware that X11 has been run on.

    X11 doesn't support a great way to share identical pixmaps from different apps. This is really hard to do in a secure way.

    Basically, I'm reminded of the SSL discussion that came up recently. Everyone wants to run out and rewrite SSL to be simpler, faster, easier. They don't understand that the stuff in SSL is there because it *needs*