Hacker News Reader

Comment by INTPenis | Hacker News Reader

I thought so too, first impression is very good. Unfortunately I couldn't keep using it because you can't screen share in MS Teams with Wayland, and most games don't work in Wayland either.

So it was back to X11. Until screen sharing works in more apps, and until Proton/Wine games work I'm sticking to X11 and I'm not complaining.

View on HN

Have you tried Pipewire for screen sharing:

https://wiki.archlinux.org/title/PipeWire#WebRTC_screen_shar...

Doesn't help, Teams doesn't support pipewire yet.

I use Sway (and therefore Wayland) for everything except gaming; for that I switch to i3 (X11) on TTY2. Works great for me.

Back in the start of the century I used to run two X servers. One with a Linux desktop (tried various stuff) and one with Nvidia's proprietary kernel module, purely to play games, and have any crashes not lock up my whole machine. It worked beautifully. Eventually I switched to the red side, and I stayed there as much as possible.

I use Gnome+Wayland for gaming. I only had one problem for years that I used it. Something related to "Failed to initialize parser".

You can if you use it from an up-to-date web browser (or if microsoft would use an up-to-date electron build as a base).

This is absurd. Why would the browser matter for such a basic system functionality as screenshoting?

Because screenshotting is very security sensitive.

I don't think that's the problem. Browsers can do screenshotting correctly. MS Teams' Electron app can't. You can use the web version of teams in a browser to get around this issue.

Because it is an electron app, built on top of a browser that doesn’t use the correct build flags?

But why does the nature of the program matter at all? If a program writes a file on my home directory, I can read that file with other programs, regardless of the build flags of the first program. Why isn't my screen just the same? A program writes pixels to it, then I use another program to read them.

Having the pixels of your screen be more "sacred" than the files on your $HOME is a disturbingly bizarre security model.

Try writing to a file using linux kernel calls on windows — APIs matter.

Also, please have a look at here: https://news.ycombinator.com/item?id=30735099 This simply should not happen, any random executable having access to your $HOME is a terrible terrible practice.

> any random executable having access to your $HOME is a terrible terrible practice.

Running random executables is the only terrible practice here. If I run "cat" over a file on my $HOME, then I expect to see its contents, regardless of which program wrote the file. Similarly, if a program writes pixels on my screen, then I expect to be able to screenshot them.

Conversely, if I write a file in my $HOME, then I expect that other programs that I run will be able to read it. Similarly, if I write pixels on my screen, I should not be surprised that my other programs can read them.

Call me conspiracist, but this silly wayland security theater seems like a side of a multi-pronged attack to destroy the very principles of unix. First, screens; then, files. But you know what? You'll pry fopen and fread from my cold, dead hands!

> Similarly, if a program writes pixels on my screen, then I expect to be able to screenshot them.

You can screenshot it. Zoom or whatever else can’t do so without calling the respective APIs with the respective security policy (which by default is: giving you a popup to allow the request)

Have you seen my linked thread? Ok, let’s say `cat` works on behalf of you. Does `apt`, `npm` etc also do what it does on behalf of you? The problem is not only third-party code, but third-party data — any bug in the program can hijack the whole program at which point it no longer works on your behalf.

It isn't necessary that any particular program have access to $HOME, is it? That's often the most straightforward way for things to work, but anything can be run in a chroot jail or simply as another user.

Reply on news.ycombinator.com