Skip to content

macOS System

Discussions on system-software-related topics…

Yosemite: An alternative zoom-to-fit action

As you're probably aware, Apple changed the functionality of a green button click in Yosemite: it not longer "zooms to fit" (which could have different behaviors per app), but instead it enters Full Screen mode (if the app has one; otherwise, it does zoom to fit). If you want zoom-to-click, you can option-click the green button; there's no apparent way to toggle these two functionalities.

But today, I discovered a second zoom-to-fit shortcut: double-click the window's title bar. This is easier to do, as you don't have to hit the small green button target; just get the mouse anywhere in the title bar, and double-click.

Note that this won't work if you have "Double-click a window's title bar to minimize" enabled in the Dock System Preferences panel.



Goodbye cron task, hello launchd agent

On April 29th, 2005, Apple launched Mac OS X 10.4, aka Tiger. With Tiger came launchd, a new Unix-side job scheduling tool. launchd was intended to replace cron, the long-established (and quite cryptic) tool for such tasks.

And now, a mere nine-plus years later, I decided it was time to give up cron and move to launchd myself. Mr. Bleeding Edge, that's me! (Note: Unless you enjoy the Unix side of OS X and currently use cron to schedule tasks, this article won't be of much interest to you.)

Why now, after so long as a holdout? Primarily because I kept running into issues with cron tasks that needed to do things as "authorized me," such as mounting an encrypted disk image, or even just mounting a network share. Or my Mac would be asleep for a scheduled cron task, and it therefore wouldn't run. (launchd will queue any missed tasks to execute when the Mac reawakens.) Finally, my cron file was getting huge and unwieldy, and making simple changes was fraught with danger of breaking something.

So I dedicated a portion of a recent weekend to figuring out launchd, and migrating my cron tasks to this brave no-longer-at-all-new world. If you're still hanging on to cron, read on to see what I've learned about launchd—maybe it'll inspire you to move, too (or not).

[continue reading…]



Leaked—Tim Cook’s October 16th monologue notes!

[Serious, reserved look]
At Apple, your trust means everything to us. And we know that recently we've lost that trust. We released a horridly-rushed iOS 8.0.1 update that clobbered a number of users' phones. Our celebrity users had their most private moments shared with the world. Our web site crashed when people tried to order the new iPhone 6. We had to ship iOS 8 without HealthKit and iCloud Drive. We spammed everyone with a U2 album that not everyone wanted. Hell, the last time I tried to give one of these talks, most everyone on the internet had to listen to a Chinese version of myself at the same time.

[Earnest appearance, eye contact with everyone!]
As you can see, we've made a number of seriously un-Apple-like mistakes recently, and quite frankly, that's not acceptable. Not acceptable to you, our customers. Not acceptable to me, and certainly not acceptable to everyone else here at the company. This is not the Apple we all know and love[dramatic pause]…users have been putting up with this for way too long, and today, it ends! [demonstrative]

[continue reading…]



An iPhone 6, (no) movies, and me

On Friday, I received my new iPhone 6, which I really like—a lot, in fact. Over the weekend, however, I discovered that my new iPhone does not like iTunes—at least not syncing my movies via iTunes.

Things started great, with the arrival of the new iPhone 6 on Friday afternoon:

From there, though, things didn't go exactly according to plan…and I documented my progress (or lack thereof) via Twitter over the weekend. Read on for the full story, as told in 140 character increments.

[continue reading…]



Behind OS X’s modern face lies an aging collection of Unix tools

Note: This article has been heavily modified, as I was a total knucklehead and completely forgot about GPL v3—thanks to Geordie Korper for pointing it out in the comments. Basically, the cause of the aging Unix tools in OS X is GPL v3. I've updated the following table to include the license information. In every case but one (nano), GPL v3 is the license on the non-updated apps. So that's that…I'll leave this up, though, in case anyone's curious about this stuff.

As I covered recently, the version of bash that ships with OS X is quite old, and as such, is vulnerable to the recently-revealed bash security hole.

At some point, Apple will release an OS X update containing a patched version of bash. (Update released.)

So while Apple has patched bash, this version of the shell is simply ancient. Just how old is it? bash 3.2.53(1) is roughly seven years behind the current version, 4.3.25. Seven years is like, well, forever, in Internet time!

With that bash age gap in mind, I took at look at a number of common Unix apps—in both Mavericks and Yosemite—to see which versions were in use. Then I checked the same apps in MacPorts, a tool that makes it simple to install many Unix apps.

