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

← Back to Stories (view on slashdot.org)

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

Posted by msmash on Friday January 26, 2018 @04:00AM from the tough-calls dept.

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.

135 of 194 comments (clear)

Min score:

Reason:

Sort:

See Saw Cycles of Adoption and Abandonment by CRB9000 · 2018-01-26 04:07 · Score: 2, Interesting

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."
1. Re:See Saw Cycles of Adoption and Abandonment by Viol8 · 2018-01-26 04:11 · Score: 5, Insightful
  
  "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.
2. Re:See Saw Cycles of Adoption and Abandonment by CRB9000 · 2018-01-26 04:14 · Score: 1
  
  I disagree. If they were totally abandoning Wayland, then you'd have a point. They simply saying, "Hey! Look! Choice! Yay us."
3. Re:See Saw Cycles of Adoption and Abandonment by jouassou · 2018-01-26 04:29 · Score: 2
  
  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.
4. Re:See Saw Cycles of Adoption and Abandonment by Junta · 2018-01-26 04:29 · Score: 5, Insightful
  
  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.
  
  --
  XML is like violence. If it doesn't solve the problem, use more.
5. Re:See Saw Cycles of Adoption and Abandonment by chill · 2018-01-26 04:31 · Score: 3, Interesting
  
  This is called the Tyranny of the Default, and is a real thing.
  
  --
  Learning HOW to think is more important than learning WHAT to think.
6. Re:See Saw Cycles of Adoption and Abandonment by Galactic+Dominator · 2018-01-26 04:33 · Score: 1
  
  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.
  
  --
  brandelf -t FreeBSD /brain
7. Re:See Saw Cycles of Adoption and Abandonment by Fly+Swatter · 2018-01-26 04:34 · Score: 4, Interesting
  
  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.
8. Re:See Saw Cycles of Adoption and Abandonment by thegarbz · 2018-01-26 04:39 · Score: 1
  
  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.
9. Re:See Saw Cycles of Adoption and Abandonment by postbigbang · 2018-01-26 05:15 · Score: 1
  
  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.
  
  --
  ---- Teach Peace. It's Cheaper Than War.
10. Re:See Saw Cycles of Adoption and Abandonment by Anonymous Coward · 2018-01-26 05:16 · Score: 5, Insightful
  
  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.
11. Re:See Saw Cycles of Adoption and Abandonment by Spacelord · 2018-01-26 05:34 · Score: 3, Insightful
  
  > 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.
12. Re:See Saw Cycles of Adoption and Abandonment by kurkosdr · 2018-01-26 06:31 · Score: 1
  
  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.
13. Re:See Saw Cycles of Adoption and Abandonment by Cyberax · 2018-01-26 07:23 · Score: 1, Insightful
  
  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.
14. Re:See Saw Cycles of Adoption and Abandonment by CRB9000 · 2018-01-26 08:09 · Score: 1
  
  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".
15. Re:See Saw Cycles of Adoption and Abandonment by Viol8 · 2018-01-26 08:30 · Score: 2
  
  Yeah, its so easy to hack thats why it's hackers favourite attack vector into *nix systems. Oh, wait...
16. Re:See Saw Cycles of Adoption and Abandonment by rahvin112 · 2018-01-26 08:32 · Score: 1
  
  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.
17. Re:See Saw Cycles of Adoption and Abandonment by Cyberax · 2018-01-26 08:35 · Score: 1, Insightful
  
  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.
18. Re:See Saw Cycles of Adoption and Abandonment by Lord+Kano · 2018-01-26 09:00 · Score: 2
  
  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
  
  --
  "Hi. This is my friend, Jack Shit, and you don't know him." - Lord Kano
19. Re:See Saw Cycles of Adoption and Abandonment by Uecker · 2018-01-26 09:06 · Score: 3, Informative
  
  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...
20. Re:See Saw Cycles of Adoption and Abandonment by Anne+Thwacks · 2018-01-26 09:12 · Score: 2
  
  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.
  
  --
  Sent from my ASR33 using ASCII
