14 ms·

Sway (the window manager) _is_ the compositor. There is no need for a separate program like compiz or picom.

sprash 6y ago
Which is a mistake. On X11 the server, window manager and compositor are three separate programs. Both window manager and compositor can individually crash, started, stopped and replaced at runtime without any of the other running X11 client instances affected.
- ubercow13 6y ago
  On the other hand on X11, Xorg cannot crash without the X11 client instances being affected - a much larger chunk of code. It's only because Xorg is older that that doesn't happen much.
  - sprash 6y ago
    A chunk of code that is running in production for more than 30 years and should be considered battle tested. In my experience Wayland compositors crash much more often than X11 despite the supposed reduced complexity. The last time X11 server crashed on me was in 2004 if I remember correctly.
    - ubercow13 6y ago
      Exactly, that reliability of Xorg is a function of its age and doesn't imply anything about the correct design of a Wayland compositor. What's the chance those Wayland crashes were in the window management code rather than the rendering, protocol, clipboard, and drag/drop handling code? dwm is 2000 SLOC to Xorg's 1 million or so. I don't think splitting out the WM code would have gained much.
      - sprash 6y ago
        You underestimate the inherent complexity of Wayland. As exercise I recommend to implement a "Hello World" native Wayland client. Watch and see the complexity explode when you simply want to add the functionality to take screenshots to that client.
        cycloptic 6y ago
        I'm not sure what kind of "Hello World" clients you're comparing, but if you check the Wayland backends in Gtk/Qt, you will actually find them to be smaller than the respective X11/XCB backends there, for various reasons.
        sprash 6y ago
        I'm specifically not talking about toolkits. I'm talking about a "simple" native Wayland client. Try to write one and witness utter insanity.
        cycloptic 6y ago
        Can you be more specific about what are you comparing this to? An X client with similar functionality would likely be longer and require several X extensions.
        jude- 6y ago
        > you will actually find them to be smaller than the respective X11/XCB backends there, for various reasons. It doesn't seem surprising to me. As X.org has gained extensions over the last 30 years, toolkits that speak X11 find themselves having to decide which extensions they'd like to use. Adding flexibility on this naturally leads to a bigger feature matrix. Of course, the toolkits are also free to drop support for X servers that don't have those extensions, which in turn would shrink the X11 backend. I have no doubt that in 30 years, they'll have a similarly-sized feature matrix for all the Wayland extensions they'll want to support.
        cycloptic 6y ago
      - jude- 6y ago
        How much of that 1 million lines of code actually gets executed? Also, everyone runs the X server, so its code gets a lot of testing. This isn't true for window managers -- there's a long tail of them. This is just one data point, but in my experience I've had window managers crash far more often than X servers (since they get less love).
      - wander_homer 6y ago
        Actually most of the crashes I had with Sway were in fact related to compositing and window management. including stupid stuff like crashing because sway couldn't decide which window to focus after hiding another.
jude- 6y ago
Yes. That's the problem. Not only is the resulting stack less resilient to crashes, but also it takes away flexibility by needlessly welding together two orthogonal design concerns (window management vs rendering). Sway is like putting X11, the window manager, the global hotkey daemon, screenshot grabber, and so on, all into the same address space. What could possibly go wrong? /s Regarding security, I'm honestly surprised no one has just tried to make it so you can "firewall" X11 programs from one another. Like, aren't keystrokes propagated as packets sent through an X11-owned UNIX domain socket in /tmp? Can't we just attach a policy to that socket to decide which PIDs (or process groups, session groups, containers, etc.) get to see which messages?
- sprash 6y ago
  > I'm honestly surprised no one has just tried to make it so you can "firewall" X11 programs This can be done via firejail[1] + xpra/xephyr but is a rather cumbersome endeavor. The X11 standard also contains access control hooks that allow you to "firewall" any aspect of your application. However it is used by no application I personally know of and is rendered useless by how the xinput mechanism is implemented at this point. The reason nobody bothered to deal with this so far is that people almost never run untrusted software on FOSS systems which is what X11 primarily targets. There was no demand. 1.: https://firejail.wordpress.com/documentation-2/x11-guide/ https://firejail.wordpress.com/documentation-2/x11-guide/
  - cycloptic 6y ago
    The demand there would be with products like Qubes and Subgraph, which are currently using Xephyr and Xpra. Eventually Wayland should be able to improve performance there, and bring some of the security benefits of those setups to other distributions.
    - jude- 6y ago
      Seems to me that firewalling X11 programs from one another would take a lot less work and be a lot less disruptive than requiring users to run multiple VMs with multiple X11 servers and/or replace the whole graphics stack.

