mac

For years, Mac users have dealt with slow filesystem performance for Docker volumes when using Docker for Mac. This is because the virtualized filesystem, which used osxfs for a while and will soon be upgraded to use VirtioFS.

But if you need to do large operations on huge codebases inside a shared directory, even using NFS to share from the Mac into Docker is a lot slower than running a native Docker volume or just using files inside the container's own filesystem.

After upgrading my main workstation to a Mac Studio, I decided to break tradition.

Usually, I sell off my old workstation to offset the cost of the new one. But just last week, Asahi Linux announced their first alpha release.

If you haven't heard of Asahi, it's a Linux distribution based on Arch Linux that aims to bring a polished Linux experience on Apple Silicon Macs (all the current M1 Macs, and any new Apple Silicon Macs that come in the future).

Last month, I built an all-AMD PC to try out Linux Gaming with Steam and Proton, and so I'd have a faster native Linux build machine for my various compilation tasks.

This month, Apple introduced the Mac Studio, and as a now full-time video producer, it was a no-brainer for me to upgrade from an M1 Mac mini.

My Mac Studio arrived Friday, and over the weekend, I spent some time benchmarking it against not only my M1 mini, but also my new AMD Ryzen 5 5600x PC build.

My Mac Studio's specs:

Docker for Mac's shared volume performance saga continues!

After monitoring the issue File system performance improvements for years (discussion has moved to this issue now), it seems like the team behind Docker Desktop for Mac has finally settled on the next generation of filesystem sync.

For years, the built-in osxfs sync performance has been abysmal. For a Drupal developer like me, running a default shared volume could lead to excruciating slowdowns as PHP applications like Symfony and Drupal scan thousands of files when building app caches.

Or God forbid you ever have to install dependencies using Composer or NPM over a shared volume!

It got to the point where I started using NFS to speed up volume performance. Heck, the Docker team almost added Mutagen sync, which I tested successfully, but it caused problems for too many projects.

At AnsibleFest 2021, I presented a session titled Automating the Uncommon - Ansible automates everything!.

Since watching on-demand versions of the AnsibleFest sessions requires a signup, I thought I'd also post the session to my YouTube channel, so everyone can learn from it without registering. The session seemed well-received, and I hope it shows that, as I state in my 'Rule of Golden Hammers':

I demonstrate how I use Ansible to:

Recently I upgraded from an Intel-based MacBook Pro to two M1 Macs. As part of the upgrade, I also made sure to refine my Mac setup automation with Ansible and my Mac Development Ansible Playbook.

But one weird thing I noticed was no matter how I installed Ansible on my new Macs, I couldn't get libyaml support to work:

Ah, the feeling of unpacking a brand new computer:

In my case, I'm actually selling the 16" MacBook Pro pictured above and replacing it with a 13" MacBook Air and 10 Gigabit Mac mini.

Once you turn on the new Mac, what's next? Do you:

(With a caveat: I'm compiling the ARMv8 64-bit Pi OS kernel.)

It seems every week or so on Hacker News, a story hits the front page showing some new benchmark and how one of the new M1-based Macs matches or beats the higher-priced competition in some specific benchmark—be it GeekBench, X86-specific code, or building Emacs.

Well, here's my quick story.

I've been doing a lot of work with Raspberry Pis lately—more specifically, work which often requires recompiling the Pi OS Linux kernel for the aarch64 architecture. I recompile the kernel enough I made my own shirt for it!

After doing a video testing different external GPUs on a Raspberry Pi last week, I realized two things:

1. Compiling the Linux kernel on a Raspberry Pi is slow. It took 54 minutes, and I ended up doing it 7 times during the course of testing for that video.
2. If you ever want to figure out a better way to do something, write a blog post or create a video showing the less optimal way of doing it.

To the second point, about every fifth comment was telling me to cross-compile Linux on a faster machine instead of doing it on the Pi itself. For example:

And on the Pi Forums, it seems like nobody worth their salt compiles the kernel on the Pi either, so I figured—since I'm probably going to have to do it again another thousand times in my life—I might as well put together a guide for how to do it on a Mac.

I recently got an offer from MacStadium to use one of their dedicated Mac minis to perform CI and testing tasks for my Mac-based open source projects (for example, my Mac Dev Ansible Playbook, which I use to configure my own Macs).

So I thought I'd document a little bit in this blog post about how I configured the Mac mini for more secure remote administration, since Macs tend to be a little more 'open' out of the box than comparable Linux machines that I'm used to working with.

Securing SSH

First of all, I used ssh-copy-id to add my SSH key to the default administrator account on the Mac mini that was created for me: