this post was submitted on 16 Sep 2023
83 points (84.3% liked)

Linux

48208 readers
1557 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.

you are viewing a single comment's thread
view the rest of the comments
[–] lukas@lemmy.haigner.me 6 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?

[–] theshatterstone54@feddit.uk 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.

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.