10 ms·

Exposing the Wayland lie (2018)

116 points by ubercow13 8y ago

est31 8y ago
So wayland is just a waste of time or what? Why are the Wayland maintainers doing it then? To hurt users? I don't get it, sorry.
- Hendrikto 8y ago
  Obviously not, but it is not the solution to all problems, that people make it out to be, and still needs a lot of work.
  - sverige 8y ago
    And really, X11 isn't that bad. Or at least xenocara on OpenBSD, which is what I'm most familiar with and which has addressed some of the more glaring problems.
- AnIdiotOnTheNet 8y ago
  Well, Wayland has been around for a decade now and is still rarely the default for any given distribution. I think that says a lot about Wayland.
  - lapinot 8y ago
    Apart from this being increasingly false (wayland being the default display server for gnome since more than 2 years now), adoption rate is much more correlated to the importance of the component than with the quality of the tool, just look at the history of ipv6. The more a component is part of a low-level core, the longer it will take to replace it with anything. Inertia.
mnd999 8y ago
I can absolutely relate to 4). Getting kicked out of the graphical environment every time sway crashes is frustrating enough for me to abandon it at least until 1.0. The Nvidia issue is also annoying, why it has taken so long to resolve is hard to comprehend.
- mbrumlow 8y ago
  They say and wlroots off master. I have only had a single crash, and that was many months ago. I do keep it fairly updated.
  - mnd999 8y ago
    Maybe I've just been unlucky, or maybe it's a nouveau issue but I've had a fair few to the point that I'm not quite confident enough to use it yet. I'm a great admirer of what the developers have achieved with sway / wlroots though and looking forward to being able to use it full time.
  - lapinot 8y ago
    I do have a sway crash every week or so, next time it happens i'll try to investigate. Nothing unbearable tho, the upside of running new software is seeing the edges getting softer (and sometimes helping with that process).
Hello71 8y ago
Several points made in this article are false, misleading, or complete horseshit. 1. > Except the fact that Wayland is based around libinput, which is trivial to record key events from. This is complete horseshit. You cannot "record key events from libinput", because libinput merely processes key events from evdev in the kernel, received via /dev/input/event*. This is exactly the same as on X. 2. > Wayland’s compositing protocol is basically designed from the ground up to require the kind of closed-source, blob-filled graphics driver from AMD or Nvidia This is malicious FUD. sway's authors have specifically and repeatedly stated that they explicitly do not support AMD and nVidia proprietary drivers. 3. > Network transparency ... allows you to run something like a Web browser on a more powerful device while running X11 locally This is true but misleading. If you actually try to run a modern web browser, you'll find that the experience is usable but extremely poor. The graphics are ugly, it's slow to respond, and videos don't work properly.
- swiley 8y ago
  Re: 3 A lot of people keep saying this about X apps but anything written with GTK will be awful because (from what I understand) it’s just paints everything itself and then uses X11 to actually display what it draws. Plus if you run anything over the network like that GLX doesn’t work. My main two personal complaints with wayland is that writing simple programs without widget libraries is much harder and that the window management is handled by the app (which IMO makes absolutely no sense but maybe there’s something I’m missing, which isn’t crazy since the last time I messed with it was a year or two ago.) Until those two things get dealt with I’m unwilling to use it.
  - jcelerier 8y ago
    > A lot of people keep saying this about X apps but anything written with GTK will be awful because (from what I understand) it’s just paints everything itself and then uses X11 to actually display what it draws. Plus if you run anything over the network like that GLX doesn’t work. I don't find that to be true, e.g. I've used pavucontrol (a GTK3 app) over the wifi X11 networking and it worked fine - the very nice thing with X11 networking is that it will use your client DPI for rendering / Xresources / etc... so you can have both lo-dpi and hi-dpi clients connecting to the same machine and it works for both without any configuration.
ryu2k2 8y ago
Why do we need the power of GPUs meant for fast and complex 3D graphics applications to draw 2D text, lines and icons?
- pasta 8y ago
  Because 3D is just an extra dimension for the same calculations? The GPU does not accelerate 3D, but the computations (so 3D can be much faster).
  - zozbot123 8y ago
    Many graphics cards/chipsets/etc. do accelerate 2D operations, unfortunately there's no feasible unified model of a "2D hardware accelerator" the way there is with 3D, so there's no unified support for it in kernel, either. The whole thing is inherently hardware-dependent.
    - vetinari 8y ago
      Not anymore; at least not like they used to in 90's and 2000's. Today, they expose some overlays (and some limitations, how they can be used) and that's it. There is a Nvidia OpenGL extension NV_path_rendering that was intended for accelerating 2d, but it wasn't widely adopted.
- emersion 8y ago
  Wayland doesn't require you to use GPUs. Only wl_shm is in the core protocol, you can build a software-only Wayland compositor without any hacks, with shared memory. By the way, Wayland has nothing to do with drawing text, lines and icons. You just give Wayland a bunch of pixels. That said, using the GPU for compositing is often better for performance and battery savings. It doesn't require anything fancy, GLESv2 is used by many Wayland compositors and is widely available, even on old hardware. It doesn't require proprietary blobs.
