Brewfile maintenance

Not a terribly catchy title, but then again it’s not a terribly catchy subject. Still, a useful thing to have up your sleeve and incorporate into your regularly-scheduled maintenance. You are doing regularly-scheduled maintenance on your computer, right? Not just letting it be and then being surprised when it transpires that your sole copy of The Great American Novel™ disappears one day and you discover that the last backup took place sometime last June? Thought so. We’re all terribly responsible.

I’m a big fan of homebrew because I’m a sucker for package managers and small, superb little tools that make your life easier in a million ways (provided that you’re passably comfortable with using the Terminal.app). However, now and again I have to switch machines or upgrade/reinstall, and it’s a drag to have to remember all the stuff I’ve installed onto one machine and then go and find it all and reinstall it again on another machine. Yes, it’s not what you might call an everyday occurrence, but it happens from time to time and is – for lack of a better catchy epithet – a total bummer

Fortunately, you can mitigate some (if not all) of that by using a brewfile to go and build a list of everything you have on your computer and then format that in a file that homebrew can read and use to reinstall everything. And it’s ludicrously simple to do, thus:

• Install the Homebrew bundle tap: brew tap Homebrew/bundle

• Run the bundle command to dump a formatted list of all your homebrew packages into a brewfile: brew bundle dump

This will go and create a file called “brewfile” at the root of your home directory, and opening that file will reveal something like this:

There are many like it, but this brewfile is mine.

Now, having that brewfile on your computer is great, but in the case where you’d want to restore that onto a new computer then there’s no guarantee that your older computer will be accessible (or even functional), so having the file somewhere else seems like a good idea. If you run the brew bundle dump command a second time it’ll error out because the file already exists, so I like to combine it with a mv command to create the file where it expects it to be (in my home folder) and then move it to my Dropbox, thus:

brew bundle dump; mv ~/Brewfile ~/Dropbox/

Because the mv command is moderately intelligent it will overwrite any existing file with a new copy, thus saving a lot of tiresome hunting and deleting every time you want to save a new copy.

Finally, I automate the process by creating an alias in my .zprofile to do a lot of the tedious typing for me:

alias brewfile='brew bundle dump; mv ~/Brewfile ~/Dropbox/'

Great! But what if I want to also put a copy of my .zprofile to Dropbox as well? I can’t use the mv command for that because, well, I need my .zprofile where it is and not solely living in Dropbox where it can’t do me any good. All things are fixable through the mercy of hideously clunky shell commands, so I cobbled together this monstrosity that seems to do the job nicely:

rm ~/Brewfile; brew bundle dump; cp ~/Brewfile ~/Dropbox/; cp ~/.zprofile ~/Dropbox/zprofile

You can also make an alias of this roiling horror in your .zprofile if you can stand it, like so:

alias roilinghorror='rm ~/Brewfile; brew bundle dump; cp ~/Brewfile ~/Dropbox/; cp ~/.zprofile ~/Dropbox/zprofile'

Using the brewfile to restore your packages onto a new machine is trivially simple; just install homebrew, then brew tap Homebrew/bundle again to get the bundle package onto your machine, then finally put your saved brewfile into the root of your home folder (where bundle expects it to be) and run brew bundle install – depending on all the stuff you have on there it can take a while (and if it’s trying to pull down Xcode and a bunch of Apple productivity apps then I mean a while).

This approach isn’t what you’d call pretty, but it’ll get the job done. And if that’s not the definition of using UNIX packages then I don’t know what is.

Variables, operators, scripts and Jamf Pro.

Yes, this is going to be a tiresome shell script post, but the thing about tiresome shell script posts tend to be actually useful things if you’re looking for a quick way of reminding yourself about the quickest, easiest and most efficient way of performing some simple but crucial task without a lot of pointing and clicking (and, better yet, without having to actually do any of that at all). After all, this blog is squarely pitched at people like me who enjoy shell scripting but got their degrees in Anthropology and had to pick this stuff as they went along so there’s probably some value in it.

I greatly enjoy Jamf Pro, and if you’re looking for a solution to implement or administer a whole raft of computer and devices then you could a) do far worse than use what is essentially the premier product for doing that, and b) give me a call. Rates are reasonable, operators standing by etc etc.

One of the fun things about Jamf Pro is that there are a couple of different ways of sending a script to a client machine without much (if any) input from the user, who probably has better things to do with his/her/their time. The best way is by setting an Extension Attribute – you write a script (or use/customize one of the hundreds of scripts or templates built into Jamf Pro or posted on Jamf Nation) to run a script against a macOS computer on check-in. In plain English, the Jamf Binary that gets installed on your client computer when you setup Jamf sits quietly in the background and occasionally phones home to the Jamf Server to let the server know that all is well, and to ask if there are any messages for it to look at. When it checks in then the Jamf Server can send down policies and profiles to restrict or allow the client computer to do all kinds of things, and in addition can run a shell script on the computer as root.

