
The X-Windows Disaster (1994) - shp0ngle
http://www.art.net/~hopkins/Don/unix-haters/x-windows/disaster.html
======
ddingus
X is kind of amazing.

Once, just for fun, I had an SGI do window management, another one serve up
fonts, a linux box serving apps via NFS, and yet another headless SGI running
a shared app displayed on yet another Linux machines X window server session.

It was surreal. Launch that app, and all those machines contributed to the
interaction of it.

Plus, it made that instance of RH Linux look like an SGI. 4dwm has a distinct
look and feel.

For the most part, running over a 100T network, one could not tell all that
was happening. (Was a high end CAD app.)

Later, I did run that same app remotely, using its Windows NT build and the
Exceed X server for Win NT. Cool.

~~~
kevin_thibedeau
I like being able to run a Linux desktop in a VM on windows and "extend" to
another monitor with VM X apps rendering to a Cygwin Xorg instance. Wayland
can't do that.

~~~
cycloptic
There is no reason wayland couldn't do that, other than that your compositor
doesn't support the concept of virtual screens. I can't say that this is a
very high-priority feature for any compositors at the moment.

~~~
ddingus
And that is why X is kind of amazing. They thought it all through.

Today, it is a game of which pieces make the most sense, and whether multi
user graphical computing should be a thing.

We know it can. X did all that.

Should it?

~~~
cycloptic
As far as Wayland goes, that is up to the developers and users of those
compositors. The protocol itself supports the concept of multiple seats.

I can't speak for all the original X developers but TFA seems to suggest that
they didn't think it all through.

~~~
ddingus
When X is matched, then we can discuss whether that is true.

Currently, it's not. That does not make current efforts bad. I think they are
quite nice.

They just do not yet actualize the vision X did and does today.

Whether that is wanted / needed is also an open discussion at this time.

~~~
cycloptic
It won't be matched unless someone sees enough of a need to make it happen.
Wayland the protocol doesn't have an explicit goal of doing everything that X
did. The design is different.

As far as I can tell, the original vision of X was to unify all the
proprietary Unix vendors with a standard windowing protocol. The network
capabilities happened because they wanted to support dumb terminals connected
to mainframes. Most of those proprietary Unix vendors are now gone. Currently
it's not clear to me what role X is supposed to have, if any.

~~~
ddingus
The role is multi user graphical computing. I made comments elsewhere in
thread about that.

We may find or choose for that to not be a thing.

Ok, fine.

The X window people did make that a thing and the end result is powerful and
flexible.

None of that makes efforts like Wayland bad. They aren't.

But they, by your own definition, are a subset of what X is too. They aren't
thinking it through, by design. That is OK.

~~~
cycloptic
Wayland (the protocol) supports the necessary bits and it's up to the
compositors if they want to go the extra mile to support everything.

My own personal take is that most compositors won't because X does not
represent multi user graphical computing in the way that most people use it
today. That role is fulfilled by web applications.

------
kabdib
I was in a used bookstore a few years ago, and ran across a book titled
something like "User Interface Design with MOTIF". Well, it had been a power
of years since I last touched X-Windows (with intent to draw pixels, anyway)
and I started leafing through it.

Looking for user interface examples.

Leaf, leaf, nothing.

Flip, flip, flipflipflip . . . oh, we're at the index. Nothing.

Over 300 pages and no pictures. Zero diagrams. No user interface principles or
discussion about good or bad practices. It was all descriptions of APIs. There
was _nothing_ about user interface design in there at all.

IMHO, that's all you really need to know about X-Windows.

~~~
pengaru
> IMHO, that's all you really need to know about X-Windows.

That there was at least one poor, misleadingly titled book about MOTIF?

I've had many X-related textbooks over the years, and frankly the
documentation was exceptionally good and felt like a total waste on something
as byzantine as X.

~~~
anthk
OpenBSD has one book about Motif in in the books sectin of ports. book/vol6a I
think.

------
simonblack
And yet, here we are, over a quarter-century later, and that "disaster" is
still allowing our programs to run on one computer and display the result on
another computer on the other side of the world.