- api 8y ago
  To get that load off the CPU mostly.
ddevault 8y ago
I am the maintainer of the most influential library in the Wayland ecosystem, forming the foundation of a strong majority of Wayland compositors, and the author of a popular Wayland compositor on top of this still. Last week I asked the author of this article to issue a full retraction, because every point is a blatant falsehood. Here is my appeal to the author, with some edits for the sake of general audiences: >I'd like to ask you to update this with a retraction at the top. I'm not sure if you recall when we spoke about this on IRC a few months ago, but each of these points is entirely false, and the article is a dishonest smear on Wayland (though I assume you only had the best of intentions). To recap: >1 - recording events from libinput only works if you're root, and if you're root, you can do whatever you want. This is hardly a valid criticism of Wayland. LD_PRELOLAD hacks don't work if the compositor launches the programs - some simple .bashrc trick won't work, and getting the LD_PRELOAD into .bashrc requires being unsandboxed, which itself opens up a wealth of side channel attacks. None of this is a mark against Wayland - it's only one part of a secure system, and the other parts are mandatory. >2 - Wayland is a protocol, not its implementation. And many implementations are widely supported by older hardware. wlroots, which is the dominant Wayland ecosystem with over 75% of all compositors using it for their rendering, requires only GLESv2, which is the most broadly supported OpenGL standard. >3 - The headline doesn't match the body, but both are wrong. The design of Wayland and its implementations is indeed much simpler than X11/xorg-server. As for the use-cases brought up in the body of this point, the caracatures of Wayland developers are rude and incorrect. For network transparency, it wouldn't be difficult but no one who cares has stepped up to do the work. Multiple clipboards are now supported. Many of the pieces of remote desktop are in place, and again someone who cares needs to step up to implement the rest and tie it together. We are ready and waiting to support anyone who wants to step up to complete this work. >4 - A bug in xorg-server will similarly bring down your X session. Driver bugs affect both. Bugs are addressed when they're found, what more do you want from us? Regardless, restart protocols are in the research phase and your comments about the security holes implicated are blatant speculation. >Support whatever you wish in your distro, but please don't publish dishonest articles.
- CyberShadow 8y ago
  > Last week I asked the author of this article to issue a full retraction, because every point is a blatant falsehood. That doesn't sound reasonable. > LD_PRELOLAD hacks don't work if the compositor launches the programs - some simple .bashrc trick won't work, and getting the LD_PRELOAD into .bashrc requires being unsandboxed, which itself opens up a wealth of side channel attacks. This lists quite a few assumptions. Are there many distributions that provide these assumptions out of the box (specifically, the compositor running all applications, and all applications being sandboxed)? > >4 - A bug in xorg-server will similarly bring down your X session. A Xorg server needs to implement: - the display server A Wayland compositor needs to implement: - the display server - the window manager - the compositor - the hotkey daemon - the screenshotting tool - everything else that is now unimplementable in Wayland, but needs to be in the Wayland compositor because users need them and Wayland compositor implementers have no choice but to provide the features as API extensions. I'm not really sure what's XWayland's story security-wise, but from my limited understanding, it is a component that is not going away soon, and allows bypassing some limitations of Wayland's API in order to accommodate X11 clients.
zozbot123 8y ago
So far, Wayland is removing legacy cruft and replacing it with newfangled cruft. The Wayland protocol itself is not even well specified in the way that X is - the whole thing is very far from true maturity. Just like, e.g. Pulseaudio, which is apparently now getting replaced by Pipewire.
rwmj 8y ago
Until Wayland supports X-style remoting of applications, I literally can't use it, so here's hoping X remains an option for a long time to come. (Edit: Or Wayland implements X-style remoting which would probably be the preferable option since in other respects such as client-side rendering using the GPU Wayland is cleaner)
- Sir_Cmpwn 8y ago
  >Until Wayland supports X-style remoting of applications, I literally can't use it, so here's hoping X remains an option for a long time to come. Xwayland supports X forwarding, so your existing forwarding setup will work fine OOTB. What's missing is forwarding native Wayland applications, but if everything you use today works on X11, it'll work on a Wayland compositor via Xwayland too.
