this post was submitted on 16 Sep 2023
99 points (85.6% liked)

Linux

48375 readers
1148 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
 

Now, I really like Wayland, and it's definitely better than the mess that is X11

BUT

I think the approach to Wayland is entirely wrong. There should be a unified backend/base for building compositors, something like universal wlroots, so that applications dealing with things like setting wallpapers don't have to worry about supporting GNOME, Plasma, Wlroots, AND Smithay (when COSMIC comes out). How about a universal Wayland protocol implementation that compositors are built on? That way, the developers of, say, wayshot, a screenshot utility, can be sure their program works across all Wayland compositors.

Currently, the lower-level work for creating a compositor has been done by all four of the GNOME, KDE, Wlroots and Smithay projects. To me, that's just replication of work and resources. Surely if all standalone compositors, as well as the XFCE desktop want to, and use wlroots, the GNOME and KDE teams could have done the same instead of replicating effort and wasting time and resources, causing useless separation in the process?

Am I missing something? Surely doing something like that would be better?

The issue with X11 is that it got big and bloated, and unmaintainable, containing useless code. None of these desktops use that useless code, still in X from the time where 20 machines were all connected to 1 mainframe. So why not just use the lean and maintainable wlroots, making things easier for some app developers? And if wlroots follows in the footsteps of X11, we can move to another implementation of the Wayland protocols. The advantage of Wayland is that it is a set of protocols on how to make a compositor that acts as a display server. If all the current Wayland implementations disappear, or if they become abandoned, unmaintained, or unmaintainable, all the Wayland apps like Calendars, file managers and other programs that don't affect the compositor itself would keep on working on any Wayland implementation. That's the advantage for the developers of such applications. But what about other programs? Theme changers, Wallpaper switchers etc? They would need to be remade for different Wayland implementations. With a unified framework, we could remove this issue. I think that for some things, the Linux desktop needs some unity, and this is one of these things. Another thing would be flatpak for desktop applications and eventually nix and similar projects for lower-level programs on immutable distros. But that's a topic for another day. Anyways, do you agree with my opinion on Wayland or not? And why? Thank you for reading.

top 50 comments
sorted by: hot top controversial new old
[–] [email protected] 69 points 1 year ago (1 children)

Don't worry too much about the duplicated effort of different projects implementing the same standard on their own. It's good to have lots of implementations of a standard. That's what makes it a standard rather than just some code we all depend on.

[–] [email protected] 20 points 1 year ago

That's what makes it a standard rather than just some code we all depend on.

succinctly encapsulates the importance of code diversity. 👍

[–] [email protected] 62 points 1 year ago (1 children)

Things like taking screenshots and setting wallpaper actually do have a standard API. That stuff is just part of xdg desktop portals and not the core Wayland protocols. If, for example, a screenshot app uses the org.freedesktop.portal.Screenshot API then it should work with any compositor (as long as the compositor follows the API standards).

[–] gamma 2 points 1 year ago* (last edited 1 year ago)

Well, those requires D-Bus. The wlroots project decided early on to support non-dbus software stacks, so wlroots compositors expose Wayland protocol extensions which could either be used directly or wrapped by the xdg-desktop-portal-wlr daemon.*


*(Well... many wlroots devs argued that the ecosystem should have chosen WP extensions instead of dbus, but I think most relented when Pipewire entered the equation.)

[–] [email protected] 39 points 1 year ago

- person using software developed in opposition to monolithic architectures rediscovering the benefits of monolithic architectures

[–] [email protected] 34 points 1 year ago (1 children)

Wayland isn't to blame for duplicate effort. Instead of 4 different efforts doing the same thing, they can collaborate to build a common base. Heck, wlroots is exactly that.

There's a ton of duplicated work in Linux ecosystem. Just think about every new distro coming out doing the same things other distros did. Just think about all those package managers on different distros. They do almost the same thing. Do they need to have codebases that share nothing? No. But they don't care. They rather duplicate effort. They chose this.

[–] [email protected] 20 points 1 year ago (2 children)

Wayland is a classic case of underspecification. They set out to replace X11, but their replacement only covered maybe 50% of what people were actually doing with X11, everything else was left as an exercise for the reader. That's how you get this sluggish progress of the whole thing, as people will either ignore Wayland because it doesn't work for their case, try ugly workarounds that will break in the long run or implement the thing properly, which in turn however might lead to multiple incompatible implementations of the same thing.

This also creates a weird value proposition for Wayland, as it's basically like X11, just worse in every way. Even 14 years later it is still struggling to actually replace the thing it set out to replace, let alone improve on it in any significant way.

[–] [email protected] 12 points 1 year ago (6 children)

I have seen some improvements to be honest. I have never seen screen tearing (was quite common on X11) and Compositors run more smoothly for me, with less resource usage (that is unfortunately taken up by heavy bars like Waybar). For example, Qtile would usually run at about 780 Mb on a coldboot on X11, while on Wayland, it averages at about 580-600 Mb.

load more comments (6 replies)
load more comments (1 replies)
[–] nous 33 points 1 year ago (1 children)

I don't quite follow your arguments. X11 got big and bloated, wayland applications need to worry about the different compositors? So we should use one implementation? Implementations should be irrelevant. That is the whole point of an API/protocal - a description of how things should talk to each other even for different implementations.

I don't see how one implementation helps here - that one implementation still needs APIs for the applications to talk to. The problem is not that there are different implementations but maybe that the wayland protocol does not cover enough of the API space needed by applications. Some of which are addressed by things like the xdg-desktop-portal.

