7 ms·

Most of those seem like a consequence of good design? I don't want one process to be able to decide that it's windows should be higher priority than another pr

Most of those seem like a consequence of good design? I don't want one process to be able to decide that it's windows should be higher priority than another process, or see what's displayed on another processes windows, or steal keystrokes from windows owned by another process. So I think the net effect of that list is to make me less likely to use Xorg.

armada651 4y ago
Good security doesn't prevent users from executing a legitimate use case though. A user can have legitimate reasons for wanting to share a certain window or their entire screen with a process like Zoom. Once you start preventing users from executing their use case you turn the user into an adversary. They'll start undermining your security model and you will always lose that fight. This is why permission models exist, make the user aware of the security implications and allow the user to decide on a per-app basis what permissions should be granted. Make the user complimentary to your security model rather than making them an adversary.
- hackerbrother 4y ago
  Is a standard Google Meet meeting in Chrome for Linux on a Wayland desktop not functional?
  - deleted 4y ago
    [deleted]
  - dralley 4y ago
    I use Google Meet on Firefox on Wayland. Screen sharing works fine (now). It didn't for a while, admittedly, but now it does.
    - linsomniac 4y ago
      I'm using Google Meet via Firefox on Ubuntu 22.04 and have not had any success with screen or window sharing, so YMMV.
  - dijit 4y ago
    Usually not, no. There are two processes that need to be running that somewhat work. xdg-desktop-portal & xdg-desktop-portal-wlr Even then it can be garbled, only supports one screen, and you can’t use it if the process was started under Xwayland - which is opaque when it’s being used. Might be better under Firefox, but chrome is spotty for me.
    - jhugo 4y ago
      Disabling Xwayland, if you can, makes wayland a much better experience. Not possible for everyone, as you may have software that doesn't work on Wayland, but I ran my daily driver Arch laptop with sway and no X at all for years, everything worked really well.
      - bitwize 4y ago
        Xwayland is probably going to be deprecated and removed anyway. It's only included for backward compatibility with "legacy applications". It's like DOS compatibility on Windows.
        deleted 4y ago
        [deleted]
        dijit 4y ago
        Sincerely hope not, I’ll be forced to go back to X11 for jetbrains tools and everything electron based. (as the version that ships almost never has wayland support enabled in the sandbox browser- and even force enabling it where it isn’t compiled out crashes it randomly) EDIT: why did I get downvoted for that? It’s extremely true and I’ve tried to run without Xwayland a lot.
        jhugo 4y ago
        With Chromium having decent Wayland support since a while now, I expect Electron apps will catch up eventually. A major DE deprecating Xwayland would give packagers of Electron apps a reason to get around to it.
- wmf 4y ago
  Wayland doesn't prevent anything that people need, but the APIs are different and apps need to be ported. (Worst case, certain features need to be implemented in the compositor itself not in an app.)
  - nicce 4y ago
    Yeah. The most of the screen sharing and recording issues are easily solvable. It just takes engineering time, and time is money. As from the global user space, Wayland is in minority, for example for Zoom to create proper support.
- Nursie 4y ago
  > Once you start preventing users from executing their use case you turn the user into an adversary. I'm reminded of an early systemd security choice that killed all of a users processes on logout, for 'security'. Because they didn't personally have the use-case of wanting to fire off long-running jobs, so didn't consider it. (I'm not raging at systemd, I like the unit files and while I have some concerns about the design, in general I believe it's a positive thing to have around. IIRC this issue was fixed fairly quickly when it came to light.)
  - usrn 4y ago
    They still do this. It really sucks when you don't expect it. I wish the people who wanted all this crap would just go run ChromeOS since it does what they want better anyway.
    - Izkata 4y ago
      Downvoters: The systemd default really is still to do this, it's just become less obvious because individual distros have been changing it since the initial fallout instead of accepting systemd's default configs.
      - Nursie 4y ago
        Really? Wow that is crappy. Yeah I haven't encountered it since way-back, partly because my use-cases have changed but also quite likely because debian and ubuntu (my general distros of choice) have configured it better.
        kaba0 4y ago
        From a theoretical view, why is it a bad thing? I very much want my OS/service-manager to.. manage services and upon terminating my session, nothing should continue to run under it. Put another way, would you expect to get a higher bill on some cloud provider because after logout some userspace process (say, a dev server) continued to chug along? I do understand Hyrum’s law and that there are legitimate programs depending on decades old hacks like ignoring OS signals instead of exiting for some functionality - that could not be implemented other way back than. But these are trivially portable to user services that are meant to linger after logout (but hurrdurr, why depend even more on evil systemd) with like a few lines of configuration, solving all of these problems. Just remember, after a while every observable behavior of a program will be dependent on. If the alternative is forever stagnation, I very much prefer evolution and some manageable breaking changes instead.
