Link to article: https://gist.github.com/probonopd/9feb7c20257af5dd915e3a9f2d1f2277?permalink_comment_id=4749746

This OUTDATED article gets posted all the time. The full story is the guy is a massive FreeBSD fan so he is trying to convince more people to keep on using Xorg because he wants to make sure it isn’t abandoned. Reason for that being that Wayland is built with Linux in mind and would not work under FreeBSD without a lot of effort bwing put in as it uses some Linux-specific components or libraries.

Let’s go through the article point by point:

Wayland is broken by design:

• A crash in the window manager takes down all running applications: Yes, because the compositor IS the server, window manager AND compositor at the same time.

• You cannot do a lot of things: What, like allowing Windows to see your keystrokes, which makes developing a keylogger absolutely trivial?

• There is not /usr/bin/wayland: Yes, because Wayland is a set of protocols, which a bunch of projects can implement as few or as many of, as they see fit, thus avoiding the issue of “unmaintainable mess” that has plagued Xorg for years.

• It offloads work to the window manager: Again, yes, that’s a part of its structure: do the protocols, then let the compositor implement them. That way, you have multiple implementations running simultaneously that are well integrated with their window managers and thus more efficient and performant. It also means that when a compositor suffers from too much cruft, we can just make a new one, while application developers wouldn’t really have anything to change because if their application works on Wayland, then it works on different compositors (unless it is made specifically for GNOME, or specifically for wlroots, like wlr-randr)

…so what works on DE 1, doesn’t necessarily work on DE 2: True, because oftentimes, it doesn’t need to. Not implementing features can lead to a more lean and streamlined software solution. However, sometimes features are necessary and only implemented in some compositors. This usually happens because the universal solution is not ready. KDE are often known to do this with Plasma and KWin.

