NVIDIA Makes It Easier On Fedora To Try GNOME With EGLStreams On Wayland

[bug77]

That's why we need the new protocols to be defined by the best teams possible. That would be RH/GNOME since they have the $$$ and experienced hackers that maintain a toolkit.

Protocol is one thing. But hackers usually target implementations. And yes, you can have a perfectly designed protocol with a vulnerable implementation.

I assume that is one of the reason why Ubuntu team prefer gnome environment to Kde.

That's not why. Ubuntu actually used Gnome prior to Unity. They're merely switching back. Unity itself uses GTK, so they're already more familiar with that stack.

[Azrael5]

That's not why. Ubuntu actually used Gnome prior to Unity. They're merely switching back. Unity itself uses GTK, so they're already more familiar with that stack.

At that time wayland was not developed yet or it was in the first phase of development. However I assume that the developers have considered the intrinsic risk of xorg so to prefer gnome desktop environment to plasma (KDE) unable till now to implement wayland because of Qt.

[bug77]

At that time wayland was not developed yet or it was in the first phase of development. However I assume that the developers have considered the intrinsic risk of xorg so to prefer gnome desktop environment to plasma (KDE) unable till now to implement wayland because of Qt.

Right. What I've said is totally irrelevant, they've switched because of imaginary threats

[erendorn]

Yeah, because if anyone was smart enough to punch a hole in X, there's no chance in hell they'll punch a hole in Wayland's security module/framework. Though I admit, it's hard to hack into functionality that's not there.

There's no hole to punch in X. Every program has access to every inputs and outputs all the time, by design. You can find keygrabbers examples on stackoverflow that show the basic grabbing in 20 lines (xlib lets you see all other windows and send events to other windows, so you can intercept keystrokes by using the api itself). And all applications render in the same screen buffer, so they obviously have access to all of it.
In wayland, every program has acces to its own buffer only. The compositor (that's what compositors are for) merge these buffers into the final screen buffer. Each window doesn't know about other windows, and inputs are sent to their target application by the compositor.

So, yes, inwayland not all user level applications have access to the full screen and all inputs, and you need to implement a privilege system to access that. I'm a bit puzzled about how anyone can consider that a bad thing.

[bug77]

There's no hole to punch in X. Every program has access to every inputs and outputs all the time, by design. You can find keygrabbers examples on stackoverflow that show the basic grabbing in 20 lines (xlib lets you see all other windows and send events to other windows, so you can intercept keystrokes by using the api itself). And all applications render in the same screen buffer, so they obviously have access to all of it.
In wayland, every program has acces to its own buffer only. The compositor (that's what compositors are for) merge these buffers into the final screen buffer. Each window doesn't know about other windows, and inputs are sent to their target application by the compositor.

So, yes, inwayland not all user level applications have access to the full screen and all inputs, and you need to implement a privilege system to access that. I'm a bit puzzled about how anyone can consider that a bad thing.

I don't consider that a bad thing, I consider the lack of a screen shot utility a bad thing. I "shoot" my screen all the time (for bugs and what not) and somehow nobody exploited that till now. But since Wayland started, that seems to be such a big problem now, that the functionality cannot be provided any longer. That's just... wrong.

[JPFSanders]

So, yes, inwayland not all user level applications have access to the full screen and all inputs, and you need to implement a privilege system to access that. I'm a bit puzzled about how anyone can consider that a bad thing.

No, it is not a bad thing at all, what is bad and a massive problem problem is: that knowing such functionality will be universally needed (ti is obvious) it is not part of the core functionality implemented once, debugged once and tested once. (I may be wrong here and a universal mechanism is provided, but AFAIK it is not)

Everybody now has to choose between spending many months coding or relaxing things and conveniently implementing the X model on top of Wayland.

Guess which model is going to be the prevalent one. Yes the most convenient one, happens in real life all the time.

[bug77]

This pretty much sums the current desktop situation. We relied on bad designs, ego-driven developers spawn new forks all the time, ungrateful users demand feature parity even during major shifts.

GNOME is the beacon of hope. They just keep moving ahed with systemd, wayland and flatpak.

I'll take a bad design that works over a good design that doesn't any day, tyvm.

"GNOME is the beacon of hope." - get a life, it's just software.

[bug77]

Let me guess; you also prefer an old init system, and you prefer a strict dependency model without runtimes and sandboxing? Because all the flaws are better than temporary regressions.

I prefer flawed, working software over perfect and non-functional, yes.

And some food for thought: are you sure that by the time all the "temporary regressions" are addressed Wayland won't end up an uglier beast than X?

[bug77]

That depends on who designs and implements said protocols. RH/GNOME can do it, it is more easy if they remain the only consumer. This way there will be no rush to declare the interface stable.

Wrong. It depends on the problem being solved. If the problem is complex, a simple protocol cannot handle it. It will only handle a subset (which is what we're seeing in Wayland atm).

[TheOne]

Maybe the protocol could allow generating screen shots per application by a defineable shortcut that defaults to alt+prtscr and make part of the protocol a requirement where a question message dialog always ask the user to allow this. For complete desktop screenshot the protocol should define a similar behaviour where the compositor is the only piece that can generate a screenshot by listening to also a defineable key that defaults to prtscr, and it should also define an interface to render a question message dialog asking the user if he wants to proceed. The same protocol mechanism could be applied for screen recording where the compositor will always ask the user before executing the task,which should work around the security concerns.