[belorn]

One key feature of X that Wayland refuses to implement is the concept of remote access. Everything is intended to be local only. For those "strange" users out there who want remote access, the developers replies has so far been to use VNC.

Its kind of odd that remote access has been shoved to the side in this age of cloudiness and always connectedness. One would think that there existed better methods to remote access then just copying the image buffer and compress it.

[andolanra]

From page 3, "Some Misconceptions about X and Wayland":

    II) “X is Network Transparent.” Wrong. Its not. Core X and DRI-1 were
    network transparent. No one uses either one. Shared-Memory, DRI-2 and
    DRI-3000 are NOT network transparent, they do NOT work over the
    network. Modern day X comes down to synchronous, poorly done VNC. If
    it was poorly done, async, VNC then maybe we could make it work. But
    its not. Xlib is synchronous (and the movement to XCB is a slow one)
    which makes networking a NIGHTMARE.

And later:

    V) “Wayland can't do remoting.” Wrong. Wayland should be BETTER than X
    at remoting, partially do  its [sic] asynchronous-by-design nature. Wayland
    remoting will probably look a like a higher-performance version of
    VNC, a prototype already exists. And this is without us even giving it
    serious thought about how to make it better. We could probably do
    better if we tried.

So, Wayland will implement remoting in a way similar to VNC, which will be an improvement over the current state of things in X anyway.

[cbs]

From what I understand, modern X applications run remotely are just painting a region of bytes to be shot over the wire anyway. I'll borrow X terminology for a second here, what functional difference is there between these two approaches:

X client -> (network) -> X server

Wayland "client" -> wayland intermediary "server" -> (network) -> wayland intermediary "client" - wayland server

I get the feeling that the pushback (not necessarily yours, but in general) might be rooted in the visual interface where an X server will manage and composite remote applications as if they were local but vnc and rdp (in most use cases) offer a window to the remote system. As I understand it, the former presentation style isn't precluded by wayland's approach.

Wayland's design for a client and server on the same machine doesn't do much more than pushing a buffer full of painted bytes to the server. So anything fancier than that isn't something they refuse to implement for just a network connection, they don't do it at all.

[belorn]

> From what I understand, modern X applications run remotely are just painting a region of bytes to be shot over the wire anyway.

No, that's incorrect. X server sends high level commands over the network and let the client render the requests. VNC on other hand work exactly as you describe, by simply copying the servers image buffer (a region of bytes), compresses it, and sends it over to be painted on the client's screen.

My general approval of X method rather then the VNC approach mostly comes down to performance (less traffic, smother rendering) and style. Its the same reason why I like the concepts of vector graphic over pixel formats.

But if Wayland is designed to not have any high level commands (like "create a window"), and thus only push buffers of pixels between server and client, I guess that is that then. Anything beyond copying the image buffer would then be in conflict with Waylands core design.

[fmoralesc]

> X server sends high level commands over the network and let the client render the requests.

AFAIK, that's not true most of the time nowadays, since most toolkits don't use X drawing primitives.

[lazyjones]

The X way of doing window updates became impractical with common graphics-heavy applications like web browsers. I could already feel this in the mid-90's when opening a browser window on a 19" NCD X-Terminal took several seconds over 10mbit/s Ethernet (noticeable because most other X client applications at that time used drawing primitives and appeared instantly).

For modern applications (graphics- and video-heavy), VNC/RFB seems like a much more suitable protocol, although I haven't really kept up with the latest X extensions that probably cover some of these applications.

Personally, I liked the X architecture more (despite X's inherent complexity) and expected it to become more popular with cloud-hosted applications etc., but as applications and GUI toolkits evolved in an unsuitable way (i.e. not using X's primitives), it's probably time to let go. Or to build a proper GUI toolkit first...

[dllthomas]

It works like this:

User -> Interface -> X Server -> Network -> X Client

