3 ms·

X11 has no GUI isolation which in this day and age is inexcusable in a desktop operating system. The only decent attempt at proper isolation for X that I know o

by Seirdy 5y ago

X11 has no GUI isolation which in this day and age is inexcusable in a desktop operating system. The only decent attempt at proper isolation for X that I know of is Qubes, done using Xen. 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.

sprash 5y ago
> GUI isolation 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.
- Seirdy 5y ago
  > On a system running primarily trusted open source applications 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.

by Seirdy 5y ago

sprash 5y ago

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

Seirdy 5y ago
> On a system running primarily trusted open source applications 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.