mac

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:

Note: There's a video version of this blog post available here: What does Apple Silicon mean for the Raspberry Pi and ARM64?

A couple weeks ago I tried using the latest Raspberry Pi 4 8 gig model as my main computer for a day, and I posted a video about my experience.

Besides many diehard Linux fans complaining in the comments about my apparent idiocy caused by being a Mac user, the experience taught me one thing: A lot of software still isn't built for 64-bit ARM processors, or even for Linux in general.

But there's one trend that I'm seeing: most of the open source software I use already works great on a Pi 4 running on its 64-bit ARM processor.

I've been doing a lot of video production work for the past few months, both for my YouTube channel, and in helping people with their live streams, and one thing that I miss by not having dedicated (and expensive!) video production system like a NewTek TriCaster is being able to record multiple camera angles at their full resolution simultaneously on my Mac.

.embed-container { position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden; max-width: 100%; } .embed-container iframe, .embed-container object, .embed-container embed { position: absolute; top: 0; left: 0; width: 100%; height: 100%; }

There are a lot of little conveniences you get used to if you do professional live video production with high-end equipment that you often can't replicate in a budget studio... like my desk here at my house.