
X11 Window System Turns 25 Years Old - Xyzodiac
http://linux.slashdot.org/story/12/09/15/1551223/x11-window-system-turns-25-years-old
======
winestock
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.

~~~
winestock
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.

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

~~~
pjmlp
With the success we all know.

Better does not always succeed.

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

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

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

~~~
unavoidable
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.

~~~
Teckla
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_.

------
kabdib
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
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

~~~
npsimons
"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

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

------
joe_the_user
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
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
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
_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/>

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

