Sway 1.8-rc1 Wayland Compositor Brings More Secure Screen Lockers, Improved Vulkan Code

[oiaohm]

Wayland is also brain damaged (requires multiple server implementations when X11 had just one). All the talks about wlroots are BS, plain and simple. This library does not solve this issue and never will.

https://en.wikipedia.org/wiki/List_of_display_servers#X11

Sorry no X11 server history does not have you with just one. Yes there was one reference X11 server most of the time but this was not the case for early X11 history.

Also scroll down on that page into the Wayland section.

libwayland-server any ideas what this is birdie. That right a single library that all of the current wayland compositor implementations use. Turns out that library is the core Wayland compositor protocols.

wlroots is just a toolkit on top of the core.

[birdie]

...

For the past 15 years all Linux distros have had a single X.org implementation, so, please stop BS'ing everyone and calling the things from the long past no one cares about.

wlroots still results in multiple Waylands compositors/servers, i.e. multiple implementations and horrible code/bugs/missing features duplication, so, again, stop BS'ing everyone.

I don't even want to talk about that wlroots is not actually a library. It's a huge stinking code dump you have to link in. This is not how shared libraries have ever worked.

[sinepgib]

For the past 15 years all Linux distros have had a single X.org implementation, so, please stop BS'ing everyone and calling the things from the long past no one cares about.

15 years ago X11 was already 23 years old. Yes, the servers converged eventually, but there's been several and many times those coexisted. There's still a chance Wayland will converge to one library in due time.

I don't even want to talk about that wlroots is not actually a library. It's a huge stinking code dump you have to link in. This is not how shared libraries have ever worked.

That's pretty much how libraries work, never heard of static linking? But further, it's how it makes sense for a window server library to work. You wouldn't have several independent WMs running at the same time and that's the only sensible user for this kind of library.

[Quackdoc]

You wouldn't have several independent WMs running at the same time and that's the only sensible user for this kind of library.

there are a few good uses for running multiple independant window managers, in fact I do it a fair chunk, doing multiseat over wlroots, thankfully wlroots recently fixed nested touch which is really nice for waypipe. but multiseat in general is something quite nice.

[oiaohm]

For the past 15 years all Linux distros have had a single X.org implementation, so, please stop BS'ing everyone and calling the things from the long past no one cares about.

Not true. https://github.com/tinycorelinux/tinyx you need to stop BS'ing people on this point. This is only 2 years back.

For the past 15 years majority Linux distributions have used single X.org implementation not all of them. There are many cases where x.org implementation of X11 server is too heavy so different distributions maintained ghosts of the past. Yes patches were added to allow tinyx stuff by tinycorelinux and puppy linux to work to many X11 windows managers in recent years and at times breaking x.org main support for a short while in the process..

[archkde]

No known insecurities in slock for X, though, are there? Seems this increased security is just a perception with Wayland.

Secure screen locking is impossible on X, no matter whether you use slock (which is actually not that great even for X), kscreenlocker or xscreenlocker (which are a bit better). A "lock screen" on X is actually just a window that is put (hopefully) on top of everything else. Any application can inadvertedly bypass or even block the lock screen by showing the wrong kind of popup. If the "screen locker" crashes, the screen just unlocks. If you hot-plug monitors, the screen locker may appear too late (or not at all) on the new monitors.

On Wayland with ext-screen-lock (or the similar proprietary implementations by GNOME and KDE), the situation is much better, because the screen locker actually tells the compositor that the screen is supposed to be locked. Now the compositor can simply make sure that nothing of value is displayed while the screen is locked. (The X way can be emulated using wlr-layer-shell, but it shares the same security issues.)

[kpedersen]

15 years ago X11 was already 23 years old.

The Lindy Effect shows that the future is going to be very bright for X11 compared to Wayland indeed. That is the point you were making by stating its age right?

Yes, the servers converged eventually, but there's been several and many times those coexisted. There's still a chance Wayland will converge to one library in due time.

Banter aside, a convergence really does need to happen. Every small compositor project is never going to be able to get everything right. It will simply end up in a very small amount of choice. For example the only feasible WM equivalents at the moment are Sway and Weston (Gnome and KDE are DEs and not simply compositors. No-one ran Metacity or KWin directly back then and don't now).

If we can get an official high level library (akin to libX11) that makes writing compositors simple and fun again, this will put Wayland in a good position. However the technology is *still* too immature.

[oiaohm]

Banter aside, a convergence really does need to happen. Every small compositor project is never going to be able to get everything right. It will simply end up in a very small amount of choice. For example the only feasible WM equivalents at the moment are Sway and Weston (Gnome and KDE are DEs and not simply compositors. No-one ran Metacity or KWin directly back then and don't now).

Really even with X11 Windows managers we were needing convergence because they were not getting stuff right. Wine, firefox and other projects have been deal with X11 windows manager unique quirks like at times completely losing windows.

Lot of ways libwayland-client having generic quirk support would be useful. Like the way vulkan has layer system.

[sinepgib]

The Lindy Effect shows that the future is going to be very bright for X11 compared to Wayland indeed. That is the point you were making by stating its age right?

I mean, I'm not denying X11's success at all. Just pointing out that convergence from day 1 is a bit of an unrealistic expectation. It wasn't the case for X11, why would it be the case for Wayland? If we waited 23 years for convergence for X11 into a single server, we surely can wait 15 for other projects. Of course, the sooner that happens, the better.
With that said, the variety of X11 servers was less troublesome for WMs than the variety of Wayland libraries is, mostly because WMs in Wayland, being really the compositor, can't simply switch from implementation to implementation seamlessly. It's a similar issue in terms of bug surface, but not that similar for development effort.

Banter aside, a convergence really does need to happen. Every small compositor project is never going to be able to get everything right. It will simply end up in a very small amount of choice. For example the only feasible WM equivalents at the moment are Sway and Weston (Gnome and KDE are DEs and not simply compositors. No-one ran Metacity or KWin directly back then and don't now).

I agree 100%. I think wlroots is the best candidate at convergence. Because it's meant to replace the server, it's better for it to be a library rather than a particular WM. Because it's meant to be more or less neutral and lightweight and usable by small teams, it cannot be one of the behemoths. And since Weston is meant to be stupid simple because its role is to illustrate the protocols, you can't really do things like optimize it or make it really generic, so it rules it out as well.

If we can get an official high level library (akin to libX11) that makes writing compositors simple and fun again, this will put Wayland in a good position. However the technology is *still* too immature.

Completely agree. I think it's slowly evolving, but until we have that, the soil will be a bit sterile.

[sinepgib]

there are a few good uses for running multiple independant window managers, in fact I do it a fair chunk, doing multiseat over wlroots, thankfully wlroots recently fixed nested touch which is really nice for waypipe. but multiseat in general is something quite nice.

I stand corrected then. However, in terms of efficiency it actually helps to link statically, assuming it's the same WM. It may be two instances, but if mapping the same binary twice it's better to have all the code in one place to avoid relocation overhead. They will use only one in-memory copy of the code.