Golem VI
Hopefully, you didn’t notice, but Golem V has been replaced. Superficially, the new machine looks pretty much like the old.
It’s another Mac Mini, with an (8-core) Apple Silicon M2 chip (instead of a quad-core Intel Core i7), 24 GB of RAM (instead of 16), dual 10Gbase-T NICs (instead of 1Gbase-T), a 1TB internal SSD and a 2TB external SSD (TimeMachine backup).
The transition was anything but smooth.
The first step involved retrieving the external HD, which contained a clone of the internal System drive, from UDC and running Migration Assistant to transfer the data to the new machine.
Except … Migration Assistant refused to touch the external HD. It (like the System drive of Golem V) was formatted with a case-sensitive filesystem. Ten years ago, that was perfectly OK, and seemed like the wave of the future. But the filesystem (specifically, the Data Volume) for current versions of Macos is case-insensitive and there is no way to format it as case-sensitive. Since transferring data from a case-sensitive to a case-insensitive filesystem is potentially lossy, Migration Assistant refused to even try.
The solution turned out to be:
- Format a new drive as case-insensitive.
- Use
rsync
to copy the old (case-sensitive) drive onto the new one. rsync
complained about a handful of files, but none were of any consequence.- Run Migration Assistant on the new case-insensitive drive.
And that was just Day 1. Recompiling/reinstalling a whole mess ‘o software occupied the next several weeks, with similar hurdles to overcome.
For instance, installing Perl XS modules, using cpan
consistently failed with a
fatal error: 'EXTERN.h' file not found
error. Googling the failures led me to perlmonks.org, where a post sagely opined
First, do not use the system Perl on MacOS. As Corion says, that is for Apple, not for you.
This is nonsense. The system Perl is the one Apple intends you to use. But … if you’re gonna do development on Macos (and installing Perl XS modules apparently constitutes development), you need to use the Macos SDK. And cpan
doesn’t seem to be smart enough to do that. The Makefile it generates says
PERL_INC = /System/Library/Perl/5.34/darwin-thread-multi-2level/CORE
Edit that by hand to read
PERL_INC = /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/System/Library/Perl/5.34/darwin-thread-multi-2level/CORE
and everything compiles and installs just fine.
And don’t even get me started on the woeful state of the once-marvelous Fink Package Manager.
One odder bit of breakage does deserve a mention. sysctl
is used to set (or read) various Kernel parameters (including one that I very much need for my setup: net.inet.ip.forwarding=1
). And there’s a file /etc/sysctl.conf
where you can store these settings, so that they persist across reboots. Unnoticed by me, Migration Assistant didn’t copy that file to the new Golem, which was the source of much puzzlement and consternation when the new Golem booted up for the first time at UDC, and the networking wasn’t working right.
When I realized what was going on, I just thought, “Aha! I’ll recreate that file and all will be good.” Imagine my surprise when I rebooted the machine a couple of days later and, again, the networking wasn’t working right. Turns out that, unlike every other Unix system I have seen (and unlike the previous Golem), the current version(s) of Macos completely ignore /etc/sysctl.conf
. If you want to persist those settings between reboots, you have to do that in a cron-job (or launchd script or whatever.)
Anyway, enough complaining. The new Golem seems to be working now, in no small part thanks to the amazing support (and boundless patience) of Chris Murphy, Andrew Manhein and the rest of the crew at UDC. Thanks guys!
Re: Golem VI
Welcome to Golem VI!
I wonder to what extent AI will become part of the OS, in this or the next machine…