This post isn't for the basic operations like installing stuff, because those are easy to remember or easy to figure out if you're missing them.
It recently occurred that I had the need to route all traffic by a certain application through a VPN. While premade solutions for this exist using Docker (especially in combination with BitTorrent clients), I preferred looking for something that really just isolates what is needed and leaves the rest alone.
This post contains Q&A-style notes on compiling software for OpenWrt or compiling OpenWrt itself.
With Raspbian (now named Raspberry Pi OS) having been released as 64-bit, I can finally write a proper sequel to the previous post that dealt with virtualizing ARM/Linux distributions headlessly using QEMU.
You can read the original article here: Virtualizing Raspbian (or any ARM/Linux distro) headless using QEMU. Since the process is the same I will skip detailed explanations here.
Installing an Unifi controller on a Raspberry Pi seems like a straightforward task until you notice the section with system requirements.
The software requires a MongoDB version before 4.0. The last version that satisfies this is 3.7.9 which is almost four years old at the time of writing. You may find old versions packaged on the MongoDB website or in other repositories but certainly not for ARM. The second problem is that MongoDB dropped 32-bit support in version 3.4 so the latest we can actually use is 3.2.22 (also 4 years old).
In the end I was unable to find a build of MongoDB 3.2 that could run on a Pi which leaves only the option of compiling from source. This is what I ended up doing, it required lots of trial and error  before it succeeded. To (hopefully) save someone else time I put up the final Debian package for download.
A few months ago I wanted to test something that involved OpenVPN on an old, small VPS I rented.
At this point it would've been easier to give up or temporarily rent another VPS, but I really wanted to run the test on this particular one.
The gist of it is that glibc began to make use of the new
which when running under older systemd-nspawn is filtered to return
This misdirects glibc into assuming a file or folder cannot be accessed,
when in reality nspawn just doesn't know the syscall.
A fix was submitted to systemd  but it turned out this didn't only affect nspawn, but also needed to be fixed in various container runtimes and related software    . Hacking around it in glibc  or the kernel  was proposed, with both (rightfully) rejected immediately.
I pondered what an awful bug that was and was glad I didn't have to deal with this mess.