The huge functional difference (in terms of what you describe - no idea if that's how Wayland intermediary whatever will actually work) is that with X you do not need an X server running or even configured or even installed on the system the client application is running on - only on the system it is displaying to. This may or may not be significant, depending on how lightweight and portable and easily (and flexibly) configurable the Wayland server winds up being.

[buster]

But really.. as nice as X11 network is, it's mostly just as easy to use vnc, nx, rdp, whatever. If that means a faster, lighter, better displayserver, go ahead, i say.

[bbatchelder]

You should really read the article.

[smosher]

You shouldn't believe everything you read. The tone of the article is very suspicious: the author will admit nothing bad about Wayland. In particular you might want to examine the claim that VNC style remoting is better than what X does, or that X remoting is a bad VNC.

In actuality VNC is equivalent to the worst-case option X has in terms of rendering. If you wanted something else it's just a bad joke.

[SimHacker]

Any comment on the fact that now ALL modern X rendering is worst-case? Why bother having all that useless complexity (have you ever read how the SHAPES extension deals with window borders?)?

[smosher]

X's worst-case isn't ever the whole picture. Even if most applications do a lot of drawing in the worst-case mode that doesn't rob them of the richness of communicating more useful detail as well. Even when you're "just" getting a big picture you're still getting something much more than a picture; it's a real window and it's really connected to your X server in a meaningful way. VNC has a real window featuring real pictures of real windows that are really not connected to you.

X is by all means a Rube Goldberg machine and nobody's contesting that. That doesn't mean throwing the baby out with the bath water is the better way to solve the dirty baby problem, even if it is easier—who needs soap when you can just eliminate the baby?

[SimHacker]

The baby should be able to clean itself, all grown up, educated, gainfully employed, and well on the way to paying off its student loans by now.

[smosher]

I completely agree, but Wayland Jr. has none of that because the Waylands committed infanticide the first time the baby went dookie. They still keep a photo. (I don't think stretching the analogy will be very productive.)

The fact is Wayland is less capable in this area and the project refuses to admit to it. If all you want is VNC that's a win for you, but it's insulting to say it's objectively better when many of us find it strictly worse.

[jdjb]

My understanding is that X can run as a client on top of Wayland and thus you "strange" users can run remote X applications. "One would think that there existed better methods to remote access then just copying the image buffer and compress it." Web applications fit the bill nicely.

[zqfm]

As someone who has never used X's remote access, what are its benefits over VNC?

[toyg]

It's usually snappier, because the client has some insight in what it's displaying and so it can accelerate stuff here and there; it also allows for root-less mode, where individual remote windows appear as normal windows to the local OS, rather than being forced to live in a monolithic "remote desktop" window. VNC is basically like a movie player: the local OS doesn't really know what the movie is displaying (in conceptual terms), and it cannot interoperate with it in any meaningful way.

The problem with the X approach is that client and server both do a lot of duplicated work ("oh, you're drawing a window, lemme put a nice border on it for you!" "Er, actually I was going to draw a different border, sorry." "Oh, ok, fine, I'll do what you say") and use "standards" protocols that have been hacked to death over the last 20+ years. It's very inefficient (although somehow it still feels faster than VNC in many cases, don't ask me why) and very hard for developers working on graphic subsystems (toolkits, window managers etc).

[SimHacker]

"oh, you're drawing a window, lemme put a nice border on it for you!" -- That is tragically one of the worst, most useless, and rarely used examples you could come up with for something the X server is capable of doing for you (at the expense of a lot of complexity -- read the X SHAPES extension documentation about how it supports shaped window borders) ... as long as you like black-and-white tiled 1 bit deep pixmap borders.

[toyg]

The point of the example was to show the duplication of efforts between X client and X server, which is actually in lots of places -- drawing borders, drawing backgrounds etc -- in a simple way. I'm not an X developer, I was just an unfortunate user of XFree86 and then Xorg, then I gave up and bought a Mac.

[hollerith]

>I was just an unfortunate user of XFree86 and then Xorg, then I gave up and bought a Mac.

Same here. I am able to get work done on an X11-based desktop, but the experience is definitely more aggravating than working on OS X. (OS X is slower than X11 + Linux and seems to have a weakness relative to Linux in which file IO slows down processes that aren't even doing IO, but that's not as aggravating as what X11 does.)

[SimHacker]

X-Windows is a dead end (and has been for a long time), and X window managers are as complex and dug into a pit of pointless complexity as the Space Shuttle.

There are a lot of good reasons to have a scriptable window manager, with a scripting language tightly integrated with the window system.

When I started hacking X10, I wanted to implement pie menus for it. There was a cheezy little library called "XMenu" that was intended for other programs to use to make menus, which I adapted for pie menus, but no programs actually used it, and it was not very configurable (no menu definition language, just an api), plus its model and api was not well suited for pie menus. And once you have menus, you need a way to make selecting their items actually do something!

So I adapted the "uwm" window manager to support pie menus, so you could define your own pie menus and linear menus in your .uwmrc file. Because a window manager could really benefit from pie menus: lots of the commands are spatially oriented and can be arranged in appropriate mnemonic directions, and they have a fixed set of common window management commands that can be thoughtfully arranged into a set of efficient pie menus, as well as a menu definition language to enable users to create custom menus for running apps, connecting with remote hosts, etc.

I wanted to experiment with different styles of menu tracking, mouse ahead, display pre-emption, feedback, screen edge handling, rolling between pie menus and linear menus, invoking window management commands, and stuff like that, and uwm's C code was not very flexible in that regard.

We also wanted to perform a controlled experiment comparing the selection time and error rate of pie menus and linear menus, so I needed to program the window manager to administer the experiment, define and randomize the menus, prompt the user to select from pie and linear menus, time the menu selections, report the statistics, etc.

I had been using Mitch Bradley's "Forthmacs", which was a very nice Forth system for the 68k. (It eventually evolved into the Sun 4 Forth boot ROMS, OpenFirmware, and the OLPC boot ROMs). It was capable of dynamically linking in C code (well not dll's or shared libraries, but it would actually call the linker to relocate the code to the appropriate place in Forth's address space, read in the relocated code, and write Forth wrappers, so you could call C code from Forth, pass parameters, etc -- SunOS 4.2 didn't have relocatable shared libraries or light weight threads back then, so Forth had to do a lot of the heavy lifting to plug in C code. But Forth was a really great way to integrate a library into an interactive extension language, call it from the Forth command line, build on top of C code in Forth, call back and forth between C and Forth, play around with it from the Forth command line, etc).

