X11 Window System Turns 25 Years Old
linux.slashdot.org
linux.slashdot.org
They said that the separation of mechanism and policy would make inevitable any number of advances in user interfaces that were not possible under closed source models. Look at what actually happened. The overwhelming majority of Linux window systems and desktop environments were Windows 95 work-alikes, NeXTstep work-alikes, or attempts at minimalism based on BlackBox or aewm. Enlightenment was the only major exception, but it went by the wayside due to Rasterman's falling out with RedHat and by that project's attempt to build resources that were not but should have been included in X-Windows.
In the meantime, Microsoft kept improving Windows until, with XP, they had an operating system that even many Slashdotters were forced to admit was usable and productive. In the meantime, Apple went to the brink of ruin and bounced back to usability preeminence using Unix code, but violating -- nay, extravagantly violating -- the Unix philosophy when it comes to user interfaces.
"The year of Linux on the desktop" has long since become a bad joke even among the Slashdot set precisely because they held to their principles. Because they held to their false principles. If one wants to have a good user interface, then mechanism should not always be separated from policy. Configurability should not be paramount. An authority must be in charge to enforce interface consistency, if only imperfectly.
Apple Computer is the existence proof. If the X-Windows partisans were right, then Steve Jobs pulled off the impossible.
Separating out the mechanism and policy allowed massive exploration in this space, so you have everything from wm2 to GNOME 3 to xmonad to Enlightenment. Just because you haven't heard of them or used them doesn't mean they aren't appreciated.
> Configurability should not be paramount.
The lack of configuration does not offer anything to the end user. It's a good business strategy to lower costs whilst still guaranteeing a bug/quirk free product. It is however not a plus. Less is not more.
>Apple Computer is the existence proof. If the X-Windows partisans were right, then Steve Jobs pulled off the impossible.
It only proves that their strategies and products appeal to a small demographic of computer users. For it to prove what you are implying, every OS X and X11 user must actively choose one over the other. I'm sure most OS X users never ventured anywhere near X11. I for one despise WIMP, whether in traditional Windows format or in shiny white gray OS X format. Give me a simplistic window manager any day.
Oh, it /absolutely/ does. It means that companies can train people -- remember, those pesky hundreds of millions of people who are not computer savvy -- to use applications and not see their investments go up in smoke when some neckbeard decides that shift-clicking the mouse just has to center it on the screen, or play rogue, or something.
The companies who have been successful at UI platforms -- mostly Apple and Microsoft -- have extensive guidelines on how applications should behave. People expect this behavior, and if it changes radically from release to release you hear a lot of complaints. (Windows 8 is going to be interesting to watch).
The X-windows applications I've had the misfortune to use in my career have without exception been inconsistent, poorly designed, very bad at error recovery, and just generally all misery. You might be able to reconfigure them; frankly, I just wanted to scream.
On the other hand I seldom use apps on Windows that piss me off. I don't know whether this is because these apps have more competition, or the platform guidelines are better, or the platforms themselves are better -- whatever the reason, I rest my case.
Configuration is the booby prize if the underlying platform is garbage.
The X-Windows partisans -- particularly those trumpeting the use of Linux in the 1990s -- made predictions about which kind of graphical user interface would see more adoption, more innovation, and achieve greater ease of use. These predictions were consequent to the design principles of X-Windows. My point is that we should see if those predictions came true and, if not, how far they diverged from reality.
One of the design principles of X-Windows was the classic Unix tenet of "mechanism, not policy." This principle was most visible in the separation of the window system from the window manager and optional desktop manager. The prediction consequent to this principle was that this separation -- combined with the healing, cleansing power of open source -- would cause a thousand flowers to bloom. Unconstrained by the diktats of The Man, neck-bearded GNU hippies would unleash innumerable window managers and desktop managers showcasing a dizzying number and kind of user interface enhancements. These ideas would compete and combine in Darwinian frenzy faster than the suits at Redmond or Cupertino could cope with.
What actually happened? For the past fifteen years, the greater number of Linux users stuck to programs that aped the interface of Windows 95 or NeXT. This is especially hilarious in the case of Windows because Windows 95 was loudly reviled by the Slashdot crowd on release. "You have to press 'Start' to shut down? M$ is so stupid, LOL!" Then they paid Microsoft the ultimate compliment by implementing Start buttons, task bars, and even CUA keyboard shortcuts on Gnome and KDE.
When people are free to do as they please, they mostly imitate each other. And it's not just the so-called 'mundanes,' either; most nerds are no different.
Aside from Gnome, KDE, and perhaps WindowMaker, other user interfaces for X-Windows have remained in the minority. That includes wm2, ratpoison, xmonad, Symfony, and so forth. The Shell for Gnome3 came very late in the game and has received "mixed reviews" to put it charitably.
More to the point, if the prediction were true, then user-interface innovation should have been immediate, obvious, and embraced by nearly all. Didn't happen.
Now look at Microsoft and Apple. Their user interfaces were never as configurable as what Linux had. Closed source. Little separation between mechanism and policy. Everything was tightly coupled. And in 2003, RedHat advised general users to stick to Microsoft Windows. Hardy har har.
Microsoft and Apple understand that the purpose of a graphical user interfaces is not just to put pixels on a screen; it is to make computers easier to use. That requires research into human-computer interaction. That requires establishing interface guidelines and getting people to abide by them. That means that depending on "Don't Tread on Me" hackers may not be the best approach.
Another design principle -- really, a body of design principles -- was the X-Windows approach to network transparent display. It is central to X-Windows. X-Windows may have been the first software subsystem to pioneer this concept. X-Windows partisans declared that this feature put X-Windows far ahead of Microsoft Windows and the Apple Macintosh.
What actually happened? Here we are, living in the future, using applications delivered over the Internet. Almost none of them are delivered using the X-Windows protocol. Instead, they use the HyperText Transport Protocol. It's easy to see why. Elsewhere on this page, a commenter noted that Hacker News would crawl if it had to be delivered over X-Windows. What X-Windows is best at, it isn't much good at.
As Don Hopkins has noted (sorry, I don't have a link handy), the ideas behind NeWS, X-Windows' competitor, were so good that they got re-invented. The client side does the rendering and input management. The back end is often written in an entirely different programming language. This bifurcation between the front end and back end is what put off so many people from adopting NeWS, even though Sun provided tools for transitioning from PostScript to C. Here we are with a far clunkier substitute in the form of HTML+CSS+JavaScript because it's still better than making it work on X-Windows.
Once again, the Unix-Haters were right. As usual.
Go ahead. Say that X-Windows addresses problems that web pages can't. Make whatever objections you like. Come back to this: What do we observe? Are cross-network apps delivered more often by X or by HTTP? Again, go ahead and say that X-Windows is better for some critical use case. As funky as HTML+CSS+JavaScript can be, no venture capitalist will throw money at you to port it to GNOME. They haven't been that stupid since the tech bubble.
The centrality of network-transparent display has hindered the adoption of any replacement to X-Windows. The barrier to entry is simply too high. Whenever such a replacement was proposed on Slashdot, the inevitable comments got posted: "Does it do cross-network display? No? That's when I stopped reading." Don't tell me that it's a life-saver when you really need it. That's a tautology. If you "really need something," then, by the law of identity, you really need that thing. The fact remains that the overwhelming majority of people never needed cross-network display implemented in the way that X-Windows implemented it. Microsoft's and Apple's customers were not screaming for this feature.
The final prediction was adoption. The combination of the above features would make X-Windows so compelling, that Microsoft and Apple would have to concede or the time would come for "The Year of Linux on the Desktop."
What do we observe? Microsoft Windows remained the dominant desktop operating system without adopting any of those features. X-Windows clients for operating systems other than Unix never took off. Apple and Microsoft continued to refine their user interfaces. Apple practically came back from the dead, spurned X-Windows in favor of Display PDF, and cemented its reputation for ease-of-use and good design.
Most damning of all, it wasn't just "the mundanes" who voted with their wallets; it was hackers, too. Paul Graham has written about how many of his hacker friends switched from Linux to Macintosh. Go to any hacker or start-up meetup and note how many Macintosh notebooks you see. Think back to the drama that occurred when Jamie Zawinskie switched to the Macintosh. Ask yourself: Was it marketing? Was it Steve Jobs' Reality Distortion Field?
X-Windows has failed. The most parsimonious explanation for this failure is that the principles behind its design are false.
Except that the creators of Unix were some of the biggest X-haters, as I noted here: http://news.ycombinator.com/item?id=4528049
Unix gets blamed for lots of things that could not be further from the philosophy and design its creators had in mind.
I guess that is why they gave up on Unix and went on to create Plan 9 (and then Go).
Better does not always succeed.
X-Windows succeeded! It achieved abundance of choices for us hackers, and is hackable. In contrast, Mac OS8, Windows Vista, Windows Me failed; and if the companies behind them were able to introduce a newer model which seems more successful is to be found in elsewhere, not in their design promises or philosophy.
The majority of existing Linux window managers are not representative of the window managers that the majority of Linux users actually use.
There are just a lot of Linux window managers, most of them were probably coded and abandoned decades ago, but they still exist and the code is still out there, because they're open source and the repository they reside in is still maintained by someone, even if no one actually uses them.
You'd be very hard pressed to argue that the versions of KDE and Gnome used by the majority of Linux users fit in to either of your three categories: "Windows 95 work-alikes, NeXTstep work-alikes, or attempts at minimalism based on BlackBox or aewm"
"In the meantime, Microsoft kept improving Windows until, with XP, they had an operating system that even many Slashdotters were forced to admit was usable and productive."
Maybe Microsoft plants at Slashdot would admit that, but most Slashdot users certainly would not. They might admit that XP was better than Vista or Windows 8, though.
"Apple went to the brink of ruin and bounced back to usability preeminence using Unix code, but violating -- nay, extravagantly violating -- the Unix philosophy when it comes to user interfaces."
Some would call the one-button-mouse "usability preeminence", others would call it dumbing down the UI to pander to the lowest common denominator.
Yes, it's undeniable that Apple and MS made a lot of money selling their wares to the technologically illiterate masses.
On HN, where the making money is considered a holy virtue, this might lead some to call Apple's and MS's strategy genius, and to imply that their UIs must be great by association.
But not everyone is so enamored with making money, pandering to the masses, or dumbing down UIs so that even an idiot could use them.
"If one wants to have a good user interface, then mechanism should not always be separated from policy. Configurability should not be paramount. An authority must be in charge to enforce interface consistency, if only imperfectly."
Fortunately there's choice of window managers and UIs on Linux, and we don't have to suffer any benevolent dictators enforcing interface consistency on us all. There is no one-size-fits-all interface, UI, or window manager. I, for one, and grateful for the customizability and flexibility that the Linux ecosystem and X offers us.
On the other hand, that very separation is X's greatest hindrance. It imposes a fairly large cost, not just in terms of performance, but also in terms of complexity. You have to deal with a network protocol just to display things on the screen. No other windowing system imposes this level of cost on the developer, and it can be argued that the reason we never got a Linux desktop was because of X. Simply put, Apple showed us what could be done with a Unix system if you abandon X and set allow your GUI API to talk directly to the hardware. A large part of Apple's success can be tied directly to their decision to forego X11.
I'm not a linux guy at all, and it saddens me when I am the one to teach (supposedly advanced and technical) linux users about X forwarding.
This works even across different architectures, and the debugger is completely network unware, is all handled transparently by the file system interface to processes.
Some goes for the window system, which also works across the network even when it knows nothing about networks.
See this paper by Rob Pike about how to design window systems: http://doc.cat-v.org/bell_labs/transparent_wsys/
I would argue that Linux isn't mainstream because it has nothing like Apple's budget, specially on design and marketing. Add to that those hardware vendors that are actively hostile to support from other operating systems, and software developers that don't care, and you have it. Still, Linux is doing fine, for what resources it has.
At the time, there were many commercial Linux distributors - Red Hat, Mandrake, SuSE all spring to mind - and any one of them could have beaten Apple to the punch in offering a Unix desktop environment that was easy to use and, for lack of a better term, pretty. They didn't, though. Why not? I think the need to build on top of X is one thing that hampered Linux desktop environments when competing with OSX.
No normal application developer "have to deal with a network protocol". Even if you write code directly against Xlib that is largely transparent to the developer.
Performance was an issue until XRender and DRI arrived around 2000. It has not been an issue for years.
Incidentally, one of the reasons Wayland is becoming so attractive is exactly because so little of what X was traditionally is actually being used any more in most setups, since XRender and DRI combined means most apps does all or the vast majority of rendering client side, and the server is largely left as a resource manager and compositor and not much more.
I used to rather like X back in the early 90's but I think we've moved on a bit since. The introduction of hardware accelerated graphics and the decline of the old "network application" model have pretty much killed the model it was built on.
I'd like to see things such as Wayland succeed in the future.
The "display side" of Web apps can do a lot of useful processing which cannot be done on the "display side" of X apps. JavaScript is not my favorite technology, and the performance is, at best, mediocre, but you can perform useful computations with it.
Also, well written Web apps can reduce network activity to a minimum.
Consider, for a moment, if ten thousand people were using HN via an X app. HN would need monster servers and monster bandwidth to handle all that load, even if the users were only scrolling through comments or spending minutes typing up replies.
During the time I've been typing this reply, the Web app side of HN is making no network calls and putting no demand on HN's servers at all.
I've seen people vaguely equate X apps and Web apps before, and I'm always bothered by it since they have such important fundamental differences that change everything.
On top of that the only way to control a complex remote application was something like X because having 15 80x25 terminals wasn't cutting it.
The web browser and markup, combined with the advancement in local processing/rendering ability completely destroyed one of the fundamental problems X was trying to solve. That it didn't kill X right then and there was, in my opinion, an artifact of the implementation as a glorified telnet session for the HTTP server.
The rendering model for most apps is totally different.
Overheard at a Usenix conference, around that time:
Person A: "... well, I think that Mach is the best example of intellectual fraud that I've seen here this year."
Person B: "What about X Windows?"
Person A: "I said _intellectual_ fraud."
I was never a fan. X was just too far removed from the actual frame buffer to make this video-game writer happy. At. All.
(Probably didn't help that I tried to bring up one of the first versions of X on our Vax, and thought that their design decisions were just jaw-droppingly awful. I don't remember many details -- the frame-buffer layout was pretty strange, though they changed it later -- I just remember shaking my head a lot).
"Programming graphics in X is like finding the square root of PI using Roman numerals." -- Henry Spencer
"Sometimes when you fill a vacuum, it still sucks." -- Dennis Ritchie speaking about X
"If the designers of X Windows built cars, there would be no fewer than five steering wheels hidden about the cockpit, none of which followed the same principles – but you’d be able to shift gears with your car stereo. Useful feature that." -- Marcus J. Ranum
"The X server has to be the biggest program I've ever seen that doesn't do anything for you." -- Ken Thompson
Throwing out having an actual graphics protocol and going bonkers on net-blit (as is a collection of a bunch of hard-to-predict tradeoffs: Is the app graphics-op heavy? (might support using net-blit) Is the window size large? (2560x1600 here sometimes - net-blit is usually a disaster at this size) Is responsiveness an issue? (jamming the net with video can impede getting events back) Is the user trying to access an app at home from work? (Uplink speed on many consumer-grade connections is crap) What if the remote server doesn't have a console? X deals with this really well, allowing full apps and virtual X servers to be run on a headless system and used remotely.
3D graphics operations are an even more interesting discussion.
To put it simply, I love X because of remote graphics ops, which fill in essential niches few graphics system even think about. Taking issue with the bandwidth and lag of the graphics ops stream between computer begs for more work to be done to improve it (ah, NeWS, how I miss you).
Simply: If I can't use graphics apps running on a headless server with no graphics card on my local, graphically-awesome workstation - then that failing window system just Doesn't Interest Me.
:-)
(That doesn't means X can't be improved... OMG... there is so much to improve, in particular being able to push x,y using events to a window without have to do it from the backwards full-screen paradigm... jeez)
I don't directly have to call many X11 apis (only some hotkey grabber thing). It is more a matter of occasionally going through Qt code to find out why X doesn't work or workers strangely.
The most annoying continuing thing from my viewpoint is how every top-level QT window appears on any task-list under Gnome. I don't even know if this a Gnome or an X11 artifact. I suppose what I should say is the annoyance is having a multitude of lower levels apis to page through when you find a problem and are looking for the culprit.
On a break this week, otherwise I'd go back and give more specific example.
Probably. We use Qt for an application [1], and we didn't encounter any serious problems on Linux/X11. We never had to dig deeper than any of the Qt classes. Qt itself has some weak spots (e.g. if you have a table view in a tab with very many items, switching between tabs can become very slow). But the most serious problems we encountered on OS X, mostly because Qt doesn't naturally map to how OS X applications work (e.g. Document-based interfaces, OS X-specific features) and Qt on OS X seems to be less well-tested (e.g. between Qt 4.7 and 4.8 the default renderer was changed, but the new renderer had a bug, which broke painting in our application).