Not true. FreeBSD and OpenBSD have had various wlroots compositors such as Sway available for some time. e.g [1] Some people have even been experimenting with KDE-wayland on FreeBSD since 2021.
Wayland support on any OS is not binary because there is no single layer like Xorg. It's a matter of individual compositors and their components being ported to the OS, which is a matter of popularity, and the BSDs are always at a disadvantage in that respect, so they lag behind, same as other software. Nevertheless, they are definitely gaining support.
[1] https://docs.freebsd.org/en/books/handbook/wayland/
> Lack of screenshots/screencasts is a failure.
... but there are many functional screencapture apps, and even browser support, I use this pretty much every week. I think you might be operating on out of date info. I'd highly recommend giving it another try, the Wayland ecosystem has come quite far over the last decade.
And even then you have to deal with a mix because you have to work through two different unsynced possibly broken in weird ways connections (Wayland + D-Bus).
This results in how last week I couldn't screenshare under Wayland, and had zero chances to figure it out - and to make it worse since I had some important state and no time to play with reboots, I couldn't fix it.
Multiple IPCs make the whole stuff way more complex, there is a reason why we have a big monolith as browsers and not some `curl | htmlRender | jsInterpreter` Rube Goldberg machine — the unix philosophy is not the pan ultimate design, it works in some cases and is utterly broken in others.
And Wayland did not stop requiring multiple IPCs, in fact it mandates them as several features require passing data by secondary channels, not just for Portals et al - some don't even have any described way to reliably pass the information that I have seen (like how to pass around cookie to let one application activate window of another? Or maybe the spec is such a mess that I'm looking at completely wrong place when I tried to fix ability to reliably switch between applications without extending compositor).
And yes, the architecture is more complicated in practice, otherwise it might have reached parity with what X11 did after as many years - like input method support. Unfortunately it's so broken that you have multiple versions of it in practice, it requires extra IPC in practice, and at least in my experience just does not work.
You need to have `xdg-desktop-portal-wlr` or equivalent package installed (should be depended upon by sway package really), and also the gtk one for some other stuff wlroots doesn't implement like notifications I think (don't worry it doesn't drag in all of gnome).
This is technically the only thing you should need to do beyond picking a wayland compatible screen capture program or browser - However it's possible the dbus variables are broken if you wrote your own sway config from scratch (guilty)... Depending on your OS, the default config should do this automatically, on Debian it includes /etc/sway/config.d/50-systemd-user.conf, I can't say for FreeBSD. So point is if your config omits the dbus-update-activation-environment command, you probably need to include it in your config.
TL;DR
apt install xdg-desktop-portal-{wlr,gtk}
And include this at the top of your sway.conf exec dbus-update-activation-environment --systemd \
DISPLAY WAYLAND_DISPLAY SWAYSOCK XDG_CURRENT_DESKTOP=sway
Those environment variables are set by sway, but this line imports them into dbus (is my limited understanding) so that programs call the correct xdg portal backend.Remember to restart sway to test this.
But they are wrong. Their security model assumes an ecosystem of untrusted apps when we already had something far superior: distributions with vetted packages.
Wayland is like bolting down your furniture because if you let in random strangers from the street they might steal your stuff. Instead of adding obstacles that make my own life harder I prefer to keep better company.
It's rare but not unheard of for someone to be able to sneak malicious code into a vetted package. It's extremely common for vetted packages to have security vulnerabilities that could be exploited.
I don't want someone who finds a vulnerability in a fart app to be able to escalate that to attack other apps on my computer.
I trust my accountant with a lot of sensitive data but I don't give them the keys to my house. I trust a friend with my house keys to water plants while I'm gone, but I don't give them the password to my bank account.
> It's rare but not unheard of for someone to be able to sneak malicious code into a vetted package. It's extremely common for vetted packages to have security vulnerabilities that could be exploited.
Ok, when is the last time you or anyone you know personally sustained any nontrivial damage because of such an event? You can make up hypotheticals to scare people all you want but the simple fact is that no, people are not actually in any more danger on their computer than they are just being alive.
Even Windows generally switches down to software rendering when resizing. And on mobile devices, nobody resizes.
No pointer warp, however, is a failure (CAD packages all have significant issues on Wayland). Lack of multilingual support/accessibility is a failure. Lack of screenshots/screencasts is a failure. Lack of support for the BSD lineages is a failure. etc.
People are still bitching up a storm because Wayland still (Pipewire does screen sharing using DBUS(!) for example) hasn't fixed basic things while DeadRat is shoving it down everybody's throat by dropping X11 support.
The Wayland devs aren't wrong about the security implications of this kind of stuff. However, they're also not giving anybody solutions, either.
One big issue is that Wayland devlopment is so slow that the entire space moved forward and destroyed a bunch of assumptions that Wayland is based around.