Archive for the 'Mac Stuff' Category

December 7th, 2008

Twitter Tools Goes Haywire

So I was trying out Twitter Tools, which can do interesting things like creating a tweet when you post on your blog, and creating a blog post when you post a tweet. Both of which are potentially useful things. From the FAQ in the Read Me file:

What happens if I have both my tweets posting to my blog as posts and my posts sent to Twitter? Will it cause the world to end in a spinning fireball of death?

Actually, Twitter Tools has taken this into account and you can safely enable both creating posts from your tweets and tweets from your posts without duplicating them in either place.

Yeah, except it didn’t. As soon as I turned it on and set up the various options I wanted, two things happened. First, it downloaded my last 20 tweets and made blog entries out of them. (Not at all what I wanted, because some of them are quite old…I was assuming it would start with my next tweet.) And then, having discovered 20 new blog entries, it created 20 new tweets, one for each. (That’s what the Read Me explicitly said wouldn’t happen.) So they were totally duplicated—highly annoying. Nor did this stop after the initial batch—my next tweet, to apologize, was also turned into a blog post that was immediately re-tweeted.

I also discovered another missing feature: when Twitter Tools creates a blog post from a tweet, it just truncates the tweet arbitrarily and turns that into the title, but with no verbiage like “From Twitter…” (comparable to the “New Blog Post” it puts in tweets). So, another big minus.

So: Twitter Tools = FAIL. And sorry for all the birdy poo. Now to uninstall…

October 17th, 2007

Early bird gets the Leopard

Almost exactly four years ago, on October 24, 2003, Apple released Mac OS X 10.3 Panther. On that same day, the very first ebook in the Take Control series appeared—my upgrading guide, Take Control of Upgrading to Panther. Little did I know then that this little publishing experiment, undertaken by most of the TidBITS staff and a handful of other talented authors and editors, would be so successful as to eventually produce the majority of my income. But today, less than 24 hours after Apple finally announced the shipping date of Mac OS X 10.5 Leopard, I’m pleased to report that my 14th title in the series is now on sale: Take Control of Upgrading to Leopard: Early-Bird Edition.

When I wrote my second Upgrading book, Take Control of Upgrading to Tiger, I naturally started with what I’d written about Panther, added some stuff, removed some stuff, and generally updated everything to be accurate under the new system. But this time I wanted to go way beyond that. Leopard is a big, big release with lots of serious changes; I wanted the Upgrading book to reflect that and prepare users as thoroughly as possible. So in addition to massively reworking the text to cover all the changes to the Leopard installation process, I pulled in some material from my ebooks on backups, maintenance, and troubleshooting. Now I provide detailed instructions on getting your Mac in tip-top shape, complete with an excellent backup, before inserting that Leopard DVD—and I think the extra steps up front will lead to much happier installations later.

Of course, there was a tiny problem: ideally, you’d do all that preparatory stuff days or even weeks before you get your Leopard DVD, but I can’t actually release the full book, with all its top-secret information about the ins and outs of Leopard installation, without violating my NDA. So we decided to create two versions of the book. The Early-Bird Edition, which you can buy (for $10) and download today, has all the background information you need to get your Mac ready for the upgrade, but leaves out all the information I’m not allowed to reveal (which amounts to quite a large portion of the book). The full edition will become available the instant Leopard goes on sale in North America (that’s 6:00 p.m. Eastern Time next Friday, October 26). Anyone who has already purchased the Early-Bird Edition can simply click a link on the cover of the PDF to go to a Web page where they can download the full version for free. And then they can skip (or skim) about 50 pages of text and get on to the actual upgrading process fairly quickly. Of course, if you wait until next Friday or later to make your purchase, you’ll simply get the full version, which is a superset of the Early-Bird Edition.

