In my previous post, I mentioned that I somehow ended up with a corrupted filesystem on the WireGuard server I had set up earlier this year. That iteration of my VPN server was built on Linux as I expected I would get better performance using the kernel-based WireGuard implementation. It had taken me a while to set it up right, and I didn’t get the impression that the performance was so much better anyway. Keep in mind that I mostly use my VPN server from hotel WiFi and we all know how “good” that tends to be performance wise.

While I’ve done a fair bit of Linux admin work, I didn’t fancy re-doing the whole setup again. I also hadn’t scripted it up using Ansible or similar. I tend to prefer BSD anyway, and most of my personal servers run some flavour of BSD Unix. As I didn’t want to spend too much time securing this server, I used OpenBSD as it is a little more secure out of the box compared to FreeBSD. I also hadn’t experimented with OpenBSD for a while so I was curious to see the more recent improvements.

I’ve blogged about setting up a WireGuard VPN server earlier this year. It’s been running well since, but I needed to take care of some overdue maintenance tasks. Trying to log into the server this morning and I am greeted with “no route to host”. Eh? A quick check on my Vultr UI showed that the VPS had trouble booting. The error suggests a corrupted boot drive. Oops.

Guess what the maintenance task I was looking at was? Creating an Ansible script so I’d be able to stand up the server from scratch in case something like this happened. And yes, the irony of being the guy who regularly preaches to his clients about the need for backups doesn’t quite escape me.

MongoDB has a handy command to rename a collection, db.collectionName.renameCollection(). There is currently no equivalent to rename a database. Now if we accept that from time to time, one positively, absolutely just has to rename a database in MongoDB, well, there are a couple of options. Unfortunately they aren’t quite as straight forward as single MongoDB command. All methods for renaming a database in MongoDB also take a fair amount of time and/or disk space to complete. Keep this in mind when you try to use any of them.

My previous instructions for installing a newer Emacs version on Ubuntu still work. Ubuntu (and in my case, XUbuntu) 19.04 ships with Emacs 26.1 out of the box. As usual I want to run the latest version - Emacs 26.3 - as I run that on my other Linux, FreeBSD and macOS machines.

I only had to make one small change compared to the older instructions. Instead of running the versioned sudo apt-get build-dep emacs25 I ran sudo apt-get build-dep emacs. Once the dependencies are installed, you’re a configure/make/make install away from having a working Emacs 26.3:

I like Lispy languages. One I’ve been playing with – and occasionally been using for smaller projects – is Clojure. Clojure projects usually use Leiningen for their build system. There are generally two ways to install leiningen – just download the script as per the Leiningen web site, or use the OS package manager. I usually prefer using the OS package manager, but Manjaro doesn’t include leiningen as a package in its repositories. Installing leiningen is pretty easy via the package manager and I’ll show you how.

macOS Time Machine is usually set up to work in the background and not overly affect anything that’s going on in the foreground while the user is working. Under normal circumstances, this is desirable behaviour. It is not desirable when you try to take one last backup of a failing SSD before it keels over completely. Which was the unfortunate situation I found myself in.

Turns out there is a sysctl that can be used to disable or enable this behaviour. If you turn it off, the backup in macOS Time Machine runs much faster, at the expense of additional network bandwidth and disk IOPS. The backup daemon will increase disk IOPS usage both for reading and writing.

In a previous post I mentioned that I upgraded my homebrew install of Emacs after Emacs 26.2 was released, and noticed that I had lost its GUI functionality. That’s a pretty serious restriction for me as I usually end up with multiple frames across my desktop. I did end up installing the homebrew Emacs for Mac tap which restored the GUI functionality. It had have one niggling problem for me, though. My muscle memory says that I use Shift-Meta-7 (aka Meta-/ ) for keyword expansion as I use a German keyboard layout most of the time. Unfortunately, with Meta mapped to the Apple Command key, Shift-Meta-7 is a menu shortcut. Instead of expanding keywords, I kept opening menus. That clearly wouldn’t do.

I’ve blogged about building Emacs 26 on WSL before. The text mode version of my WSL build always worked for me out of the box, but the last time I tried running an X-Windows version, I ran into rendering issues. Those rendering issues unfortunately made the GUI version of Emacs unusable on WSL. Nothing like missing the bottom third of your buffer to cramp your style. Or your editing.

Going all in with Emacs 26.2 with Cairo

I’ve just built the newly released Emacs 26.2 on my Ubuntu WSL with the options –with-cairo –with-x-toolkit=gtk and it looks like the rendering has improved massively. I’ve also recently upgraded VcXsrv to version 1.20.1.1, so it’s not quite clear to me if this is due to improved compatibility of WSL itself, changes between Emacs 26.1 and 26.2, or the fact that I turned on Cairo or VcXSrv upgrade.

I mentioned in my previous post that I somehow had ended up with a non-working org2blog installation. My suspicion is that this was triggered by my pinning of the htmlize package to the “wrong” repo. I had it pinned to marmalade rather than melpa-stable, and marmalade had an old version of htmlize (1.39, from memory). The fact that marmalade is erroring out with an expired certificate is most likely a sign that I need to stop using it. Anyway, re-pinning htmlize to melpa-stable unclogged that particular problem and the updated org2blog flowed onto my machine.

I finally got around to upgrading my OS X installation from Mojave to High Sierra - my OS update schedule is usually based on the old pilot wisdom of “don’t fly the A model of anything”. As part of the upgrade, I ended up reinstalling all homebrew packages including Emacs to make sure I was all up to date. That proved to be a big mistake as I suddenly had a GUI-less Emacs. Of course I found the post on Irreal about the Emacs homebrew package being broken on Mojave after, well, I noticed that my Emacs GUI wasn’t working. Oops.