Valve Engineer Mike Blumenkrantz Hoping To Accelerate Wayland Protocol Development

[hf_139]

Nobody sane claimed that, ever.

I agree that no sane person ever claimed that. Waylanders claimed it and they are not sane people.

CSD is inherently insecure. There is no way to cope here. Any application can scam you. If you are worried about hotkeys and screensharing "vulnerabilities", you have to admit that CSD is an insecure fad that Gnome fell for during Windows 8 times and doubled down on.

[Artim]

Good question how does the crash happen.



I am about to answer that question and when do you will need to take this back.

Why would I when you only prove me right?

There is a little bit of system evil on Linux.
https://www.kernel.org/doc/gorman/ht...rstand016.html

This one sentence already completely disqualifies you from this discussion, but hey, you had to further explain your utter lack of knowledge...

The out of memory manager. It picks processes to terminate as in kernel causes to crash due to resource usage this is based on oom_score you can cause a X11 windows manager to have a horrible oom_score based on just having a process create and destroy windows repeatedly. The application doing this will have it oom_score growing at a low rate than the X11 Windows manager.

What does that have to do with anything? We are talking about Wayland, not X11. And if oom is done this terribly that it will kill X11/it's WM instead of the process actually running amok, you clearly have other issues.

Maybe if you have a SSD application trying to pull a denial of service attack on you interface to cause you interface to repeatably be terminate maybe you will not be wanting to straight up restart that SSD functionality.

Why would anyone want to do so? This has no benefit. And why would I not have the whole thing crash in order to restore a working state? Of course the bigger question is why is the program even able to do this and should there be a way to prevent it from doing so. But in the end, this will only make the case against SSD, and also after all this is Linux we talk about, not Windows. If you decide to mess up, you mess up. Then you'll have to fix the shit you broke. Simple as that. And that shouldn't change in every way possible, people need to learn from their mistake. Just obvious security issues like any program being able to act as a keylogger with no real obstacles in its way should be closed. But that's why we have Wayland.

Dealing with the Linux kernel design of resource management single source of SSD is not a great idea as this create a location that is quite simple to do a denial of service attack on and cause it to be terminated instead of the process causing the denial of service. Yes KDE feature to allow the application to live though compositor death also means an application intentionally design to break the system will also remain alive. So yes KDE design restart compostior then it goes back down because it oom_score is spinning though the roof and the kernel killer keeps on killing it.

Well, pulling examples out of your ass that will just never happen just because you can't come up with anything realistic doesn't help anyone, does it? Right now the easiest solution to what you say is to just do what Wayland was designed to and only permit CSD, as that is the superior technology anyways. And maybe overthink oom design. Case closed.

Yes a per application compositor doing SSD the per application compositor would be going down with the application and it would be very clear to the user what application is the problem child.

But that would break your ridiculous argument of some arbitrary program spawning windows and not being detected and killed by oom or some sanity check. So what will it be now?

CSD application pulling the same stunt would be spinning it oom score up faster than the compositor so resulting in correct process killed and also be clear to user what one is the problem child.

This comes about from understanding how to cause the Linux kernel oom killer to take out the wrong targets.

As already said, don't do CSD and call it a day. Just because KDE enabled SSD in Plasma 6 doesn't mean it was a smart move. Let's keep in mind that you where the one that wanted to force the clearly inferior SSD technology onto Gnome and Weston, not me.

[hf_139]

I think everybody can agree that wayland is run in a backwards thinking harmful way.
Not even the hardcore wayland supporters will say with a straight face: "Yes, this constant NACKing and decade long blocking is awesome and how things should be!"

[Artim]

This concept reminds me of how Google Chrome initiate the trend of putting webpages into their separate processes despite they are being displayed in the same browser and living in tabs within the same browser window. With this implemented, browsers nowadays won't get fully crashed by one erroneous website.

p.s. Will DE compositors implement such idea? It probably depends on how big such threat it is in their opinion.

They already did, it's called CSD. As the text you cited clearly states. But beyond that, yes, in cases where it can be a good idea, things do get their own processes. I think it's not too long ago that at least Gnome/Mutter gave the mouse cursor its own process (or at least thread) so if something freezes, it can still interact with things that didn't. Also because resource heavy processes were able to let the cursor stutter.

[deusexmachina]

