16. On the Thesis that X is Big/Bloated/Obsolete and Should Be Replaced

16.1. The New Linux Windowing System

Every once in a while, someone decides that X is not appropriate for their needs, and that they need to create some sort of windowing system that runs atop SVGAlib .

The purported problem is that X is too "bloated," combined with some criticism about:

• A lack of good "widgets"

• A lack of a "good GUI"

There are three major problems with such proposals:

• The "good widgets" and "good GUI" will never get widely enough deployed. People will not agree on a common set.

• By the time the code gets implemented, the memory footprint is not likely to be that much less than that of X.

• Systems implemented atop SVGAlib only work as console-based Linux applications on the IA-32 architecture. Which means that network transparency just went away...

There are people that don't care about portability or system flexibility. I will simply be unkind and say:

" I don't care to help support people that don't care about portability. "

In five years, it is entirely possible that IA-32 chips will be tough to find. Being portable to IA-32 and IA-64 and some combination of Alpha, MIPS, ARM, and PPC are likely to be crucial. X provides that and will continue to do so. SVGAlib doesn't; GGI may or may not.

• NanoGUI Tiny alternative to X for little devices

• Greg Haerr's MicroWindows Page

• Crust

  The display system for Nova.

• Montage

  A windowing system where the server was implemented as an interactive Scheme compiler where applications are implemented in a client/server fashion, where there is a "server portion" running in the server, and a "client portion" in a separate set of processes.

• [ D11: a high-performance, protocol-optional, transport-optional window system with X11 compatibility and semantics (from SGI) ]

  This may be the most "competent" of the analyses; SGI has designed a system called D11 that may provide substantially better performance for display of widgets on local workstations than does X11.

16.2. Wayland

Wayland is the latest (2010) would-be-alternative to X. It wants to take some of the context switches out of compositing.

At present, it seems to mainly run atop X, and efforts to have clients that can talk to Wayland without essentially being X clients are only at a nascent stage.

16.3. Berlin: A Case Study

The Berlin Project is now officially "dead," as the original participants in the project are gone, and the focus has substantially shifted from being an "all-sing-all-dancing super-fast IA-32 assembly language hack solely for Linux to being a graphical framework design based on the old Fresco library, and, as of 2002, being renamed as Fresco . As a result, the criticisms in this section do not apply to Fresco as it exists today. The analysis, nonetheless, continues to be relevant, as people keep coming along that make rash claims about X11 and about their pet would-be-replacement project. Happily, since Fresco is no longer called Berlin, they don't need to get irritated about this analysis anymore!

Proponents of the Berlin graphics environment have claimed at various times that "X is dead" and that Berlin is its replacement-to-be.

The primary complaints are that X is slow, and it is a moribund technology. Neither assertion is conclusively borne out by facts, particularly when compared to the speculative assertion that Berlin represents a useful solution to the problems that exist with X. (And I cannot totally disagree; X indeed has some flaws. )

The other most often claimed shortcoming of X is that it is a "memory pig;" I claim that this is substantially a fallacy, and that any reasonable alternative will not consume significantly less memory.

The following discussion is not really directed towards comparing X to Berlin; it can be readily applied to any reasonably similar competing technology, which I will call "GNotX."