Which is very, very handy, because when you’re trying to administer computers and you need to do something substantive to those computers via the command line then you need to be able to do so as root, and chances are that a good number of your end users are either going to look askance at plugging in their passwords into odd screens or are running non-admin accounts and just plain don’t have useful passwords to plug in there. And also very handy because you can take the output of those scripts and put them into Jamf Pro by setting an Extension Attribute and throwing the result into a Smart Computer Group and in turn putting that onto your Dashboard.

In plain English – this is a thing that Jamf Pro puts on your computer that can report back all kinds of custom, non-standard but highly useful information, such as whether your laptop battery health has dipped below acceptable levels, whether your hard drive has been throwing up errors, or if your computer hasn’t backed up in a week; all useful things that someone should know about, and all indicative of a need for urgent attention and service. Further, all things that you – as the end user – might just plain not notice until it’s far, far too late.

Extension Attributes can handle full-size, complex, heavy duty scripts. You can see some examples here. The other place you can use shell scripts in Jamf Pro is in the Files and Processes field in Policies, and that’s where the operators come into play.

See, the idea is that you throw simple, single-command one-shot scripts into that field so that you can accomplish quick, basic tasks – with root permissions – on the destination Mac. Which is great if you want to, say, set the NTP time server or point the computer at an alternate Software Update Server.

But what if you want to put something a little more complex in there and string a couple of commands together? Well, it’s not widely and loudly talked about but you are able to do that by stringing your commands together using an operator like &&, || or ;.

A very quick word or two about && and || follows:

&& works as a logical AND statement – requiring all conditions to be true. An example of this would be something like:

echo 'Hello World' && echo 'Goodbye Cruel World'

Which would give you an output of

Hello World

Goodbye Cruel World

|| works as a logical OR statement – requiring only one condition to be true, thus:

echo 'Hello World' || echo 'Goodbye Cruel World'

Which would give you an output of

Hello World

Back to the good stuff! Let’s say that I wanted to be able to construct a policy that would change the hostname of a client computer to match it’s hardware serial number. There are reasons not to do that (chiefly that it looks messy and that end users might find it confusing and impersonal), but equally if you’re working in a lab with a lot of identical workstations then using that as a demarcator might be practical. There are two steps to making this happen.

First, you have to find the serial number of the computer. This part is relatively straightforward because all you really need to do is to go talk to the I/O Kit Registry (ioreg) command and tell it to go search through the million billion things it can look at and pull out the entry for the computer’s serial number, thus:

ioreg -c "IOPlatformExpertDevice" | awk -F '"' '/IOPlatformSerialNumber/ {print $4}'

Go ahead and drop that into your Terminal and hit return, and it’ll throw your serial number back at you. Great. Next you’ll need a command to go and set the hostname of the computer. We’ll hit up the System Configuration Utility command (scutil), thus:

sudo scutil --set HostName insertSnappyNewHostnameHere

Finally, we’ll need to stick these two crazy kids together by getting ioreg to return the serial number, setting that as a variable, and then passing that variable over to scutil, like so:

myVar=$(ioreg -c "IOPlatformExpertDevice" | awk -F '"' '/IOPlatformSerialNumber/ {print $4}'); sudo scutil --set HostName $myVar

What we’ve done here is glue those two commands together with a ; – but if the first command errored out or failed or some new update renamed or borked something in ioreg then the latter command would simply fail without giving you much indication that anything had gone wrong. The good news is that with this particular command the worst that could happen would be inaction; without relevant input from the first command to the second then the computer would just sit there with it’s original hostname until told otherwise, and thanks to the magical healing powers of Jamf Pro you’d be able to make a nice, neat, very visible smart computer group on its dashboard so that you’d know which computers had the command failed and required additional work or laying on of hands…

Unlocking your laptop with your watch is a terrible idea.

Don’t get me wrong; I love my MacBook Pro and I love my Apple Watch. I was a first-adopter of the original Series 0 watch and wore it religiously until the battery life dropped to an hour or two and then the battery itself decided that after four years of service it was going to swell to the point that it popped the screen off of the thing, forcing me to go out and buy a new one. And by “forcing” I mean enabling, and by “enabling” I mean giving me the slight excuse I needed to go buy another thing.

My current Apple Watch is a Series 3 Space Grey Aluminum. I also have a stainless steel Series 3 that’s sitting in a drawer and that I’ll be trading in when I get round to it; it looks great and feels very solid, but that sucker is heavy to the point that when I put the aluminum one on I wonder if I’ve suddenly become a lot stronger than I thought I was because everything weighs half as much. I love my Apple Watch and it’s basically become indispensable in a world where I shove my phone in my bag most of the time and rely on the thing on my wrist to tell me what time it is, who’s calling me, and how little I’m working out. It’s an amazing gadget, and one of the things it does best is be a proxy for an iPhone. Which is a curse and a blessing when it comes to things like, say, authentication.

The idea goes something like this: if your iPhone can be unlocked by biometric data that positively identifies you as the owner of the device (TouchID or FaceID), then your watch talks to your iPhone and decides that it’s okay for it to unlock itself based off of that lower tier of authentication. And then, if your watch knows that you’re you because your iPhone tells it that’s the case, then can’t the watch itself then act as a proxy form of authentication for your computer?

