6 ms·

X11 Window System Turns 25 Years Old

78 points by Xyzodiac 14y ago

joe_the_user 14y ago
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.
- nilliams 14y ago
  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.
  - joe_the_user 14y ago
    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.
    - danieldk 14y ago
      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/ http://rug-compling.github.com/dact/
    - nilliams 14y ago
      Understood, thanks for the insights.
  - megrimlock 14y ago
    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.
quanticle 14y ago
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.
- reacweb 14y ago
  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.
  - masklinn 14y ago
    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.
  - luriel 14y ago
    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/ http://doc.cat-v.org/bell_labs/transparent_wsys/
- lolcraft 14y ago
eckyptang 14y ago
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.
- ChuckMcM 14y ago
  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.
- unavoidable 14y ago
  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.
  - evoxed 14y ago
    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.
winestock 14y ago
I remember lurking on Slashdot during the 1990s. X-Windows partisans did not cease to extol its supposed strengths over Microsoft Windows and the Macintosh. 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.
- rwmj 14y ago
  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.
- icebraining 14y ago
  I'd rather have a configurable than a consistent interface. The principles aren't false just because you don't like them.
- 14y ago
kabdib 14y ago
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).
- luriel 14y ago
  Some of my favorite quotes about X ( from http://quotes.cat-v.org/programming/ 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
  - npsimons 14y ago
    "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
pg 14y ago
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?
- aaronblohowiak 14y ago
  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.
erlkonig 14y ago
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)
drhowarddrfine 14y ago
The meaningless drivel of "kids these days" in this thread pretending they know X and how it works just makes me want to run down the street and scream (except for the very few who commented and really know).
fromhet 14y ago
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-did-the-web-win-the-space-of-remote-applications-and-x-not#comment317285_165041 http://programmers.stackexchange.com/questions/165041/why-di...

78 points by Xyzodiac 14y ago

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.

nilliams 14y ago
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.
- joe_the_user 14y ago
  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.
  - danieldk 14y ago
    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/ http://rug-compling.github.com/dact/
  - nilliams 14y ago
    Understood, thanks for the insights.
- megrimlock 14y ago
  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.

quanticle 14y ago

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.

reacweb 14y ago
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.
- masklinn 14y ago
  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.
- luriel 14y ago
  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/ http://doc.cat-v.org/bell_labs/transparent_wsys/
lolcraft 14y ago

eckyptang 14y ago

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.

ChuckMcM 14y ago
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.
unavoidable 14y ago
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.
- evoxed 14y ago
  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.

winestock 14y ago

I remember lurking on Slashdot during the 1990s. X-Windows partisans did not cease to extol its supposed strengths over Microsoft Windows and the Macintosh. 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.

rwmj 14y ago
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.
icebraining 14y ago
I'd rather have a configurable than a consistent interface. The principles aren't false just because you don't like them.
14y ago

kabdib 14y ago

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

luriel 14y ago
Some of my favorite quotes about X ( from http://quotes.cat-v.org/programming/ 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
- npsimons 14y ago
  "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

pg 14y ago

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?

aaronblohowiak 14y ago
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.

erlkonig 14y ago

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)

drhowarddrfine 14y ago

The meaningless drivel of "kids these days" in this thread pretending they know X and how it works just makes me want to run down the street and scream (except for the very few who commented and really know).

fromhet 14y ago

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-did-the-web-win-the-space-of-remote-applications-and-x-not#comment317285_165041 http://programmers.stackexchange.com/questions/165041/why-di...