Slashdot Mirror
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?
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.
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.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
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.
I am sure that there are many other solipsists out there.
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...
*plays the Apogee theme song music*
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...
It's used every day, just not by you.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
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).
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.
I am TheRaven on Soylent News
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.