dooglius 8y ago
> wl_proxy protocol can be LD_PRELOAD to own the entire system without any privilege required I don't understand this claim. LD_PRELOAD doesn't allow you to do anything you couldn't normally do. It sounds like the claim is if you run Wayland with LD_PRELOAD set, it's vulnerable, but this is a case of what Raymond Chen would call being on the other side of the airtight hatchway.
CyberShadow 8y ago
Thank you. From what I've seen, Wayland seems to follow a very narrow set of use cases, and willfully ignores others outside its philosophy, no matter what their practical applications might be. From what I remember reading previously: - Wine is unimplementable in Wayland. By design. - Programs cannot set their own hotkeys in Wayland. You must use the desktop enviromnent's hotkey tool to set global hotkeys. (Desktop enviroments may provide APIs for this, but then you get the foreseeable issues with using e.g. KDE apps on Gnome. And what if you don't want a desktop "environment"?) - Screenshotting and screen casting tools are unimplementable in Wayland, by design. - Some Wayland implementations provide additional features, like screenshotting / hotkey registration, anyway, as API extensions. These extensions are not standardized and require individual support for each Wayland implementation in each program, thus causing further fragmentation. - I use the X forwarding feature so often that I have a hotkey on my laptop to open an Emacs frame running on my desktop (on my laptop's screen). Being able to jump between machines while keeping the entire session, incl. open and unsaved files, is pretty great. I can certainly think of situations where Wayland's advantages greatly outweigh its drawbacks, but its philosophy seems so much at odds with at least the way I interact with my computer, that the idea of switching to Wayland seems completely unfathomable. As far as I can see, at this rate, Xorg will live forever. I've been instead working on my own little tool to fix the few annoyances in Xorg clients that I ran into (the ease with which I've achieved this and the flexibility of the tool speaks further in Xorg's favor): https://github.com/CyberShadow/hax11 https://github.com/CyberShadow/hax11
- hawski 8y ago
  Could you expand on why Wine is unimplementable in Wayland?
  - CyberShadow 8y ago
    Essentially because many Windows APIs are unimplementable in Wayland. Here is some discussion in Wine's bugtracker: https://bugs.winehq.org/show_bug.cgi?id=42284 https://bugs.winehq.org/show_bug.cgi?id=42284
    - 8y ago
lewiscollard 8y ago
Regardless of the merits of the article, I don't like "lie", because it implies people deliberately spreading falsehoods, and the comments here so far reflect that tone which makes everyone's life a little worse. We're all in this together; can we please be nicer to each other and not assume bad faith?
IshKebab 8y ago
> Network transparency allows you to run an X11 application from any computer on your network and display it on your local computer. This is a rubbish point. Remote X may work OKish over a wired LAN, but over anything else it sucks. Not even NX uses the X11 protocol any more. Honestly the only reason people even use it over a LAN is because VNC is so archaic and nobody has written a modern version. Wayland actually makes that easier though. The point about crashing compositors is good though. Windows can handle a crash in the graphics driver seamlessly. I don't think any Wayland compositors can come close to that.
- CyberShadow 8y ago
  > Remote X may work OKish over a wired LAN, but over anything else it sucks. It depends entirely on the software. E.g., Emacs is great (and even kinda usable across the ocean), while Firefox and most Qt/GTK programs are much less so.
  - zbuf 8y ago
    For the Qt applications, try setting QT_GRAPHICSSYSTEM=native. I did experience Qt applications pushing whole window-sized bitmaps until I discovered this. Now remote $DISPLAY works well again. It seems the functionality is there, just the default setting gives poor performance over the network. I agree, good software works over wireless LAN with no issues. At my workplace this is used extensively.
- welterde 8y ago
  Applications that use X11 properly don't just work OKish over wired LAN, but work good enough that you can't tell it's not running locally.. One usual workflow is to ssh into a data reduction machine, do some reduction task and inspect the data products without having to copy them to the local machine or use NFS or the likes to access the files.
  - delian66 8y ago
    What is a data reduction machine?
Spivak 8y ago
> Wayland is impossible to keylog. This is an incorrect assessment of the claim which is, "with Wayland it becomes possible to build a system where applications cannot record each-other's events." To the best of my knowledge the only approach with X11 that actually works is running each app with a separate X server. The author points out that being able to register global handlers or programmatically interact with other apps is useful which is why it's possible by asking the compositor nicely. The trick with libinput requires that the system already be pwnd. Another way of saying the same thing, "you cannot meaningfully sandbox applications that talk to your X server." > Network Transparency Is a bad thing and a poor remote desktop solution. Let's say you have a desktop with an Nvidia graphics card and you've installed their drivers. Your laptop is using the OSS Intel drivers. You forward an OpenGL app from your desktop to your laptop -- it will crash. Why? Because Nvidia's libGL expects to talk to a server with Nvidia's GLX extension of the same version. However, a ton of work is going into getting screencasting and remote desktop working under Wayland in a manner that will let you implement whatever protocol you care to speak on top RDP/VNC. And VNC currently works on Mutter so I'm not sure why the author is bemoaning it's loss. It's the feature that's getting the most development time right now. > Multiple clipboards That's up to the implementor, Wayland had a very general API that's used to exchange data between clients that can be used to implement clipboards in any way the compositor sees fit. Just because GNOME/KDE don't want to maintain it doesn't mean it's not there. > Restarting ends your session. If your X server crashes it ends your session too. So this is really an argument that X.org is more stable than Mutter/Kwin. I don't think the devs will argue with that but the point is that they'll get there.
- yjftsjthsd-h 8y ago
  > Multiple clipboards If it's up to the implementer, and two of the biggest options don't do it, then it might as well not exist.
  - mbrumlow 8y ago
    It's open source. You can add support if you so desire. You can even likely get it pushed upstream if what is done makes sense.
