Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Wayland vs. X – Overview

wayland.freedesktop.org

Post reply on HN
Print view View original

111–120 of 186 posts

Re: Wayland vs. X – Overview

#111

Post by yjftsjthsd-h »

bzzzt wrote: post #100
account42 wrote: post #84

Earlier quoted context omitted.

> They needed to do this Few things are ever truly needed . Those things don't include Wayland. That doesn't mean there are reasons for it but it does mean you can't just discard the downsides. > Xorg was complicated And Wayland will be complicated too by the time its mature. Especially when you include all the other compontents needed to provide the same functionality as X.org > Xorg was [...] insecure Under what th…

> Under what threat model? Personally I have no interest in the zero-trust model needed for proprietary app stores and would rather not pay the cost. Under the threat model of websites using browser exploits to grab other data on your system? Or under the threat model of company policy or legislation not allowing you to handle confidential information on a system that can't offer even a basic guarantee of privacy.

> Or under the threat model of company policy or legislation not allowing you to handle confidential information on a system that can't offer even a basic guarantee of privacy.

Last I'd checked, Windows had the same security issues as X, so it's unlikely to come up.

Re: Wayland vs. X – Overview

#112

Post by anthk »

vlovich123 wrote: post #41
BenjiWiebe wrote: post #22

Earlier quoted context omitted.

If those are insecurities, I want an insecure desktop. I use my computer to get things done, not be a paradigm of security.

Those aren't inherently insecurities, but the way X implemented them was quite insecure. Wayland is now having to do the heavy lifting of defining a secure protocol to implement it and migrating the entire Linux GUI ecosystem to using the new mechanisms. Also, I can take screenshots just fine on Wayland via KWin. I can't pick arbitrary 3p apps just yet but KWin's screenshotter is fine. Not sure about screen recording…

Again, I said this multiple times: XTerm/UXTerm has a secure mode to lock all input.

Re: Wayland vs. X – Overview

#113

Post by account42 »

bzzzt wrote: post #100
account42 wrote: post #84

Earlier quoted context omitted.

> They needed to do this Few things are ever truly needed . Those things don't include Wayland. That doesn't mean there are reasons for it but it does mean you can't just discard the downsides. > Xorg was complicated And Wayland will be complicated too by the time its mature. Especially when you include all the other compontents needed to provide the same functionality as X.org > Xorg was [...] insecure Under what th…

> Under what threat model? Personally I have no interest in the zero-trust model needed for proprietary app stores and would rather not pay the cost. Under the threat model of websites using browser exploits to grab other data on your system? Or under the threat model of company policy or legislation not allowing you to handle confidential information on a system that can't offer even a basic guarantee of privacy.

> Under the threat model of websites using browser exploits to grab other data on your system?

Browsers already have multiple layers of sandboxes. You can always add another one to the browser if you are paranoid.

Personally I prefer not running untrusted javascript in the first place (where I can avoid it). An exploit that gains control of the browser is already a doomsday scenario if you are using the browser for internet banking, work or anything that matters. Being able to grab the input and output of other applications is a nothingburger in comparison.

> Or under the threat model of company policy or legislation not allowing you to handle confidential information on a system that can't offer even a basic guarantee of privacy.

Those are usually fine with running countless proprietary drivers and tools with root access. So in other words it's security threater.

Re: Wayland vs. X – Overview

#114

Post by jsrjenkins »

bradrn wrote: post #40
dinkleberg wrote: post #37

Earlier quoted context omitted.

I think the place you get into trouble is when you try and DIY the config. I'm using Fedora and everything works perfectly out of the box. But when I was using arch and was trying out Sway (i3 + wayland) I was constantly running into issues.

Odd, I use Arch (well, EndeavourOS) with Sway and have experienced no problems. Quite on the contrary, my setup with a high-DPI laptop + external monitors is far nicer with Wayland than with X.

How is it nicer with Wayland? I have a high-DPI laptop and it works great with X11. What would I gain with Wayland?

Re: Wayland vs. X – Overview

#115

Post by biblbroxxx »

vlovich123 wrote: post #41
BenjiWiebe wrote: post #22

Earlier quoted context omitted.

If those are insecurities, I want an insecure desktop. I use my computer to get things done, not be a paradigm of security.

Those aren't inherently insecurities, but the way X implemented them was quite insecure. Wayland is now having to do the heavy lifting of defining a secure protocol to implement it and migrating the entire Linux GUI ecosystem to using the new mechanisms. Also, I can take screenshots just fine on Wayland via KWin. I can't pick arbitrary 3p apps just yet but KWin's screenshotter is fine. Not sure about screen recording…

Spectacle can record a screen, too. It works fine in general, but I had some issues with applications that were running with Xwayland.

Re: Wayland vs. X – Overview

#116

Post by DonHopkins »

hedora wrote: post #58
jbverschoor wrote: post #4

Earlier quoted context omitted.

Isn't only the transport layer of X insecure? That could be swapped out with another layer. With Wayland you have to use VNC which is fine for local networks, but not for remote ones.

There's nothing wrong with the transport layer's security, as far as I can tell. (For one thing, it's usually tunneled over SSH). The X11 security model assumes that anything with access to the screen has at least as much privilege as the user account that owns the session. In practice, that's true (things like flatpack claim to support fake sandboxing, but whatever.) Hypothetically, in a universe where Wayland was r…

> they're expecting all software to be rewritten.

ALL software was ALREADY rewritten for the web, so just use a web browser running directly on the hardware instead of bothering with X11 or Wayland or some hypothetical replacement like X12. That's just an extra useless layer that nobody needs.

A web browser is totally extensible and scriptable in JavaScript and WASM. Standards based. Excellent networking support. Streaming video. Secure sandboxing. Remote accelerated 2D and 3D graphics and GPU programming and WASM engine. Not rocket science. Off-the-shelf, well tested, open standards based solution. Problem already solved.

Why this is not the most obvious thing in the world since the Effrafax painted a mountain pink, and hasn't already been done, totally baffles me. It's as if the Linux community would much rather bicker and squabble about X11 -vs- Wayland for another 30 years than solve the problem once and for all and permanently and perfectly.

https://en.wikipedia.org/wiki/Somebody_else%27s_problem

>An SEP is something we can't see, or don't see, or our brain doesn't let us see, because we think that it's somebody else's problem. That’s what SEP means. Somebody Else’s Problem. The brain just edits it out, it's like a blind spot.

>The Somebody Else's Problem field... relies on people's natural predisposition not to see anything they don't want to, weren't expecting, or can't explain. If Effrafax had painted the mountain pink and erected a cheap and simple Somebody Else’s Problem field on it, then people would have walked past the mountain, round it, even over it, and simply never have noticed that the thing was there.

https://news.ycombinator.com/item?id=38442601

https://news.ycombinator.com/item?id=38442660

https://news.ycombinator.com/item?id=38445174

https://news.ycombinator.com/item?id=31988890

https://news.ycombinator.com/item?id=29094938

https://news.ycombinator.com/item?id=29097030

https://news.ycombinator.com/item?id=20182294

https://news.ycombinator.com/item?id=11484148

https://news.ycombinator.com/item?id=5844345

Re: Wayland vs. X – Overview

#117

Post by vetinari »

nolist_policy wrote: post #110
rhabarba wrote: post #86

Earlier quoted context omitted.

To be fair, X (VcXsrv) works on Windows and (XQuartz) pre-M1 macOS.

And Windows apparently has a Wayland compositor for WSL

They use RDP RAIL (RDP-for-a-single-window) on top of Weston, and then the resulting surfaces are managed by the DWM.

Which is actually an interesting approach; linux native compositors should "steal" that idea and implement it too. It could lead to RemoteApp-alike for Linux.

Re: Wayland vs. X – Overview

#118

Post by FirmwareBurner »

edent wrote: post #98
FirmwareBurner wrote: post #70

Earlier quoted context omitted.

>No idea. I'm using Pop OS. So you're being upvoted to the top by praising how flawless Wayland works on an OS that runs by default on X11? :)) Aww man, I hope there's a miscommunication somewhere, like you switched PopOS from X11 to Wayland, because otherwise this is HN comedy gold.

I had to do some pretty hardcore hacking to get Wayland working on Pop. I wrote it up at https://shkspr.mobi/blog/2020/05/fix-screen-tearing-on-rotat... Warning - you'll need to be at least a Level 17 Linux expert to understand the complexity involved.

Sorry. Thanks for the laugh :)

Re: Wayland vs. X – Overview

#119

Post by ndiddy »

bzzzt wrote: post #94
ndiddy wrote: post #59

Earlier quoted context omitted.

My main issue with Wayland is how big of a missed opportunity it is. If you're going to introduce a massive breaking change like this to modernize the Linux desktop, the least you can do is make it an actually compelling design. Wayland was originally created to fix the parts of Xorg that made it difficult to use it for embedded devices (digital signage, car infotainment systems, etc), so the base protocol only defin…

I don't see how a client application blocking its main event handler isn't broken? If you're going to do lots of work or blocking I/O you spin it off to another thread so UI updates will be handled without pause.

On desktop we don't have realtime scheduling. Processes can get descheduled for arbitrary amounts of time. This issue happens with well-behaved applications that don't block at all on their main event handler threads when the system is under high CPU or I/O load.

Re: Wayland vs. X – Overview

#120

Post by westurner »

superkuh wrote: post #75
icarito wrote: post #8

I suffer from the limitations of both X11 and Wayland. Some things work in one and not the other, it's a trade off. In Wayland I can use different scaling for each monitor (in exchange for a LOT of RAM). But in X11 I can use Barrier to share my mouse / keyboard with my other computer. So I use one when I have a second monitor and have to restart my session when I use a second computer :'( Please fix this!

It will be fixed on some Waylands with libei, but it will never be fixed on other waylands that find libei distasteful (like sway). And that's the waylands in a nutshell: many different things, never "wayland" always "waylands".

libei looks useful. But IDK why libei is necessary to run Barrier with Wayland?

For client systems, couldn't there just be a virtual /dev/input/XYZ that Barrier forwards events through

And for host systems, it looks like xev only logs input events when the window is focused.

Is xeyes still broken on Wayland, and how to fix it so that it would work with Barrier?

With Barrier, when the mouse cursor reaches a screen boundary, the keyboard and mouse input are then passed to a different X session on another box until the cursor again crosses a screen boundary rule.

Barrier is a fork of Synergy's open core: https://github.com/debauchee/barrier

libei: https://libinput.pages.freedesktop.org/libei/

Post reply on HN