Author: Dave

More of a best-practices post than a concrete article, but nonetheless there might be some value here.

Time Machine has worked in pretty much the same way since its incarnation on the grounds that macOS has also pretty much run the same way since its incarnation: as a monolithic OS that sits on a big volume with lots of bits of data sloshing around on said volume. Time Machine would obligingly go and grab all those bits of data, compare them against a destination, then bring over all the bits of data that it deemed had changed so that you had a snapshot of whatever was on there at the moment you did the backup.

This was all very sensible and worked just fine – right up to the point where the basic underlying mechanic of the way that macOS handled files (all sloshing around on a big volume) – irrevocably changed into more intelligently having all your files sloshing around on two entirely separate APFS volumes. And when I say “irrevocably” I mean it in the tangible, literal sense of “you can’t go back to the old way.” Apple makes this moderately clear in this document, right down there at the bottom:

“If you upgraded to macOS Catalina on a Mac that uses a Time Capsule or other network storage device as the backup destination, your existing backups are also upgraded and can be used only on macOS Catalina. New backups that are created can be used only on macOS Catalina.”

Well. Good to know. In case there was any doubt about this, Catalina changes out the tried and trusted .sparsebundle suffix for the new and improved .backupbundle, the latter of which cannot be opened on anything earlier than Catalina.

There’s further good news and bad news. The good news is that (at least in most typical cases) Time Machine seems to update your existing backups as part of setup once you’ve upgraded to Catalina. The bad news is that this takes a long time and uses a lot of space, as putting everything you use onto two APFS volumes with a drastically different file structure requires significant rewriting of your backup file. In fact, it’s pragmatically a toss-up about whether to let Catalina update your existing fresh ones or just start a new one.

I’ve found that if you have the time (and additional drives) then the best practice seems to be to try and get the best of both worlds. Back up everything under Mojave to two backup sets, detach one of them and stash it in a safe place so you’ll have a backup of your backup, then run the update to Catalina and let it go hog crazy on your remaining backup set. That way if things go awry then you have another clean copy of your old backups to pull data from (and, if it becomes apparent in short order that Catalina isn’t going to work for you, enough data that you can wipe the computer and roll back to Mojave with relative ease.)

New technologies always require transitions, and those transitions are inevitably messy – no matter how well-conceived and well-implemented. Time Machine is practically a venerable institution at this point, and while some parts of this new incarnation have been extant prior to now – local snapshots, I’m looking at you – making substantive changes in the way things work is always going to have rough edges.

And – although this is a good thing – I’ve yet to hit a point where it’s really been put to the test due to hardware or software failure (although I’ve done some full restores on new machines without incident.) Still, time will tell…

“If Mac Pro is in firmware recovery mode, the status indicator light rapidly flashes amber three times, briefly flashes amber three times, then rapidly flashes amber three times. This repeats until the computer is turned off. You might need to revive the firmware on your Mac Pro. If you still need help, contact an Apple Authorized Service Provider“

So, to be perfectly clear about this, they’re saying that if your Mac Pro, say, suffers a power failure during a firmware update and requires repair then it lets you know this by flashing the standard International Morse Code signal for S.O.S?

That’s outstanding.

Back in the day when Apple was telling ACNs that Xsan was the new thing that we all had to know everything about I went out and bought an Xserve.

Okay, it wasn’t just me: it was my fellow ACN and business partner Seth and I . And it was three Xserves. And an Xserve RAID. And a giant box to put them all in. And a fiber channel switch, a ton of cards and cables and adaptors and assorted doo-dads. And it was glorious. And cost as much as a reasonable used Toyota. And it was loud.

Really loud. Really, really loud. To the point where Seth and I would eventually pad the mobile rack with a foam kit, and then wheel it into the back corner of our office in Carpinteria, and then finally wheel it into another room, and then close the door. Don’t get me wrong; Xsan was incredible once you got it set up, and it was equally incredibly advantageous to have a test platform in place that you could throw enormous amounts of data at and have it not even blink. But when we finally pulled the plug on the Xserve/Xsan/RAID experiment after one Xserve blew a processor and another developed some kind of remarkable fault with a backplane we saw the writing on the wall, migrated everything to a couple of nice Promise RAIDs, and ended up giving away, parting out, and eventually recycling the whole lot.