Now then…what’s crazy to me about all this is that I initially wrote (both versions of) this book back in February, when Apple was still saying Leopard would be released in the spring. It went through our whole editorial and technical review process way back then. In April, when Apple announced a delay until October, we just put the project on ice. This summer I picked it up again, and updated the manuscript with new information from each new beta version of Leopard. Yesterday, as soon as Apple made their announcement, I had to tweak a few things in the Early-Bird Edition to correspond to the latest truth, but even so, we were organized enough that the PDF was available for sale within hours. Between now and next Friday, I very much hope to see an even more recent version of Leopard than what I’ve been working with, and should it contain any significant changes, I’ll work those into the final text as well. The result should be our most thorough and up-to-date upgrading guide ever! If you’re planning to install Leopard, I think you’ll find this ebook to be immensely helpful.

August 8th, 2007

New .Mac storage limits: still way behind

Among the many interesting announcements from Apple yesterday was an expansion of .Mac’s capabilities, but with the same price as before. And there are lots of groovy new things, such as the Web Gallery and the capability to use .Mac with your own domain. Unlike most people, my reaction to these changes was, in a word, “Ugh,” by which I mean “I now have to spend many days updating my book Take Control of .Mac to reflect the current truth.” Yeah, I know, boo hoo.

However, what most caught my attention was the change in storage limits. Previously, .Mac came with 1 GB of storage for $100 per year, and you could increase it to either 2 GB (for $50 extra per year) or 4 GB (for $100 extra per year). Now, at those same prices, you get a base level of 10 GB, which you can increase to either 20 GB or 30 GB. And it seems a lot of people are thinking, “Wow, a 10x increase in space at no extra cost! Great!” But I’m thinking: not great.

As before, that space has to be divided among Mail, .Mac Groups, and iDisk—and, of the iDisk space, a lot of that will presumably go toward sharing all your photos and videos and iWeb sites. You can use whatever’s left for sharing files or backups. But here’s the thing. Apple is still way behind the times; they should have done that two years ago and made yesterday’s upgrade another order of magnitude greater. At least. Compared with other Web/email hosting providers (because really, that’s basically what .Mac is), .Mac still gives you a fraction of the typical storage space at a higher price. For example, Dreamhost will give you 145 GB of storage (which, by the way, increases by 1 GB each week) in their cheapest plan, which is $9.95 per month—just $20 per year more than .Mac (and you can decrease that to $7.95 per month by prepaying for two years).

My particular area of concern here, though, is backups, because I’ve written a lot on that subject, and am at this very moment in the process of updating Take Control of Mac OS X Backups to say a lot more about, among other things, online backup services. If .Mac stacks up poorly against Web hosting providers, the comparison with online backup providers is even bleaker. Mozy gives you unlimited backup storage space for $5 per month. And CrashPlan is right behind—you get 50 GB for $5 per month, with additional gigs at 10 cents each (so, 100 GB would be $10 per month, and so on). That’s exactly the sort of space:price ratio where Apple should be. Previously, they were at 1 percent of that, and now they’re at 10 percent. I find that kind of insulting, as though I’ll see all the pretty graphics (yes, they are pretty) and forget that I’m still being overcharged and underserved.

Speaking of that 1 percent figure…I find it interesting that the new iMacs released yesterday can include up to 1 terabyte of disk space. Clearly, Apple expects you to fill up that space with all your excellent new media. Equally clearly, they expect you to put no more than 1 percent of it (10 GB)—or, maybe, 3 percent (30 GB)—online. That’s weird and sad. I say this even realizing the realities of internet bandwidth (sure, it’d take months to back up 1 terabyte over a DSL connection). That’s no excuse to let your competitors leave you in the dust.

All this is not to say I don’t find .Mac useful. I do find it useful—enough so that I keep renewing every year (even though I also have to supplement it with other services). And I’m happy that it’s gotten considerably more useful in the past 24 hours. But let’s not kid ourselves: this is one area in which Apple is still far, far behind the curve.

August 7th, 2007

Safe Sleep addendum

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.