That's probably the worst argument that you could make against Wayland: there has only ever been a single X11 server in common use on the Linux desktop (first XFree86, now X.Org), but there are tons of independent Wayland "server" implementations (Weston, Mutter, KWin, wlroots, etc.) [0]. Lots of these are written in completely different languages and implement different extensions from each other, so there's way more variety and flexibility with Wayland than with X11.
The more common criticism that I've heard is that Wayland's variety and flexibility is actually bad, because it makes it harder to add extensions (since you need to implement it in multiple different projects, and not just the single X.Org codebase), and it means that applications potentially have to test against multiple implementations. (I don't necessarily agree with this criticism myself, but it's still a valid complaint.)
and of course nothing would run on BSDes
FreeBSD [1] and OpenBSD [2] both have Wayland support.
The hard part is knowing where to draw the line between relatively stable infrastructure items that don't benefit from duplication, and flexible items that are likely to benefit from specialization and competition.
X11 made the right choice in putting graphics drivers in the "stable infrastructure" stuff and display toolkits and window managers in the "specialize and compete" section.
I'm sort of pleased about that we're finally trying to replicate this division with the River ecosystem, building a standard compositor that we can plug in different actual window management logic into it, but that makes River itself a huge single point of failure-- if it has a bum release or fails to keep up with trends and extensions, it takes down a lot of the ecosystem, but perhaps not enough to be a five-alarm fire the way Xorg or XF86 back in the day would have been.
I think the flexibility issues is more that you can't easily do things that used to be trivial. Try to spin up a bunch of headless wayland gnome sessions with VNC on a modern linux distro running on a server, it basically can't be done. This was trivial in the past, you just launched an X11 server for each one and handed it to VNC and you were done.
And one implementation that everyone settled on, and pretty much everyone can assume to be present is worse than multiple incompatible implementations how?
Comments
That's probably the worst argument that you could make against Wayland: there has only ever been a single X11 server in common use on the Linux desktop (first XFree86, now X.Org), but there are tons of independent Wayland "server" implementations (Weston, Mutter, KWin, wlroots, etc.) [0]. Lots of these are written in completely different languages and implement different extensions from each other, so there's way more variety and flexibility with Wayland than with X11.
The more common criticism that I've heard is that Wayland's variety and flexibility is actually bad, because it makes it harder to add extensions (since you need to implement it in multiple different projects, and not just the single X.Org codebase), and it means that applications potentially have to test against multiple implementations. (I don't necessarily agree with this criticism myself, but it's still a valid complaint.)
FreeBSD [1] and OpenBSD [2] both have Wayland support.
[0]: https://en.wikipedia.org/wiki/List_of_display_servers#Waylan...
[1]: https://docs.freebsd.org/en/books/handbook/wayland/
[2]: https://xenocara.org/Wayland_on_OpenBSD.html#running-wayland
The hard part is knowing where to draw the line between relatively stable infrastructure items that don't benefit from duplication, and flexible items that are likely to benefit from specialization and competition.
X11 made the right choice in putting graphics drivers in the "stable infrastructure" stuff and display toolkits and window managers in the "specialize and compete" section.
I'm sort of pleased about that we're finally trying to replicate this division with the River ecosystem, building a standard compositor that we can plug in different actual window management logic into it, but that makes River itself a huge single point of failure-- if it has a bum release or fails to keep up with trends and extensions, it takes down a lot of the ecosystem, but perhaps not enough to be a five-alarm fire the way Xorg or XF86 back in the day would have been.
I think the flexibility issues is more that you can't easily do things that used to be trivial. Try to spin up a bunch of headless wayland gnome sessions with VNC on a modern linux distro running on a server, it basically can't be done. This was trivial in the past, you just launched an X11 server for each one and handed it to VNC and you were done.
And one implementation that everyone settled on, and pretty much everyone can assume to be present is worse than multiple incompatible implementations how?