21. Re: See Saw Cycles of Adoption and Abandonment by chill · 2018-01-26 09:12 · Score: 1
  
  This isn't Linux, it is Ubuntu. :-P
  
  --
  Learning HOW to think is more important than learning WHAT to think.
22. Re:See Saw Cycles of Adoption and Abandonment by Uecker · 2018-01-26 09:14 · Score: 1
  
  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.
23. Re:See Saw Cycles of Adoption and Abandonment by Cyberax · 2018-01-26 09:37 · Score: 4, Informative
  
  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
24. Re:See Saw Cycles of Adoption and Abandonment by Uecker · 2018-01-26 09:55 · Score: 1
  
  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, ...)
25. Re:See Saw Cycles of Adoption and Abandonment by JesseMcDonald · 2018-01-26 09:56 · Score: 1
  
  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.
  
  --
  "The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
26. Re:See Saw Cycles of Adoption and Abandonment by Cyberax · 2018-01-26 10:12 · Score: 1
  
  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).
27. Re:See Saw Cycles of Adoption and Abandonment by Cyberax · 2018-01-26 10:41 · Score: 1
  
  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.
28. Re:See Saw Cycles of Adoption and Abandonment by Uecker · 2018-01-26 10:52 · Score: 1
  
  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.
29. Re:See Saw Cycles of Adoption and Abandonment by Cyberax · 2018-01-26 10:58 · Score: 1
  
  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.
30. Re:See Saw Cycles of Adoption and Abandonment by Uecker · 2018-01-26 11:18 · Score: 1
  
  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.
31. Re:See Saw Cycles of Adoption and Abandonment by Cyberax · 2018-01-26 12:00 · Score: 1
  
  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...
32. Re:See Saw Cycles of Adoption and Abandonment by DrXym · 2018-01-26 22:08 · Score: 1
  
  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
33. Re:See Saw Cycles of Adoption and Abandonment by Viol8 · 2018-01-27 00:29 · Score: 1
  
  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.
34. Re:See Saw Cycles of Adoption and Abandonment by dakra137 · 2018-01-27 05:25 · Score: 1
  
  How could 40 year old code be written for a processor that was announced 32 years ago? https://en.wikipedia.org/wiki/Intel_80386
35. Re:See Saw Cycles of Adoption and Abandonment by KozmoStevnNaut · 2018-01-27 10:23 · Score: 1
  
  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.
  
  --
  Eat the rich.
36. Re:See Saw Cycles of Adoption and Abandonment by sjames · 2018-01-27 13:43 · Score: 1
  
  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.
37. Re:See Saw Cycles of Adoption and Abandonment by Cyberax · 2018-01-28 08:00 · Score: 1
  
  You have port 600X open on a network-facing interface (i.e. not localhost)? Yeah, lol.
38. Re:See Saw Cycles of Adoption and Abandonment by Gr8Apes · 2018-01-29 04:01 · Score: 1
  
  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.
  
  --
  The cesspool just got a check and balance.
39. Re:See Saw Cycles of Adoption and Abandonment by Uecker · 2018-01-31 07:01 · Score: 1
  
  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?
40. Re:See Saw Cycles of Adoption and Abandonment by Cyberax · 2018-01-31 07:16 · Score: 1
  
  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).
41. Re:See Saw Cycles of Adoption and Abandonment by Uecker · 2018-02-01 23:13 · Score: 1
  
  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.
42. Re:See Saw Cycles of Adoption and Abandonment by angel'o'sphere · 2018-02-02 03:08 · Score: 1
  
  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.
  
  --
  Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
But but .... by Viol8 · 2018-01-26 04:08 · Score: 5, Funny

... 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!
1. Re:But but .... by KiloByte · 2018-01-26 04:15 · Score: 2
  
  I guess that's just a hard to discover easter egg, like mouse paste.
  
  --
  The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
2. Re:But but .... by jbernardo · 2018-01-26 04:27 · Score: 4, Informative
  
  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...
