River: A dynamic tiling Wayland compositor
github.com
github.com
I can't be the only one who is frustrated when they click on a HN link hoping to learn more about something, and instead I'm presented with a list of folders and files.
Things are supposed to be a bit more secure and extensible, and it's mature enough now that I've been using it for my daily life with little to no problems for a couple years.
Read this for a better description: https://wayland.freedesktop.org/
https://wayland.freedesktop.org/
Appreciate where you're coming from re the detail. It can be hard to know where to draw the line when explaining projects and it depends on the target audience etc.
In this case, I would say it's ok that they don't explain what Wayland is on the project page. Wayland has pretty widespread adoption now and I reckon the vast majority of people that might be interested in projects like tiling window managers for linux will have heard of it (and that has probably been true for quite some time now, Wayland has been around for over a decade).
If you're keen to dig into it more, another popular project in the space is sway https://swaywm.org/.
The implementation of the protocol may differ, but I know for example MUTTER, that is used in GNOME (https://gitlab.gnome.org/GNOME/mutter)
This article has nice and not too complex visualisations and explanations: https://www.secjuice.com/wayland-vs-xorg/
Quiet the opposite. Tearfree rendering, forced vsync and the completely opaque way of interacting with graphics memory in order to fulfill the "every frame is perfect" philosophy means Wayland is optimized for all kinds of things (mainly to give involved consulting firms some lucrative gigs) but certainly not latency.
If you are fine with visual glitches like screen tearing due to e.g. a lack of vsync then X might have less latency.
There are cases where tearing is extremely distracting, like playing videos or scrolling in the browser. There are cases where tearing will not be noticed at all but low latency might be beneficial, e.g. when you only have small areas of the screen that are updated, like moving the mouse cursor or editing text. And there are cases where it is a user preference, e.g. Games (Many people play competitive FPS Games without vsync whereas scrolling without vsync in strategy games will be very distracting).
The point is to give the user a choice when there is a trade-off. The trade-off here is vsync vs. low latency.
Wayland makes the choice for you. On X11 each application can do what makes sense for that particular use case and on top of that the compositor can be turned off, on or even be replaced at runtime without affecting running programs. X11 is superior technology in every way if you ask me.
So, from a personal practical perspective, whatever Wayland does has worked for me, while X11's "superior technology" has completely failed me, on that laptop.
If the system makes it easy to write buggy programs and there are common problems that take a lot of effort for developers to overcome it is a bad system.
Furthermore, Wayland can have lower input latency than X if you are dealing with more complex input. Text nowadays has grapheme clustering, ligatures and text shaping (including runtime text shaping), and other oddities; this is a heavy task that can incur latency. Latency can be reduced by offloading some of this to the GPU. Frame timing combines well with this approach to ensure that only displayed frames get rendered, synced with display refresh. The result is dramatically lower latency when taking into account display refresh rate.
In other words, Wayland's vsync support can make complex tasks like modern text input incur lower latency and use fewer resources.
On Sway, for instance, if you tune the compositor with sway-input, you can actually achieve lower latency than on X11 WMs like dwm, even without a compositor. This is even more pronounced on low-end ARM machines.
Just like vsync, GUI isolation is a trade-off. It comes at a cost with major inconveniences for the user and programmer. On a system running primarily trusted open source applications GUI isolation is not a priority whereas letting programs talk to each other without restrictions is. On a system where you primarily run proprietary software from untrusted sources (like Android or Windows) GUI isolation has a high priority.
> The result is dramatically lower latency
You understand that the bandwidth between your front buffer and monitor is many orders of magnitude lower than the bandwidth from GPU to front buffer? This means it is impossible to have lower latency if you force vsync (especially if you have unpredictable events like user input). Besides, all the weird "timing solutions" and "offloading to the GPU" you are proposing can be implemented on X11 as well. Wayland is just a protocol to manage multi process access to memory on your GPU. Inherently it doesn't do more than DRI3 on X11.
I'm not sure how releasing the source code to a program alters its security state or makes the bugs disappear. Security audits typically rely on binary analysis and runtime inspection rather than source code review, regardless of source model. This is because doing so takes into account things that can violate the contract that is source code: the larger runtime, toolchain bugs, and source code bugs that pass by flawed human eyes unnoticed. Assuming your binaries aren't obfuscated, binary analysis is one thing that is incredibly difficult to hide from. The whole field is actually moving towards stuff like black box fuzz testing; I can guarantee that you can thank that for some of the most significant security fixes you've benefited from in the past couple years.
FLOSS has many merits, but security is lower on that list every year. Proprietary software does not have a monopoly on vulnerabilities.
Also, there is no such thing as a "trusted program" unless you employ formal proofs; Project Everest is one example and their progress pales in comparison to less rigorous TLS implementations. Everyone writes buggy code, and some bugs are more exploitable than others.
Finally, most users do regularly run hostile programs in the form of remote JavaScript apps in runtimes that we call Web Browsers. Browsers use all the OS features they have access to in order to provide sandboxing. On Linux, this includes seccomp for syscall filtering, multi-process isolation, and user namespaces; however, this typically lacks robust GUI isolation on Linux and BSD due to the lack of support in X11. Chromium has a (very partial) mitigation by limiting access to the GPU process while Firefox does no such thing; Webkit2GTK browsers leave you even more exposed as they often disable sandboxing. If open source was perfectly secure, Firefox wouldn't regularly lead Pwn2Own's browser exploits.
This isn't limited to browsers: PDF readers, ebook readers, email clients, media players (ASS subtitles might as well be programs of their own), and countless other programs literally exist primarily to work with untrusted content.
> This means it is impossible to have lower latency if you force vsync (especially if you have unpredictable events like user input).
User input in 2022 is complex work that is far more involved than just printing characters one after the other. Characters interact with each other, modify each other with context, overlap, change each others' direction, and switch meanings. Libraries like harfbuzz are quite advanced. With all this work taking place, vsync does reduce latency by reducing the amount of rendering: vsync allows the rendering to skip changes that don't sync with a display refresh.
> Besides, all the weird "timing solutions" and "offloading to the GPU" you are proposing can be implemented on X11 as well.
Wayland has excellent support for frame timing; X11 just does not. You'd have to break compatibility or layer a more advanced compositor on top, and the latter won't be following any standards that programs can adopt. Wayland standardizes the process so that programs can actually reap the benefits. Terminal emulators like Alacritty and Foot are two examples of this.
I keep hearing all these theoretical answers of things that are broken or could be improved -- but I'm a 20 plus year Linux user who has zero trouble doing work, playing games, including using a setup that uses a 4K monitor; with little or no modifications to standard installs of popular distros.
Not really. There are common APIs called XDG Portals, so all you need is a compositor-specific portal implementation which is transparent for applications.
dwl[0] is closer to a port, it's explicitly trying to work the same as dwm for wayland with the same philosophy, although it's still an independent project written from scratch.
A Windows 3.11 or Mac Classic like compositor would be fun.
In wayland there's additionally KWinFT, hikari, and wayfire. Although neither of them are comparable to the classic Windows/Mac WMs.
(a) looks good and modern (b) can tile well but also allows for free floating windows (c) has simple commands, not multi stroke Emacs-style commands (d) can allow tiling with the mouse with snapping
If you're worried about 'bloat', it's surprisingly lightweight and you don't need to pull in a full KDE desktop environment.
And KDE doesn't wake up properly from suspend on my machine.
:-/
I actually like Cinnamon a lot since you can hit Windows+LEFT/UP/RIGHT/DOWN and at least tile in 4 regions (though I wish it could split more fine grained, and I wish they supported Wayland.
[1] https://github.com/seanpringle/goomwwm
[2] I personally use sway these days, but I still prefer manual tiling where I move and size windows myself, rather than having the WM try to do it for me, as long as the WM makes it very easy to do, as goomwwm did (and its predecessor, musca: https://github.com/enticeing/musca)