If Wayland is the future, the future is grim. People often complain that Wayland is taking a long time to catch up to X11, but that actually stems from a deeper issue: Wayland has a horrible design, for an X11 replacement, a design that leads to massive fragmentation issues across the graphical part of the Linux ecosystem. Implementing a Wayland compositor requires much more effort than implementing an X11 window manager and each new compositor implementation reinvents the wheel many times, leaving users with less options for a desktop environment than on X11. Even worse, Wayland does not standardize on or is hostile to some essential features, meaning that users need to rely on compositor specific behavior for those features, if they are even available. E.g., an application that needs to grab the entire screen will need separate code for each compositor it supports screenshots on, or it must use a protocol outside Wayland to get the screenshot. Quoting Red Hat:
> Furthermore, there isn’t a standard API for getting screen shots from Wayland. It’s dependent on what compositor (window manager/shell) the user is running, and if they implemented a proprietary API to do so.
An xdotool (an input event automation tool, imagine wanting to inject or intercept input events) replacement is not possible on Wayland (without having separate support for each compositor, of course). These seem to be intentional design decisions (marketed as being necessary for security, but really being power-user hostile), this[0] Reddit comment puts it nicely:
> It has been almost a decade, why does Wayland not have a protocol definition for screenshots?" - answer - "Because security, dude! Wayland is designed with the thought that users download random applications from the interwebz which are not trustworthy and run them. Wayland actually makes a lot of sense if you don't think of Linux desktop distributions and desktop systems, but of smartphones. But for some reason we absolutely need this technology on the desktop, like we had not enough pain and lose ends over here without it.
But the lack of these features AFAIK also causes big trouble for users with special accessibility needs. Wayland is also, with its forced composition, hostile to interactive applications requiring low latency, e.g. video games.
> These seem to be intentional design decisions (marketed as being necessary for security, but really being power-user hostile)
That's an unnecessarily abrasive view: the Wayland protocol designers do not hate power users. But allowing programs to constantly take in arbitrary input & output information in the background, as well as simulate arbitrary input to other programs, is an obvious and glaring security flaw. Unfortunately, that forbids general-purpose screenshotting and key-rebinding programs - but there is no sensible middle ground.
>Wayland is designed with the thought that users download random applications from the interwebz which are not trustworthy and run them.
I appreciate that the average HN poster, and to a lesser extent the average Linux user, does not do this - but many, many Windows users do. In order to actually break into a mass desktop market, there has to be consideration of the ways people who do not currently use Linux behave.
I would even argue that lots of current Linux users are guilty of this - how many Arch users are checking the contents of PKGBUILDs from the AUR? How many Linux users, when searching for the solution to some problem with their desktop, have blindly copy-pasted commands from some support post - or worse still, just downloaded a "fix it" script to run?
Wayland is built on sane assumptions, because it also aims to cater to a not-insignificant part of the desktop market. That the response of an X11 supporter is "simply run the correct programs" show how little they have understood the goals and successes of Wayland as a project. It is not X12, and some of us are grateful for that.
>Unfortunately, that forbids general-purpose screenshotting and key-rebinding programs - but there is no sensible middle ground... In order to actually break into a mass desktop market, there has to be consideration of the ways people who do not currently use Linux behave.
Oddly, the actual mass market desktops have (and have had for a long time) solutions for the 'general-purpose screenshotting and key-rebinding programs'.
I know how bad was X11 technically, and sympathize with replacing it - but that by itself does not make Wayland a success. It took Wayland over a decade to almost get basic capabilities, and it's going to take another decade until all the compositor-based protocols are standardized (probably by eventually only having a single compositor implementation). By the time Linux finishes reimplementing its desktop, Windows and MacOS will be in an entirely different place.
Maybe this can't be helped - Open Source desktop development was always extremely underfunded and undersupported.
> by eventually only having a single compositor implementation
I'd just like to note explicity that this would probably be a compositor that tries to cater to only 80% of users (if that), with the rest of us being told to fuck off.
> That's an unnecessarily abrasive view: the Wayland protocol designers do not hate power users. But allowing programs to constantly take in arbitrary input & output information in the background, as well as simulate arbitrary input to other programs, is an obvious and glaring security flaw. Unfortunately, that forbids general-purpose screenshotting and key-rebinding programs - but there is no sensible middle ground.
Of course there's a middle ground: require special permission for programs that wish to do those things. For example, macOS has permission prompts for "[Application] would like to record this computer's screen." and "[Application] would like to control this computer using accessibility features."
> Unfortunately, that forbids general-purpose screenshotting and key-rebinding programs
Without this, you will forever be incalculably behind the proprietary OSes and the original X server. Perhaps you're happy in that corner, great! That puts you and whoever else exists there in the same conceptual space where everyone else with impractical and unreasonable restraints on their software lives.
That's a fine space to be in, but you don't get to say that it's the "correct" choice for the average user. It's the wrong choice, because it puts the Linux ecosystem at a permanent usability disadvantage. Instead of going with this "no you can't have it" approach, it would have been entirely reasonable to go with something permissions-based (perhaps even with a default that says it won't happen). Instead, we're stuck with one part of the community yelling that this is what everyone should want and everyone else trying their hardest to ignore them. It's an unhealthy situation for everyone.
> These seem to be intentional design decisions (marketed as being necessary for security, but really being power-user hostile)
>> That's an unnecessarily abrasive view: the Wayland protocol designers do not hate power users.
For the sake of civility and discourse I just want to point out the quote you're responding to does not talk about hating power users. The OP clearly just says that the "decision [is] power-user hostile." That's an important difference, as one is talking about substance (i.e. the decisions) and the other is veering into personal attacks. It's easy to conflate the two and I've certainly done it, but I just wanted to point it out to try and de-escalate the conversation a bit.
I also think it's reasonable to say that many security decisions in many contexts are "user hostile." Hostile design is an actual thing, where security and order are prioritized above convenience and functionality, and not simply an attack on "bad design"[0]. This is not to say all user hostile decisions are bad, but it's a trade-off. Asking for your password before every single interaction is user hostile (the user will never get in the flow[1]), but could be the right decision in certain contexts.
> Unfortunately, that forbids general-purpose screenshotting and key-rebinding programs - but there is no sensible middle ground.
Unfortunately, this makes it unusable for 98% of the population. Wayland also breaks screen sharing programs, which are essential for most, especially now during COVID.
> I appreciate that the average HN poster, and to a lesser extent the average Linux user, does not do this - but many, many Windows users do. In order to actually break into a mass desktop market, there has to be consideration of the ways people who do not currently use Linux behave.
Restricting Wayland feature makes sense if other permission is also restricted like Android. But it's a Linux Desktop that can easily run/install anything with `sudo`. Wayland should support advanced features.
OK then, if Wayland is meant for closed and user-hostile platforms, why is it being marketed as a X11 replacement? Why is there a constant FUD-included push to dissmis Xorg in favor of Wayland compositors?
When you dismiss any reasoning as "userhostile" and "FUD" it will be difficult to understand any change.
For the life of me I can't understand why so many people are always convinced that people who develop replacements for decades old frameworks do it only to spite users.
But the answer is: X sucks. It's 36 year old software with dozens of extensions. No one wants to write software that uses X, and apparently, per this HN submission, no one wants to maintain X.
OK, X sucks in a way (although your argumentation for that is wrong), but replacing X with Wayland is like trying to fit a square peg in a round hole. (Also, I don't think Wayland fits in any hole nicely, with it being hostile to even such basic and universally expected features such as taking a screenshot.)
I don't understand where you are going with your first paragraph, except that you are assuming things about others that you should not. Similarly with the second paragraph.
less than a minute. And it is second time in decade I've tried Wayland.
>>> why is it being marketed as a X11 replacement? Why is there a constant FUD-included push to dissmis Xorg in favor of Wayland compositors?
>> "FUD"
> Wayland is intended as a simpler replacement for X, easier to develop and maintain. [1]
"Intended" is not "ready". Could please cite your claims?
> replacing X with Wayland
Would you prefer if X.Org developers just abandoned it? We would have "X.Org is Abandonware" ten years ago.
And it is not zero sum game. These are different projects. People tried to fix X and failed. No one on this thread is going to maintain X.Org. But hope is not lost — another project have risen to maturity in last ten years. It covers some use cases and now you are bashing it because it is not perfect.
All of it while X.Org still works and I use it every day.
It is an X11 replacement. Just like CDs were a replacement for vynil records, and MP3 files were a replacement for CDs. But nobody expects to play records in a CD player.
Considering you're this deep in the discussion with your comment, you've managed to overlook quite a few expected and needed features that Wayland misses (or is even hostile to) compared to X, and which thus make your analogy obviously invalid. In fact I have to wonder if you're just trolling me.
The problems Wayland solve are those of yesteryear, sprinkled with the broken dreams that we'd all be running it on Linux phones by now. In that context a strict security model makes sense.
Trouble is, that security model makes no sense on today's desktop. In 2020, people aren't downloading and running native applications on desktops, not even (especially?) on Linux. The desktop is now solely a manager of browser windows. Everything that normal folks do is done through the browser, from email to office collaboration. Maybe a few Electron apps sprinkled in (mostly targeted for developers, ironically). Maybe the calculator? That's pretty much it.
The most important desktop apps today? Chrome and Zoom. Both which barely work in Wayland. But at least all that non-existent native desktop software can't now spy on my web mail? Too bad screen sharing is now a complete shitshow.
Actually worthwhile problems to solve on the desktop are for example high DPI and fractional scaling, rock-solid multi-monitor support, dynamically plugging in and removing displays, mixing displays of varying DPIs, high refresh rates and variable sync etc. The desktop will increasingly become a niche for high-end developer setups.
You must realise that many people use desktop applications for their work. The Office suite, the Adobe suite, AutoCAD, ArcGIS: whatever program is in use in the industry you are in.
>> In 2020, people aren't downloading and running native applications on desktops, not even (especially?) on Linux.
No, we download and run them in our web browsers because the operating systems (and X11) failed to implement security models that fit the modern world. Wayland is a move in the right direction here.
One more thing: the Wayland security model doesn't make much sense anyway, considering that running untrusted code over a large attack surface and without at least virtualization is probably a bad idea anyway nowadays (and even virtual machines can be escaped from).
> Trouble is, that security model makes no sense on today's desktop.
At least some users disagree. Flatpak and snap run applications in sandbox. I am to used for open source software, I fear installing closed source like Opera, MS Edge (not supported on Linux yet), Steam. And Steam with Proton is the next thing to bring Linux on the desktop.
Why are you comparing X11 and Wayland?
If something does not work on X.Org we are better with another project than with nothing. If Chrome and Zoom work on X.Org stick to it.
> massive fragmentation issues across the graphical part of the Linux ecosystem
This is a fair criticism. It is true that we see each of the compositors rolling its own extensions to the protocol. But I believe wayland is trying to standardize a lot of the protocols which should cover common use cases.
> each new compositor implementation reinvents the wheel many times
This is not true. There are libraries like wlroots[0] which you can build on top of. You don't have to redo the work that is already done in other compositors.
> application that needs to grab the entire screen will need separate code for each compositor it supports screenshots
There is the PipeWire[1] effort to support screenshot and screen capture on wayland in a unified way.
> Wayland is also, with its forced composition, hostile to interactive applications requiring low latency, e.g. video games.
Also not true. On a properly implemented compositor, video games frames shouldn't have longer latency to screen than on Xorg. X server has to do composition too, whether you run a compositor or not.
You're missing the point, which is that all of this should have been a part of Wayland, because "the desktops" will never agree on a common protocol.
Also, you're wrong that this isn't related to security, I can't be bothered to dig up some quotes right now, but it is/was actually very common to explain the lack of a screenshot feature on Wayland with security, and even to dismiss the feature altogether as a security issue.
Making it a part of Wayland would not have accomplished much. If the desktops really couldn't agree on a common protocol then you would end up with a bad standard that no desktop implements. See wl_shell for another reason why doing this in the core protocol would have likely been a mistake.
I don't know who was painting it as a security issue but they're mostly wrong. The security issue is in restricting use of those capabilities to only privileged applications. Maybe other (embedded?) compositors left that out entirely for security reasons, but GNOME and KDE always had plans to include screenshots, and wlroots has it too. Weston even had its screenshooter protocol for a while now but the other desktops decided not to use it and went their own way, for various reasons. (Full-featured screen capture is actually not as simple as you'd think, and it gets messier when pipewire and zero-copy capturing are on the table)
It likely won't ever be a drop-in replacement because a lot of X operations don't really make sense in Wayland. (Even in X, xdotool isn't perfect and a lot of its commands won't work if your window manager doesn't support the right hints) Unless you feel like volunteering to make a standard for this, you'll get the best mileage out of using an API specific to your compositor rather than waiting for someone else to come up with a standard. I know GNOME exports its internals with a javascript interface, and Sway has a way to run various commands using a JSON interface too.
I've added this comment to my favorites; a very succinct description of the problems with Wayland. At this point I wonder if starting from scratch was the right call vs. spending the 12 intervening years trying to (yes) dig into X11 and fix existing issues.
And it doesn't even mention the valuable features of X11 that were considered out of scope for wayland, such as network transparency.
It's really super useful being able to just fire up a program on a remote SSH session and get the window on my local computer. Without having to set up VNC and a window manager etc etc on the remote computer.
Of course this feature also needs a big review. It needs proper security (though tunneling over SSH fixes a lot of that) and there's too many back-and-forths in the protocol leading to it being really sluggish over high-latency connections. Makes sense as it was mainly invented for X-terminals on a local network. Also, more and more features like fonts are now rendered remotely instead of locally on the user's computer (the server in X terminology). NX and X2go fix that mostly but it would be great to have this in the actual protocol. As well as provisions for smooth video streaming.
As well as that, the whole computing industry is moving back from powerful endpoints (PCs) to powerful central computing (now cloud, the mainframes/powerful unix servers in the early days of X). So really, this feature will become more important again.
But yeah I would really prefer to see X11 being brought up to date rather than Wayland. Wayland is focused way too much on the local desktop.
X (at least nowadays) isn't very network transparent. Most things are done via shared buffers (it's faster than shoving bitmaps down a socket), with special fallbacks implemented by the clients, so that x forwarding doesn't break.
I know, also font rendering with anti-aliasing is usually done on the client side now (though the old way with font servers was far from ideal, it was much more bandwidth efficient!).. I know it's not perfect but they do this because the protocol lacks support for smooth video.
I'm just advocating a modernised X over moving to Wayland altogether, like the poster I replied to.
> > It has been almost a decade, why does Wayland not have a protocol definition for screenshots?" - answer - "Because security, dude! Wayland is designed with the thought that users download random applications from the interwebz which are not trustworthy and run them. Wayland actually makes a lot of sense if you don't think of Linux desktop distributions and desktop systems, but of smartphones.
The real problem of this "security" nonsense isn't even existing use cases like screenshot or xdotool but rather the cost it imposes on any future power tool that someone might think of but can't implement witout getting every compositor on board.
> Implementing a Wayland compositor requires much more effort than implementing an X11 window manager and each new compositor implementation reinvents the wheel many times, leaving users with less options for a desktop environment than on X11
At least if this helps to reduce fragmentation, so that we can have a decent desktop environment, instead of 4.000 half backed ones, could be something positive for Linux.
> Furthermore, there isn’t a standard API for getting screen shots from Wayland. It’s dependent on what compositor (window manager/shell) the user is running, and if they implemented a proprietary API to do so.
An xdotool (an input event automation tool, imagine wanting to inject or intercept input events) replacement is not possible on Wayland (without having separate support for each compositor, of course). These seem to be intentional design decisions (marketed as being necessary for security, but really being power-user hostile), this[0] Reddit comment puts it nicely:
> It has been almost a decade, why does Wayland not have a protocol definition for screenshots?" - answer - "Because security, dude! Wayland is designed with the thought that users download random applications from the interwebz which are not trustworthy and run them. Wayland actually makes a lot of sense if you don't think of Linux desktop distributions and desktop systems, but of smartphones. But for some reason we absolutely need this technology on the desktop, like we had not enough pain and lose ends over here without it.
But the lack of these features AFAIK also causes big trouble for users with special accessibility needs. Wayland is also, with its forced composition, hostile to interactive applications requiring low latency, e.g. video games.
[0] https://www.reddit.com/r/linux/comments/7lb5l7/new_screensho...