Comment by bsder | Hacker News Reader

Comment by bsder | Hacker News Reader

Parent Full thread

"Jank" is still functional. And, to a first order approximation, nobody cares.

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.

> Lack of support for the BSD lineages is a failure.

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. Then again this distinction is only technical, for functional support new DEs/WMs would always have needed to be ported regardless of display architecture, the only case it would not is for an Xorg drop-in, which defeats the purpose.

> 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.

[1] https://docs.freebsd.org/en/books/handbook/wayland/

Wayland unfortunately is a mess that is hard to implement so we get a balkanized situation where not only everything often boils down to Big Important Process in the middle (that actually integrates more things than X.Org used to), the set of features it supports are way more balkanized and most importantly, specific to that one Big Important Process as they can't be viably separated out.

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.

XOrg was predominantly used as a useless middleman between a compositor and a window manager communicating with each other. Just because the wayland compositor is “one big important process” doesn’t mean that the whole architecture is more complicated.

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.

X11 != the lowest common denominator implementation of X11. Nor was everyone using it with big heavy compositors (honestly, the only reason I used a compositor for years was intel removing sync circuitry from their iGPUs).

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.

If you know how to make screen sharing work under Sway on FreeBSD, please do share. I have not managed to figure it out.

I'm using Debian so I can't say how well this applies to FreeBSD:

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.

Whoops, you will probably need to remove the --systemd flag.

> The Wayland devs aren't wrong about the security implications of this kind of stuff.

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.

Vetted packages are great, but they aren't the end of all security problems. Good security needs defense-in-depth.

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.

What good security needs more than anything is proportionality. After all the only criterium you care about is how secure your computer is then you should simply turn it off because nothing else is going to beat that.

> 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.

The FreeBSD handbook claims that KDE works with Wayland but I have never gotten it to work. X11 still works flawlessly.

Reply on news.ycombinator.com