Joe Kissell

My article in last week’s issue of TidBITS, Stewing Over Safe Sleep, generated an awful lot of feedback. Most of it was of the “Yeah, that was really stupid of Apple” or “Thanks; now I know how to solve an annoying problem” varieties. Some of it was along the lines of “How could anyone not love safe sleep?” or “I’m not seeing 49-second delays on MY machine” or “It probably doesn’t really matter if you move your computer while the RAM is being cached to disk” or the simple and elegant “You’re an idiot.” Well, thanks one and all for sharing your thoughts, constructive and otherwise.

Two particular threads of discussion, though, are worth a more detailed look.

Hibernating Only When Necessary First, Greg Nicholson sent me a clever script he wrote (to replace the one I showed in TidBITS) that’s significantly smarter. Greg pointed out that there are certain situations, such as a long flight to China, in which one might be much more likely to want the default Safe Sleep behavior. So his script, which he runs every 10 minutes with cron, checks the battery life. If it’s over 50%, it turns off hibernatemode (as my script does). But if the charge is less than 30%, it turns hibernatemode back on. Very spiffy, and I wish Apple would have built something like this right into Mac OS X. You can, of course, tweak the percentages and so on to your liking. Here’s (my slightly modified version of) Greg’s script:

#!/bin/sh
MODE=`/usr/bin/pmset -g | grep hibernatemode | awk '{ print $2 }'`
LEFT=`/usr/bin/pmset -g batt | grep Internal | awk '{ print $2 }' | awk -F % '{ print $1 }'`

if [ $LEFT -lt 30 ] && [ $MODE != 3 ] ; then
  {
     echo "Less than 30% remains" >> /var/log/system.log
     echo "setting Hibernate mode 3" >> /var/log/system.log
     `/usr/bin/pmset -a hibernatemode 3`
  }
elif  [ $LEFT -gt 50 ] && [ $MODE != 0 ]; then
  {
     echo "Greater than 50% remains" >> /var/log/system.log
     echo "Setting Hibernate mode 0" >> /var/log/system.log
     `/usr/bin/pmset -a hibernatemode 0`
     `rm /var/vm/sleepimage`
  }
fi

Greg noted that since the script requires root privileges, you need to add the following to your sudoers file:

ALL ALL=(ALL) NOPASSWD: /usr/bin/pmset -a hibernatemode 3
ALL ALL=(ALL) NOPASSWD: /usr/bin/pmset -a hibernatemode 0

An easier way to achieve that effect would be to put the cron job in your system crontab, if you feel comfortable doing that.

Dealing with an Unencrypted “sleepimage” file Correction (08-Aug-2007): I see I munged some of my facts here earlier, so I’ve rewritten this paragraph to reflect what I currently believe to be the truth.

Second, the issue of encryption came up. It turns out that using hibernatemode values of 5 or 7 (the prescribed values for those using Secure Virtual Memory) don’t actually result in your sleepimage file being encrypted—in fact, it’s just the opposite. If you have Secure VM turned on and use 5 or 7, your encrypted RAM is apparently decrypted while being written to the sleepimage file. So if you’re using Secure VM and want your sleepimage file, too, to be encrypted (which you should), stick with values of 1 or 3 (3 being the default).

Now, in the real world, this fact probably makes little practical difference for most people, most of the time. Even if you don’t encrypt your VM, it’s not a given that any particular password (or other sensitive data) will actually be in RAM when it comes time for your computer to sleep—it might be, or it might not, depending on a long list of details about how particular programs do things, how recently you logged in, what applications you have running, and so on. And also, the risk is certainly greater for power users who enter an administrative password multiple times per hour than people for whom that is a rare occurrence. Even then, the contents of your RAM is cached to that unencrypted disk image only when your computer goes to sleep and only when the hibernatemode setting is at its default (3) or “always hibernate” (1). And even then, the fact that potentially sensitive stuff is sitting on your hard disk in a readily readable format only causes problems if someone gets access to your computer and knows how to find this data. So, like I say, not a problem for most people, most of the time.

If you’re concerned about this, though, DO follow my advice to turn of Safe Sleep. But go a step further. Instead of using

sudo rm /var/vm/sleepimage

to delete the RAM cache, use the secure version of rm, srm, and use the -m flag for a 7x overwrite rather than the default 35x overwrite:

sudo srm -m /var/vm/sleepimage