7e 8y ago
The most glaring deficiency so far is lack of support for the binary NVIDIA driver in most implementations. The whole affair is rather childish.
- ddevault 8y ago
  The lack of support for standard Linux APIs in the NVIDIA driver, you mean. You're asking compositors to implement this: if (nvidia proprietary driver) { /* thousands of lines of code */ } else { /* thousands of lines of code */ } We cannot debug the proprietary driver. We cannot fix bugs in the proprietary driver. We cannot read the code to understand it's behavior. Our answer: "no".
  - codedokode 8y ago
    Actually, you don't need to read the driver's code to run it. Just provide the environment the driver needs. If you could provide an environment Windows provides for the drivers then you would be able to run Windows' drivers.
  - nmikhailov 8y ago
    > Our answer: "no". Good thing you are not speaking for KDE and Gnome then.
    - lasagnaphil 8y ago
      But KDE and GNOME are quite large organizations which gets financially supported by many tech companies. And they seem to have closer connections with NVIDIA engineers compared to sway and wlroots. I've even heard that NVIDIA was directly contributing the EGLStream backend code for Gnome and KDE (see the links below) https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-Better-EGLStreams-Mutt https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-B... https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-KDE-KWin-EGLStreams-POC https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-K... It's pretty sad that compared to this, sway and wlroots are being completely neglected by NVIDIA. And I think that is precisely why the sway project decided to ditch proprietary NVIDIA driver support.
codedokode 8y ago
Not being able to make a keylogger is actually bad thing. Both X11 and Wayland have poorly designed keyboard events handling (which was defined in XKeyboard spec in 1995). For example, you want to use Ctrl + Shift keys to switch keyboard layouts on release. Simple thing that is working in Windows. You cannot do that in Linux, because: - if you assign Ctrl + Shift to switch keyboard layout then when these keys are pressed, the event will be consumed and you cannot use combinations like Ctrl + Shift + F (this will be interpreted as Ctrl + F or Shift + F depending on what key you have pressed earlier) - you cannot make a separate program that would monitor all key presses and releases and switch layout without breaking other programs. In the X server and extensions there is no such feature as "monitoring pressed keys" The only way to do it reliably is to have a privileged program that would listen to events in /dev/input. By the way this bug hasn't been fixed for 14 years [1], and instead of fixing it the distributions have been using different hacks and workarounds. Also, they don't warn user that using Ctrl + Shift to switch layout will break hotkeys using these modifiers. Another issue is remote control programs like VNC. In both X11 and Wayland to emulate user input VNC server muss pass a key number to the X server or Wayland compositor. Not a keysym, not a unicode codepoint, but rather a number of the key on a physical keyboard. Now guess what happens if VNC client's machine has a keyboard layout with characters not present in layout on VNC server's machine? Everything gets broken. Typical solution for this is to find unused key number and patch current keyboard layout before sending a key press event to the X server. Because of the same reason on-screen keyboards on Linux cannot produce characters not present in keyboard layout. Emoji, for example. [1] https://bugs.freedesktop.org/show_bug.cgi?id=865 https://bugs.freedesktop.org/show_bug.cgi?id=865
- yellow_lead 8y ago
  Are you referring specifically to Ctrl + Shift? Because I use Super + Space (think it's default) to switch between languages in Gnome on Fedora with Wayland and it works fine for me, even when an app has focus.
  - codedokode 8y ago
    Ctrl + Shift (or Alt + Shift) is what Windows uses so people migrating from Windows often choose this combination. It is actually a poor choice, because you have to remember which layout is selected and make mistakes, so you type something in the wrong layout, notice it and have to delete and retype it again. A better solution is to use non-modal layout switching, when you have a dedicated key for every layout. On Windows I use left and right Control keys (with a help of a closed-source program), so I always start typing with pressing one of them. But on Linux I cannot use them (I tried to write a program that would listen to /dev/input but found out that you cannot switch layout in Wayland-based Gnome from an external program because there is no API for this). Super + Space which is used on Macs, is also a poor choice. It is surprising that Apple, which manufactures it own hardware, was unable to just make dedicated keys for different layouts.
cat199 8y ago
... beware the GNUluminati
crsmithdev 8y ago
> You can achieve pretty much the same isolation as Wayland on X11 with cgroups and Xephyr. Wait, you mean I could get something almost as good just by adding in two additional technologies to the mix? Amazing!
- giornogiovanna 8y ago
  Adding just one application (Xephyr) is a whole lot easier than replacing X, though. It's probably worse for isolation, but it's also probably good enough.
ken 8y ago
> Multiple clipboards provide flexibility and power. I will be the first to admit that a great deal of people don’t know about this feature, and it is entirely possible to use a computer without it (look at Windows or the Mac OS). That doesn’t mean that I would enjoy losing it, however. macOS sort of has multiple clipboards, if you squint just right, but they aren't all equally supported. Select "aaa", command-C, then put your cursor at the front of "bbb", control-K. You can paste the former with command-V, and the latter with control-Y (just like Emacs). The kill buffer is just for text, and has basically no API, so third-party programs can't (easily) use it. There's also the search selection (command-E), which is pretty much only usable for moving the selection to the search box. It's another semi-persistent way to save some text, though. The situation reminds me of the 6502 (which has 3 registers, each with specific duties), or the 3 robots of Robot Odyssey.
- panic 8y ago
  > There's also the search selection (command-E), which is pretty much only usable for moving the selection to the search box. In most apps, Command-E followed by Command-G will search for the selected text without even going through the search box!
mishurov 8y ago
Wayland is a meme for Arch-tier schoolkids - it wasn't even put into LTS - but at least it's not Apple NPC retardation.

116 points by ubercow13 8y ago

So wayland is just a waste of time or what? Why are the Wayland maintainers doing it then? To hurt users? I don't get it, sorry.

Hendrikto 8y ago
Obviously not, but it is not the solution to all problems, that people make it out to be, and still needs a lot of work.
- sverige 8y ago
  And really, X11 isn't that bad. Or at least xenocara on OpenBSD, which is what I'm most familiar with and which has addressed some of the more glaring problems.
AnIdiotOnTheNet 8y ago
Well, Wayland has been around for a decade now and is still rarely the default for any given distribution. I think that says a lot about Wayland.
- lapinot 8y ago
  Apart from this being increasingly false (wayland being the default display server for gnome since more than 2 years now), adoption rate is much more correlated to the importance of the component than with the quality of the tool, just look at the history of ipv6. The more a component is part of a low-level core, the longer it will take to replace it with anything. Inertia.

mnd999 8y ago

I can absolutely relate to 4). Getting kicked out of the graphical environment every time sway crashes is frustrating enough for me to abandon it at least until 1.0. The Nvidia issue is also annoying, why it has taken so long to resolve is hard to comprehend.