And then Apple stopped making anything that would fit in a rack mount (I’m not talking about you, Mac mini/Mac Pro 2013 rack conversion kits. Sit down at the back, there). Until they came out with this:

I find myself more curious about this than I am about the stock Mac Pro – and not just because it’s a fabulous-looking piece of industrial design (and for my money much better looking than the standard Mac Pro), but because for a platform that’s been carefully engineered for cooling and silence a rack-mountable version is a slam dunk.

The thing is that it’s not simply like they slapped a couple of 19″ rails on the side of the existing box so you could stick it into a rack; it’s an entirely different machine. Sure, there are a lot of similarities with the regular Mac Pro. The base models are identical on specs, but the rackmount version is $500 more, and that $500 gets you a different chassis with migrated ports from the top of the case to the front, built-in spots to attach the included rail kit and a slightly altered rear plane that looks like it’ll accommodate increased airflow. There are those who’ll look at the $500 increase and chalk it up to Apple padding their profits unnecessarily (cough cough Pro display stand cough), but I’d ask those people to go out and look for good rail kits for rack mount servers. Not the cheap, nasty powder coated jobs that eventually buckle and refuse to extend; a really good rack kit. Go on. I’ll wait.

You’re back? And you clocked that a 4U, four-post rack kit can handily set you back about $700? Yeah. I hear you.

It kind of makes sense, though. Four-post rack kits are pricey, and with good reason. If you’re putting your 40lb, $20,000 server six feet up in the air then you want to be very, very sure indeed that it’s not being held in place by something that’s going to snap or warp or wear out, and thus risk turning your extremely pricey (and probably business-critical) asset into a large aluminum box full of broken bits.

This a machine that exists in a world of very limited uses. For every hundred Mac Pros Apple sells they’ll be lucky if they sell one or two of these. This product is an anachronism. A delightful, absurdly clever and well-designed anachronism, but an anachronism just the same; a call-back to a product that existed for a few scant years, failed to thrive, and although it was brilliant never found sufficient traction to compete or persevere.

Which is a shame, because this is exactly the machine that the Xserve should have been; powerful, price and feature comparable with the Pro desktop du jour, and (once you get over the fact that a good rack kit is a non-trivial expense) cost-effective.

And quiet. So, so very quiet.

I toyed with including this last time, but in the end opted to go a different way as macOS Catalina seems to (as of writing this) refuse to work very well with the latest version of John The Ripper. Worse still, the homebrew version seems to either not work at all or throw out very peculiar permissions-based errors no matter what machine I try and run it on. Still, undeterred, here’s how to use the “Pro” version of John The Ripper to crack macOS passwords.

Obligatory note: This is not in anyway an invitation to anyone to try and break into anyone else’s Mac. As mentioned last week, Apple includes very good security options right out of the box on their computers, and those are absolutely things that everyone should be employing. At the very least I implore you to turn on Filevault. Come on, folks.

Additional Obligatory note: Everything in this article would only be possible if you were able to follow the instructions I put in the last article about this sort of thing and thus had full, unfettered, unobstructed access to the OS.

A word about that “Pro” thing. Openwall – who host and distribute JtR – offer it for download to the world for free but will also sell you a copy for about $40 that gives you the kinds of boring things that you like to have when you’re a legitimate IT outfit and that are worth the money; i.e., something you can deduct from your taxes as a business expense and something to put in your asset file that helps you keep tabs on your tools and equipment. Openwall also offer tiered options and licenses that include assorted types of support, but I opted for the simple download sans support because I like figuring this stuff out for myself.

Which, it turns out, is shockingly straightforward. Just like last time, we’ll use the following command to go grab a copy of the target’s hashed password:

sudo cp /var/db/dslocal/nodes/Default/users/test.plist ~/Desktop

…and then use plist2hashcat.py to pull the hash out and put it into a file that we can use:

sudo python plist2hashcat.py ~/Desktop/test.plist

Next, download and build/use Homebrew to install/buy the pre-assembled binary of John The Ripper from Openwall, then download and unzip it into a directory of your choosing. I threw it in my $PATH, but your mileage may vary and I can think of a few good reasons that you might want to just tuck something like this away in a safe place and only pull it out when needed.

Fire up the Terminal, then cd to the run directory in the unzipped John folder. Once there, the syntax to run the thing is about as straightforward as it gets. I’m using the same hashed file as last time, thus:

./John ~/Desktop/test_hash.txt

Now, hashcat is great and it’s well-supported and super-flexible, but compared to John The Ripper it’s like swimming through a sea of molasses with concrete flippers. John The Ripper is fast. Like, seriously fast. From hitting return on that last command I counted twenty-two seconds before it spat out the following:

Twenty-two seconds to digest that hashed password and spit out “test1” which, drumroll, is the correct answer.

Again, as I pointed out last week this kind of thing is only useful on machines that aren’t using encryption like Filevault, and this only makes it clearer than ever that those kinds of protections are no longer optional in a day and age where someone with $40 and a little free time can break into your Mac seemingly at will…

Today – January 5th, 2020 – is a banner day for Apple and anyone who uses Apple products and services. It’s the twentieth anniversary of a product/service that has become integral to the company’s entire internet strategy, app and media distribution efforts, and is the foundation block that every vital service – particularly development and device management – rest on. It is, in point of fact, the thing that turned Apple from a company clawing its way out of financial ruin and irrelevance into the behemoth it is today.

You might think – and I say this not in a subjective sense but in the sense of a person who asked his friends about this – that I’d be talking about something revelatory like the iPod (although you’d be a year or so early) or possibly the iMac (although you’d be a couple of years too late). Those are solid answers, but the real hero of the piece is our old friend, .Mac.

Okay, to be fair, it was originally called iTools because Apple was squarely fixated on their internet strategy and had made the reasonable decision to prefix everything with an “I”, but when you signed up for it (and I did on January 5th, 2000 from the cramped confines of our tiny apartment on Capitol Hill over a 28.8k modem) you got an actual email address @Mac.com and so much more.

Almost everything that came with iTools was weird, and is now gone. The two goofiest ones are easy picks: iReview and iCards. iReview was a sort of peculiar review site for web pages (a noble goal, but ultimately unworkable considering the exploding rate of web adoption amongst the world at large), iCards was a sort of Blue Mountain-esque web greeting card outlet.

Homepage wasn’t awful, and in fact was a fairly serviceable web-page tool that allowed you to host your own site on your iDisk, which could handle up to a whopping 15mb of content. iDisk itself enjoyed direct support in the OS, too; you had the ability to mount the thing on your desktop as if it were just another drive that made copying data to and from the thing laughably simple and intuitive in a way that probably makes iCloud Drive wake up in a cold sweat every night.

A couple of years later iTools became .Mac, and then .Mac became iCloud, and now I have an email address that works with all of those suffixes and has done so – reliably – for twenty years. And because I’m a digital packrat, I can look at those early mails like some sort of data archaeologist and capture little glimpses of the places we all lived and the things we all did back then. There are pictures of my first new car in there, and long email chains between my wife and I that are weird echoes of who we were before we had kids and mortgages. Updates from friends whose names I’ve long-since forgotten, and notes to and from my Dad who passed away almost eighteen years ago.

My private fear is that someday some bean-counter at Apple will look at iCloud and decide that enough is enough and that .Mac addresses will no longer Be A Thing and that we’ll be left with .me.com and iCloud.com, and while that may cause some headaches about AppleIDs and address books I don’t think it’ll be the end of the world. Still, it would be a shame. Twenty years is an eternity in the internet age.

So, Happy Birthday iTools. If I have one wish it’s that you’ll be here in another twenty years time, and that I’ll be around to check back in with you then.

(Note: Everything below is evil and should only be used to access data you are legitimately allowed to access. Also, while TV makes things look cool and easy, hacking someone’s macOS password is likely to take a very long time and should only be attempted if you’re comfortable with breaking your computer quite badly. Your Mileage May Vary. Do Not Feed The Dog. You get the idea…)

(Additional note: I’ve had some feedback from some nice people at Apple that the original version of this article was more of a hacking how-to than they were strictly comfortable with, so this has been edited to make it clear that the mechanics of trying to hack a macOS login password are messy, haphazard and extremely time and effort-intensive. And very easily defeated if you employ some of the built-in tools.)

I love watching “Mr Robot”. Not just because of Rami Malek’s extraordinary acting and weirdly hypnotic bug eyed monologuing (although that never gets old) – no, I love it for the same reason that a lot of people in my trade love it; because it tries very hard to stick to the actualities of computer and network securities and most of the time it does an excellent job. Sure, they fudge it a little here and there for the sake of the plot, but in general if our protagonist is going to do some particularly clever piece of hacking then what they show you on the screen will be at least broadly accurate.

My wife and I were watching a recent episode in which our Kali Linux-loving hoody-wearing pal was trying to hack into a Mac, and I spent the whole sequence grinning like an idiot. “Wait, is that possible?” my wife asked. “He just hacked into that Mac. I thought Macs were unhackable?”

And therein lies the rub. The old adage was that the only real security is physical security, and as long as your device is accessible there’s always a way in. These days – with modern advances like the T2 chip and Secure Enclave – that’s starting to look less like an absolute and more like a general rule that has the occasional exception.

If you’ve done any of the elementary things you can do to secure your Mac (Filevault, used the Startup Security Utility to limit external boot, put a firmware password in place) then you’re in good shape and your Mac is (at least as things stand right now) safe from miscreants and TV hackers.

Still, for fun, I thought I’d replicate the broad strokes of what our hero did to hack a macOS login password and gain access to an account on that Mac. Oddly enough, life mirrored art in that a week after figuring this all out I was contacted by a client who had an employee leave under strained circumstances and who had changed the login password on an important computer and then “forgotten” what they’d changed it to.

First we’re going to take it that you’re sat at a Mac that nobody has made any attempt to protect. No biometric precautions, no firmware password, not even Filevault. If you’re sat at the Mac login screen then you are – by default – presented with a list of users and a field for the password for that user. If you don’t know the password then you can get a hint, but let’s assume that when the target set up their Mac they made that hint either wildly inaccessible or just left the field blank. Without that password it’s impossible to get into the account in any meaningful way; sure, if you have an external bootable drive and you’re not dealing with a Mac that’s been set up to disallow external booting (and you know what you’re doing) then you can get some access to files, but passwords and protected data is off the table.

So, what do you do? Well, first things first; you make yourself an account on the machine with full admin privileges to do so:

• Boot into recovery by holding down Command-R

• In the Terminal, turn off SIP by typing in csrutil disable

• Reboot into Single-User mode by holding down the s key

• delete /var/db/.AppleSetupDone, then reboot.

The computer now thinks that it’s a brand new device and prompts you to create an account which will be – because it thinks its a new device – an account with full administrator privileges.

Congratulations! Now you have an account on the computer and can perform further mischief. At this point you could change the password on the account you want to access and be able to log in, but that would blow out the keychain password and you wouldn’t be able to get any other credentials or passwords off the thing – and you certainly wouldn’t be able to cover your tracks so that the legitimate owner of the machine wouldn’t know you’d been tinkering around.

No, to really give them a bad day you’ll need to find where the OS keeps the encrypted hash of their password and then throw that into something that’ll brute force it into submission.

As of macOS Catalina, password hashes for local accounts are kept in /var/db/dslocal/nodes, so once you know the name of the account you’re trying to access (for the sake of argument we’ll call it “test”) you’ll need to copy that users’ plist to some place where you can get at it, thus:

sudo cp /var/db/dslocal/nodes/Default/users/test.plist ~/Desktop

That gives you a file called test.plist, which contains all sorts of data that the OS stores relating to that user’s authentication on the computer. That file will still have the default permissions on it, so you’ll need to Get Info on it and add yourself as a user with read/write permissions to go further with it. The password for the account is stored in a hash that you can get out with an assortment of tools, but I like to use plist2hashcat, so download it and use the terminal to change to its directory to run the command thus:

sudo python plist2hashcat.py ~/Desktop/test.plist

It’ll spit out the hash it pulls from that file, which will look something like this (note – example hash, not a real one):

$ml$34602$964ef09ca051dcfca85bc4b733ef70aef3cbe294db43cb0f2efcfdfc8f140f8d$acf35221b0e1bc4097db1d919c13839bbe2c4712044ecd4daa2c3803798a57179269e99ee745ad592614426e3a955695198f3581f8cd467d29ef073325ae408a

Copy that to a file called, I don’t know, say, test_hash.txt on your Desktop.

Finally, you’ll need some way to brute force that hash against a list of passwords (and a list of passwords to use). There are many, many sources for passwords out there and I’m not going to link to them because a lot of them are taken from actual data breaches and there’s a fine line between an academic discussion of how a thing can be done and pointing people at resources to engage in criminal conspiracy. Suffice to say that there are sources out there, and that I have a passwords file that I’m going to call passwords.txt and put it on my Desktop along with test_hash.txt. We’re also going to need a place to dump the finished file, so let’s create a directory at the root level of user folder called pots, thus:

mkdir ~/pots/

Next, we’ll install hashcat. I like John The Ripper too, but hashcat is light and easy and relatively flexible, and besides, I think that’s what Eliot used. Download it, install it, then cd into its directory and type the following to tell it to select the test_hash file, pull from that dictionary file and dump the results into the pots directory:

sudo ./hashcat -a 0 -m 7100 ~/Desktop/test_hash.txt ~/Desktop/passwords.txt -w 4 --potfile-path ~/pots/result.pot

This will take – depending on the complexity of the password and the size/scope of the dictionary file – a while. And by “a while” I mean somewhere from light lunch to come-back-tomorrow-morning. Further, it’s in no way a slam-dunk certainty that you’ll get anything useful out of it, and while it looks cool on TV it is a moderately miserable experience in real life. It will, however, eventually spit out a password if you’re lucky (note: the password it found for Mr Test was test1, because I guess he/I wasn’t feeling that creative).

And really, what does it get you anyway? Access to the user’s keychain is handy, sure, but if you’re after files locked away in a user account there are far simpler and faster ways of getting access to those files that don’t require downloading and compiling a bunch of python scripts and trawling around some of the sketchier bits of the web for lists of hacked passwords.

And it’s readily defeated, too. When you set up a new machine you get the option to turn on Filevault – and you should absolutely do that (and you can do it afterwards at any point from the Security & Privacy Preference). Further, with T2 protected machines there are protections in place to prevent booting from external drives, which makes attempting to use another drive to boot into the machine pretty much impossible.

This is one that – except in very fringe cases – is either extraordinarily time consuming or woefully impractical. Looks good on TV, though…

This is almost by way of a followup on last week’s update.

If you’re like me (and I’m assuming for the sake of argument that you and I are functionally identical in our interests and peccadilloes), you have a share on your work server that you use exclusively for old OS installer media. Partly out of some sort of sense that one day it might be useful to have a copy of Mac OS X v.10.1, but mostly out of a sort of obsessive compulsive need to have the full set.

Yeah, it’s probably not a healthy impulse, but storage space is comparatively cheap and it’s not an impulse that’s actively harming anyone. I can feel the condemnation through the magic of the internet, and I spurn it with my foot. Digital hoarding is pretty low-footprint, anyway.

So, whole bunch of macOS installers, dating all the way back to the Public Beta. The only problem is that nowadays most of them are uninstallable. When you try anything back past the last couple of releases you run into a nasty bug whereby the installer looks at the date on your machine, realizes that it’s installer certificate has expired, and calmly tells you that the installer is corrupt or damaged and that instead of installing Mac OS X Lion you’re more than welcome to hang your head in shame and weep the bitter, bitter tears of defeat.

