Ubuntu 18.04 LTS Will Default To The X.Org Stack, Not Wayland (phoronix.com)

An anonymous reader writes: Five years after their original goal to ship Ubuntu with Wayland, Ubuntu 17.10 transitioned to using the Wayland display system by default as part of their transition to GNOME Shell as the default desktop. But with the upcoming Ubuntu 18.04 LTS release, Canonical has decided to transition back to the X.Org Server. Their reasoning for moving to an X.Org Server by default is better support for screen sharing, remote desktop, and better recovery from crashes. But for those interested the Wayland session will still be available as a log-in option.

Comments

See Saw Cycles of Adoption and Abandonment

[CRB9000]

Really, these things swing back and forth and really is a non-news item. The headline should be changed to read: Defaults to X.org Allows Choice of Wayland. Which is not really newsworthy.

In other words, "Meh."

Re:See Saw Cycles of Adoption and Abandonment

[Viol8]

"Which is not really newsworthy."

Well it is actually. Various vested interests have been plying the X Windows is dead, Wayland is the way forward line for a few years now. For Ubuntu - a distro not exactly known for its conservatism and aversion to releasing bleeding edge sofware - to return to X as the default graphics system is a pretty obvious statement that Wayland is a long way from being ready for prime time.

Re:See Saw Cycles of Adoption and Abandonment

[CRB9000]

I disagree. If they were totally abandoning Wayland, then you'd have a point. They simply saying, "Hey! Look! Choice! Yay us."

Re:See Saw Cycles of Adoption and Abandonment

[jouassou]

It's not necessarily that it's a long way from prime time. But it's definitely not stable enough at the moment to be the default in an LTS version, which has to run stable for the next 3 years without relying on any major upgrades.

Re:See Saw Cycles of Adoption and Abandonment

[Junta]

Well, it's a bit more than that. The statement has been in various circles 'wayland is good enough *today*, you don't need xorg anymore'

This is acceptance that people do have things they can't do in Wayland, and it needs to be opt-in rather than opt-opt to avoid bad user experience.

It's not 'wayland will *never* be better', but it is a statement that it has a ways to go, and some of the limitations are design choices that will require interesting conversations, particularly about security with regards to screen sharing.

Re:See Saw Cycles of Adoption and Abandonment

[chill]

This is called the Tyranny of the Default, and is a real thing.

Re:See Saw Cycles of Adoption and Abandonment

[Galactic Dominator]

Canonical's Shelf of Broken Dreams is well stocked. It's just one more in a long line of abysmal, over-ambitious failures. However it can still be argued Wayland is still in a Failure-in-Waiting status.

Re:See Saw Cycles of Adoption and Abandonment

[Fly Swatter]

A vendor in it for money chooses to backtrack and default away from the new and shiny. I don't think that is about choice and a hell of a lot more about what they think of the current state of Wayland.

Re:See Saw Cycles of Adoption and Abandonment

[thegarbz]

Various vested interests have been plying the X Windows is dead, Wayland is the way forward line for a few years now.

And they are right for the use cases they presented. Unfortunately those use cases do not overlap with the use cases of those who jump only between LTS releases of Ubuntu.

Re:See Saw Cycles of Adoption and Abandonment

[rahvin112]

Baloney, it's retaliation for the community not getting behind mir when everyone said wayland had everything mir wanted.

I should also point out the same people beyond Wayland are behind X86.org. At some point that 40 year old code based designed around a 386 when the software had to draw even the primitives just isn't going to cut it anymore.

Re:See Saw Cycles of Adoption and Abandonment

[postbigbang]

Canonical announced dumping Wayland quite some time ago, so this isn't news at all. It was too tough for them, and couldn't be rectified with their new best friends, Microsoft.

It was over-promised, then never-delivered.... although it's only one of the few Canonical failures.

Re:See Saw Cycles of Adoption and Abandonment

[Anonymous Coward]

At some point that 40 year old code based designed around a 386 when the software had to draw even the primitives just isn't going to cut it anymore.

You got the reality exactly backwards. A codebase designed around being efficient enough to run on a 386, and field-tested on every thing imaginable for 40 years.
Anything that today's wonder boys can generate, is destined to be a steaming pile in comparison - just because they never saw a reason to learn what efficiency or portability even is.
Barring a major miracle, X will stay with us for quite some time yet.

Re:See Saw Cycles of Adoption and Abandonment

[Spacelord]

> that 40 year old code based designed around a 386

It's less than 30 years, and you can say exactly the same about Linux.

Re:See Saw Cycles of Adoption and Abandonment

[kurkosdr]

Because let's face it, what's holding back Wayland is the same reason X.org's problems aren't all architecture-related: Money. Developing a modern display server is a money-sucking process and nobody is willing to put them on a table, so everything proceeds at a glacial pace. Even the CLI of linux isn't all that great IMO. You don't get rolodex autocomplete (where you can cycle through the suggestions by pressing tab), autocomplete doesn't automatically fill in quotes for you for filenames with spaces, and "clear" just prints some blank lines instead of actually clearing the screen, apparently thinking it is outputting to an old terminal without scroll features. And then there is lack of support for line-drawing characters everywhere. And the people responsible for this mess try to make a display server lol.

Re:See Saw Cycles of Adoption and Abandonment

[Anonymous Coward]

No, you already have the choice. The GP is right. 18.04 LTS means that Ubuntu is going to have to support the default choice for 5 years. Rather than having to risk maintaining Wayland for five years if development goes south, they've went for the more stable, long-term option. Also, to avoid the risk of having to switch to X.Org midway through the 5 year LTS if development goes really south, they've decided to do it preemptively.

I think they may have learned their lesson with Unity.

Re:See Saw Cycles of Adoption and Abandonment

[Cyberax]

Oh please do shut up. X.org codebase is a steaming pile of single-threaded shit that needs to be patched up from 10 different directions to be even able to deal with modern graphics. It's so full of security holes that it doesn't even make sense to look for them.

Re:See Saw Cycles of Adoption and Abandonment

[Anonymous Coward]

Even the CLI of linux isn't all that great IMO.

I can already tell this is going to be a great list of well-reasoned complaints and not just a description of default behaviors that work well for most people but can be changed if desired.

You don't get rolodex autocomplete (where you can cycle through the suggestions by pressing tab)

This is determined by your shell. Personally, I hate this kind of autocomplete. If that's your thing, you might want to look into zsh (and might I suggest Oh My Zsh as well).

autocomplete doesn't automatically fill in quotes for you for filenames with spaces

That's because it doesn't need to. At least in bash, which I assume is the shell you're using, it escapes characters that need to be escaped, so if a filename contains spaces they will be filled in preceded by a backslash.

"clear" just prints some blank lines instead of actually clearing the screen, apparently thinking it is outputting to an old terminal without scroll features

clear does actually clear your screen, unless you're using an old terminal without scroll features. From man clear:

clear clears your screen if this is possible, including its scrollback
buffer (if the extended "E3" capability is defined). clear looks in
the environment for the terminal type and then in the terminfo database
to determine how to clear the screen.

In my terminal, clear clears my screen and resets my cursor to the top line, just like a newly-opened window would look.

And then there is lack of support for line-drawing characters everywhere.

[citation needed]. I haven't run into support issues with line-drawing characters in years.

Re:See Saw Cycles of Adoption and Abandonment

[CRB9000]

Are you telling me that Linux users are not smart enough to make the changes they want? I've been hearing the exact opposite for ages about why Linux users are freakin' geniuses for their ability to do just that. The "Tyranny of the Default" does not apply to Linux users by definition of the term "Linux User".

Re:See Saw Cycles of Adoption and Abandonment

[rahvin112]

Mod parent up.

Re:See Saw Cycles of Adoption and Abandonment

[Viol8]

Yeah, its so easy to hack thats why it's hackers favourite attack vector into *nix systems. Oh, wait...

Re:See Saw Cycles of Adoption and Abandonment

[rahvin112]

No you can't. When you run Xorg on your modern computer you are using about 8% of the code base, all the rest of that codebase is still sitting there in the binary waiting for a security hole that NO ONE is looking for.

The people that developed Wayland are the same people that developed X86. They realized before they started the Wayland project that the x86 code base is such a nasty pile of hacks and shit that's not used anymore that it's simply impossible to move forward without a total rewrite because it would take 10 times longer to try to fix that pile of shit than rewrite it from scratch with a proper modern design.

Re:See Saw Cycles of Adoption and Abandonment

[Cyberax]

X server normally is accessible only locally through Unix domain sockets or through SSH tunnels bound to localhost. And if an attacker gets access to the X connection then they already own you.

Re:See Saw Cycles of Adoption and Abandonment

[Lord Kano]

I disagree. If they were totally abandoning Wayland, then you'd have a point. They simply saying, "Hey! Look! Choice! Yay us."

Like they did with systemd, right?

LK

Re:See Saw Cycles of Adoption and Abandonment

[Uecker]

The code is actually not bad in my opinion and due to its age, a lot of problems have already been fixed a long time ago. Ilja von Sprundel (just featured in another story on slashdot) did some auditing a couple of years ago and fixed many bugs. He gave a talk about it on the CCC conference and he seemed actually quite fond of X from a security perspective (quotes: "the developer involved actually amazing" and about the core protocol "this code is actually pretty cool (from a security perspective) you can see where the code got patched over (e.g. integer overflow checks)") . In fact, he seriously complained about clients and in particular about Qt/KDE in this talk. This is a much newer code base...

Re:See Saw Cycles of Adoption and Abandonment

[Anne Thwacks]

is a pretty obvious statement that Wayland is a long way from being ready for prime time.

Au contraire, mon frere

