3 ms·

> They changed it so that everyone who previously just wrote a window manager now had to write an entire display server. Not entirely true. Now if you want to

by jchw 1y ago

> They changed it so that everyone who previously just wrote a window manager now had to write an entire display server. Not entirely true. Now if you want to share the "display server" bits you can plug in a library like wlroots or Smithay. The real issue, if any, is that most of those bits are not standardized; or at least, only the libwayland part. Of course, that's not even the entire story either. When X11 servers were basically entire operating systems that ran as root, implemented print servers and directly touched /dev/mem, only a lunatic would want to maintain multiple of them... but now on Linux and even some BSDs, you can fall back to GBM/DRM/KMS/libinput/etc. for most of your "hardware" needs, the OS is doing the OS things. Wayland is also just simpler than X11; The current day cleaned-up X.org is still around 5x larger by SLOC and much more complex than wlroots. So how come GNOME and KDE both built their own display server? Well really, they didn't; they took their existing compositors they had for X11 anyway and grew Wayland server limbs out of them. In practice retrofitting Wayland into existing compositors is still hard, but if you already have written a compositor and window manager it's still probably easier than writing a new one from scratch. And for KWin, I believe they're also making use of Qt's Wayland compositor infrastructure, too. Something that took me a long time to understand is that people are just unhappy no matter what. Not that all of their points are invalid, just, it's often not even really about that; the specific points are often just the obvious weak spots, like the classic "Wayland can't screen capture" meme (totally fair point, but persisted so long that some people still don't know it hasn't been an issue for years.) This right here is just another one of those. Notice that when many Linux distros unified towards a singular init system, systemd, people came out with pitchforks. Were they all spouting incorrect nonsense? Well, blah blah UNIX philosophy, but largely no, there were plenty of valid complaints about systemd and what it meant for the Linux ecosystem, but it wasn't really about that. Same with Wayland! Wayland did the exact opposite, and defined a set of protocols anyone could implement, allowing you to choose your compositor. Seeing as people hated what systemd did and wanted to preserve "choice" in the Linux world, you'd expect that people would like what Wayland did, but instead everyone is just pissed about fragmentation now. You can pick apart that argument and try to figure out why it's wrong or and invalid comparison and I'm not going to try to fight anyone on that. You can also say that the argument is made by different people and maybe that's true too (though personally I believe "people who hated systemd" and "people who hate Wayland" forms more of a circle than a venn diagram.) Even if it is, the outcome is the same: you're damned if you do and damned if you don't. What I do know is that desktops on X11 stagnated with the same sorts of problems they always had and with Wayland a lot of that got unblocked. X11 will probably be in the same crappy state it's in today and Wayland will continue iterating and improving over time. I'm sure there will be a lot of pain along the way, and I agree it isn't always pretty, but it is what it is. Software isn't a beauty contest, and there's a good reason why "elegant" stuff rarely wins in the long run.

magicalhippo 1y ago
> Seeing as people hated what systemd did and wanted to preserve "choice" in the Linux world, you'd expect that people would like what Wayland did, but instead everyone is just pissed about fragmentation now. As a mere Linux user, who's occasionally been annoyed at systemd and as mentioned have had poor experiences with Wayland implementations, I've been wondering about the alternate timeline where systemd and Wayland swapped approaches. That is, systemd was just a set of protocols along with reference implementations, so people could say swap out journald to something that logged to text instead of a binary database etc. And Wayland instead just did the whole kitchen sink, becoming the basis for the Linux desktop of the future, instead of fragmenting the existing ecosystem even more. Probably a lot of good reasons why it wouldn't have been better, but it would be interesting to see what might have been.
- eliaspro 1y ago
  Well, with systems that's actually the case. It's suite of mostly loosely coupled tools and services and you totally can swap out or disable many of the components however you like. They mostly just use DBus and/or Varlink for IPC and use some common shared libraries to prevent code duplication across the whole project.
  - mqus 1y ago
    well, no? Systemd actually also delivered all of the implementations of those protocols and barely no one cared to fit their previous solution to their standards? Rather, it was the opposite, systemd could also run your usual service shell scripts for a while. Sure, there are similarities in the sense that you started out with 0 service files at the beginning and no GUI toolkit implemented the Wayland protocol from the start, but the thing itself is pretty different. Systemd wasn't designed by committee (and many people still have gripes about this). Wayland kinda is.