I mean, it makes sense in a very practical way. Apple puts reasonable protections in place – the iCloud account you’re using has to have two-factor authentication set up – and it all seems pretty clever – once you get past the idea that your computer identifies you from your watch which identifies you from your iPhone which identifies you from your face or fingerprint, that is. It smacks of a bunch of kids standing on each others’ shoulders wearing an enormous overcoat to get into an R-rated movie, but nonetheless you can’t really fault the basic core of the idea. And really, it works well in reality too; Bluetooth Low Energy (BLE) does its job the way you expect it will.

This might be a good time and place to dip – in a very cursory fashion – into what Bluetooth actually is. Which is, confusingly, two entirely different things that don’t talk to each other. What we’ve traditionally considered as Bluetooth is Bluetooth “Classic”. It enjoys a robust data rate that allows you to transmit and receive data at a high rate, which makes it perfect for applications like media streaming to speakers – it ensures a constant flow of data between source and destination at distances up to 100 meters on the 2.4GHz spectrum. The other technology is Bluetooth Low Energy (or BLE for those of us who don’t want to type that out every time), which while it uses the same frequency and enjoys the same (if not greater range) isn’t designed for the kind of throughput you get from Bluetooth Classic. BLE is used in industries and applications where connectivity and small data transfers are preferred, which at the moment mostly means wearables and thus mostly means Apple Watches. While BLE technically enjoys the same range as Bluetooth Classic the proximity-sensing function of it is active within a much shorter range (about 1-2 meters).

In the case of my 16″ MacBook Pro and my Series 3 watch, it’s exactly 60″. I know this because I spent an enjoyable afternoon with a tape measure, a watch, a laptop, and a cat who tried to sit on all three at some point. With the “Unlock with Apple Watch” option checked in the Security Preference Pane I was able to unlock the laptop with the watch reliably at that distance before hitting the proverbial wall. That’s five feet from the laptop, and common sense would dictate that if you’re five feet’s worth of lunging distance from your computer then you’re probably going to be able to stop some miscreant from getting on there and causing much havoc.

In fact, it’s almost a certainty that you’ll be able to do that. Especially if your Mac is a desktop, as desktops are notoriously difficult to pick up with one hand and walk away with. You can probably see where I’m going with this; while you can bring your Apple Watch into close proximity with your laptop and unlock your way in you can also bring your laptop into close proximity with your watch and achieve the same result. And I know this because I’ve done it.

Just so we’re clear: I didn’t steal anyone’s laptop. In fact, I asked a friend of mine who works in a coffee shop to wait for me to go to the restroom, pick up my MacBook Pro, walk up to the restroom door and then see if it would unlock. He did, and it did, and if I’d been sans pants in a locked room then he could have escaped out of the back door with my unlocked laptop containing a ton of privileged data. As it is he charged me five dollars for two shots of espresso, so it’s not like the man is a saint.

Which brings me to the crux of the matter; you have to exhibit a little common sense when it comes to matters of authentication and access. The use case of a laptop wielding maniac loitering outside a restroom is a statistical long shot, but in an office with a ton of people wandering around it’s not improbable that this kind of attack could be carried off pretty efficiently…

Speedtest from the Command Line.

As a person who fires up the Speedtest site and/or app somewhere between three and about eight hundred times a week, it is incalculably negligent of me not to have know that there’s a way of doing this from the Terminal.

“Fine,” I hear you ask. “That’s great, but why should anyone have to go tinkering around with the Terminal when there’s a browser right there that they probably have open already?

That’s an excellent question, and the answer is that using Speedtest from the browser is pretty awful. I mean it looks like this for goodness sakes:

Actual IP address obscured via VPN. Nice try, h@XXors!

I don’t need to see a lot of adverts, and I also don’t want to be mucking around with ad blocking software and tweaking hosts files and whatnot. Yes, there are ways to deal with this kind of annoyance, but you often end up with a different set of annoyances that are really no better in terms of your general mental health and not-grinding-your-molars-into-powder. This is much better, though:

100% improved by green text and fewer mortgage refinancing adverts.

It’s fabulously easy to do, and huge kudos to the good people at Ookla for not only building a tool to do this but also making it downloadable as a binary and also installable via homebrew using these three, simple commands:

$ brew tap teamookla/speedtest

$ brew update

$ brew install speedtest --force

When you first run it you’ll have to agree to their licensing terms, but on the assumption that those are acceptable to you then I encourage you to go ahead and install the thing. Your blood pressure levels will probably thank you.

Update: It gets better! Hitting speedtest -help gets you all manner of goodies that you don’t get with the regular, boring web version. Being able to specify the interface you want to test on is pretty huge, and probably extremely useful for network troubleshooting…

Options abound!

It’s The End Of The World As We Know It (but I feel… okay?)

I – as I’ve probably noted elsewhere on this blog – am rapidly becoming terribly old. Well, not terribly old; it seems to be a convention of the human condition that we shift the goalposts on a rolling basis, and while I felt like the weight of adulthood had settled firmly on my shoulders in my late-twenties I’m now willing to accommodate a world view where forty-seven doesn’t seem so bad.