The 'Unix Hater's Handbook' is supposedly a humorous work. But it was mainly
used in the 1990s by non-Unix companies as anti-Unix propaganda. Unfortunately
for them, all of today's main computer/software companies either use Unix or
Unix-like operating systems (Apple:BSD Unix, Google:Android, IBM and
Others:Linux, Microsoft:WSL). [https://en.wikipedia.org/wiki/The_Unix-
Haters_Handbook](https://en.wikipedia.org/wiki/The_Unix-Haters_Handbook)

~~~
gok
A lot of the criticisms have been addressed though. Basically no one outside
of enthusiasts uses X any more; Android and Chrome OS use an entirely
different graphics system. The filesystems have been replaced. Shells have
been replaced and/or obviated for most users.

~~~
ddingus
Really, and this is an OK choice, but is a choice all the same:

What happened is others settled on a subset of multi user graphical computing.

That is not replacing X. It is something different, less.

Maybe less is more too. I have an open mind.

However that goes, X nailed multi user graphical computing. Pretty much any
crazy thing you can think of can be done on X.

Want to make a computer that several people use locally, each with their own
screen, keyboard, mouse? X can do that, and permit those users to view and
interact with any combination of each others display data.

One says, hey can you sort this for me? Another says, "sure", and a window
pops up on their screen...

Now, replicate that same setup, each user has their own powerful computer,
maybe with a common, shared display among them, like a wall display or
something.

No problem. X does that too, and chances are only the sysadmin differs. The
apps will have no clue.

It may be that we just do not work that way, or maybe not enough know how, but
let's be clear here.

X is not being replaced. A subset at best is being put forward.

I think that means we just are not really doing multi user graphical
computing. And that is OK.

~~~
battery_cowboy
Wow, can you tell me where I can find out about how to do those things, like:

> Want to make a computer that several people use locally, each with their own
> screen, keyboard, mouse? X can do that, and permit those users to view and
> interact with any combination of each others display data.

> One says, hey can you sort this for me? Another says, "sure", and a window
> pops up on their screen...

Is there literature or something about setting up complex things like this in
X? I'd be interested in learning more.

~~~
ddingus
The term for multiple displays is "Dual or multi-head"

The term for multiple, independent users is "Multiseat"

Those should get you somewhere near the entrance to the rabbit hole. Enjoy
your journey.

 __The view and interact part, when I explored this stuff, is very insecure by
today 's standards. Can be fun though. :D

------
ddingus
Here is one advantage of X that was notable, even today:

Keeping user data out of user hands.

A high end CAD application I used to do sales, service, sysadmin for used X
and the SUID permission bit in UNIX to accomplish keeping data out of users
hands.

On my bigger systems, I would run one application image, shared by a lot of
users. This app, when run by a user, had the data permission and "ran as" data
admin. The user has no permission.

All access to the data was through the app. And the users had no access to the
app or data, just a remote X session.

I had tens of users interacting on big designs that way. No worries.

Secondly, I could where needed, spawn a second copy of the app to run local to
be served up to or even just ran directly by needy users and everything still
worked fine. I just had the app run as a different user and the access barrier
remained intact.

But the big win was one application, one data repository, many users via X. I
made a scripted login for them. They would launch it, do their thing, and
that's it.

All I needed was a respectable X server for whatever box they ran locally.

I could admin that setup, and did, on a free JUNO dialup from all over the
country.

This was the 90's through early 00's.

~~~
tinus_hn
This kind of security is more like a suggestion. It only works without an
adversary.

X and the libraries used on it are not suitable for setuid programs.

~~~
ddingus
Context matters. The notable part today isn't hacker protection. I'm sorry I
implied that.

It's user error / protection. And at the time, getting that on anything that
required data move around? Horrors!

We've got that today, though it took an amazing amount of thrashing about to
get where I was then. And it's more secure in the adversarial sense too.
Still, a lot of data has to move around, and it's still a PITA when it does.

The better tools today are rapidly converging on that same basic model: App
serve to users through display only protocols.

------
dang
By Don Hopkins!

[https://news.ycombinator.com/user?id=DonHopkins](https://news.ycombinator.com/user?id=DonHopkins)

------
downerending
At the time when X was first being developed, there simply were no open source
alternatives. I used a few of the closed source ones and they were nice
enough, but generally available on only a single platform (e.g., HP), which
made them fairly useless.

Even _if_ Wayland succeeds, it'll be a long time before it has truly replaced
X. In reality, I think it's more likely that both will be (or already have
been) been run over by web apps.

~~~
code_duck
The browser needs to be displayed somehow.

~~~
DonHopkins
The window system needs to be displayed somehow too. What works for the window
system works for the browser too. There's no need for an additional layer of
widow system once you have a browser that can draw on the screen itself. A web
browser can make a much better scriptable window manager / desktop environment
all by itself, than anything that's possible with X-Windows.

~~~
code_duck
The comment I replied to said that X and Wayland were being overrun by web
apps, which doesn't make any sense at all.

NB as this article reminds us, there is no system called X- Windows.

~~~
DonHopkins
If you want to be pedantic, I didn't call it "X- Windows". I called it
"X-Windows". Nobody ever puts a space between the "X-" and the "Windows". The
title of the article we're discussing that I wrote and named uses the term
"X-Windows" because I specifically told the editors of the book to spell the
name that way on purpose, to annoy X fanatics. That fact was stated in the
last sentence of the article.

So what is there about drawing on the screen and handling input events and
handling network requests that a window system can do, but a web browser
can't? Why does there need to be a window system, if you already have a web
browser?

Does you phone have a web browser? Does it also have a window system too? How
often do you open and close icons and move and resize windows around on your
phone, compared to how often you browse the web on your phone? Name one thing
a window system can do that a web browser can't these days.

For example, is this a web browser or a window system?

[https://www.windows93.net/](https://www.windows93.net/)

You should read up on the history of window management and alternative designs
for window systems and interactive graphical user interfaces. Things weren't
always the way they are now, and there are many different ways of doing
things, that are a hell of a lot better than the status quo. Back before
everybody blindly imitated Google and Facebook and Apple and Microsoft because
they didn't know any better and never experienced anything different, there
were a lot of interesting original ideas. But now everybody's into Cargo Cult
programming and interface design, blindly imitating shallow surface
appearances and over-reacting to the latest trendy craze (like flat design)
that was an over-reaction to the previous trendy craze (like skeuomorphism),
without ever looking deeper into the reasons, or god forbid scientific studies
and research and user testing, or further back than a few months into the
past, and never understanding why things are the way they are, or how and why
they got to be that way.

[https://en.wikipedia.org/wiki/Cargo_cult_programming](https://en.wikipedia.org/wiki/Cargo_cult_programming)

[https://www.uxmatters.com/mt/archives/2012/02/cargo-cult-
use...](https://www.uxmatters.com/mt/archives/2012/02/cargo-cult-user-
experience-theres-an-app-for-that.php)

To illustrate my point, and lead you to enlightenment (and I don't mean the
Enlightenment window manager):

Here is one of Gosling's earlier papers about NeWS (originally called
"SunDew"), published in 1985 at an Alvey Workshop, and the next year in an
excellent Springer Verlag book called "Methodology of Window Management" that
is now available online for free. [1]

Chapter 5: SunDew - A Distributed and Extensible Window System, by James
Gosling [2]

Another interesting chapter is Warren Teitelman's "Ten Years of Window Systems
- A Retrospective View". [3]

Also, the Architecture Working Group Discussion [4] and Final Report [5], and
the API Task Group [6] have a treasure trove of interesting and prescient
discussion between some amazing people.

[1] [http://www.chilton-
computing.org.uk/inf/literature/books/wm/...](http://www.chilton-
computing.org.uk/inf/literature/books/wm/overview.htm)

Methodology of Window Management

F R A Hopgood, D A Duce, E V C Fielding, K Robinson, A S Williams

29 April 1985

This is the Proceedings of the Alvey Workshop at Cosener's House, Abingdon
that took place from 29 April 1985 until 1 May 1985. It was input into the
planning for the MMI part of the Alvey Programme.

The Proceedings were later published by Springer-Verlag in 1986.

[2] [http://www.chilton-
computing.org.uk/inf/literature/books/wm/...](http://www.chilton-
computing.org.uk/inf/literature/books/wm/p005.htm)

5\. SunDew - A Distributed and Extensible Window System

James Gosling

SunDew is a distributed, extensible window system that is currently being
developed at SUN. It has arisen out of an effort to step back and examine
various window system issues without the usual product development
constraints. It should really be viewed as speculative research into the right
way to build a window system. We started out by looking at a number of window
systems and clients of window systems, and came up with a set of goals. From
those goals, and a little bit of inspiration, we came up with a design.

GOALS

A clean programmer interface: simple things should be simple to do, and hard
things, such as changing the shape of the cursor, should not require taking
pliers to the internals of the beast. There should be a smooth slope from what
is needed to do easy things, up to what is needed to do hard things. This
implies a conceptual organization of coordinated, independent components that
can be layered. This also enables being able to improve or replace various
parts of the system with minimal impact on the other components or clients.

Similarly, the program interface probably should be procedural, rather than
simply exposing a data structure that the client then interrogates or
modifies. This is important for portability, as well as hiding implementation
details, thereby making it easier for subsequent changes or enhancements not
to render existing code incompatible. [...]

DESIGN SKETCH

The work on a language called PostScript [1] by John Warnock and Charles
Geschke at Adobe Systems provided a key inspiration for a path to a solution
that meets these goals. PostScript is a Forth-like language, but has data
types such as integers, reals, canvases, dictionaries and arrays.

Inter process communication is usually accomplished by sending messages from
one process to another via some communication medium. They usually contain a
stream of commands and parameters. One can view these streams of commands as a
program in a very simple language. What happens if this simple language is
extended to being Turing-equivalent? Now, programs do not communicate by
sending messages back and forth, they communicate by sending programs which
are elaborated by the receiver. This has interesting implications on data
compression, performance and flexibility.

What Warnock and Geschke were trying to do was communicate with a printer.
They transmit programs in the PostScript language to the printer which are
elaborated by a processor in the printer, and this elaboration causes an image
to appear on the page. The ability to define a function allows the extension
and alteration of the capabilities of the printer.

This idea has very powerful implications within the context of window systems:
it provides a graceful way to make the system much more flexible, and it
provides some interesting solutions to performance and synchronization
problems. SunDew contains a complete implementation of PostScript. The
messages that client programs send to SunDew are really PostScript programs.
[...]

[3] [http://www.chilton-
computing.org.uk/inf/literature/books/wm/...](http://www.chilton-
computing.org.uk/inf/literature/books/wm/p004.htm)

4\. Ten Years of Window Systems - A Retrospective View

Warren Teitelman

4.1 INTRODUCTION

Both James Gosling and I currently work for SUN and the reason for my wanting
to talk before he does is that I am talking about the past and James is
talking about the future. I have been connected with eight window systems as a
user, or as an implementer, or by being in the same building! I have been
asked to give a historical view and my talk looks at window systems over ten
years and features: the Smalltalk, DLisp (Interlisp), Interlisp-D, Tajo (Mesa
Development Environment), Docs (Cedar), Viewers (Cedar), SunWindows and SunDew
systems.

The talk focuses on key ideas, where they came from, how they are connected
and how they evolved. Firstly, I make the disclaimer that these are my
personal recollections and there are bound to be some mistakes although I did
spend some time talking to people on the telephone about when things did
happen. [...]

[4] [http://www.chilton-
computing.org.uk/inf/literature/books/wm/...](http://www.chilton-
computing.org.uk/inf/literature/books/wm/p019.htm)

[5] [http://www.chilton-
computing.org.uk/inf/literature/books/wm/...](http://www.chilton-
computing.org.uk/inf/literature/books/wm/p020.htm)

19\. Architecture Working Group Discussions

19.1 INTRODUCTION

The membership of the Architecture Working Group was as follows:

George Coulouris (Chairman). James Gosling. Alistair Kilgour. David Small.
Dominic Sweetman. Tony Williams. Neil Wiseman.

[...] The possibility of allowing the client process to download a procedure
to be executed in response to a specific class of input events was discussed,
and felt to be desirable in principle. However, more work was needed to
establish the practicality in general of programmable window managers. The
success of Jim Gosling's SunDew project would be an indicator, but it was felt
that it would be fruitful to initiate a UK investigation into this issue. John
Butler pointed out in discussion that in the Microsoft MS- Windows system an
input event received by a client process could be sent back to the window
manager for interpretation by one of a set of translation routines. [...]

[6] [http://www.chilton-
computing.org.uk/inf/literature/books/wm/...](http://www.chilton-
computing.org.uk/inf/literature/books/wm/p021.htm)

21 Application Program Interface Task group

[...] There was a strong feeling that, at this stage in their development,
window managers need to be very flexible. The downloading-of-procedures idea
in James Gosling's work was seen as a nice way to achieve this. In this
context protection issues were seen to be important. There need to be some
limits on loading arbitrary code, especially since the window manager has in
some sense the status of an operating system in that it must be reliable and
not crash. One idea for achieving protection was through the use of
applicative languages which are by their nature side-effect free. [...]

21.4 DISCUSSION

Teitelman: Referring to point (3) in your list, can you characterize the
conditions under which a window manager would refuse requests from a client?
It feels so soft that the user might feel uneasy. Is the window manager surly?
Is it the intention that requests are honoured most of the time, and that
failure is rare?

Gosling: Yes, but failure should be handled gracefully.

Bono: I think that there are two situations which arise from the same
mechanism. The first is occasional failure such as a disk crash. The program
environment should be robust enough to deal with it. The other situation is
where device independence is written into the system. What happens if a colour
device is used to run the program today, where a black and white device was
used yesterday? This may show up in the same mechanism, so you cannot say that
it is rare.

Gosling: When an application makes a request, it should nearly always be
satisfied. The application program can inspect the result to see if it is
satisfied exactly. If it asks for pink and it doesn't get it, it should be
able to find out what it did get. Only then should the application deal with
the complex recovery strategy that it may need. We need some sort of strategy
specification. What sort of strategy should we use to select a font or colour
if there is no exact match? What feature is more important in matching a 10
point Roman font, its size or its typeface? At CMU, if you point at a thing
and want 14 point Roman you may get 14 point Cyrillic, which is not very
useful. On point (7), are you implying a dynamic strategy, or one determined
at system configuration?

Gosling: Harold (Thimbleby) is all for downline loading this. In reality this
is not usually very easy. GKS adopts a compromise - an integer is used to
select a predefined procedure. As you may only have 32 bits, this does not
give you many Turing machines. Something of that flavour would not be a bad
idea.

Cook: Justify synchrony in point (2).

Gosling: This is mostly a matter of complexity of program. Not many languages
handle asynchrony very well. If we have Cedar or Mesa then this is possible.

Teitelman: How we do it in Cedar is that the application is given the
opportunity to take action. In Mesa we require that the application catches
the signal and takes any action. In the absence of the application program
intervening, something sensible should be done, but it may impose a little bit
more of a burden on the implementer.

Gosling: In Unix software there is no synchronization around data objects. In
Cedar/Mesa there are monitors which continue while the mainline code is
running; there are no notions of interrupt routines.

Teitelman: This is a single address space system. We are unlikely to see this
in Unix systems.

Newman: How realistic is it to design an interface using your criteria?

Gosling: Bits and pieces already appear all over the place. The CMU system
deals with most of this OK, but is poor on symmetry. The SUN system is good
for symmetry, but not for synchrony. It is terrible on hints, and has problems
with redraw requests. There is no intrinsic reason why we can't deal with all
of these though. The problem is dealing with them all at the same time.

Williams: A point that I read in the SunWindows manual was that once a client
has done a 'create window' then the process will probably get a signal to
redraw its windows for the first time.

Gosling: Right, but it's a case of maybe rather than will. Some programs may
redraw and redraw again if multiple events aren't handled very well, and give
screen flicker.

Hopgood: Do you have a view on the level of interface to the window manager?

Gosling: Clients don't want to talk to the window manager at all, but should
talk to something fairly abstract. Do you want to talk about this as the
window manager as well? The window manager shouldn't implement scroll bars, or
buttons or dialogues, we need another name for the thing which handles the
higher level operations.

~~~
code_duck
>That fact was stated in the last sentence of the article.

I know, that's what I was referring to you. Myself, I spell "X-Windows" as "X-
Windows" to annoy anti- fanatics.

I'm confused about your point about web browsers. Web browsers do not handle
any sort of graphics or display on my phone. There an app. They handled
graphics and display within the app. It's the same thing for chrome OS. Some
people seem to think that chromeOS is a giant web browser. It's not. It's
essentially a regular Linux distribution.

I was using Linux for years before Facebook existed or apple was considered a
legitimate computing company again.

I'm pretty confused about your comparisons to web browsers or Windows 93. I
would consider those more in the realm of window managers, if even that.

It seems that this entire discussion has people confused about window systems
and window managers. If you want to write direct to a frame buffer, go for it
I guess.

------
gok
> like Sun's Open Look clock tool, which gobbles up 1.4 megabytes of real
> memory

Meanwhile the clock app on my phone is currently using 12 MB. A popular time
telling website uses over 100MB on my laptop.

~~~
0xff00ffee
I bet 99% of that 12MB is graphical assets: different sized icons for
different display geometries. I always found asset management for multiple
platforms to be most annoying when developing for mobile.

This reminds me of when people started to realize Microsoft Foundation Class
(MFC) was blowing up and were bemoaning code-bloat. In 1997.

~~~
hermitdev
The very mention of MFC gave me shivers down my spine. The macro horror show
and indecipherable error messages...

Thankfully, I never had to do much MFC professionally, but holy shit, if you
inadvertently messed with one of the generated macros, good luck. I remember
it sometimes being easier to throw away everything and start from scratch than
debug the horrible compiler errors.

------
_ph_
I have been using X-Windows in that timeframe - on VMS workstations. The
biggest problem was indeed, that X-Windows mostly was a place to run xterms
on. But there were a few native GUI applicatons and they were quite nice. The
biggest problem was, that Motiv wasn't freely available. You had to pay
license costs. If not for that, "Unix on the desktop" might have actually
happened. And as the time progressed, Motiv wasn't unbearably slow any more.

~~~
donio
I remember those days too, the lack of a good GUI toolkit felt like such a big
deal. Funny that nowadays I find myself using applications that don't use a UI
toolkit, Emacs (compiled without toolkit), st, mupdf, games that do their own
UI. The only application I have running that uses GTK is chromium.

~~~
_ph_
The point I was trying to make was, that there were too few gui applications
at all, most of the application I was running were just terminal applications.
A widely available GUI toolkit might have helped this. The funniest example
was a chemical database software, which would be VT100 based running inside an
xterm, but for graphical input/output would spawn a separate window based on X
toolkit graphics. But beyond that, those expensive workstations (like $20k in
todays money) were mostly running xterm. While being technically widely
superior to the PCs of that time - there were also Win3.1 machines around,
running a dreadful VT100 emulation - they made little out of it, because there
was so little software. So they were eventually replaced with PCs at a
fraction of the price.

Ironically, even if it were the times of Linux 1.0, I suggested they should
run Linux, as they would get excellent X Windows support, unfortunately the
suggestion wasn't taken upon.

------
XMPPwocky
"The right graphical client/server model is to have an extensible server.
Application programs on remote machines can download their own special
extension on demand and share libraries in the server. Downloaded code can
draw windows, track input eents, provide fast interactive feedback, and
minimize network traffic by communicating with the application using a
dynamic, high-level protocol."

Huh, that's surprisingly prescient.

Applications on remote machines can download their own special JavaScript on
demand and share code in the server. Downloaded code can draw windows, track
input events, provide fast interactive feedback, and minimize network traffic
by communicating with the application using HTTP.

~~~
gopalv
> Applications on remote machines can download their own special JavaScript

Depending on what era we imagine writing this, this could be a Java applet or
a Flash application or an ActiveX component.

~~~
XMPPwocky
Yeah, but "SPAs" based on Java/Flash/ActiveX weren't nearly as ubiquitous as
web-based SPAs are now, were they?

~~~
fiddlerwoaroof
Flash was

------
commandlinefan
When I first saw X, I had already grown up with PCs, so the whole concept of
running the “main program” on another computer just to display it on my
computer seemed so illogical I thought I must just be misunderstanding it. I
mean.. I have a computer right here, why not run the program on this
computer…? However, if you think about it - the X philosophy was actually
mostly correct (or at least more useful than it initially seemed), they just
did it in a clunky way. We’ve been slowly migrating to web applications which
are the same basic concept: the program runs on the web server and your
browser displays the results. This actually is better from a security
standpoint (the server can access data that isn’t distributed to the client)
and a maintenance standpoint (I can deploy a new version to the server and
it’s instantaneously available to all clients). Running a “program” remotely
and displaying the results locally is so ubiquitous now that my teenage kids
are confused by the entire concept of desktop applications. What I’d love to
see, and wish I had the free time to implement, is a Linux UI based on
something like SVGALib that doesn’t use X at all; just enough to run a
terminal and a browser (and maybe an email client and a word processor if
somebody wanted to write one).

~~~
trilinearnz
I'd like to dig into this point for a moment. Why _was_ it necessary to have a
client/server architecture for a windowing system? Was it because X was
developed before practical GUI alternatives were on the market? Did the
computing power of institutional mainframes exceed that of the user-facing
terminal systems (clients)? As time passed and "client-only" windowing systems
came onto the scene, could the client/server design choice not have been
revisited for greater efficiency?

~~~
brianpaul
I think there's kind of two aspects to that (why client/server):

1\. The X protocol was roughly like an evolution of the VT-like protocols
which were used for text-based terminals back in the day. Those protocols
supported cursor control, simple character-based graphics, and later, simple
vector graphics. X was an evolution of that to deal with bitmapped displays,
mice, etc.

2\. Hardware was pretty expensive. Giving everyone in the office an X terminal
was far cheaper than giving everyone a workstation. Again, that was an
evolution of VT terminals vs. minicomputers.

Even X terminals weren't cheap. In the early 90's a monochrome 15" terminal
could be a couple thousand dollars while the workstation was at least 10x
more.

------
m463
I have so agreed with this for years.

Not setting policy is what ALL of unix does... and then everyone is fumbling
around for years trying to find a policy that works for them.

I'm reminded of that Lilly Tomlin quote: "I always wanted to be somebody, but
now I realize I should have been more specific."

------
jgon
A disaster, and yet I remember reading about attempts to replace it when I was
still in University, and now here I am over a decade into my career and
Wayland still isn't ready for primetime, especially if you use a video card
from the #1 producer of performance video cards on the planet. Small use case
I guess. X lets you do forwarding over the network and maybe sometime in the
2020's Wayland will have some sort of remote desktop solution? Still waiting
on that to be ironed out...

Replacing X feels like the nuclear fusion project of the Linux world,
constantly receeding into the future even as it maintains its promises of
fixing all our problem When It's Done(tm).

~~~
cycloptic
There are various solutions already available for remoting in Wayland.

GNOME:
[https://wiki.gnome.org/Projects/Mutter/RemoteDesktop](https://wiki.gnome.org/Projects/Mutter/RemoteDesktop)

KDE: [https://userbase.kde.org/Krfb](https://userbase.kde.org/Krfb)

Sway/wlroots: [https://github.com/any1/wayvnc](https://github.com/any1/wayvnc)

Generic:
[https://gitlab.freedesktop.org/mstoeckl/waypipe/](https://gitlab.freedesktop.org/mstoeckl/waypipe/)

Web-Based:
[https://github.com/udevbe/greenfield](https://github.com/udevbe/greenfield)

You can also still use your X11 programs remotely within Wayland, by using
XWayland, which is supported by all the major implementations.

Unrelated to Wayland, there is also backend support in GTK3/4 for rendering to
a web socket: [https://developer.gnome.org/gtk3/stable/gtk-
broadway.html](https://developer.gnome.org/gtk3/stable/gtk-broadway.html)

~~~
ricktdotorg
from this page:

> GNOME:
> [https://wiki.gnome.org/Projects/Mutter/RemoteDesktop](https://wiki.gnome.org/Projects/Mutter/RemoteDesktop)

"Currently only remote passwordless unencrypted VNC access to an existing
session is supported."

i guess that is technically a solution, but not a good one.

~~~
cycloptic
Yes, the quality of these varies, pick the one that is right for you. X11
forwarding is not without issues either. With VNC you'll probably also want to
tunnel the connection over SSH to secure it rather than rely on server
authentication anyway.

------
dang
A thread from 2017:
[https://news.ycombinator.com/item?id=15035419](https://news.ycombinator.com/item?id=15035419)

------
andyjpb
The UNIX Haters Handbook was funny at the time but doesn't make much sense
these days unless you understand all the rival hacker groups and cultures that
were largely eventually unified under "Free Software" and, later, "Open
Source". Even the LISPers have come in from the cold!

Much of this criticism of X was prescient for things to come. Autotools,
dependency problems, modularity issues, compatibility, "DLL-hell", etc. Many
of these problems don't have solutions today that are orders of magnitude
better than then.

On the other hand, one thing that's really holding X back, especially on
handhelds, is 'Myth: X is "Device Independent"'.

If the difference between a 75dpi screen and a 100dpi workstation screen was
too much, today's "retina" displays really struggle to run a usable X. You're
heavily reliant on the toolkits (Qt, GTK, etc) to scale things for you and
they mostly understand about font scaling but not about widget scaling.

Lots of distributions that might want to use it, for example Maemo Leste,
Ubuntu Touch or Gemian, are having to do a lot of UI work and hand-pick
applications for "porting" to the screens and input devices (touch) that they
want to use them on.

This means that Linux-on-the-smartphone is not yet in any position to give
Android or iOS a run for it's money because it really struggles to effectively
leverage its existing app ecosystem.

Even ignoring security models, X struggles to provide even a compelling visual
of a vision for handheld devices.

Don't even mention Wayland: that has other economic incentives that are not
yet properly aligned for widespread success (including X's app ecosystem
ones).

~~~
jcelerier
> If the difference between a 75dpi screen and a 100dpi workstation screen was
> too much, today's "retina" displays really struggle to run a usable X.

I've been running X11 on retina displays since 2014 without much of an issue.
The only big offenders were chrome and firefox. Nowadays everything just
works.

~~~
fsh
It works if you have more or less the same pixel density across all screens.
As soon as you mix very different ones, X becomes essentially unusable.
Microsoft and Apple have solved that issue years ago.

~~~
tinus_hn
Microsoft for certain is nowhere near solving this.

~~~
fsh
Legacy applications are somewhat blurry when moved from high-dpi to low-dpi,
but anything modern works perfectly well. In my experience, X with current
gnome or KDE is completely unusable in the same scenario. Either everything is
huge on the low-dpi screen, or tiny on the high-dpi screen.

~~~
Izkata
There is a third option: xrandr lets you choose different resolutions per-
screen. Nothing ends up too large or too small, you just don't get the benefit
of the high-dpi screen.

~~~
fsh
This makes it completely pointless to even have a high-dpi screen. I think it
is a pretty common use-case to have a new 4K monitor together with older FHD
ones, or a high-dpi laptop with a low-dpi external screen. X really shows its
age in relying on everything having roughly the same pixel density.

~~~
Izkata
Not completely; I do this while docked and the laptop screen is further away,
when high-dpi doesn't matter as much, and go full-res when mobile.

> or a high-dpi laptop with a low-dpi external screen

Yep, that's where I am right now, which is why I wanted to mention the third
option - our IT support people upgrading everyone's laptops didn't even know
this could be done.

------
kkotak
I think first successful implementation of Client-Server OS (and wide adoption
in the banking industry) was BTOS/CTOS that was developed by Burroughs
Technologies (BTOS) and then continued by Convergent Technologies (CTOS). It
was sweet to works with - with modular Hardware and built in debugger on the
CLI!

------
mshook
It's X-Window (System), no S.

~~~
s_gourichon
The text of the article actually has it correct most of the time. The name is
just "X". It's a windowing system that happens to be named "X".

It's named this way because it is a successor to another windowing system
named "W" and "X" comes after "W" in alphabet order.

[https://en.wikipedia.org/wiki/X_Window_System#Predecessors](https://en.wikipedia.org/wiki/X_Window_System#Predecessors)

~~~
ptx
Exactly. Many people seem to read it as "the system named X Window", but, as
you say, it's actually "the window system named X". The Linux Operating System
is an operating system and the X Window System is a window system.

Maybe part of the reason is the Title Case convention in English? (And the
other part may be the name of Microsoft's window system leading the mind along
this path.)

~~~
reificator
> _The Linux Operating System is an operating system and the X Window System
> is a window system._

You're being pedantic online about software naming and the example you choose
is the Linux "operating system"?

Good luck.

~~~
perl4ever
So you're saying it's really the "X window system"?

~~~
reificator
X is a window system, but capitalizing the wrong letters will cause a bit of
an argument.

Linux is not an operating system, and it doesn't matter how you capitalize it.

~~~
perl4ever
A "Linux distribution" is not a distribution of a kernel.

------
Izkata
> For some perverse reason that's better left to the imagination, X insists on
> calling the program running on the remote machine "the client." This program
> displays its windows on the "window server."

Um, what? By your own description, X's terminology is correct and
straightforward:

> The idea was to allow a program, called a client, to run on one computer and
> allow it to display on another computer that was running a special program
> called a window server.

The "service being provided" is "display a window", that the client connects
to. There is no inversion here.

~~~
stormbrew
The inversion is at a higher level of the conceptual stack, where a user
generally thinks of their _own computer_ as a client in all things. When they
connect out to another machine, that's the server.

So if you ssh to another machine (a server) and then use a program on it that
now displays on your machine, the direction of the connection is absolutely
"you're the server, they're the client" but it inverts the user's intuition of
what is in which role.

~~~
salawat
You're not looking at it right.

Imagine the X server running on your local machine as a server providing
access to your eyeballs.

That's why the remote machine is the client; it is a subscriber to the server
providing access to your screen.

~~~
stormbrew
I am not confused about the metaphor. Or at least, I haven't been since like..
1997 or so.

I am explaining why it confuses people. It's pretty undeniable that it does,
and telling people that they're wrong about their confusion is shockingly
unhelpful.

~~~
salawat
I'm not telling you you're wrong; simply stating a fact. You are looking at it
the wrong way.

Projects/solutions often don't make sense unless you look at them from the
perspective of the implementers; and like it or not, there is nothing _wrong_
with the reversal of client and server in reference to X. The rendering to be
done requires that your particular local hardware be controlled and
orchestrated by X aware software. It makes no sense for the remote machine to
in any way be burdened with the implementation details of every prospective
display set up it could potentially have to talk to. Therefore, the better
approach is to define an abstract API from which the remote machine can just
speak "X" and leave the details up to the server on the other end to display.
Thus, the reversal of Client and Server _makes sense_. The Server translates
your local interactions and display state into "X" protocol messages while the
remote client tracks and translates the specifics of the raw display
interactions into the implementation details specific to how what is displayed
on your local machine interacts with the system present on the remote machine.

You're getting confused by Client and Server meaning something in particular,
when that isn't really the case. X isn't doing just one thing. The X Server
provides the service allowing the client to draw on your hardware. The remote
Client is also a Server in that it provides an interface through which actions
that take place through your local system are translated into useful
functionality on the remote system; however that is a fundamentally different
perspective from which to view what X does than through the lens of being a
rendering mechanism alone. X does both things. As a rendering technology, the
"X client" is remote, the "X server" is local. As a binding between I/O events
and program functionality, you can absolutely view the "X server" running on
your machine as a client behaviorwise of the server that is the "X client" on
the remote machine; but it is still a server in the sense of being aware what
your specific hardware setup is, and how to handle it, because the "X client"
on the remote is blissfully unaware, and is only there to translate what your
"X server" reports to it into meaningful state changes on the remote host.
Client/Server is not an atomic concept in computing. You can be both depending
on how you are looking at the system. It's a bit like a duck-rabbit.

Is it complicated? Yes. Why? Because something that powerful is pretty much
guaranteed to be so, and because we try to apply terminology that is generally
used in a much more straightforward manner elsewhere to a system that taken as
a whole adopts a bidirectional client/server relationship with regards to
different subsets of the functionality that the software is intended to
enable; namely, to allow graphical interfaces to be utilized between machines
with wildly different characteristics, without burdening the "source" machine
(the remote machine) with the responsibility of driving our (the local
machine's) hardware.

Again, There is nothing wrong with the approach except that yes, at first
blush, it feels unpleasant to wrap your head around terminology-wise because
the conventional way the terms are used exists in both directions in the same
software. I don't expect most to _grok_ X the first time. You just have to dig
in and get uncomfortably familiar with the hell that is the rat's nest of
abstractions that makes remote graphical computing possible.

~~~
stormbrew
This is an incredibly large number of words that has nothing to do with what I
was saying.

------
pjmlp
> X-Windows started out as one man's project in an office on the fifth floor
> of MIT's Laboratory for Computer Science. A wizardly hacker, who was
> familiar with W, a window system written at Stanford University as part of
> the V project, decided to write a distributed graphical display server.

An overview of how this came to be:

"A Political History of X" \- Keith Packard (LCA 2020)

[https://www.youtube.com/watch?v=cj02_UeUnGQ](https://www.youtube.com/watch?v=cj02_UeUnGQ)

------
jeffrallen
Companion website to the Unix Hater's Handbook:
[https://web.archive.org/web/19981202041010/http://catalog.co...](https://web.archive.org/web/19981202041010/http://catalog.com/hopkins/unix-
haters/handbook.html)

------
AzzieElbab
Yeah sure, having CAD display on a PC with x11 server hooked to a Unix
workstation with dialup is a complete disaster and total waste of resources
when compared to uber apps of today like slack

------
jasoneckert
The Unix hater's handbook was never intended to be taken seriously.

It was written by Unix gurus that have the quirky hacker sense of humour. It's
just a Unix roast.

X was always awesome.

Y, on the other hand, well.....

------
DonHopkins
Bill Joy referred to X-Windows as "Rasterop on Wheels".

I gave a NeWS/Pie Menus/HyperTies/Emacs demo to Steve Jobs once, on the trade
show floor at the Educom conference, right after he finally released the NeXT
Machine, in November of 1988.

Sun was letting me demo NeWS and the stuff we were developing at the UMD Human
Computer Interaction Lab on a workstation at their booth, and NeXT's booth was
right across the aisle, so Ben Shneiderman rope-a-doped him and dragged him
over for a demo. He jumped up and down and yelled "That sucks! That sucks!
Wow, that's neat. That sucks!"

I figure a 3:1 sucks:neat ratio was pretty good for him comparing something
different than his newborn baby NeXT Step, which critics had taken to calling
NeVR Step, since it had been vaporware for so long until then.

When I tried to explain to him how flexible NeWS was, he told me "I don't need
flexibility -- I got my window system right the first time!"

Here's Ben's account (I love how he gently put it that "Jobs had little
patience with the academic side of things" \-- and by "engage" he meant "jump
up and down and yell"):

    
    
        Date: Tue, 1 Nov 88 07:55:48 EST
        From: Ben Shneiderman <ben@mimsy.umd.edu>
        To: hcil@tove.umd.edu
        Subject: steve jobs visit
    
        I just couldn't resist telling this story....
    
        On Tuesday I was at the EDUCOM conference in DC and Steve Jobs was showing
        NeXT...I was quite impressed...a nice step forward, improving, refining
        and developing good ideas.  I invited him to see our Hyperties SUN version
        that we were showing at the SUN booth.  The gang managed to get the new
        NeWS version working and the Space Telescope looked great...Jobs spent
        about a half hour with us going from positive comments such as "Great!"
        to "That sucks"...he had a terrific sensitivity to the user interface
        issues and could articulate his reasons wonderfully.
    
        On Wednesday he came out to the lab and spent time looking at a few more
        of our demos...the students (and me too) were delighted to have him as
        a visitor.  
    
        What impresses me is that he took his ideas and really put them to work...
        pushing back the frontier a bit further.  His system really works and
        has much attractive in the hardware and software domains.  Jobs had little
        patience with the academic side of things, but was very ready to engage
        over interface issues.
    
        Do check out NeXT...there are things to criticize, but I did come away
        more impressed and pleased than ready to pick at the flaws.
    
        -- Ben
    

Here's some old email from the Sun internal NeWS mailing list I saved:

    
    
        From: npg@East (Neil Groundwater - Sun Consulting)
        Date: Wed, Jun 27, 1990
        Subject: Humor from Dennis Ritchie (at USENIX)
    
        (Actually Dennis's latter remark was attributed by him to Rob Pike)
    
        from Unix Today 6/25 page 5.
    
        "..., Richie reminded the audience that Steve Jobs stood at the same podium
        a few years back and announced that X was brain-dead and would soon die.  "He
        was half-right," Ritchie said.  "Sometimes when you fill a vacuum, it still
        sucks."
    

[http://www.anvari.org/fortune/Miscellaneous_Collections/1332...](http://www.anvari.org/fortune/Miscellaneous_Collections/133229_in-
his-90-usenix-presentation-dennis-ritchie-reminded-the-audience-that-steve-
jobs-stood-at-the-same-podium-a-few-years-back-and-announced-that-x-windows-
was-brain-dead-and-would-soon-die.html)

------
0xff00ffee
I never thought about it from this person's perspective because I never had to
program X beyond the graphics and OS classes I took in the early 90's.
(Motif's insane verbosity makes code look awful.)

I've been using X + MWM since 1991 (AIX and Solaris, anyone?). It is still
everywhere, and I wonder how it managed to persist for so long.

Why didn't anything ever disrupt Xorg?

~~~
DonHopkins
MOTIF ANGST PAGE

If you have any ANGSTFUL Motif code, comments, documentation, or resources,
please share them with me! Here is some of the stronger stuff I've found.
Note: this is only for official Open Software Foundation Motif inspired Angst.
If you're experiencing TCL/Tk That Only Looks Like Motif But Doesn't Suck
Angst, then you should stop whining and fix the problem yourself, if somebody
else hasn't already.

[http://art.net/~hopkins/Don/unix-
haters/x-windows/motif.html](http://art.net/~hopkins/Don/unix-
haters/x-windows/motif.html)

