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.
The sysctl to turn off the low priority backup in the background is:
sudo sysctl debug.lowpri_throttle_enabled=0
Obviously, set the value back to its default of 1 if you want to restore the original behaviour. Based on the atop stats on my home server, network bandwidth usage went up from 5-10% to about 20%, and disk IOPS usage from 7-8% to about 65-70%. The backup is not maxing out the server or client. On my old 6 core Mac Pro, I have no problem running the backup at the higher speed without a big impact to my main work. I suspect that it would be different if I were to run disk intensive applications, though.
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.
Malcolm Purvis had been kind enough to point out in a comment to my original homebrew Emacs post that Davide Restivo had created a brew tap that brings the necessary
–with-cocoa build option back. He just upgraded it to Emacs 26.2, so this morning I rebuild my Emacs on OSX again and ended up where I wanted to be, with the latest version of Emacs, keyword expansion as I expected it to work, and a working GUI. Thanks, Davide!
And yes, it might come across as silly to rebuilding the editor just to get my preferred key combination back. It probably is – after all, I could’ve just remapped the key combination in my .emacs. I tend to run Emacs across a myriad of platforms (Linux, OSX, Windows, FreeBSD to just list a few) and having a “stock” Emacs experience on all of these platforms means that my .emacs has only a minimal amount of OS-based conditionals in it. For example, it has the following OS X specific combo:
;; On OS X/Darwin, make sure we add the path to the homebrew installs (when (string-equal system-type "darwin") (setq exec-path (append exec-path '("/usr/local/bin"))) (global-set-key [home] 'move-beginning-of-line) (global-set-key [end] 'move-end-of-line))
In fact, the above block is the only OS-specific configuration in my whole .emacs file. I’d like to keep it that way.
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 184.108.40.206, 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’m still seeing a couple of odd rendering issues that I can’t fully reproduce. They’re mostly around the resizing and buffer splitting, which I can live with for now. The Cairo renderer is known to still have a few bugs, so that might be contributing to the problems I’m seeing. I’m just happy that I do have a 95% working Emacs on WSL.
One other oddity I noticed is that I have to specify -d to set the display if I want to enable the GUI. Setting DISPLAY in the environment doesn’t quite seem to do the trick for now. I will keep playing with this a little more to see if I’m overlooking the blindingly obvious.
There’s also a little issue with Emacs not being able to connect to VcXsrv if I just specify -d localhost:0.0. This should work but the only way I can get it to work is by using -d 127.0.0.1:0.0. I suspect that’s because I recently added IPV6 capabilities to my home network and for some reason, VcXsrv doesn’t listen on the IPV6 interface. And no, -d ::1:0.0 doesn’t work, either.
Anyway, here we have another self-referential screenshot of the Emacs UI showing me working on this blog post:
Here we go again, this time without Cairo
I ended up rebuilding the Emacs binary without Cairo support as the rendering issues got a little annoying. Disabling Cairo seems to have taken care of the rendering issues during buffer splits for now. I’ll still have to look into the IPV6 issue at some point, but for now I’m pretty happy with the final result. So for our final, final result for today, here’s a non-Cairo screenshot running the anti-zenburn theme with powerline with its default theme.
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.
As a bonus, I ended up following the instructions for installing org2blog v1.1.0. While that version is not yet available on melpa-stable, it exposed me to use-package, which is something I’ve been meaning to look at but haven’t got around to so far. A quick glance at the docs – which is all I’ve had time for so far – suggests that I really need to look at use-package in depth and possibly update my .emacs to make use of it rather than continuing to maintain the home grown package installation wrapper I’ve been using for the last few years.
Either way, I’m happy to be able to blog from Emacs again rather than having to suffer WordPress’s built-in editor.
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.
A bit more poking around the Internet brought me to the homebrew cask for the Emacs Mac Port. As the screenshot below shows, it works with a UI on Mojave, so if you’re looking for an alternative to the regular Emacs port, this one seems to be fine, at least based on a quick “test drive”.
Time to make sure that the installed packages are also working as it doesn’t seem to recognise org2blog and I ended up having to write this post in the WordPress editor. Can’t have that.
As I’ve mentioned before on this blog, I still have one of the “cheese grater” Mac Pros around. It’s a 2009 that I upgraded somewhat with SSD, 6 core Xeon and a few other small goodies. As I split my time between Linux, Windows and OS X, I like having it around but can’t really justify getting a newer machine.
Anyway, I’m upgrading my monitor to wide screen monitor and the old graphics card (Apple branded AMD Radeon 7970) was unlikely to be too happy about it. Plus, I had a spare AMD RX470 lying around from upgrading the graphics card in my PC. The Hackintosh community seems to generally recommend AMD cards for newer versions of OS X, so I figured I’d give it a try. The RX470 is listed as a supported card in newer versions of OS X after all.
The whole amount of drama to get the card to work in the Mac went – open case, pull old card, fit new card, close case, ignore the lack of boot progress screen, job done. That was certainly a lot less fuss than I had expected.
The card is an ASUS Strix RX470, but I don’t think the brands matter too much. Although the Hackintosh forums seem to have identified one or two brands that don’t work that well with OS X. And yes, I’m still running High Sierra. Works fine for what I need this box for.
As an IT consultant, I travel a lot. I mean, a lot. Part of the pleasure is having to deal with day-to-day online life on open, potentially free-for-all hotel and conference WiFi. In other words, the type of networks you really want to do your online banking, ecommerce and other potentially sensitive operations on. After seeing one too many ads for VPN services on bad late night TV I finally decided I needed to do something about it. Ideally I intended to this on the cheap and learn something in the process. I also didn’t want to spend the whole weekend trying to set it up, which is how WireGuard entered the picture. I only really needed to protect my most sensitive device – my personal travel laptop.
As I’m already a customer at Vultr (affiliate link) I decided to just spin up another of their tiny instances and set it up as my WireGuard VPN server. Note that I’m not setting up a VPN service for the whole family, all my friends and some additional people, all I’m trying to do is secure some of my online communications a little bit more.
I also decided to document this experiment, both for my own reference and in the hope that it will be useful for someone else. Readers will need to have some experience setting up and administering Linux server. Come on in and follow along!
Straight from the “make work for yourself because there aren’t enough hours in the day already” files.
I’ve mentioned before that I am self-hosting this blog rather than using a hosted instance. I hosted the WordPress instance on FreeBSD and it’s been running quite well for a while, but during a double FreeBSD port upgrade to WordPress 5.0.1 and PHP 7.2 – after the php 7.0 port had been discontinued – broke the blog. php-fpm failed regularly with a signal 10, but I wasn’t able to figure out why in a hurry, so I started looking at alternatives.
Ben Simon has a post up on his blog describing how he set up a scheme development environment on his Galaxy S9 Android phone. It was also an especially timely post as I had been eyeing a Mac Quadra with a Symbolics Lisp Machine extension card on eBay. As if we needed another reminder just how powerful current phones have become!