Still, age is all in the mind. And the knees. Well, actually it’s more tangibly a knee-based phenomenon; you can feel as vigorous and sharp as you ever did but then you stand up and your joints make alarming gronking sounds and you start to wonder how long before the reaper starts pencilling you in on his rounds.

All this homespun wisdom is a preamble to the meat of this piece, which is about the state of malware on macOS. Oh, you didn’t get that from all the blathering about knees? That’s fair, I suppose; the occasion of my impending decrepitude is more about being old enough to remember when Macs got viruses, which was a very, very long time ago.

It’s worth spending a moment digging into what viruses actually are and the difference between viruses and malware. These seem to be used interchangeably, but they’re distinct and very different animals and the methods in which they’re employed and protected against are also distinct.

Viruses are computer programs that self-replicate when executed, modifying other pieces of code (executables and files/data) to incorporate themselves so that they can spread and infect other computers. If you make an exception for Microsoft Word macro viruses (which I do because they don’t do code-injection into anything and your Mac can only be a carrier) then there are no macOS viruses. That’s right, I’m planting my flag squarely in “none” and I’m holding that ground. If you disagree then, well, you and I are going to have to go outside and fight. And I’m going to take off my shirt and fight and nobody wants to see that.

(Sidebar: I wear glasses and have bad knees and a doctors note that stipulates no brawling in the street.)

The Mac used to have viruses, back pre-OS X. Some nasty ones, too, but virus software is just that – software – and if your modus operandi was to write code to infect the maximum number of machines in the 1990’s and 2000’s then your best bet was to go and write viruses for Windows. The irony that developers wouldn’t write viruses for Macs for the same reason that they wouldn’t write a lot of other software for Macs is not lost on me.

Malware is a wider net, and were it not for the specific mechanic of viruses (and the fact that people were talking about computer viruses decades before anyone coined the phrase “Malware”) then I’d be including viruses in that net. Most people do, and I agree that while that’s technically accurate in that a virus is a piece of software that runs on your computer and does Something Bad what we think of as Malware (or Adware, which is basically just a flavor of Malware) in this day and age tends to require human input. Generally speaking you have to perform an action to enable it; it’s the modern-day equivalent of having to invite the Vampire into your home before it can eat you.

Fortunately, Apple has done a lot to protect macOS. So much, in fact, that if we take a step out of the world of breathless hand-wringing and pause for a brief moment of sanity it becomes apparent that macOS malware is a fringe problem. A couple of weeks back the nice folks at Malwarebytes got a lot of press by pointing out that macOS Malware attacks are up disproportionately compared with Windows/Android attacks, and this is in fact broadly accurate. What a lot of people seem to have conveniently side-stepped is that you can shoot arrows at a brick wall all day long and not manage to do a lot of damage. Yes, macOS Malware attacks are up, but actual, real-world damage? Not a lot of significant difference there.

Why? My theory is that the point where macOS was insignificant enough to not merit attention and the point in which Apple introduced protections like GateKeeper (and now code notarization) was less a point and more an overlap. Further, it’s worth pointing out that with some elementary training and an ounce of common sense you can probably roll around in Malware all day long and come away smelling of roses. Let’s use the miracle of educational jpegs to illustrate this, shall we?

This looks scary, no?

The fine folks at Kaspersky published this graphic back in January, showing that the Shlayer Trojan has an astonishing 29.28% share of attacks against macOS users. That’s clearly a bad thing and makes for great copy if you’re a company that makes anti-virus/anti-malware software, but the one thing that Shlayer has in common with every single other item on that list (and in fact every single other piece of malware for the Mac) is that it requires the following three things:

First, it requires you to download a piece of software from a suspicious website.

Second, it requires you to ignore the warnings that Apple gives you about installing unsigned software from an unknown source.

Third, it requires you to install that software by giving it your username and password – effectively authorizing the code to run on your computer.

That’s three break points that you’re required to sail through without considering your actions. It’s easy to point fingers at end-users and decide that that kind of negligence is inexcusable, but that’s childish behavior, lazy, reductive thinking and a quick and easy way to pass blame around; while finding who is to blame for something is always fun and enjoyable it’s ultimately not as important or useful as figuring out the explanation for the process of what went wrong.

So, let’s talk about process and education and best practices for not infecting your computer with Coronavirus, burning your house down and generally ruining your life. Those three break points are great places to start, and we’ll hit them with three actions; Evaluation, Execution and Consideration

Evaluation – Why do you need that piece of software? That browser extension? That utility that will make your Mac Run Faster And Better And Free Up Memory? What issue are you trying to correct? Recognizing that bad actors are perfectly willing to push solutions to problems that may (or may not) exist is a solid first step, and one that I encourage people to undertake.