mbrumlow 8y ago
They say and wlroots off master. I have only had a single crash, and that was many months ago. I do keep it fairly updated.
- mnd999 8y ago
  Maybe I've just been unlucky, or maybe it's a nouveau issue but I've had a fair few to the point that I'm not quite confident enough to use it yet. I'm a great admirer of what the developers have achieved with sway / wlroots though and looking forward to being able to use it full time.
- lapinot 8y ago
  I do have a sway crash every week or so, next time it happens i'll try to investigate. Nothing unbearable tho, the upside of running new software is seeing the edges getting softer (and sometimes helping with that process).

Hello71 8y ago

Several points made in this article are false, misleading, or complete horseshit. 1. > Except the fact that Wayland is based around libinput, which is trivial to record key events from. This is complete horseshit. You cannot "record key events from libinput", because libinput merely processes key events from evdev in the kernel, received via /dev/input/event*. This is exactly the same as on X. 2. > Wayland’s compositing protocol is basically designed from the ground up to require the kind of closed-source, blob-filled graphics driver from AMD or Nvidia This is malicious FUD. sway's authors have specifically and repeatedly stated that they explicitly do not support AMD and nVidia proprietary drivers. 3. > Network transparency ... allows you to run something like a Web browser on a more powerful device while running X11 locally This is true but misleading. If you actually try to run a modern web browser, you'll find that the experience is usable but extremely poor. The graphics are ugly, it's slow to respond, and videos don't work properly.

swiley 8y ago
Re: 3 A lot of people keep saying this about X apps but anything written with GTK will be awful because (from what I understand) it’s just paints everything itself and then uses X11 to actually display what it draws. Plus if you run anything over the network like that GLX doesn’t work. My main two personal complaints with wayland is that writing simple programs without widget libraries is much harder and that the window management is handled by the app (which IMO makes absolutely no sense but maybe there’s something I’m missing, which isn’t crazy since the last time I messed with it was a year or two ago.) Until those two things get dealt with I’m unwilling to use it.
- jcelerier 8y ago
  > A lot of people keep saying this about X apps but anything written with GTK will be awful because (from what I understand) it’s just paints everything itself and then uses X11 to actually display what it draws. Plus if you run anything over the network like that GLX doesn’t work. I don't find that to be true, e.g. I've used pavucontrol (a GTK3 app) over the wifi X11 networking and it worked fine - the very nice thing with X11 networking is that it will use your client DPI for rendering / Xresources / etc... so you can have both lo-dpi and hi-dpi clients connecting to the same machine and it works for both without any configuration.

ryu2k2 8y ago

Why do we need the power of GPUs meant for fast and complex 3D graphics applications to draw 2D text, lines and icons?

pasta 8y ago
Because 3D is just an extra dimension for the same calculations? The GPU does not accelerate 3D, but the computations (so 3D can be much faster).
- zozbot123 8y ago
  Many graphics cards/chipsets/etc. do accelerate 2D operations, unfortunately there's no feasible unified model of a "2D hardware accelerator" the way there is with 3D, so there's no unified support for it in kernel, either. The whole thing is inherently hardware-dependent.
  - vetinari 8y ago
    Not anymore; at least not like they used to in 90's and 2000's. Today, they expose some overlays (and some limitations, how they can be used) and that's it. There is a Nvidia OpenGL extension NV_path_rendering that was intended for accelerating 2d, but it wasn't widely adopted.
emersion 8y ago
Wayland doesn't require you to use GPUs. Only wl_shm is in the core protocol, you can build a software-only Wayland compositor without any hacks, with shared memory. By the way, Wayland has nothing to do with drawing text, lines and icons. You just give Wayland a bunch of pixels. That said, using the GPU for compositing is often better for performance and battery savings. It doesn't require anything fancy, GLESv2 is used by many Wayland compositors and is widely available, even on old hardware. It doesn't require proprietary blobs.
api 8y ago
To get that load off the CPU mostly.