(MacPorts doesn't necessarily have the absolute latest version of every Unix app, but they do stay relatively current. For instance, they already have a patched version of bash that fixes the above vulnerability.)

The results were interesting, to say the least—many of the core Unix utilities in OS X are years and multiple versions behind their open source, er, sources. You can thank GPL v3 for that, as noted above (and covered in more detail below). But that still leaves the big question:

Does it matter?

That is, should we care that these tools aren't keeping up with their latest and (presumably) greatest versions? Is it a problem, or merely a statement that what we have works well enough for the majority of users? (For those who don't want to bother reading, my general opinion is no, it doesn't matter.)

[continue reading…]



A look at the first eight years of macosxhints.com

I was cleaning out some old images from the site, and found over 150 apparently unused images. Whoops, that's what nine years of bad housekeeping will get you.

One of the leftovers, though, was kind of interesting. At some point in time, I graphed the number of hints published each day on macosxhints.com, from launch through 2008—a total of 12,051 hints.

Even if unlabeled, it'd be pretty easy to figure out where the major OS X releases occurred (except for 10.1, not sure what's up with that?). And you can see a general downward trend in hints per day, as the OS became more established (and more locked down) over time.

In any event, I thought it was an interesting chart, and figured I'd toss it into a quick post instead of just sending it to the dustbin.



iCloudy with a 100% chance of stupidity

I use a lot of cloud services for file storage, primarily Dropbox, but also Box and (begrudgingly, for certain shared projects) Google Drive.

I also use iCloud, but not in any way that would be considered a true cloud file storage service. I use it strictly as a sync service for contacts, calendars, reminders, notes, Safari; I also use Back to My Mac.

But that's it; I don't use iCloud for cloud-based file management at all. Why not? Because iCloud in its current implementation is chock full of the stupid, at least for those of us who still use and rely on OS X.

Stupid #1: Not enough free space, and too costly for more

A quick comparison chart shows just how far out of line iCloud is with other cloud-based services:

ProviderFreeTier 1Tier 2Tier 3
GBGB$/Yr$/GB/yrGB$/Yr$/GB/yrGB$/Yr$/GB/yr
Box10100$60$0.6001000$180$0.180------
Dropbox2100$100$1.000200$199$0.995500$499$0.998
Google Drive15100$24$0.2401,000$120$0.12010,000$1,200$0.120
iCloud515$20$1.33325$40$1.60055$100$1.818
Pricing sources: Box • Dropbox • Google Drive • iCloud
Note that you can get additional free space on Dropbox through referrals and uploading images; Box occasionally offers a promo with 50GB of free space.

Kirk McElhearn covers this price and space issue in more detail in his blog post, Why Does Apple Only Offer 5 GB Storage with iCloud?.

I agree with him; if iCloud wants to attract more users, it needs more free space, and more competitively priced upgrade plans.

Read on for more of the stupid…

[continue reading…]





Use Mountain Lion in VMware Fusion with Tools

Note: As of VMWare Fusion 4.1.2, this hack is no longer necessary. I've left it here mainly for those using older versions of Fusion (though you may not be able to install newer Mountain Lion previews on those older versions of Fusion).

If you're a Mac developer with access to OS X Mountain Lion, you might want to use it in a virtual machine. This is simple in VMware Fusion, but if you try to install VMWare Tools, Mountain Lion will kernel panic. Unfortunately, using virtual OS X without VMware Tools installed is painful—no screen resize, captured and laggy mouse, etc. So here's a workaround to get Mountain Lion working with VMware Tools (this assumes you have Mountain Lion already running in a virtual machine):

  1. Make a snapshot of your current setup!
  2. Run the VMWare Tools installer, but do not reboot when it's done. Just leave the installer running onscreen.
  3. Navigate to /Library > Application Support > VMware Tools.
  4. Delete vmmemctl.kext and vmmemctl
  5. Edit (you'll need root power) services.sh in that same directory.
  6. Comment out these two lines (they're shown commented out, via the # in front of each):

  7. Save the edited file, quit the editor, and now (via the still-running Installer) reboot the virtual machine.

The initial reboot may take a long time, but it should work. If it doesn't, you're on your own, as I've now exhausted all my knowledge on the topic.



New Macworld video posted…

Macworld logoIt was my turn on the Macworld video blog-go-round again this week. The topic I chose is "working with multiple Macs in one home." The end result is a 10-minute clip covering a number of third-party tools that make the process easier, and a couple of general usage hints.

Due to the huge number of downloads, the size of the macworld.com video is 320x240. But if you want, you can see grab the original 640x480 version right here. Warning, it's 185MB in size (I didn't work very hard to compress it, so the quality is good, but it's huge).