I’ll go one further: pretty much every “Utility” “designed” to “make your Mac Faster” is either a con or outright lie. The vast bulk of them do nothing, and the few that actually do anything at all just run shell scripts to do the kind of periodic self-maintenance that your Mac does by itself without requiring stupid, shoddily-designed third party nonsense. A lot of these are malware, and the ones that aren’t are dumb and bad and designed to prey on the fears and concerns of people who don’t have the time or inclination to think about things like how your computer does periodic self-maintenance. You don’t need an app to free up memory or defrag your drive. Those are things that your computer does all by itself, or else there are sensible, grown-up reasons why it doesn’t do them at all. “Clearing Virtual Memory” sounds great, but when it means that your computer has to go and rebuild the caches it has in place and you’ve actually made your computer slower and less responsive then it doesn’t sound so great after all.

As a person who makes their living charging people for the privilege of having me help them with their macOS/iOS/network issues it may sound self-serving, but if you’re having an issue with your computer then call someone professional and ask their opinion. Or at least do a little research, and recognize that you’re not alone in figuring this stuff out. Not to be too pay-no-attention-to-the-man-behind-the-curtain about this, but malware authors don’t issue press releases and when a new piece of malware hits. We IT professionals are not notified in advance. We have groups and bulletin boards and mailing lists that we subscribe to where other professionals find weird things and report them and we figure stuff out. We ask questions and raise concerns and identify threats as a group. The second that some new, weird utility called “FixMyMacProFast” pops up you can bet someone’s looking at it with a long, critical eye, and if it’s problematic then word gets out fast. At the very least, google things before you download them and consider your sources.

So, call your IT person. There’s a decent chance that he/she/they won’t bill you for it, and they’ll be a lot happier about nipping something in the bud for free than dealing with a roiling nightmare and sleepless nights on the company dime.

Execution – This is your second break point. The moment that you’ve downloaded the new thing™ and you’re at the precipice of installing it. Before you go ahead, Gatekeeper will step in and your Mac will throw up a warning if the thing isn’t signed by a developer certificate, thus:

Names blanked out to protect the innocent.

Your computer is literally telling you “Hey, I can’t guarantee that this isn’t going to do something really, really bad. Are you completely sure that you want to do this? I mean, really?”

At this point you can’t open the thing, except by hitting “OK” and then either adjusting your Gatekeeper preferences or by right clicking on the installer and explicitly telling your Mac to open it. Depending on how you look at it that’s either one or two break points at which you should be considering the provenance of what you’re about to put on your computer.

Consideration – This is your last chance. Before the executable runs it will probably want your username and password, so take a breath and think about what that means. This is a potentially unknown actor on your computer that Apple has specifically warned you isn’t necessarily legitimate, and that you’ve had to undertake extra steps to allow in, and now it wants your credentials – the same credentials used for, say, your Keychain. Where you probably keep a lot of encrypted data that you wouldn’t necessarily want accessed by anyone else. Passwords for email. Web pages. Encrypted notes. Banking information. Apple has included all kinds of security in the OS and in the hardware of the device itself, but that’s largely for naught if you’re going to hold the door open and freely hand out your private information. Consider this move very carefully.

The only thing that I really took away from my long-ago degree in Anthropology was the lesson that people – by and large – aren’t dumb. We may not understand why our fellow man believes something or acts in a certain way, but it’s a solid bet that they’re doing it for what they believe to be a damn good reason. Cargo cultists only look misguided and ill-informed from the outside; step in their shoes and look at their perspective and it’s very difficult to announce that their actions are illogical.

People tend to act in ways that make sense to them and seem the most logical and beneficial using the information on hand, and that’s the only vector that malware authors have to exploit. Further, anti-Malware/anti-Virus companies have a vested interest in building a little healthy hysteria up because they have targets and sales goals and costs, and if you’re a fire-extinguisher salesman then yelling “Fire” in a crowded theater makes good sense if you have a stall set up in the lobby. The middle line between actual and perceived threat is something that should be clearly identified and kept in perspective; if you want to protect yourself or your organization against attack then it’s vital to stay abreast of the dangers, enact reasonable protections and educate users on the threats that they’re going to face. There are great tools built into macOS, but tools are only as good as the hands that wield them…

Vandalism != Hacking.

There’s a certain type of person – and I’m sure everyone knows someone like this – that deals with you having something they don’t by trashing that thing. “Oh, you have the iPhone 11 Pro? That’s nice, bro, but the Pixel camera is better.” “New Mac Pro? Apple hardware is way overpriced. You got ripped off, idiot.” “Nice car? Yeah, well my Corolla has much better gas mileage. And anyway, only morons buy domestic.”

There’s no point and zero profit engaging with these people, and the older I get the easier it is to step back, dip into a little empathy, and realize that there’s a lot of complex emotional baggage being shunted around there that has a lot to do with need and want and envy and self-worth, and that someone disapproving of your choices is in no way an invalidation of those choices. And really, most of the time the people who engage with you like this aren’t terrible people. Let it go. Move on with your day. Life’s too short.

The exception I’ll make – the thing that causes me to frown and shake my head and engage – is inaccuracy and flat-out manipulation of the facts. Which brings me to the gloating text message I got this morning from a friend, linking me to this Technology Review article about how Teslas can be hacked:

Hackers have manipulated multiple Tesla cars into speeding up by 50 miles per hour. The researchers fooled the car’s Mobileye EyeQ3 camera system by subtly altering a speed limit sign on the side of a road in a way that a person driving by would almost never notice.

