X11 Window System Turns 25 Years Old(linux.slashdot.org)
linux.slashdot.org
X11 Window System Turns 25 Years Old
http://linux.slashdot.org/story/12/09/15/1551223/x11-window-system-turns-25-years-old
38 comments
I'm responding to my own post in order to answer already-posted objections as well as to flesh out some ideas.
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.
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.
> Once again, the Unix-Haters were right. As usual.
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).
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).
With the success we all know.
Better does not always succeed.
Better does not always succeed.
The incoherent statements you make are totally dissonant to my mind; here are short notes: Mac UI pre-OS-X failed to attract people too (though designed by a single entity). X-Windows enabled a wonderful proliferation and diversification of desktop alternatives nowhere to be in Mac or Windows world. X-Windows and Unix philosophy is not to be confused. HTTP's win is a punch in the face for Microsoft and Apple, rather than X-Windows, X-Windows is rather an inspiration, especially Xterm over SSH. Your connection between linux desktop's lack of mass adoption and X-Windows is a far to stretch; Linux desktop is working for hackers already.
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.
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 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.
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.
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.
Wait what? Are you saying that Gnome, KDE, and Xfce don't stand up to what OS X and Windows have to offer? You are entitled to your own opinion and it's a subjective topic but I would definitely not agree there.
> 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.
> 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.
> The lack of configuration does not offer anything to the end user
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.
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.
I'd rather have a configurable than a consistent interface. The principles aren't false just because you don't like them.
"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."
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.
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.
I'm implicitly targeting X11 through writing a QT application for Linux. The continued existence of goofy low-level apis not fully encapsulated by higher-order calls and not relevant to the role of the modern desktop certainly doesn't seem like anything to celebrate.
Interesting, I wasn't aware this was a pain-point. I may have some similar (Qt) work coming up soon and was wondering if you could elaborate with some examples, i.e. situations where you encounter the X11 APIs when working with Qt.
I'm working on an application launcher so what I've seen might be different from what you'll see.
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.
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.
I'm working on an application launcher so what I've seen might be different from what you'll see.
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).
[1] http://rug-compling.github.com/dact/
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).
[1] http://rug-compling.github.com/dact/
Understood, thanks for the insights.
I'm working on a GUI app in Qt where we use X11 in several places. The main usage is to open multiple connections to the X server for GL widgets, so that we can refresh their time-sensitive contents even when the main Qt event loop is blocked. Another is to query the current X11 virtual desktop as soon as possible after app startup, so we can display subsequent Qt windows there by default even if you switch away to browse the web while our levianthanic app loads. There are a number of less interesting examples, like setting X11-specific attributes on windows, and papering over minutiae that varies between e.g. X11 and OSX. Despite these few things, Qt has served us fantastically well.
I have mixed feelings about X. On the one hand, it's a very impressive bit of kit. It offers a unified protocol that separates the program drawing the window from the hardware that displays the window on the screen. This allows the program and the hardware to be completely separate, possibly even running on separate machines.
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.
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 really don't think this has anything to do with it. Yes, there are complexities with X, but nobody writes serious applications targeting X. You target a toolkit. And the toolkits have effectively abstracted X away for many years. So well, in fact, that both GTK and QT can run fine with other backends (including a web browser for GTK, as well as DirectFB and Wayland).
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.
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.
[deleted]
If Apple has shown something, is what putting millions of dollars and more than a thousand full-time engineers working on a Unix OS with custom hardware looks like. Most Linux users don't care about the X server nor find it underperformant. Hell, not even GUI developers have to touch it.
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.
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.
Linux doesn't have Apple's budget, true, but neither did Apple, when they started the OSX project. Remember, when Jobs came back on board and made the decision to pivot to Unix, Apple was roughly 90 days from bankruptcy. Apple of 2000 was not the fearsome behemoth that Apple of 2012 is.
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.
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.
When I remotely debug applications running in foreign countries, I always feel that X (and ssh -Y) are miraculous inventions. Unix gives a divine feeling of ubiquity.
Way too few people know about and understand X forwarding.
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.
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.
You should look up how Plan 9 handles debugging, you just import /proc from the remove machine, and run the debugger locally.
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/
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/
And we've not killed it yet.
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.
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.
I strongly agree with that sentiment. Strangely perhaps, I expect many of the original X advocates probably would as well. X was created at a time when computers had 1/50,000th the power they do today by inverse Moore's law reasoning 2^(25/1.5). From a graphics performance perspective its probably closer to one five-millionth the equivalent power by the reasoning that a full frame (1920 x 1080) specularly lit frame can be rendered in 16 mS today vs 86400000 mS 25 years ago. So you had a choice, you could either render a UI, or you could do computation, but not both.
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.
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.
We've not killed it yet because the protocol was/is extensible enough that things like XRender and DRI could be slotted in and fundamentally alter what X "is" to clients without breaking older clients.
The rendering model for most apps is totally different.
The rendering model for most apps is totally different.
Perhaps more acutely, the web browser and increased network performance killed it. When you think of the X11 model of separating server side processing with GUI, that's more or less what web applications do nowadays. Nowadays there's very little advantage (if any) to using X11.
There are some important fundamental differences between X apps and Web apps.
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.
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.
While I lack the experience and real historical context to judge, I rather like the comparison to present day web apps. Especially for new developers, which 'side' to take (or at least start, since it has to be somewhere) can seem to split your head when looking at the pros/cons and applications of either.
Joke:
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).
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).
Some of my favorite quotes about X ( from http://quotes.cat-v.org/programming/ ) :
"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
"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
"I admit that X[Windows] is the second worst windowing system in the world, but all the others I've used are tied for first." -- Paul Tomblin
X was our original inspiration for web-based apps. When we first thought of the idea it was in X terms (pun acknowledged though not intended): could we make the software run on the server and use the browser as an xterm?
Other interpretations of this have lead to what is effectively the opposite of "stateless" design. Lift and a few other frameworks work by modeling the page session on the server and letting the browser just be a render target -- to the point where you could have click events handled server side. Yes, the latency stinks in many cases so it didn't work out quite as well and more logic started moving onto the client.. but that was X over WAN's failing as well, so we collectively re-learned that lesson.
X remote feature isn't about speed, it's about being able to use a window remotely AT ALL, and being able to mix it with other apps on other machines as though they were all local. This was invaluable in large Sun environment with shared home directories across all the networks in the 1980s and 1990s in particular. The modern trend shows a lot more group environments with linux boxes with no shared admin and few shared local resources (compared to every computer being a shared resource in many networks before), and much more reliance on long-haul networks to bridge sites, instead of just using X apps between local computers with multiple users. This is a change in the balance of use cases, and in no way changes the old use case, where VNC's screen-wide focus is a bit of a fail.
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)
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)
Here is a programmers.se question on the subject of X vs web that y'all may be interested in: http://programmers.stackexchange.com/questions/165041/why-di...
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.