If only there were some way to trick the installer? Okay, you can probably see where this is going. Enter the date command.

date allows you to either read or set the system date and time down to the minute, following a [mm][dd][HH][MM][yy] format. In human readable terms, that’s month-day-hour-minute-year in double digit form, so that, say, September 27th 2017 at 4:27pm would read 0927162717

So, neat. Right? Right. What do you do with this nugget of information? Simple enough; fool the installer into thinking it’s actually the past (a time when it was perfectly acceptable to install oldie timer operating systems while waxing your lustrous mustache whiskers and riding your penny farthing) and not the present, when we’re all wearing disposable paper clothes in our flying cars and living on the moon. We’re going to lie to the computer, in essence. We’re bad people. And this is how we do it.

First, you’ll need to know when in the past you’re going to tell the computer to imagine that it is. To do that, I utilize the magical powers of the internet to find the release date of the operating system I’m after, and then I add a few days and convert that date into the appropriate string. The example earlier isn’t random – it’s a couple of days after High Sierra/macOS 10.13 hove into view, and thus a good date to use for an install of that OS.

Next, create installer media for the appropriate macOS version (using the well-documented createinstallermedia method seen here), plug that installer media into the computer you’re installing onto, then hold down the option key while rebooting to choose the installer media as a startup disk.

Once you’re booted into the installer, disconnect from the internet/turn off wifi and open the Terminal from the Tools menu. Type in the command date followed by the string you worked out earlier, e.g., date 0927162417, then hit return.

Quit out of the terminal, jump back into the install, and proceed as normal expectations dictate. One thing to remember is that once you’ve finished the install and booted back into the OS that date flag remains set – in other words, if you tell your computer that it’s 2017 then it’ll keep thinking it’s 2017 until notified otherwise, which can play all kinds of havoc with software updates/the Mac App Store. Fire up System Preference, hit the Date & Time pane, uncheck the “Set date and time automatically” checkbox, then check it again to force the OS to go out and get the right time.

Et, as they say, voila!

Actually, the title is a bit misleading; mas allows you to download anything from the Mac App Store that you’ve purchased or previously downloaded for free – so if you’ve legitimately acquired every macOS release since the beginning of recorded time (like I have) then it’s a simple matter to go and grab those installers and download them to your Mac for your archiving/amusement/future use needs.

So, how to do it. First, you’ll need to go and download and install a package manager like homebrew. You can get the latest version by copying and pasting this into your browser of choice:

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

You’ll also need the current version of the Xcode command-line tools (if you don’t already have the current version of Xcode downloaded and installed). There are pre-built packages kicking around Apple’s site, but the easiest way to get the current version is to put this into the Terminal:

xcode-select --install

…and then sitting back and clicking the appropriate buttons to say that yes, you want to install this and you haven’t just decided to start slapping a bunch of additional tools into place on your system just for the hell of it.

Once both homebrew and the Xcode tools are in place, you can start downloading mas by typing the following:

brew install mas

Simple enough, right? The next part is a tiny bit trickier.

Typing mas into a new Terminal window will helpfully default to giving you the options that you have to play with, thus:

Now, provided you’re already signed into the App Store on your Mac you shouldn’t have to tinker around with the account option, but blindly typing in mas install isn’t going to do you any good unless you know what ID the App Store has assigned to the package that you’re looking for. The easiest, simplest way of locating the information you need is to go to the App Store via the built-in app and search from there. Let’s use macOS Catalina as an example, thus:

Click on the share icon and choose “Copy Link”:

…and then paste that into the text editor of your choice to get the full URL of the application you’re targeting:

The ID that we’re looking for is the number to the right of the “id” – in this case 1466841314.

Finally, feed that number to mas like so:

mas install 1466841314

Your application should start downloading once you hit return.

