What irritates me with regard to Wayland is the assumption that all rendering is local. The great thing about X was on a LAN you could bang up an ssh session somewhere, carry across your $DISPLAY and have the exact same application running somewhere else but rendered to your screen. It doesn't sound like much but there were times when it was incredibly useful.
Thin terminals brought this to the logical conclusion of not needing a desktop at all, but unfortunately X's protocol is too chatty and sensitive to latency to really shine across a WAN. These days you can work around all of that by opening a session via Guacamole or the like but that's still one tab in a browser per graphical session. There's no just using SSH in a for loop and opening up a raft of xterms to a bunch of machines in Wayland, AFAIK.
From the Wayland FAQ
Is Wayland network transparent / does it support remote rendering?
No, that is outside the scope of Wayland. To support remote rendering you need to define a rendering API, which is something I've been very careful to avoid doing. The reason Wayland is so simple and feasible at all is that I'm sidestepping this big task and pushing it to the clients. It's an interesting challenge, a very big task and it's hard to get right, but essentially orthogonal to what Wayland tries to achieve.
To be honest, I think remote rendering is unnecessary and is mismatched for actualy application workloads. The amount of data and IO needed by the renderer in many applications outstrips that needed to send the rendered result to a display. I.e. the textures, models, or font curves loaded into GPU-local RAM and then resampled or reinterpreted to draw frames. This stuff is the heart of a graphical application, and doesn't really make sense to split across a network.
When the application host is really resource-starved and does not need to supply much content to a renderer, we are better off using more abstract network interfaces. On one hand, HTML+CSS+js are the remote rendering protocol to the browser which becomes the remote renderer. On the other hand, sensor/data interfaces become the remote data source for a GUI application that can be hosted somewhere more appropriate than on the resource-starved embedded device.
What I will miss from SSH X-forwarding is not remote rendering. It is per-window remote display. I would be perfectly happy with remote applications doing their rendering within their own host, and just sending their window contents to my display server, where my local compositor puts the window content onto my screen. Protocols more like VNC or RDP could be used for each of these windows, adaptively switching between damage-based blitting, lossless and lossy image codecs, or even streaming video codecs. What is needed is the remote window-manager and display protocol to securely negotiate and multiplex multiple windows opening and closing rather than one whole desktop.
What I won't miss from SSH X-forwarding is window and application lifecycle tied to the network connection. Let me disconnect and reconnect to my remote application and its windows. Let me share such a connection to have the same windows displayed on my desktop and my laptop, or to window-share with a coworker down the hall...
If X was maintainable then this would be an extremely reasonable complaint. However, the reason that Wayland is about to get rammed down our throats is that the only developers willing to work on X.Org are those who are paid to do so and they are all working as hard as they can to depreciate it for something that fits their needs.
The idea that a desktop compositor should be network aware by default is not really a defensible design decision. Why should the compositor be responsible for sending a compressed stream of OpenGl instructions over a network? This is an activity that is Someone Else's responsibility; making a graphics developer responsible for decisions about latency and compression is just going to reduce the number of people who can understand the codebase.
The reason for X was that in 2008 the driver manufacturers wouldn't support anything else. AMD and Intel have open source drivers now, so the reason isn't good enough to justify X as a near universal standard.
At 18m30, he mentions that everyone uses SHM and DRI2, which don't work over the network. He mentions X isn't "network transparent" anymore, it's "network capable". I'm not 100% sure what the difference is tbh.
At 40m10, he mentions that rendering on the "server" then compressing it to transfer over the network to display locally is basically VNC.
When I first realized you could do this I was blown away. Just set `DISPLAY` in your environment to an X server (any X server, anywhere) and any applications you run will appear there.
Of course, there are immense problems with this. For one thing, it's usually crippled by latency. Even if the client X application is in a Docker container on the same machine, applications are only halfway usable. Use a local Ethernet network, and things start to fall apart. Going over the Internet isn't really worth trying.
The other major problem is that there's no security. If you have an open X server, anyone can connect to it and run random applications on your display. But in addition to opening you up to annoyance from cyber-hooligans, allowing an X application to run gives it access to all your keystrokes, which may not be something you want. Beyond that, all the X data is going out over the network unencrypted. There's just no security model here.
That said, it would be cool if there were some kind of plugin for Wayland that would let you use this feature (or even something better, if someone wanted to implement that). I've wondered---can you set up XWayland to be an open X server and just let random X applications connect to it? It would be interesting to hear from Wayland experts on this point.
It irks me too, but I can't really argue with the decision. X11's model of remote rendering is flawed; try starting up Firefox over a tunneled SSH connection sometime.
In order to justify network rendering at the windowing system level, I think you need a model that could reasonably give good performance to both local and remote applications without application developers having to care.
Sun's early windowing system was NeWS, which had a PostScript interpreter running on the display terminal. I think it was the better idea in the long run, but at the time X was easier to work with and wasn't patent encumbered...
That's what is generally bothering me about this whole Wayland thing: it does a (small) fraction of the things that Xorg does and calls itself a better alternative.
We have a better remote terminal client today than anything X ever achieved: the web browser.
It's not as good as a local display for resource intensive stuff, e.g. games, but X never was either (it was abysmal, in fact). It's a hard problem, but given that price/performance of computational power has mostly run ahead of network speed for most of computing history, and latency is a (mostly) insoluble problem for long distance networking, Web Assembly is often a better solution for pushing even resource intensive applications out to the edges.
I have a (IMO) next little thing that runs a docker image of my "ideal" workstation and then XForwards the GUI to the host machine - this way I can have the very same immutable workstation on different machines.
It totally depends on X. I don't even know how to run wayland.
I am surprised that X was / is so under funded and under supported.
fyi, there are two ways of using X across the network. The X forwarding via an ssh tunnel that you refer to, is technically rendered on your machine where you forward the DISPLAY from. The X client on the remote side is a 'client' and connects to your forwarded (local) display. The rendering happens in that display server (local) that dumps the result into your graphics device framebuffer/onto your screen. The instructions though come from your client on that remote machine, incl. any drawing primitives like drawing a line etc. But still the actual resources that client uses are local to your X server.
The other approach is (and that was like in the older days), when you avoid any tunneling but let X clients connect to open X servers across the network, like if your X display server listens on all NICs for clients. This setup is still technically possible but pretty much discouraged for security concerns. But with this setup you could also run a local xterm or whatever X client against a remote X server (like your neighbours ;), assumed it would accept your connection.
Uggh. RedHat has a long history now of replacing working stuff with half baked, regressed-by-design replacements.
I’d really like to have a working Unix environment, and Linux stopped being that for me years ago.
More conservative alternative distros keep bit rotting due to upstream (usually RedHat induced) breakage. (SystemD, Wayland, DBUS, PulseAudio, Gnome 3, kernel API brain damage, etc)
Does anyone know of any alternatives? Is there a distro/foundation that will actually support open source Unix moving forward (BSD, maybe?)
It's about time. A 10+ year transition from X.org to Wayland is long enough.
X.org is open source, it is does not belong to Red Hat. It's a truly desirable technology, anyone else is welcome to contribute to the maintenance of it or fork it.
When no one else wants to maintain it favor of newer technologies, that's a good sign it's ready for retirement.
In those ten years, clusters in remote datacenters went mainstream, but Wayland has never delivered network transparency except by embedding X. Where are these users who are still running everything on one computer under their desk?
Sad. It's probably unpopular but wayland is not ready yet IMHO and lacking on a conceptual level. Yet another few years/months until most bugs are fixed and more broken functionality...
I'm wondering if all the resources that went to Wayland for the past TEN years were directed to slowly evolve X11 to the same direction we would be in a worse or better situation.
It seems to me very similar to the Python2/Python3 debacle.
What pisses me off more than anything else is having to replace a lot of tools there are working perfectly with xorg but are not compatible with wayland.
Yes, I know that I'm using an unconventional setup, but the freedom to do that was one of the reasons that attracted me to a unix environment. Redhat is working very hard to change all of that for a "year of the linux Desktop" that (in my opinion) will never come.
>I'm wondering if all the resources that went to Wayland for the past TEN years were directed to slowly evolve X11 to the same direction we would be in a worse or better situation. It seems to me very similar to the Python2/Python3 debacle.
Are you arguing that a decade of constant breaking changes to a huge number, if not the majority, of desktop linux programs, and the accompanying maintenance challenges (as versions of window managers, Gtk and the like would all be tightly coupled to specific Xorg versions) would have been a better approach than a rewrite + compatibility shim (XWayland) that allows for a fair amount of backwards compatibility?
With the coming IBM transition, I'm expecting Red Hat itself to go into "Hard Maintenance Mode" fairly quickly. Another comment here estimates 10 years of RH support, but I'm confident that X.org will outlast RH.
The Wayland developers have a security model [-1] that is hostile to "power-users" (those who like to use the Unix (or other OS) programming environment to its full potential) and the visually impaired (eg., blind). See [0] [1] [2] to see what features I am talking about.
It is possible to implement some of those features on a per-compositor basis, but the result of that will be graphical API fragmentation, as programs that interact with GUIs will need to have separate code for each compositor. And the work is not done even for Gnome (more precisely Gnome's Wayland compositor and the Gnome applications that use it) yet.
On the other hand one could say, eg. "Why not make a compositor accessibility protocol on top of Wayland?". End result of that, it is easy to guess, would be something worse than X Windows (because of even more layers of abstraction, and possibly even more incompatible standards/APIs/protocols), which the Wayland people were supposedly trying to escape from.
Edit: Another thing that makes Wayland (at least without an extension ...) unsuitable to replace X Windows is forced compositing. This means unavoidable double buffering and thus worse video performance (especially noticeable for interactive stuff like video games).
[-1] I prefer calling it security theater, because it does not bring any real security improvement in practice.
The X Window System has had a great run; a whole generation. And it's still going, even if it's trailing edge tech now. Thanks Bob Scheifler, Jim Gettys, and the whole crew.
Fedora 31 is looking to be the most advanced OS yet. If you haven't tried it yet..I strongly recommend trying it out (for those who don't know, Linux can be tried out using a usb drive without affecting your hard disk called "liveboot").
Fedora is a much more polished experience than Ubuntu and other than the lack of Sketch and Photoshop, I daresay at par with OSX.
What a blanket statement. Ubuntu is the same Gnome with three super popular extensions enabled, Yaru theme and some minor dconf tweaks. It even provides a simple gnome-session package in case you want an even more vanilla experience. The software selection is quite standard and sensible. The installer is good looking and idiot-proof. It's not that I dislike Fedora, it's just that it's not a more o less polished experience than Ubuntu.
From a normal users perspective it didn't seem any more advanced than Ubuntu. Exactly the same but installing software on the command line takes 2 minutes longer.
I wish I could move to Wayland, but I make heavy use of X-only automation tools ( https://github.com/autokey/autokey for keyword expansion and cross-app macros, and wmctrl/xdotool for window switching using https://github.com/ronjouch/marathon ) and nothing similar exists under Wayland.
So far, it doesn't look like similar tools are planned, and neither GNOME nor Sway offer these features I'm looking for :-/ .
Oh, I was going to mention Sway too, since of all the compositors I've seen it is the only one that seems to care about replicating such functionality. Is it really still that lacking on the automation front?
Everybody's blaming Red Hat. Why should they maintain something they're no longer using? If a credible new maintainer would step up, I'm sure Red Hat would be happy to hand over the reigns.
This is especially bad with anything based on Chromium/Electron and fractional scaling at the moment. The Ozone/Wayland back end is still a way off it seems.
I want to switch to wayland, but it’s impossible until Nvidia get their shit together on linux. I hear AMD has awesome open source drivers now, time to give them a shot!
Have been using Sway on Wayland since 1.0 came out six months or so ago and the only awkward part has been HiDPI (I have an Intel card so not effected by the nVidia support). Otherwise good riddance to X, honestly. It felt old 10 years ago! Here's hoping the major desktops etc can finally sort out the remaining instability/rough edges over the next year or two.
Here's hoping that the wlroots protocols become more widespread so that one can actually make cross-DE tools like taskbars. I'm using tint2 on Xorg at the moment and there just isn't any alternative on wayland - you have to use what your DE gives you or suck it.
That means a plethora of taskbar extensions on GNOME, all of which suck (poor multi monitor support, poor workspace support). Having to have a separate software project for each DE is the way to get bit rotting projects nobody cares about.
I really hope they consider that Linux' graphic stack isn't an end in itself, but a driver for running the relative wealth of graphic apps (GIMP, Inkscape, Krita, Blender, Firefox, and more) many people spent the last 30 years or so developing. Those aren't going to be rewritten from scratch into Electron-based apps or whatever, and loosing them, as well as BSD and Mac OS compat, is no option IMHO.
Not sure if I understand correctly, but the absence of this is what has prevented Nvidia's proprietary drivers from supporting GPU switching without having to restart the X server session.
[+] [-] technofiend|6 years ago|reply
Thin terminals brought this to the logical conclusion of not needing a desktop at all, but unfortunately X's protocol is too chatty and sensitive to latency to really shine across a WAN. These days you can work around all of that by opening a session via Guacamole or the like but that's still one tab in a browser per graphical session. There's no just using SSH in a for loop and opening up a raft of xterms to a bunch of machines in Wayland, AFAIK.
From the Wayland FAQ
Is Wayland network transparent / does it support remote rendering?
No, that is outside the scope of Wayland. To support remote rendering you need to define a rendering API, which is something I've been very careful to avoid doing. The reason Wayland is so simple and feasible at all is that I'm sidestepping this big task and pushing it to the clients. It's an interesting challenge, a very big task and it's hard to get right, but essentially orthogonal to what Wayland tries to achieve.
[+] [-] saltcured|6 years ago|reply
When the application host is really resource-starved and does not need to supply much content to a renderer, we are better off using more abstract network interfaces. On one hand, HTML+CSS+js are the remote rendering protocol to the browser which becomes the remote renderer. On the other hand, sensor/data interfaces become the remote data source for a GUI application that can be hosted somewhere more appropriate than on the resource-starved embedded device.
What I will miss from SSH X-forwarding is not remote rendering. It is per-window remote display. I would be perfectly happy with remote applications doing their rendering within their own host, and just sending their window contents to my display server, where my local compositor puts the window content onto my screen. Protocols more like VNC or RDP could be used for each of these windows, adaptively switching between damage-based blitting, lossless and lossy image codecs, or even streaming video codecs. What is needed is the remote window-manager and display protocol to securely negotiate and multiplex multiple windows opening and closing rather than one whole desktop.
What I won't miss from SSH X-forwarding is window and application lifecycle tied to the network connection. Let me disconnect and reconnect to my remote application and its windows. Let me share such a connection to have the same windows displayed on my desktop and my laptop, or to window-share with a coworker down the hall...
[+] [-] roenxi|6 years ago|reply
The idea that a desktop compositor should be network aware by default is not really a defensible design decision. Why should the compositor be responsible for sending a compressed stream of OpenGl instructions over a network? This is an activity that is Someone Else's responsibility; making a graphics developer responsible for decisions about latency and compression is just going to reduce the number of people who can understand the codebase.
The reason for X was that in 2008 the driver manufacturers wouldn't support anything else. AMD and Intel have open source drivers now, so the reason isn't good enough to justify X as a near universal standard.
[+] [-] Zren|6 years ago|reply
At 18m30, he mentions that everyone uses SHM and DRI2, which don't work over the network. He mentions X isn't "network transparent" anymore, it's "network capable". I'm not 100% sure what the difference is tbh.
At 40m10, he mentions that rendering on the "server" then compressing it to transfer over the network to display locally is basically VNC.
[+] [-] xiii1408|6 years ago|reply
Of course, there are immense problems with this. For one thing, it's usually crippled by latency. Even if the client X application is in a Docker container on the same machine, applications are only halfway usable. Use a local Ethernet network, and things start to fall apart. Going over the Internet isn't really worth trying.
The other major problem is that there's no security. If you have an open X server, anyone can connect to it and run random applications on your display. But in addition to opening you up to annoyance from cyber-hooligans, allowing an X application to run gives it access to all your keystrokes, which may not be something you want. Beyond that, all the X data is going out over the network unencrypted. There's just no security model here.
That said, it would be cool if there were some kind of plugin for Wayland that would let you use this feature (or even something better, if someone wanted to implement that). I've wondered---can you set up XWayland to be an open X server and just let random X applications connect to it? It would be interesting to hear from Wayland experts on this point.
[+] [-] metric10|6 years ago|reply
In order to justify network rendering at the windowing system level, I think you need a model that could reasonably give good performance to both local and remote applications without application developers having to care.
Sun's early windowing system was NeWS, which had a PostScript interpreter running on the display terminal. I think it was the better idea in the long run, but at the time X was easier to work with and wasn't patent encumbered...
[+] [-] znpy|6 years ago|reply
[+] [-] vbezhenar|6 years ago|reply
[+] [-] wmf|6 years ago|reply
[+] [-] emersion|6 years ago|reply
[+] [-] SwellJoe|6 years ago|reply
It's not as good as a local display for resource intensive stuff, e.g. games, but X never was either (it was abysmal, in fact). It's a hard problem, but given that price/performance of computational power has mostly run ahead of network speed for most of computing history, and latency is a (mostly) insoluble problem for long distance networking, Web Assembly is often a better solution for pushing even resource intensive applications out to the edges.
[+] [-] lifeisstillgood|6 years ago|reply
It totally depends on X. I don't even know how to run wayland.
I am surprised that X was / is so under funded and under supported.
https://github.com/mikadosoftware/workstation
[+] [-] garbeam|6 years ago|reply
The other approach is (and that was like in the older days), when you avoid any tunneling but let X clients connect to open X servers across the network, like if your X display server listens on all NICs for clients. This setup is still technically possible but pretty much discouraged for security concerns. But with this setup you could also run a local xterm or whatever X client against a remote X server (like your neighbours ;), assumed it would accept your connection.
Like: DISPLAY=yourneighbour.host:0 xterm
BR, garbeam
[+] [-] ezoe|6 years ago|reply
[+] [-] fluffything|6 years ago|reply
[+] [-] AzzieElbab|6 years ago|reply
[+] [-] hedora|6 years ago|reply
I’d really like to have a working Unix environment, and Linux stopped being that for me years ago.
More conservative alternative distros keep bit rotting due to upstream (usually RedHat induced) breakage. (SystemD, Wayland, DBUS, PulseAudio, Gnome 3, kernel API brain damage, etc)
Does anyone know of any alternatives? Is there a distro/foundation that will actually support open source Unix moving forward (BSD, maybe?)
[+] [-] markstos|6 years ago|reply
X.org is open source, it is does not belong to Red Hat. It's a truly desirable technology, anyone else is welcome to contribute to the maintenance of it or fork it.
When no one else wants to maintain it favor of newer technologies, that's a good sign it's ready for retirement.
[+] [-] m463|6 years ago|reply
Two sort of non-obvious humble things have eliminated my need for X:
- ssh
- emacs + tramp
and there's always been VNC, but all I actually ever used that for was to get to PCs anyway.
[+] [-] erik_seaberg|6 years ago|reply
[+] [-] throwaway2048|6 years ago|reply
[+] [-] nisa|6 years ago|reply
[+] [-] mrighele|6 years ago|reply
What pisses me off more than anything else is having to replace a lot of tools there are working perfectly with xorg but are not compatible with wayland.
A few example
* Window manager (of course)
* taking screenshots
* setting desktop background
* Intercepting multimedia key (e.g. volume handling)
* using redshift to set the screen temperature
* ...
Yes, I know that I'm using an unconventional setup, but the freedom to do that was one of the reasons that attracted me to a unix environment. Redhat is working very hard to change all of that for a "year of the linux Desktop" that (in my opinion) will never come.
[+] [-] dralley|6 years ago|reply
Are you arguing that a decade of constant breaking changes to a huge number, if not the majority, of desktop linux programs, and the accompanying maintenance challenges (as versions of window managers, Gtk and the like would all be tightly coupled to specific Xorg versions) would have been a better approach than a rewrite + compatibility shim (XWayland) that allows for a fair amount of backwards compatibility?
Needless to say, I disagree.
[+] [-] vmchale|6 years ago|reply
Pretty annoying IMO. XMonad works exactly how I want it to.
[+] [-] pinewurst|6 years ago|reply
[+] [-] nsajko|6 years ago|reply
It is possible to implement some of those features on a per-compositor basis, but the result of that will be graphical API fragmentation, as programs that interact with GUIs will need to have separate code for each compositor. And the work is not done even for Gnome (more precisely Gnome's Wayland compositor and the Gnome applications that use it) yet.
On the other hand one could say, eg. "Why not make a compositor accessibility protocol on top of Wayland?". End result of that, it is easy to guess, would be something worse than X Windows (because of even more layers of abstraction, and possibly even more incompatible standards/APIs/protocols), which the Wayland people were supposedly trying to escape from.
Edit: Another thing that makes Wayland (at least without an extension ...) unsuitable to replace X Windows is forced compositing. This means unavoidable double buffering and thus worse video performance (especially noticeable for interactive stuff like video games).
[-1] I prefer calling it security theater, because it does not bring any real security improvement in practice.
[0] https://news.ycombinator.com/item?id=20308011
[1] https://wiki.gnome.org/Accessibility/Wayland
[2] https://www.freedesktop.org/wiki/Accessibility/Wayland/
[+] [-] OliverJones|6 years ago|reply
[+] [-] sandGorgon|6 years ago|reply
Fedora is a much more polished experience than Ubuntu and other than the lack of Sketch and Photoshop, I daresay at par with OSX.
[+] [-] mmplxx|6 years ago|reply
[+] [-] chacha2|6 years ago|reply
[+] [-] Iolaum|6 years ago|reply
[+] [-] ronjouch|6 years ago|reply
So far, it doesn't look like similar tools are planned, and neither GNOME nor Sway offer these features I'm looking for :-/ .
[+] [-] nsajko|6 years ago|reply
[+] [-] AnIdiotOnTheNet|6 years ago|reply
[+] [-] ndarwincorn|6 years ago|reply
[+] [-] bryanlarsen|6 years ago|reply
[+] [-] jordigh|6 years ago|reply
Rein -- what you use to guide a horse
Rain -- water that falls from the sky
Free reign -- a kingdom where people have freedom, but are still under monarchical rule
Free rein -- letting go of that which you control a horse with (preferred idiom)
Free rain -- rain's default state
[+] [-] rvp-x|6 years ago|reply
[+] [-] afitnerd|6 years ago|reply
It's especially bad new if there's no more x.org support
[+] [-] kevinherron|6 years ago|reply
I don't even own any screens that aren't high DPI at this point.
[+] [-] carwyn|6 years ago|reply
[+] [-] dredmorbius|6 years ago|reply
[+] [-] Epskampie|6 years ago|reply
[+] [-] bananaoomarang|6 years ago|reply
[+] [-] doubleunplussed|6 years ago|reply
That means a plethora of taskbar extensions on GNOME, all of which suck (poor multi monitor support, poor workspace support). Having to have a separate software project for each DE is the way to get bit rotting projects nobody cares about.
[+] [-] IceWreck|6 years ago|reply
* KDE and most non-gnome based DEs don't work with Wayland
Wayland is not ready for mass usage
[+] [-] tannhaeuser|6 years ago|reply
[+] [-] iso-8859-1|6 years ago|reply
[+] [-] robrtsql|6 years ago|reply
Not sure if I understand correctly, but the absence of this is what has prevented Nvidia's proprietary drivers from supporting GPU switching without having to restart the X server session.