None of that is relevant to parent's comment about "churn". I guess they're assuming the X11 ecosystem is literally the same as the Javascript one, or something.

I'm honestly astonished at how quickly people jump on to wayland to complain about it, about how things are changing, about how it's not perfect etc. Wayland is an ongoing answer to a plethora of long term problems that Linux is facing. Display-level app sandboxing, screenlock security, high DPI (scaling) support, etc. Dropping support for 30 years of legacy that is no longer relevant is just a bonus.

In the real world, things like multi pointer never worked (neither GTK nor Qt really supports it). High DPI monitors on the other hand are getting more and more common. So yeah, priorities.

And the wayland devs aren't some cabal out to prevent people from implementing those things you mention; or creating a solid plugin interface. They're just lacking in manpower because 1. it's hard and 2. few are seriously paying for that development to happen.

So when a company like Canonical decides to do their own version of wayland, not only are they actively removing potential users from the display server, and duplicating the migration effort, but they're also impeding development on wayland itself. So if you're annoyed multipointer isn't supported in Wayland, I can point you towards whose fault it is.

I think the general frustration is not that X is being replaced, rather that practically anything the OSS world does quickly fragments over minor differences, resulting in a very inefficient division of already-scarce labor.

I believe this happens because there is no real unifying force other than good feelings. In a company, people are forced to make reasonable efforts to work together or they imperil their paycheck. In the open-source world, people won't volunteer their time to work on your young project if it doesn't fit their taste profile quite exactly. Since it's rare for that to happen, lots of people spend lots of time re-inventing the same basic stuff and very few people spend time working on the difficult 20% of problems that would yield an 80% improvement in overall experience.

We see this over and over in the open-source world, and it's not without its benefits, but particularly in core underlying components like display servers, it can be very frustrating because you just want everyone to adopt something and move forward. The delays caused by the fragmentation can impair things for years as driver vendors play a "wait and see" game and talented developers look at it and say "Wow, that looks like a mess, I'll stick with Windows for now".

Personally I think Mir is straight up power grab. Canonical said "Why should we be bound by what these Wayland dweebs say? Even if their stuff is great, we are the biggest desktop Ubuntu distribution and we want to be in control. We will make our own display server." It is frustrating on the outside, but I guess you can't argue that it's not in Canonical's interests, and they may indeed end up winning the war (though it didn't work that way with Upstart).

Ubuntu is arguably the most widely used Desktop Linux distro, and likewise has become very popular on the server. In this case they felt that they had a better handle on the UI needs for the graphics system in place, and in fairness they probably do. In fairness, Canonical is free to do wtf they want... there are places where they've gone with the larger linux community and other upstream things (like SystemD).

I really don't fault them too much for their decision, especially depending on how much, or not their input was considered regarding Wayland... I'm also not sure when each respective project was started.

I do find a few quirks around Ubuntu... my HTPC box is about the only Ubuntu UI I work with, the rest are VM images running a server version. The intel audio (via hdmi) often doesn't come back after sleep/suspend, there are other issues there (i3-5010U nuc), but for the most part, I appreciate the Unity ui. That said, I don't do much beyond launch Kodi or Chrome and the terminal to fix problems after updates more often than I'd like.

Also, sometimes you need a dissenting opinion in order to make something better. As much as I've disliked some of the delays from MS wrt browser enhancements, a lot of the time what comes out after is arguably better than what came before... although I do still feel that MS should have just adopted SQLite for web-sql like everyone else.

It really does depend. In the end, canonical is dedicating developer resources to make something better, and is a much smaller company with far fewer resources than Intel.

"X isn't network transparent anymore" according to Daniel Stone (longtime X.org and Wayland developer): https://youtu.be/RIctzAQOe44?t=18m31s

If you use X11 forwarding with any application that uses a modern toolkit (Gtk+ 3, Qt 5, maybe also Gtk+ 2 and Qt 4) you are just pushing uncompressed pixmaps over the wire, as a bad substitute for VNC/RDP/etc.

Xpra adds image compression on top, AFAIK, so it should be slightly better.

The entire video (https://youtu.be/RIctzAQOe44) provides a good overview as to why people that have been working on X11 for many many years decided to start Wayland.

Whose fault is that? The toolkit's? Or the protocol's? Expecting Wayland to sop up the slop because by definition it communicates at RAM-bandwidth speeds does not remove the fact that you have slop, and eventually it will bite you.

Most GUIs are relatively static. They are not Crysis. Even if you hate X's drawing primitives and believe absolutely in the power of client-side rendering, there are huge wins to be had simply by pre-rendering stuff and storing it server-side as pixmaps, then using XCopyArea calls to show them on the screen. Sheesh, I was doing that since I was 18 years old, and I figured it out using just the man pages. It's not hard. It's not even particularly burdensome. It's just a case of "herp, derp, we don't want to think about our rendering code" from the toolkit crowd. Do we have to burn the entire display stack to conform to toolkits written the stupid way around?

Well, I'd be all for a rewrite. But doing so, we're throwing all existing Xwindows code down a drain. I'm not liking that, at all.

I also want network transparency. Right now, I can run a Windows program remotely, via X and WINE. I can't do that on Windows proper without a whole lot of setup on a Windows Server (I've done it). Yeah, X may be slow. It may have crappy security model. But in the end, it's better than what MS has and better than what Mac has.

I could imagine something different. Go back to core principles, and write a server using current design paradigm and knowledge of hardware. Get the server side running, and well. Write an emulation layer that will allow existing X apps to use it. And then start porting from X to.. say, Ywindows. :)

(Then again, I wished that DRM existed for Linux, so the graphical subsystem could have its own top, memory manager, process scheduler, and such. Then that would have set up Linux to be the dominant force in computation. Alas, it never happened that way.)

I'm pretty sure I remember some compatibility shim being part of the wayland & mir plans in order to support X11 apps.

> They got rid of the idea of the X protocol and network transparency.

> I like being able to log in to remove Linux machines, and run programs that show up locally on my desktop.

I sure don't. I've had terrible experiences with this and end up going with VNC for any sufficiently complicated program (Firefox, Matlab, Cadence).

X is inherently insecure. That's enough of a reason to have everything in Wayland ASAP.

There's nothing inherently insecure about the X protocol. Sandboxing X would involve simply not providing information about drawables not created by the client. That means filtering out input events destined for those drawables and returning blank pixmaps when their contents are asked for.

That the X server doesn't do this, and provide knobs to control who is trusted and who isn't, is a shame. But again, we don't have to burn the entire graphics stack because security.