3. Re:But but .... by Junta · 2018-01-26 04:37 · Score: 2
  
  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.
  
  --
  XML is like violence. If it doesn't solve the problem, use more.
4. Re:But but .... by LiENUS · 2018-01-26 04:41 · Score: 1
  
  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
5. Re:But but .... by Anonymous Coward · 2018-01-26 04:44 · Score: 3, Insightful
  
  "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.
6. Re:But but .... by jbernardo · 2018-01-26 04:45 · Score: 3, Interesting
  
  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.
7. Re:But but .... by thegarbz · 2018-01-26 04:47 · Score: 2, Informative
  
  ... 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.
8. Re:But but .... by jbernardo · 2018-01-26 04:50 · Score: 3, Insightful
  
  "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?
9. Re:But but .... by serviscope_minor · 2018-01-26 04:58 · Score: 1
  
  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.
  
  --
  SJW n. One who posts facts.
10. Re:But but .... by thegarbz · 2018-01-26 05:00 · Score: 2
  
  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.
11. Re:But but .... by jbernardo · 2018-01-26 05:13 · Score: 1
  
  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/
12. Re:But but .... by serviscope_minor · 2018-01-26 05:22 · Score: 3, Interesting
  
  x host si:localuser:root
  was all I meeded
  So all you needed to get Wayland to work properly was... X.
  
  --
  SJW n. One who posts facts.
13. Re:But but .... by Eluan · 2018-01-26 07:36 · Score: 1
  
  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!
14. Re:But but .... by thegarbz · 2018-01-26 08:07 · Score: 1
  
  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.
15. Re:But but .... by thegarbz · 2018-01-26 08:11 · Score: 1
  
  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.
16. Re:But but .... by jbernardo · 2018-01-26 08:12 · Score: 1
  
  Wooosh......
17. Re:But but .... by rahvin112 · 2018-01-26 08:38 · Score: 1
  
  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.
18. Re:But but .... by Greyfox · 2018-01-26 09:04 · Score: 1
  
  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.
  
  --
  I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
19. Re:But but .... by Anne+Thwacks · 2018-01-26 09:25 · Score: 1
  
  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?
  
  --
  Sent from my ASR33 using ASCII
20. Re:But but .... by Uecker · 2018-01-26 09:30 · Score: 1
  
  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.
21. Re:But but .... by Anne+Thwacks · 2018-01-26 09:30 · Score: 1
  
  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!
  
  --
  Sent from my ASR33 using ASCII
22. Re:But but .... by arth1 · 2018-01-26 09:33 · Score: 1
  
  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.
23. Re:But but .... by tepples · 2018-01-26 13:38 · Score: 1
  
  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.
24. Re:But but .... by LiENUS · 2018-01-26 15:43 · Score: 1
  
  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
25. Re:But but .... by LiENUS · 2018-01-26 15:47 · Score: 1
  
  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?
26. Re:But but .... by LiENUS · 2018-01-26 15:49 · Score: 1
  
  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"
27. Re:But but .... by _merlin · 2018-01-26 17:55 · Score: 1
  
  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.
28. Re:But but .... by serviscope_minor · 2018-01-26 22:37 · Score: 1
  
  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.
  
  --
  SJW n. One who posts facts.
29. Re:But but .... by jon3k · 2018-01-27 01:18 · Score: 1
  
  I don't think so, I think it's more about application compatibility or just general maturity.
