For the last couple macOS releases, I've had nothing but trouble searching in Mail. Note that I didn't write "trouble searching mail," but rather, "trouble searching in Mail." For example, today I needed to find an email from my business partner Peter about a hidden pref in Butler. (I was hoping this pref could help a user who was having problems with the pasteboard in a certain app.)
Based on a document on my hard drive, I knew the name of the default was Pasteboard Normalization Interval, but I couldn't remember the syntax of the defaults write command to set its value. So I searched in Mail…
So clearly, no emails in my database contain the words I'm looking for, right? Here's the exact same search, run in Spotlight:
Not one but two email messages match my search, and provided the needed syntax for the command.
Wait, I know what you're thinking: "Ahh, look, it's in quotes!" Doesn't matter; searching Mail for "Pasteboard Normalization Interval" still results in zero matches. Searching on even one word of the phrase, like Normalization, also finds no matches.
Again, I know what you're thinking: "Oh, I bet the Mail index is screwed up." Nope; even after rebuilding the index on all 250,000+ messages in my database, no matches are found. (And yes, I let the index complete its rebuild, which took hours.)
I've heard from others that search in Mail works for them. But it's a no go for me, and I know, for others. So something's wrong, but I don't know exactly what it is, nor how to fix it.
So for now, I have to rely on Spotlight to search Mail…or a third-party app, but more on that in a bit.
Once a month, I download roughly 25 gzipped (.gz) files from Apple—these are our Mac App Store sales reports, with one file for each App Store region. I could have Safari expand these files (via the "Open 'safe' files after downloading' item in its preferences), but I prefer to leave that option unchecked. (Why? I often download archives that I want to leave archived, and I like to keep originals of many of the things I download).
If you work with lots of compressed files, you're probably familiar with what happens in Finder (see note) when you go to expand any semi-large number of files: The infamous Dancing Dialog™. It looks something like this…
[Note: Technically, this isn't Finder, it's Archive Utility doing the expansion. But this is the service that Apple provides to expand compressed files, and it's what 99% of macOS users will use. It can be changed via the Get Info dialog, but very few people will take that step. So to most users, it seems it's Finder handling the expansion. For ease of reference, I'm going to say it's Finder doing the expansion.]
Not only is this randomly-resizing dialog box visually annoying, it turns what should be a super-fast process into one that takes a ridiculous amount of time. The end result is that users think they have a slow machine—"it took over 12 seconds to expand 25 tiny little archives!"—when what they really have is a horrendously slow GUI interface to a super fast task.
Just how fast is the task, if the GUI doesn't get in the way? Thanks to the Unix core of macOS, we can answer that question using Terminal, the geeky front-end to the Unix core. The Unix command to expand .gz archives is gzip; so to expand all the .gz files in a folder (and keep the originals), you'd use this command in Terminal:
gzip -d -k *.gz
If you try this, you'll find out it's nearly instantaneous—press Return, and the files are expanded. Unix actually gives us a way to see exactly how fast it is, via the time command:
$ time gzip -d -k *.gz
This was for a set of 24 .gz archive files (on a solid state drive), and the real line in the output shows exactly how long it took to expand them all: 0.013 seconds. By comparison, I made a screen recording (with an onscreen stopwatch for timing) of Finder expanding the same 24 files; it took 12.8 seconds for all the dialog dancing to end. Think about that…
Expand 24 .gz files
Finder: 12.8 seconds
Terminal: .013 seconds
Terminal is 984.6x faster than Finder
To put those results another way, if expansion time is linear, gzip could expand 23,631 files in the time Finder takes to expand 24 files. That's nuts!
(You can watch this video for a visual comparison of expanding the same set of files in Finder and Terminal.)
So it's not the computer that's slow, it's the GUI interface to the computer that (in this particular use case) is incredibly, horrendously slow. And there's no need for it—the separate individual progress bars, appearing and vanishing in under a second each, provide no useful feedback to the user. They just slow down the task.
Finder (née Archive Utility) should just execute the task without any visual feedback (though it should pop up a window if there are exceptions). If visual feedback is really required, a window with a single progress bar for the entire task would be OK, but would still slow operations down.
This is a great example of how an everyday task can make you think you have a slow computer, when what you really have is a fast computer with a slow interface element. Given how often we all deal with compressed files, it'd be nice to see Apple clean up this mess. Until they do, however, you can harness the power of Unix—even while in Finder—to speed up the task. Here's one way to do just that.
Kirk McElhearn explains how Messages in Yosemite has trouble sending pasted images. These problems typically only occur between people who use AIM accounts in Messages; sending pasted messages when using iMessages' accounts seems to work fine. (I use an AIM account to keep iMessage traffic off my main Mac, and for its great screen sharing.)
Kirk's article details the fix, which is to kill the imagent process, which is what controls Messages. He uses Activity Monitor to do so, which works fine. But I have to kill the stupid imagent many times a day, so I wrote the World's Easiest AppleScript™ to do the work for me.
Unlike my previousincidents with iTunes and iOS devices, today's report isn't on a sync problem per se.
It's more like a math problem which then leads to a sync problem. Here's the tl;dr version: I have an iPad with 5GB of free space, and I cannot add a 1.8GB movie to it, as iTunes eventually tells me it needs another 526MB of space in order to do so.
During the attempted sync of this movie, iTunes displays some horridly bad math skills; just watch the video to see.
For those who aren't familiar, Console (found in Applications > Utilities) is an application that shows you what's happening beneath the lovely skin of OS X. Open the application, and you'll see a combination of status and error messages from any number of sources.
If you've never looked at Console before, you might be surprised by just how much stuff gets written there. But with the release of Yosemite, things have really taken a turn for the worse—the amount of stuff written to Console is greater than I recall for prior OS X releases.
As a test, I set up a new Yosemite virtual machine, installed ScreenFlow (and nothing else), then launched and interacted with a number of Apple's apps for two minutes while recording the screen. The results are quite sobering; here's what two minutes of Console logging looks like, reduced to a 10-second movie:
As you can see, there are a lot of Console entries in just two minutes.
Those following me on Twitter this weekend will have noticed that my (lovely, stunning, amazing, I am keeping it) iPhone 6 is not playing nicely with iTunes. I've invested over 10 hours—in one day—just trying to get music and movies onto my iPhone.
Frustrated as hell, I decided ask Tim Cook for some tech help, not that I have much hope of any sort of reply. Emails to his address, however, are apparently all read by someone. For those having similar issues, I think it may be useful to also send your feedback in Tim's direction; his email address (not a secret, published in many places) is tcook at Apple's domain. Perhaps if there are enough voices providing feedback in high places (not that Tim reads these himself), we might see some action.
Further update: I have now done two full system restores. I did the second just before bed last night, and let the iPhone sync overnight. On wake, everything worked! So then I added in a few more movies, and—of course—they failed to sync. So now I'm back where I started, oh so many hours ago.
Anyway, For the curious, here's the tech support request I sent to Tim yesterday.
Note: Dropbox—sadly—removed this feature in July of 2017, so don't even bother reading any further.
Did you know that Dropbox lets you create photo albums? No? Me neither, until this morning, that is. And it turns out, it's incredibly easy to do:
Copy or move a folder of images into your Dropbox folder. Choose any location within the Dropbox folder that you wish; I set up a Photos folder to hold slideshows.
Open the Dropbox web site, and sign in to your account.
Navigate to the folder you just uploaded, right click, and choose Create album.
Click Share album, then copy the link or directly invite those you'd like to see the album.
That's it, your'e done. The only time-consuming portion of the process is uploading the images; creating and sharing the album takes almost no time at all. That's about as simple as it gets.
Now assume you want to do the same thing using iPhoto: create a web-based slideshow of images for anyone to see via a shared URL. Sure, you could use iCloud's Photo Stream, but that's not a web-based solution. Instead, you'll need to use File > Export in iPhoto, and either create a Web Page or a Slideshow. Slideshow is really misnamed, though, as what it really creates is a movie of your images. So Web Page it is.
One of the touted features in Mavericks is better multi-monitor support. And at some levels, that's true. Unfortunately, my overall experience is that things are worse, not better, than they were before—especially if you don't use full screen mode often (or at all). (more…)
If you follow me on Twitter, you're probably familiar with my iOS5 installation difficulties. Two days into the process, and I've still not been able to update either my iPad (first generation) or iPhone 4. This is—by far—the most frustrated I've been with any Apple upgrade, ever…and that covers a lot of history!
Simply as a means of venting, and perhaps to save someone else from going through what I've gone through (though note that I haven't yet solved the problem), here's what I've gone through to try to upgrade my iPhone and iPad.
Update: On my 48th attempt, my iPhone 4 successfully updated to iOS5. Now, on to the iPad…
When Steve Jobs demoed Leopard at the Worldwide Developers Conference in June, one of the new features included in the revised Desktop is a semi-transparent menu bar. It's clearly visible in the streaming video of the keynote, and in many of the screenshots on Apple's Leopard pages.
Now, I'm all for fancy effects, at least where it makes sense and might actually help the user. But in this case, I don't think it makes sense—look at many of Apple's own screenshots, and you'll see that certain entries in the menu bar are quite hard to read, owing to the bad mix of black text, a semi-transparent background, and a dark background image. Instead of being useful, it seems to me that—based on what's been shown, at least—the semi-transparent menu bar will do nothing but annoy me when I try to find a menu item against a non-cooperative background image. Of course, I won't know for sure until October when Leopard ships and I can test (and discuss) how well it does or doesn't work.