Go on, read the article if you’re interested, but if you’re not then I’ll give you the tl;dr – notably that “hackers” discovered that if you alter a speed limit road sign then the camera in the Tesla will read a 35 mph speed limit as an 85 mph speed limit, and when in Autopilot mode will accelerate as appropriate to hit that speed limit (assuming that there are no other vehicles on the road). Said “Hackers” were in the employ of… wait for it… McAfee. Who I’m sure are smart and law-abiding folks, but my personal opinion is that if you’re looking for Chicken Little-types for the modern age then antivirus companies are right at the top of the heap. When your entire business depends on scaring people into using your product and trying to get them to distrust technology then it’s hard to wave a flag of impartiality with this kind of stuff.

Still, this is bad. But it’s not hacking. Hacking would be in directly compromising the computer system in the car, allowing a bad actor access to the mechanisms of control that govern the way the car behaves. Altering a road sign is vandalism, pure and simple. The moment you’re grabbing paint and tape and tinkering around with something by the side of the road is the moment that you’re compromising the world at large, not just one device. If I paint a perfect counterfeit “STOP” sign at the intersection near my house then the entities in charge of the locomotion of the vehicles that approach that sign – human or computer alike – are going to stop.

Now, this whole thing on my end might smack of a certain degree of Get-Off-My-Lawniness, but the fact remains that words have a function and a duty, and as cloying and picayune as the distinction may seem to be it’s nevertheless one worth observing. Hacking is an involved task – sometimes noble, sometimes criminal – but a deliberate and calculated action requiring forethought and execution and carried out with specific intent.

This, though? This is just criminally, irresponsibly dumb; an act that proves… nothing. There’s nothing intelligent or thought-provoking in it, and nothing that indicates a deficiency in the system that is unique and peculiar to that system. It’s not a hack; at best it’s ruinously irresponsible fear-mongering based on a tortured, twisted version of the truth.

At worst? It’s a fiction based on a lie.

MAC OS X AND TESLA API (PT. 3)

Well, technically that should read “macOS and Tesla PT.3” because it’s been a while since I last wrote about this and times change.

For one thing, I used to have a Model S, and while that was a wonderful thing it had certain downsides; notably the woeful deficiencies in places to put things, and by things I mean cups. Yes, I got rid of my electric dream machine because it had too few cupholders and I moved to Santa Barbara from Washington State because of all the rain. Imagine a shallow and petty reason to make ruinously expensive life decisions, and rest assured that when you’re looking for some sap to make those dreams come true then I’m the man for the job.

I replaced the Model S with a Model 3, which has lots of cupholders and many other places to put things besides, and is a little shorter and narrower and can be parked by a human being without the need of tugboats or the kind of steely-eyed determination you expect from the sort of people who drive massive tankers through the Panama Canal every day, effortlessly moving between locks while leaving a credit card’s worth of space between the paint job and the concrete walls. I could rave about this car all day, but I’ll wrap this bit up quick by telling you that I bought it from a nice young man who used words like “bro” and “sweet” and “nodoubtnodoubt” and that driving the car is like driving a bicep. It’s solid and planted and capable-feeling and you drive around all day doing the things one does in cars when one is an enormous white man heading into middle age (being mildly concerned by the passage of time and the nature of mortality, wondering what you’re going to make for dinner, whether the amount of hair you pulled out of the shower means you should call a plumber or start worrying about whether you’re developing male pattern baldness). And then, like an unthinking fool, you mash the accelerator and start gibbering and screaming like a frightened ape in a lightning storm.

The storage bins between the seats are TARDIS-like and contain more space than they reasonably should. You merely touch them and then they open, and then you touch them again to close them. If you try and close them too hard then they bounce helpfully open again; repeat this process too often and the car bongs at you discretely and puts a notification up on the screen to the effect that You’re Closing The Door Too Hard, and also Please Stop That. Chastened, you learn your lesson.

It does everything better than the Model S except for one thing; the old way of connecting your computer to your car was lovely and only moderately impossible, and the new way of doing things is a headache.

At some point Tesla decided that OAuth was better than just sending your username and password in cleartext over the internet, which is generally a bad idea and more particularly one when said username and password allows the person who has it to unlock your car, get in, and drive it away without comment. Switching to the new way of doing things has managed to break the old teslams solution pretty comprehensively, and the replacement for it – teslajs – fails spectacularly to do anything except send me harsh notes to the effect that it can’t install things that it has in fact installed, and then compounds that by utterly failing to do anything useful whatsoever.

So instead, I’ve been tinkering around with Nikola. It’s a prebuilt binary that allows you to do most of the stuff you used to be able to do with the old teslams commands but is now all nicely wrapped up in a convenient package that doesn’t make you want to pull your hair out in chunks and thus exacerbate the kinds cranial-related problems you think about while driving.

As of right now teslajs doesn’t work, but despite how lovely Nikola is I rather miss having shell commands I can throw into the Terminal to quickly pull up data about my car. Hopefully I’ll have a little time down the road to bang my head about this. Who knows, maybe there’ll be a fourth update in a year or two…