Ubuntu has a strong track record of deliberately choosing things that are not ready for prime time - the move back to X is probably an indication that Wayland is finally stable.

Re: See Saw Cycles of Adoption and Abandonment

[chill]

This isn't Linux, it is Ubuntu. :-P

Re:See Saw Cycles of Adoption and Abandonment

[Uecker]

The idea that X has been abandoned for Wayland by its own developers is a myth. Even a brief look at the relevant mailing lists makes it absolutely clear that this is far from the truth.

Re:See Saw Cycles of Adoption and Abandonment

[Anonymous Coward]

After this post and the high moderation it got, I'm pondering about other kinds of abandonment...

Re:See Saw Cycles of Adoption and Abandonment

[Cyberax]

I worked on X codebase and I know it's shit. It's a patched-over shit, but still. Integer overflows, memory corruption, it has everything.

But even setting this aside, X.org is insecure by design. Any application can just send any events to any other application, so there's no point in trying to make it secure. If you have access to an X connection then you already have full access to the user's data. For example, you simply can inject "ctrl-t" into the shell to launch a terminal and then inject any commands you want into it.

And about "todays wonder boys" - Wayland is designed and written mostly by the same developers who are working on X.org

Re:See Saw Cycles of Adoption and Abandonment

[Anonymous Coward]

Quoting rules can be byzantine or you might want to do your own quoting. I like that the tab completion teaches you how to escape your spaces and apostrophes with a backslash.
Now maybe some things are silly but Windows got stuck for decades thinking it's 80-column CP/M with DOS character encoding (not even the same as in GUIs like explorer and notepad) which amusingly turned out worse than supporting ttys that predate microprocessors, SRAM and DRAM.

Re:See Saw Cycles of Adoption and Abandonment

[Uecker]

I worked on X codebase and I know it's shit. It's a patched-over shit, but still. Integer overflows, memory corruption, it has everything.

.What did you work ont?

But even setting this aside, X.org is insecure by design. Any application can just send any events to any other application, so there's no point in trying to make it secure. If you have access to an X connection then you already have full access to the user's data.

Any application on the same host can hijack any other even without X. Ever used a debugger? Wonder how it works? For remote, you have point. There is a solution: Untrusted X Clients. I would need a bit of work, and I would rather prefer people fixing these minor things instead of rewriting everything.

For example, you simply can inject "ctrl-t" into the shell to launch a terminal and then inject any commands you want into it.

You can do this without X.

And about "todays wonder boys" - Wayland is designed and written mostly by the same developers who are working on X.org

Not really, most X developers seem to still work on X and not on Wayland (Packard, Coppersmith, ...)

Re:See Saw Cycles of Adoption and Abandonment

[JesseMcDonald]

You don't get rolodex autocomplete (where you can cycle through the suggestions by pressing tab)

This is determined by your shell.

Or if you don't want to change shells, just bind Tab to the menu-complete command (in ~/.inputrc, or with the command: bind "Tab: menu-complete"). Presto, pressing Tab now cycles through all the possible matches.

autocomplete doesn't automatically fill in quotes for you for filenames with spaces

That's because it doesn't need to. At least in bash, which I assume is the shell you're using, it escapes characters that need to be escaped, so if a filename contains spaces they will be filled in preceded by a backslash.

But sometimes you don't want backslashes in the completion. No problem: the completion will respect whatever quoting style was already started.

Anyone who does significant work in Bash really should read through the manual page some time. There are a lot of useful features available beyond the basics "everyone" knows about.

Re:See Saw Cycles of Adoption and Abandonment

[Cyberax]

I worked on the input stack.

Except that in X there can be multiple applications at different privilege levels. That sudo in an X terminal? Totally vulnerable for an application that runs in a browser and has somehow gained access to the X socket. Never mind that ptrace() can be effectively limited through a multitude of methods (LSM, namespaces, caps).

Re:See Saw Cycles of Adoption and Abandonment

[CRB9000]

So you say you produced shit code? That your work product was shit? Hell of a thing to admit.

Re:See Saw Cycles of Adoption and Abandonment

[Cyberax]

I worked on an input driver for a complicated device. The code in the X-server that I had to interact with was total garbage. It was designed in 80-s and patched to at least try supporting anything more modern than a Space Cadet keyboard.

For example, X.org is single-threaded so it doesn't need synchronization. Except that it isn't. Signal handlers for input devices can whack the cursor state directly. And if you want to do a device handover so an application can take exclusive ownership of a device you'll have to do a lot of interesting contortions.

Re:See Saw Cycles of Adoption and Abandonment

[Uecker]

I worked on the input stack.

I have to admit that I never looked at this part. It must be bad considering that this is where most prominent wayland developers also came from.

Except that in X there can be multiple applications at different privilege levels. That sudo in an X terminal? Totally vulnerable for an application that runs in a browser and has somehow gained access to the X socket.

I pointed out the solution: X clients could be isolated against each other. This would require some work, but the fundamental parts to make this work exist in X already for a long time.

Never mind that ptrace() can be effectively limited through a multitude of methods (LSM, namespaces, caps).

Wake me up if any Linux distribution ships with proper isolation between different programs from the same user. There are many issues and not just ptrace or X. And no, I do not see rewriting everything again and again in incompatible ways as an ideal strategy towards a solution.

Re:See Saw Cycles of Adoption and Abandonment

[Cyberax]

I pointed out the solution: X clients could be isolated against each other

No, they can not be isolated. X.org is shared across all clients and it can't be changed without re-architecting it. Attempts to do it (XAce) died ignominiously. You'll need to introduce multiple independent X servers and a layer above them to orchestrate input devices and access to direct rendering. In short, you'll get Wayland.

Wake me up if any Linux distribution ships with proper isolation between different programs from the same user.

Ding! Wake up call! Ubuntu does it quite well with snaps.

Re:See Saw Cycles of Adoption and Abandonment

[Uecker]

I pointed out the solution: X clients could be isolated against each other

No, they can not be isolated.

Why not? The necessary hooks seem to be all there. Untrusted X Clients are isolated against trusted X Clients. This seems to work.

X.org is shared across all clients and it can't be changed without re-architecting it.

A wayland shell would also be shared by its clients, or? With the security hooks already there, why is there are need for re-architecting?

Attempts to do it (XAce) died ignominiously.

True, but without proper access isolation for processes with the same UID, there was also no point.

You'll need to introduce multiple independent X servers and a layer above them to orchestrate input devices and access to direct rendering. In short, you'll get Wayland.

I don't mind splitting up X or re-architecting parts of it (although I do not quite see why you think it is needed - we also have a monolithic kernel). The main problem I have with Wayland is that it breaks compatibility with the wire-protocol without a good reason.

Wake me up if any Linux distribution ships with proper isolation between different programs from the same user.

Ding! Wake up call! Ubuntu does it quite well with snaps.

Well, if they can interact, then isolation is difficult and somehow I doubt they have solved this completely, and if they can not really interact, they are useless.... The other issue with Snap packages is that seem to come bundled with their own libraries. This seems to be a security nightmare.

Re:See Saw Cycles of Adoption and Abandonment

[Cyberax]

Why not? The necessary hooks seem to be all there. Untrusted X Clients are isolated against trusted X Clients. This seems to work.

Who told you this nonsense? X.org doesn't have any real distinction between clients. They are all similarly "trusted".

There's a thin veneer of SECURITY and XAce extensions which are not used by anybody. They are not even build-enabled in Debian and CentOS. They are also utterly inadequate, for example, SECURITY extension puts all "untrusted" clients together as there's no per-client isolation and doesn't prevent all sniffing.

A wayland shell would also be shared by its clients, or? With the security hooks already there, why is there are need for re-architecting?

Wayland clients don't have access to each other without shell explicitly granting capabilities to do it. They _might_ have access to the shell but it's easy to isolate. For example, a browser application can be limited only to submitting requests for direct rendering manager and to reading its input stream.

I don't mind splitting up X or re-architecting parts of it (although I do not quite see why you think it is needed - we also have a monolithic kernel). The main problem I have with Wayland is that it breaks compatibility with the wire-protocol without a good reason.

Run XWayland for perfect backwards compat. Problem solved.

Well, if they can interact, then isolation is difficult and somehow I doubt they have solved this completely, and if they can not really interact, they are useless....

Solved: https://github.com/snapcore/sn...

Re:See Saw Cycles of Adoption and Abandonment

[Anonymous Coward]

Both sides are right. I've written a couple DDX drivers at this point, and the code is beyond ugly. Having said that, I've come to recognize there is an enormous amount of value in a codebase that while ugly, has both 40 years of development and 40 years of testing. Scrapping it and solving all the worlds problems in an elegant way is the good intention of every rewrite, but once it has to work the same way, you start to realize that the ugliness is inherent to the problem, and edge cases abound in graphical user interfaces, especially when you are at the layer of the hardware talking to the upper level APIs. I'm a fan of Wayland, and have a lot of confidence that it will be successful, though a lot of that confidence comes from it being the Xorg guys.

Re:See Saw Cycles of Adoption and Abandonment

[DrXym]

Not even that - they're defaulting to X in the LTS release. It's the people paying for LTS support who are conservative rather than Ubuntu. Maybe it cuts down on a few support tickets. I doubt Wayland is going anywhere, or that come 18.10 it'll back to being the default again

Re:See Saw Cycles of Adoption and Abandonment

[Viol8]

I guess you don't know about port 6000 then. Was open by default for years. I don't remember it being a major attack entry point.

Re:See Saw Cycles of Adoption and Abandonment

[dakra137]

How could 40 year old code be written for a processor that was announced 32 years ago? https://en.wikipedia.org/wiki/Intel_80386

Re:See Saw Cycles of Adoption and Abandonment

[KozmoStevnNaut]

