X Window System Turns 30 Years Old

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?

Comments

DECwindows ;)

[TheGratefulNet]

that's where I first saw X. at DEC we had DECwindows on ultrix (bsd like unix) and vax/vmx.

motif was the toolkit we developed guis in. and we used UIL to describe the UI, which was data that was read in and could change the look/feel of the widgets or their layout without rebuilding from source.

instead of node:1 for a display it was node::1 for the display (double colon meant decnet instead of that newfangled thing called IP)

Re:DECwindows ;)

[Archtech]

We spent an inordinate amount of time and effort explaining (often to people with considerable software experience) why "client" and "server" were the wrong way round.

Re:DECwindows ;)

[gman003]

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.

time to die...

[bumba2014]

30 years is long enough.... time for the ritual of "Carrousel"...

Re:time to die...

[fuzzyfuzzyfungus]

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

[Arker]

It's used every day, just not by you.

Re:time to die...

[BitZtream]

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

[TheRaven64]

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:time to die...

[TheRaven64]

The protocol is fine,

Except for the fact that it has a limited set of extensions that can be supported and a load of command numbers are used for 'core protocol' stuff that no one has used for over a decade. It has no concept of security (you can easily steal input from another application, for example).

the library isn't that horrible unless your a newbie to dev

XCB is pretty nice, but xlib is a clusterfuck. It hides interfaces that need to be used asynchronously for good performance behind synchronous API calls. It's impossible to write an application that performs well over a network and does a nontrivial amount of drawing with xlib. It is with XCB, but it requires carefully designing your toolkit for asynchronous drawing, and all modern X toolkits have too much xlib heritage to easily adapt to using XCB as it's intended to be used, rather than as a lighter-weight xlib.

Too old.

[Anonymous Coward]

30 is ancient in computer years, the X system is too old for the new generation of developers. I recommend we replace it with a far more superior one written in Javascript and Rails. With AGILE development methods we can have a better system up in a week.

1994-95

[wbr1]

Was in school, supposedly the first community college on the internet (ISDN to UVa across town) and we had NeXt workstations. I do not remember if they used X11, but that clued me into Unix. Later that year we wanted to get our gopher and mosaic servers on a better box, so I took an amazing 486DX2 and setup Slackware. There I know I saw X (although it was later removed from the server). IIRC I downloaded the entire set of Slackware discs directly to floppy using FTP from Sunsite the first time and NFS the second from UIUC (after searching hours for open NFS exports in the mirror lists). I did it directly to floppy as I did not have enough HDD space for the files and the currently running OS. I think that was Linux kernel 1.2.10. Am I old?

WABI

[just_another_sean]

First time I saw it was also on a Sun. Lowly kids like me (data entry clerk) had to use DOS on the job but the cool guys (engineers) had Sun workstations running WABI*. I was blown away by how much more advanced their stuff was than what we were stuck with. First time actually using it was when I finally managed to get Slackware installed along side Windows 95.

* Sun's Windows Application Binary Interface which allowed a full blown Windows 3.1 installation to run on their "desktop".

Sun Lab in '87

[Greyfox]

I saw it in a Sun lab at RPI in '87. It was running some clunky-ass version of CDE. Or maybe it was just plan CDE.

It's funny, I'm working on a project for which a lot of the components were coded back in the mid '90s. The state of the art really hasn't advanced since then. The basic API (Xlib/Motif/Xcb) are nominally well documented -- you can find books and the library calls have man pages. Newer libraries and X extensions are a hodge-podge of largely-undocumented and generally incompatible API calls that take more work to integrate than they do to program in (Assuming you can find an example to work from.) The actual frameworks typically require you to drink all their kool-aid in order to use the framework. So I could go GTK+ or QT, learn their idioms and framework implementation details and that's great assuming I never want to change frameworks again and am willing to accept their quirks. And outside of QT, everyone (including motif/xlib) re-invent C++ badly with home-rolled type systems which often involve pushing strings around. Brilliant.

Somehow despite all this it still does what it does better than anything else I've seen. I'm not sure how this is possible, but there you go.

time to die...

[Danzigism]

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

Grad school. 1990.

[140Mandak262Jamuna]

Sun diskless workstations. Knew motif window manager inside out. Had taught a unix course using a strange Sony workstation that had a TV card in it displaying live TV in X windows. Eventually became the root (of all evil, according to my students) of the lab.

Employer morphed from being a Unix shop (1990-2000) to Microsoft + Mainwin (2000-2010) shop, then slowly coming back to display agnostic (2011 - till date) (but limited to X11+OpenGL or MSWin) shop.

Paul Asente's Stanford masters project

[peter303]

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.

June, 1997

[tsqr]

On a re-purposed Win NT 4.0 box running OpenCaldera 1.0. That was when I first dipped my toes into the Linux pool, and I've been swimming happily ever since.

Network transparency of X has always impressed me

[Admiral_Bob2000]

I've been using Linux/UNIXes for 15yrs now. One of the beauties of X11 has been the fact that the application programmer typically does not even have to /plan/ for network transparency - it's built in right from the start (in the various graphics toolkits), no special APIs to .

This means that whenever the users have a need for displaying X11 apps remotely (e.g. needing to deploy new thin clients at short notice to accommodate new staff in a corporate environment - very quick setup time), you just simply set $DISPLAY and away you go. I've long come to count on this feature and I value having that option kept open all the time.

I believe in the future fibre optic LAN equipment will come down in price and will offer much lower-latency and higher-throughput than today's copper-wired Ethernet. It may even get to the point where transmit times of sending bitmapped real-time graphics over fibre may be as fast as a CPU writing to a reasonably modest PCI/AGP graphics card.

I think the Wayland project is making a SERIOUS mistake in treating network transparency as a second-class citizen, and will likely see the project relegated to a toy-like status (useful only for gaming and entertainment, or apps that need extremely low video latency like video editing suites) and shunned by the corporate world.

If the current X11 protocol makes it hard to do anti-aliased text, glossy/brushed GUIs, zooming fading menus, wobbly exploding windows and the like, then what we need is a new set of core drawing primitives, much like Apple's Display Quartz system (IIRC). Call it X12 if you will, but keep the network transparency in and that decision will pay off many times over.

I personally have no need for such resource-hogging eye-candy - I turn all of that off and prefer a minimalistic slick-but-functional snappy inteface. I am perfectly happy with X11, and all the current-version applications I use work well with it. It has its quirks and faults, but I believe they can be reasoned with and there is certainly room for improvement: http://www.x.org/wiki/Developm...

I also think the Wayland proposals of polling (pixel-scraping) window buffers and sending them over rdesktop for remoting is only going to lead to massive CPU overhead on shared application servers, for one thing.

At the very least, I'd like to see the major graphics toolkit groups (Qt, GTK, WxWindows et. al.) collaborate on designing a standard remote drawing protocol that has similar transparency to X11 - then I might have more respect for Wayland attempting to replace X11.

(sorry for double post - accidentally selected wrong formatting mode. Mod my other post into oblivion if you wish).