[–] [email protected] 3 points 1 year ago (1 children)

Well, yes, but there are programs like wdisplays, wlr-randr, etc. which only work on wlroots compositors. Why is that the case?

[–] nous 8 points 1 year ago

It should work in any compositor that implements the wlr-output-management-unstable-v1 protocol. Compositors that are known to support the protocol are Sway and Wayfire.

It uses a new unstable protocal that others dont support yet. The fact it is unstable suggests it might change over time as well,

[–] [email protected] 21 points 1 year ago (1 children)

The issue with X11 is that it got big and bloated, and unmaintainable, containing useless code. None of these desktops use that useless code, still in X from the time where 20 machines were all connected to 1 mainframe.

I don't think that is very fair to say. From what I heard, the X.org code as in the implementation of the protocol and its extensions is actually of very high quality, so it can be maintained. The problem as you correctly describe is the design and the resulting protocol with its extensions which don't fit modern needs.

It's also not like theoretically multiple X11 servers implementing the X Window System couldn't have existed simultaneously, it was just too much effort regarding the complexity of the protocol. In fact, for a short time, two different implementations existed: XFree86 and the X.org server. Granted the latter was a fork of the former, but they were independent projects during the time of their coexistence.

[–] [email protected] 9 points 1 year ago (1 children)

But it is fair to say that considering they started Wayland because they could not fix the issues with X11.

[–] [email protected] 4 points 1 year ago

Yea, sometimes new problems need new solutions and the old architecture can get fundamentally outdated!

[–] [email protected] 19 points 1 year ago (1 children)

I find it hard to understand what I'm supposed to address from your monologue, but I'll go with one thing that stuck out to me.

What does this have to do with app developers? GNOME, Plasma, Wlroots, and Smithay use the Wayland protocol. If app frameworks use the Wayland protocol, then they're compatible with GNOME, Plasma, Wlroots, and Smithay. Apps won't work if GNOME, Plasma, Wlroots, and Smithay were compositors with their own, separate, incompatible protocol. Or the Wayland protocol in that hypothetical world is so poor that Wayland compositors deviate so much from each other that app frameworks must support each compositor individually.

[–] [email protected] 4 points 1 year ago (1 children)

Well, there are programs like wdisplays, wlr-randr, etc. which only work on wlroots compositors. Why is that the case? Am I missing something here? Please explain. I will admit I don't know as much about Wayland as I wish I did.

[–] [email protected] 8 points 1 year ago (1 children)

Because Wayland is in active development. wdisplays and wlr-randr use wlr-output-management-unstable-v1. Why should GNOME and Plasma implement an unstable protocol for a use case they support out of the box?

[–] [email protected] 1 points 1 year ago (1 children)

Why would they be different about it? I understand they want this supported asap and couldn't wait for an unstable protocol to become stable, but I sincerely hope they switch to using this protocol once it matures.

[–] [email protected] 1 points 1 year ago

Why would they be different about it?

Because if they rush it into stable, and then find flaws in it, or want to change how an API works for whatever reason, it will break applications that used to work perfectly one compositor update ago. (not so stable behavior)

When you first transition to Wayland, you need to replace applications that don't use Wayland APIs and it's a pain in the ass. Now imagine having to do that every time your compositor is updated. That's what rushing things into stable will do.

[–] [email protected] 18 points 1 year ago (1 children)
[–] [email protected] 2 points 1 year ago

Yeah, that's why I think it would be better to focus on existing standards rather than multiplying work so much, when that time could have been used for more productive tasks like working on accessibility or fixing bugs, or addressing documentation issues, or when everything else is done, working on the Mobile space, which is very much an emerging market.

[–] [email protected] 10 points 1 year ago

So why not just use the lean and maintainable wlroots

wlroots can't be used (comfortably and idiomatically) in Rust because it's too hard (if not impossible) to provide a memory-safe interface for it.

we can move to another implementation of the Wayland protocols.

So unfortunately this has already happened.

[–] [email protected] 5 points 1 year ago (1 children)

What i wonder about, why do compositors have to handle Keyboards (again)? Wayland does and X did. Shouldn't that be separately handled?

[–] nous 16 points 1 year ago (1 children)

What do you mean by handled seperatly? Both wayland compositors and X11 use libinput nowadays to get input from the hardware. But then it needs to be routed to the right application - the one that is in focus minus any global shortcuts that the compositor might want to deal with. The compositor is what understand what application has focus and thus is what knows where to send input to so it makes sense for it to handle that. It is not just about where to render windows - but manages all events such as input that applications require.

[–] [email protected] 6 points 1 year ago

Right, forgot that part.

[–] [email protected] 1 points 1 year ago (1 children)

I love the idea of Wayland, but it only finally actually booted for me onto the desktop earlier this year (on Manjaro KDE). But it still randomly freezes for about a full minute, quite a bit. I am keen to move to it as my compositor hangs on X11 for some odd reason on KDE every time I try to do a rectangular area screenshot with Spectacle (mmm just realised it is also for around a minute - maybe I do have some other underlying issue), or when accessing the Compositor menu option. But X11 is still otherwise rock solid for me.

[–] [email protected] 2 points 1 year ago

Manjaro's to blame. Manjaro ships botched packages sometimes, and they are always two weeks behind, meaning you can't use the AUR lest you break your system.

load more comments
view more: next ›