Research shows that users don’t actively want every ad to be blocked

The fuck are they talking about? Get that shit out of here. I visit web pages for the content, not the ads. If your page need ads to survive, maybe it's better off dead.

Re:See Saw Cycles of Adoption and Abandonment

[sjames]

If that was the case, they wouldn't be switching the default BACK to X. They would never have made Wayland the default at all. If they were feeling especially sour about it, Wayland wouldn't have even been an option.

The problem is Wayland, like most of Freedesktop has been all about claiming "nobody uses that anyway" and then when throngs of people report that they DO, long on promises like "you'll be able to do that again real soon now" and short on delivery.

The same sort of nonsense is what caused Mozilla to slingshot Chrome into the lead.

Re:See Saw Cycles of Adoption and Abandonment

[Anonymous Coward]

Ubuntu mainline LTS is supported for 5 years, not 3 years. You probably was thinking about some Ubuntu flavors LTS, Kubuntu 16.04 LTS is only supported for 3 years for instance.

Re:See Saw Cycles of Adoption and Abandonment

[Anonymous Coward]

Xorg and Wayland are made by the same developers idiot.

Re:See Saw Cycles of Adoption and Abandonment

[Cyberax]

You have port 600X open on a network-facing interface (i.e. not localhost)? Yeah, lol.

Re:See Saw Cycles of Adoption and Abandonment

[Gr8Apes]

Well, it's a bit more than that....It's not 'wayland will *never* be better', but it is a statement that it has a ways to go, and some of the limitations are design choices that will require interesting conversations, particularly about security with regards to screen sharing.

Let me be more clear then: Wayland is not better and will not be better, because it missed the boat on some key fundamentals such as security. To quote others, security cannot be bolted on at the end and be expected to work well. We can give MS as a prime example of that approach.

Re:See Saw Cycles of Adoption and Abandonment

[Uecker]

Why not? The necessary hooks seem to be all there. Untrusted X Clients are isolated against trusted X Clients. This seems to work.

Who told you this nonsense? X.org doesn't have any real distinction between clients. They are all similarly "trusted".

There's a thin veneer of SECURITY and XAce extensions which are not used by anybody. They are not even build-enabled in Debian and CentOS. They are also utterly inadequate, for example, SECURITY extension puts all "untrusted" clients together as there's no per-client isolation and doesn't prevent all sniffing.

Yes, that could easily be changed by also separating untrusted clients from each other. I once had a proof of concept patch doing exactly that and it was very simple... It wasn't too useful as untrusted clients also can't use render and other important extensions. This also seems easily changed.

A wayland shell would also be shared by its clients, or? With the security hooks already there, why is there are need for re-architecting?

Wayland clients don't have access to each other without shell explicitly granting capabilities to do it. They _might_ have access to the shell but it's easy to isolate. For example, a browser application can be limited only to submitting requests for direct rendering manager and to reading its input stream.

Ok, so it starts from the other direction. So what? It isn't clear to me why - once all desired features and extensions have been added - the end result would be any better than what could be achieved by using isolated untrusted clients on X.

I don't mind splitting up X or re-architecting parts of it (although I do not quite see why you think it is needed - we also have a monolithic kernel). The main problem I have with Wayland is that it breaks compatibility with the wire-protocol without a good reason.

Run XWayland for perfect backwards compat. Problem solved.

So we now have to maintain both X and Wayland. Wow, Genius!

Well, if they can interact, then isolation is difficult and somehow I doubt they have solved this completely, and if they can not really interact, they are useless....

Solved: https://github.com/snapcore/sn...

"Since many of the underlying technologies in these environments were not designed with strong application isolation in mind, users should only install applications using these interfaces from trusted sources." Solved?

Re:See Saw Cycles of Adoption and Abandonment

[Cyberax]

It wasn't too useful as untrusted clients also can't use render and other important extensions. This also seems easily changed.

Not really. There's no accounting for buffer space, for example, or throttling for command streams in X.org. So one misbehaving client can still bring down everything. You can rewrite X.org completely from scratch using async primitives and threadsafe code everywhere. Sure. No problem at all.

Ok, so it starts from the other direction. So what? It isn't clear to me why - once all desired features and extensions have been added - the end result would be any better than what could be achieved by using isolated untrusted clients on X

The X.org codebase is crap. It can't be patched indefinitely, its core design is basically broken to be useful in a modern environment. The fact that somebody bothered to fake it with "security" extensions doesn't change it.

So we now have to maintain both X and Wayland. Wow, Genius!

With XWayland you can have each application running its own private crappy version of X.org.

"Since many of the underlying technologies in these environments were not designed with strong application isolation in mind, users should only install applications using these interfaces from trusted sources." Solved?

Yep. Ubuntu snaps are as good as containment mechanisms in Linux (i.e. not that good at all).

Re:See Saw Cycles of Adoption and Abandonment

[Uecker]

It wasn't too useful as untrusted clients also can't use render and other important extensions. This also seems easily changed.

Not really. There's no accounting for buffer space, for example, or throttling for command streams in X.org. So one misbehaving client can still bring down everything. You can rewrite X.org completely from scratch using async primitives and threadsafe code everywhere. Sure. No problem at all.

Adding accounting for buffer space or throttling doesn't sound like major issues and I do not see why one would need to rewrite everything to add this. Not that this is the most pressing issue with modern desktop GUIs. I have not had a client bring down or hang X for a very very long time (and when this last happened years ago, this was a graphics driver issue). In contrast, those idiots rewriting everything have cost me hours or productive time by breaking the user interface of perfectly working tools again and again in the last decade.

Ok, so it starts from the other direction. So what? It isn't clear to me why - once all desired features and extensions have been added - the end result would be any better than what could be achieved by using isolated untrusted clients on X

The X.org codebase is crap. It can't be patched indefinitely, its core design is basically broken to be useful in a modern environment. The fact that somebody bothered to fake it with "security" extensions doesn't change it.

Again, the code base looks very reasonable to me. I have seen much worse. Please do not spread FUD. The core design is also not broken. In fact, the Wayland FAQ itself states: "It's entirely possible to incorporate the buffer exchange and update models that Wayland is built on into X" (and with present and DRI3 this has in fact already been done). So obviously, there is no fundamental problem with core X which would prevent such things as you incorrectly seem to believe.

So we now have to maintain both X and Wayland. Wow, Genius!

With XWayland you can have each application running its own private crappy version of X.org.

I can't find any real argument here. Your wording suggest that your judgement is a bit clouded by emotions. Having applications run their own copies of X will break useful communications mechanisms between different applications.

"Since many of the underlying technologies in these environments were not designed with strong application isolation in mind, users should only install applications using these interfaces from trusted sources." Solved?

Yep. Ubuntu snaps are as good as containment mechanisms in Linux (i.e. not that good at all).

Linux has excellent containment mechanisms. But the existence of this mechanisms does not imply that applications do not need to communicate or interact anymore, which needs careful consideration and design of safe APIs. I do not see how snaps solve this problem. Snaps also prevent centralized security fixes to libraries. This is the reason we abandoned static libraries a long time ago. This is not progress.

Re:See Saw Cycles of Adoption and Abandonment

[angel'o'sphere]

I answer here, because your coal threat is closed.
The 'Energiewende' did not start 2009, how do you come to that braindead idea?
It started around 1985. Probably earlier.
2009 was an exceptional low 'CO2 emmiting year' because of the super heat, which caused Germany to shut down many coal _and_ nuclear plants and import lots of power.
Using outliers for arguments is simply plain dumb, sorry.
The trend is clear, 30% reduction in coal usage.
Far over 30% increase in renewables.

If you want to spread lies anout the topic, up to you.

17.04 will be lts, so yeah, stay with stable stuff

[Anonymous Coward]

ive had some fun time trying to resize wayland screens within a vm guest, does anyone else got that one working? xrandr being not an option (as choosen by the wayland devs) i wonder whats the alternative, if theres any.

not to mentoin that my synaptics laptop touchpad wouldnt work when installing 17.10 on my laptop, cause, well, theres a synaptics x server, just not for wayland, but maybe there is, but it doesnt come enabled by either default or a system check before install if thats even beind done this days...

im totally for new stuff, gotta fix it first though.

But but ....

[Viol8]

... the Wayland devs kept telling us that no one cares about remoting with X which is why they hardly bothered to work on that side of it. Were they wrong?? Say it ain't so!

Re:But but ....

[KiloByte]

I guess that's just a hard to discover easter egg, like mouse paste.

Re:But but ....

[Anonymous Coward]

That's quite a shortcoming. Not only is it much too easy to do it accidentally. It's simultaneously too hard to do it on purpose.

Re:But but ....

[jbernardo]

Or like being incapable of running GUI apps as root - which breaks among others gparted, and won't ever be fixed for native Wayland apps, but you need to "think of the children" - https://bugzilla.redhat.com/sh...

Re:But but ....

[Junta]

Actually, for executing a remote application, Wayland can accomodate with Xwayland.

Here the thing is sharing your screen, like in a teleconference situation or accessing your whole screen remotely rather than X forwarding which Wayland can't accommodate, in part due to intentional design decisions to mitigate security risks.

Re:But but ....

[Anonymous Coward]

They weren't wrong, blasting pixels across the web just because either a) you don't know how to do what you want from the CLI or b) the stupid "app" you are using didn't build in any properly networking capability, is a shitty way of doing things and shouldn't be encouraged. If you really do need a visual output from a remote process there are virtual frame-buffers. For people who don't know how to use computers, there's windows where X or wayland will never exist anyway.

Re:But but ....

[LiENUS]

Or like being incapable of running GUI apps as root - which breaks among others gparted,

