For a couple of years now we’ve been interested in trying this Firefox sync thing. It always sounded like a pretty nice idea, and being able to host your own storage server that holds all your data sounded very nice indeed. Unfortunately the same can not be said about the accounts server that is also needed to get sync working: while we can keep control of our data just fine, the metadata would always live on Mozilla servers in the Mozilla accounts system. This obviously would not do.

Fortunately Mozilla publishes their code for the accounts server complex in their fxa repository. It’s pretty easy to clone this repository to look at what the accounts server does (although it’s still not obvious, the accounts server being a massive pile of javascript), and the repository even contains a number of dockerfiles for self-hosters. Awesome! Right?

Imagine a little ARM board with a 64 bit processor on it. Something like a Raspberry Pi 3, or a newer Pi 2. These things aren’t exactly the first to come to mind when anyone asks for “a fast computer”.

So what should we do if we want to run NixOS on one of these, which routinely uses a gigabyte of memory or more to do system updates? We could add a lot of swap space and wait a while, sure, but that gets annoying pretty quickly and doesn’t exactly speed things up either.

Now what could we do to make this whole process a little nicer?

We all know that science can go wrong, and that of all science that can go wrong rocket science has lots of potential to go the wrongest. Usually you would want to launch your rocket smoothly, on a trajectory pointing in the general direction of “up”, and then control it for a good long while after. But sometimes things do not turn out quite as planned, and you get an explosion instead.

Computer science is a lot like rocket science in that respect, except that our explosions tend to be somewhat less spectacular.

Recently we got access to a camera that records reasonable 4k video at 10bit and 12bit color depth. So naturally we now need a way to edit this 4k video. While proprietary software like DaVinci Resolve does have free variants that could be useful, those free variants often come with unfortunate restrictions like “no 4k exports” or “no commercial use” (sometimes with questionable definitions of “commercial”).

Warning: this post will not contain much information about editing at all, just a colorful recollection of all the problems had on the way to a 4k editing setup that works reasonably well. Software is a horrible mess most of the time. This will be quite a rambling. So sit comfortable, grab a soothing object and/or foodstuff of your choice, and prepare to be disappointed.

Why, pray tell?

The Pinebook Pro is a pretty nifty device. A 200$ laptop. With an RK3399 SoC in it, a hex-core AArch64 chip from Rockchip. That’s just amazing.

The default OS it ships with is a Debian with a vendor kernel and U-Boot provided by Rockchip. For the shipped Debian this bootloader works well, but other OSes may have some problems. In the case we’re adressing here it is the Manjaro kernel booting very slowly, caused by the Rockchip bootloader not bringing up all CPU cores of the chip properly. There are a few workarounds for this (booting with nr_cpus=4 for example), but all of them have their drawbacks. Also, booting with an (almost) fully upstream bootloader is just, you know, more satisfying.