Karunamon 4y ago
Sometimes those things are necessary for completely normal, non-nefarious use cases. Instead of giving you the option, you're not allowed to do it at all in the name of Safety® I'm really not a fan of software being this presumptuous. The root of most of my gripes with things like Windows and macOS (not to mention most of the things gnome/freedesktop puts out) are entirely because of this mindset. I am not interested in infecting Linux with this baby-proofing as well. Security maximalists, especially when removing or refusing to implement useful functionality as a result of that stance, should be reminded that the first pillar of security is availability.
- Hizonner 4y ago
  Wanting to run programs without them being able to screw around with one another is a use case... and it's more a more common, fundamental one than wanting to run remote video conferencing or whatever. More to the point, you can always add the ability to do stuff like that, when you have the time to do it in a way that lets the user decide what should and should not have any given kind of access. On the other hand, if you start out by just letting everything run amok and then try to add controls later, assumptions will get changed underneath existing programs. That pretty much always makes things break in ugly ways... if it's even possible to do it at all, which is not guaranteed if you didn't think hard before you designed the function to begin with.
  - michaelmrose 4y ago
    Remote video conferencing is vastly more popular than Linux at this point with work from home, remote doctors appointments, and travel issues. It's now something your 70 year grandmother who doesn't understand computers does.
    - Hizonner 4y ago
      My 70 year old grandmother (who'd only be about 10 years older than I am, which is a bit strange...) ALSO runs other programs all the time, and does not expect them to interfere with one another in confusing or malicious ways.
Silhouette 4y ago
The main problem with Wayland seems to be that it's trying to fix some real problems such as those you mentioned but its solution is to build the house as a concrete and steel box without doors or windows. It's true that it's a more secure building that way but since it doesn't work as a house any more that doesn't really matter.
- kaba0 4y ago
  The wayland approach is indeed to build a house and it already has windows and doors for it (though perhaps the painting is not ready). But that is much easier to do than not getting soaked in the rain when all you have is a door in the middle of nowhere.
ironmagma 4y ago
This is peak “why do you want that?” An anti-pattern in OSS communities.
- favorited 4y ago
  No, it's not. It's acknowledging that this is a new protocol, and is intentionally not designed to be a drop-in replacement for X because it makes different trade-offs. Do you really think that Linux users are asking "why do you want that?" about screen sharing applications? Of course not. You can't implement screen sharing the same way you did in X, and software will need to change if it wants to support Wayland.
  - noobermin 4y ago
    Quite the statement on an article that lists the biggest apps for screenrecording (like obs) saying wayland is broken and they won't work with it. Just pure persistence in the face of contrary evidence in front of your eyes. If OBS can't figure out how to support wayland there's something wrong with wayland.
    - byteduck 4y ago
      This gist is from 2020. OBS does support Wayland now, AFAIK.
  - ironmagma 4y ago
    It falls into a general bucket of vaguely gaslighting behavior wherein the person talking about how a particular use case is important, is met with the claim that it isn’t because of some reason (either it’s not a good use case, software design shouldn’t allow it, or it’s “already possible” in some convoluted way). This isn’t a unique situation, this kind of response happens over and over in the Linux community.
    - favorited 4y ago
      Except no one ever said “software design shouldn’t allow it,” which is the claim here. They said “this software won’t implement that feature the same way that other did, so there will need to be wider changes.” Which shouldn’t surprise anyone changing their display server.
usrn 4y ago
I'm currently in the "X11 is still better group" but I will say the way QT does modals on X drives me up the wall and it would be nice to have something force it to behave.
josephcsible 4y ago
I don't want most of my processes to be able to do those things, but I do want some to. And if my only choices are all of my processes being able to do those things, or none of them being able to, I'd take the former.
akho 4y ago
> I don't want one process to be able to decide that it's windows should be higher priority than another process, or see what's displayed on another processes windows, or steal keystrokes from windows owned by another process. The traditional, greybeard way to deal with a misbehaving application is to stop using it. This “security” approach breaks all other applications instead.

armada651 4y ago

Good security doesn't prevent users from executing a legitimate use case though. A user can have legitimate reasons for wanting to share a certain window or their entire screen with a process like Zoom. Once you start preventing users from executing their use case you turn the user into an adversary. They'll start undermining your security model and you will always lose that fight. This is why permission models exist, make the user aware of the security implications and allow the user to decide on a per-app basis what permissions should be granted. Make the user complimentary to your security model rather than making them an adversary.

hackerbrother 4y ago
Is a standard Google Meet meeting in Chrome for Linux on a Wayland desktop not functional?
- deleted 4y ago
  [deleted]
- dralley 4y ago
  I use Google Meet on Firefox on Wayland. Screen sharing works fine (now). It didn't for a while, admittedly, but now it does.
  - linsomniac 4y ago
    I'm using Google Meet via Firefox on Ubuntu 22.04 and have not had any success with screen or window sharing, so YMMV.
- dijit 4y ago
  Usually not, no. There are two processes that need to be running that somewhat work. xdg-desktop-portal & xdg-desktop-portal-wlr Even then it can be garbled, only supports one screen, and you can’t use it if the process was started under Xwayland - which is opaque when it’s being used. Might be better under Firefox, but chrome is spotty for me.
  - jhugo 4y ago
    Disabling Xwayland, if you can, makes wayland a much better experience. Not possible for everyone, as you may have software that doesn't work on Wayland, but I ran my daily driver Arch laptop with sway and no X at all for years, everything worked really well.
    - bitwize 4y ago
      Xwayland is probably going to be deprecated and removed anyway. It's only included for backward compatibility with "legacy applications". It's like DOS compatibility on Windows.
      - deleted 4y ago
        [deleted]
      - dijit 4y ago
        Sincerely hope not, I’ll be forced to go back to X11 for jetbrains tools and everything electron based. (as the version that ships almost never has wayland support enabled in the sandbox browser- and even force enabling it where it isn’t compiled out crashes it randomly) EDIT: why did I get downvoted for that? It’s extremely true and I’ve tried to run without Xwayland a lot.
        jhugo 4y ago
        With Chromium having decent Wayland support since a while now, I expect Electron apps will catch up eventually. A major DE deprecating Xwayland would give packagers of Electron apps a reason to get around to it.
wmf 4y ago
Wayland doesn't prevent anything that people need, but the APIs are different and apps need to be ported. (Worst case, certain features need to be implemented in the compositor itself not in an app.)
- nicce 4y ago
  Yeah. The most of the screen sharing and recording issues are easily solvable. It just takes engineering time, and time is money. As from the global user space, Wayland is in minority, for example for Zoom to create proper support.
Nursie 4y ago
> Once you start preventing users from executing their use case you turn the user into an adversary. I'm reminded of an early systemd security choice that killed all of a users processes on logout, for 'security'. Because they didn't personally have the use-case of wanting to fire off long-running jobs, so didn't consider it. (I'm not raging at systemd, I like the unit files and while I have some concerns about the design, in general I believe it's a positive thing to have around. IIRC this issue was fixed fairly quickly when it came to light.)
- usrn 4y ago
  They still do this. It really sucks when you don't expect it. I wish the people who wanted all this crap would just go run ChromeOS since it does what they want better anyway.
  - Izkata 4y ago
    Downvoters: The systemd default really is still to do this, it's just become less obvious because individual distros have been changing it since the initial fallout instead of accepting systemd's default configs.
    - Nursie 4y ago
      Really? Wow that is crappy. Yeah I haven't encountered it since way-back, partly because my use-cases have changed but also quite likely because debian and ubuntu (my general distros of choice) have configured it better.
      - kaba0 4y ago
        From a theoretical view, why is it a bad thing? I very much want my OS/service-manager to.. manage services and upon terminating my session, nothing should continue to run under it. Put another way, would you expect to get a higher bill on some cloud provider because after logout some userspace process (say, a dev server) continued to chug along? I do understand Hyrum’s law and that there are legitimate programs depending on decades old hacks like ignoring OS signals instead of exiting for some functionality - that could not be implemented other way back than. But these are trivially portable to user services that are meant to linger after logout (but hurrdurr, why depend even more on evil systemd) with like a few lines of configuration, solving all of these problems. Just remember, after a while every observable behavior of a program will be dependent on. If the alternative is forever stagnation, I very much prefer evolution and some manageable breaking changes instead.

Karunamon 4y ago

Sometimes those things are necessary for completely normal, non-nefarious use cases. Instead of giving you the option, you're not allowed to do it at all in the name of Safety® I'm really not a fan of software being this presumptuous. The root of most of my gripes with things like Windows and macOS (not to mention most of the things gnome/freedesktop puts out) are entirely because of this mindset. I am not interested in infecting Linux with this baby-proofing as well. Security maximalists, especially when removing or refusing to implement useful functionality as a result of that stance, should be reminded that the first pillar of security is availability.

Hizonner 4y ago
Wanting to run programs without them being able to screw around with one another is a use case... and it's more a more common, fundamental one than wanting to run remote video conferencing or whatever. More to the point, you can always add the ability to do stuff like that, when you have the time to do it in a way that lets the user decide what should and should not have any given kind of access. On the other hand, if you start out by just letting everything run amok and then try to add controls later, assumptions will get changed underneath existing programs. That pretty much always makes things break in ugly ways... if it's even possible to do it at all, which is not guaranteed if you didn't think hard before you designed the function to begin with.
- michaelmrose 4y ago
  Remote video conferencing is vastly more popular than Linux at this point with work from home, remote doctors appointments, and travel issues. It's now something your 70 year grandmother who doesn't understand computers does.
  - Hizonner 4y ago
    My 70 year old grandmother (who'd only be about 10 years older than I am, which is a bit strange...) ALSO runs other programs all the time, and does not expect them to interfere with one another in confusing or malicious ways.

Silhouette 4y ago

The main problem with Wayland seems to be that it's trying to fix some real problems such as those you mentioned but its solution is to build the house as a concrete and steel box without doors or windows. It's true that it's a more secure building that way but since it doesn't work as a house any more that doesn't really matter.

kaba0 4y ago
The wayland approach is indeed to build a house and it already has windows and doors for it (though perhaps the painting is not ready). But that is much easier to do than not getting soaked in the rain when all you have is a door in the middle of nowhere.

ironmagma 4y ago

This is peak “why do you want that?” An anti-pattern in OSS communities.

favorited 4y ago
No, it's not. It's acknowledging that this is a new protocol, and is intentionally not designed to be a drop-in replacement for X because it makes different trade-offs. Do you really think that Linux users are asking "why do you want that?" about screen sharing applications? Of course not. You can't implement screen sharing the same way you did in X, and software will need to change if it wants to support Wayland.
- noobermin 4y ago
  Quite the statement on an article that lists the biggest apps for screenrecording (like obs) saying wayland is broken and they won't work with it. Just pure persistence in the face of contrary evidence in front of your eyes. If OBS can't figure out how to support wayland there's something wrong with wayland.
  - byteduck 4y ago
    This gist is from 2020. OBS does support Wayland now, AFAIK.
- ironmagma 4y ago
  It falls into a general bucket of vaguely gaslighting behavior wherein the person talking about how a particular use case is important, is met with the claim that it isn’t because of some reason (either it’s not a good use case, software design shouldn’t allow it, or it’s “already possible” in some convoluted way). This isn’t a unique situation, this kind of response happens over and over in the Linux community.
  - favorited 4y ago
    Except no one ever said “software design shouldn’t allow it,” which is the claim here. They said “this software won’t implement that feature the same way that other did, so there will need to be wider changes.” Which shouldn’t surprise anyone changing their display server.

usrn 4y ago

I'm currently in the "X11 is still better group" but I will say the way QT does modals on X drives me up the wall and it would be nice to have something force it to behave.

josephcsible 4y ago

I don't want most of my processes to be able to do those things, but I do want some to. And if my only choices are all of my processes being able to do those things, or none of them being able to, I'd take the former.

akho 4y ago

> I don't want one process to be able to decide that it's windows should be higher priority than another process, or see what's displayed on another processes windows, or steal keystrokes from windows owned by another process. The traditional, greybeard way to deal with a misbehaving application is to stop using it. This “security” approach breaks all other applications instead.