...And yes, he urgently needs to be committed so he can be treated...
PS: ... So you better get a shrink before you go completely insane and have to be comitted too.

Tripling down on forcibly committing people that you disagree with and whom are totally acting within their rights under the law... Shall we now associate this stance with being pro-Wayland? We've already covered that you (and likely 'Myownfriend') associate opinions that should lead people to be forcibly committed with also being "anti-Wayland". Isn't this exactly the kind of toxicity that can cause software project and collaborative efforts to turn out this way?

[WileEPyote]

Lets be real we already have cases of gnome application under KDE looking out of place and the reverse. Majority of users would not care if it out of place as long as it equals that the window does not appear without title bar and control buttons.

So from usability point of view we don't need agreement.

Lets say someone did a proxy wayland compositor as in like Xwayland except this compositor is just do SSD any application connecting to this compositor just add SSD. This would mostly fix up gnome and weston lack of SSD support. This proxy compositor would be able to crash only taking down the SSD applications.

In some ways for me it makes sense for the wayland protocol to provide two sockets one of CSD applications and one for SSD applications so that SSD processing and CSD processing can be independent processing so increasing stability.

As a Plasma user, I hate having to use GTK apps for exactly the reasons you stated here.

[Artim]

I agree that no sane person ever claimed that. Waylanders claimed it and they are not sane people.

Source...

CSD is inherently insecure. There is no way to cope here. Any application can scam you.

Then you won't have any trouble finding proof for that, won't you? Like at least a theoretical way to force a CSD window onto the user that has no close button on it's own but also can't simply be closed from the DEs/WMs application bar or some task manager. Or at least in case of GTK applications simply right-clicking the header bar or dialog. I'll be waiting...

If you are worried about hotkeys and screensharing "vulnerabilities", you have to admit that CSD is an insecure fad that Gnome fell for during Windows 8 times and doubled down on.

Wrong. Nobody actually claimed hotkeys being insecure, just adverse to usability if not done right, and yes any program being able to be a keylogger and being able to watch your every doing without your consent or even knowledge is a major security issue. A window that doesn't have a close button but still very simply can be closed may be an annoyance, but is very far from being a vulnerability.

[Artim]

I think everybody can agree that wayland is run in a backwards thinking harmful way.

Not everybody, just everybody that refuses to acknowledge reality, like you. The vast majority of Linux desktop users meanwhile are just using it without any of the alleged issues.

Not even the hardcore wayland supporters will say with a straight face: "Yes, this constant NACKing and decade long blocking is awesome and how things should be!"

Yes, that is how it should be. Except there has never been a "decade long blocking" you allege. I prefer things to be done right and not in a half-assed way. Otherwise I could just use Windows.

[Artim]

Tripling down on forcibly committing people that you disagree with and whom are totally acting within their rights under the law... Shall we now associate this stance with being pro-Wayland?

No, just pro-sanity. And everything else you just pulled out of your ass. Or should we associate the clinical habit of not being able to cope with reality with you Wayland-haters?

We've already covered that you (and likely 'Myownfriend') associate opinions that should lead people to be forcibly committed with also being "anti-Wayland". Isn't this exactly the kind of toxicity that can cause software project and collaborative efforts to turn out this way?

You have me the wrong way round. Only people that clinically insane are left to be anti-Wayland. Everyone who is not clinically insane has accepted reality way over a decade ago and has accepted that X has no future and Wayland is the only way forward. That's also the reason why only a few clinically insane are left, desperate to make X look alive while everyone sane only works on X to improve XWayland. But there's a reason XWayland was split off Xorg, so there isn't really anyone sane left on the Xorg side of things.

[billyswong]

They already did, it's called CSD. As the text you cited clearly states. But beyond that, yes, in cases where it can be a good idea, things do get their own processes. I think it's not too long ago that at least Gnome/Mutter gave the mouse cursor its own process (or at least thread) so if something freezes, it can still interact with things that didn't. Also because resource heavy processes were able to let the cursor stutter.

I see usually 3 goals for people who want SSD:
1. They want a frozen application to have the window management UI on the window surface remains working.
2. They want window management innovation / UI design beyond the common min-max-close triple buttons to be available to all window surfaces.
3. They want a title bar that fit their theming taste and they hate the GNOME style.

How such goals shall be implemented is a technical detail. If you can achieve the above 3 goals with CSD, they will stop asking for SSD in Wayland.