Author: Dave

Here’s the thing: I had another post all prepped and ready to go, but instead of prattling on about Digital Legacy (which, to be fair, is a genuinely fascinating idea if you’ve ever wondered what happens to all your Digital bits after you die – albeit somewhat gloomy), I thought it would be more fun to do what I arguably do best; break out my soapbox and start yelling incoherently and impotently at the brooding and uncaring skies about UI design.

Look, okay. I’m not hurting anyone. It’s cheaper than day-drinking and everyone needs a hobby. Leave me alone.

I’d like to kick off with a quote from my old boss (or boss’s boss – the org chart at the time was confusingly egalitarian) Ray Ueno. Back in the early 2000’s we worked at a fabulous company that did remarkable bespoke boutique Branding and Identity work, and at some point said company was acquired by a succession of larger fish in short order. It’s hard to really explain what “bespoke, boutique Branding and Identity” work actually involves, and so as an attempt to clear a few things up we produced an internal video piece – part documentary but mostly skit – to showcase our company culture to our New Corporate Masters™.

Ray’s segment featured him – ensconced in his corner office, bespectacled, focussed, wryly soft-spoken – sorting through his mail and mostly just throwing it all into the recycling bin – unopened – while he ruefully confessed to camera.

“It’s interesting, because a friend of mine came to visit me once and she told me after seeing my office – my little cubby space – she told me that some of the greatest thinking minds in the history of man actually were slobs in the office. Guys like Einstein and Da Vinci and Aristotle? I guess they were slobs just like I was, and I thought “Well, I guess I can make that work for myself. I like that a lot.” 

And then I got this big promotion and I got this office. And my office has been clean ever since. 

Not quite sure what to make of that.”

The piece was, of course, a joke. One of the designers was portrayed as a borderline obsessive, concerned solely with oral hygiene. The CEO talked about her family’s rich history in dentistry and her resultant aversion to blood. And, honestly, I don’t recall whether Ray’s office was actually really that tidy, but I don’t recall it being a noted disaster area either, so the truth of the matter is that it probably stood betwixt those poles and showcased the normal amount of clutter.

Still, the meat of the business is worth exploring; to whit, that cleanliness and orderliness are synonymous with progress, whereas messy, messy desks are problematic because for every Einstein there are a million, billion people who Just Never Clean Anything Up Dammit.

Happily, the metaphor is sustained when it comes to talking about operating systems, as provided you’re talking about a non-mobile platform you’re pretty much universally buying into the idea that the place on the screen where you keep most of your icons is your Desktop, that the directories you store your data in are colloquially known as Folders, and even that the data itself is mostly described as Files. That’s the problem, though – when erstwhile, predominantly-mustachioed, bell-bottom-clad 1980’s software engineers were pioneering the concept of the GUI they naturally seized onto what they had at hand – desks and work surfaces – and made Digital analogs for those things. It turned out to be an effective and genuinely useful idea; that you could take the idea of a conventional, physical experience and translate it into a digital form, and with that they brought along a lot of assumptions from the one experience and lumped them into the other. It was a move of staggering simplicity and rare genius, and paved the way for how we’ve interacted with computers for the last forty-odd years. It was a turning point; rare and perfect and brilliant.

And, it turns out, when you stretch it to the limit it starts to become irredeemably problematic.

Note: I’m going to harp on about UX and UI for a while, so it’s probably worth setting out a very basic idea of what I’m talking about when I start blathering on about that. Another note: I am not a UX/UI designer – or any kind of designer for that matter – but I’ve butted up against that world just enough to have a working idea of the most basic concepts. UX design is – in a nutshell – the design of the User experience. If you’re, say, designing a bank’s website then you’d turn to a UX designer and have them come up with ideas about how to make the thing functionally simple, easy, and intuitive for your end users. With that in hand, you’d need a UI designer, as UI design concerns itself with the interactivity/look and feel of the design. It’s unfortunate that UI design is often broadly interpreted as “make the buttons look pretty”, but the reality is that it’s a far, far more complicated and nuanced business than that. Right. Notes over!

The problem, I suspect, is the iPhone; once it hove into view then that fundamental rethink of how we interact with devices became a sort of sea change that rolled over into other platforms and fields. Making mobile device interfaces as bone-simple as possible isn’t – in itself – controversial; after all, if you have very limited screen real estate and need to present a core set of functions to end users then you have to make some hard choices about what to put in, what to take out, and where to put everything. To make matters more complicated a lot of users expect mobile applications to offer a sizable portion of the same configurations and options as the equivalent Desktop product, which leads to some significant challenges re: shoehorning solutions designed for enormous screen real estate into a tiny, tiny fraction of said real estate.

So, challenges abounded. And, by and large, UX and UI rather stepped up to the plate, to the extent that thoughtful, resonant design has flourished and the App Stores of your mobile platform of choice are – generally speaking – stacked to the gills with clever, well-designed applications that fulfill the major functions of Desktop or web clients. So. Well done all round. Time to roll out the red carpet to all concerned, award small trophies, and fire up the grill for the celebratory UX/UI Association Pancake Breakfast and Annual Jamboree? Absolutely. Except…

Here’s the thing. It’s one matter to take limited resources (i.e., screen real estate) and pare away the dead wood in the name of functional parity with Desktop applications, but it’s another thing entirely to do the same thing in reverse; i.e., take a look at your fancy mobile platform with its clean layout and simplified controls and then decide that well, if people like not being able to see a lot of buttons on their iOS devices then logically it follows that they don’t want to see a lot of buttons on their Desktop computer. Yes, that was a hell of a run on sentence, but I’m annoyed – no, I’m irate – and I’m all bent out of shape because of this:

This, I realize, might require a word of explanation. In a nutshell, this defaults write command allows you to turn this:

into this:

“Those,” I hear you cry, “are two screenshots of macOS Finder windows that are pretty much the same.” No, no they are not. I mean, yes, okay, technically they’re both screenshots of the same folder, but the first one is set with the default options you get with macOS Big Sur (and so far with macOS Monterey), and the second one is what you see when you tell the Finder to stop being a bloody idiot and actually show you some useful things for a change.

The first screenshot – the default view – shows you arrows for navigating back to the prior screen, the name of the folder, one view menu that you can toggle to reveal other options, another for sorting the contents of the window, share, tag, and options buttons, and a truncated magnifying glass search button. (Both windows also contain a Synology Drive button because I love Synology Drive, but we’ll ignore that for now, okay? Okay.)

The second screenshot has the name of the folder centered at the top of the window along with a permanently-viewed proxy icon, a full set of clickable view options, the same share, tag and options buttons, and a full search field.

These, I hear you say, are not so different. There are few real deal-breakers here. Yes, having the proxy icon visible without having to scroll over it to make it something that you can click on is a definite boon, and sure, being able to quickly click on a view type and also type directly into the search bar are mild improvements and remove small annoyances, but there’s little there to make a fuss over. That’s fair, but the greater point is that we should be asking ourselves “What prompted the move to take those options away by default?” If having a full search field available saves you clicking on the magnifying-glass icon and watching the cute little animation then it also saves you a few fractions of a second of clicking around, stabbing at the little icon. Likewise not having to scroll up and down a menu to choose a different view. These are not monstrous intrusions on your day, but they are paper cuts to the soul for people who like having everything on their desk that they need. Removing them is an unnecessary indulgence in the name of cleanliness.