So I refactored UWM a bit so I could plug it into Forth and rewrite the main loop and event tracking code in Forth, and write higher level menu tracking and window management code in Forth, and administer the experiment in Forth. For example, you could pick up a window and throw it, and it would fork off a light weight Forth task to make it bounce around on the screen! See the "fling" code: http://www.donhopkins.com/home/archive/piemenu/uwm1/hacks.f

I didn't realize it at the time, but it foreshadowed what I would later do with NeWS and PostScript.

It was very nice to have a window manager that I could program in Forth, because that was my scripting language of choice at the time, and I could integrate it with C code and Xlib. But then I learned about SunDew aka NeWS (I read the SunDew article in Methodology of Window Management: http://www.chilton-computing.org.uk/inf/literature/books/wm/... and saw Gosling give a talk about it at SUG).

I visited James Gosling, David Rosenthal, Owen Densmore and Mitch Bradley at Sun, who showed me NeWS, and gave me a beta copy to play around with. I learned to program PostScript, and switched from Forth to PostScript for programming windows managers, pie menus and user interfaces. PostScript is a much better language for that than Forth, not only because it has a nice graphics model, but because it's a lot more like Lisp or Smalltalk than Forth, and NeWS extended it with an object oriented programming system that used the dictionary stack to implement inheritance, with which we built user interface toolkits and entire apps, like a visual PostScript programming environment and debugger: http://www.donhopkins.com/drupal/?q=node/97

NeWS was architecturally similar to what is now called AJAX, except that NeWS coherently:

+ used PostScript code instead of JavaScript for programming.

+ used PostScript graphics instead of DHTML and CSS for rendering.

+ used PostScript data instead of XML and JSON for data representation.

Some years passed, NeWS was canceled, some other stuff happened, the web came along, the Mac stopped sucking so badly and adopted Unix and NeXT Step, the term AJAX was coined to describe what NeWS was doing all along and what X refused to do for political reasons, and JavaScript took over the world.

So back to real-time: I just recently installed and read the source code of a nice Mac tiling window manager called "Slate": https://github.com/jigish/slate . It look very clean and well designed and even simple, and I think it has a lot of potential! You can program it in JavaScript (it makes an invisible web browser and injects a JavaScript API to the application into it, and delivers events to JavaScript when windows move or change state, calling JavaScript handlers that can call back and manipulate the windows to achieve tiling window layout, and so on and so forth), and it exposes some of the Mac's accessibility API to JavaScript, which brings a lot of power to the table.

Slate is very powerful and flexible, and I'd like to teach it to support pie menus (and other user interface widgetry, maybe by simply popping a web browser up in a window), so you can define pie menus in JSON for window and application management or whatever you want, and script their behavior in JavaScript, and manipulate windows and apps via the accessibility API from JavaScript. Maybe throw in an http server so your window manager can surface web pages and interactive user interfaces in web browsers (that would be a good way to implement pie menus in JavaScript and html, instead of coding them up in Objective C).

I think that Slate takes exactly the right approach with JavaScript, and I hope to get my head around it and do some work with it, like making pie menus for window management, app launching and controlling the accessibility API.

[sprash]

OpenGL commands sent over the network can be executed on the local graphics card via GLX.

[Someone]

And that, for instance, means that your simulation running on a huge CPU cluster that does not even have a GPU can run interactive graphics on your desktop GPU.

I am not sure whether that still is a big advantage nowadays, as the typical cluster is fast enough to do OpenGL in software, but 20 years or so ago, this was a big issue, as that huge cluster might have been a 4 CPU, 2 GB, 100 MHz machine, if you were lucky.

[vacri]

I'm told that sending the native code is smaller than sending pictures of the desktop - meaningless on your home network, but it has ramifications on a busy network.