ddevault 8y ago

I am the maintainer of the most influential library in the Wayland ecosystem, forming the foundation of a strong majority of Wayland compositors, and the author of a popular Wayland compositor on top of this still. Last week I asked the author of this article to issue a full retraction, because every point is a blatant falsehood. Here is my appeal to the author, with some edits for the sake of general audiences: >I'd like to ask you to update this with a retraction at the top. I'm not sure if you recall when we spoke about this on IRC a few months ago, but each of these points is entirely false, and the article is a dishonest smear on Wayland (though I assume you only had the best of intentions). To recap: >1 - recording events from libinput only works if you're root, and if you're root, you can do whatever you want. This is hardly a valid criticism of Wayland. LD_PRELOLAD hacks don't work if the compositor launches the programs - some simple .bashrc trick won't work, and getting the LD_PRELOAD into .bashrc requires being unsandboxed, which itself opens up a wealth of side channel attacks. None of this is a mark against Wayland - it's only one part of a secure system, and the other parts are mandatory. >2 - Wayland is a protocol, not its implementation. And many implementations are widely supported by older hardware. wlroots, which is the dominant Wayland ecosystem with over 75% of all compositors using it for their rendering, requires only GLESv2, which is the most broadly supported OpenGL standard. >3 - The headline doesn't match the body, but both are wrong. The design of Wayland and its implementations is indeed much simpler than X11/xorg-server. As for the use-cases brought up in the body of this point, the caracatures of Wayland developers are rude and incorrect. For network transparency, it wouldn't be difficult but no one who cares has stepped up to do the work. Multiple clipboards are now supported. Many of the pieces of remote desktop are in place, and again someone who cares needs to step up to implement the rest and tie it together. We are ready and waiting to support anyone who wants to step up to complete this work. >4 - A bug in xorg-server will similarly bring down your X session. Driver bugs affect both. Bugs are addressed when they're found, what more do you want from us? Regardless, restart protocols are in the research phase and your comments about the security holes implicated are blatant speculation. >Support whatever you wish in your distro, but please don't publish dishonest articles.

CyberShadow 8y ago
> Last week I asked the author of this article to issue a full retraction, because every point is a blatant falsehood. That doesn't sound reasonable. > LD_PRELOLAD hacks don't work if the compositor launches the programs - some simple .bashrc trick won't work, and getting the LD_PRELOAD into .bashrc requires being unsandboxed, which itself opens up a wealth of side channel attacks. This lists quite a few assumptions. Are there many distributions that provide these assumptions out of the box (specifically, the compositor running all applications, and all applications being sandboxed)? > >4 - A bug in xorg-server will similarly bring down your X session. A Xorg server needs to implement: - the display server A Wayland compositor needs to implement: - the display server - the window manager - the compositor - the hotkey daemon - the screenshotting tool - everything else that is now unimplementable in Wayland, but needs to be in the Wayland compositor because users need them and Wayland compositor implementers have no choice but to provide the features as API extensions. I'm not really sure what's XWayland's story security-wise, but from my limited understanding, it is a component that is not going away soon, and allows bypassing some limitations of Wayland's API in order to accommodate X11 clients.

zozbot123 8y ago

So far, Wayland is removing legacy cruft and replacing it with newfangled cruft. The Wayland protocol itself is not even well specified in the way that X is - the whole thing is very far from true maturity. Just like, e.g. Pulseaudio, which is apparently now getting replaced by Pipewire.

rwmj 8y ago

Until Wayland supports X-style remoting of applications, I literally can't use it, so here's hoping X remains an option for a long time to come. (Edit: Or Wayland implements X-style remoting which would probably be the preferable option since in other respects such as client-side rendering using the GPU Wayland is cleaner)

Sir_Cmpwn 8y ago
>Until Wayland supports X-style remoting of applications, I literally can't use it, so here's hoping X remains an option for a long time to come. Xwayland supports X forwarding, so your existing forwarding setup will work fine OOTB. What's missing is forwarding native Wayland applications, but if everything you use today works on X11, it'll work on a Wayland compositor via Xwayland too.

dooglius 8y ago

> wl_proxy protocol can be LD_PRELOAD to own the entire system without any privilege required I don't understand this claim. LD_PRELOAD doesn't allow you to do anything you couldn't normally do. It sounds like the claim is if you run Wayland with LD_PRELOAD set, it's vulnerable, but this is a case of what Raymond Chen would call being on the other side of the airtight hatchway.

CyberShadow 8y ago