And, worse yet, they’re entirely redundant. What, after all, is really being saved in hiding those features? Nothing. Nothing is being saved. A Finder window doesn’t have the same stringent limitations on screen real estate that you’d find on a mobile platform. There’s no real-world benefit, here. To duck back into the now-tired metaphor, it’s like keeping your stapler in your desk drawer when you use it all the time and there’s a spot right on your desk where it’s lived for years, not getting in anyone’s way and cheerfully doing nothing except dispensing staples and letting you get on with life.

So, sure, I’m all bent out-of-shape about how my computer looks. Fine; I’ll hold my hand up to that. But stripping my personal tantrum aside, it’s worth putting your head to the proverbial railroad tracks and listening to what’s oncoming. After all; what’s next? How many layers of elephants can you go down before there’s nothing left at all? It’s not as if this was a decision made out of necessity – in fact the procedure to turn the old view back on has been in macOS for years, albeit entirely undocumented.

Let that sink in a moment: Apple – a company synonymous with industry-leading and ground-breaking UX and UI design – made a sea change in the interface that people were used to, stripped away functionality for no discernible reason except in the service of clean design, and could have easily put a button somewhere in the OS that would have allowed you to just toggle it back to the old, more functional view. I am not Apple and not part of their macOS development team, but if you were to tell me that a professional operating system designer could have taken more than five minutes to write that code and slap that button into place then I’d be fabulously, fabulously surprised.

There’s value in good design that informs the user experience, and in the pursuit of that it’s entirely appropriate to decide that Less is More. But there needs to be an ounce of examination of what motivates that design. After all, sometimes Less is just… less.

Look, it’s been a while since I wrote one of these. I feel kind of bad about that, but on the other hand it’s been an interesting couple of months of doing more IT than writing about doing IT – which culminated in the entire floor of the building I had my office in being sold to some shadowy conglomerate and thus having to go and find a new place to work from. Tl;dr – I’ve been busy.

Still, I have a new office now, and it while it has… indifferent air conditioning, it also has big, cool, old-fashioned windows that let a lot of sunlight in.

This, of course, is lovely. And I have no complaints about this save for the fact that my Synology NAS gets warm, and because it gets warm it decides to turn itself off semi-regularly, and while I appreciate the clever design of a piece of tech that takes the extra step to preserve data, I’d really rather it didn’t do it quite so often.

The root cause of the problem is that my NAS is full of SSDs, because they’re quiet and fast and I had a lot of SSDs and nowhere to put them. They’re a superb alternative to old-school rotational hard drives, although they do tend to get warmer, and that’s the issue I’ve been running into. Regular hard drives run fairly cool, and the Synology DSM monitors the temperature of those drives and switches itself off once they hit about 61° – which is fine and laudable because having your NAS shut itself down is infinitely preferable to having your NAS suddenly filled with the screaming, smoking ruin of all of your hard drives exploding at once. SSDs, however have a significantly higher thermal threshold before performance and functionality degrade, and so shutting down when an SSD hits 61° is somewhat premature.

Synology DSM gives you some fairly stripped down tools for managing temperatures – chiefly, the ability to choose how fast the fans run in the thing and thus how effectively they can cool the drives down. And when I say “chiefly” I mean “solely”. Still, I started doing some digging into what could be done to manually adjust those fan speeds – after all, Synology NAS units use Linux as an operating system, and as such a lot of settings for how the thing actually runs are stashed away in editable form in .XML documents. Fan control should be, therefore, something that could be tweaked, and shouldn’t be limited to just the handful of presets that Synology gives you to work with right out of the gate. It transpires that fan speed and settings are stashed in a file called scemd.xml that can be accessed by ssh-ing into the DSM, and that when you open that file you see this:

Now, I don’t know about you, but I see fan_speed in there and also disk_temperature, and it didn’t take a herculean leap to note that:

<disk_temperature fan_speed="99%00hz" action="SHUTDOWN">61</disk_temperature>

…might mean that when the temperature of the disk gets to 61° then the NAS decides that it’s time to shutdown. Common sense would dictate that if you could edit that file with a temperature that an SSD might be happier with – say, 70° – then the thing wouldn’t stop working every time there’s a warm day (which there are a lot of here in California). So, I decided to fix it, and here’s how I did it.

First, you’ll need to log in to your Synology DSM and make yourself a home folder on the thing to work from (it’s possible to do all the below a lot faster if you log in as root, but I prefer to go slow and steady and build in break points when I’m tinkering around with the device that holds all of my work data oh god please don’t go wrong). In the DSM, open the Control Panel, hit the Terminal & SNMP tab, then check the box to enable ssh.

Open a terminal window on your Mac, and log in to your NAS via ssh:

ssh administrator@fake-nas-name.local

Note: I’m using administrator and fake-nas-name.local as the user and name of the NAS for the purposes of this article. Use your actual admin name and the address of your actual NAS. That sort of goes without saying, right?

If prompted, hit “yes” and then enter the password of the DSM user you’re ssh-ing with.

DSM users don’t have homes set up by default, but you can make one by doing the following in the ssh session:

cd /var/services

sudo mkdir homes

sudo chmod 777 homes

cd homes

sudo mkdir administrator

sudo chmod 777 administrator

Once you’ve got that set up it’s time to go and start mucking with the scemd.xml file. Because I’m not an utter blithering incompetent I decided to go make a backup of that file so that if I screwed something up terribly, terribly badly then I’d be able to roll things back. I encourage you to do the same:

cd /usr/syno/etc.defaults

sudo cp scemd.xml scemd.xml.bak

With that out of the way, it’s time to go grab the scemd.xml file and either edit it yourself on the DSM or do what I did and copy/paste the thing into BBEdit on your Mac so that you’re not tampering with a live file. To to this I just did a cat scemd.xml and then copy/pasted out from the terminal and into BBEdit.

The scemd.xml file is pretty straightforward; it’s laid out in sections with the settings for the NAS at the top in both DUAL_MODE_HIGH (i.e., the DSM default more-cooling-more-noise) and DUAL_MODE_LOW (quieter fans, more heat) underneath, followed by settings for a lot of expansion chassis units that we’re not going to mess with.

Find the DUAL_MODE_HIGH and DUAL_MODE_LOW lines that read:

<disk_temperature fan_speed="99%00hz" action="SHUTDOWN">61</disk_temperature>

and edit the 61° to 70° so that it reads:

<disk_temperature fan_speed="99%00hz" action="SHUTDOWN">70</disk_temperature>

Save the file to your Desktop, close BBEdit, then open a new Terminal window.

The next step is to move the newly-edited sceml.xml file to your newly minted home folder on the DSM, which you can do with this command:

cat ~/Desktop/scemd.xml | ssh administrator@fake-nas-name.local 'cat -> scemd.xml'

Jump back into the Terminal window running your ssh NAS session and check that the scemd.xml file is in your home folder:

ls /var/services/homes/administrator

All things being equal you should see scemd.xml as the output.

Finally, you’ll need to write over the existing scemd.xml file with your edited version, and then copy the new file to /usr/syno/etc:

sudo mv /var/services/homes/administrator/scemd.xml /usr/syno/etc.defaults/scemd.xml

sudo cp /usr/syno/etc.defaults/scemd.xml /usr/syno/etc/scemd.xml

Reboot your Synology NAS to restart the appropriate services, and that should do the trick.

