Hacker News Reader

Comment by quotemstr | Hacker News Reader

More specifically, I want to give some applications the ability to place windows where they want, warp the mouse, grab certain keys globally, snoop input, and so on. And I want to give other applications a small sandbox where they can't steal focus or hurt anything.

X11 could have been evolved in this direction by sandboxing applications within little mini-universes within the existing protocol. Windows solved this problem without breaking compatibility: https://en.wikipedia.org/wiki/User_Interface_Privilege_Isola...

I have a fundamental philosophical disagreement with the Wayland and GNOME camp. They believe that they can enumerate all interesting use cases and that each app should fit in one of their pre-defined boxes. I'm old school and believe in making systems that provide mechanism, not policy, and that give applications the ability to do unanticipated things.

View on HN

>I want to give some applications the ability to place windows where they want, warp the mouse, grab certain keys globally, snoop input, and so on.

This is already how it works. The plan with GNOME and wayland is to put those in the xdg desktop portal so they can be subject to whatever security policy is appropriate. Really, nothing has changed here in regards to how much mechanism is provided or not.

And FYI, X11 can already be sandboxed using those methods in combination with firejail: https://firejail.wordpress.com/documentation-2/x11-guide/

Why don't you propose a protocol to solve the issues you have? If it solves a problem other users have it would get adopted I'm sure (except maybe GNOME).

I'm not a Wayland developer but it's what I observed in the issue tracker of my WM. A limitation is often overcome by a protocol and a basic implementation after. If you put the work in, the wlroots and KDE people are always very nice and will help you get started.

https://github.com/wayland-project/wayland-protocols/tree/ma...

https://github.com/swaywm/wlr-protocols/tree/master/unstable

They did propose a protocol: X11 plus sandboxing, modeled after the windows approach to sandboxing.

And they are free to continue adding features and maintaining their preferred software choices. Nobody else seems to want to do it. IIRC the X11 maintainers are the same people who started Wayland.

> https://blogs.gnome.org/uraeus/2019/06/24/on-the-road-to-fed...

> Once we are done with this we expect X.org to go into hard maintenance mode fairly quickly. The reality is that X.org is basically maintained by us and thus once we stop paying attention to it there is unlikely to be any major new releases coming out and there might even be some bitrot setting in over time. We will keep an eye on it as we will want to ensure X.org stays supportable until the end of the RHEL8 lifecycle at a minimum, but let this be a friendly notice for everyone who rely the work we do maintaining the Linux graphics stack, get onto Wayland, that is where the future is.

But we were talking about Wayland here. You're free of course to fantasize about hypothetical scenarios or propose features to software nobody wants to maintain.

Yeah, the end game for this seems pretty horrible. Wayland (still) doesn’t work, and is user-hostile (at least for this user). The BSD’s and most applications I use seem to be sticking with x.org.

Maybe this is the end of portable, open source video stacks.

One of the problems is that X is effectively being deprecated in favor of something that isn't X 2.0: it has different goals, different targets, different ideologies, and not to mention different architecture.

Eg Wayland is unashamedly Linux-centric (mind you, definitely not the same as Linux exclusive), while X most definitely isn't. One was designed to allow for remote rendering, one wasn't. One integrates the window manager functionality and one doesn't. The list of course goes on.

The things you list have not really been true in the real world for a long time. Modern Xorg uses the same Linux exclusive APIs as Wayland, is not network transparent, relies heavily on window manager and compositor features, etc. Modern Xorg and Wayland are more or less conceptually identical. Wayland just replaces the X server with a UNIX socket and has a clean slate for APIs.

Or, in another words, Wayland is the same as the modern X, minus the legacy core that couldn't be removed from X because it is not extension (anyone using stippled unaliased lines yet?) and plus sandboxing.

1. You're conflating X and Xorg.

2. Network transparency is still there and I use it everyday. The problem is toolkits (GTK and others) who decided it would be 'simpler' to redo everything themselves in a canvas. Of course the result of not taking advantages of X primitives was a massive slowdown over the network.

3. Wayland sits at an odd place, not having the advantages of being a proper protocol in the sense of X (complete abstraction from the substrate), while at the same time not having the advantages of being a direct API to hardware (simplicity, performance).

I have found that “OK, why don’t you just do xyz if you think you’re so smart” shuts down interesting discussion, and that’s what you’ve been doing here. Would you be willing to not do that or explain why you think that isn’t the case here?

No, it does not shut down discussion, it shuts down bikeshedding. There's a large peanut gallery with strong opinions how they would do it, but because they never did something similar, they have no idea what they are talking about and what trade-offs are involved.

Unsurprisingly, people who know these things, for example because they develop it, may disagree with the peanut gallery and do it in a way they consider the best.

I would much rather hear a reason why something wouldn’t work than the responses saying “ok, how would you do it” and “ok, well someone would have done that if it was legitimate but they didn’t”.

It's not that simple; explaining one reason why something would not work means re-examing many of the underlying assumptions and not many like to go deeper than that one problem at hand in isolation. The "ok, how would you do it" forces thinking about underlying issues, because the solution you propose has to account for factors you otherwise wouldn't think of.

It is not a new problem either; this video is 9 years old already: https://www.youtube.com/watch?v=ZTdUmlGxVo0. It is almost one hour long, but well worth to watch to see the two different approaches to clash.

Reply on news.ycombinator.com