• Speed, Speed, Speed.

  The primary argument put forth against X is that it is slow.

  X was in the past noted for being slow. The primary causes have generally been a lack of memory, slow video hardware, and inefficient use of such hardware. These things have been greatly alleviated of late by improvements in display hardware, improved availability of cheap RAM, and improved use of hardware acceleration by X servers.

  With only 8MB of RAM, an X11R5 server, and an old Cirrus Logic 512K video board, running Netscape Navigator on my PC in 1993 was an unwise proposition. Each of these components were significant bottlenecks to system performance. In 1997, with 32MB of RAM (worth about $75), an S3V PCI card with 4MB of RAM (Cost: about $60), and the hefty acceleration provided by the latest rendering features in X11R6.3, Netscape scrolls thru large HTML documents far faster than I can possibly control it. In 2002, with 640MB of RAM, an GeForce2 graphics card with 32MB of RAM, and XFree86 4.0, even the "bloated" recent releases of Mozilla work out reasonably well. The spectacular increases in the power of the hardware make what was bloated and slow in the 1980s quite workable in the 21st century.

  It is only reasonable to expect significantly improved performance of "GNotX" over X in situations where either:

  • X consumes more memory than "GNotX," thus causing swapping or

  • "GNotX" uses "better algorithms," beating X, or

  • X's protocols represent a performance bottleneck compared to "GNotX."

  Looking at these in detail:

  • There is insufficient memory to run X, but sufficient for "GNotX."

    Overall, this seems rather unlikely, as the "memory footprint" that can be attributed to X being "bloated" does not appear that significant.

    My X "sessions" typically consume on the order of 10MB of RAM. Of this, the vast majority represents screen data.

    With 1024x768x16 bits with 4 virtual screens, the amount of screen data that needs to be held within system memory is approximately 6.2MB. With any use of backing store, fonts, or other forms of caches or buffers, that can readily bump up the data requirements by 1MB.

    At maximum, that leaves the potential of 4MB of "bloat" that could be saved. Which would require that "GNotX" consume no memory. A more realistic estimate would be that X contains on the order of 1MB of "bloat."

    From the memory perspective, GNotX could "buy" you an effective savings that is worth $3. I hardly think that this is worth the programming effort.

    Furthermore, the amount of memory being deployed on graphics cards has been increasing with astounding leaps and bounds. At the time of this modification (November 1998), some "state of the art" graphics cards seem to have as much as 64MB of RAM just on the graphics card. The amount of memory resources now being thrown at graphic devices is simply astounding. A few megabytes of "bloat" in an X server disappear in comparison.

    The following report was recently seen on Usenet, from Jim Gettys, one of the original designers of X, and is quite pertinent.

    	A bit of data: Keith Packard and I recently ported X to the Itsy... I put the X server (3 fonts built in), xterm, xmh, a bunch of the random little X utilities (xdpyinfo, etc.), Xt, Xlib, various other of the "standard"> shared X libraries, and it was 1.3 megabytes compressed (2-3 times this size uncompressed). The only significant difference from a "standard"> X11R6 server was new frame buffer code Keith has written that cuts the code size of the X server down by about .5 megabytes. While running, the server was reporting its size was a couple of megabytes. I don't have an Itsy handy this moment to get exact data; this is from memory. There are certainly some very bloated X toolkits out there; there are also some reasonably small ones. For most servers, backing store and save unders rapidly dominate memory usage: with 32 bit deep displays, a screen full of memory is 4 megabytes. It doesn't take all that many apps, particularly with some fragmentatation of the memory pool in the server, to cause the virtual address space of an X server to get large. So backing store and save unders dominate memory usage on most displays people use today (and/or any pixmaps the clients save at the server); the X server itself is hardly "bloated", though there is code around I question the need for from time to time... Note that this is the nature of the beast; some other window system that also implements backing store and save unders would use similar amounts of memory for this purpose. On itsy, of course, the display size is 320x200x4bits, so even backing store doesn't take much memory (about 1/100'th of the memory that a current 32 bit frame buffer would take). But this is virtual space; so long as you aren't actively paging, what matters is that the working set be in memory. If you are memory starved on a system, you might see if your X server supports disabling backing store and/or saveunders; this might save LOTS of memory (some servers these days just always do backing store and save unders).
    --Jim Gettys

  • The "GNotX" algorithms are better than those used by the X server.

    This would set up the "straw man" argument that GNotX uses fundamentally better algorithms, and that X servers cannot be improved upon to use similar techniques or algorithms. Which is unlikely.

    It will be very interesting to see what changes result when the modularized XFree86 "Version 4" is released.

  • The last possibility are that X protocols are the bottleneck for performance, and that GNotX solves this problem.

    We must here be talking about those cases where programs are specifically bound by the "atrocious" bad speed of the X protocols, and moreover, due to the weakness of arguments for the other plausible causes of substantial GNotX superiority over X, I would argue that this has got to be the true crux of the argument for an alternative system.

    I would note that for someone who wants to run applications across a network or across different system architectures that may not be restricted to Linux, this is all pretty irrelevant; no system has been announced that would provide graphical support for any substantial number of different systems. X is platform independent, which is a crucial property.

    Moreover, as we are talking about applications where the X protocol is the bottleneck, it should be noted that this is likely to only affect a somewhat special class of programs.

    • Many interactive applications are mostly bottlenecked by the user's ability to read and respond. If the system is waiting for you to respond, you're obviously not waiting on X.

    • Netscape may pump out a lot of X updates, but the bottleneck that affects the user is normally the speed of the connection across the Internet, and not the X protocols.

    • Speed is often bound by the efficiency of the application itself, which only a truly magical graphical infrastructure can help. A program like Xaos (a fractal renderer) pumps out a lot of X updates, but the bottleneck is most definitely the CPU, and not X.

    The case where the X protocol will be a bottleneck is that specific case where an application is continually updating the screen, and where computing what is to be displayed takes less time than it does to communicate to the server what is to be displayed.

    The only major class of applications where this is liable to be a common and significant bottleneck is that of games and animation.

    Moreover, it should be noted that X is no slouch in this area; more recent versions of the X protocol (e.g. X11R6.3) provide more and more functionality oriented towards animation, and the use of the MIT SH-MEM facility, when available, can improve performance substantially.