I literally ran gparted a few days ago under wayland. It was a minor pita but it is very doable.
http://ubuntuhandbook.org/index.php/2017/10/ubuntu-17-10-tip-graphical-apps-doesnt-launch-via-root-sudo-gksu//

xhost si:localuser:root

was all I meeded

Re:But but ....

[Anonymous Coward]

"gparted should not run its UI as root. It should run its UI as a regular user and use PolicyKit or something else similar to gain elevated privileges only when necessary to query or modify devices"

I'm all about being angry, but this makes sense. root only when needed, we don't need root for the UI.

Re:But but ....

[Anonymous Coward]

This is not a 'weakness' of Wayland, it's a weakness of gparted (and other graphical applications that try to run as root). gparted should not run its UI as root. It should run its UI as a regular user and use PolicyKit or something else similar to gain elevated privileges only when necessary to query or modify devices.

idk, that seems reasonable to me.

Re:But but ....

[jbernardo]

I know of that workaround, but it is all it is, a workaround. The fact that you need it in Wayland is a consequence of its lack of support for running GUI apps as root. And it won't work for native apps,only for X apps.

Re:But but ....

[thegarbz]

... the Wayland devs kept telling us that no one cares about remoting with X which is why they hardly bothered to work on that side of it. Were they wrong?? Say it ain't so!

Not at all. Remote desktop was always important to a subset of users that were not at all targeted by Wayland. Those same users happen to also be the ones who would use LTS releases of Ubuntu.

If you read the original post they will use Wayland as defaults on all other releases and specifically rushed Wayland to 17.10 to gauge if it will be a default in 18.04LTS. But there are some features that need to be worked on before it will be suitable for LTS release.

But by all means smug on.

Re:But but ....

[jbernardo]

"gparted should not run its UI as root. It should run its UI as a regular user and use PolicyKit or something else similar to gain elevated privileges only when necessary to query or modify devices"

Why? Because Wayland devs decided the UI should not run as root? Because breaking functionality in the name of a misguided sense of security is fashionable?

Re:But but ....

[serviscope_minor]

I guess that's just a hard to discover easter egg, like mouse paste.

No, fuck you, we ARE going to turn Linux into a cheap half-arsed knockoff of Windows 95, uhhh Windows XP, er I mean OSX.

Screw anyone who actually uses it. We HAVE to assume that the only way of getting The Year Of The Linux Desktop is to make it a crap version of everything else out there.

Re:But but ....

[thegarbz]

but you need to "think of the children"

Actually I think it's more like "think of the security hole". I can't say I disagree with the fact that old software should use the modern way of interacting with a modern system if it wants to work for users.

Expecting full backwards compatibility for everything for ever just invites any script kiddy to take over your computer. It's amazing how we're progressive about protocol adoption and depreciation in Linux, ... until it comes to some GUI application that hasn't gotten its act together in the past several years.

Re:But but ....

[Anonymous Coward]

At last, someone thought about those poor MacIntards.

Re:But but ....

[jbernardo]

What security hole? I'm more worried about my user data than about some imagined security hole, and blocking root apps won't protect the user data.

Obligatory xkcd - https://xkcd.com/1200/

Re:But but ....

[Anonymous Coward]

Expecting full backwards compatibility for everything for ever just invites...

It also requires an army of developers to be feasible, ah la Microsoft. On the other hand, tearing up the floorboards on gparted, virt-manager, etc. (several programs are mentioned in the linked bug) also requires a lot of development.

Software is hard.

Re:But but ....

[serviscope_minor]

x host si:localuser:root

was all I meeded

So all you needed to get Wayland to work properly was... X.

Re:But but ....

[Anonymous Coward]

It doesn't stop there, there's such a thing as "XWayland" which most your stuff will use anyway.