As is ever the case with these things, your mileage may vary, and any time you tinker with the guts of your NAS you run the risk of fat-fingering something and the whole thing coming crashing down. Please, I implore you, please do a full backup of your data before attempting to do any of the above.

So far, this has worked without incident. In fact, as of writing this I can see that one of my SSDs is hovering at about 57° and the other is running at °61 without a hitch, which I’m calling an absolute win…

The problem with knowing people who are very smart is that occasionally you get dragged into their smart-person shenanigans. Dumb people are more fun in this way; their idea of a good time is to go set off all the illegal fireworks they found in a trash bag next to the freeway inside the nearest dumpster or abandoned refrigerator, which is generally a good time and requires little from the average bystander except a willingness to bring their own fire extinguisher and an ability to watch out for the cops. Smart people, however, will drag you into Intellectual Pursuits, and it’s thus that I’ve ended up banging my head obsessively against trying to get Exotic installed on Big Sur.

“What is Exotic”, I hear you cry? Well, it’s a clumsy acronym for EXOplanet Transit Interpretation Code, which in its simplest terms (which are the only terms that I can reliably understand), means that it’s a Python package that you use to reduce photometric data of transiting exoplanets into light curves, thus retrieving transit epochs and planetary radii.

Okay, you got me. I copied that last bit from the Exotic GitHub page. I am not a data scientist; I am merely an well-coiffed ape with a dream and what Liam Neeson would doubtless describe as a set of Very Particular Skills – none of which involve understanding what the hell a “transit epoch” might consist of.

Still, Better Minds Than Mine assure me that Exotic is a Python package that examines data from massive telescopes and interprets that data to let you know if there might be a planet zipping around a distant star, and who am I to challenge this claim? How does it do this arcane task? I don’t know. Hell, I don’t think anyone really knows – this kind of thing, as far as I’m concerned, is essentially synonymous with witchcraft. Which has some tonal resonance for me, because getting the thing installed on a Mac running Big Sur required a certain amount of supernatural wrangling all of its own.

For one thing, it requires a long list of Python dependencies (software components required by a system to be in place before you install The Thing You Really Wanted To Install) to get the thing installed, and most of those dependencies have their own lists of dependencies, and after a while it starts to feel like there’s dependencies all the way down. Some of those dependencies install without error or comment, and others fail in the most dramatic way possible – mostly by spitting out 2,700 lines of alarming red text where the precise shade of red has been carefully engineered to provide maximum guilt and terror (red on black is also hard to read, but I’m going to stick with the guilt/terror thing as that means I don’t have to confront my fading eyesight. Having bad ears is quite enough, thank you).

Apple helpfully updates Python with every OS release, which has the unfortunate effect that they’re continuously moving goalposts without telling anyone – so a package that might work just fine with one release might fail utterly after a seemingly trivial point upgrade. Fortunately, you can get hold of a lot of old versions of Python here. Which is what I did – downloading a fresh copy of Python 3.8.6. This, unfortunately, is the non-M1 version of Python and requires Rosetta 2 to be installed on your M1 Mac, but there’s regrettably not much that can be done about that.†

You can, it should be noted, install as many versions of Python as there are (ha ha) stars in the sky. The problem with that approach is that you’ll possibly need to switch between them using something like pyenv, but in this case it wasn’t important to do a lot of mucking around with keeping options open vis-a-vis Python versions; the prime directive was to make sure that as far as the Mac was concerned when someone typed python then this was interpreted as the freshly-installed Python 3.8.6, and not the included-with-the-computer-and-hard-to-remove Python 3.9.2.

This was fairly simple to accomplish with a command to write an alias into the .zshrc file:

echo "alias python=/usr/local/bin/python3.8" >> ~/.zshrc

What this does is inject the alias python=/usr/local/bin/python3.8 command into the file that macOS uses to configure the zsh shell so that whenever you type “python” into the terminal your Mac sort of clears it’s throat and discreetly directs whatever comes next toward the version of Python that you tell it to instead of the one that it would customarily choose right out of the box.

Next, there are three python packages that should be installed before attempting to install Exotic:

pip3 install wheel

pip3 install importlib_metadata

pip3 install —upgrade keyrings.alt

With those in place, you’ll need to run the Install Certificates command that you should find in the Python 3.8 folder in your Applications folder (otherwise you’ll run into all kinds of SSL/TLS errors. Which are Bad Things).

Finally, you can install exotic:

pip3 install exotic

Note: You may have to run this command twice as I’ve seen it error out on installing one package with a missing dependency that is fixed by a second install.

All things being equal, you’ll be able to type exotic in the Terminal, and see something like this:

† – Way back at the beginning of this article I mentioned that we installed a non-Apple Silicon version of Python (3.8.6), which means that if you’re using an M1 Mac then that M1 Mac will be running Python through emulation – in effect, pretending to be an Intel-based computer. This, it should be noticed, means that it’s running a lot slower than it would be capable of doing with software written for the ARM-based chip in the M1 (Later versions of Python are available that are optimized for Apple Silicon, but none of them seem to work with Exotic). This sounds bad – and in reality it’s not perfect, but here’s some anecdotal feel-good data for you.

The ingenious boffins who came up with exotic also make some test data available so that you can try the thing out to make sure it works. Running that test project on a 2017 i7 MacBook Pro took twenty-two minutes to process and render the test data, accompanied by a chorus of whirring fans and a truly alarming spike in how hot the computer got.

My 12-core Xeon Mac Pro with a bucket of RAM and fast drives took a decently respectable fifteen minutes to chew through the same data and spit out a fancy-looking graph, and because it’s largely comprised of fans (and pretty noisy as a baseline) it didn’t get noticeably hot or bothered by this procedure

A bottom-of-the-line, base spec M1 MacBook Air? Five minutes. It took five minutes, and the thing didn’t so much as get mildly warm. Running on an older version of Python while under emulation. Five minutes.

This is… well. Blimey.

macOS (at least, as of Big Sur 11.2.1) ships with Python 2.7.16 by default. This seems curious when you consider that Python 2.7 was deprecated and no longer supported after December 2020, but there are Reasons for shipping the newest and shiniest macOS operating system with a (much) older version of Python.

For one thing, Python 3 isn’t backward compatible, and Python 2 has vast library support that might be critical to your workflow, and not having those libraries available seems like a recipe for disaster. For another thing, you invoke Python 2 with the python command, and Python 3 with the python3 command – and while this seems less obviously an issue it’s actually a much bigger problem that you’d expect. After all, how many pieces of code or scripts are out there, undocumented, starting with #!/usr/bin/python? I’m betting the answer to that question is, well, a lot.

So, what to do if you want to be able to run both Python 2.7 and Python 3 on a single install of macOS? Well, there’s a two-pronged way of doing it by utilizing the homebrew pyenv package (which is ingenious and well-supported) along with a little .zshrc hack (which is something I came up with and therefore almost certainly deeply problematic).

You can find pyenv here, and the simple installer for it linked here. In the simplest terms, what pyenv does is intercept any request that’s made for python commands and then slides those requests over to the selected version of python. It’s extremely clever and additionally that rare and unusual creature in that it’s a GitHub project that’s both well-maintained and well-documented. You’ll need to install the Xcode Command-Line tools with an xcode-select --install command, but once that’s done you can run the installer linked above and it shouldn’t cause you much trouble.