Which is a mistake. On X11 the server, window manager and compositor are three separate programs. Both window manager and compositor can individually crash, started, stopped and replaced at runtime without any of the other running X11 client instances affected.

ubercow13 6y ago
On the other hand on X11, Xorg cannot crash without the X11 client instances being affected - a much larger chunk of code. It's only because Xorg is older that that doesn't happen much.
- sprash 6y ago
  A chunk of code that is running in production for more than 30 years and should be considered battle tested. In my experience Wayland compositors crash much more often than X11 despite the supposed reduced complexity. The last time X11 server crashed on me was in 2004 if I remember correctly.
  - ubercow13 6y ago
    Exactly, that reliability of Xorg is a function of its age and doesn't imply anything about the correct design of a Wayland compositor. What's the chance those Wayland crashes were in the window management code rather than the rendering, protocol, clipboard, and drag/drop handling code? dwm is 2000 SLOC to Xorg's 1 million or so. I don't think splitting out the WM code would have gained much.
    - sprash 6y ago
      You underestimate the inherent complexity of Wayland. As exercise I recommend to implement a "Hello World" native Wayland client. Watch and see the complexity explode when you simply want to add the functionality to take screenshots to that client.
      - cycloptic 6y ago
        I'm not sure what kind of "Hello World" clients you're comparing, but if you check the Wayland backends in Gtk/Qt, you will actually find them to be smaller than the respective X11/XCB backends there, for various reasons.
        sprash 6y ago
        I'm specifically not talking about toolkits. I'm talking about a "simple" native Wayland client. Try to write one and witness utter insanity.
        cycloptic 6y ago
        Can you be more specific about what are you comparing this to? An X client with similar functionality would likely be longer and require several X extensions.
        jude- 6y ago
        > you will actually find them to be smaller than the respective X11/XCB backends there, for various reasons. It doesn't seem surprising to me. As X.org has gained extensions over the last 30 years, toolkits that speak X11 find themselves having to decide which extensions they'd like to use. Adding flexibility on this naturally leads to a bigger feature matrix. Of course, the toolkits are also free to drop support for X servers that don't have those extensions, which in turn would shrink the X11 backend. I have no doubt that in 30 years, they'll have a similarly-sized feature matrix for all the Wayland extensions they'll want to support.
        cycloptic 6y ago
    - jude- 6y ago
      How much of that 1 million lines of code actually gets executed? Also, everyone runs the X server, so its code gets a lot of testing. This isn't true for window managers -- there's a long tail of them. This is just one data point, but in my experience I've had window managers crash far more often than X servers (since they get less love).
    - wander_homer 6y ago
      Actually most of the crashes I had with Sway were in fact related to compositing and window management. including stupid stuff like crashing because sway couldn't decide which window to focus after hiding another.

jude- 6y ago

Yes. That's the problem. Not only is the resulting stack less resilient to crashes, but also it takes away flexibility by needlessly welding together two orthogonal design concerns (window management vs rendering). Sway is like putting X11, the window manager, the global hotkey daemon, screenshot grabber, and so on, all into the same address space. What could possibly go wrong? /s Regarding security, I'm honestly surprised no one has just tried to make it so you can "firewall" X11 programs from one another. Like, aren't keystrokes propagated as packets sent through an X11-owned UNIX domain socket in /tmp? Can't we just attach a policy to that socket to decide which PIDs (or process groups, session groups, containers, etc.) get to see which messages?

sprash 6y ago
> I'm honestly surprised no one has just tried to make it so you can "firewall" X11 programs This can be done via firejail[1] + xpra/xephyr but is a rather cumbersome endeavor. The X11 standard also contains access control hooks that allow you to "firewall" any aspect of your application. However it is used by no application I personally know of and is rendered useless by how the xinput mechanism is implemented at this point. The reason nobody bothered to deal with this so far is that people almost never run untrusted software on FOSS systems which is what X11 primarily targets. There was no demand. 1.: https://firejail.wordpress.com/documentation-2/x11-guide/ https://firejail.wordpress.com/documentation-2/x11-guide/
- cycloptic 6y ago
  The demand there would be with products like Qubes and Subgraph, which are currently using Xephyr and Xpra. Eventually Wayland should be able to improve performance there, and bring some of the security benefits of those setups to other distributions.
  - jude- 6y ago
    Seems to me that firewalling X11 programs from one another would take a lot less work and be a lot less disruptive than requiring users to run multiple VMs with multiple X11 servers and/or replace the whole graphics stack.