There is a lazy workaround too : ssh -X root@localhost
(confirmed by some random guy on a forum. I can't be arsed to install gnome 3)

Re:But but ....

[Eluan]

Few middle mouse buttons in the world? I've not seen a mouse without a middle button (hint: the scroll wheel is a middle button) in more than twenty years!

Re:But but ....

[Anonymous Coward]

I think similar things occasionally happen on a Xorg system. e.g. run a file manager as root and you might be lacking contexts for USB devices or network mounts or trash can etc. that are available to the user mode file manager that sits right next to it, and that's a significantly more complex issue.

Re:But but ....

[Anonymous Coward]

No because every sane person ever decided that you should not run any UI as root.

Re:But but ....

[thegarbz]

What security hole?

The one they fixed through the introduction of polkit to allow fine grained access control to the system. If you don't understand why Polkit exists and why it's preferred I don't expect you'll ever understand the security aspects of what Wayland specifically avoids here by design.

Re:But but ....

[thegarbz]

And by "work properly" you mean back track an architectural choice that has been pushed for security reasons for the past 3 years.

Man if you people were around when sudo was adopted you'd still be suggesting everyone log in as root.

Re:But but ....

[jbernardo]

Wooosh......

Re:But but ....

[rahvin112]

This is absolutely incorrect.

Remote desktop was always going to happen on Wayland, the dev's just didn't want it baked right into the protocol where it would cause all the same problems it's caused on xorg over the last 20 years. There was a wicked misunderstanding between users and the devs and yes it was probably the dev's fault, but they always intended for their to be remote desktop capability, just not baked into the protocol where it doesn't belong.

Re:But but ....

[Anonymous Coward]

Or like being incapable of running GUI apps as root

Good grief. If you design an application that requires root to run the UI, you deserve to have it break. Literally the rule of root should be, use me for 15 ms and then stop using me. If your application needs root, 10-15ms touches of root not 100% of the time the application is running you're root, should be the rule. gparted is insecure and it should be called out as such. Anyone not seeing the semi sized hole you punch in security by that is blind or just itching for mudslinging. You never run anything as root, period. If you need to violate that rule, you do it as absolutely few times and as absolutely short as possible. Every graphical package manager issues as few possible "apt" or "dnf" commands as possible, allows you to select a list of things you want in an insecure environment, and once you're ready to commit, it then issues the "sudo apt" "sudo dnf" commands in one short go and let you know how it went. Short, concise, purpose driven usages of root and not a touch more.

Re:But but ....

[Greyfox]

Yuh huh. They also don't mention that the Nvidia drivers don't work with Wayland. They put an optimistic "yet" at the end of that. First thing I ended up doing in The Big Upgrade of a couple of machines a few days ago was force X.org sessions in GDM so I could get 3D acceleration. Remote windows? Don't tend to use 'em here, but have in the past and do consider it important.

Re:But but ....

[Anne Thwacks]

No because every sane person ever decided that you should not run any UI as root.

But what if you are root, and want a GUI?

Or does your system administration never do anything more complex that a single DOS command?

Re:But but ....

[Uecker]

What is the fundamental problem with remote?

You have to understand that any efficient graphics system today has to treat buffers as remote anyway, as they live on the other side of the PCI bus on a discrete GPU. It is also therefor not too surprising that both Wayland and X are in fact very similar in how graphics is done with modern clients. There is no fundamental difference. Wayland just lacks a lot of functionality compared to X and is not backwards compatible.

Re:But but ....

[Anne Thwacks]

If you have a supercomputer visualising its enormous mass of data, you might want to display the visualisation in another building in another country

Some people are not working on home computers!

Re:But but ....

[arth1]

Man if you people were around when sudo was adopted you'd still be suggesting everyone log in as root.

Log in with the user/group with the least amount of privileges needed to do the job. Create new users/groups/permissions/contexts if needed. sudo is privilege escalation, which is made for convenience, is inherently insecure and leads to exploits. I don't have sudo on my systems, for security reasons. Privilege escalation is the Windows way of doing things, while the Unix way is to only drop privileges, not escalate them.

Re:But but ....

[tepples]

In general, each process should operate with the least possible privilege. Windows went through this in 2007 when Windows Vista cut off services' ability to display a GUI. Splitting it into a GUI to parse (possibly untrusted) user input and a worker to do the actual work, with a narrow communication channel between the two, makes it less likely that an inadvertent flaw in the GUI will cause problems in the elevated part.

Re:But but ....

[Anonymous Coward]

Screw anyone who actually uses it. We HAVE to assume that the only way of getting The Year Of The Linux Desktop is to make it a crap version of everything else out there.

No, the main drive behind this isn't "crap", it's "centralized control" something that the OSS community fears and lashes out against.

You won't get a "Year Of The Linux Desktop" if every single computer in a company it runs on has to have a distro specific script run manually on each system to remedy a config issue. You won't get that year if network users can't do something as basic as mount a thumbdrive, or use a scanner without being manually added to the local shadow / groups file. You won't get that year if people have to constantly check what they have installed to know what how to guide to follow.

In short, the issue is lack of convenience and complexity of maintaining it. Sure you have a software repository with a built-in to the OS standard management tool, but that's where the ease of use stops, and the difficulties begin. There's no such authoritative tools anywhere else, instead you have a handful of half baked tools to manage their specific configs, and maybe a few others. But try to do something as simple and as common as change the desktop wallpaper, and you'll see real quick all of the corner cases and intrinsics you'll need to consider when writing that one-size-fits-all bash-scripted (or zsh, or busybox?) solution. It's a mess.

Ever try doing help desk with a clueless linux user? At least with Windows you can kind of feel around over the phone to figure out what the user is doing and what they've set up / installed, under your average linux distro, you're clueless. Heck in some cases even lsb_release isn't installed by default. So you can't check the distro or it's version / codename without doing more guesswork. Have fun figuring out the bugs when you can't even figure out the os version easily.

Your average linux distro is too cumbersome to use by most people, but in an office environment, it's even worse. Imagine 10,000 machines that need to have the company wifi password changed, or have an internal CA certificate installed and trusted by the installed browsers. In the case of the wifi password, you can't push a wifi profile, you'd need to first figure out whether or not ifup or NetworkManager is installed, then you'd either need to locate and replace the ifcfg file for the connection (have fun with that consistent device naming again, hope your devices are all perfectly identical...) or write the nmcli commands to execute in a script file. In the case of the CA cert, your first question would be "is some variant of update-ca-certificates / update-ca-trust installed?" Then the next one (assuming the answer to the first one was yes), would be "does it actually work with Chromium / Firefox / etc?" If the answer to that is yes, (good luck with those odds) then you drop the cert in the proper directory and run the update util. If the answer to either of those questions was no, then you get to either try to configure p11-kit-trust.so or have to manually edit the browser's nssdb, then manually fix the other OS apps (openssl, curl, wget, etc.) yay.... Oh did I mention puppet? Oh I didn't because it's free version (much like every other automated solution for linux config management), requires a programmer on staff to maintain it, while the GUI that the windoze admin needs costs money? (Good luck with that if you got linux in the door because it was "free".) How impotent of me, I apologize. Not.

You might manage this on your own systems, but for the vast majority out there, the average linux distro is far too complex for them to manage sanely. They need a one-stop shop to get things done. The OSS community's attitude of "if you don't like it, fork it and maintain it yourself" however, prohibits a solution from being made. Every attempt at a solution is chastised and ridiculed by pretty much every leader in the community to some extent. Meanwhile, those that need th

Re:But but ....

[LiENUS]

So all you needed to get Wayland to work properly was... X.

I mean at this point pretty much all of the wayland apps are already using X

Re:But but ....

[LiENUS]

I know of that workaround, but it is all it is, a workaround.

Typically for legacy apps one uses workarounds.

And it won't work for native apps,only for X apps.

You're absolutely right, it only works for poorly designed apps. Properly designed apps use polkit and the workaround isn't needed. So whats your complaint?

Re:But but ....

[LiENUS]

And by "work properly" you mean back track an architectural choice that has been pushed for security reasons for the past 3 years.

It's a work around for shitty apps from people stuck in the old ways or that just haven't been updated yet.

Man if you people were around when sudo was adopted you'd still be suggesting everyone log in as root.

It's pretty funny you say that since the whole thread got started by a guy with just that attitude. The people pushing wayland are saying "hey, check it out polkit is better than sudo"

Re:But but ....

[_merlin]

I manage all my RHEL and CentOS servers with no GUI, and I've never had a problem. Also, privilege separation is a thing. The more stuff you run elevated, the more chance of an exploit. A UI toolkit is a huge attack surface. Better to just run the parts that need elevated privileges as root and keep the GUI running as a regular user.

Re:But but ....

[serviscope_minor]

You won't get a "Year Of The Linux Desktop" if

We're not getting the year of the linux desktop either way. Seeing linux shipped by default on a significant minority of laptops and desktops? Not happening.

So, these quixhotic attempts to create such a year by destroying everything the current users like about the desktop is going to make things worse, not better.

And, if you're running an office without some kind of remote admin stuff installed so you can sutomatically roll out policy changes of some sort then you've fucked up whether you're runing Linux or Windows.

Look, I love my linux desktop. I think it is the best one ever. If the GNOME folks get their way and destroy it (the middle mouse button is not a FUCKING easter egg you arseholes), all we'll have is a nice OS with a shitty desktop. We will never have a mainstream one and that's OK. My tastes are strange and I accept that.

Re:But but ....

[jon3k]

I don't think so, I think it's more about application compatibility or just general maturity.

Re:But but ....

[chapstercni]

(Serious question here, as I am only a user.)

Instead of 'sudo', but about just 'su' ? So instead of using sudo to do something, I su to the needed user, do that thing with the necessary privilege, then switch back to my regular user/whatever?

Re:But but ....

[arth1]

Instead of 'sudo', but about just 'su' ? So instead of using sudo to do something, I su to the needed user, do that thing with the necessary privilege, then switch back to my regular user/whatever?

If you do "/bin/su -" (including the hyphen), it's safer. You then don't inherit any of the environment that you do with just "su", and don't risk running a different su that someone who hacked your account might have left there.

And yes, it's IMHO much safer than sudo because there's no privilege escalation. Knowing your own password should not be enough to get root access. It's much easier for a hacker to hack any of the user passwords that has sudo access than it is to hack just the root password. And if an admin changes the root password, that doesn't stop sudo users.

That around a third of the Linux rootkits attempt to exploit sudo isn't because sudo is so securely designed and implemented. In general, anything that adds convenience will reduce security.

Of course, closing login sessions when done with them should be done no matter what the user is. Don't leave them open because it's convenient.

Re:But but ....

[chapstercni]

Thank you, Arth1

Re:But but ....

[sjames]

That's a funny thing. Most of Wayland's fan's claims for workarounds hinge on apps continuing to support X. I guess the easiest way to make sure of that is to use X.

Perhaps Wayland should just formally make itself a next generation X server and be done with it.

Re:But but ....

[sjames]

What forever? Wayland is barely used. You sound like it's been the dominant GUI display for 5 years.

Re:But but ....

[sjames]

Even if you're in the same facility, you probably don't want to squint at a rack mounted LCD display in a room that sounds like it's full of angry bees.

Re:But but ....

[benjymouse]

Privilege escalation is the Windows way of doing things

Nope. Windows does not escalate any privileges. When you log in it creates *two* tokens, one for regular use and one for "elevated" processes. Windows *never* escalates to "root " (or the equivalent "system" on Windows) only to drop down. The "elevated" token is simply the default user token. The "normal" token - the one used for all processes by default - is the user default token stripped for any administrative or super privileges. So even if the user is a member of the local administrators group, the normal user token describes a user *without* this group - and consequently without administrative permissions/privileges.

This is because Windows has proper fine-grained tokens instead of the stupid 70-era byte-saving Unix way of "effective userid" coded in a single word. It does not need to "escalate".

In fact, every process under Windows can has its own token. This *may* be a copy of the user token or it may be more restricted. A so-called "elevated" process is simply a process started with the user's non-stripped token. Under windows, there is no equivalent feature to SUID. As a user you simply cannot start processes as other users without providing full credentials (username/password). You cannot start *any* process as "System" because the system account is not allowed to run interactively.

Finally!

[Anonymous Coward]

It's about time!

Yawn

[Anonymous Coward]

Wake me when it also includes APK Hosts File Engine by default. I canâ(TM)t even find it in any Linux repos.

In fact, never mind. Iâ(TM)ll just stick to the Windows master OS.

Now...

[Anonymous Coward]

... if we can just get an Ubuntu without systemd based on Devuan instead of Debian!

Re:Now...

[Anonymous Coward]

Mint user here. Full agreement. Replace PulseAudio too.

I got tired of rolling my own... but sometimes think of going back to Slackware.

Re:Now...

[Anonymous Coward]

Meh. Pulseaudio and systemd work great for me, I'd probably switch *away* from Ubuntu if they dropped them.

Why switch to Wayland in the first place?

[halivar]

Despite it's touted simplicity, Wayland lags behind X functionality in both network awareness and driver support, as well as still a slight lag in performance despite its purported closeness to the hardware compared to X. Am I misunderstanding something?

Re:Why switch to Wayland in the first place?

[Fly Swatter]

Those guhnome fellows pulled one over on them.

Re:Why switch to Wayland in the first place?

[thegarbz]

Wayland lags behind X functionality in both network awareness and driver support

So things that matter to users of LTS releases and pretty much no one else?

In the meantime there's a laundry list of reasons X.org is a horrible system to use on a desktop. Which is also why you'll see Wayland as the default in 18.10 again.

Re:Why switch to Wayland in the first place?

[serviscope_minor]

In the meantime there's a laundry list of reasons X.org is a horrible system to use on a desktop.

OK, I'll bite.

Like what?

So far about 80% of them are "I refuse to acknowledge the existence of any new API calls past about 1987". A few others centre around the kernel being unreasonably slow, and there's one or two decent points.

Re:Why switch to Wayland in the first place?

[thegarbz]

Wow you get those two out of them? Forget the speed, the issues around hardware access, the issues on on exclusive access that creates a huge security issue for lockscreens, the inability to use most of the buttons on a laptop while a locked session is in progress (but yes having to open up and login to a device just to hit the volume down key is totally what we expect from modern 2018 systems).

I'm not going to repeat them all here (because who has the time), this horse has been beaten to death so often it is now a goo of red puree mushed into the carpets. Feel free to google it, ... but I'm sure you won't.

Re:Why switch to Wayland in the first place?

[serviscope_minor]

Right indeedio I will bite!

Forget the speed,

Yes indeed, forget that because there's no evidence X is slow. Sure it was slow on a Sun 3/60 and people were maybe right to whine then. It's been a very VERY long time since I've run a 20MHz desktop CPU.

the issues around hardware access

Which are?

the issues on on exclusive access that creates a huge security issue for lockscreens

Oh you mean the issue that doesn't happen at all if you use a compositor like 99% of modern desktops. Note: if the desktpos don't implement that, it's their fault not an inherent limitation in X.

the inability to use most of the buttons on a laptop while a locked session is in progress (but yes having to open up and login to a device just to hit the volume down key is totally what we expect from modern 2018 systems).

Ah yes, the thing that isn't an issue with a modern compositor architecture. Note: bugs in gnome aren't bugs in X11.

Look: the modern X architecture routes EVERYTHING through the compositor just like Wayland. So the security tradeoffs are identical. It's impossible for an actave grab to interpose.

If gnome have done a shit job of actually using the features that X has had for the last decade or more, blame gnome, not X.

I'm not going to repeat them all here (because who has the time), this horse has been beaten to death so often it is now a goo of red puree mushed into the carpets

No it hasn't. It's been beaten by ill-informed people repeating poorly understood talking points.

Re:Why switch to Wayland in the first place?

[Anonymous Coward]

Yes

Re:Why switch to Wayland in the first place?

[Anonymous Coward]

Wait, you're seeing only LTS users are interested in performance?

And X11 is not horrible on a desktop. GNOME3, yeah, I'll give you that, but when GNOME 2 was current, Ubuntu was objectively better than Windows in every UI metric, and only slightly behind Mac OS X. And it was running X11. So you're wrong.

Re:Why switch to Wayland in the first place?

[Anonymous Coward]

Damore's document is so bad, the only arguments left to fans are spurious claims that "you didn't read it".

Your signature is so bad that it is killing any other reasoned and logical argument you might make. You must work for google to be that blind.

Re:Why switch to Wayland in the first place?

[DCFusor]

Have to agree. I've skipped giving servicscope + mods for that sig myself.

Re:Why switch to Wayland in the first place?

[Anonymous Coward]

Very interesting bit about the volume keys. That might be a reason linux phones don't run Xorg.

One strike against Wayland though is I read it's locked to 60 fps, might just be current Gnome implementation but still. Even some cheap 1080p desktop monitors can do real 75Hz.
Not an issue for a 60Hz laptop, 60Hz TV, 60Hz monitors (there are a ton of them from 1280x1024 to 4K)
I also wonder about variable refresh, which can be a power saving feature. Say you're very miserly about your battery, you would refresh your laptop or phone at smooth synced 40Hz and save a number of milliwatts - that's yesterday's technology. (this may change on a really short notice too, milliseconds)

Re:Why switch to Wayland in the first place?

[Greyfox]

Yeah I was doing some big X11 development a couple years ago and was stunned by just how far things haven't progressed since I was looking at Motif in the '90's. In fact the application I was working on was a Motif program, if you can believe it. Oh God that thing was crap, and there was really no way to fix it in X. Oh, in theory you could do some sort of quad-tree thing back with double-buffered bitmaps on the client, but whoops, our clients (Windows running some crappy X11 server) didn't support the double-buffering extension I would have needed to do that. And I still would have had to do all the image management routines myself from scratch. If you're working on a local system with a local server, it has the potential to not completely suck. If you're actually going over the network, you'd probably be better off just writing a webapp or something anyway.

Re:Why switch to Wayland in the first place?

[Anonymous Coward]

What do you think of FLTK? Seems good software, I was only a user though. Dillo browser is a well known program using it.

Re:Why switch to Wayland in the first place?

[serviscope_minor]

Yeah I was doing some big X11 development a couple years ago and was stunned by just how far things haven't progressed since I was looking at Motif in the '90's. In fact the application I was working on was a Motif program, if you can believe it. Oh God that thing was crap, and there was really no way to fix it in X.

Well, no. I mean you're using a program using a late 1980s era toolkit. It'd be like using the Windows 16 bit API on modern as a reason to not use Windows. Yes being M*tif, your experience will suck.

. Oh, in theory you could do some sort of quad-tree thing back with double-buffered bitmaps on the client, but whoops, our clients (Windows running some crappy X11 server) didn't support the double-buffering extension I would have needed to do that.

You wouldn't run a version of Windows so crappy that it didn't have double buffering, why on earth would you do the same with X?

Re:Why switch to Wayland in the first place?

[sjames]

Yeah, everyone knows gamers prefer laggy VESA mode displays.

Re:Why switch to Wayland in the first place?

[sjames]

Since you're already willing to do a rewrite in something other than Motif (you don't actually think THAT is going to be updated to support Wayland, do you?) why not try a modern toolkit interacting with X?