30. Re:But but .... by chapstercni · 2018-01-27 02:52 · Score: 1
  
  (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?
31. Re:But but .... by arth1 · 2018-01-27 03:34 · Score: 1
  
  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.
32. Re:But but .... by chapstercni · 2018-01-27 11:04 · Score: 1
  
  Thank you, Arth1
33. Re:But but .... by sjames · 2018-01-27 14:18 · Score: 1
  
  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.
34. Re:But but .... by sjames · 2018-01-27 14:51 · Score: 1
  
  What forever? Wayland is barely used. You sound like it's been the dominant GUI display for 5 years.
35. Re:But but .... by sjames · 2018-01-27 14:57 · Score: 1
  
  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.
36. Re:But but .... by benjymouse · 2018-01-30 06:17 · Score: 1
  
  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.
  
  --
  Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
Yawn by Anonymous Coward · 2018-01-26 04:10 · Score: 1

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... by Anonymous Coward · 2018-01-26 04:11 · Score: 1, Insightful

... if we can just get an Ubuntu without systemd based on Devuan instead of Debian!
Why switch to Wayland in the first place? by halivar · 2018-01-26 04:11 · Score: 3, Interesting

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?
1. Re:Why switch to Wayland in the first place? by Fly+Swatter · 2018-01-26 04:36 · Score: 1
  
  Those guhnome fellows pulled one over on them.
2. Re:Why switch to Wayland in the first place? by thegarbz · 2018-01-26 04:51 · Score: 1
  
  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.
3. Re:Why switch to Wayland in the first place? by serviscope_minor · 2018-01-26 05:02 · Score: 2
  
  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.
  
  --
  SJW n. One who posts facts.
4. Re:Why switch to Wayland in the first place? by serviscope_minor · 2018-01-26 05:29 · Score: 5, Informative
  
  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.
  
  --
  SJW n. One who posts facts.
5. Re:Why switch to Wayland in the first place? by Greyfox · 2018-01-26 09:10 · Score: 1
  
  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.
  
  --
  I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
6. Re:Why switch to Wayland in the first place? by serviscope_minor · 2018-01-26 10:02 · Score: 1
  
  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?
  
  --
  SJW n. One who posts facts.
7. Re:Why switch to Wayland in the first place? by sjames · 2018-01-27 14:59 · Score: 1
  
  Yeah, everyone knows gamers prefer laggy VESA mode displays.
8. Re:Why switch to Wayland in the first place? by sjames · 2018-01-27 15:02 · Score: 1
  
  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?
9. Re:Why switch to Wayland in the first place? by Greyfox · 2018-01-28 04:42 · Score: 1
  
  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.
  
  --
  I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
10. Re:Why switch to Wayland in the first place? by sjames · 2018-01-28 05:43 · Score: 1
  
  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?
11. Re:Why switch to Wayland in the first place? by Greyfox · 2018-01-30 16:03 · Score: 1
  
  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.
  
  --
  I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
12. Re:Why switch to Wayland in the first place? by sjames · 2018-01-30 16:17 · Score: 1
  
  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... by ckatko · 2018-01-26 04:14 · Score: 5, Insightful

...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.
1. Re:Honestly... I'm sure why... by LiENUS · 2018-01-26 04:44 · Score: 1
  
  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.
2. Re:Honestly... I'm sure why... by jouassou · 2018-01-26 05:08 · Score: 5, Informative
  
  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 :).
3. Re:Honestly... I'm sure why... by serviscope_minor · 2018-01-26 05:18 · Score: 5, Informative
  
  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.
  
  --
  SJW n. One who posts facts.
4. Re:Honestly... I'm sure why... by halivar · 2018-01-26 05:32 · Score: 3, Insightful
  
  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.
5. Re:Honestly... I'm sure why... by thegarbz · 2018-01-26 08:13 · Score: 1
  
  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.
6. Re:Honestly... I'm sure why... by Greyfox · 2018-01-26 09:14 · Score: 1
  
  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.
  
  --
  I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
7. Re:Honestly... I'm sure why... by Uecker · 2018-01-26 09:43 · Score: 1
  
  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.
8. Re:Honestly... I'm sure why... by ChunderDownunder · 2018-01-26 09:58 · Score: 1
  
  The blackjack and hookers was Ubuntu's Mir and Unity - Half a decade wasted on that.
9. Re:Honestly... I'm sure why... by LiENUS · 2018-01-26 15:41 · Score: 2
  
  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.
10. Re:Honestly... I'm sure why... by serviscope_minor · 2018-01-26 22:45 · Score: 1
  
  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.
  
  --
  SJW n. One who posts facts.
11. Re:Honestly... I'm sure why... by Greyfox · 2018-01-27 01:23 · Score: 1
  
  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.
  
  --
  I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