deleted 1y ago
[deleted]
saurik 1y ago
The "choice" people want is the ability to easily mix and match a patchwork quilt of software from different parties, each adding one tiny behavior. Wayland doesn't do that: it makes it so almost every behavior people want must be added to the compositor. The magic is in finding what the right point in the abstraction is: what will be centralized and what will be decentralized. Both of your examples--systems and Wayland--made the same decision: the patchwork quilt of behaviors was complex for many users to get working, and even then often didn't work 100% always. It was also slow and a bit insecure (if you don't trust your software). So, both systemd and Wayland took the same approach of pushing forward the boundary of abstraction and merging together most of the things people would have had to configure. This means that that one core component in the middle -- and sure: in Wayland you can have multiple implementations, and those can even share a library, but you can't MIX AND MATCH -- must do all of the things people want. The reality is that no one wanted to maintain multiple X11 servers... but we also didn't want to! What we do want is to to be able to mix and match compositors and macro systems and window managers and all of the fun little behaviors that make a computer feel like it works for us, and now we can't, as we have to find and select a single giant ball of behaviors that happens to be close enough to what we wanted. Theoretically, some day, someone could make a really advanced and capable display server for Wayland, one that will be extremely general and will have a number of protocols for how to extend its behavior. It will be the one display server to rule all display servers, and even ecosystems like Gnome and KDE could just interoperate with it, and we could get back the glorious ecosystem that people are killing... ...but that's effectively what X11 is, right now, and by the time you get that--with a ton of protocols that are old enough to be widely used--all of those behaviors will have aged and ossified and the code will be built by people who are gone in a language that isn't fun using conventions that are out of date, and some A-hole will point out that the stack is difficult to maintain and user's experience is variable and throw the entire thing out to start over :/. Like, I dunno... I honestly do not understand how you are saying Wayland is doing the thing people wanted from systemd: the issue isn't that I wanted to be able to replace systemd, the issue is that I wanted systemd to not be a single giant C program because I really liked the patchwork of scripts and behaviors and alternative parts that were built up in the ecosystem. And again: everything tends to end up with some central thing in the design somewhere... but you have to make that thing be so boring that no one has any interest in innovating on it, and X11 was that: while I do think we should have multiple implementations for robustness, we would expect every one of those implementations to work as close as possible to 100% identically.

by jchw 1y ago

magicalhippo 1y ago

> Seeing as people hated what systemd did and wanted to preserve "choice" in the Linux world, you'd expect that people would like what Wayland did, but instead everyone is just pissed about fragmentation now. As a mere Linux user, who's occasionally been annoyed at systemd and as mentioned have had poor experiences with Wayland implementations, I've been wondering about the alternate timeline where systemd and Wayland swapped approaches. That is, systemd was just a set of protocols along with reference implementations, so people could say swap out journald to something that logged to text instead of a binary database etc. And Wayland instead just did the whole kitchen sink, becoming the basis for the Linux desktop of the future, instead of fragmenting the existing ecosystem even more. Probably a lot of good reasons why it wouldn't have been better, but it would be interesting to see what might have been.

eliaspro 1y ago
Well, with systems that's actually the case. It's suite of mostly loosely coupled tools and services and you totally can swap out or disable many of the components however you like. They mostly just use DBus and/or Varlink for IPC and use some common shared libraries to prevent code duplication across the whole project.
- mqus 1y ago
  well, no? Systemd actually also delivered all of the implementations of those protocols and barely no one cared to fit their previous solution to their standards? Rather, it was the opposite, systemd could also run your usual service shell scripts for a while. Sure, there are similarities in the sense that you started out with 0 service files at the beginning and no GUI toolkit implemented the Wayland protocol from the start, but the thing itself is pretty different. Systemd wasn't designed by committee (and many people still have gripes about this). Wayland kinda is.

deleted 1y ago

[deleted]

saurik 1y ago

The "choice" people want is the ability to easily mix and match a patchwork quilt of software from different parties, each adding one tiny behavior. Wayland doesn't do that: it makes it so almost every behavior people want must be added to the compositor. The magic is in finding what the right point in the abstraction is: what will be centralized and what will be decentralized. Both of your examples--systems and Wayland--made the same decision: the patchwork quilt of behaviors was complex for many users to get working, and even then often didn't work 100% always. It was also slow and a bit insecure (if you don't trust your software). So, both systemd and Wayland took the same approach of pushing forward the boundary of abstraction and merging together most of the things people would have had to configure. This means that that one core component in the middle -- and sure: in Wayland you can have multiple implementations, and those can even share a library, but you can't MIX AND MATCH -- must do all of the things people want. The reality is that no one wanted to maintain multiple X11 servers... but we also didn't want to! What we do want is to to be able to mix and match compositors and macro systems and window managers and all of the fun little behaviors that make a computer feel like it works for us, and now we can't, as we have to find and select a single giant ball of behaviors that happens to be close enough to what we wanted. Theoretically, some day, someone could make a really advanced and capable display server for Wayland, one that will be extremely general and will have a number of protocols for how to extend its behavior. It will be the one display server to rule all display servers, and even ecosystems like Gnome and KDE could just interoperate with it, and we could get back the glorious ecosystem that people are killing... ...but that's effectively what X11 is, right now, and by the time you get that--with a ton of protocols that are old enough to be widely used--all of those behaviors will have aged and ossified and the code will be built by people who are gone in a language that isn't fun using conventions that are out of date, and some A-hole will point out that the stack is difficult to maintain and user's experience is variable and throw the entire thing out to start over :/. Like, I dunno... I honestly do not understand how you are saying Wayland is doing the thing people wanted from systemd: the issue isn't that I wanted to be able to replace systemd, the issue is that I wanted systemd to not be a single giant C program because I really liked the patchwork of scripts and behaviors and alternative parts that were built up in the ecosystem. And again: everything tends to end up with some central thing in the design somewhere... but you have to make that thing be so boring that no one has any interest in innovating on it, and X11 was that: while I do think we should have multiple implementations for robustness, we would expect every one of those implementations to work as close as possible to 100% identically.