Re:Why switch to Wayland in the first place?

[Greyfox]

Looked at 'em, Qt was the only thing that even remotely offered a solution to pushing as many pixels as we needed pushed, but since we'd be talking about rewriting those applications from the ground up, doing it as a webapp would have been a simpler solution. The code was not very well written -- over 400 global variables, some defined in header files shared across three or four executables. And of course all the display logic was in with all the business logic of the applications, with no documentation as to why or when any particular branch in the code would be followed. It was a blast from the past. The company decided the data it was generating wasn't worth the development effort of maintaining it, and I've since moved on to video processing for fun and profit.

Re:Why switch to Wayland in the first place?

[sjames]

So none of the toolkits had the performance you needed unless you did it through a browser using those same toolkits? Is there a xritique of X itself somewhere in there?

Re:Why switch to Wayland in the first place?

[Greyfox]

Yeah, it would have been less complex to do that application as a webapp. Browser caching of imagery that had already been downloaded would probably have been enough caching on the client side and it would have been persistent across restarts of the application. A lot of the problems that we had with it were due to assumptions of the original design, including running the programs on our server and pushing pixels out to machines that were just as capable but which were being used just as dumb display devices. None of the programs were particularly complex in terms of what they were doing, but they were pushing gigabytes of imagery across the network and the business logic was where the tricky bits were. None of it was commented or enumerated in requirements anywhere, the programs just followed whatever execution path they followed and were executed in an order documented in a few pages on a wiki.

Re:Why switch to Wayland in the first place?

[sjames]

That's kinda my point. It doesn't sound like X was the problem at all, it was the app itself that was screwed up. If you were married to that particular client-server architecture, Wayland DEFINITELY wouldn't help you since it doesn't do that at all.

Honestly... I'm sure why...

[ckatko]

...we even have Wayland/Mir.

The X Server stack was fast enough back in the days of the FOUR-EIGHTY-SIX.

And almost all the implementations of the new system lack features that we already expect to work on x server without thinking about it.

Re:Honestly... I'm sure why...

[Anonymous Coward]

It's about games.

Re:Honestly... I'm sure why...

[LiENUS]

The X Server stack was fast enough back in the days of the FOUR-EIGHTY-SIX.

Because back in the days of the "FOUR-EIGHTY-SIX" your cpu was generally faster than your graphics card. Nowadays your graphics card is so much faster than your cpu the X stack leaves your graphics rendering waiting on the CPU. So Wayland is an attempt (successful or not is an entirely different discussion) to get the cpu out of the way for your graphics card to work more efficiently.

Re:Honestly... I'm sure why...

[jouassou]

Most of the Wayland maintainers have also been working on X.org for a long time, and I trust the developers to know better than the users when a rewrite is due. From what I've read, in addition to the issue of maintainability, X.org is inherently insecure (any app is allowed to draw over / screencapture / keylog any other app), contains a lot of code that is never used anymore (e.g. the builtin font rendering and GUI toolkit in X), while modern developments such as DRI and compositing were bolted on as ugly extensions. So if the X.org maintainers say it's cleaner to rewrite it than to keep bolting on new features on top, then I believe them.

If you're genuinely interested in why people are developing Wayland, I recommend looking at this talk :).

Re:Honestly... I'm sure why...

[serviscope_minor]

Because back in the days of the "FOUR-EIGHTY-SIX" your cpu was generally faster than your graphics card. Nowadays your graphics card is so much faster than your cpu the X stack leaves your graphics rendering waiting on the CPU.

No it isn't: X has supported hardware acceleration from the earliest days and continues to do so. See, for example GlamourGL, in which Xorg uses OpenGL shaders to do all the 2D drawing operations.

So Wayland is an attempt (successful or not is an entirely different discussion) to get the cpu out of the way for your graphics card to work more efficiently.

No, that's utter crap. Wayland doesn't do that AT ALL. Wayland is basically a system for sending bitmapts to a compositor and have the compositor send back input. Wayland provides very little else and certainly no rendering. Applications are expected to render to their own buffers using something like DRI, which is PRECISELY the same as they use under X11 too if running locally.

Re:Honestly... I'm sure why...

[halivar]

I trust the developers to know better than the users when a rewrite is due

As a developer who has been on way too many misguided rewrite projects, I do not share this credulousness.

"Ugh, this code is so messy!"

"I know! Let's rewrite it!"

And thus we enter purgatory.

Re:Honestly... I'm sure why...

[Anonymous Coward]

Thanks for the info! I didn't know this was running. I found out the spelling is glamor gl (no "u"). I was getting "glamour gals" on a google search.

Re:Honestly... I'm sure why...

[Anonymous Coward]

The X Server stack was fast enough back in the days of the FOUR-EIGHTY-SIX.

640k is enough for everyone

Re:Honestly... I'm sure why...

[thegarbz]

The X Server stack was fast enough back in the days of the FOUR-EIGHTY-SIX.

And I'm sure if all we care about is drawing rectangles on the screen it still would be.

Re:Honestly... I'm sure why...

[Greyfox]

There's a lot of politics around the X design and code base. At some point in the past some XFree86 guy was probably a dick to some future Wayland developer on a forum or in a bug tracker, and the Wayland guy was probably all like "Fuck you! I'm going to make my own GUI, with blackjack and hookers!"

Funnily X11 is a lot like Lisp in that, during the course of rewriting it, they'll probably make exactly the same mistakes and require the same work-arounds until the Wayland is such a steaming pile of shit that some new guy will be all like "Fuck you! I'm going to make my own GUI!" and the cycle will repeat.

Re:Honestly... I'm sure why...

[Uecker]

No, it was all about mobile. All the UI rewriting craziness started because people (Ubuntu, Intel, and many others) saw a huge opportunity in building a mobile operating system based on Linux. This is also the reason the interests of its old user base and backwards compatibility were not much of a concern (The reason for the systemd craziness was probably the virtualization I think). Only some clueless fanboys reading phoronix thought it is about making their gaming or desktop experience better and believed all the X is bad propaganda.

Re:Honestly... I'm sure why...