There are some gotchas with this, and it’s not universally reliable. If you share purchases with someone via Family Sharing then the App Store will occasionally decide that irrespective of whether you’re the person who purchased the app or not the app belongs to the other person, and that you’re not allowed to download it. Additionally, you might also run into the odd “HTTP 500 Internal Server” error, although I’ve found that waiting a few minutes and trying again seems effective.

Still, the good thing about using mas to download packages is that it can be an enormous time-saver if your company has a standard suite of applications that it owns through the App Store and wants to deploy to new machines that don’t use/aren’t enrolled in some kind of Mobile Management or Deployment scheme. After all, if you can get homebrew onto a machine then it’s possible to script mas to download specific items to specific machines.

As someone who primarily makes their living supporting businesses that use the Mac platform, I’ve been watching the tea leaves as close as most of my peers re: when this thing is going to actually hit the proverbial streets.

After all, the Mac Pro is a staple of the platform – or at least it’s historically filled that role. The new Mac Pro has been referred to as akin to a halo car by better writers who are in greater possession of greater creative gifts than those sandwiched between my ungainly ears, and they’re right; it’s the biggest, baddest, fastest consumer computer that you can buy and has a price tag to match. It’ll be amazing and lionized – but it won’t be ubiquitous.

Now, I may be biased because I’m typing this on an early 2009 Mac Pro that I assembled from a box of scraps in a cave a la Tony Stark, but this isn’t the first Mac Pro I’ve owned. Back in the late 00’s I had a couple of early cheesegrater/classic Mac Pros because they were relatively affordable and phenomenally expandable, and then later on I bought a 2013 trashcan Mac Pro because I needed a desktop that wasn’t an iMac and Apple had decided to let the Mac mini languish to the point of irrelevance. If you put together everything that I spent on those three computers you’d have a sum sufficient for me to roll around at the lower entry point of the new machine.

And really, that’s okay. Would I like Apple to offer a lower-spec, expandable entry-level Mac Pro? Yes. Yes I would. There’s a healthy market of folks who do professional work who need something with expandability and a decent amount of grunt to do heavy lifting, and that’s why prior to 2013 you’d find a Mac Pro under every desk at every design firm or architect office. But the use-case scenario has shifted – mostly, I suspect, as a matter of circumstance. Apple whiffed on the 2013 Mac Pro, let it languish, and the audience for that product hung onto their old gear until it became untenable to support it any more and then winced, shut their eyes, and ordered iMacs to replace them.

Timeliness is the key. If Apple had had a better grasp on what their customers wanted and – possibly – updated, upgraded and improved the 2013 Mac Pro in line with that then they might not have put themselves into a position where the product is boxed into a corner, where a great number of potential users are already invested into other products. More plainly; if the 2013 Mac Pro had kept pace with the new technologies that other products introduced and embraced (USB-C, Thunderbolt 3, the T2) then chances are that the new machine wouldn’t be priced to start at about $6k and pitched toward a small handful of highly specialized use cases who are probably going to be the only ones who’ll find any real value in that kind of outlay.

Which is kind of a shame. The new Mac Pro is imminent (any day now – supposedly by the end of the month with a quiet release, and there are already support documents floating around for the thing) and it’s a remarkable piece of design and engineering that demonstrate that Apple hasn’t missed a beat in those departments. It’s sad that I suspect that we won’t be seeing many under desks for a long, long time.

One of the primary purposes of this blog is for me to write things down that would otherwise disappear out of my feeble, aging mind; thus they stand not only as the moderately-indifferent ramblings of a middle-aged nerd but also as a sort of ad-hoc playbook for the things that I’d really like to dip into now and again. This entry, however, doesn’t fall into that category. Mostly because – unlike a lot of things I do – my .zprofile isn’t something that I forget about and have to be reminded of, and is in fact something that I have to look at Every. Single. Day.

Compared to some, it’s relatively short and simple. I’ve written long profiles before and crammed them with aliases and whatnot, but in the end simple muscle-memory evolution and reduced expectations have kind of stripped that down into the abbreviated list below.

