Big Endian Firefox: Now with more compositing

I’m currently in the process of trying to bring up the PowerPC platform as a fully supported architecture in Firefox.  I’ve already implemented better support for XPCOM / JS interfacing, and fixed a crash in the JavaScript interpreter. My next challenge is fixing graphical issues, which is proving to be more of a challenge than I initially anticipated.

However, I have broken some new ground.  Before, the compositing engine had wildly inaccurate colouring caused by errant “swizzle methods” (which are functions that take images of one colour type and change them to another – or, “swizzle” them).  This resulted in Firefox 64 (Nightly) looking like this on my workstation:

Firefox, with blue blocks and weird colours everywhere
Firefox, with a broken compositor

I’ve just managed to fix these methods and lo and behold, Firefox 64 (Nightly) looks like this now:

Screenshot_20181019_205618
Firefox, with working compositor

Obviously, there are still some minor nits to work out.  (Namely that my avatar in the top right corner has a blue tint to it!)  I believe the last issues are going to be in the Cairo code, which seems to get very confused by Skia’s byte ordering.  I already have a lead on how to potentially fix this issue.  The good news is that there are no longer any (non-debug) crashers, unless you attempt to view H.264 video.  This is because video playback via FFmpeg crashes due to another byte ordering issue.

All in all, I’m very satisfied with what I was able to knock out in just a few hours on a Friday night.  Thanks go to the #gfx chat room on Mozilla IRC for their guidance in what to look at.

A re-introduction to blogging

I’ve finally moved my blog off Google Blogger and over to WordPress.  WordPress is much nicer and I’m much happier with this platform – and recommend it highly!

I have so much to say, and so many drafts that I’ve written.  I wanted to start by noting that I imported the “best of” my old blog directly in to here, with a few minor edits or notes to ensure consistency.  I’m hoping to talk a lot more about more diverse subjects than just computers and LGBT equality on this one (though I definitely do still care about those).

I have some (hopefully!) exciting articles to follow, including a new series where I review old games.  I also want to write more about my cat Mr Gaz, as well as music, photography, and exploring Oklahoma.  Stay tuned!

Ridiculous unusable download URLs for open source projects

I told myself (and everyone I know) that I wouldn’t write another blog post until I moved the blog off Google Blogger, but I can’t stay silent on this issue.

UPower, the open source power management software used on Linux (and I believe the *BSD family), has recently changed their download URLs. As the lead of Adélie Linux, I personally maintain a significant chunk of “core” desktop experience packages. We consider UPower to be one of those, because it is important to conserve energy whenever possible.

Today I was notified by Repology that UPower was out of date in Adélie. No big deal, I’ll just bump it:

>>> upower: Fetching https://upower.freedesktop.org/releases/upower-0.99.8.tar.xz 
curl: (22) The requested URL returned error: 404 Not Found

“Hmm”, I wondered to myself, “maybe this is a git snapshot package someone uploaded”. It turns out it wasn’t; Debian, Arch, and Fedora are all shipping 0.99.8 now. What gives?

I looked at Debian’s packaging first, since they typically have a good hold on stability. I didn’t even understand the change, though, so I looked up Exherbo’s packaging and was horrified.

Instead of a simple URL, they are now using a GitLab Upload URL which contains an SHA-1 hash in the URL. That means all of our bump scripts can’t work any more. Instead of simply typing a single abump command, for every release of UPower I will now have to:

  1. Open their GitLab instance in a Web browser, which isn’t even installed on any of the staging computers to minimise security hazards:
  2. Wait for all the JavaScript and miscellaneous crap to load;
  3. Context-click the link for the UPower tarball;
  4. Copy the link;
  5. Connect to our staging system remotely from a computer with a Web browser installed;
  6. Open vim on the APKBUILD file for UPower;
  7. Paste the link into the source= line, replacing what is already there;
  8. And then run abuild checksum manually to update the sha512sum in the file.

WHY!? fd.o people, please, out of respect for us packagers that want to give your software to the people who need it, please use your /releases/ directory again!

Exposing The Wayland Lie

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.