Of late, my Mojave-running iMac has been having major Spotlight problems: Occasionally I'd find it rebuilding the main index, despite me not having done anything to require such an action. Even worse, though, is that it would stop working entirely in Mail until I rebooted.
My main use of search in Mail is to help our customers find lost license files—I have records that go back to 2010, so I can usually find their license if they did buy from us. With Spotlight broken, I'd have to login to the two different cart providers we've used over the years to find license files. Having a functional Spotlight in Mail was fairly job-critical to me.
Some digging showed that a process named suggestd was repeatedly crashing…
Any macOS engineers out there who might be able to solve a recurring suggestd crash? I've searched, and can't find anything useful. I cleaned up Mail, but that was no help.
Crash line: …NSInternalInconsistencyException', reason: 'Asset identifier storage too small' #HaveLogs
When this happened, it seemed it would often, but not always, kill Spotlight in general and in Mail. After a lot of debugging, I gave up on fixing the suggestd crash—it's stil crashing multiple times a day—and instead, set out to find another way to search my Mail archives without the help of Spotlight.
I wanted to offload all that historical Mail data to some other app whose search feature wouldn't be dependent on a functional Spotlight. And so, the search began.
tl;dr summary: I chose EagleFiler, a long-lived Mac app that works wonderfully for this task (and many others). It creates its own indices, so it's not reliant on Spotlight, and it's quite speedy at ingesting large amounts of Mail. An unexpected side benefit is that the database is small enough—and fully self-contained—that it's easy to sync to my laptop—so I now always have my email archives available.
As part of my struggles to fix my constantly-crashing suggestd process (and the Spotlight failures that it seems to cause), I reinstalled macOS Mojave a couple of times using the Internet Recovery partition. These were in-place reinstalls, so I didn't start completely clean, but the OS is reinstalled from scratch—so much so that I even had to run the 10.14.6 updater and a couple of security updates again.
In the end, not only did this not fix the suggestd problem, but it also broke my all-important VMware Fusion virtual machines. When I tried to launch any of them, I was greeted with an error message:
Error: Could not open /dev/vmmon: Broken pipe
This is apparently so common that VMware has a knowledge base article on the issue. The error is due to VMware Fusion not loading its required kernel extensions, but nobody seems to be sure of the cause of the problem. However, that article is supposed to fix it…unfortunately for me, it did not. I never saw an entry in the Security & Privacy System Preferences panel to allow VMWare's extensions. As a result, they didn't load.
Here's the tl;dr for the fix that did work: Rebooting in Recovery mode (hold down Command-R at startup) and deleting the KernelExtensionManagement folder located in /private/var/db. There was a lot more to it than that, though, which I cover for my own possible future needs in the rest of this post, in case the linked sources ever vanish.
A while back, my friend James and I were discussing the amount of tracking cruft in many URLs. In my case, I subscribe to a ton of email newsletters, and I noticed that those URLs are just laden with tracking information—and most go through a URL processor, so you don't really see those tracking details until you've clicked the link, at which point it's too late to avoid any tracking.
I wanted a way to clean up these URLs such that the least-possible tracking information was sent to a server—and in particular, to prevent any browser cookie creation. In addition, if I want to share a link with friends, I don't want to send them a crufty tracker-laden link—I wanted a nice clean shareable URL.
Note: I wrote all of this before I knew about Jeff Johnson's Link Unshortener, which does all of this (and more) in a "real" app. If you'd like the easy solution, Jeff's app is the way to go. Mine is definitely a do-it-yourself concoction that's not for the faint of heart.
tl;dr version: Install this macro group (v7) in Keyboard Maestro to remove tracking details from copied URLs in a set of defined apps. Keep reading if you want some more info on how it works…
Nov 29 2021 Update: There was a bit of a logic bomb in the handling of already-decrufted URLs (or completely clean URLs) that has been resolved. The macro now behaves properly if you copy a clean URL for a domain that would normally be decrufted, or if you copy a crufty URL that has a cleaned version available in your history.
Nov 17 2021 Update: I completely rewrote the history routines—now both the original crufty URL and clean URL are saved. If you copy either the crufty URL or clean URL again, the macro won't re-run curl, it will just look up the clean version and open that. I also added code for flyingmag.com, which now uses an HTML redirect (ugh!), requiring another step to clean.
Nov 1 2021 Update: Added t.co links, as seen on twitter.com (and probably other Twitter clients) to the decrufter.
Updated and republished for macOS 12.0.1; skip it unless you really really care about all the macOS releases. Originally published on November 14th, 2005.
Below the break is a table showing all major releases of macOS (previously Mac OS X) from the public beta through the latest public version, which is 12.0.1, as of October 25th, 2021—the 156th release in total.
Note: Click the ⓘ symbol to read Apple's release notes for a given update.
As much as I rely on our own Many Tricks' apps every day, there's one I rely on more: Keyboard Maestro (KM), the macro app for macOS that can do pretty much anything. How much do I rely on it? The shrunken image at right lists all of my macro groups—not macros, just the groups holding the macros. In terms of actual macros, there are over 425 at present. (These are not all user-facing; many are macros that support other macros.)
I use KM for everything from gathering monthly utility bills to inserting HTML code in blog posts to generating replacement license files for users to controlling iTunes to decrufting URLs when copying (future post coming on that one) to automatically naming and filing documents I scan to storing snippets for insertion into our apps' help files to opening oft-used URLs to adding key functionality to many apps such as Excel, Mail, Messages, Photos, Preview, Safari, etc. In short, it's the single most-used app on any of my Macs.
For as much as I love KM, it has one major shortcoming: All of those macros live in one large XML file. Yes, I back it up to many local and cloud locations, so I'm not worried about losing it. It does mean, though, that if I mangle a single macro while trying to fix something, there's no easy way to get back to the working version (assuming I've gone past the point of multiple undo steps).
But now I can recover from such stupidity, thanks to the amazing Macro Repository Suite from Dan Thomas. This suite consists of two macros: One that updates (and initially creates) the repository, and one that restores a given macro from the repository.
I like Excel. I cover it often here, and I use it in projects where it probably would make more sense not do to so. Like my current task, which is developing a stats tracking package for a billiards training game (yea, obscure, I know).
While working on this workbook, I ran into a problem where I couldn't effectively select text in the formula bar: Whenever I tried, the selection would continually grow back to the left, regardless of what I did with the mouse. I also couldn't click on a location in the formula to place the cursor there; it would instantly start selecting text. It looks like this:
But this didn't always happen—in fact, it didn't happen very often at all. And I didn't seem to see the problem in new workbooks, only this one, and then sometimes seemingly randomly, in others. After way too much troubleshooting, I figured out the cause and the solution:
If you resize the pop-up menu at the left of the screen, that triggers the selection bug. Resizing after that, even back to where it was, won't help. You can either close and reopen the workbook, or drag the slider to remove the box. This video shows the entire process, from working to broken and back again:
I don't know how old this glitch is—it exists at least as far back as Excel 16.33 (16.46 is current). I'm trying to get someone at Microsoft's attention, but if you can help, please do—it's a very annoying bug.
As part of my job, I occasionally have to make screencasts, usually demonstrating features in our various apps. Sometimes I need to record the entire screen, as I'll be demonstrating things that require activating and selecting menu items. I have a demo account I use for these recordings that lacks all of my usual menu bar add-ons, so the look is quite clean.
And in versions of macOS prior to Big Sur, I also hid the menu bar clock (via System Preferences → Date & Time → Clock, uncheck "Show date and time in menu bar.") But in Big Sur, the menu bar clock is also the button you click to open Notification Center…so there's no way to remove the clock from the menu bar.
Most of the time, this isn't a problem. But when recording screencasts, it's a big issue. I often record segments across days, and at multiple times a day. I then splice those bits together, often times not in a linear fashion. With the default Big Sur settings (displaying the full date and time), this leads to a real annoying time travel experience as the clock jumps around like crazy.
The following two tips help greatly with this problem, though being able to hide the clock entirely would be a much better solution…
I recently received my Apple M1-powered 13" MacBook Pro, which is primarily going to be used for testing our apps on Apple silicon, and supporting customers using these machines. But that doesn't mean this is a work machine; it's a personal purchase as I'll use it for my own needs as well. (Thankfully, it only had a net cost of $33 after I sold my 16" MacBook Pro.)
By now, you've probably read a slew of stuff about both the MacBook Pro and its slightly-lighter MacBook Air cousin. Between unboxing videos, extensive benchmark suites, and multi-thousand-word reviews, there is no lack of coverage of these machines. (However, I will add that I did make a video of my MacBook Pro—with its 16GB of RAM—opening 75 apps in just over a minute. Not bad for an entry-level machine!)
I'm not going to try to replicate those reviews, because they do an excellent job of covering the new M1-powered Macs in a level of detail that I just don't have time to get into. Instead, here's what I'll be discussing…
I ordered my 13" M1 MacBook Pro with 16GB of RAM, as I felt buying the most offered was the best bet for future proofing this "entry level" M1 chipped Mac. Later today I'll be posting a detailed writeup of my time so far with the new machine, but for now, here's a little over-the-top demo.
I selected everything in the Applications folder—excluding Time Machine, Siri, Launchpad and a few other similar non-apps—and opened them all at once. I did this with a timer running, while recording the screen, and here's the result…
As you can see at the end of the video, it took one minute and seventeen seconds to open all 75 apps—do the math, and you'll see that's about 1.5 seconds per app (it was notably quicker than that at first, and slower than that at the end). For 75 apps. On a machine with nowhere near enough RAM to fit them all in active memory. I was amazed at how rapidly it was able to complete this task.
These weren't even all native apps, it was a mix of Intel, Apple, and Electron (both native and non-native) apps.
I tried a similar test on my MacBook Air, but as it's an 8GB RAM machine, I limited it to opening 37 apps, which took it well over three minutes (about 5.5 seconds per app). I didn't bother to try on my iMac—it has 40GB of RAM, but it's also got a slower SSD, so I don't know that it would've matched the MacBook Pro's performance.
I've been having an odd issue with the Mac App Store app on my Mojave-running iMac: Sometimes the App Store app will fail to install an update for some app. When that happens, I see a dialog with this text as the title:
We could not complete your purchase.
Below that is a single word, "cancelled," and that's all. Searching the web, I came across this thread on stackexchange.
What finally worked for me was a combination of things listed there—none of these steps on their own seem to fix the problem, but all together do, at least until it occurs again.
Quit the App Store app.
Switch my DNS to another provider.
In Terminal, paste this command and press Return: open "$TMPDIR/../C/com.apple.appstore/"
Confirm that the Finder opened a window to the com.apple.appstore folder, then drag everything there to the trash.
Back in Terminal, paste this line and press Return: killall -9 appstoreagent
Relaunch the App Store app.
This method has worked for me each time I've had this issue. It's annoying that it keeps recurring, but at least the fix is relatively simple.