• Wayland breaks screen recording applications: Correction: The following screen recording applications were not built to support Wayland (because Wayland is new to them or they just decided not to, or they were either too busy or too irresponsible enough to realise Wayland is coming, and has been for over 10 years. In defence of the devs, they probably wanted to make sure Wayland will become stable enough, but it has been the default even on Debian for many years now, so…

In terms of the applications, I’m not aware of many of them, and for this sort of application, I’m sire alot of work is required to change the graphical backend, so I understood that some smaller projects gave up, but OBS has been working on Wayland for quite a while. Is it perfect? I don’t think so, but back when Brodie Robertson was using Hyprland, he was recording his videos using OBS. This article is quite outdated.

• Wayland breaks screen sharing applications:

As the update shows, Jitsi now does work on Wayland.

Zoom only seemed to work on gnome, BUT if you open up the Link to the zoom issue and read through the comments, there is clearly a person that clearly states that they changed /etc/os-release from PureOS to debian and it worked for them, all because of some pointless limitations enforced by the Zoom developers. As the person posting the issue states “Currently, the zoom application has put an arbirtrary restriction on screensharing so it ONLY works on GNOME, when the api being used works on all wayland desktops.” Read that again. It’s a pointless restriction put there by the Zoom team because they couldn’t be bothered to test anything non-GNOME.

And the last issue is a problem with the article writer’s own appimage. I don’t know about that one.

• Wayland breaks automation software

As stated IN YOUR FACE, it is an application that works on X11 only. Yes, Wayland is not made to use such applications, but it doesn’t mean they can’t exist. Every heard of ydotool (remember that name)? Now you have.

Next up, we have 3 issues about GNOME and KDE global menus (1 for GNOME, 2 for KDE). From the little I know about global menus and using these projects, as well as considering that they are both incredibly stable on Wayland and Fedora KDE will be dropping Xorg completely, I think it’s safe to assume these issues have probably been fixed. Please correct me if I’m wrong.

• Wayland breaks AppImages that don’t ship a special QT plugin: Great! Just ship the plugins then! Problem solved! Also, quote from the article: “However, there is a workaround: “AppImages which ship just the XCB plugin will automatically fallback to running in xwayland mode” (see below).”

• Wayland breaks Redshift: Once again, a program built for Xorg doesn’t always work on Wayland. Especially if it works with the compositor, like a colour temperature control application, or a wallpaper setter. The article quotes that “Redshift does not support Wayland since it offers no way to adjust the color temperature” which is not true, as proven by Redshift alternatives like Gammastep.

• Wayland breaks global hotkeys: I present to you: Hyprland (where you can get global hotkeys). Now, it is normally not allowed by design, as a security measure, but Hyprland has not allowed that to stop them from implementing a solution where you can choose keys that will be passed on to the application. Boom, problem solved. Unfortunately, it doesn’t seem to be implemented anywhere else, as far as I know.

• Wayland does not work for XFCE: Come back to me in late 2024 after XFCE 4.20, which will introduce Wayland support, has been released. Also, https://wiki.xfce.org/releng/wayland_roadmap

• Wayland does not work properly on Nvidia Hardware: It keeps on getting closer but is not there yet, or so I’ve heard. Apparently, the issue is with the proprietary drivers, as noveau works well. But I use AMD, so I’m only working off rumours and opinions here.

• Wayland does not work properly on Intel hardware: Again, I’m using AMD, so I can’t confirm or deny this, but considering the Intel drivers are open source, and I’ve heard about many, many improvements made on the Intel side of things, I think it would be reasonable to assume it has been fixed.

Edit: As multiple Intel users have pointed out in the comments, there seem to be no issues on Wayland with Intel hardware.

• Wayland prevents GUI applications from running as root: This one has been crossed out as the article writer admits there is a solution

• Wayland is biased towards Linux and breaks BSD: Arguments seem valid, and I’m guessing, are correct. This one is likely true and will remain so for the foreseeable future.

Edit: And yet, it seems that there are Wayland compositors for FreeBSD, so the above might only be true for OpenBSD and others.

• Wayland complicates server side decorations: From what I’ve heard, this is true, mainly something to do with some GNOME agenda, as the article states. I think that one is true.

• Wayland breaks windows raising/activating themselves: The linked issue is closed and seems to be resolved. There is a mention of a WIP protocol at the time (2019) that woukd fix this. I had difficulty following the discussion, but I think this has been fixed.

• Wayland breaks RescueTime: Because RescueTime depends on X11-only tools like xprop.

• Wayland breaks window manager: What you’re describing is Wayland breaking X11-only tools for doing various tasks in a window manager. They are X11 tools, so of course they don’t work on Wayland. I’m not sure if there are alternatives, but I’d guess there probably are. I know for a fact that Xrandr has alternatives like wlr-randr and kanshi for wlroots.

• Wayland requires {instert WM here} to implement Xorg-like functionality:Yes, it does.

Quote from article: "As it currently stands minor WMs and DEs do not even intend to support Wayland given the sheer complexity of writing all the code required to support the above features. "

DEs: GNOME, KDE, MATE, XFCE, Cinnamon, Budgie, Enlightenment, and recently even Pantheon have either announced to start work on, have started work on, or already support Wayland.

Window managers: Qtile is doing it. Xmonad wants to hire a dev to do it. Dwm has a spiritual successor called dwl. i3 has a drop-in replacement called sway. Openbox has 2 spiritual successors called labwc and waybox. Now you might notice one of the biggest WMs is missing on here: AwesomeWM, which is such a shame. The Awesome devs have said they would be okay with someone taking on that challenge (which has already been attempted, as evidenced by the existence of way-cooler), but it seems that they wouldn’t do it themselves.

As for the projects mentioned in the article, (JWM, TWM, XDM, IceWM) they are too small and obscure, and will likely fade away with Xorg.

• Wayland breaks _NET_WM_STATE_SKIP_TASKBAR protocol I don’t know about that one, ao I’ll assume it is still the case. Edit: Ignoring the fact that the link is broken, it basically just links to a docs change where skipTaskbar is marked as unsupported on Linux. Link: https://github.com/electron/electron/pull/33226

• Wayland breaks NoMachine NX The link points to a page that has this marked as “SOLVED, Released in version 8” so I’m guessing it has been solved.

• Wayland breaks Xclip: As you said it yourself, Xclip is an X11 application, so it doesn’t work on Wayland. Of course it wouldn’t work on Wayland. With Wayland, we’re trying to prevent what happened with Xorg from happening again, or am I wrong?

Edit: As pointed out by some people in the comments, there are also alternatives to xclip like wl-clipboard.

• Wayland breaks SUDO_ASKPASS: That link seems to point to the way this issue has been resolved so I don’t see your point.

• Wayland breaks X11 atoms: I lack knowledge on the topic so will assume this to be a valid argument

• Wayland break games: I’m 99% sure you can disable Vsync??? But I’m not a gamer. Also, WINE on Wayland is getting better and better. Soon enough, I hope the subpar performance will become better performance (when compared to Xorg)

• Wayland breaks xdotool: Well, yes. There is ydotool, but you’re looking for a 1-to-1 replacement and I’m not sure if ydotool fits the bill for that.

• Wayland breaks xkill: Well, yes. Again. It is an X application, so of course it does. Though for some reason I remember it working once on wayland. Must have been an xwayland app, or maybe I’m just misremembering this.

• Wayland breaks screensavers: Yeah, that seems to be the case.

• Wayland breaks setting the window position: That is a WIP for Plasma, not sure about any other projects, so assume true for anything else.

• Wayland breaks color management: Not anymore. That is being actively worked on.

• Wayland breaks DRM leasing: While not rhat familiar with the issue, my understanding of the topic is the article is correct: not all compositors support it.

• Wayland breaks in-home streaming: Not familiar with this, so will assume true.

• Wayland breaks NetWM/EWMH: Yeah, that seems to be the case.

• Wayland breaks window icons: Yeah, that seems to be the case, as said in the article, when no .desktop files are used.

And that concludes my response to this article based on my fairly limited knowledge on the topic. If I got anything wrong, please, please let me know. As you can see my knowledge is quite limited, and as such, any corrections (preferably backed up with evidence) would be appreciated