Life after X: Plans for getting rid of the X server in the future | Hacker News Reader

Life after X: Plans for getting rid of the X server in the future

lwn.net

65 pointseerpini26 comments

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.

In all the threads I've read about Wayland, there's been considerable hyperventilation about loss of network transparency along with assurances that those concerns would be easier to deal with in a post-X world; basically, that the people working in these problems weren't born yesterday.

For example, read the whole of this thread: http://lists.fedoraproject.org/pipermail/devel/2010-November...

Except that the "assurances" are wrong:

(1) They refer to vaporware features that the upstream developers have explicitly rejected: seriously, read the upstream mailing list.

(2) They refer to a two-tier world where some old X apps will still work remotely, while all new apps won't work.

(3) They refer to VNC and RDP as acceptable alternatives, even though these are inferior because they forward the whole desktop, require you to install and run an entire desktop on your remote server, refer to vaporware rootless RDP which doesn't exist on Linux, and don't deal with trivial items like pixel-size incompatibility between server and client.

RDP has included the ability to forward individual windows. RDP also includes a lot of capabilities that (as far as I can tell) X11 doesn't like bidirectional audio redirection, redirection of local hard drivers, printers, etc.

Frankly, the user experience for remote desktop and remote application access with more recent versions of RDP (in Win2008, etc) is vastly superior to what's currently available for remote desktop and/or application access in Linux.

Now admittedly, I don't know of an RDP server for Wayland that implements those features (or any RDP server for Wayland really). But given that Wayland is still fairly young that's not surprising. There's certainly no compelling reason why a good RDP server can't be written for Wayland.

Have you taken a look at mpd and its accompanying CLI frontends? Tunneling X applications over SSH isn't popular because there's almost always a CLI application that accomplishes the same thing.

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.

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

D-Bus is a cancer of the Linux desktop.

I do quite frequently for various reasons. It would be disappointing to lose it, but at the same time, I still want to see X go.

Perhaps the future tool will have a way to push ui data over the network, as well, and we won't lose those abilities.

Reading email in my work PC with my work PC software from my home PC, or burning a DVD on my mediacenter from my netbook.

A pair of commands as glue and a simple icon in the lauch bar can do marbelous things... I hope they find a way to get that features back.

I have only ever used X over ssh, at least as far as running applications remotely. Particularly when I'm on a windows box - putty + Xming is fantastic.

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.

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.

Considering that you can do all of those things today on Windows using RDP just as well (I'd say even better) than you can on a Linux system using RDP, it seems like all we need is a good RDP server for Wayland?

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

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 !

After X is dead, someone should do a fork and name it :X

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.

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

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

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

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.

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

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

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.

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.

Reply on news.ycombinator.com