Once installed, there are a couple of additional required steps. Firstly, you’ll need to make a backup of the .zshrc file in your home directory with ditto ~/.zshrc ~/.zshrcbackup (if you don’t already have a .zshrc file then feel free to skip this part.)

Next, make another copy of your .zshrc file: ditto ~/.zshrc ~/.zshrc2 (This may seem needlessly duplicative, but it’ll come in handy in the ugly hack part of the procedure later on).

Finally, edit your .zshrc file and add these lines onto the end:

export PATH="/Users/daveb/.pyenv/bin:$PATH" (Note: substitute your short username for daveb unless your name is also Dave B.)

eval "$(pyenv init -)"

eval "$(pyenv virtualenv-init -)"

Once you’ve done all the above, quit Terminal, open it again, then install your Python version of choice by issuing the pyenv command, invoking the install option, and then adding the version of Python you want to install like so:

pyenv install 3.9.1

…and that’s it. If you want to install other versions of Python then you can run the pyenv install command again with the relevant build, and if there’s one particular build that you want to, say, specify Python 3.9.1 as the default then you can make that so with the pyenv global 3.9.1 command. A more complete and in-depth list of commands can be found here.

So, now that’s all the pretty, elegant stuff out of the way, so time to move on to the ugly hack. The problem I’ve found with pyenv is that it’s great for installing versions of Python that are up-to-date, but that it really doesn’t seem to want to toggle back to the version that Big Sur ships with, and there doesn’t seem to be a convenient off switch for the thing. Further, trying to install that old version (2.7.16) doesn’t work because Python 2.7.16 is ancient and wicked and pyenv refuses to allow something so arcane to be installed on your machine (despite the fact that it was on there already).

To get around that, I added this to my .zprofile:

alias py='mv ~/.zshrc ~/.zshrctemp; mv ~/.zshrc2 ~/.zshrc; mv ~/.zshrctemp ~/.zshrc2'

Ugh. Just look at that thing.

Like I said, it’s ugly, but when you type the alias py into a terminal window then what happens next is that it takes your existing .zshrc file, renames it to .zshrctemp, then takes the .zshrc2 file and renames it .zshrc, and then finally takes the .zshrctemp file and rename it .zshrc2.

In effect, it takes the .zshrc2 file (the one that isn’t set up to enable pyenv) and switches it out with your .zshrc file (the one that is set up to enable pyenv). When .zshrc2 becomes .zshrc, pyenv suddenly no longer works, and your computer defaults to the version of python that it shipped with (in my case 2.7.16) because it suddenly doesn’t know any better. And because the command just switches those two files around, issuing it again turns the tables and re-enables pyenv.

Normally I like to make these amusing little bon mots tightly focussed on macOS and iOS integrations, tips and tricks, but this one is… a little different.

Instead of talking about macOS, I’d like to talk about Izzy Stradlin. If you can’t immediately picture Izzy (maybe you weren’t paying attention to the rock charts in the late eighties), then he’s this guy:

Still not ringing any bells? Okay, I can see that. That’s fair – sad, and makes me feel very, very old, but fair. You might know him as this guy:

Izzy Stradlin was the rhythm guitarist, sometime vocalist, and a primary song-writer for Guns N’ Roses – a band that I loved with a rare and utter abandon back in 1988. This is not something I feel I have to defend as a foolish whim of youth; “Appetite for Destruction” is a perfect album and if anyone would tell me otherwise then that person would no longer be my friend and there is an additional statistically decent chance that we would – in due course – result to fisticuffs. There may even be a donnybrook.

Later Guns N’ Roses got pretty wobbly (quality and production-wise), but this album remains flawless because it was recorded by brilliant engineers who had the wisdom to embrace a stripped-down approach; to whit, put Axl Rose in the middle where he could growl and scream and wail at the world, have Slash on lead guitars on the right channel and Izzy playing his distinctive, borderline unnecessarily-choppy and bonkers-aggressive rhythm on the left channel.

Izzy left the band in the early nineties and went on to make a lot of solo records that I justifiably rave about because they are universally excellent, but one day in 2010 he disappeared from my life.

Okay, that’s a little dramatic. He didn’t disappear – as far as I know he’s living somewhere outside Ojai doing… whatever semi-retired rock stars do, and good luck to him. No, I mean that about the time that he put out his last solo record and steadily retreated from the world he also steadily retreated from my left ear, and has remained gone for the last decade.

---

I am forty-seven years old. There are things that you don’t imagine about being forty-seven that sort of creep up on you without noticing. My back never really completely healed after falling off a horse (my own damn fault) about eighteen years ago. My left knee made a sort of “popping” sound one day while hiking back circa 2014, and at the time I looked at it with a quizzical expression and thought “Huh. Well. That can’t be good.” (Spoiler: it wasn’t.)

Bits of you slow down and stop working and generally you degrade in both small and large ways, and while this is something you entirely expect (because you have no illusions about the predations of time and are not an idiot in that regard), it’s one thing in the abstract to understand that you’re not going to be springing out of bed in fighting form in your middle-aged years and another to wake up one day with the dim realization that this is more difficult than it used to be, that dim realization calcified in your mind as much as in your calcified joints.

And really, I’m not complaining. These are table stakes for seeing another day – they are the price we pay for the stuff we did thirty years ago, and I think most people are happy to pay it if that means that you got to drink and dance and spend your weekends headbanging like a maniac to “Welcome to The Jungle” in a lot of now-long-defunct rock clubs. These were good times – and I’d do them all over again except that I now look like my Dad, can’t pull off the long-hair look, and mosh-pits are probably all COVID hot zones these days. Some things are better left in the past; you just have to embrace the moments gone by and let them go. Take what they give you, and move on with your life.

Unfortunately, what those experiences mostly gave me was hearing damage, which brings me on to Mimi Hearing Test.

Mimi is a free download from the App Store, and in conjunction with the Accessibility options in iOS it can mitigate some of your possible hearing loss – at least, for phone calls and audio played through the iPhone. It creates a custom audiogram that you can point Accessibilty at, and in turn Accessibilty will run audio through that audiogram so that frequencies that you may be lacking are boosted. The overall effect of this is that – at least in my personal experience – I can now hear Izzy Stradlin again in my left ear for the first time since late 2010.

Here’s how set it up. First, download the app from the iOS App Store and install it on your phone. Then open it. I doubt these are controversial steps. On opening the app you’ll see the following:

Find a quiet place in your abode to sit while you run the thing. It’s going to test your hearing, so try and ensure that there’s the least ambient or environmental noise possible. I sat in a dark closet at the furthest end of the house from everyone else. This worked well, but I have no knowledge of the particulars of your domestic environment so choose your own spot. No, you can’t use my closet. That would be weird. Hit “Continue”, and you’ll be prompted to connect and select your headphones. Mimi seems to be designed with certain headphones in mind (both in and over ear), but as one of the pre-ordained options is for Apple AirPods (and they’re my ear sticks of choice) I opted for that.

Dial the volume on your phone to 50%:

And then begin the test:

This took me a couple of tries – fortunately you can re-do a bad test. The idea is that you tap the “I can hear it” button whenever you hear a sound in each ear, and then release the button as soon as that sounds goes away. Each ear is tested with a range of frequencies for a couple of minutes, and this quickly becomes annoying when the sounds of your own breathing conflict with the almost-inaudible sonic whines you’re trying to pay attention to. Once you’re done you’ll get the results, which in my case look something like this:

This wasn’t what I’d call something I was happy about, but it tracked with what I knew already; any audio I’d play with any headphones was always substantially quieter in my left ear, and there are only so many pairs of headphones you can go through before you have to admit that they can’t all be bad on one side and that you, in fact, are bad on one side. So, while it’s jarring to have confirmation of your own failing senses, we’re better off moving on to the fixing-it bit, right? Right.

To do that, open up the Settings app on your iPhone, click on Accessibility, and then scroll down to tap on Audio/Visual:

Toggle on Headphone Accommodations:

…and then hit “Continue”. All things being equal you’ll see an option for Audiograms that you can select and use:

Finally, you’re presented with the Recommended Settings screen, which is really just an excuse for the phone to show off how good (or bad) the custom setup you’ve made is compared to the standard. Make sure you’ve selected “Custom” and then “Use Audiogram”:

The difference is jarring. But in a good way. Each time you run the Mimi app you can create a new Audiogram – and what I’ve shown above is a bit of a cheat because it’s actually my third attempt (I fat-fingered the first one, the second one was impacted by having a plane fly overhead and the resulting audiogram made everything hopelessly distorted), so you may want to tinker a little to get to the optimum experience.

Having the hearing of a thirty-seven year old doesn’t sound like a game-changer unless you’re a forty-seven year-old. Although, come to mention it, the only way that I’d know for sure how effective this is would be to go and dig further back through my music catalog and break out some of the stuff I was listening to in the early 2000’s – and that’s a potential chamber of musical abominations that I’m largely glad I’ve left behind. For now I’m just happy to have Izzy Stradlin back where he belongs, buzzing away in my left ear like a bizarre, insanely, gleefully infectious reminder that the past isn’t necessarily always as far away as we imagine it to be.

The new M1 Macs are things of wonder and delight. Cool, inexpensive and fast. Staggeringly, ludicrously fast. Everyone should have one. In fact, if you’re reading this and you don’t own one then you should probably close this window (I mean, bookmark it first) and go and buy one and then come back and we’ll continue.

You did that? Good. Congratulations! I don’t think I know anyone who is disappointed with the whole Apple Silicon experience except for my friend who, for the sake of argument, we’ll call David. Because this is in fact his name.

My friend bought an M1 Mac mini on my recommendation to do some development work on, and was immediately frustrated that many of the things that he’d want to use don’t work properly (at least, not yet). Cocoapods, Docker, the native version of Homebrew – these are all things that are actively incoming. And that’s fine – these things might be a month or two out from being fully and totally supported and reliably working. He understands that; what seems to bother him is that despite all the purported speed increases, the Mac mini feels… slow.

The problem, I suspect, is Big Sur. Whether you’re running the slowest, oldest, least supported i3 iMac or a $55k Mac Pro there are some things that remain true across the board. Speed is all about perception, and there are tangible roadblocks that have been put in place in the name of User Experience in Big Sur which rely on tinkering with the balance between speed and aesthetics.

One example is the wretched rollover delay in the Finder. Here, for example, is what I see when I roll over the (stupidly hidden) spot to reveal the proxy icon for the current folder:

Ignoring the fact that there’s no earthly reason why this icon should be hidden in the first place there’s the matter of the delay before it pops into being. It’s a little more than a second, no matter what computer you’re using. A little more than a second may not sound like a lot, but if you’re spending the day – purely for the sake of argument – doing a lot of filing of documents and general end-of-year/spring cleaning on your Apple IT Consulting business then you’re going to end up rolling over proxy icons a lot, and that grain of sand between your toes is going to grate.

Fortunately there’s a simple way of fixing it by adjusting the default rollover delay via the Terminal, thus:

defaults write com.apple.Finder NSToolbarTitleViewRolloverDelay -float 0; killall Finder

This tweaks the delay down to 0 seconds, which ends up looking like this:

Still, that’s not enough. There are other delays built into macOS that (depending on your taste) you might want to decrease or dispose of altogether. My personal favorites are reducing the initial delay when pressing a key and then also reducing the key repeat rate. Thankfully, these can both be demonstrated with a single animated gif and tweaked with a couple of simple Terminal commands.

The “before” gif:

This isn’t terrible, but if you’d rather have something more responsive then you can try the following Terminal command:

defaults write NSGlobalDomain InitialKeyRepeat -int 12; defaults write NSGlobalDomain KeyRepeat -int 1

Which – after you log out and in again – gets you this:

These are, it has to be said, small hacks. Trifles. Almost inconsequential in the grander scheme of things, and definitely fringe cases where your mileage may vary. Not everyone, after all, is happy with a version of the world where hitting the delete key for a fraction longer than they normally would can result in vast swaths of text being instantly deleted. But on the other hand, they do point to a greater issue; that the way that you work with your computer is wholly subject to the decisions made on your behalf by other people. Apple’s fit and finished on their operating systems is… well, if not without reproach (because that’s a bold claim) at least the result of rather more careful thought and review than the fit and finish of most of their competitors.

Still, having some flexibility and the ability to customize the way your Mac operates isn’t a repudiation of Apple’s work. If anything, it condones it. Or, at least, makes it a little faster.

Okay. This isn’t some philosophical nonsense about how to tear yourself away from the screen, or how it’s important to compartmentalize your life, or how we’re all engendering negative self-imagery because we’re looking at pictures of ourselves all day or anything of that nature. This, in a very literal sense, is about how to Quit Zoom.

Or more precisely, how to get Zoom to quit. I’m sure that I’m not alone in my frustrations in this department; you’re done with your Zoom call and everyone is saying their farewells, so you hit the “Leave” button in the bottom right hand corner of the Zoom window, thus:

and… don’t leave, because you have to click “Leave Meeting” a second time:

I mean, sure, the world is full of horrors right now, but while we’re all carrying rocks in our back with names like “insurrection” and “pandemic” and “looming economic apocalypse” it’s the little things that seem to get me down the most. The flecks of grit in ones proverbial sock, and as I spend a lot of every day on Zoom this is the one that chafes me the most. So I decided to do something about it, and that something is a little script/application that I call…. Zoomkiller.

Okay, the name is a work in progress. I’m workshopping a few alternatives. I should probably also come up with an icon while I’m at it, because right now it looks like this:

The reason it looks like this is because it is, in fact, an AppleScript application. I could have written the thing in Swift (and may actually go that route at some point), but AppleScript (while increasingly archaic) is pretty great for knocking together very simple tools to do very simple jobs.

Telling AppleScript to quit an open application is easy – you just tell it to activate the application and then use System Events to feed it the appropriate keystroke, like so:

If Zoom was something that played nice and quit right away with one simple Command-Q keystroke then that’d be all that was required (and, more to the point, something simple enough that Zoomkiller wouldn’t be required at all), but unfortunately it’s not that simple. When you try and quit Zoom, you get that pesky second “Leave Meeting” button that pops up on the screen – fortunately that can be killed with AppleScript and System Events again:

This does the same thing as the first script, but then additionally tells System Events to go look at the front-most window and click the first button (which is, in this case, “Leave Meeting”). The next step is to save the thing as an AppleScript application by choosing “Export” from the “File” menu and selecting the appropriate options as seen below:

Et voila! There are just a couple of more steps to get this thing to run properly. Firstly, you’ll need to tell your Mac that it’s okay for Zoomkiller to control your computer (i.e., that it’s allowed to use System Events to send keystrokes to Zoom to tell it to quit).

