
Life after X: Plans for getting rid of the X server in the future  - eerpini
http://lwn.net/Articles/413335/
======
jluxenberg
Does no one else ever use X applications over an SSH tunnel? It's an easy way
to, for example, control the music playing on my Linux box hooked up to my
stereo system.

In all the blog posts about replacing X, I don't see anyone even mentioning
this feature of X. Or if they do, they say that its an irrelevant feature.

~~~
mhansen
Apparently VNC does it better. And most X apps these days use D-Bus for
communication anyway, so you can't run those over a network link.

~~~
rwmj
That just means D-Bus was a big mistake. I've looked at the implementation,
and that's a mistake on many levels too.

------
nodata
_how many of these applications care about network transparency, which was one
of the original headline features of X? How many of them care about ICCCM
compliance? How many of them care about X at all? The answer to all of those
questions, of course, is "very few"_

What an odd, contrived, series of questions. With X anybody can use pretty
much any app over the network by default. This one in particular is very odd:

 _how many of these applications care about network transparency_

How many _applications_ care? Who knows! _I_ care about network transparency.
I want to run my app where my data is. That's pretty much the killer feature
of X.

~~~
retube
I've always loved X. When I was first introduced to Unix (DEC) a little more
than 10 years ago, it absolutely stood out as the killer feature. It still
does (although apt-get is now a close second). The _only_ issue with X is
audio, and I think that is its achilles heel. I know there are workarounds,
but any other client-server windowing system must include audio natively for
it to be a viable replacement.

------
aufreak3
Apart from jokes about the "X is dead" (where X is a variable) reports, I
think the principles on which X stands are very much alive in the webM.N space
- web apps treating the browser as their display. When looked at that way, "X
has won".

~~~
eerpini
yeah, X was developed with the server-client model in view and the scenario of
the web currently fits in well with this type of thinking, so no wonder !

------
aidenn0
Probably way to late for anyone to read this comment, but I used to think X11
was dead for remoting since VNC was faster over high-latency high-bandwidth
connections (which describes most of the internet today). Then I discovered
nomachine NX; it is way better than VNC or native X for remoting. A bunch of
linux distros even have the GPL version available in the package management
system. It is as much faster than VNC than VNC is over native X11. Also, it
doesn't try to jpeg compress my syntax-highlighted text.

------
pkaler
Core Graphics, Quartz, and Core Animation are essentially the same across Mac
OS X and iOS. OS X supports OpenGL; iOS supports OpenGL ES. OS X has AppKit;
iOS has UIKit. OS X also has Core Image.

The balkanization of desktop Linux and Android makes no sense to me. The
Surface Graphics Library and Surface Manager on Android needs to converge with
desktop Linux. [http://developer.android.com/guide/basics/what-is-
android.ht...](http://developer.android.com/guide/basics/what-is-android.html)

------
joe_the_user
An alternative to X would be great.

The Linux windowing system is currently a gawd-awful mix of poorly mixed
layers.

The problem is that any replacement might follow the dynamics that generated
the present arrangement...

~~~
burgerbrain
>The Linux windowing system is currently a gawd-awful mix of poorly mixed
layers.

Yes, because the mix of X and Wayland being added to that is really going to
improve the situation...

Like it or not, that system of layers is what makes linux feasible and viable
in the first place. Each program/project doing specializing in one particular
thing means each programmer specializes in one particular thing. If you want a
monolith then you have plenty of other options, but linux is done this way by
design, not accident.

------
rryyan
Could anyone explain what the "mouse ahead" feature of X is? It's mentioned in
the article and it piqued my curiosity -- googling has been unhelpful.

~~~
sparky
I wouldn't characterize it so much as a feature (I know that's the article's
wording, not yours), but some features meant to deal with a potentially
problematic situation called "mouse-ahead".

I found the explanation in "Why X is Not Our Ideal Window System" (
[http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.8.2...](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.8.2723&rep=rep1&type=pdf)
) to be pretty thorough. Essentially, X defines an asynchronous protocol
between client and server, since they may be running on different computers
with hundreds of milliseconds of round-trip latency between them.

In most asynchronous systems like this there are race conditions that must be
attended to. Mouse-ahead is one such problem. Imagine that you have it mapped
into your muscle memory that you need to click a button to expose a menu, drop
down about 40px, then release the mouse button to open a new file. In reality
that sequence of events involves a few roundtrips between you and the X client
(remember, this could be up to a second). What happens if your "I released the
mouse button" signal is processed by the X client before it knows "a mouse
release in this part of the screen denotes that he wants to open a file"? If
you don't think about mouse-ahead beforehand, the answer is either your mouse
release will be interpreted as happening as whatever is under the menu, or the
mouse release will be lost forever; neither is good.

So pg. 6 of the linked article suggests a solution, a _synchronous grab_ , in
which you don't actually send the mouse release command until you know the
client is ready for it. I'd suggest reading the first few pages of the
article, it's one of the more cogent descriptions of a real race condition
I've encountered.

~~~
rryyan
Thanks! Just what I was looking for, and that article is very interesting.

------
henryprecheur
I would love to see X die. Over the years it has become a very complex beast.
But I don't think X will die anytime soon: Replacing it with something better
is a daunting task, but it's kind of trivial compared to rewriting all the
applications that use X.

Of course we can run X on top of something like Wayland, but we'll just have
added another layer, and X will still sit on top for another 10 years.

~~~
rwmj
You would "love to see X die" why exactly? You claim it is "very complex" but
don't explain in what ways this affects you. How do you know Wayland will be
any less complex or smaller?

X was overengineered for a SunOS 4 system with 8 MB of RAM (but it still ran
there). But my systems are way larger than that now, and X has stayed roughly
the same. Now I've got python crap running consuming more memory than X.

