Should Xwindows Be Replaced
Should Xwindows Be ReplacedThis page is an attempt at ReFactoring XwindowProtocolShouldBeStabbedAndBurnt, which is a nasty ThreadMess. I've added some (hopefully) neutral content to glue this together; the rest of the content is from the original page. I've left the original page alone (other than a forwarding link) for now; though I suggest that it eventually be deleted. Assuming, of course, that the community likes this refactoring.
If people think I'm being too generous to X (I'm trying to be fair to both sides; but I will admit to being one of X's defenders), please feel free to further ReFactor.
-- ScottJohnson (DeleteWhenCooked)
It is frequently suggested that the XwindowSystem is unsuitable (in some fashion or another) for a modern graphics system (especially compared to the windowing systems in MicrosoftWindows and MacOsx), and that it's unsuitability is so inherent in X and it's architecture that the only reasonable solution for those computing platforms which use X (primarily LinuxOs and other Unix-like platforms, excluding MacOsx and legacy platforms like NeWs? and NextStep) is this: to BurnTheDiskpacks, abandon X altogether, and invent a new graphics protocol from the ground up. Many critics point to factors such as a) the low-level nature of Xlib and the XwindowProtocol; b) poor usability in X-based environments (even today, KDE and Gnome are frequently regarded as less usable than MacOsx or WindowsXp); c) complaints of poor performance (real or imagined); d) other (perceived or real) architectural flaws with X (such as MechanismNotPolicy, the asynchronous nature of the XwindowProtocol, or rendering tasks being performed by the client and not the server.
Others think that this viewpoint is incorrect; and that X has been subject to such criticisms for the 20 or so years it has existed -- and X has continued to evolve and keep pace with graphics systems on other platforms. Some allege that the majority of X critics are either a) technically uninformed about X, it's architecture, it's capabilities; b) basing their criticism on a bad experience with a particularly God-awful X-based environment (of which there have been many examples); or c) have an axe of some sort to grind, and/or base their criticism on a personal notion of architectural purity/goodness (rather than an ability, or lack thereof, to efficiently meet user requirements).
This page attempts to discuss both points of view. It should be noted that many defenders of X do not take the view that X is perfect, and/or cannot be improved. Instead, X defenders object to the claim that X is so fatally flawed that the only reasonable course is to scrap it -- it should be pointed out that X has been improved numerous times in its history, often in response to legitimate complaints from detractors and users alike.
Random flames of X (some taken out of context):
From HowToQuashMicrosoft:
SteveJobs is famous for saying "X Windows is brain-dead", way back when he was starting up NextStep, Inc. On MacOS X today, we've got a minimum of three GUI APIS - Carbon (based on Classic MacOS APIs), Cocoa (based on NextStep / OpenStep), and AWT/Swing (Java). How's GnuStep for Linux coming along?
Random flames of X critics
[Most of the "Let's replace X11!!!" projects that have cropped up over time begin by deciding to outright delete important features of X11, such as network support. -- DougMerritt]
"Let's replace X" rants seem to come from one of several quarters:
Technical criticisms of X, and responses
X is slow:
Complaints about X's performance usually revolve around the client/server interface - at a minimum, a context switch (even if through a fast IPC mechanism like a Unix-domain socket) is necessary for most operations. In contrast, Windows environments only require a privilege elevation (which can be performed much faster) to go from user to kernel space. This was a significant problem early on when X was run on less-capable hardware (such as early 1990's PCs running Linux), and remains an issue for 3D games. For most applications on modern hardware, it's simply a non-issue.
And the issue on games is (seemingly) addressed - the DirectRenderingInfrastructure? allows processes running on the same machine as the server to directly access the graphics hardware (providing a means to negotiate access to the hardware among multiple competing processes, including the X server itself).
Other performance-related criticisms (and responses) are:
X is often criticized for being "bloated" - meaning either it consumes too much memory when running, or that it encompasses too much code. X11 is certainly a big system that does a lot; in some cases it is being compared to a (hypothetical?) system that excludes features that the user in question doesn't desire. However, many criticisms on size grounds may not be poorly founded:
X is an architectural "kludge" (or otherwise inelegant):
X has been attacked by numerous critics on various architectural grounds. Among the reasons for criticism include:
This has been a longstanding bugbear of X, as anyone who has messed with an .Xresources file or an XFree86Config file can attest to. There still remain issues with both KDE and Gnome. However, the situation here is again much better; X has supported plug-and-play VGA monitors for years now, and KDE/Gnome provide much more user-friendly ways for users to configure their desktop. Still, X-based systems are often appear less "unified" than Windows or Mac platforms. Of course, many of these configuration issues have little to do with any fundamental limitation on X itself.
X is difficult to use:
X has been criticized on usability grounds for many reasons, among them:
Complaints about X's ugliness have been around for a long time. Among the culprits are:
It is claimed that "The X11 design breaks a very important principle: optimize for the most common case. 99% of the computers display graphics on the local machine." Certainly, most desktop machines in the home (and many desktops/laptops in the office) are such environments. However, others claim that X11 + DRI does optimize for the common case; and that the 99% figure above does understate the use (and importance) of remote displays.
X has poor hardware/driver support:
It is claimed that X11 is a "second class citizen" for graphics chipset manufacturers, with Windows being the #1 platform. Undoubtedly true today. However, most chipset manufacturers (including the major ones like Nvidia) do provide X drivers; the ones that refuse to do so (and refuse to publish specifications to enable a third-party driver to be written) are more often than not the "el cheapo" chipset manufacturers targeting sub-$500 PCs - low-performance hardware. Further, this has little to do with the merits of the X design itself; when X isn't supported it's for economic and not technical reasons.
Advantages of X over other platforms, and responses
X is cross-platform
X proponents tout this as a major advantage - indeed, X can run on all Unix flavors, MicrosoftWindows, VxWorks, GnuHurd, pre-OSX Macs, MacOsx (though this is Unix under the hood), and even on ancient hardware such as the CommodoreSixtyFour. Critics of X downplay this importance; the only platform that uses X that isn't a niche player is Unix/Linux, and X servers on other platforms are more often than not used to provide display services to Unix/Linux clients. In general, the primarily advantages are for developers rather than users (one cannot easily take a Linux x86 binary and run it on a Solaris/SPARC box, even if both us X).
Another thing that X undoubtedly does better than the competition - though many claim this doesn't matter much. Protocols for remoting of display/input hardware exist for other platforms; and proponents of these platforms claim that moving the network transparency outside the core is a more elegant design. Others argue that X's network transparency just works better - nothing special needs to be set up (beyond "setenv DISPLAY"), and that X has an advantage in being designed "from the ground up" for network transparency rather than having it bolted on via an RPC mechanism.
X is easily extended
Another claimed advantage of X is that it is easily extended - the XwindowProtocol provides a well-defined mechanism for supporting extensions (including client/server negotiation of their presence), and that the X user community provides well-defined mechanisms for publishing them and promoting their use (or disuse, for poorly-designed extensions). Many enhancements initially proposed as extensions have subsequently become part of X itself (such as DRI and Render). It is claimed by proponents that this extensibility fundamentally disproves a major argument behind the belief that XwindowProtocolShouldBeStabbedAndBurnt - that X is not extensible and thus unable to support graphical computing of increasing performance and sophistication. Opponents of X claim that the presence of extensions (and the need for an extension mechanism) is instead evidence of X's deficiencies - if it were any good, it wouldn't need extensions. Further, extension support can become a maintenance problem - what occurs when an X app requires an extension, but the server the user has access to doesn't provide it?
X is OpenSource (and a "bazaar" development model)
Both Windows and the Mac (the chief competitors for X which are mature products and have significant marketshare) are completely (or partially) closed-source solutions, whereas X11 is a fundamentally open-source model (though closed-source X implementations do exist; the most common implementation - XFree86 - is open source). Thus furthers the extensibility of X, as developers can propose new enhancements at all layers of the architecture. Others say that the open-source model results in a lack of conceptual integrity that one gets with control by a single entity or vendor; and that the soup has been spoiled by too many cooks.
What (if anything) should X be replaced with?
It is often proposed that a "new" windowing system be devised, to replace X. Some paper proposals have been put forth; some ambitious projects in that direction have been launched. Nothing has yet been delivered which is a suitable replacement for X in all areas where it excels; though some proposals may be superior to X in a constrained set of applications (usually single-user workstations where network transparency is not an issue). Many point out that X contains a tremendous amount of functionality; and that replacing it will require re-implementing the vast majority of that functionality - and that such a reimplementation would likely be as "bloated" or "slow" as X itself.
Some proposals for an X replacement claim "backwards compatibility" as a goal (whether at the Xlib layer or the protocol layer); others claim that this would goal would essentially require rewriting, rather than replacing, X.
Other proposals to replace X intentionally abandon areas of functionality that the advocates of the proposal deem unnecessary, superfluous, or too expensive to include. The usual capabilities that are suggested for removal include network transparency, cross-platform support, and various "legacy" graphics capabilities, such as non-scalable fonts, bitplanes, and other support for primivite graphics hardware.
Proposals to replace X include:
Further Discussion
EditText of this page
(last edited September 2, 2014)
or FindPage with title or text search