[ChunderDownunder]

The blackjack and hookers was Ubuntu's Mir and Unity - Half a decade wasted on that.

Re:Honestly... I'm sure why...

[Anonymous Coward]

I'm not sure what he meant but all or most current games need X11 (modern linux games were based on Ubuntu 12.04 + Steam libraries). You want to run them on Xorg to not suffer mouse lag or other random issues.

Re:Honestly... I'm sure why...

[LiENUS]

No it isn't: X has supported hardware acceleration from the earliest days and continues to do so. See, for example GlamourGL, in which Xorg uses OpenGL shaders to do all the 2D drawing operations.

There's a reason that any serious graphics rendering under Xorg uses DRI. It's because DRI bypasses most of the X stack.

No, that's utter crap. Wayland doesn't do that AT ALL. Wayland is basically a system for sending bitmapts to a compositor and have the compositor send back input. Wayland provides very little else and certainly no rendering.

So what you're saying is wayland gets the cpu out of the way so applications can render on the graphics card more efficiently? wow why didn't I think to say that?

Applications are expected to render to their own buffers using something like DRI, which is PRECISELY the same as they use under X11 too if running locally.

So what you're saying is all that Xorg nonsense just bogs it down and anything rendering 3d any serious graphics is just going to do direct rendering like wayland prefers anyway? holy shit I wish I had thought to say that... oh wait I did.

Re:Honestly... I'm sure why...

[serviscope_minor]

There's a reason that any serious graphics rendering under Xorg uses DRI. It's because DRI bypasses most of the X stack.

By serious graphics, you mean OpenGL?

You do know that OpenGL debuted as a feature of X11, right, you know waaay back in 1993? And you don't even know what you mean when you say "the X stack gets out of the way".

It was never in the way in the forst place. Since it's inception OpenGL has been very efficient on X11. In fact with many bits of X, it's possible to ship data to the card over shared memory when you're local and over the network when you're not all without losing transparency or performance.

So what you're saying is all that Xorg nonsense just bogs it down

No, look, put up or shut up.

Either present some evidence that X slows things down (no, a blog post claiming that kernel transitions are 3 orders of magnitude slower than they are in reality does not cut it) or GTFO.

So far you're arguing at the level of "herp derp X is teh suxors wayland is teh roxors" and yet you don't seem to know much about what either Wayland or X11 actually do.

Re:Honestly... I'm sure why...

[Greyfox]

I won't disagree with you, but you know sometimes you get a developer boner to make something shiny. A lot of UIs I work with (Android in general and Samsung's version of it in particular) are very shiny, but also infuriating to work with. Unity kind of felt like that, for the few minutes I was ever able to stand it. I like my focus follows mouse and having multiple windows far too much to stand something that wants to arbitrarily deny me those things. Funnily I can make Windows work for me a lot better than OS/X, but I'm heading back toward Linux everywhere, and a nice, clean and simple window manager.

Re:Honestly... I'm sure why...

[LiENUS]

No, look, put up or shut up.

I quote the parent I was replying to... oh wait that's you

Applications are expected to render to their own buffers using something like DRI, which is PRECISELY the same as they use under X11 too if running locally.

DRI Bypasses X.org. Why do you think that is?

Re:Honestly... I'm sure why...

[LiENUS]

By serious graphics, you mean OpenGL?

You do know that OpenGL debuted as a feature of X11, right, you know waaay back in 1993? And you don't even know what you mean when you say "the X stack gets out of the way".

I'm well aware of that. Why do you think everyone uses DRI which bypasses X and not indirect rendering for gl which goes through X.

Re:Honestly... I'm sure why...

[serviscope_minor]

Ah yes, we're back to the old "X11 is crap because it provides fast ways to do things" argument.

It's not interesting debating if your axiom is "X is slow".

X isn't slow. Since the late 80s, it provided non-socket ways of sending data to the hardware. That's not "bypassing X", that's using the features of X as designed.

You might as well say Wayland is crap because programs "bypass" it and render directly with DRI.

Re:Honestly... I'm sure why...

[serviscope_minor]

I'm well aware of that. Why do you think everyone uses DRI which bypasses X and not indirect rendering for gl which goes through X.

You mean, unless people are running remotely?

Apparently if most systems provide fast ways to do things, that's good. But if X does, then that's bad. WTF.

X provides fast local, and accpetable non local ways of doing things. Only the rabid haters seem to thing this is a bad thing.

Re:Honestly... I'm sure why...

[Anonymous Coward]

It's about job security.

Re:Honestly... I'm sure why...

[Anonymous Coward]

I trust the developers to know better than the users when a rewrite is due

As a developer who has been on way too many misguided rewrite projects, I do not share this credulousness.

"Ugh, this code is so messy!"

"I know! Let's rewrite it!"

And thus we enter purgatory.

Meh. Yes, of course sometimes a rewrite is a terrible idea. However, sometimes it is essential. The Art is knowing which.

Oh dearie, dearie me

[Phillip2]

Does this mean that all the things that broke in 17.10 that I then had to work out how to fix will now rebreak because of those same fixes? And I will have to return to where I was?

Really screwed up installing 17.10. Should have stuck to LTS.

Re:Oh dearie, dearie me

[LiENUS]

Really screwed up installing 17.10. Should have stuck to LTS.

Absolutely. If you aren't willing to reinstall on a regular basis then always stick with LTS releases. Upgrading every time theres a new Ubuntu release gives you the latest and greatest, but lots of stuff will be broken.

Re:Oh dearie, dearie me

[Anonymous Coward]

No. You can still log into Wayland session if that suits you better. It's a change in DEFAULT, ie. the session used when you don't explicitly choose one. They're not removing Wayland.

Re:Oh dearie, dearie me

[Anonymous Coward]

Not always. Newer stuff can have bugfixes, new or more useful drivers. There was a stupid old Xorg bug in 8.04 and lenny, which didn't give me too much trouble. Or I once updated a buddy's laptop to 9.10 and he gained working internal wifi (prior version allowed to dick with preliminary support in a terminal)

For the parent anyway : if you choose Wayland session from the login screen, then you'll have the same set of issues as in 17.10 Wayland but perhaps better. Later with 18.04.2 and .3 (or "HWE" packages) it might get better from driver improvments or fixes. So you can take it easy I think.

Common sense like this should be applauded.

[blind biker]

This is the first time in a long while that a company steps back from what looked like suicidal commitment to a bad idea, and actually went back to what works.

I wish Lenovo did the same with the 7-row keyboardes on the ThinkPad. Also I wish Linux companies (except RedHat, of course) would ditch SystemD.

Re:Common sense like this should be applauded.

[thegarbz]

from what looked like suicidal commitment to a bad idea

So you mean you didn't read the post? The only reason they stepped back from Wayland is because it specifically breaks screen sharing and many developers have not ported their programs to the Wayland way of doing it, as well as architectural issues with Gnome Shell which can bring down the system and are due to be fixed in 4.0

If you think this is some massive backflip and a thumbs up to X.Org, you're going to be very upset when Ubuntu 18.10 is released.

Re:Common sense like this should be applauded.

[reanjr]

Actually Ubuntu does this pretty regularly. That might just mean they make lots of bad decisions, though. Unity. Upstart. Wayland. Nautilus has been upgraded and subsequently regressed twice, I think. Et al.

Re:Common sense like this should be applauded.

[thegarbz]

Good examples:

Unity - adopted because Gnome Shell was a bucket of shit that looked unfix-able. Dropped once Gnome Shell became "fixed".
Upstart - adopted because sysvinit was garbage and there was no replacement providing the suitable features. Dropped once systemd became suitable.
Wayland - I assume you meant mir? adopted because x.org has it's warts on a modern desktop and it won't ever change without a ground up re-write. Dropped because Wayland became suitable. Wayland still the default, still shipped and still supported is only not the default for a single LTS release with a different use case than the rest of Ubuntu.
Nautilus ... well I honestly have no idea. Upgraded, regressed? Didn't notice. Didn't make a difference to my system.

Et al. - Yes when you're as big as Canonical you have the resources to try and solve your own problems. That doesn't mean duplicating other's efforts. It's a testament to them that they drop duplicated effort when something better actually comes around.

Re:Common sense like this should be applauded.

[Anonymous Coward]

All correct and good, except for this statement which is not true:

Upstart - adopted because sysvinit was garbage and there was no replacement providing the suitable features. Dropped once systemd became suitable.

It's never been suitable.

Re:Common sense like this should be applauded.

[Ramze]

holy jumpin' speculation, Batman!

16.04 is an LTS release. Most servers run the LTS version of Ubuntu. So, while your average Joe is fine with upgrading every 6 months, there are a massive number of production servers running an almost two year old LTS about to upgrade to this, and their sysadmin concerns have to be taken into account before this is released. It's going to have to keep them happy for another two years 'til the next release as well.

Ubuntu is smart enough to keep that backwards compatibility upon upgrade or replacement for this specific release for those sysadmins. It's a small concession to leave X.org as the default upon login to keep them happy for the next two years.

I wouldn't be surprised if 16.10 flips the options to make Wayland the default as it wouldn't affect those remaining on LTS & it gives developers more time to shift to Wayland. Most of the programs I use have partial Wayland support, but it's improving -- VLC, Firefox, Chrome/Chromium... and Nvidia is slowly coming around with Wayland compatible drivers. But, it's not there yet -- I wouldn't want Wayland as the default for an LTS version either w/ it's current state. It's not polished, but it's good enough for average users not running production LTS servers.

Re:Common sense like this should be applauded.

[Anonymous Coward]

Actually Ubuntu does this pretty regularly. That might just mean they make lots of bad decisions, though. Unity. Upstart. Wayland. Nautilus has been upgraded and subsequently regressed twice, I think. Et al.