Thank you. From what I've seen, Wayland seems to follow a very narrow set of use cases, and willfully ignores others outside its philosophy, no matter what their practical applications might be. From what I remember reading previously: - Wine is unimplementable in Wayland. By design. - Programs cannot set their own hotkeys in Wayland. You must use the desktop enviromnent's hotkey tool to set global hotkeys. (Desktop enviroments may provide APIs for this, but then you get the foreseeable issues with using e.g. KDE apps on Gnome. And what if you don't want a desktop "environment"?) - Screenshotting and screen casting tools are unimplementable in Wayland, by design. - Some Wayland implementations provide additional features, like screenshotting / hotkey registration, anyway, as API extensions. These extensions are not standardized and require individual support for each Wayland implementation in each program, thus causing further fragmentation. - I use the X forwarding feature so often that I have a hotkey on my laptop to open an Emacs frame running on my desktop (on my laptop's screen). Being able to jump between machines while keeping the entire session, incl. open and unsaved files, is pretty great. I can certainly think of situations where Wayland's advantages greatly outweigh its drawbacks, but its philosophy seems so much at odds with at least the way I interact with my computer, that the idea of switching to Wayland seems completely unfathomable. As far as I can see, at this rate, Xorg will live forever. I've been instead working on my own little tool to fix the few annoyances in Xorg clients that I ran into (the ease with which I've achieved this and the flexibility of the tool speaks further in Xorg's favor): https://github.com/CyberShadow/hax11 https://github.com/CyberShadow/hax11

hawski 8y ago
Could you expand on why Wine is unimplementable in Wayland?
- CyberShadow 8y ago
  Essentially because many Windows APIs are unimplementable in Wayland. Here is some discussion in Wine's bugtracker: https://bugs.winehq.org/show_bug.cgi?id=42284 https://bugs.winehq.org/show_bug.cgi?id=42284
  - 8y ago

lewiscollard 8y ago

Regardless of the merits of the article, I don't like "lie", because it implies people deliberately spreading falsehoods, and the comments here so far reflect that tone which makes everyone's life a little worse. We're all in this together; can we please be nicer to each other and not assume bad faith?

IshKebab 8y ago

> Network transparency allows you to run an X11 application from any computer on your network and display it on your local computer. This is a rubbish point. Remote X may work OKish over a wired LAN, but over anything else it sucks. Not even NX uses the X11 protocol any more. Honestly the only reason people even use it over a LAN is because VNC is so archaic and nobody has written a modern version. Wayland actually makes that easier though. The point about crashing compositors is good though. Windows can handle a crash in the graphics driver seamlessly. I don't think any Wayland compositors can come close to that.

CyberShadow 8y ago
> Remote X may work OKish over a wired LAN, but over anything else it sucks. It depends entirely on the software. E.g., Emacs is great (and even kinda usable across the ocean), while Firefox and most Qt/GTK programs are much less so.
- zbuf 8y ago
  For the Qt applications, try setting QT_GRAPHICSSYSTEM=native. I did experience Qt applications pushing whole window-sized bitmaps until I discovered this. Now remote $DISPLAY works well again. It seems the functionality is there, just the default setting gives poor performance over the network. I agree, good software works over wireless LAN with no issues. At my workplace this is used extensively.
welterde 8y ago
Applications that use X11 properly don't just work OKish over wired LAN, but work good enough that you can't tell it's not running locally.. One usual workflow is to ssh into a data reduction machine, do some reduction task and inspect the data products without having to copy them to the local machine or use NFS or the likes to access the files.
- delian66 8y ago
  What is a data reduction machine?

Spivak 8y ago

> Wayland is impossible to keylog. This is an incorrect assessment of the claim which is, "with Wayland it becomes possible to build a system where applications cannot record each-other's events." To the best of my knowledge the only approach with X11 that actually works is running each app with a separate X server. The author points out that being able to register global handlers or programmatically interact with other apps is useful which is why it's possible by asking the compositor nicely. The trick with libinput requires that the system already be pwnd. Another way of saying the same thing, "you cannot meaningfully sandbox applications that talk to your X server." > Network Transparency Is a bad thing and a poor remote desktop solution. Let's say you have a desktop with an Nvidia graphics card and you've installed their drivers. Your laptop is using the OSS Intel drivers. You forward an OpenGL app from your desktop to your laptop -- it will crash. Why? Because Nvidia's libGL expects to talk to a server with Nvidia's GLX extension of the same version. However, a ton of work is going into getting screencasting and remote desktop working under Wayland in a manner that will let you implement whatever protocol you care to speak on top RDP/VNC. And VNC currently works on Mutter so I'm not sure why the author is bemoaning it's loss. It's the feature that's getting the most development time right now. > Multiple clipboards That's up to the implementor, Wayland had a very general API that's used to exchange data between clients that can be used to implement clipboards in any way the compositor sees fit. Just because GNOME/KDE don't want to maintain it doesn't mean it's not there. > Restarting ends your session. If your X server crashes it ends your session too. So this is really an argument that X.org is more stable than Mutter/Kwin. I don't think the devs will argue with that but the point is that they'll get there.

yjftsjthsd-h 8y ago
> Multiple clipboards If it's up to the implementer, and two of the biggest options don't do it, then it might as well not exist.
- mbrumlow 8y ago
  It's open source. You can add support if you so desire. You can even likely get it pushed upstream if what is done makes sense.

7e 8y ago

The most glaring deficiency so far is lack of support for the binary NVIDIA driver in most implementations. The whole affair is rather childish.

ddevault 8y ago
The lack of support for standard Linux APIs in the NVIDIA driver, you mean. You're asking compositors to implement this: if (nvidia proprietary driver) { /* thousands of lines of code */ } else { /* thousands of lines of code */ } We cannot debug the proprietary driver. We cannot fix bugs in the proprietary driver. We cannot read the code to understand it's behavior. Our answer: "no".
- codedokode 8y ago
  Actually, you don't need to read the driver's code to run it. Just provide the environment the driver needs. If you could provide an environment Windows provides for the drivers then you would be able to run Windows' drivers.
