Comment by from | Hacker News Reader

Comment by from | Hacker News Reader

Wayland's protocol is basically an isolation prison that requires "big DE's" and destroys choice. The protocol moves everything into one central place called the "compositor.” This machinery must provide:

- the window manager - the hotkey daemon - the compositing effects - the windowing server - screen reading tools - screenshots - screen casting

magnifying glass tools global dictionary tools etc etc etc everything. Wayland's design makes it impossible to write a portable hotkey daemon for instance. Supposedly for "security reasons.” Wayland is a GNOME dev's dream, it kills the ability of people to control their own system. If you're actually excited for Wayland you either thoroughly misunderstand what it brings and just like it because it's new or you're a GNOME-lover who hates customization.

And don’t get me started on the security argument. If someone has arbitrary code execution on your machine, you’re already toast. I’ve yet to see an example of malware that can use xlib to read keyboard inputs on X (the supposed vulnerability Wayland was made to stop) but can’t just write some LD_PRELOAD hook to .profile or bashrc to make the compositor keylog on Wayland too. Is there a real world example where this supposedly great isolation that is easily circumventable actually prevented any security issue?

None of this is to say that X.org isn’t the accumulation of 30 years of cruft and technical debt but I don’t think Wayland is the right alternative.

Wayland forces you to move most of the logic into libraries that you can mix and match. X has this one monolithic server that nobody knows how to maintain anymore. You either use the only implementation or you live without a GUI. X destroys choice because there will only ever be one Xserver.

But simple window managers for Wayland exist. Like sway (i3 clone for Wayland)

Personally I also still use X11. Mainly because KDE on Wayland is currently broken on FreeBSD. And I'm not in a hurry anyway.

> KDE on Wayland is currently broken on FreeBSD.

Is for me too on Linux. On both a variety of Intel and Nvidia GPUs. On a variety of distros. And everytime I ask around, I'm told it works for others, so it must be me. Everytime forcing X11 solves all my problems.

To be honest, last time I tried KDE on Wayland was a year ago, so perhaps it works now. Then again, so many years have passed where it turned out it didn't, that I'm not particularly keen to try.

It's arguable whether sway is "simple". Last I remember it clocked in at ~50k lines of C excluding wlroots.

Some X window managers are a few hundred lines.

Sounds like functionality that can be turned into a common library.

It is. Sway is based on WLRoots which you can easily import and build a new window manager on with minimal code.

Most of the wayland fud is either seriously out of date, mistaken, or malicious.

FWIW, i3 is in the same ballpark, maybe a bit less if I am not mistaken.

As far as I know, wlroots [0] comes with implementations for most of the "machinery" for folks wanting to write their own compositor.

Here's [1] a tutorial on writing a compositor with it!

[0] https://gitlab.freedesktop.org/wlroots/wlroots

[1] https://drewdevault.com/2018/02/17/Writing-a-Wayland-composi...

The protocol says nothing about the compositor implementation, because it is a protocol. X11 is the same way; ICCCM and EWMH are protocols that use X11 as an IPC mechanism. There is nothing stopping you from writing a multi-process compositor swarm with all the traditional pieces broken out using an IPC channel of your choice.

The fact is, given that a compositor must necessarily handle display and input, it is much more convenient (and secure) to centralize display and input dispatch in a single process. This is also how X11 works, except it dispatches all display and output to any process that asks nicely.

> If someone has arbitrary code execution on your machine, you’re already toast.

Funny how this isn’t the case for many other OS. My system isn’t toast when I load a website or install an app on my phone.

There certainly are sandboxing efforts on Linux but most of them have incredibly permissive rulesets to the point where nearly every program has read/write access to everything in $HOME.

That's a temporary measure. Get the sandboxing layer in with whatever permissions are required. And then move to tightening everything / replacing permission lists with permission requests like on iOS/Android.

There are a lot of pieces that have to fall in to place and any one on its own is not useful but they will eventually build up something secure.

Reply on news.ycombinator.com