Hacker News Reader

Comment by o11c | Hacker News Reader

Yes, Wayland is broken by design, since a single crash takes down the whole desktop; unlike other Wayland complaints, this one fundamentally will never be fixed. This is unlike X11, where it was very common to recover from the inevitable single-component crashes.

View on HN

On the Qt side, it looks like Qt clients are able to survive a compositor crash since Qt 6.6. I haven't personally tried this, as I don't recall experiencing any kwin crashes in the last few years.

https://www.phoronix.com/news/Qt-Wayland-Compositor-Restart

As I understand it, in Wayland all the necessary state lives client side, so a client is free to wait around and connect to a new compositor. The compositor might not place the windows exactly where they were before, but there is nothing architecturally that forces clients to crash if the compositor crashes.

> Wayland is broken by design, since a single crash takes down the whole desktop

A single crash of what? I have used a Wayland only system for a long time and application-level crashes certainly don't bring down other applications much less the whole desktop.

Crashes of the now-merged display server / window manager / whatever. Why does everybody keep talking about "applications" like they're the problem people have with Wayland? Our problem is the Wayland server itself.

Both window manager and shell were historically extremely likely to crash, whereas the display server was very resilient (and the session script would restart the WM and shell as needed). I'm not sure how separate the shell is nowadays, but more than just the traditional duties of a WM have been embugged into the display server.

Crash resilient Wayland compositing exists since 2017, it just isn't implemented in mainstream Wayland implementations. You have to go to Arcan for full resilience. KDE does have some crash resistance, thanks to some changes in toolkits, but it doesn't go as far as Arcan does.

https://arcan-fe.com/2017/12/24/crash-resilient-wayland-comp...

X11 can't recover from an Xorg crash though.

That's okay since X11 is stable and not very crash prone for the last few decades.

The WM and Shell are far more likely to crash, which is it's completely fucking retarded to move any of their logic into the display server.

I found Xorg crashyness depends on how shitty your drivers are. Agreed that merging the components is a bad idea. Under KDE, there is more of a split, kwin does compositing and WM stuff, and plasmashell does the shell and other UI bits. In theory they don't need to all be in one process either. I also found that kwin crashing doesn't bring down apps these days, haven't tested that theory with X11 Xwayland apps though. Also see my other comment about Arcan for proper crash resilience.

> That's okay since X11 is stable and not very crash prone for the last few decades.

I've been using wayland on three computers for the last two or three years and haven't had a crash that could be attributed to wayland in like.. more than a year?

I've had mesa driver crash when running a particular game a few months ago that eventually got resolved by... updating mesa. I bet many people wrongly attribute that to wayland.

applications can reconnect to the compositor, KDE already supports this, and Qt does too. They also contributed code to gtk/gnome to do the same, which they are slowpoking on..

you are talking about things you do not know enough about

Ouch I didn’t know that.

its not true though, when a wayland compositor dies, the clients can simply reconnect once the compositor has started again. this is already implemented in KDE and Qt, and KDE contributed patches to GTK/Gnome(which they havenot merged yet i think).

A crash of the wayland compositor does NOT mean a crash of your entire session, in fact it is more resilient than X11 in this way

Reply on news.ycombinator.com