''This 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: * " good start to helping Linux become a better user-oriented OS would be: Take X. Stab it repeatedly until it dies. Then burn it, and jump on the ashes. * ''Yes'' * '''''''You forgot to bury the ashes at a cross-roads. Unless you do that it'll come back.''''' * ''I've never seen anything fill up a vacuum and still suck...'' -- The X-Windows Disaster, Chapter 7 of TheUnixHatersHandbook: http://www.art.net/~hopkins/Don/unix-haters/x-windows/disaster.html From SteveJobs: 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: * People overly-concerned about "efficiency" (and thus opposed to network support), and who have little idea of just how minimal of an impact that is - especially on modern machines with modern graphics hardware. * People who object to the low-level nature of X (and the C implementation of xlib), and want to replace it with something "higher-level"; often something which will require use of some non-mainstream programming language of which they are an advocate. * People who are still upset about NeWs (or similar systems) losing out in the marketplace, and wish to rewrite history. * People who think that because X can (and was originally designed to) support low-level graphics hardware from the 80s and early 90s; that it must ''not'' be able to support modern hardware. * People who saw an ugly GUI on a Linux/UNIX box once (using Athena widgets or something else which is similarly godawful) and thus believe that X is inherently ugly. * People who have used X without a proper session manager/UI toolkit (e.g., Gnome or KDE), noted that their apps behaved differently, and think that X is inherently unusable. * People who dislike X because of it's UNIX heritage. ---- '''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: * Poor hardware support (see below). Some things aren't (or are probably not) the fault of X but are blamed on X because the contribute to overall UI sluggishness: * Poor linker technology (leading to slow application load times) * Poorly tuned operating systems * Poorly written applications or application frameworks ''X is bloated'': 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: * Tools such as "top" include in memory reports things such as the frame buffer and other graphics chipset memory (for the X server, at least). * One might experience "sticker shock" looking at the size of the X codebase, or the X-related binaries. It should be noted that an "apples to apples" comparison with platforms of comparable ability (the Windows and Apple graphics stacks) is difficult. ''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: * Unix heritage * Specification of Xlib in CeeLanguage; it is claimed that C is too low-level for a modern graphics system. (Others point out that a) nobody uses Xlib directly but graphics library authors, and b) many other language bindings are available). * Client/server architecture and network transparency. This is often criticized on performance grounds (see above). Others feel that this is a fundamental X requirement, and that the DirectRenderingInfrastructure (a recent addition to X) essentially solves the problem for the class of applications (mainly high-performance games) where the client/server interface remains a bottleneck. * Rendering of complex widgets has traditionally been done on the client (the machine running the app) rather than the server (the machine the display and input devices are attached to - increasing network usage (in a distributed environment). Modern extensions to X have allowed more and more rendering onto the server. * Some necessary part of a complete graphics programming "stack" are missing. Among the (alleged) missing pieces include 3d rendering libraries (though OpenGl is essentially integrated with X), a "physics engine", video/audio codecs, high-level application frameworks, advanced GUI toolkits, etc. Others feel that many of these criticisms are either incorrect (i.e. lack of 3D), shouldn't be part of X due to MechanismNotPolicy, or are altogether orthogonal. * Asynchronous nature of the XwindowProtocol; it is claimed that this makes error handling difficult and makes the programmer's life harder. Others feel that this is required for efficient performance on slow or high-latency networks, and that a good app framework will solve these problems. * X is a "mess". It is often claimed that X contains kludge upon kludge upon kludge. Others respond that such claims are unspecific and unfalsifiable - little more than "flamebait" that need not be answered. * X has "evolved" rather than being "designed" - some claim that a clean, "holistic" design is superior to one that evolves over time. Others claim that this is a longstanding fallacy which has long plagued ComputerScience, and that evolution is a legitimate (and preferred) design methodology, as opposed to haphazard happenstance. ''X is difficult to configure'': 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: * MechanismNotPolicy. The designers of X made a decision to not dictate GUI ''policy'' - there is no official guideline on what the left button vs the right button should do, for instance. Many feel this was a disaster (at least initially) - policy decisions were delegated to application programmers, resulting in an inconsistent system were every app behaved differently (and none behaved particularly well, as the app programmers were not skilled at UI design). However, with the advent of desktop environments such as KDE and Gnome (which ''do'' provide policy, (and allow user customization to some extent), this problem has disappeared somewhat. Others feel that allowing users (as opposed to application programmers) maximum flexibility in configuring their personal environments is a good thing. * X apps (old ones especially) tended to make gratuitous assumptions about screen resolution, color maps, etc. * It is claimed that X is (allegedly) designed for technical users (see comments on configuration above), whereas Windows and Mac were designed for "mortals". Others claim that this (even if true) has little to do with the technical underpinnings of X. ''X is (visually) ugly'': Complaints about X's ugliness have been around for a long time. Among the culprits are: * Poor font handling (originally). X11 predates font anti-aliasing, and was designed contemporaneously with scalable font technology. Neither were in X for quite a while; X users had to live with bitmapped fonts and no anti-aliasing for quite some time. Today, of course, that is no longer the case - X can do TrueType and anti-aliasing with no difficulty. One other issue with X for a while was font quality - MicroSoft and AppleComputer paid font foundries megabucks to design professional fonts for their systems; for a long time X fonts were often amateurish in comparison. However, the fonts provided with most Linux distributions are comparable to those found in Windows nowadays. (Plus, it should be noted, font quality is not a technical issue with X itself anyway). * Primitive early widget kits. The Athena widgets were unrivalled in their sheer ugliness (as well as having the most braindead scrollbar known to man). Fortunately, this hasn't been a major issue with X systems for at least 10 years. * MechanismNotPolicy again. In addition to producing apps which ''worked'' different, it resulted in apps that ''looked'' different (and were individually ugly anyway). The advent of modern desktop environments makes this a non-issue with modern X systems (though lots of legacy X apps are still around). ''X is architected/optimized for the "uncommon" case'': 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). * No, not on the CommodoreSixtyFour, which had a max of 64K RAM; that would have been impossible (aside perhaps from a toy/rigged demo). You're probably thinking of the Amiga. Dale Luck ported X11r4 to the Amiga 1000 (the first generation Amiga), a tour de force by today's standards, considering it was only a 2meg RAM machine. ''X is network transparent'' 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: * SmalltalkExtensibleWindowServer -- essentially NeWs plus SmalltalkLanguage (proposal only) * TheBerlinProject / FrescoFramework (somewhat implemented; nowhere near functional) * WayLand * MirProject Interestingly enough; platforms such as the JavaPlatform or DotNet might be a "threat" to X - not that these are a direct replacement for X (they are not), but that if applications target ''these'' platforms, the underlying layers in the software stack (such as X and it's competition) become less relevant. Of course, Java and .NET remain highly unsuitable for many high-performance applications. ---- '''Further Discussion''' * GoalsOfXwindowsDiscussion ---- CategoryXwindow CategoryDiscussion