First, open the Security and Privacy pane in System Preferences:

Click on the padlock in the bottom-left corner to unlock the prefpane (you’ll need to enter your computer password), then click the “+” icon and navigate to where you put your Zoomkiller application and click “Open”.

…and that’s about it. I’ve dragged Zoomkiller into my Dock so that at the end of each call I can just tap on the icon – because the application is saved as run-only and because it doesn’t stay open after running it just neatly quits Zoom and then quits itself without any further required input.

PS: Copy/pasteable code below. Enjoy(?)

activate application “zoom.us”

tell application “System Events” to keystroke “q” using command down

tell application “System Events”

tell front window of (first application process whose frontmost is true)

click button 1

end tell

end tell

As I’ve made abundantly clear to a lot of people over the years, we should all have been paying more attention to Helen Keller.

Okay, maybe I should clarify that somewhat.

If you were to start talking about Helen Keller to the proverbial person-in-the-street then there are certain touchstones of knowledge that you’ll see come into play. Some people will have no idea who Helen Keller is – which I get, because she’s a much bigger deal in the USA than anywhere else, so for those folks I’d mention the whole being-born-deaf-and-blind thing (which is what most people customarily jump to), as well as the whole Socialism thing (which is an association that a significantly fewer number of people make), but those are kind of table stakes. They’re showy and textbook inspirational/surprising, but differently-abled socialists aren’t uniquely unknown.

No, the thing I’d really draw attention to was her incisive grasp of the nuances of late twentieth and early twenty-first century Information Security, which were as gimlet-sharp as they were eerily predictive – the latter being quite a feat considering that she died in 1968.

What I’m referring to – of course – is this quote:

“Security is mostly a superstition. It does not exist in nature, nor do the children of men as a whole experience it. Avoiding danger is no safer in the long run than outright exposure.”

Helen Keller – “The Open Door”

Now, I’ve used this quote in a lot of talks in a lot of hotel conference rooms near a lot of airports over the years, and once this current plague is over I hope to use it in a lot more, because it’s something that’s absolutely worth absorbing and I like the weird little swag bags you sometimes get when you’re a speaker at a conference because I never seem to have enough pens and novelty iPhone chargers. Pursuing absolute security is like blundering into your nearest National Park, blindly hoping to bump into a Unicorn; no matter what your intentions you’re going to end up cold and tired and wet and disappointed.

Security doesn’t exist. It’s a mental and conceptual model that we’ve created so that we can sleep at night, and nothing more. You are not safe from lightning strikes on clear summer days. You can be as cautious and careful as possible and be rigorous in your use of PPE and distancing and still get COVID-19. A meteor could crash through your house while you sleep. Terrible, unexplained, fatal things happen to people all over the world on a daily basis; sure, sometimes the odds are fantastically slim, but you’re still playing a game with those odds.

It’s usually after making that point that I bring up the next slide in the deck, which looks a little something like this:

When we talk about “security” what we’re really talking about is “the mitigation of risk.”

This is an unpleasant truth, and when I address it in front of the aforementioned crowds in the aforementioned hotel conference rooms I can usually see the audience do one of two things; dutifully nod and go back to screwing around on Facebook (which is what most conference attendees – whose presence is mandated by their bosses – do anyway), or actually start to pay attention (which, as a person standing on a stage who spent two hours the night before rehearsing in the bathroom mirror, is something I heartily approve of).

This, in an admittedly roundabout fashion, brings us around to this story. If you’re disinclined to go and follow and read that link then I’ll lay out the broad strokes thus: during the current imbroglio that is the SolarWinds investigations another security firm (CrowdStrike) reported that Russian hackers had used compromised access to the vendor that sold it Microsoft Office 365 licenses in order to attempt to harvest emails that – because of the nature of CrowdStrike as a security company – would probably have contained privileged information.

Apple people traditionally like to throw shade at PC people, and as an Apple person I hate being lumped in with that crowd. Talking trash about a company just because you think that its products are inferior to the products of the company that you prefer doesn’t make you right, or sophisticated, or some arbiter of taste. It means that you have an opinion – which is fine – and that your opinion is something that you can’t keep to yourself – which isn’t, and which in turn makes you an asshole. I don’t want to court controversy here, but I’d venture that not being an asshole is a low bar that everyone should really try and clear, or at least strive to.

So, with that in mind you have to step back and consider this story with a little distance. Sure, this sounds bad – and it is bad – but fair’s fair; CrowdStrike have been forthcoming about the attempted breach, and while it’s fun to sling mud and hand out blame there’s really no fault in their actions – nor is there any in the actions of Microsoft (without more information on the nature of the breach on the vendor’s side there’s little value in making accusations and throwing accountability around, but my hunch is that if we’re hearing about all of this then they’ve probably done the smart thing and been transparent about the issue too.)

The problem here was not Microsoft, nor the vendor, nor CrowdStrike. Giving all of them the benefit of the doubt they may have acted perfectly. No, the problem is that if the model you’ve created to ensure your organizational security isn’t correct then no matter how well that model is implemented it’s always going to be subject to compromise. Keller’s maxim is universal. Security is superstition.

This article isn’t really about the Microsofts and CrowdStrikes of the world; I can’t speak to that scale of company because I’m an independent IT consultant in a coastal SoCal town, and because I rarely actually bump into that kind of setup. Amazon and Raytheon and the handful of larger enterprises that have facilities around here aren’t my clients, because they’re dealing with issues of size and complexity that entail a full-time staff of in-house dedicated IT support. I’ve been that in-house guy before, and I’m very happy that those clients aren’t in my base (because I like to take weekends off and I like to sleep nights and because being on call 24/7/365 is exhausting). But there are lessons to be taken here that can be applied to smaller-scale organizations. So:

It’s your data.

Passwords, certificates, login credentials – they’re your data. They don’t belong to anyone else, and they shouldn’t be given to anyone else. Not third-party vendors, not indiscriminately handed out to employees. Not even given to IT consultants.

I don’t keep passwords, because it’s a terrible business practice. Leaving aside the blatantly horrifying liability issues, I firmly believe that clients have the right to fire their IT consultants (and vice versa). I’m fortunate in that I’ve only been fired by one client, and in that case it was less of a firing than a mutual parting of ways (after all, if you’re moving from an all-macOS Server infrastructure to an all-Windows Server infrastructure then there’s relatively little point in keeping the Apple consultant around when the Windows consultant is right there in the mix). On the other hand, I’ve fired a handful of clients over the years, and having both parties able to walk away amicably and secure in the knowledge that nobody owes anybody anything makes that process easier.

Good IT consulting outfits don’t retain your data. If you forget your password and call your IT person, and they can look it up for you in their records then you should fire that IT person immediately and then change all of your passwords – and I mean all of them. The offending IT person can be of the stoutest character and unimpeachable ethical standards, but if they have your data then they’re a threat because if a third party can get to their data then that third party also owns yours. There’s little point investing in locks and alarm systems if the person who maintains the locks and alarms leaves your keys and codes lying around their office for their cleaning staff to see.

Your data doesn’t just live on your computer.

It’s not just about the services and credentials that you use inside your organization; it’s also about the services and credentials that reside outside your organization. Some of the most critical things that effect your ability to do business are some of the most-often overlooked – a prime example is DNS.

