Slashdot Mirror
Ubuntu Is Switching to Wayland (omgubuntu.co.uk)
An anonymous reader shares a report: Ubuntu is to ship Wayland in place of X.Org Server by default. Mir, Canonical's home-spun alternative to Wayland, had been billed as the future of Ubuntu's convergence play. But both Unity 8 the convergence dream was recently put out to pasture, meaning this decision was widely expected. It's highly likely that the traditional X.Org Server will, as on Fedora, be included on the disc and accessible from whichever login screen Ubuntu devs opt to use in ubuntu 17.10 onwards. This session will be useful for users whose system experience issues running on Wayland, or who need features and driver support that is only present in the legacy X.Org server session.
With Ubuntu's switching to PulseAudio, to systemd, to GNOME 3, and now to Wayland, what is it that makes Ubuntu different from Fedora?
Gratuitous privilege escalation enabled by default.
http://toaruos.org/yutani-the-new-compositor.html
How this will be solved in the long run remains to be seen. In the short run, toolkits that support Wayland still support X11. Mainly I'm talking about GTK and Qt. Thus KDE, Gnome, GTK, and Qt apps will all run either on Wayland or X11 without recompiling. So for many people, remoting needs can be accomplished by simply using X11 on Wayland and tunneling X11 over SSH. Simply ssh into your remote machine and run the apps. Locally on wayland things are silky smooth, remotely they still work, though a bit choppier (X11 over ssh isn't fast enough for anything but LAN anyway... I use X2Go for WAN remote X11 stuff.
Of course in the long run if Wayland is successfull the X11 backend bits will languish in the toolkits and this will not be a sustainable future. I think essentially RDP will be adopted as the standard remoting protocol for wayland desktops. This will be used to forward individual apps or whole desktops. RDP is already a lot faster than X11 over ssh, due to the way X11 works and the fact that all modern toolkits essentially just push bitmaps these days anyway.
Before criticizing Wayland and extolling X11's virtues, consider watching this talk by Daniel Stone who was formerly intimately involved with X.org and seems to know hist stuff. He makes a good case for Wayland. https://www.youtube.com/watch?...
I too use X11 forwarding over SSH (ssh -Y) all the time. Sometimes I'm at work and want to quickly tag some music that's on my machine at home. I can remote SSH with X11 forwarding and start up easy tag.
It's a pretty common use case among some of us Linux users.
Before criticizing Wayland and extolling X11's virtues, consider watching this talk by Daniel Stone who was formerly intimately involved with X.org and seems to know hist stuff. He makes a good case for Wayland. https://www.youtube.com/watch?... [youtube.com]
I can't second this enough. This should be required viewing before any of the anti-Wayland people spout their bullshit rhetoric.
You might be interested in XRDP: http://www.xrdp.org/
I haven't used it in a few years, but I remember really liking it.
Team effort to a fault at times :/
Here's Fedora trying to come up with a release name for Fedora 20:
https://fedoraproject.org/wiki...
Which, whatever, ok...
Eventually they decided they could never come up with release names any more, it was just too hard:
https://lists.fedoraproject.or...
Which is why you'll see stuff like 'Fedora Core 25 ("Twenty Five")' - the part in quotes was supposed to be a fun name. But every name is offensive.
https://lwn.net/Articles/48890...
You can't name things after astronomical objects, because those are offensive, because Mars is offensive (apparently lol). Anything named after something religious or mythological offends an atheist. Coffee can't be used because some religions are offended by coffee. Scientist names are sexist because most of them are men, and they even tried that card to claim numbers are offensive, but that one apparently didn't fly.
So when everyone gets together to name something, they eventually just decide that Things are simply not nameable, lest someone be offended. If instead, some asshole was in charge of naming, it would just be named GloryPork and anyone who wanted to bitch about it would have their complaints circular filed. There are benefits to just some asshole in charge.
There is no fundamental benefit with respect to performance as Wayland and modern X clients basically work in the same way when operating locally.
I think what he's referring to is this:
For a "modern" X system (i.e. using a compositing WM---though I don't use one), the event (say, mouse) goes to X, to the compositor program, back to X and then to the focussed program, compared to the old version of X where it goes from X to the program directly. I think Wayland, not having the compositor as a separate program, skips one of those steps.
I've seen that touted as an advantage of Wayland, but FFS, context switches are FAST, and the time taken to process events is down in the microseconds. It shaves a few microseconds of latency off events happening at 10s per second, and for which the minimum perceptible latency is about 0.05 seconds.
The advantage is therefore so minute as to to be irrelevant and touting it as a big advantage is pure FUD. I agree with the GP.
SJW n. One who posts facts.
You do realize that most of the folks that started Wayland were originally long-time X hackers, right? There has to be a reason why they gave up trying to get X11 to behave properly, besides "because it's bloated".
Education: https://www.youtube.com/watch?...
My spoon is too big.
Nothing about RDP limits it to full desktops. RDP can remote a single window as well as a full desktop. MS doesn't normally use it that way, but it can be done.
Furthermore, Xrdp can run in rootless mode, if I'm not mistaken. A single X11 apps could connect to it.
I'm going to start where a lot of people don't usually start. The actual people who maintain X11. They hate the code base, they just simply don't want to deal with the tangled mess that it is. Seriously go look at a dependency graph of just the xserver or a slightly higher level view of the state of things. Point, no one wants to maintain this mess. Anyone feeling frisky in doing so is strongly encouraged to do so, but the majority of developers who have worked on this in the heyday have long since left the building. The sheer pool size of people working on X is low and fresh blood in the development pool is best described as anemic. Fewer developers working on one project and more on another project pretty much seals the deal on the direction. Arguments of X being better falls on non-existent ears. You want to talk to an X developer? Head over to Wayland, that's where you'll find a lot of them.
Next in line is that X is ineffective at one of the things that it's suppose to do, draw stuff on your screen. (Not even going to touch multi-monitor, sleep, touch input, etc all which have had extensive hacking to get it working and thus resulting in patches of code with serious bus factor one issues.) X11 lacks pretty much everything we take for granted in a modern GUI. Want anti-alias text? Well X11 doesn't do that. Want the concept of an alpha-channel? Not present in X11. Quite literally, X11 does nothing in the way of anything that say KDE, GNOME, Unity, Cinnamon, or whoever wants. Instead, your chosen toolkit is using a library that builds in memory the bits that need to be drawn and if your xserver supports RENDER, your toolkit just gives a stream of bits over to X11 via that method, and X just forwards it on to either the card or to a compositor, which by the way X11 doesn't have a concept of, hence the reason you need one external to the xserver. At some point someone said, if every toolkit is just building bits by themselves and then having X forward it on, why not just cut out the middle man? Why have this extra layer that we keep having to build ad-hoc extensions for? (RENDER, XDamage, RANDR, XFixes **yes literally an extension to fix stuff but mostlly to turn a lot of old X11 stuff off.) All of these wonderful extensions are in reality short circuiting old cruft in a code-ugly fashion. Add in new complexities being added to video cards, functionality that's difficult to eventually get working, and yeah everyone is ready to put the old girl out to pasture. X11's lack of so many things is a roadblock to tapping your card's fully ability, which is why most of the time we're happily ignorant of all of the by-passing of huge parts of the core of an xserver, with the prolific set of extensions that come automatically built into your distro. (which is why a lot of folks never notice and just think that this is the way X was built, but nothing further from the truth could be said. Try building an xserver from source.)
Now let me move on to your points
Network transparency. X11 has it. Wayland doesn't.
If you are using X11 over ssh, you aren't using X11's network transparency. What you are doing is streaming pixels across ssh, but you aren't using anything remotely looking like core X11 protocol. On the remote side, Cario, Qt, Mutter, or someone is drawing pixels and then that gets wrapped into a generic X11 package and sent to you to open up and then have your computer decide what to do with the newly received pixels. There's no commands like "Window A is currently at location x,y. It has a button at rx, ry relative to the top-left corner of the parent widget, blah blah blah." Nope, it's just "here's pixel one, here's pixel two, here's pixel three..." There's no distinction in X between a button in an application running on a remote server and a picture
RDP is pretty awful in comparison. Consider a use case where you need to have multiple X servers on your display from multiple machines. Using RDP you would have multiple desktops on your display.
Well, depends on how much of RDP Wayland would implement. It certainly supports Seamless Windows:
Remote Programs, also known as remote applications integrated locally (RAIL), is a Remote Desktop Protocol (RDP) feature (as specified in the Remote Desktop Protocol: Basic Connectivity and Graphics Remoting Specification [MS-RDPBCGR]) that presents a remote application as a local user application. RAIL extends the core RDP protocol to deliver this seamless windows experience.