They just take decisions too early, before things work. Unfortunately, the same seems to be true with almost every other distribution.

LTS

[erapert]

It's an LTS right? So isn't it the right move to keep it in stable territory for now?

Re:LTS

[Anonymous Coward]

The irrational hatred is for X11, not Wayland. X11 does everything everyone wants. It doesn't necessarily do it in a pure, elegant, way, but that's true of every windowing system. It's cleaner than, say, Mac OS X whose authors started with the fucking PDF specification and turned it into an Objective C API. That's a big WTF.

Dislike of Wayland is entirely rational: it doesn't do what X does, so people using it are losing functionality, and despite it supposedly being a pure, clean, design, it's slower and less efficient in practice. Benchmarks put it at 10% slower than X11, in those areas where it can be compared.

X11 isn't perfect, but it's completely irrational and stupid and moronic to form the conclusion, as Wayland's cheerleaders have, that "X11 = imperfect, Wayland != X11, therefore Wayland Better Than X11". No, X11 is better than Wayland. The latter was an interesting exercise, but it's a failure, it's objectively less functional and less efficient than X11, and anyone promoting Wayland at this point is a kook.

gnome-shell wayland disaster

[Anonymous Coward]

The shit is a total clusterfuck with Wayland. Something happens to gnome-shell--REBOOT. Some random gnome-shell plugin acts bad, no way to unload it--REBOOT. Mouse stops working--REBOOT. Come back from screen lock and clicks don't work--REBOOT.

All of this shit is possible to completely fix non-destructively when gnome-shell runs under X by Alt-F2 'r', or lacking input, Ctrl-Alt-F1 'killall -HUP gnome-shell'.

Now Alt-F2 'r' is disabled, and every other previously working solution causes EVERYTHING to be killed, because now gnome-shell is the parent of the entire session. The gnome-shell developers have basically said tough, this is intended operation, and you shouldn't need to restart the shell ever. Fuck them. I leave my workstation powered up for months on end, yet I have to restart gnome-shell it seems every week or two sometimes.

Re:gnome-shell wayland disaster

[Junta]

The problem is it is out of gnome shell's hands in wayland. in X they have a responsibility, but that responsibility isn't core to the applications working.

In Wayland architecture, gnome shell is basically the X server. Now they could do a better job segregating their code and have a more bulletproof core to be the wayland compositor, but it's just a whole new role they had never had to handle in the past.

Re:gnome-shell wayland disaster

[Anonymous Coward]

The gnome team have had almost 6yr now of Wayland existence and possibility to use it in Ubuntu. It was first targeted for 12.10 and I believe you have been able to optionally run Wayland/Mir since then. This by no means is a 'new' issue.

Re:gnome-shell wayland disaster

[Anonymous Coward]

We were promised modern shit - as an example of what is modern Vista could survive DRIVER CRASHES or even replacing replacing VESA-like driver with Intel driver that does the full res and 3D. To this day zillions computers run Windows 7 which is Vista 1.1.

That's more robust than Xorg which might require to kill your whole session sometimes.
Wayland somewhat goes backwards! If I give benefit of the doubt tho to Wayland or Gnome, it could get better with Gnome 4.

(I feel sorry to be an AC, for all the named people I replied to or the readers, but too bad!)

Re:gnome-shell wayland disaster

[vandamme]

That's OK for us recent converts from Windows, we're used to it.

Re:gnome-shell wayland disaster

[sjames]

Sounds like they still shouldn't be handling that responsibility. Perhaps it's a bit early to let Wayland force the issue.

lnx

[Anonymous Coward]

Because these changes, 2018 is year of the LINUX.

Sensible choice by Canonical

[Anonymous Coward]

It's best to let all those Fedora and Arch users work out the Wayland kinks on their crashing systems before adopting as a default.

Re:Sensible choice by Canonical

[bobstreo]

It's best to let all those Fedora and Arch users work out the Wayland kinks on their crashing systems before adopting as a default.

Works for Microsoft...

Re:Sensible choice by Canonical

[Anonymous Coward]

It's best to let all those Fedora and Arch users work out the Wayland kinks on their crashing systems before adopting as a default.

Works for Microsoft...

Can you elaborate?

Re:Sensible choice by Canonical

[bobstreo]

It's best to let all those Fedora and Arch users work out the Wayland kinks on their crashing systems before adopting as a default.

Works for Microsoft...

Can you elaborate?

Microsoft historically does it's OS and Application debugging after releasing a new version, based on feedback from telemetry and user complaints,,,

Good job Canonical

[Anonymous Coward]

I think they should be congratulated on responding to user sentiment. I wish more companies would admit they acted prematurely and roll back changes that didn't work out. I can think of one or two very large Linux features that I could live without, but which are foisted on all of us.

Re:Good job Canonical

[Anonymous Coward]

Agreed.

Wayland is the systemd of windowing systems

[Anonymous Coward]

Wayland is pretty much the systemd of windowing systems. It ignores decades of accumulated knowledge and experience to deliver a shitty offering that often doesn't work and that is widely disliked and unwanted by users.

Re:Wayland is the systemd of windowing systems

[Anne Thwacks]

a shitty offering that often doesn't work and that is widely disliked and unwanted by users

so .. pretty much in keeping with Ubuntu mindset. Why are they dumping it again?

Re:Wayland is the systemd of windowing systems

[Anonymous Coward]

To concentrate on mir.

Not Ubuntu's Decision

[Anonymous Coward]

Russian Hackers are removing Wayland and inserting X.org.

Good news.

[Anonymous Coward]

Good news. I run the LTS versions for stability, this should massively increase the chances of 16.04->18.04 being smooth.

Wayland simply did not deliver

[Anonymous Coward]

Wayland did not deliver on its promises. It is slow and lacks functionality. Same as Gnome.

Hey Wayland devs...

[gosand]

talk to Poettering, I am sure he can hook you up to be the de-facto standard despite the shortcomings of Wayland.

Re:Hey Wayland devs...

[Anonymous Coward]

Actually, i thought Wayland was already being integrated into systemD.
All hail to sytemwaylanD.

LTS

[DrXym]

The clue is in those letters. Wayland isn't going to stop being the focus going forward, irrational hate for it notwithstanding.

Xorg just won't f*cking die.

[Qbertino]

You have to admit, they do tend to stick around no matter what newfangled graphics server comes around. Hold old X11 now? 30+ years or something? ... Nice.

Language input problem

[UnsignedInt32]

I tried to use it. Biggest problem I see is Japanese language input doesn't work as they still runs on Xwayland realm. And even when it works, it's a hit or miss. Perhaps things will improve once they are fully ported to Wayland...

ssh -X

[Anonymous Coward]

Efficient remote display through ssh is the issue. If there was a wayland solution, then the replacement would be complete.

difference between Ubuntu and Debian

[Anonymous Coward]

Now that Ubuntu has dropped most of the Canonical'isms,

Why should I not switch to upstream Debian?

Re:difference between Ubuntu and Debian

[DCFusor]

Because it's not quite as nice as Mint?

Re:difference between Ubuntu and Debian

[Anonymous Coward]

I found out they were much the same nine years ago. It's like asking about the difference between a Volkswagen and an Audi. There's even the Skoda, so three brands for an identical car.

Re:18.04 will be lts, stay with stable stuff

[Anonymous Coward]

Fixed Subject.

Fix Xorg security.

[Anonymous Coward]

Only real issue with X anymore is the ability for malicious apps to snarf input data for other apps, etc. Make an ACL daemon/windowmanager extension/etc to filter what each app can see when out of focus and the problem goes away.

Personally, Wayland offers *NO* benefits for me. kms fbdev+egl+gpm+maybe raw keyboard access is all I need for basic dos-style GUI apps, and anything more complicated X does and has done a far better job for me for 20 years.

Wayland on the other hand takes away key features, network accessability, and the possibility to migrate to non-bitmapped primitives in the future. While Display Postscript and the X drawing primitives didn't take off in their time, the modern era is really about ready to start trending the opposite way. Most of our UIs and Applications could be made infinitely scalable and eliminating the bitmap/fixed framebuffer allows the potential for scriptable UIs that can automatically resize for the current screentype, even changing mid-process during display changes if necessary. Wayland is already built around an obsolete model and was mostly egotistical members of the X team thinking they could do things better while also ensuring job security for decades to come.

As to discussions about multithreading below: So noodle through it and make X11 into X12 with multithread compatible protocol changes. Hell, you might even be able to do it without throwing out X11, although at this point a code factoring where X11 was a single threaded subset of X12 would probably be best.

Threads? Mwahaha

[Anonymous Coward]

Dude, multithreaded is harder to get right, and very much harder to debug when you fuck it up. The GNOME crowd are pretty challenged with single-threaded; their attempts at multithreading will get CPUs die laughing, despite silicon being a stone.

Xpra and firejail protections for X11 apps

[Anonymous Coward]

The firejail and Xpra combo gives us process isolation (memory, filesystem, process space, bandwidth, Linux caps...) and X11 isolation NOW. That is the demostration that it can be done. It started years ago, the concept of jails is pretty old in Unix, and Xpra started before 2014 (0.11 version), while Xephyr (& Xvfb) is(are) even older (and the fallback in case firejail can't find Xpra when asked to give protection for X11).

Integrate the ideas, make the system easier and we get a lot better than Wayland, with no rewrites, compatible out of the box, and should be possible to disable as needed.

But rewrites are better for job security. You can do them over and over if you can blame the need of a new one in something else.

Whats New is Old Again

[CrashNBrn]

No wonder Google switched to Debian as a distribution base. Shuttleworth has turned Ubuntu into a major clusterf*ck.