DNS – and this is an immensely stripped down explanation so don’t shoot me – is the mechanism by which the internet knows where computers and servers actually are and what they do. DNS servers tell the world where your website is, and where your email server resides. Unless you’re hosting your own DNS server (which is thankfully a rarer occurrence these days) then your DNS host has the power to – deliberately or not – completely cut off and isolate your organization from the internet.

This sounds like a worst-case scenario, but I’ve seen this a lot more than I’d like; organizations that let third-parties administer their DNS without giving any control to the organization. If I had a nickel for every time I’ve asked a client if they have any documentation or information on where their DNS is hosted and then had nothing in return but a blank, panicked stare then I’d have… I don’t know. A lot of nickels.

And again, that’s understandable. The structural mechanics of How The Internet Words are a conceptual handful, and there’s no practical need for most people to stay on top of that as a matter of course. But there is a need to have that information if needed.

Have a secure repository for your data.

Yes, yes, I know; “Security is mostly a superstition” and so forth. That’s a given, but the rest of the Keller quote – part that I don’t generally like to include in the talks at the conferences in the hotels near the airports runs as follows: “Life is either a daring adventure, or nothing.” It’s easy to take that as a carefree expression of the vital need to embrace a zest for life, but I look at it as something more chilling. “Daring adventures” are a hell of a lot better than doing nothing, after all. It’s better to have a carefully thought-through and protected repository for your data than it is to write it down in a book and put it on your desk, or throw everything in a Filemaker database or spreadsheet on your server marked “Passwords”.

(Note: Those are actual examples of things I’ve moved actual people away from doing.)

Take some time and find the right tool for documentation. Something cloud-based would be good; better yet, something with a lot of redundancy and good encryption options. I like IT Glue, but that’s just a personal preference. If you’re at an appropriate scale then look into having something written for you by a decent web/database person – there are options to explore in this space. Just don’t blindly either put everything into one bucket that lives on your computer (which can be stolen/damaged/hacked/just decide to die one day) or equally blindly go and throw it all onto a Google Workspace or Office 365 document.

Know where your keys are.

I don’t mean “keys” in the PKI sense (well, okay, maybe I do, but that’s not where I’m going with this) – I mean the keys to the things that run your business. I’ve already mentioned DNS, but there’s also Domain Registration. Do you know where your domain is registered? Whose account was used for the registration? When it expires? What about organizational Apple IDs used to administer Apple Business Manager, or APNS? What about software licenses? How are you tracking that data? Whose account was used to purchase those, and from what vendor?

That’s a lot of questions – I apologize. But not much; it’s a regrettable truth that when your job often involves going into organizations experiencing systemic trouble then you tend to only see the worst case scenarios, and in those kinds of cases it’s not uncommon to discover that the absolute critical piece of information or credential is locked behind a defunct email address, or originally set up sans documentation by a former employee, or more often than not just missing in action without a trace or a clue.

There’s nothing that can’t be fixed (well, very little that can’t be fixed), but some fixes are well-documented and quickly squared away because there’s a clear chain of information, and other fixes can take literally days of complete downtime and mountains of billable hours. Don’t get me wrong; I enjoy billable hours – I just don’t particularly enjoy writing them for reasons that could have easily been averted.

Make sure that you’re being diligent in how you implement products and services, and that there are established procedures for how those are accessed and serviced. Apple recommends having a specific Apple ID for organizations just for administering Volume Purchasing/MDM, but I’d go further and suggest setting up a specific administrative account that’s used as the contact for everything else – web, DNS, registration, licensing, the whole nine yards. Not an account that’s regularly used by an individual, either – an account that’s purely reserved for that specific purpose and that alone, with critical notifications forwarded to people inside the organization that need to see them.

What Helen Keller got wrong.

To be perfectly fair, there’s not a lot to say here. The only thing I’d throw into the ring would be that – philosophically at least – there’s little value in accepting the “Security as superstition” maxim at face value. Yes, the broad strokes are accurate, but while the idea of safety is something that we’ve constructed with our meaty, inefficient animal brains we’ve also managed to create systems that are more capable of dealing in absolutes. Nobody is going to start declaring Public Key Infrastructure as the greatest invention since fire/the wheel/sliced bread etc, but the fact remains that we live in a world where danger is starting to run on diminishing returns. You can narrow the risks – slice them into thinner swathes than ever before – because now we have better, more finite, stronger tools that we can use to protect ourselves.

These are – as has become abundantly clear over the last twelve months or so – Unprecedented Times. While we’re trotting out tired platitudes I’ll throw “the world is getting smaller” into the ring, because that and the unprecedented-times bit tie in pretty neatly; when we’re able to communicate faster and more completely then our connections contract. They become less nuanced, more immediate, and far, far more polarizing – creating systems so vast that simple fixes are less likely to be attended to and more likely to be overlooked or misunderstood.

Earlier I wrote about Security as an abstract mental model – and I think that’s an important way to consider it. Models are – to my way of thinking – the primary way that we’re able to containerize the outside world and build frames of reference and connections that adequately map our personal constructs of our personal worlds to the reality we actually live in. Both people and organizations exist and integrate with each other by creating and maintaining those models of the world, and with rapid change those are models that have to be updated and checked and refitted on a continual basis – and this applies whether you’re considering correct personal pronoun usage or assessing organizational network weaknesses. The only ways to stay relevant are to be continuously reactive and adaptive in updating and maintaining those models, and attacks like the SolarWinds incident point to bad actors being similarly more determined and focussed.

At the end of the day, the responsibility for your data lies with you and you alone. It’s an uncomfortable truth (after all, it’s much more fun to blame someone else when everything goes horribly wrong) so selecting the right tools and approaches to try to protect that data is something best done carefully and with considered understanding. Your model is never going to be perfect, but the sooner you can accept and internalize that then the sooner you can adopt a critical approach to remedying potential threats.

This is, believe it or not, the busiest part of the year if you’re an IT consultant. There are excellent reasons for this; businesses are generally keen to close out budgets, or make purchases and roll out products prior to the end of the tax year, or even just feel the universal urge to do whatever it takes to tie a neat knot around the year and go into the next one loaded for bear. The practical upshot of that is that I haven’t written anything for this thing for a while because I’ve been far too busy running around and actually working (which is exactly the kind of problem you want to have if you’re me).

Still, I have a running list of things I wanted to touch on because I think they’re interesting and because this blog is as much as anything else a resource that I can go back and look at when I need to remember some piece of syntax that gets shoved out of my aging cranium to make space for something more critical. One of those things concerns my first love (at least in a professional sense), which is homebrew.

(Okay, honorary shout-out to Synology as my other first love. It’s the weirdest, nerdiest form of polygamy.)

Homebrew is fabulous. I like to support it financially when I can because it’s a simple and effective way of putting together tools that enable me to do my job. I mean, sure, there are other ways of building programs and tools that are perfectly functional, but if IT consultants are plumbers then homebrew is an organization that just hands out wrenches for free. You can’t beat that value, and you’d be a fool to try. Still, now and again open-source tools run afoul of the rest of the world, and it can be jarring to reach for a wrench only to find that – against all expectation – it’s not where you left it.

