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.
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!
Update 2019-11-16: I updated the syntax for the homebrew cask search as “brew cask search” is deprecated. Also, while the post below still mentions the java8 cask, only the java6 and java 11 casks are currently available.
Update 2019-05-07: The java8 cask is affected by recent licensing changes by Oracle. There’s a discussion over on github about this. I’m leaving the post up partially for historic context. The java8 cask is no longer available, at least at the time of writing.
In an earlier post, I described how to install the latest version of the Oracle Java JDK using homebrew. What hadn’t been completely obvious to me when I wrote the original blog post is that the ‘java’ cask will install the latest major version of the JDK. As a result, when I upgraded my JDK install today, I ended up with an upgrade from Java 8 to Java 9. On my personal machine that’s not a problem, but what if I wanted to stick with a specific major version of Java?
We all love the odd debugging story, so I finally sat down and wrote up how I debugged a configuration issue that got in the way of the iOS mail app’s ability to retrieve email while I was on the go.
tl;dr – iOS Mail uses IPV6 to access you email server when the server supports IPV6 and doesn’t fall back to IPV4 if the IPV6 connection attempt fails. If if fails, you don’t get an error, but you don’t get any email either.
The long story of why I sporadically couldn’t access my email from the iOS 10 Mail app
Somewhere around the time of upgrading my iPhone 6 to iOS 10 or even iOS 10.2, I lost the ability to check my email using the built-in iOS Mail app over an LTE connection. I am not really able to nail down the exact point in time was because I used Spark for a little while on my phone. Spark is a very good email app and I like it a lot, but it turned out that I’m not that much of an email power user on the go. I didn’t really need Spark as Apple had added the main reason for my Spark usage to the built-in Mail app. In case you’re wondering, it’s the heuristics determining which folder you want to move an email to that allow both Spark and now Mail to suggest a usually correct destination folder when you want to move the message.
I’ve blogged about getting Manjaro Linux to work with my AMD RX 470 before. The method described in that post got my AMD RX 470 graphics card working with the default 4.4 kernel. This worked fine – with the usual caveats regarding VESA software rendering – until I tried to upgrade to newer versions of the kernel.
My understanding is that the 4.4 kernel series doesn’t include drivers for the relatively recent AMD RX 470 GPUs, whereas later kernel series (4.8 and 4.9 specifically) do. Unfortunately trying to boot into a 4.9 kernel resulted in the X server locking up so well that even the usual Alt-Fx didn’t get me to a console to fix the problem.
My adventures with Manjaro Linux continue and I’ve even moved my “craptop” – a somewhat ancient Lenovo X240 that I use as a semi-disposable travel laptop – from XUbuntu to Manjaro Linux. But that’s a subject for another blog post. Today, I wanted to write about package download performance issues I started encountering on my desktop recently and how I managed to fix them.
I was trying to install terminator this morning and kept getting errors from Pamac that the downloads timed out. Looking at the detailed output, I noticed it was trying to download the packages from a server in South Africa, which isn’t exactly in my neighbourhood. Pamac doesn’t appear to have an obvious way to update the mirror list like the Ubuntu flavours do, but a quick dive into the command line helped me fix the issue.
First, update and rank the mirror list:
sudo pacman-mirrors -g
Inspecting /etc/pacman.d/mirrorlist after running the above commands showed that the top ranked mirrors now are listed in the US with very short response times.
After updating the mirrors, it’s time to re-sync the package databases:
sudo pacman -Syy
Now with the new, faster mirrors ranked accordingly, I suddenly get my Manjaro packages and package updates at the full speed of my Internet connection rather than having hit and miss updates that take forever to install.
Turns out it’s not only Windows 8 that has its telnet client disabled, Windows 10 is in the same boat. I’ve been using Windows 10 for quite a while now and just discovered this issue. Anyway, the way to enable is as follows:
I’ve been a Xubuntu user for years after switching from OpenSuse. I liked its simplicity and the fact that it just worked out of the box, but I was getting more and more disappointed with Ubuntu packages being out of date, sorry, stable. Having to rebuild a bunch of packages on every install was getting a little old. Well, they did provide material for all those “build XXX on Ubuntu” posts. Recently I’ve been playing with Manjaro Linux in a VM as I had been looking for an Arch Linux based distribution that gave me the right balance between DIY and convenience. I ended up liking it so much that I did a proper bare metal install on my main desktop. The install was pretty smooth apart from a issue with getting my AMD RX 470 graphics card to work.
This blog is self-hosted, together with some other services on a FreeBSD virtual server over at RootBSD. Yes, I’m one of those weirdos who hosts their own servers – even if they’re virtual – instead of just using free or buying services.
I recently had to migrate from the old server instance I’ve been using since 2010 to a new, shiny FreeBSD 10 server. That prompted a review of various packages I use via the FreeBSD ports collection and most importantly, resulted in a decision to upgrade from PHP 5.6 to PHP 7.0 “while we’re in there”.