[Posted March 25, 2003 by corbet]
The Jargon File defines X as "An over-sized, over-featured, over-engineered and incrediblyover-complicated window system developed at MIT and widely used on Unixsystems.
" The Unix Hater's Handbook states: "X Windows[sic] is the Iran-Contra of graphical user interfaces: a tragedy ofpolitical compromises, entangled alliances, marketing hype, and just plaingreed.
" The "fortune" program shipped with most Linuxdistributions contains six extendeddiatribes 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 aboveis interesting, though, when confronted with one little fact: thereare no competing window systems.
Most LWN readers will be aware by now of the current dispute over thedirection of the XFree86 project. The next article will look at what isgoing on there, but, first, it's worth taking a moment to look at theabsolute monopoly that X holds on Linux (and Unix) desktops.
As free software projects go, X is one of the older ones. The first Xrelease, built with support from the company then known as DigitalEquipment Corporation, came out of MIT in 1984. By the time X10 wasreleased, the window system was beginning to be widely used outside of MIT, but it was X11 (releasedon September15, 1987 - you could order it on nine-track tape) thatestablished X as the definitive Unix windowing environment. Severalvendors, wanting to support the continued development of a vendor-neutralwindowing system, formed the X Consortium to further support development in1988. The Consortium eventually lost its relevance when the Unix vendorsdecided they wanted to start "differentiating" their window systems, andthe XFree86 project became the real core of X11 development. That, ofcourse, is how things stand today.
X11 is certainly one of the longest-lasting major releases in softwarehistory; more than fifteen years later the X11 protocol maintains backwardcompatibility, and there has never been an X12 release.
Since the early days, X has been the target of severe criticism. Attackersclaim that it is over-engineered and bloated. Its absolute refusal todictate policy (or even provide a standard window manager) has led towildly incompatible interfaces on the same desktop. X requiresapplications to deal with too much information about the underlyinghardware. The network-based client/server protocol is slow and has led tosecurity problems. There is no way to load code into the server itself.The server doesn't even maintain window contents, forcing applications todeal with "expose" events. And so on. X, it is said, is "vacuumware," itsucks, but succeeded because there was nothing else out there.
The above criticisms are, beyond doubt, not entirely lacking in merit. Butthe fact remains that X is the only viable windowing system forUnix-like systems. It pushed aside numerous proprietary systems (SunViewwas halfway out the door before Sun officially switched) and establisheditself as the standard across an amazing range of systems fromdifferent vendors. If X were truly that bad, a viable competitor wouldcertainly have arisen in the 15 years since X11R1 was released. The fewattempts (your editor once had the unfortunate experience of trying toprogram a project under NeWS) have sunk without a trace.
Why has X been so successful? Here's a few possible reasons:
- X actually does pretty well at hiding hardware details for many applications. But the ability (and, occasionally, requirement) to deal with the hardware allowed the writing of applications that behaved optimally on a wide range of systems.
- The X client/server protocol was unique; it enabled the separation of applications from the desktop where their interfaces were displayed. If you were a system admin who suddenly could easily monitor several servers on one screen, or a scientific user who could run supercomputer visualizations from your desktop, this was a big deal.
- The refusal to set policy allowed a great deal of experimentation in user interface policies. Lots of bad ideas (i.e. tiling window managers, Motif) were tried and discarded without having been wired into the window system itself. Even now, X provides a platform where competing visions of the desktop can be implemented and tried out.
- The built-in extensibility of the X11 protocol has allowed it to evolve over time without breaking compatibility with older applications.
- It works, and has for a long time.
Of course, one should not forget the other important reason why X succeededback in the 1980's: it was free software.
So now X dominates the non-Windows desktop. Given the extent to which somepeople criticize X, one would assume there would be a whole set ofdevelopment projects working to replace it. The fact that X works welland the existence of a large set of existing Xapplications present a daunting challenge to any potential replacement,however. Without a compelling reason to change (and rock-solid Xcompatibility), users are likely to remain with X for quite some time intothe future. So it is not surprising that free software projects working onX replacements are not easy to find. There just isn't that much of an itchto scratch.
One group that is trying, however, is the Fresco project(formerly known as "Berlin"). Fresco's approach differs from that of X in manyways: user interface policy will be wired into the window system itself;more advanced rendering will be supported by the server; the API will bebased on vector operations and will be resolution-independent; CORBA willbe used as the network transport; and the whole thing will be built withheavy 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 secondmilestone release on March4.
Someday a project like Fresco may well succeed in displacing X from ourdesktops. Someday. Meanwhile, X will remain one of the crucial componentsof free operating systems like Linux. So the current disagreements overthe direction of the XFree86 project are important.
(Log in to post comments)
Posted Mar 27, 2003 9:51 UTC (Thu) by paulsheer (guest, #3925) [Link] (5 responses) In the first place, X is not bloated. It is in fact theminimal piece of software for what it needs to do. Consideringthe range of types of raster devices out there, X conanicalizestheir differences perfectly. Its protocol needs to be exactlyas it is to facility interclient communication. One cannot think of a better way of coping with the problemof creating a hardware independent network transparent Windowingsystem. Try and see.
Each and every one of the criticisms about X is either completelyunfounded, or applies to any other piece of software anyway. MyselfI have been programming under XLib for many years.The X Window System, past and future
Let us compare X to MFC (microsoft foundation classes). MFCis the most chaotic mess a developer could ever wake up screaamingto in the middle of the night.
The capacity to transparently use other machines on the networkhas never been so successfully achieved as by The X Window System.It is an essential cornerstone of Unix computing in the worldtoday. Most people who critisize X do so from a single homemachine that is used mostly to play games.
Such people want to strip the computing world of networktransparency (to break their network card in half) just to geta few more FPS out of their first person shooter.
Of course there are performance penalties resulting fromnetwork transparency. But you don't see them if you aredoing productive things with a computer (i.e. not gaming).
X is also extremely light on resources - considerthat X runs on a 2 floppy Linux distribution. Really noone could ever critisize X for that.
Posted Mar 27, 2003 22:20 UTC (Thu) by slamb (guest, #1070) [Link] (2 responses) 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. Posted Mar 28, 2003 0:23 UTC (Fri) by josh_stern (guest, #4868) [Link] Posted Mar 28, 2003 1:16 UTC (Fri) by iabervon (subscriber, #722) [Link] Posted Mar 28, 2003 1:10 UTC (Fri) by iabervon (subscriber, #722) [Link] (1 responses) 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. Posted Mar 29, 2003 17:36 UTC (Sat) by ptr (guest, #5885) [Link] Another fundamental question is, if there are better approaches for inter process
Of course there are performance penalties resulting from network transparency.The X Window System, past and future
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
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
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).The X Window System, past and future
I think that slightly misses the point. The criticism of efficiency applies to the protocol which The X Window System, past and future
serializes 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).
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] (1 responses)
X is an excellent piece of engineering. For a desktop environment it does all that'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.
Posted Apr 3, 2003 14:21 UTC (Thu) by obi (guest, #5784) [Link] 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.
I agree with you.The X Window System, past and future
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.
I can tell that in the large company I work in, there would be almost
NO usage of X11 apps, if it could not be used remotely. You guessed it:
most desktops are Windows-based, and the commonest way to use graphical
Unix or Linux applications is logging in via X11 emulator running on
Windows. Also note that the requirement for remote GUI use in enterprises is
so strong that it actually forced Microsoft to re-invent the feature in
Windows terminal services.
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.
Font configuration is one.
Windows does not have application level network transparency
like X. But Windows's remote desktop connection does work
nicely.
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 (guest, #755) [Link] (1 responses)
> 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.
Posted Apr 3, 2003 14:27 UTC (Thu) by obi (guest, #5784) [Link] > 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.)
> > user interface policy will be wired into the window system itself;The X Window System, past and future
The X Window System, past and future
Posted Mar 31, 2003 13:49 UTC (Mon) by stock (guest, #5849) [Link]
Hehehe, the funny part is, that the real motivation for me to try 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
http://picogui.org
Aimed at embedded only?
http://www.microwindows.org
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.
http://www.doc.ic.ac.uk/~mbt99/Y/
another
http://www.tutok.sk/fastgl/
what Linus had to say. (although old still valid)
http://www.ggi-project.org/mailinglist/may99/320.html
more
http://lists.canonical.org/pipermail/kragen-discuss/2000-March/000552.html
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.
To put a slow GUI on top of this (and the GUI *is* the OS for many people; after all, it's the final layer between them and computer) is like throwing that all away.
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.
A standard and scalable GUI could also help out the desktop world which is moving very slowly due to reasons outlined in the "Y window system" PDF.
![The X Window System, past and future [LWN.net] (2024)](data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAQAAAC1HAwCAAAAC0lEQVR42mP8/h8AAvMB+NzmkbcAAAAASUVORK5CYII=)