- nmikhailov 8y ago
  > Our answer: "no". Good thing you are not speaking for KDE and Gnome then.
  - lasagnaphil 8y ago
    But KDE and GNOME are quite large organizations which gets financially supported by many tech companies. And they seem to have closer connections with NVIDIA engineers compared to sway and wlroots. I've even heard that NVIDIA was directly contributing the EGLStream backend code for Gnome and KDE (see the links below) https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-Better-EGLStreams-Mutt https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-B... https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-KDE-KWin-EGLStreams-POC https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-K... It's pretty sad that compared to this, sway and wlroots are being completely neglected by NVIDIA. And I think that is precisely why the sway project decided to ditch proprietary NVIDIA driver support.

codedokode 8y ago

Not being able to make a keylogger is actually bad thing. Both X11 and Wayland have poorly designed keyboard events handling (which was defined in XKeyboard spec in 1995). For example, you want to use Ctrl + Shift keys to switch keyboard layouts on release. Simple thing that is working in Windows. You cannot do that in Linux, because: - if you assign Ctrl + Shift to switch keyboard layout then when these keys are pressed, the event will be consumed and you cannot use combinations like Ctrl + Shift + F (this will be interpreted as Ctrl + F or Shift + F depending on what key you have pressed earlier) - you cannot make a separate program that would monitor all key presses and releases and switch layout without breaking other programs. In the X server and extensions there is no such feature as "monitoring pressed keys" The only way to do it reliably is to have a privileged program that would listen to events in /dev/input. By the way this bug hasn't been fixed for 14 years [1], and instead of fixing it the distributions have been using different hacks and workarounds. Also, they don't warn user that using Ctrl + Shift to switch layout will break hotkeys using these modifiers. Another issue is remote control programs like VNC. In both X11 and Wayland to emulate user input VNC server muss pass a key number to the X server or Wayland compositor. Not a keysym, not a unicode codepoint, but rather a number of the key on a physical keyboard. Now guess what happens if VNC client's machine has a keyboard layout with characters not present in layout on VNC server's machine? Everything gets broken. Typical solution for this is to find unused key number and patch current keyboard layout before sending a key press event to the X server. Because of the same reason on-screen keyboards on Linux cannot produce characters not present in keyboard layout. Emoji, for example. [1] https://bugs.freedesktop.org/show_bug.cgi?id=865 https://bugs.freedesktop.org/show_bug.cgi?id=865

yellow_lead 8y ago
Are you referring specifically to Ctrl + Shift? Because I use Super + Space (think it's default) to switch between languages in Gnome on Fedora with Wayland and it works fine for me, even when an app has focus.
- codedokode 8y ago
  Ctrl + Shift (or Alt + Shift) is what Windows uses so people migrating from Windows often choose this combination. It is actually a poor choice, because you have to remember which layout is selected and make mistakes, so you type something in the wrong layout, notice it and have to delete and retype it again. A better solution is to use non-modal layout switching, when you have a dedicated key for every layout. On Windows I use left and right Control keys (with a help of a closed-source program), so I always start typing with pressing one of them. But on Linux I cannot use them (I tried to write a program that would listen to /dev/input but found out that you cannot switch layout in Wayland-based Gnome from an external program because there is no API for this). Super + Space which is used on Macs, is also a poor choice. It is surprising that Apple, which manufactures it own hardware, was unable to just make dedicated keys for different layouts.

cat199 8y ago

... beware the GNUluminati

crsmithdev 8y ago

> You can achieve pretty much the same isolation as Wayland on X11 with cgroups and Xephyr. Wait, you mean I could get something almost as good just by adding in two additional technologies to the mix? Amazing!

giornogiovanna 8y ago
Adding just one application (Xephyr) is a whole lot easier than replacing X, though. It's probably worse for isolation, but it's also probably good enough.

ken 8y ago

> Multiple clipboards provide flexibility and power. I will be the first to admit that a great deal of people don’t know about this feature, and it is entirely possible to use a computer without it (look at Windows or the Mac OS). That doesn’t mean that I would enjoy losing it, however. macOS sort of has multiple clipboards, if you squint just right, but they aren't all equally supported. Select "aaa", command-C, then put your cursor at the front of "bbb", control-K. You can paste the former with command-V, and the latter with control-Y (just like Emacs). The kill buffer is just for text, and has basically no API, so third-party programs can't (easily) use it. There's also the search selection (command-E), which is pretty much only usable for moving the selection to the search box. It's another semi-persistent way to save some text, though. The situation reminds me of the 6502 (which has 3 registers, each with specific duties), or the 3 robots of Robot Odyssey.

panic 8y ago
> There's also the search selection (command-E), which is pretty much only usable for moving the selection to the search box. In most apps, Command-E followed by Command-G will search for the selected text without even going through the search box!

mishurov 8y ago

Wayland is a meme for Arch-tier schoolkids - it wasn't even put into LTS - but at least it's not Apple NPC retardation.