Weekly Edition
Return to the Front pageSponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||
|
| |||||||||||
The X Window System, past and future
The Jargon File defines X as
"An over-sized, over-featured, over-engineered and incredibly
over-complicated window system developed at MIT and widely used on Unix
systems." The Unix Hater's Handbook states: "X Windows
[sic] is the Iran-Contra of graphical user interfaces: a tragedy of
political compromises, entangled alliances, marketing hype, and just plain
greed." The "fortune" program shipped with most Linux
distributions contains six extended
diatribes against X, with delightful tidbits like:
"The trailing edge of software technology.",
"The greatest productivity aid since typhoid.",
"You'll envy the dead.",
and
"Making the world safe for competing window systems.".
And those are just from the first of six. The last dig quoted above
is interesting, though, when confronted with one little fact: there
are no competing window systems.
Most LWN readers will be aware by now of the current dispute over the direction of the XFree86 project. The next article will look at what is going on there, but, first, it's worth taking a moment to look at the absolute monopoly that X holds on Linux (and Unix) desktops. As free software projects go, X is one of the older ones. The first X release, built with support from the company then known as Digital Equipment Corporation, came out of MIT in 1984. By the time X10 was released, the window system was beginning to be widely used outside of MIT, but it was X11 (released on September 15, 1987 - you could order it on nine-track tape) that established X as the definitive Unix windowing environment. Several vendors, wanting to support the continued development of a vendor-neutral windowing system, formed the X Consortium to further support development in 1988. The Consortium eventually lost its relevance when the Unix vendors decided they wanted to start "differentiating" their window systems, and the XFree86 project became the real core of X11 development. That, of course, is how things stand today. X11 is certainly one of the longest-lasting major releases in software history; more than fifteen years later the X11 protocol maintains backward compatibility, and there has never been an X12 release. Since the early days, X has been the target of severe criticism. Attackers claim that it is over-engineered and bloated. Its absolute refusal to dictate policy (or even provide a standard window manager) has led to wildly incompatible interfaces on the same desktop. X requires applications to deal with too much information about the underlying hardware. The network-based client/server protocol is slow and has led to security problems. There is no way to load code into the server itself. The server doesn't even maintain window contents, forcing applications to deal with "expose" events. And so on. X, it is said, is "vacuumware," it sucks, but succeeded because there was nothing else out there. The above criticisms are, beyond doubt, not entirely lacking in merit. But the fact remains that X is the only viable windowing system for Unix-like systems. It pushed aside numerous proprietary systems (SunView was halfway out the door before Sun officially switched) and established itself as the standard across an amazing range of systems from different vendors. If X were truly that bad, a viable competitor would certainly have arisen in the 15 years since X11R1 was released. The few attempts (your editor once had the unfortunate experience of trying to program a project under NeWS) have sunk without a trace. Why has X been so successful? Here's a few possible reasons:
Of course, one should not forget the other important reason why X succeeded back in the 1980's: it was free software. So now X dominates the non-Windows desktop. Given the extent to which some people criticize X, one would assume there would be a whole set of development projects working to replace it. The fact that X works well and the existence of a large set of existing X applications present a daunting challenge to any potential replacement, however. Without a compelling reason to change (and rock-solid X compatibility), users are likely to remain with X for quite some time into the future. So it is not surprising that free software projects working on X replacements are not easy to find. There just isn't that much of an itch to scratch. One group that is trying, however, is the Fresco project (formerly known as "Berlin"). Fresco's approach differs from that of X in many ways: user interface policy will be wired into the window system itself; more advanced rendering will be supported by the server; the API will be based on vector operations and will be resolution-independent; CORBA will be used as the network transport; and the whole thing will be built with heavy use of threading in mind. Potential users will need to be patient; according to the web site, "Fresco is only useful for demos (really cool demos though :)". Fresco announced its second milestone release on March 4. Someday a project like Fresco may well succeed in displacing X from our desktops. Someday. Meanwhile, X will remain one of the crucial components of free operating systems like Linux. So the current disagreements over the direction of the XFree86 project are important. (Log in to post comments)
The X Window System, past and future Posted Mar 27, 2003 9:51 UTC (Thu) by paulsheer (guest, #3925) [Link] Each and every one of the criticisms about X is either completely unfounded, or applies to any other piece of software anyway. Myself I have been programming under XLib for many years.In the first place, X is not bloated. It is in fact the minimal piece of software for what it needs to do. Considering the range of types of raster devices out there, X conanicalizes their differences perfectly. Its protocol needs to be exactly as it is to facility interclient communication. One cannot think of a better way of coping with the problem of creating a hardware independent network transparent Windowing system. Try and see. Let us compare X to MFC (microsoft foundation classes). MFC is the most chaotic mess a developer could ever wake up screaaming to in the middle of the night. The capacity to transparently use other machines on the network has never been so successfully achieved as by The X Window System. It is an essential cornerstone of Unix computing in the world today. Most people who critisize X do so from a single home machine that is used mostly to play games. Such people want to strip the computing world of network transparency (to break their network card in half) just to get a few more FPS out of their first person shooter. Of course there are performance penalties resulting from network transparency. But you don't see them if you are doing productive things with a computer (i.e. not gaming). X is also extremely light on resources - consider that X runs on a 2 floppy Linux distribution. Really no one could ever critisize X for that.
The X Window System, past and future Posted Mar 27, 2003 22:20 UTC (Thu) by slamb (guest, #1070) [Link] Of course there are performance penalties resulting from network transparency.I think you're confusing two arguments here: (1) X is slow because it supports network transparency, which is unnecessary and (2) X's network protocol is inefficient. I agree with #2 but not #1. Its network protocol is slow because it talks at such a low level: draw these shapes here, the mouse moved, etc. Basic operations like moving the mouse and adjusting a scrollbar seem unusably slow over the Internet to me, and I have broadband. If the server did buttons, scroll bars, and other primitive widgets, this would not be a problem. Fresco does this. In other words, it moves much of the toolkit to the server side. Events only need to be sent from the server to the client if your code is interested in them, and it's not that often people register a mouse movement listener. That approach isn't perfect either, but you have to admit that it's dramatically more efficient. Like the difference between applications feeling unusable over the Internet to me and feeling responsive. Less time waiting for a response = more goodness.
The X Window System, past and future Posted Mar 28, 2003 0:23 UTC (Fri) by josh_stern (guest, #4868) [Link] Agree with slamb as far as it goes, but further analysis argues that the *real* problem with X is the social/organizational one of getting new extensions to become standard. The universal design of the protocol communicating primitives works great for its intended application - non graphics intensive applications in a LAN environment - in a programmer transparent way. But as you imply, extensions are needed for graphic intensive and internet use. In fact, a general purpose, suitable, substitute already exists: display lists with GLX. But usage is only possible for particular combinations of client libraries and X servers, which are still not common enough (and bug free enough) to make it a viable, general purpose, application programming strategy. So here is an example where we can see how a larger programming team (more horses for implementation) and a more aggressive approach to promoting change and new standards could help! So the current debate is key, *because* the issues are not fundamentally ones of technical design.
The X Window System, past and future Posted Mar 28, 2003 1:16 UTC (Fri) by iabervon (subscriber, #722) [Link] The X protocol used to be fast, because those drawing primitives were what people used to make the interfaces of the day. Now it's slow, because many modern interfaces need more complicated operations. But the operations they need still don't have to involve policy or determine how things look. X ought to have splines, (more) anti-aliasing, blending of lines, etc; essentially, the set of primitives in SVG. Then applications would be able to use the primitives that their interfaces are composed of and wouldn't have to resort to the messy use of the inadaquate primitives they currently use.
The X Window System, past and future Posted Mar 28, 2003 1:10 UTC (Fri) by iabervon (subscriber, #722) [Link] Of course there are performance penalties resulting from network transparency. But you don't see them if you are doing productive things with a computer (i.e. not gaming).Or if you connect to :0.0, which uses a UNIX socket, not the network. X is sufficiently clever to *not* be network transparent if there happens not to be a network.
The X Window System, past and future Posted Mar 29, 2003 17:36 UTC (Sat) by ptr (guest, #5885) [Link] I think that slightly misses the point. The criticism of efficiency applies to the protocol whichserializes display updates into a data stream. This protocol is used no matter whether a remote network connection or a local unix socket is used. This protocol is claimed to be inefficient, because the supported drawing primitives are too low-level (as mentioned earlier in this thread). Another fundamental question is, if there are better approaches for inter process communication than serialization which scale up better in the case that the applications run on the same system. Of course, also security issues are of concern...
The X Window System, past and future Posted Mar 27, 2003 10:48 UTC (Thu) by rwmj (subscriber, #5474) [Link] I feel like I'm in a minority here, but I like X. It works really well for me. On the rare occasions I use Windows I've never noticed that platform to be any faster. I love the network transparency (I use it daily for development, you'll take it from my cold lifeless hands). I can play games really fast. Since I ditched my old Voodoo 2 and got a real graphics card, 3D stuff just works & fast. I can run OpenOffice on my big server upstairs and view it on my Sun box downstairs. In the many many years I've been using it, I've only once found a graphics card which it didn't support - and all I had to do then was upgrade the server RPM. What's the problem?Rich.
The X Window System, past and future Posted Mar 27, 2003 11:42 UTC (Thu) by dmantione (guest, #4640) [Link] X is an excellent piece of engineering. For a desktop environment it does allthat's needed, efficient, and network transparent. Nothing beats it and I have seen nothing better. But there are a few situations where X is not the right choice. One of these are for example embedded situations, where you really want Window systems in as few K as possible. Another problem is that people use X for something it's not designed for: games. People, games should *not* run under X. Why? Because they need a framebuffer and other *low level* access to graphics hardware. X is a *high level* network transparent windowing system. Why are games written for X? Well, the only reason is that for every video card, there is an X driver. There is no other reason. On what interface should games run then? A low level one and the most suitable one is: FBDEV! But as of yet that's not possible; there's no 3D for example. I would be very nice to see more projects to give the Fbdev interface the drivers and tools it needs. Instead of bashing on X, people would better spend there time on this. Trying to adapt X to games is nonsense. Conflicting interrests. It doesn't work. But for a window system, it's the best there is.
The X Window System, past and future Posted Apr 3, 2003 14:21 UTC (Thu) by obi (guest, #5784) [Link] I agree with you.Trouble is, the Xfree86 developers feel only Xfree86 "deserves" their drivers. There have been numerous attempts to leverage the XAA drivers without X, but it seems it's usually easier to rewrite them. Same thing with DRI, it's theoretically possible to use DRI without X (see fbdri.sf.net for instance), but it's a very low priority for the DRI developers. I'd really like to see a system where the hardware layer is properly abstracted from the window and network layer. So that we'd be able to use the same drivers for graphic 2D/3D console programs, and X at the same time. That would allow other windowing environments to compete on a level playing field, and allow a lot of projects to bypass X completely when it's not needed (games come to mind, or something like blender). KGI/GGI/XGGI tried to do just that, but when KGI didn't manage to get into the kernel, they threw the baby out with the bathwater. Instead of improving GGI to make the interfaces more acceptable, alot of the interest in it waned, to the point it was comatose for quite a while. Recently, there's been activity (kgi-wip.sf.net) again, and I do hope that they'll make it eventually. (BTW: they also have a very nice input layer, GII) I think the beef with X isn't that it's so terribly bad, but that it's the only choice, and holds everyone hostage because it controls the video drivers (not by design, I'm sure - they just have no interest in anything else) If nothing else, I hope the fork, or the reorganisation or whatever, will bring more modularization in the code base. So other projects can atleast share drivers with it, and improve the drivers for all.
The client-server stuff Posted Mar 27, 2003 11:43 UTC (Thu) by eru (subscriber, #2753) [Link] I always find it sad when many people accuse the client-serverparadigm of being the resource hog (not this article, but it alludes to the belief), and propose cutting it out as a way to supposedly improve X. In the distant past, I have used X11 on Sun systems that would be considered pocket calculators (regarding CPU power) today, and also Sun's proprietary "monolithic" window system on the same boxes. No difference in responsiveness. Removing client-server features would eliminate many uses of X11.
X Windows alternatives on Unix Posted Mar 27, 2003 13:15 UTC (Thu) by subhasroy (guest, #325) [Link] I like X. Wrote 1000's lines of Xlib code a decade ago. As user,I am using it for 13 years. There are other possibilities on Unix however - Mac OS X does not use X Windows. I have no experience with it but read that it uses some sort of "Display PDF" instead. I don't know if it supports network transparency like X Windows. There are some things that are hard or cumbersome with X. Windows does not have application level network transparency
Disagree about no alternatives Posted Mar 27, 2003 15:36 UTC (Thu) by jlnance (guest, #4081) [Link] The article states that X has no competitors. I do not think that statement does justice to the situation. X11 is basically a communications protocol. You could make analogies to TCP/IP or HTTP. X11 may be the protocol that all Unix workstations use, but that does not mean they are all running the same software. There are different X Servers for Linux, and in that sense you do have a choice.
The X Window System, past and future Posted Mar 28, 2003 0:49 UTC (Fri) by Baylink (subscriber, #755) [Link] > user interface policy will be wired into the window system itself;And I won't like it, and then I'm screwed. :-( As far as performance and responsiveness, I find that X is actually *more* responsive on my Linux boxen than Windows is on it's, mostly because few things which ought not to block others, do.
The X Window System, past and future Posted Apr 3, 2003 14:27 UTC (Thu) by obi (guest, #5784) [Link] > > user interface policy will be wired into the window system itself;> And I won't like it, and then I'm screwed. :-( Not at all! One of the major advantages of Fresco is to centralize policy at the server side, but that doesn't mean you're stuck with one policy. You can switch the look and feel and behaviour at runtime, by plugging in different kits (widgetkit for instance). And _all_ your apps behave the same - consistency. Fresco is really trying to do everything the right way, to a fault. It's a project that deserves to be checked out, and understood. (one of the few examples where open source truly is innovating instead of copying.)
The X Window System, past and future Posted Mar 31, 2003 13:49 UTC (Mon) by stock (subscriber, #5849) [Link] Hehehe, the funny part is, that the real motivation for me totry Linux was that X11R5 came with it (SLS 1.03 distribution by Peter McDonald) . In those days (early 1993) getting an X11 environment for your UNIX(tm) was either impossible or costing you another mortgage on the house. Linux with SLS installed easily on your 386 and if you had a $ 35,- Tjenglabs ET4000 VGA card you were running your favorate OpenLook window environment out of the box after adjusting a single Modeline in your XFConfig file. Robert
What's bad about tiling window managers? Posted Apr 3, 2003 14:36 UTC (Thu) by kaig (guest, #7625) [Link] I know two of them, Ion and larswm, and I've used Ion for an extended period of time. I liked it. (What kept me away from larswm was that it didn't allow me to customize the key bindings to my liking. Hardly something that means that tiling is fundamentally bad.) I agree that Ion still needs some way to deal with applications that don't play ball with the tiling, but once that's added, what's wrong with it?
it's got to go (but we could keep toolkit compatibility for the transition, breaking very little...) Posted Nov 18, 2003 3:38 UTC (Tue) by meep (guest, #16938) [Link] I wouldn't say Fresco is the main one.Possibly the most promising Aimed at embedded only? Y: A Successor to the X Window System - not sure about that, but the pdf certainly analyses the problem and points out a lot more of what is wrong with X than above artcile. another what Linus had to say. (although old still valid) more I've experienced X for myself on older systems and I've got to say it's not a fun experience. Win is much faster. I think this is a very sad thing - the whole underlying OS is about efficiency and freedom, not being locked into paying for fast(er) hardware/software to keep up. Linux is proven in the server market and we're now seeing its huge potential in the embedded world. The only way to maintain sanity here would be a GUI flexible enough to suite either (just like Linux itself can scale to such extremes). We're currently seeing projects like www.directfb.org aimed for individual needs, and it's really fragmenting things, making stuff less flexible, less portable.. which is really what our OS is all about.
|
|||||||||||