These first six entries are ssh key-protected remote logins to servers that I hit on a fairly regular basis to do routine maintenance. Actual domains and machines replaced with “x”s to protect the innocent. I mean, I’d have replaced the usernames too, but they’re all pretty cookie-cutter…
alias casa='ssh localadmin@xxxxxxxxx.local'
alias dh1='ssh odadmin@xxxxxx.com'
alias office='ssh officeadmin@xxxxxxxxx.net'
alias wm1='ssh w_admin01@xxxxx.xxxxxxx.com'
alias wm2='ssh w_admin02@xxxxx.xxxxxxx.com'
alias wm2='ssh w_admin03@xxxxx.xxxxxxx.com'

This next one pairs the ssh access with a command to run a shell script called (appropriately) stopthemadness.sh which quits Filemaker and reinitializes it. The server is running a very, very large Filemaker application that ties into a very, very complicated pre-press system. Once in a blue moon the thing just throws up its hands and decides that it doesn’t feel like working, so this script fires it up again.
alias pantskick='ssh filemakeradmin@xxxxxxx.xxxxx.com "./stopthemadness.sh"'

This alias gives me my external address and a geolocated stab at where I am. Handy when using a VPN.
alias whereami='curl ipinfo.io/'

This next one is probably the one I use the most:
alias la='ls -al'

I made an ASCII art version of Clarus, because the underrepresentation of Dogcows in modern operating systems is a borderline atrocity. This calls the appropriate cowfile, and is cute but utterly useless for anything except making me grin. If I ever have the chance I’d love to find some way to pipe output from Pine into Cowsay so I could have cows (or Dogcows) tell me my email.
alias clarus='cowsay -f clarus'

Alias that takes me to the git repo of the game I’m working on:
alias tdg='cd ~/dev/tdg'

Change directory to the home directory. This one really should be in the OS by default as far as I’m concerned.
alias ~='cd ~‘

Sometimes you just want to throw something in the trash from the command line (as opposed to instantly deleting it). Just type trash and then the file name…
trash () { command mv "$@" ~/.Trash ; }

Hides the ~/Library folder…
alias hide='chflags hidden ~/Library'

…and reveals it again.
alias goseek='chflags nohidden ~/Library'

I like to start nettop up in display per-process mode (as talked about here), so there’s this:

alias net='nettop -P'

Finally, here are a few things that I like to have appear in my prompt. Uptime simply shows you how long the system has been running for, as well as the number of users and the load average of the system.
uptime

This calls sysctl to print out the type of processor you’re running. It’s useless for any real practical purpose, but I have a lot of Xeons rattling around in my Mac Pro and sometimes it’s nice to be reminded of that, thank you very much.
sysctl -n machdep.cpu.brand_string

Fortune prints out a random saying or pithy bon mot for your delectation and enjoyment. Sometimes I find it helpful to have an inspiring quote to carry me through a particularly frustrating time behind the keyboard. And by inspiring I usually mean spiteful, angry and profane. Hey, each to their own:

fortune

Next, I like to be able to quickly switch audio output sources from the command line because I am fundamentally lazy and don’t like to drag the mouse pointer to the sound menu item and try and remember which option goes to what speaker. It’s easier just to have settings for “speakers” and “headphones” and be done with it, so I used Homebrew to install switchaudio-osx and set up a couple of aliases, thus:

alias speakers='switchaudiosource -s "Built-in Line Output"'
alias phones='switchaudiosource -s "Built-in Output"'

Finally I have a line break and then a quote from Wargames. Because both Matthew Broderick and Tic-Tac-Toe are cool:
echo '=================================='
echo 'Greetings Professor Falken. Would you like to play a game?'

Configuring your .profile/.zprofile with aliases and little customizations like this is both simple and – when it gets down to it – fun. But there are some very real, very useful applications to being about to add your own complex, bespoke commands and workflows to your command-line experience, and while most of these trend more toward the fun side of things I’ve found that getting my profile set up right out of the box is both the first thing I do with a new machine and also incredibly valuable at saving time and having to reinvent the wheel…