Tbh I'd much rather fight this on the front of "let's not need to run untrusted and borderline malicious programs regularly" than breaking the free world in order to make it possible.
That fight was long long lost. We will never ever make things like video games open source. But we can sandbox them. Even open source tools could do with being sandboxed.
I don't see why this is an issue. The user still has full power to do anything and its is only programs which are restricted. Under the new model, instead of a tool just grabbing your screen, it must now make a request to the OS which will show a popup asking if you want to allow access and if you accept the program can continue as it would have before.
The issue I have with wayland is that it just continues to fragment the Linux desktop ecosystem, and it moved things to the toolkit that just don’t make sense there: I don’t want my window decorations to depend on whether the app is built with Qt or Gtk. I don’t want projects like McClim ( https://common-lisp.net/project/mcclim/ ) to depend on C code to communicate with the windowing system, etc.
So for window decorations, it's up to the app developer if they want to implement special behavior for client side decorations or not. If they do, there's nothing your toolkit or window manager can really do about it, you have to show the client's window decorations or you will lose functionality. Wayland has little to do with that.
About depending on C code, Wayland is pretty much the same as X11 there. If you don't want to use libwayland, you can write your own implementation of the wire protocol.
You didn't say hardware acceleration initially. If you need hardware acceleration you will have to link against Mesa/OpenGL for direct rendering anyway, which is a giant C library, so yeah the dependency on external C is somewhat unavoidable there under any windowing system.
If you consider linking against libGL and libEGL to be okay but not libwayland then there actually is a workaround: forget the EGL wayland platform and have your custom wayland implementation use the EGL GBM platform. There's some extra code you have to write here but unless something changed that I missed, the same problem exists with Xlib if you try to use the EGL X11 platform, or if you want to use direct rendering in GLX. (Mesa's libEGL/libGLX links against libX11 and expects to get a structure with the C ABI. Keep in mind if you are using GLX calls in that CLX library, you are probably not getting direct rendering, you would have to do a similar thing and reimplement the DRI2/DRI3 path from Mesa in your toolkit or application)
> That fight was long long lost. We will never ever make things like video games open source.
I don't share your pessimism.
Yes, it is harder to exploit users with [FLO] software; so there is less profit to be made; and that will discourage some companies from making it. But I can easily imagine that with a modest income from donations, a project like [Black Mesa] would be happy to make their game open source. Also yes, most software projects today cannot make a living off of donations. But there's no inherent reason this has to be so. People have shown they are willing to pay money for software; in principle, it is ["just"] a matter of redirecting that money from proprietary software to FLO software. And yes, solving the free-rider problem is a very ambitious "just".
But addressing a collective action problem like this requires a coordination mechanism, and the [existing crowdfunding platforms] don't have that. So, I am actively working on one that does — [Snowdrift.coop] — and am not yet ready to throw in the towel.
> But we can sandbox them. Even open source tools could do with being sandboxed.
I agree, but I don't think the operating system is the right level of abstraction to do this. Sandboxing is complex. Implementing it in the OS pushes that complexity on every program, which makes tinkering much harder. I absolutely do not want to have to deal with sandboxing and permission prompts in my .bashrc aliases and shell scripts. I write shell scripts to make my life easier by automating common actions, and having to set flatpak/SELinux type permissions every time I do that would defeat the purpose, or at least substantially raise the bar for how much friction is required before I turn to a script. Writing a simple program on Android/Linux is soo much more work than writing one for GNU/Linux, and soo much less accessible.
Also, we already have an excellent application sandboxing platform for running untrusted and borderline malicious programs — the web. The result of that sandboxing is incredible complexity which makes it a herculean task to develop a web browser. That's a real shame; I'd love to see the "web of documents" split off from the "web of applications" (e.g. to a different protocol, like gopher). I don't want to see desktop environments go the same way. When I install and run a program natively, I am indicating that I trust it and want to leave the restrictions and complexity of the web sandbox behind.
I do see a case to be made for a sandboxing tool for graphical applications specifically. Because building a GUI is already a lot of work compared to writing a CLI, so the relative effort to handle permissions, etc is not as large. But this should be built into and enforced by the packaging tool (e.g. flatpak permissions), not the operating system. And, to bring this discussion back on topic, not by the display manager.
Here's a concrete example: I use Mumble for voice chat. I use push-to-talk. [PTT on Wayland] doesn't work, because the display server only sends keyboard events to the client that has focus. You can look at the linked issue and see all the complexity that results. So for now I am still running X. Yes, there are workarounds. No, I don't want to have to deal with them. Not having to deal with them is the kind of nice thing we can't have if we accept sandboxing by default, rather than sandboxing only the few programs that we cannot trust to run directly on our machines.
