4 ms·

You call it "hacks and abuses", but it's actually extensibility. Which Wayland kind of lacks (you need support for all of this in the compositor, rather than 3r

You call it "hacks and abuses", but it's actually extensibility. Which Wayland kind of lacks (you need support for all of this in the compositor, rather than 3rd party processes being able to provide it). > Do you honestly believe that wayland developers should reimplement all software that has leveraged and abused the X11 system? Most definitely not, but what they should do is just to _allow_ the continued existence of all the software which has leveraged X11 in their garden, if the garden is to have any kind of success. And not as 2nd grade citizens.

dijit 5y ago
Maybe we see it different because you’re looking at the affect and I’m looking at the capability. It might look like extensibility but it’s somewhat akin to your ISP having the ability to insert random HTML on a plaintext http stream. Of course, this is “extensible”, but it’s potentially dangerous. Your argument is that _your router_ is doing the same thing, adding HTML and JS elements to every web page to, idk, give you dark mode. It doesn’t mean it’s a good idea. Now, I can agree that it feels jarring to lose these things- but we should be looking to solve them the right ways.
- AshamedCaptain 5y ago
  The analogy is not correct, because in the case at hand, it is _by design_ that X11 allows this -- the entire "mechanism not policy" thing. And the problem with "it's potentially dangerous" is that you can use it as justification for removing any feature, so much that it doesn't really have any meaning left.
  - dijit 5y ago
    Hoo boy. X11 definitely wasn’t designed for this. It’s a byproduct of its (poor) design and the fact you can directly interfere with the renderer. It’s the same as the c64 not protecting memory addresses so you can poke memory to fuck with the video output, which people did, but the c64 is not a good computing platform in the modern age almost because of this. You might be better served by actually looking how X11 works, with quirks and what it was originally designed for, I promise you that your hair will stand on end. I should note: “potentially dangerous” is seriously downplaying a genuine problem linux had with keyloggers- it just wasn’t overly common because Linux is not a big enough platform for trojans to target, but it was known to be easy. Hugely easy.
    - AshamedCaptain 5y ago
      > You might be better served by actually looking how X11 works, with quirks and what it was originally designed for, I promise you that your hair will stand on end. You are confusing things. Where can you "interfere" with the renderer? What you can do is _replace_ the renderer. This is one extension point Wayland _forces_ on you, so what is your complain exactly? Manipulating things around using the ways provided for things to be manipulated is not a quirk. The server allows other processes to render to windows they don't own because this is how you implement decorations and the like. The server allows you to read the contents of windows you don't own because this is how you implement screen grabbers and color pickers. The server allows any two processes connected to it to communicate in any way because that is how clipboards and things like that are implemented. This is all by design. And that is the problem. If all of this was still possible with Wayland (WITHOUT having to patch the compositor), I'm certain there won't be as many complains. But no; they tried to fix "security" (for some definition of security) at the same time and thus had to spend a decade to see any hint of adoption. And face a lot of resistance. At least fetch the UNIX haters handbook if you want to see a minimally valid criticism to X... > but it was known to be easy. Hugely easy. Still is. Wayland or not. Therefore: Yes, I will downplay this issue. You would need an even more radical design to make it not trivial on Linux (e.g. passing individual input device descriptors to the process owning the focused window or the like, and then make each process a different user or god knows). Basically: something like Qubes (which used to do it with X11). And then face all the "it's not working!" complains because you break even more things.

dijit 5y ago

Maybe we see it different because you’re looking at the affect and I’m looking at the capability. It might look like extensibility but it’s somewhat akin to your ISP having the ability to insert random HTML on a plaintext http stream. Of course, this is “extensible”, but it’s potentially dangerous. Your argument is that _your router_ is doing the same thing, adding HTML and JS elements to every web page to, idk, give you dark mode. It doesn’t mean it’s a good idea. Now, I can agree that it feels jarring to lose these things- but we should be looking to solve them the right ways.

AshamedCaptain 5y ago
The analogy is not correct, because in the case at hand, it is _by design_ that X11 allows this -- the entire "mechanism not policy" thing. And the problem with "it's potentially dangerous" is that you can use it as justification for removing any feature, so much that it doesn't really have any meaning left.
- dijit 5y ago
  Hoo boy. X11 definitely wasn’t designed for this. It’s a byproduct of its (poor) design and the fact you can directly interfere with the renderer. It’s the same as the c64 not protecting memory addresses so you can poke memory to fuck with the video output, which people did, but the c64 is not a good computing platform in the modern age almost because of this. You might be better served by actually looking how X11 works, with quirks and what it was originally designed for, I promise you that your hair will stand on end. I should note: “potentially dangerous” is seriously downplaying a genuine problem linux had with keyloggers- it just wasn’t overly common because Linux is not a big enough platform for trojans to target, but it was known to be easy. Hugely easy.
  - AshamedCaptain 5y ago
    > You might be better served by actually looking how X11 works, with quirks and what it was originally designed for, I promise you that your hair will stand on end. You are confusing things. Where can you "interfere" with the renderer? What you can do is _replace_ the renderer. This is one extension point Wayland _forces_ on you, so what is your complain exactly? Manipulating things around using the ways provided for things to be manipulated is not a quirk. The server allows other processes to render to windows they don't own because this is how you implement decorations and the like. The server allows you to read the contents of windows you don't own because this is how you implement screen grabbers and color pickers. The server allows any two processes connected to it to communicate in any way because that is how clipboards and things like that are implemented. This is all by design. And that is the problem. If all of this was still possible with Wayland (WITHOUT having to patch the compositor), I'm certain there won't be as many complains. But no; they tried to fix "security" (for some definition of security) at the same time and thus had to spend a decade to see any hint of adoption. And face a lot of resistance. At least fetch the UNIX haters handbook if you want to see a minimally valid criticism to X... > but it was known to be easy. Hugely easy. Still is. Wayland or not. Therefore: Yes, I will downplay this issue. You would need an even more radical design to make it not trivial on Linux (e.g. passing individual input device descriptors to the process owning the focused window or the like, and then make each process a different user or god knows). Basically: something like Qubes (which used to do it with X11). And then face all the "it's not working!" complains because you break even more things.