• X Obsolescence

  There is validity to the notion that X is pretty "long in the tooth." It does contain "hacks upon hacks" that that it would be nice to clean up.

  Some serious efforts are under way in this regard.

• X does not coexist well with other graphical systems under Linux.

  There are some technical problems with making SVGAlib and X coexist that relate to console management; this is at least as much the fault of the other applications as it is of X.

• X doesn't enforce GUI policy on programmers or users, and GNotX will.

  There is much disagreement on this.

  The fact is that X is not a GUI. X is a graphics system on which one can construct a variety of GUIs. The problem lies in the fact that many have done so, creating somewhat incompatible systems.

  	From a user perspective, where the apps have the attributes of being unique (one of a kind) and instances of different GUI systems, (the lack of ability to share state between different GUIs for things like Drag'n'Drop) is indeed a disadvantage. But not a disadvantage of X. It is one of the disadvantages of having multiple GUI systems to choose from.
  -- <jstevens@verinet.com> John Stevens

  There has been an unfortunate continuing proliferation of GUIs that run on X, with relatively few cases where GUIs have been consolidated. The split between those that like GTk and those that like Qt is the most recent case in point.

• There are serious problems with X that GNotX will solve.

  The Unix Haters book describes some legitimate problems with X on a page entitled The Disaster of the X Window System

  • X has not traditionally provided a way for code to be run on the X server when appropriate. (As was the case with Sun's NeWS system that allowed applications to transfer over Display Postscript code to be run on the display server.)

    X11R6 "Broadway" now does provide a way to do this. Unfortunately this doesn't help with the (still common) XTerminals still running earlier versions of the X protocol.

    Moreover, I don't believe that Broadway provides any platform independent form in which the code can be represented. Rather, remote binaries must be generated individually for each kind of X server. This means that you'll need to be managing "server uploads" for all sorts of X server architectures, which will get very ugly to manage.

    Furthermore, XTerminals (particularly older ones) may not have the memory or software resources to host anything terribly sophisticated.

  • X doesn't provide support for "fancy" font manipulations such as antialiasing. Thus text can often look rather "blocky" under X.

    As of 2001, this is starting to change. XRender offers a mechanism to support antialiasing, and GTK and Qt libraries are implementing hooks to allow this to be used in applications. The enhancements don't affect legacy applications that use other libraries, but you can't have everything.

  • Authority checking (xauth) in order to allow/disallow remote access to the X server as appropriate seems unnecessarily arcane and difficult to configure.

    I'm not generally considered a "dummy," but I have found it severely troublesome figuring out how to get xauth functionality working correctly within my little Cyrix/Alpha subnet at home so as to get full functionality out of EXMH. A less sophisticated user ("Linux for Dummies") won't have a prayer of getting it right.

    In 2004, OpenSSH provides an alternative answer that seems to work fairly well; it will, if you throw in the -X option, establish an encrypted tunnel over which X requests can pass securely, without any need to fight with xauth.

16.4. Why New GUI Systems Are Not Likely to Succeed

The following evaluation uses Berlin as an example of a new GUI system that is unlikely to be successful at attracting substantial interest beyond a "niche" community. I would argue that the analysis is reasonably characteristic of would-be replacements for X.

The use of a system such as Berlin for anything useful is dependent on the availability of a number of critical system facilities. Unfortunately, the usefulness of Berlin depends on all of them being in place. And the action of developing Berlin and related applications requires that a significant portion of them already be in place.

• GGI

  For Berlin to become generally useful requires general availability of GGI. Unfortunately, as of the end of 1997, GGI still only supported a few graphics cards, only works with Linux IA-32, (with some support on Digital Unix and SGI/IRIX) and, most critically, isn't in the "experimental" kernel family (2.1.*).

  If all went very well for GGI, it is not clear that it would be able to be in the experimental kernels in 1998. If GGI had made it into the experimental Linux kernel tree, which is entirely uncertain at this time, I wouldn't have expected to see it in "stable" kernel releases until mid-1999.

  This leaves Berlin without a particularly stable platform on which to run. (Although there's the possibility of libggi running atop X, which may be reasonable...)

• Berlin's own "core" code

  Berlin is obviously dependent on completion of its own code. I wouldn't expect to see it being particularly stable before late 1999 at the very earliest. It can't get stable before GGI does.

• Berlin applications

  Having an beautiful desktop that has no applications is rather useless to the end user.

  Since Berlin does not interoperate with existing X applications, Berlin is critically dependent on people creating a body of Berlin-based applications that can replace the body of works that already function under The X Window System.

  If Berlin offered some way of crosshosting applications atop some other environment (say, on top of X) this would permit developers to work on Berlin applications even before a "full" Berlin environment is ready. Barring that, substantial porting efforts would be unlikely to start before late 1999.

• A wide base of support

  Even if all of the above things were in place, if Berlin existed and worked well, this would only be helpful to a limited degree, because it will be very difficult for it to attain a high degree of support unless it runs atop X.

  In order to get a wide base of support for a system like Berlin, you need:

  • For Berlin to run on existing and future X-Terminals

  • For Berlin to be compatible with existing X applications

  • For Berlin to interoperate on a wide range of platforms.

In short, I would argue that Berlin cannot be successful unless it builds upon an infrastructure that can interoperate with X.

By the time Berlin gets to the degree of functionality at which it might reasonably be presented as "a good Linux GUI," X and other related graphical infrastructures are likely to have progressed sufficiently as to provide sufficient performance for 90 of the people, 90 of the time. There is no evidence available that the use of Berlin would result in substantially reduced resource consumption; only that it ought to be a "really nice graphical environment."

In retrospect, the analysis seems to have been reasonably accurate. The Berlin project team, as originally constituted, has lost interest. A new crew has moved it to become more like the earlier library Fresco , and in fact have renamed the project Fresco. GGI has progressed, somewhat slowly; it seems to be more commonly run as a layer on top of X than on its own. "Replacements for X" these are not. Far more encouraging is that in 2002, there are substantial new design efforts going into XFree86 and on into X11, notably the XRender facility. In effect, some of the followup design work that they had hoped would take place is in fact taking place. It is unfortunate that we had to suffer through a decade of balkanization and Motif in order to get here, but some systematic improvements do seem to be emerging. Better late than never...