I’m referring in this case to YouTube-dl, and the recent debacle over it’s equally recent removal and reinstatement on GitHub. You can read that link, or I can outline the rough lines of the story, which is pretty simple. YouTube-dl is a tool that you can feed a streaming video URL to, and which will then process that URL to extract the video and audio feeds and download them to your computer. Despite the name it’s a tool that works on, well, basically every service that streams non-DRM encoded video, and while it’s (fairly predictably) used to scrape video content from the internet that providers may not want scraped, it also has a raft of legitimate and fair use applications. I work with educators who’ll use it to pull academically-licensed video down to machines for presentations and research purposes, for example.

Still, the problematic use cases of the tool (notably the bit about being capable of illegally downloading and saving copyrighted music and video) ran afoul of the RIAA, who complained to GitHub that they were hosting a tool that was in contravention of copyright law, and in turn GitHub pulled the tool and left a lot of proverbial plumbers without proverbial wrenches.

Fortunately, all parties saw sense and restored Youtube-dl within days, but during the outage I had to do some very specific poking around about how to find and build the tool from non-GitHub resources, and in turn how to use it to manually select video and audio formats, which turned out to be rather interesting.

As anyone who’s uploaded video to YouTube will tell you, it’s not simply a process of lobbing it a file and then going and having a cup of tea while it puts all the ones and zeroes onto a webpage for your delectation and delight. That’d be convenient, but there’s more to it; YouTube is accessed by all kinds of client computers and devices over all kinds of connections, and as such it likes to have a lot of different versions of those video and audio files to serve out to those computers and devices. After all, if I’m watching a video on my iPhone on an LTE connection and the only video they can send my iPhone is the same full-resolution 4k file they’d send to my desktop wired to fiber then I’d stand in the rain watching the thing spool for a very long time while I asked myself whether I really needed to spend thirty minutes waiting to watch a cat video, and whether I should have considered my life choices with greater attention to time-management and the ownership and use of an umbrella.

Fortunately, YouTube-dl makes it easy to look at all the different versions of audio and video streams associated with a YouTube video, and then allows you to pick and choose which versions you’d like to download. Let’s start with a classic educational staple – Dr. Richard P. Astley’s rendition of the immortal classic “I Shall Never Give You Up.”

The YouTube URL for this is:

If you copy that URL and paste into YouTube-dl while invoking the -F option then you’ll get this impressive looking list:

From looking at that list, we can see that there are four audio-only formats, seventeen video-only formats, and one combo option right at the very end. YouTube takes this menu, looks at your connection and the device you’re using, and then selects the best options from the list, but we can use YouTube-dl to make our own choices by invoking the -f option. Let’s say we want to download the highest-possible quality video file (the 1080p mp4 option – number 137 on the list ) and the worst quality audio file (the 49k webm option – number 249 on the list). To download that using YouTube-dl you’d use the command:

youtube-dl -f 137+249 https://youtu.be/dQw4w9WgXcQ

The output will look something like this:

…et voila – you now have a copy of the file in the home folder on your computer.

All talk of plumbers and nonsense aside, I can kind of see the concern about the use of tools like Youtube-dl. It is, after all, a tool that can be used for both legitimate and illegitimate use alike, and how it’s wielded is largely a matter of personal judgment and policy. On a practical level, I suspect that the prospect of it being used wholesale as a mainstream piracy tool is limited by the fact that unless you want to go spelunking into video and audio formats a default invocation of the command will feed you a pretty good copy of a video that’s really no better than just viewing the content for free on the internet. Further, if you’re of a mind to go digging around and trying to pull down higher-quality files then you’ll still usually end up with a sub-perfect product quality-wise, as well as something that will eat up probably a lot of storage space – in short, there are easier and better ways of getting to content than adopting this as a default part of your arsenal…

I spent most of last weekend in a warehouse in Carpinteria, spouting an ever more specific series of salty oaths and curses.

This isn’t – just so we’re on the same page here – the way that I normally like to spend my weekends. It’s terribly important to maintain a healthy work/life balance (particularly in These Trying Times), so keeping work and personal matters separate is important and a flagpole of mental health, and it’s vital to stay grounded and in touch with the people who are most important to you.

This is by way of saying that when I’m issuing salty oaths and curses on most weekends they are chiefly directed at my family, who are quick and open about returning them in kind.

Still, now and again the nature of honest toil involves going and working on a weekend, which is fine. A lot of substantive IT work gets done at hours when it’s less likely to cause massive disruption. Like most IT consultants, I’m no stranger to walking into a client office at 5pm and walking out at 8am the next morning. Or decamping to an onsite location for a weekend, for that matter. This is the nature of the gig; you can’t make fundamental changes to infrastructure while said infrastructure is being actively… infrastructed. It’s like repairing a car engine while the thing is hauling down the freeway. It can be done, but it’s not going to end well, there are going to be enormously destructive crashes that cost everyone a lot of money and time, and someone’s probably going to end up in the hospital.

So, last weekend should have been pretty straightforward. The migration from the client’s ancient and ailing Mac mini server to a nice, shiny new Synology NAS had been completed without incident – chiefly because Synology makes a solid, well-designed product – and all that was left to do was to install a remote access application on each Mac desktop so that the client could use their cloud-based accounting package. It was a simple matter of installing some applications, doing a little light configuration, then being home in time to sink a couple of cocktails replete in the general glow of a Job Well Done.

Except that, no, it wasn’t a simple matter. The remote access application flatly refused to launch on about half the Desktops for no discernible reason whatsoever. Same hardware, same exact operating system and patches, but while about half of them worked perfectly, the other half not only refused to launch but refused to even bounce in the dock.

This is unusual. Well-written applications either run just fine or give you some kind of polite-if-terse indication why they fail to do so. They don’t as a matter of course just sit there, unresponsive, glowering at you from the Dock while you wrack your brain and try and work out what’s wrong. A peruse of the Console.app showed an error message thus:

Termination Reason: Namespace CODESIGNING, Code 0x1

…which is the kind of thing that makes your blood run cold once you figure out what it means. Essentially, the program won’t run because the OS has decided that it either isn’t signed (see last week’s article on Gatekeeper) or because its signature is invalid. Downloading a fresh copy of the app from the Mac App Store made no difference, which pointed me in the direction of the OS thinking that the signature was invalid because anything you download from the App Store is, by the nature of the transaction, signed.

So, how to fix?

My first thought was that maybe – somehow – Gatekeeper on those Macs was somehow at fault. Other downloaded apps worked just fine, though, which rather scuppered that theory. My second thought was that maybe there was some issue with the app being flagged as damaged by the Macs, so I tried manually adding the apps to quarantine using xattr, like so:

sudo xattr -rd com.apple.quarantine /Applications/Microsoft\ Remote\ Desktop.app

(Spoiler – the app was Microsoft Remote Desktop).

Finally, I stumbled across the codesign command (installed as part of Xcode Command-Line tools). I’d run into it before while tinkering around with homebrew, and on reading the man page found that it had options for removing, altering, and replacing existing code signatures. Downloading the Xcode Command-Line tools can be done from the Terminal.app like so:

sudo xcode-select --install

The first move was to remove the existing code signature:

sudo codesign --force --deep --remove-signature - /Applications/Microsoft\ Remote\ Desktop.app

Next, now that the existing signature has been removed, we can re-sign the app (using the --force flag to actually replace the existing signature and --deep flag to ensure that any sub-hosted code signatures are also replaced) by issuing the following command:

sudo codesign --force --deep --sign - /Applications/Microsoft\ Remote\ Desktop.app

Thankfully, this worked like a charm, allowing all parties to return to their regularly scheduled weekend drinking. I mean families. Right? Right.