12. Re:Honestly... I'm sure why... by LiENUS · 2018-01-27 04:27 · Score: 1
  
  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?
13. Re:Honestly... I'm sure why... by LiENUS · 2018-01-27 04:31 · Score: 1
  
  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.
14. Re:Honestly... I'm sure why... by serviscope_minor · 2018-01-27 07:20 · Score: 1
  
  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.
  
  --
  SJW n. One who posts facts.
15. Re:Honestly... I'm sure why... by serviscope_minor · 2018-01-27 07:21 · Score: 1
  
  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.
  
  --
  SJW n. One who posts facts.
Oh dearie, dearie me by Phillip2 · 2018-01-26 04:16 · Score: 1

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.
1. Re:Oh dearie, dearie me by LiENUS · 2018-01-26 04:45 · Score: 1
  
  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.
Common sense like this should be applauded. by blind+biker · 2018-01-26 04:16 · Score: 5, Insightful

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.

--
"The agriculture ministry is not in charge of Gundam" - Japanese ministry official.
1. Re:Common sense like this should be applauded. by thegarbz · 2018-01-26 04:50 · Score: 1
  
  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.
2. Re:Common sense like this should be applauded. by reanjr · 2018-01-26 05:22 · Score: 1
  
  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.
3. Re:Common sense like this should be applauded. by thegarbz · 2018-01-26 08:19 · Score: 1
  
  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.
4. Re:Common sense like this should be applauded. by Ramze · 2018-01-26 14:28 · Score: 1
  
  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.
LTS by erapert · 2018-01-26 04:16 · Score: 2

It's an LTS right? So isn't it the right move to keep it in stable territory for now?
gnome-shell wayland disaster by Anonymous Coward · 2018-01-26 04:25 · Score: 3, Interesting

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.
1. Re:gnome-shell wayland disaster by Junta · 2018-01-26 04:39 · Score: 1
  
  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.
  
  --
  XML is like violence. If it doesn't solve the problem, use more.
2. Re:gnome-shell wayland disaster by vandamme · 2018-01-27 13:09 · Score: 1
  
  That's OK for us recent converts from Windows, we're used to it.
3. Re:gnome-shell wayland disaster by sjames · 2018-01-27 15:13 · Score: 1
  
  Sounds like they still shouldn't be handling that responsibility. Perhaps it's a bit early to let Wayland force the issue.
Good job Canonical by Anonymous Coward · 2018-01-26 04:34 · Score: 4, Insightful

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:Sensible choice by Canonical by bobstreo · 2018-01-26 04:39 · Score: 1

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...
Wayland is the systemd of windowing systems by Anonymous Coward · 2018-01-26 04:54 · Score: 1

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.
1. Re:Wayland is the systemd of windowing systems by Anne+Thwacks · 2018-01-26 09:19 · Score: 1
  
  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?
  
  --
  Sent from my ASR33 using ASCII
Hey Wayland devs... by gosand · 2018-01-26 05:51 · Score: 1

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

--

My beliefs do not require that you agree with them.
LTS by DrXym · 2018-01-26 06:03 · Score: 1

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. by Qbertino · 2018-01-26 06:23 · Score: 1

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.

--
We suffer more in our imagination than in reality. - Seneca
Language input problem by UnsignedInt32 · 2018-01-26 06:55 · Score: 1

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...
difference between Ubuntu and Debian by Anonymous Coward · 2018-01-26 07:20 · Score: 1

Now that Ubuntu has dropped most of the Canonical'isms,
Why should I not switch to upstream Debian?
1. Re:difference between Ubuntu and Debian by DCFusor · 2018-01-26 07:26 · Score: 1
  
  Because it's not quite as nice as Mint?
  
  --
  Why guess when you can know? Measure!
Re:Sensible choice by Canonical by bobstreo · 2018-01-26 08:41 · Score: 1

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,,,
Whats New is Old Again by CrashNBrn · 2018-01-27 07:17 · Score: 1

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