Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
X Graphics

X Window System Turns 30 Years Old 204

An anonymous reader writes "One of the oldest pieces of the Linux desktop stack still widely in use today is the X Window System that today is commonly referred to as X11 or in recent years the X.Org Server. The X Window System predates the Linux kernel, the Free Software Foundation, GCC, and other key pieces of the Linux infrastructure — or most software widely-used in general. Today marks 30 years since the announcement of X at MIT when it was introduced to Project Athena." X wasn't new when I first saw it, on Sun workstations the summer before I started college. When did you first encounter it?
This discussion has been archived. No new comments can be posted.

X Window System Turns 30 Years Old

Comments Filter:
  • time to die... (Score:5, Informative)

    by Danzigism ( 881294 ) on Thursday June 19, 2014 @09:53AM (#47271485)
    They are replacing X11 with Wayland. There's definitely much of X11 that is obsolete from a developer's standpoint. Pretty cool actually. http://en.wikipedia.org/wiki/W... [wikipedia.org]
  • by peter303 ( 12292 ) on Thursday June 19, 2014 @10:08AM (#47271653)
    Paul and his adviser, whom I forget, wrote it in the early 1980s at Stanford. MIT liked it and decided to manage its development. It was after Xerox Parc and Apollos distributed graphics system, but before Sun, Apple and MicroSoft. Following Unix's minimalist toolkit naming convention "X" was the command stream and "W" the display api. Our Stanford computer joined in at version #5 on a VAX. It was commercially supperted around version 10 by DEC and Sun. And "froze" at version 11, going into 2nd and 3rd digit numbering after that.

    There was always the intent to make it objected-oriented, hence the tootlkit kludge called Motif. The early 80s was in flux over OO languages Xerox MESA, way-to-slow Smalltalk, ObjectPascal, etc. C++ and ObjectiveC wouldnt be around for a few more years.
  • Re:time to die... (Score:5, Informative)

    by fuzzyfuzzyfungus ( 1223518 ) on Thursday June 19, 2014 @10:47AM (#47272191) Journal
    Network transparency is a very nice feature; but it's debatable how 'transparent' X still is once you try anything remotely fancy or modern.

    OpenGL, in particular, wasn't really part of the plan. It's been hacking in (in a number of different ways); but it's still pretty easy to trip on a mine: If the program is running on the remote host; but using your GPU, GLX indirect rendering should work, as long as you don't hit any OpenGL extensions that expect direct hardware access; but if your application likes to throw big textures around as though it were developed for computers where the 3d card is separated from the CPU by 16 PCIe lanes, rather than a LAN(or, god help you, WAN), you'll notice.

    If you want the server to do the work, so that you can use an actually-thin thin client, you end up with something like VirtualGL, which uses X11 on both ends; but actually handles slinging the image data with VNC...
  • Re:time to die... (Score:5, Informative)

    by Arker ( 91948 ) on Thursday June 19, 2014 @10:55AM (#47272283) Homepage
    It's used every day, just not by you.
  • Re:time to die... (Score:4, Informative)

    by BitZtream ( 692029 ) on Thursday June 19, 2014 @11:01AM (#47272391)

    Ah, spoken in the true voice of slashdot ignorance.

    The protocol is fine, the library isn't that horrible unless your a newbie to dev, nothing needs replaced and it was designed with extensibility to deal with modern problems in a sane way.

    Just because you read some document written by someone who wants to replace it for selfish reasons like making their display system the standard doesn't mean its actually true.

  • Re:time to die... (Score:4, Informative)

    by TheRaven64 ( 641858 ) on Thursday June 19, 2014 @11:15AM (#47272537) Journal

    The problem with network transparency in X11 is that it's done at completely the wrong place. With competing systems of the same era, such as NeWS, there was some code running in the display server for display updates. This meant that, for example, you could handle the visual feedback for a button press in the server, while transmitting the 'this button has been pressed' event to the client. In X11, you press the button but the server just sends a 'mouse clicked at x,y' message to the client, so you need a network round trip just to update the button. If you want to animate the button press, then you need to wait for network round trips to get the 'redraw finished' events. Wayland isn't a step backwards in this regard, but it's also not a step forwards.

    In a modern X client, you don't really use much of the server's drawing functionality. You do store some images for compositing and will use XRender to composite them, but that's about it. The line drawing stuff can't handle antialiased lines, the text drawing stuff (aside from XRender) can't handle fonts provided by the client easily, so all you're really using the display server for is getting some texture memory and compositing it. With Wayland, you just get an OpenGL context and do the same thing. To be honest, if you're targeting X11 that's also what you should be doing for modern hardware: the rest of your drawing code most likely uses OpenGL (or something higher-level with an OpenGL back end), or just generates pixmaps, so doing the per-window compositing in OpenGL is a lot easier than doing it in a completely different API.

  • Re:DECwindows ;) (Score:5, Informative)

    by gman003 ( 1693318 ) on Thursday June 19, 2014 @11:22AM (#47272613)

    The best way to explain it, that I've found, is this:

    A server lets clients access a shared resource. On a file server, it's storage. On a web server, it's documents. On a compute server, it's processing. On an X server, the shared resource is the display, and clients are given access to it.

If you have a procedure with 10 parameters, you probably missed some.

Working...