Christopher B. Browne's Home Page
cbbrowne@acm.org

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

Claims to this effect are commonly made on Usenet.

Many proposals for alternative graphical systems have come and gone, as have companies that promoted alternatives. DRI's GEM, XEROX Star, GEOS, DesqView, NeXTStep, BellCore's MGR, Sun NeWS, MultiTOS, AmigaOS, Plan 9 rio ...

All of these systems have come, and despite niche usage, they are, for all intents and purposes, gone. Some are still being sold, but none are being actively marketed.

The jury is still out on QNX's Photon, NeXTStep, they have not yet clearly failed. (Note that NeXTStep has kind of become MacOS, and people are still actively working on GNUStep .)

The two other graphical systems that are actively marketed and sold are "Microsoft Windows" and Apple's MacOS. Both have some aspects of functionality that X lacks, primarily in terms of providing commonly used widget sets. Both lack the network transparency that is an X distinctive.

Some would propose using SVGAlib as an alternative; that library does not provide any GUI services, only low level drawing, which would typically require, for use in any "functionality-rich" applications, building up a similar set of infrastructure to that provided by X.

X is still with us, and I haven't yet seen an alternative that is likely to push out X.

Note

The tale of 2010 involves a new project, Wayland. While Ubuntu seems to be planning to adopt this as infrastructure for a subsequent release, it is not yet evident that it's really going to go.

Warning

Beware: Do not get ultra-critical in reading things into this section without also perusing the discussion of GNUStep as well as My Overall View of X.

This page is not notably "accepting" of criticisms towards X. Note that its point is not really to provide an overall view, nor should it be regarded as a blind apologia for X, but rather, it exists to deflect a series of wrongheaded criticisms. All too often, people who get hypercritical of X are not criticizing in a knowledgeable manner, but rather are blindly criticizing something they don't understand, haven't benchmarked, and blame X for sins that should be laid at others' feet. And at the end of the day, they present something which, to the extent it is interesting, doesn't address enough of the real problems to be much more than a curiosity.

My Overall View of X does reflect on some of the areas where X shows off some blemishes.

See also:

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:

and then there is a proposal to build this either atop the Linux " SVGAlib " infrastructure, or atop GGI.

There are three major problems with such proposals:

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.

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

Caution

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

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.

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

Note

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

Google

If this was useful, let others know by an Affero rating

Contact me at cbbrowne@acm.org