The command will take a long time to run, but the disk image holding your RAM contents will be safely overwritten. Note that you only have to do this the first time. If you’ve set up a script (as discussed previously) to check regularly to see that hibernatemode hasn’t turned itself back on, having a simple rm in that script will do the trick. The reason? When hibernatemode turns back on, Mac OS X recreates the sleepimage file immediately. But initially, it’s blank. It doesn’t fill up with the contents of your RAM until your machine tries to go to sleep. If your script runs and deletes the (blank) image before then, nothing incriminating will have been in that file.

I truly hope this all gets sorted out in Leopard.

For the past umpteen years, I have dutifully installed every new version of Microsoft Office for Mac that the company has put out. I expect I will continue doing so indefinitely. I’m not particularly fond of Microsoft as a corporation for all the usual reasons, and I’ve found plenty to complain about in every piece of Microsoft software I’ve used. Nevertheless, I use Office (and particularly Word and Excel) every single day, as probably 90 percent of my income requires it in some fashion. When new versions appear, I fantasize that certain bugs that have existed since the mid-1990s might finally be gone, and they never are, but at least a few things generally get better.

Since I don’t particularly expect that any of my long-standing complaints will disappear in Office 2008, I’ve been looking forward to it for primarily one reason: it’ll be a Universal Binary, and should therefore run faster on my Intel-based Macs than Office 2004 does. In other words, I’ll be glad when Office 2008 ships only to the extent that it should scratch one certain long-standing itch; otherwise, I would have been reasonably content to keep running Office 2004 for years to come.

I say all this to put into context my remarks about today’s announcement that Office 2008 will not, as the company previously claimed, ship in the second half of 2007 but will instead ship in mid-January 2008. As a user, this slippage in ship dates is barely worth noticing. Its net effect on me will probably be next to nil. As a Mac journalist, I find it highly significant that a company the size of Microsoft can’t hit a release window that’s six months wide even when they set that target a mere six months in advance, and I think that’s worth giving the company at least a mild tongue-lashing. But really: I don’t care about the slip. It’s a pity, but no big deal.

What I do care very much about, though, as someone who uses words for a living, is the language Microsoft chose to use in the press release they sent out announcing this delay. It is, truly, a delay: a difference of (depending on how you interpreted “second half of 2007”) anywhere from two weeks to six months and two weeks. And most of the news sites that reported on the delay described it as such. But Microsoft themselves did not use the word “delay.” They didn’t mention that they’d previously announced an earlier date. They didn’t say they were sorry. Instead, they used standard weaselly marketing language to make it sound like they were announcing a virtual non-event, and perhaps even to subtly suggest that anyone who wanted to think about it differently doesn’t care about quality.

Here is the exact text of the press release I received:

Office 2008 Coming January 2008

Microsoft’s Macintosh Business Unit (Mac BU) today announced that Microsoft Office 2008 for Mac will be available in the US in mid-January of 2008 (planning for Macworld), with global general availability in the first quarter of 2008. This was a business decision based on the Mac BU’s commitment to deliver a high-quality product.

“Our number one priority is to deliver quality software to our customers and partners, and in order to achieve this we are shifting availability of Office 2008 for Mac to mid-January of 2008,” said Mac BU General Manager Craig Eisler. “We’re successfully driving toward our internal goal to RTM in mid-December 2007, and believe our customers will be very pleased with the finished product.”

As the Mac BU moves closer to the product launch, Microsoft will share more details about features and exact timing.

More information at the Mac BU’s Mac Mojo blog at http://blogs.msdn.com/macmojo

Now then…what Microsoft could have said in their press release, instead, is this:

“Office 2008 for Mac, which we previously said would ship in the second half of 2007, has been delayed until January 2008. We ran into some unexpected problems, and we now realize we can’t get this out as soon as we said. We apologize for any inconvenience this delay may cause. We hope our customers will find the final product to be worth the wait.”

See how much better that is? It’s easy: just plain English. No weasel words, but no protracted pseudo-explanations either. Just: “Look, stuff happens. It happened. We’re sorry. Here’s the new plan.” And yet, with those few words, you acknowledge that there’s a difference between what you said and what you’re doing, that that is in fact a bad thing that you wish hadn’t happened, and that you understand why people might be a bit upset with you.

Why is that so hard? Why can’t a company bring itself to admit any fault, however minor, to say they feel badly about something? It’s OK, really. Your customers will forgive you. What customers should not forgive is marketing speak. I don’t cry over spilled milk. I cry over “The erstwhile contents of the glass have been redistributed in a more horizontal fashion. This was a business decision based on gravitational forces. Information on forthcoming moisture containment strategies and potential new sources of dairy products will be made available by mid-January 2008.”