Fortune

My last post was pretty serious. Not that that is a bad thing; I tend to skew optimistic and frivolous, but it’s nice to get the occasional email about something more substantive. So, with that in mind I’m flipping back over to fun and useless to this one.

Fortune is something I put on every new machine. It has absolutely no functional usage other than giving me something to help me focus and relax, which is – in the grand scheme of things – actually pretty useful.

So, what is fortune? Well, I’m glad you asked. Fortune is a command-line utility that prints out a short or pithy phrase into standard output from a prewritten file. The fortune command comes with a bunch of these, but you can also write your own, and that’s a good thing as a lot of the pre-included fortunes are either obscure, deeply-ingrained programming or pythonesque jokes, or (admittedly more occasionally) the kind of thing regarded as very funny in 1994 and now deeply, deeply problematic in 2020.

The first step to getting it on your Mac is to install it via your package manager of choice, which in my case is homebrew. The command really couldn’t be easier – just type in brew install fortune.

Homebrew puts fortune in /usr/local/Cellar/fortune, and from there you can get to the fortune files by further navigating through 9708/share/games/fortunes. By default, fortune will pull a random fortune file and quote every time it’s invoked, and each fortune file has an associated data file with it with the .dat suffix.

A fortune file is really just a plaintext file where each quote is separated by a % character, thus:

Depend on the rabbit's foot if you will, but remember, it didn't help
the rabbit.
- R.E. Shay
%
Either I'm dead or my watch has stopped.
- Groucho Marx's last words
%
Happiness is having a scratch for every itch.
- Ogden Nash

You’re responsible for cherry-picking your own cute quotes from the existing fortune files, the internet, or modern life at large. Once you have your quotes, save them into a file called… well, anything you like, really. The fortune command just looks in the fortunes directory for correctly-formatted text files paired with a same-name data file, but I call mine “fortunes” because it’s pithy and to the point and easy to remember.

Take the existing fortune files that are installed by the command and either move them to a different directory/subdirectory or flat out toss them out. The case for the former is if you want to go poke around them at some point for additional quotes, but I’ve been down that road and saved the two dozen I like to my fortunes text file already, so I trend toward the latter strategy. Copy your new fortunes file into the fortunes directory and go jump into the Terminal to make the magic work.

Firstly, you’ll need to lose any existing file type suffix on that fortunes file you just made. The process of making a fortune data file looks for a simple, flat text file and not one with .doc or .txt or the equivalent on the end, so do the following:

Change directory to the fortunes directory –

cd /usr/local/Cellar/fortune/9708/share/games/fortunes

Once in that directory, list the existing files with ls -al, and use the mv command to rename your plaintext file to something suffix-free (so if your file is called fortunes.txt then you’ll rename it by issuing the command mv fortunes.txt fortunes).

Next, you’ll need to create the data file for your new fortunes file. We use the strfile command for that; strfile creates a data file from your fortunes file that contains a header and table of file offsets so that the fortune command can randomly pick a quote from a list separated by “%” signs. As we’re in /usr you’ll have to issue the command via sudo, thus:

sudo strfile fortunes

Once the command has run you’ll see both “fortunes” and “fortunes.dat” in the fortunes directory, and your work is done. Close the Terminal, reopen it, and type in fortune, thus:

Wise words.

“You take care of your tools, your tools take care of you.”

I love The Expanse. If you’re looking for solid science fiction that invests heavily in world-building and doesn’t resort to ludicrous, flow-breaking space magic nonsense then you can’t go far wrong with a fictional world comprised of people doing what it is that people do best: trying to get by.

Life in space is allegorically like life in the modern world. You have limited resources that have to be inventively and creatively used, and there’s a clear and pragmatic need for the kind of muscular morality that actually makes the world work. Don’t mess with the air and water, recognize that the people you work with (whether you love or hate them) are functionally indispensable and should be protected, and maintain your tools. Sound advice.

It’s the latter that I’m talking about today, though. There’s a character in the books – a phlegmatically amoral psychopath who unaccountably seems to be one of the good guys – who repeats that maxim (or variations of it) at various points, using downtime to disassemble, clean and check tools and equipment that are vital to his job. As maxims go, it’s a good one, and one that I have pinned as a geeklet on my desktop, thus:

Words to live by…

In a pragmatic, actual sense there’s a lot to be gained by making this punchy quote into something you can actually implement provided you take the time to think about what needs to be done, take the time to do it, build a solid routine and invest time and resources in carrying it out. This applies to anyone who uses their Mac (or really any computer) for something indispensable, whether it’s one iMac or Mac mini that sits on your desk for emails or it’s a Mac Pro stuffed to the gills with upgrades that you use as an Xcode build monster.

Taking the time to think about what needs to be done.

Block out an hour. Quit email and any messaging apps. Put your phone on Do Not Disturb. Get your non-alcoholic beverage of choice, sit down, and really consider the machine in front of you. What do you use it for? What are the apps and utilities that you crucially rely on? Has anything been acting up of late? Is everything backed up, patched and updated?

