How to speed up macOS Time Machine backups

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.

Wrapping up the Emacs on Mac OS X saga

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.

Unwelcome surprise – homebrew Emacs has no GUI after OS X Mojave update

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”.

Screenshot of a GUI Emacs 26.1.92 running on Mac OS X Mojave
Working Emacs For Mac on OS X Mojave

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.

2009 Mac Pro running an AMD RX470 graphics card

I thought this was going to be a long post about upgrading the graphics card in my Mac Pro

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.

2009 Mac Pro running an AMD RX470 graphics card
My Mac Pro showing off it’s shiny used RX470 graphics card

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.

Installing specific major Java JDK versions on macOS via Homebrew

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?

Read More

Installing a Java 8 JDK on OS X using Homebrew [Tutorial]

Update II – 2019-05-07: It looks like due to the recent licensing changes, the Java 8 JDK that brew used is not directly accessible anymore and likely behind some kind of paywall. The installation method described below will still work as it uses the non-versioned java cask, which installs the latest version of OpenJDK.

Update: The title of this post isn’t quite correct – using the homebrew cask mentioned in this blog post will install the current major version of the Oracle JDK. If you want to install a specific major version of the JDK (6 or 8 at the time of writing), I describe how to do that in this new blog post.

I’ve had a ‘manual’ install of JDK 8 on my Mac for quite a while, mainly to run Clojure. It was the typical “download from the Oracle website, then manually run the installer” deployment. As I move the management of more development tools from manual management over to homebrew, I decided to use homebrew to manage my Java installation also. It’s just so much easier to get updates and update information all in one place. Oh, and installs the same JDK anyway, just without all the additional pointy clicky work.

Removing the existing installation

Fortunately Oracle has uninstall operations on their website. It’s a rather manual approach but at least it is documented and the whole procedure consists of three commands. Unfortunately in my case this didn’t end up uninstalling an older version of the JDK. For some reason, I had ended up with both 1.8.0_60 and 1.8.0_131 installed on my machine, and Oracle’s uninstall instructions didn’t touch the 1.8.0_60 install in /System/Library/Frameworks/JavaVM.framework. I suspect this is an older JDK brought over from the Yosemite install and the consensus on the Internet I could find suggest to leave that alone as the system needs those.

Apparently in older versions of OS X is was possible to run /usr/libexec/java_home -uninstall to get rid of a Java install, but that option does not appear to work in OS X Sierra anymore

Installing Java using Homebrew

The installation via homebrew is about as simple as expected. I have cask installed already, so for me it’s a simple matter of running

brew cask install java

and it will install the latest Oracle JDK. You can use

brew cask info java

to verify which version it will install.

If you haven’t got homebrew installed, follow the installation instructions on docs.brew.sh and also make sure that you install cask:

brew tap caskroom/cask

After re-installing the JDK using homebrew, java_home also finally reports the correct version:

odie-pro:~ timo$ /usr/libexec/java_home
/Library/Java/JavaVirtualMachines/jdk1.8.0_131.jdk/Contents/Home
odie-pro:~ timo$