Hi, people of the future!

Did you know that I wrote a follow-up article to this one, called “Further Thoughts on Wayland“? This original article was written in a more combative tone than I originally intended, though it did spark discussions that clarified many points. So, please, do read my further thoughts on Wayland. They’re much fairer.

---

Since a growing number of people have been asking me “when” Wayland will be fully supported on Adélie, I felt like I should clear up all the lies that Wayland’s development have apparently made in to folklore.

1. “Wayland can’t be keylogged, unlike X11.”

Apparently, some people think that X11 is insecure because it allows applications to read keystrokes even while not focused (this is how global accelerator keys like Meta+L lock your screen, or Alt+F2 might display an application launcher).

And these same people believe Wayland is more secure because it “doesn’t”.

Except the fact that Wayland is based around libinput, which is trivial to record key events from.

And Wayland’s wl_proxy protocol can be LD_PRELOAD to own the entire system without any privilege required. (I’ve been told that mentioning something that uses LD_PRELOAD is cheating and that you could own any application, not just Wayland. That is true! But this is being sold as “impossible to keylog”. It isn’t.)

You can achieve pretty much the same isolation as Wayland on X11 with cgroups and Xephyr.

2. “Wayland is highly compatible with any hardware, including mobile.”

Wayland compositors universally require OpenGL profiles that older hardware, less expensive hardware, libre hardware, and most embedded chipsets do not provide.

In fact, 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 that will violate your freedom and your privacy, if you want to have any semblance of performance.

Not to mention older hardware that is perfectly capable of running LXQt or Fluxbox under X11 is unable to even start Wayland due to the GPU requirements.

3. “Wayland removes legacy cruft which makes it easier to maintain.”

This may not be a lie, but it is a vast oversimplification. Most Wayland proponents point to network transparency, multiple clipboards, and remote desktop sharing as “legacy cruft” that isn’t needed in X11.

Network transparency allows you to run an X11 application from any computer on your network and display it on your local computer. This is how things like my Spotify-on-Talos hack work (using an x86 in Qemu and ssh -X to the VM to run Spotify on libre PowerPC hardware), and it also allows you to run something like a Web browser on a more powerful device while running X11 locally on a Pinebook, or a Pi, or some other low-power device.

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.

Remote desktop sharing swings regularly from “We’re working on it!” to “Why would you want that?” to “That’s a security risk” in Wayland development circles. When I’m on the road, the ability to use something like Xpra or even VNC to remotely use applications already running back home is invaluable. VNC is also especially useful if I’m not feeling well and need to lie down. I can continue doing whatever I was doing on my desktop from my laptop to distract myself from the illness while still laying down, able to close the lid of the laptop and sleep at any time.

4. “Wayland has fewer bugs than X11.”

While the protocol itself may have fewer bugs than X11, the compositors have far more bugs. And unlike X11, where a compositing window manager crash may leave you without window decorations but a simple `kwin_x11 –replace` from a terminal or SSH session will bring you back to full working order, a crash in a Wayland compositor will terminate your entire session. This is easily the largest deficiency in Wayland, because it means that it is significantly less reliable than X11 in failure modes.

Until Wayland either implements a compositor restart protocol (which would likely cause some gaping security hole by being implemented poorly) or compositors stop having crashing bugs (which is extremely unlikely considering how complex they are, and the GPU drivers underneath), there’s too much time and productivity to be lost to use Wayland.

This is obviously not an exhaustive list and there are plenty of other issues with Wayland. I cannot say with my distro lead hat on that we will *never* support Wayland. What I can say is that I personally would not want to have any part of said support until all of these issues were fixed.

Sometimes things happen that you don’t expect. It can be anything: a power failure during a system upgrade, or maybe a careless chmod 644 /usr/lib/libc.so — in my case, it was the latter (tab completion failure).

Training yourself on the proper way to respond to unexpected failures is the key to recovering them without pain or further data loss. When I had realised my gaffe, the first thing I thought was: How do I chmod it back without the ability to run chmod?

Static-linked rescue binaries are a must-have

The first thing I learned from this experience is that having a set of static-linked rescue binaries somewhere on your system can help in a lot of unexpected situations. We’re going to be adding a busybox-static package to Adélie Linux just for such an occasion, and we may put it in the base system depending on community feedback. If I had a static busybox in, say, /var/recovery or such a path, this would have been a ten second fix rather than a few hour fix.

Embrace the system

After a few other attempts, I realised I could drop to assembler. Long ago, I spent my days writing assembler for system-level code. Since assembler is by design writing “below” C, you are not using the C runtime. Theoretically, you should be able to perform the same tasks as any utility on the system as long as there’s a matching system call for it. And by luck, there is a single syscall: SYS_chmod. Following is x86_64 assembler for Linux to chmod /usr/lib/libc.so back to 755 (executable for all users):

_start:  mov $90,%rax  /* SYS_chmod */
         mov $str,%rdi /* const char *filename */
         mov $493,%rsi /* mode_t mode */
         syscall.      /* do it! */
         mov $60,%rax  /* SYS_exit */
         syscall       /* bye */
str: .ascii "/usr/lib/libc.so\0"


Then it was a matter of as -o fixit.o fixit.S; ld -o fixit fixit.o; strip fixit to generate a 440 byte binary file that would solve my issue. The next issue was transferring it to the laptop. I tried to use bash’s /dev/tcp; unfortunately however, it does not support binary file transfer without something like `cat` or `dd`. Since I could only use the shell, I did what I had not done in over a decade: echo -n followed by the escape codes. Since a lot of the binary was still padding, I omitted the last 200 or so bytes. The output of the echo command needed to be redirected to a binary that was already executable (otherwise the file created would not have execute permission!), so I chose one I probably wouldn’t need urgently: neon-config, a configuration utility for a library I installed for tinkering. The full shell transcript is in my misc Linux directory. This worked! And my laptop ran again…

As I said in the opening of this little musing: I could have made things a lot worse and lost all my open unsaved data by turning off the computer and trying to recover using media. Additionally, that computer is very picky about booting off external media, so that would have wasted even more time. Sometimes all you need is ingenuity and experience, and the only way to acquire either one is by messing about and poking at stuff! Happy hacking.