You get the idea. Consider the lump of glass, metal and plastic in front of you and then imagine what your next steps would be if it suddenly and mysteriously went away. Run through worst-case scenarios. What would you need to have on hand if you woke up one day and found your MacBook so broken that the only logical move was to go and buy another one? What solutions and strategies should you be thinking about and investing in? Switching things around – what do you not use your computer for? What applications or tools or data do you have on there that you no longer want or need?

I have a friend who periodically clears out her workspace by assessing each object and asking whether it’s something to keep, put in storage, or throw away. Those are brutally broad categories, but effective nonetheless; something you don’t use every day can either be thrown out or cleared away to free up space and resources, and there’s no shame involved in whichever option she chooses. The trick isn’t in making ruthless decisions about paring away the tools and data you need; instead it’s being ruthless about executing those decisions. That old piece of software or utility you’ve kept around for a decade and resisted upgrading? Keep it! Those old notes that you might some day need to dip into? Keep them or file them away somewhere safe. The pre-installed copy of Garageband with its attendant huge libraries? Pft. Throw it out.

Taking the time to do it.

Santa Barbara has had a pretty terrible time of it recently. I can’t complain because I live about as far toward the edge of the world as possible and because fires and floods would have to pretty much take out the entirety of Santa Barbara and much of Goleta before they arrived on my doorstep, but I’m the lucky one. I had clients lose their computers, hard drives, photographs, personal documents, homes and everything they’ve ever owned, made, worked on or created in their lives in the floods that came after the Thomas fire. That kind of loss – the sheer breadth of it – is overwhelming and almost incomprehensible; to lose everything in an instant and still have to count yourself as one of the lucky ones. And then, on top of that, I had a family member die unexpectedly in the last year in media res, leaving behind a broken iPhone and locked PC and no accessible backups that would help us figure out their tangled finances and byzantine business dealings. It sounds facetious and we’re all sick of hearing it, but seriously; back up your data. Terrible things can (and do) actually happen, and you literally never know when your number is going to be up. Have backups and a plan, and if you’re like me have an old MacBook Air and all the chargers and dongles you’d need to work it stuffed into a backpack at a secure location along with encrypted copies of insurance and financial documents. Paranoia is cheap compared with losing, well, everything.

Back up your computer. Ideally, to two different physical drives. If you have a computer that will accommodate a spare internal drive then slap a big hard drive in there and only use it for backups. Go buy another external drive – one of those little USB-powered ones will do – and plug that in as a second backup drive, and then to finish up go and invest in an online backup service. I like Backblaze, but there are many other excellent options out there. Back up photos and home movies and any vital financial data onto a hard disk and put it in a safe deposit box, then make sure that your relatives can get to it if you’re not around. It’s a couple of hundred bucks a year, and completely worth it.

Do the research on updates and patches, and while it’s important to install urgent fixes for critical problems it’s also prudent to do some reading around on any problems raised by updates. You don’t want to update to the latest OS only to find out that it breaks compatibility with a crucial, professional-grade application. If you use a package management solution like Homebrew then update your installs, and go look through what you’ve installed and decide whether there’s anything that you need to get rid of.

Inventory the software on your computer – make sure you have copies of serial numbers and if possible have disk images saved and backed up someplace they can be readily retrieved if needed.

Build a solid routine.

An hour invested in maintenance on a regular basis – even if it’s just once a month – has the capacity to save you a lot more time further down the road. Seth and I often found that the servers we looked at and maintained for a few minutes every week had the longest uptimes and the fewest failures; by taking the time to really consider anything that seems out of place we’d catch odd log messages or note that some tasks or diagnostics took longer, and we’d catch issues long before they became critical. So, block out time on a regular schedule and stick to that schedule. You’re probably not going to run into anything disastrous on an ongoing basis, but noticing something awry in advance of failure is preferable to noticing it after failure has occurred. Read the Console.app for errors. Google the stuff you don’t understand to make sure that something disastrous isn’t around the corner.

Every Monday morning I spend thirty minutes or so doing all the above. Check the log files on the home and office servers, install critical updates and patches (or schedule downtime to run anything that needs a reboot), check logs and run updates on my desktop and laptop, run brew upgrade, check that automatic backups are working and that the things I have to backup manually are done and checked. That may sound a little OCD, but it’s thirty minutes out of the week that pays for itself in avoided failures and outages.

Invest time and resources.

So, thirty minutes a week is non-insubstantial if you bill for your time, and that time is valuable – but if you’re dead in the water then your time rapidly turns from a commodity into a liability. Likewise resources. Maintaining your computer isn’t a zero-cost solution, and if it is then you’re doing it wrong. Buy good components and quality parts. Don’t buy the dirt-cheap hard drive with a thousand single-star reviews; go tighten your belt, grit your teeth and buy the drive that isn’t likely to blow up or grind to a halt within a couple of months.

Thomas Hobbes said it best when he opined that life is “Nasty, brutish and short”, and while that sounds like the worlds’ most unpleasant law firm it has the ring of truth to it. The best way you can protect yourself isn’t with a backups or redundancies – it’s with thought and care and planning and the application of caution and investment of time.

Moving Time Machine to Catalina.

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…