TidBITS#1000/19-Oct-09 ====================== Issue link: A drum roll, please! This is our 1,000th issue of TidBITS (we're shocked too), and Adam shares some thoughts on where we are now and how we tell when we're doing a good job. But there's no time to rest on our laurels. Matt Neuburg explains how he tracked down a bug that will cause certain Apple events to fail and Rich Mogull recommends using Preview for PDF files to avoid Adobe Reader security vulnerabilities. Plus, Doug McLean covers Apple's acknowledgment of a data-destroying bug related to guest accounts, Microsoft's extension of Office 2004 support, and welcome new features in Gmail. Adam also explains how Find My iPhone can be used to increase comfort levels, covers Apple's In App Purchase policy changes, and walks through the new shared folders in Google Docs. Finally, Glenn Fleishman weighs in with some thoughts about how Apple missed the boat with the iPod nano's radio capabilities. Notable software releases this week include Acorn 2.1, Nisus Writer Pro 1.4, Phone Amego 1.0.8, Snapz Pro X 2.2.1, Performance Update 1.0, Airfoil 3.4, Cocktail 4.5.2, Evernote for Mac 1.5, Logic Pro 9.0.2, iMovie '09 8.0.5, SuperDuper 2.6.2, and Carbon Copy Cloner 3.3. Articles Apple Acknowledges Guest Account Data Loss Bug Microsoft Extends Support for Office 2004 In App Purchase Enables Free App Feature Unlocking Gmail Further Foolproofs Group Emailing Google Docs Adds Shared Folders for Easier Collaboration Protect Yourself from Adobe Acrobat and Reader Vulnerabilities Find My (Wife's) iPhone Tracking Down Snow Leopard's Apple Events Bug iPod nano Delivers Static in Radio Interface and Features 1,000 Issues of TidBITS: It's All about Our Readers TidBITS Watchlist: Notable Software Updates through 19-Oct-09 ExtraBITS for 19-Oct-09 Hot Topics in TidBITS Talk for 19-Oct-09 ------------ This issue of TidBITS sponsored in part by: -------------- * READERS LIKE YOU! Support TidBITS with a contribution today! Special thanks this week to Richard L. Sedlock, Archie Granot, Hugh Marsh, and Brian Van de Workeen for their generous support! * Get Fetch 5.5 for free! Fetch Softworks makes Fetch, the original Macintosh FTP client, free for educational and charitable use. Fetch 5.5 lets you edit and Quick Look all kinds of files. Apply today at ! * WebCrossing Neighbors Creates Private Social Networks Create a complete social network with your company or group's own look. Scalable, extensible and extremely customizable. Take a guided tour today * Bare Bones Software's BBEdit 9.2 -- A burly upgrade with new Sleep command, LassoScript support, plus enhancements to Projects and core features like Find and Multi-File Search windows, editing in browsers, and text completion. * THE MISSING SYNC: If you have a smartphone, we can sync it! Sync your address book, calendar, notes, music, pictures, and more between your BlackBerry, Windows Mobile, Symbian OS or Palm OS phone and your Mac. * VMware Fusion. The most seamless way to run Windows on your Mac. Backed by nearly a decade of proven virtualization technology. Try VMware Fusion today for only $79.99. Visit: * Microsoft's MacBU: Supporting Mac users with Office 2008. Straighten up your Office with the latest updates to Word, Excel, PowerPoint, and Entourage. Update today at Mactopia! * MacSpeech Dictate -- unleash the power of your voice with award-winning speech recognition solutions for the Mac. It's so easy to use - just talk! Now with spelling and phrase training. * StuffIt Deluxe 2010 gives you a free file-transfer service, built right into your Mac! Introducing StuffIt Connect, the easiest way to share large files online. Compress, secure, and send any file. Only $39.99 until 31-Oct-09! ---------- Help support TidBITS by supporting our sponsors ------------ Apple Acknowledges Guest Account Data Loss Bug ---------------------------------------------- by Doug McLean article link: 1 comment Apple has officially acknowledged a serious, though rare, data-erasing bug in Snow Leopard that's triggered by use of the guest account. When logging into the guest account, if the computer hangs, it is possible that, upon returning to your primary account, you'll find that all of the files and folders in your user account have been erased and that your account has been reset to default settings. Your account's path still exists on the hard drive, but _everything_ has been erased from within it. Apple responded to CNET's coverage of this bug with a prepared statement, saying only, "We are aware of the issue, which occurs only in extremely rare cases, and we are working on a fix." It's likely that we'll see Mac OS X 10.6.2 soon, perhaps sooner than it would have appeared otherwise, due to the severity of this bug. The three main discussion threads in the Account and Login forum on Apple's site are over 25,000 views and 100 replies as of this writing. Those are substantial numbers, but don't indicate a tremendously widespread problem, though that is likely due more to the generally infrequent use of guest accounts than the consistency of the bug's behavior. At this point, the specifics of how to reproduce the problem aren't clear, since most of the details have originated in discussion forums. For example, does the problem occur if you use fast user switching, if you log in from the Login window, or both? If you have two admin-level accounts and log into the guest account, are both erased? Until a fix becomes available, we recommend disabling the guest account temporarily by unchecking both "Allow guests..." checkboxes when configuring the guest account in the Accounts preference pane. This should eliminate even accidental use. Finally, consider this just one more reason to always be sure you have an up-to-date backup of at least your home folder, whether via Time Machine or another backup program! ---- read/post comments: tweet this article: Microsoft Extends Support for Office 2004 ----------------------------------------- by Doug McLean article link: Six months ago, Microsoft announced it would be ending "Mainstream Support," which includes security updates and other bug fixes, for Microsoft Office 2004 on 13-Oct-2009 (see "Microsoft Office 2008 12.1.7 and 2004 11.5.4 Updates", 2009-04-15). The five-year-old office productivity suite has now received a stay of execution, with Microsoft announcing on its Mac Mojo blog that it will extend support until 10-Jan-2012. In the post, Microsoft acknowledges that while many users have switched over to Office 2008, those who depend on Visual Basic for Applications (VBA) still require the 2004 version, as Office 2008 lacks VBA support. With the forthcoming 2010 release of Microsoft Office expected to bring back support for VBA, Microsoft says it wants to ensure continuous cross-platform support for those users who require it. While the extension means Office 2004 will have been supported for nearly 8 years by the time it reaches end-of-life status, Microsoft has made it clear that this does not change the standard 5-year support policy for other Office products. It's good to see Microsoft considering all of its Office users with this support extension, though we imagine that many of the users who rely on VBA in Office 2004 work in large enterprises with massive cross-platform installations. Selling a 10,000-seat license for the 2010 release of Office is a major incentive for Microsoft to keep those Office 2004 users happy for a bit longer. ---- read/post comments: tweet this article: In App Purchase Enables Free App Feature Unlocking --------------------------------------------------- by Adam C. Engst article link: 12 comments Apple has notified iPhone developers that the In App Purchase feature, previously restricted to paid apps, is now available for free apps as well. This is a huge change, and an about-face from the "Free apps remain free" response Apple originally gave in response to the question of using In App Purchase within a free app. We'll see the iPhone app world evolve in two significant ways as soon as developers start taking advantage of this change. First, and most obviously, it will be possible for a developer to distribute an app for free - say a comic book reader - and use In App Purchase to charge for individual titles. In the past, such an app had to cost at least $0.99 to be allowed to use In App Purchase. Such a change is welcome, if not all that interesting - is there that much difference between free and $0.99 for a reader when the primary expense will be ongoing content? Second, and most significantly, iPhone app developers will at long last be able to distribute a feature-limited version of an app for free, and use In App Purchase to unlock additional features. This should eliminate the commonplace approach of making free and paid versions of the same app. Everyone wins. The user experience is better, since users who like a free app don't have to go find the paid version and fiddle with replacing the free one. Plus, it should be easier to find apps in the App Store, because there will eventually be fewer free/paid siblings cluttering things up. Developers win, because they don't have to maintain two versions of an app, and I suspect the conversion rate from free to paid will be higher when it's done within the app. And Apple wins, both in terms of money and loyalty, assuming that users end up paying for more apps. There may be some confusion in figuring out how to handle reviews and ratings, since apps that allow unlocking of features stand to change quite a bit after that happens. Apple may have to differentiate ratings and reviews posted before and after an In App Purchase was made. ---- read/post comments: tweet this article: Gmail Further Foolproofs Group Emailing ---------------------------------------- by Doug McLean article link: 2 comments Google has added yet another feature to Gmail to protect against inadvertent mistakes. While it lacks the entertaining premise of the Mail Goggles, the new feature, named "Got the wrong Bob?", will likely prove popular with anyone who frequently writes to groups of people. Once activated, "Got the wrong Bob?" alerts you if it thinks you've included an unusual recipient in the group to which you're writing a message. By keeping tabs on the groups you most often write to, Gmail becomes your eagle-eyed friend, alerting you when you've likely mixed up two similarly named contacts. For example, if you were hosting a dinner with a regular gang of friends and wanted to invite your buddy Mike, but inadvertently included your obnoxious co-worker Mike instead, Gmail would double check with you to make sure you had the right Mike. A small alert under the address field pops up with the text, "Did you mean: X instead of Y"? Clicking X's name automatically plugs X's email address in the "To:" field, and removes the incorrect contact's address from it. Don't become too dependent on these alerts; the feature works only when writing to three or more people, and thus you'll still have to pay attention when corresponding with one or two colleagues. "Got the wrong Bob?" is a nice complement to an older Gmail feature that suggests additional recipients to a group email message when you may have left someone out. That feature, formerly referred to as "Suggest more recipients," has been renamed "Don't forget Bob." (Though I personally would have preferred "What About Bob?".) To activate either feature, log into your Gmail account, click the beaker icon in the upper right hand corner, scroll down, and click the Enable radio button for "Got the wrong Bob?" or "Don't forget Bob." (If the beaker doesn't appear, click the Settings link and then click the Labs link.) Then click the Save Changes button at the bottom. ---- read/post comments: tweet this article: Google Docs Adds Shared Folders for Easier Collaboration -------------------------------------------------------- by Adam C. Engst article link: 5 comments Google has updated Google Docs to include shared folders, a feature that has been requested by people who do a lot of collaboration on Google Docs. The problem is that although you can share any document in Google Docs with anyone whose email address you have, or even groups that you've created, you have to share every document intentionally and manually. In the real world, many documents are shared with the same set of people, over and over again, so it has been a bit clumsy to share each document in Google Docs individually. With the new shared folder feature, you can create a folder and share it with one or more people, and from then on, any document that you put in that folder will be available to them. As far as I can tell, Google Docs does not notify those with whom the folder is shared when new documents are put in it, but presumably, if you're sharing documents with the same people regularly, you undoubtedly have other channels of communication already in place. To be clear, the new shared folder feature in Google Docs works only with word processing documents, spreadsheets, and presentations that you've created in, or imported into, the Google Docs Web interface. It is _not_ a general purpose file sharing solution along the lines of Dropbox (which we use a lot for Take Control manuscripts; see "Dropbox: A Collaborator's Dream," 2009-02-03), SugarSync (see "SugarSync Sweetens Online Syncing," 2008-08-30) or MobileMe's iDisk. Although this Google Docs feature has just arrived (so we don't have a lot of experience with it yet), I've noticed two useful aspects of it that may not be obvious, and I have several wishlist items that remain. **Unusual Features** -- First, Google Docs implements folders much the way Gmail implements labels - they're essentially tags, so a document can exist in multiple folders. (You can even set the color of each folder individually, just as you can with labels in Gmail, for easy differentiation.) This is truly odd for those of us used to folders in Mac OS X, where files can exist only in a single folder (ignoring smart folders for the moment). But it's also extremely interesting when it comes to sharing, since the same document can be in a folder you share with your primary workgroup, and also in a folder shared with a remote colleague. The trick to making this work is that you must drag the file from one of the collections in the list above the folders in the Google Docs sidebar (All Items, Owned By Me, etc.) to one of your folders. Google Docs then assigns it to the destination folder, regardless of whether or not it is already in another folder, and it will appear in both. However, if you instead view the files in a particular folder and drag one of them from that folder to another folder, Google Docs removes the document from the original folder and places it in the destination folder, just like you're used to on the Mac. The second non-obvious aspect of shared folders that's worth noting is that just because you have a folder shared with a particular person or group doesn't prevent you from also sharing any document in that folder with additional people. So, for instance, I have a Take Control folder that I share with Tonya, since we always want to work on documents in it together, but we can share individual documents with particular Take Control authors when we need their input on something. **Wishlist Items** -- As last week's debacle with Microsoft erasing cloud-based data for T-Mobile Sidekick users illustrates (see "Cloud Data Blown Away for Sidekick Users," 2009-10-11), you really want a local copy of any data you have in the cloud, just in case the company maintaining that particular cloud does something mind-bogglingly stupid and loses your data. In an ideal world, Google Docs would automatically sync your documents with a folder on your Mac, using its export and import functionality to let you work on them locally or in the cloud, whichever is most appropriate. In fact, the Macintosh beta of a file-sharing service called Syncplicity promised exactly that feature, but I was unable to get it to work at all, and the company pulled the Mac version entirely not long afterwards. What Google Docs does have is offline access via Google Gears, which lets you view all your documents, spreadsheets, and presentations even when you aren't connected to the Internet, and it also lets you edit your word-processing documents. Unfortunately, although you can install Google Gears in Firefox if you're using Snow Leopard, the version for Safari isn't yet compatible with Mac OS X 10.6 (see "How to Use Google Docs Offline in Safari," 2008-09-01). So, if you're using Google Docs extensively, you might make a point of installing Google Gears in Firefox and accessing Google Docs in Firefox periodically as a way of making a backup. This is a little cumbersome for me, since I prefer to use Google Docs in a site-specific browser instance of Fluid, so Google Docs appears as its own application, rather than as tabs in Firefox. There's also an aspect of the way Google Docs handles shared folders that feels awkward: the distinction between "My folders" and "Folders shared with me." Because I created the Take Control folder that Tonya also shares, it's in "My folders" for me, and in "Folders shared with me" for her. That seems like an unnecessary distinction, and potentially a confusing one, if you want to maintain a similar folder hierarchy of your own. In fact, Tonya already has her own Take Control folder, so one of us will be deleting our folder in favor of the other person's shared folder. The reason for the confusion is that documents in Google Docs generally appear to be "local" to each user with whom they're shared, regardless of who created them. By distinguishing between these two types of folders, Google makes you think about who's in charge of the folder - you or someone else - regardless of the fact that the owner of the documents within those folders makes very little difference in regular usage. Despite my desire to have better local syncing of documents from Google Docs and the unnecessary distinction of whether folders are yours or shared, the addition of shared folders is something that's extremely welcome in Google Docs, and we'll be using it. ---- read/post comments: tweet this article: Protect Yourself from Adobe Acrobat and Reader Vulnerabilities -------------------------------------------------------------- by Rich Mogull article link: 4 comments On 13-Oct-09 Adobe released a major security update for multiple versions of its Adobe Acrobat and Adobe Reader products on Windows, Macs, and Linux platforms for flaws that could allow an attacker to take over vulnerable systems. Due to Adobe's atrocious security record, I recommend that all Mac users not only immediately patch Adobe Reader and Acrobat, but make sure they set Apple's Preview as their default PDF reader. Unless you need to access PDF files with Adobe's digital rights management protection, or commonly encounter PDF files that it can't display properly, Preview is more than sufficient to meet your day-to-day PDF viewing needs. Adobe Acrobat, a commercial product used to create PDF files, is harder to replace, but it's also far less commonly needed. Many Mac programs can generate PDF files directly, and Mac OS X has long had a Save as PDF command in the Print dialog, which enables you to turn anything you can print into a PDF. This likely won't meet the needs of marketing professionals, designers, or ebook publishers, but is sufficient for the average home user or office worker. The latest vulnerabilities affect Adobe Reader 9.1.3 and Acrobat 9.1.3, Adobe Reader 8.1.6 and Acrobat 8.1.6 for Windows, Macintosh and Unix, and Adobe Reader 7.1.3 and Acrobat 7.1.3 for Windows and Macintosh. These vulnerabilities allow an attacker to take over your computer even if all you do is view a maliciously crafted PDF file. For Windows users, this vulnerability was being exploited in the wild before the patch was released (what we in the security field call a "zero day vulnerability"). We have no evidence that Mac users are currently being exploited, but we also don't know of any technical obstacle preventing attackers from targeting Macs. Even on Windows, an attacker has to get you to open a malicious file, and while this attack is in the wild, it's certainly not widespread. In other words, your risk as a Mac user right now is quite low, but it's still prudent to patch. The vulnerabilities are fixed in Adobe Reader 9.2, 8.1.7, and 7.1.4, and in Adobe Acrobat Pro 9.2, 8.1.7, and 7.1.4. Though Adobe has updater programs, they fail sufficiently frequently that your best bet may be a manual download and update. Note that you will likely have to download and install each interim update in turn; the Acrobat 8.1.7 update, for instance, can install only on 8.1.6, not 8.1.5 or earlier. This isn't the first time the wings have fallen off the Adobe security plane this year. According to a recent report by the SANS Institute, this is at least the third time in the past 7 months that Acrobat and Reader were affected by critical zero day vulnerabilities. While the exploits have targeted Windows users, the vulnerabilities were potentially equally exploitable on Macs. According to Adobe's security page, the company has released nine critical updates, some patching multiple vulnerabilities, for Acrobat and Reader 9.x since February 2009. Adobe has struggled so much with patching that they have switched to a new quarterly patch schedule to help IT administrators keep their systems up to date with the latest security fixes. With such a poor security record, and considering the PDF support built into Mac OS X for reading and creating documents, it makes little sense to use Reader as your default PDF viewer on a Mac, and Acrobat users should ask themselves if they need the program's extra features. People who have switched over from Windows, in particular, often install and use Adobe Reader and Acrobat without realizing the native Mac software might already meet their needs. For example, a family member of mine who switched from Windows immediately installed Reader out of habit, not realizing she didn't need it to view most documents (and she has never found a PDF she couldn't view with Preview). There are exceptions. Preview can't open protected PDF files, and it may not render all PDF documents properly. The PDF file format has become extremely complex over the years, including support for JavaScript, embedded Flash content, and other advanced options. Acrobat includes far more extensive controls and content capabilities than simply printing to PDF, especially if you need to manage image resolutions and formats. Of course, this complexity in Reader and Acrobat is where a lot of these security problems come from in the first place. Adobe does recognize the risk these security issues create for their business. Earlier this year they launched a major security initiative to improve the quality of their code and their response process. This is a commendable move, but due to the complexity of software development these initiatives usually take years to manifest fully in released products. Since there is no risk unless you open a malicious file with Reader or Acrobat, one of the best steps you can take to limit the chances of future issues (aside from staying up to date with patches) is to set Preview as your default reader. Not that Preview is perfect, but we have yet to see it face the same number of zero day vulnerabilities or exploits. Changing your default PDF viewer is easy. Simply Control-click (or right-click) any PDF file and select Get Info. In the Open With section of the Get Info window, choose Preview from the pop-up menu, and click the Change All button. Your risk of being exploited is so low as to be unmeasurable, but since Adobe products (Reader, Acrobat, and Flash) are currently one of the main sources of cross-platform vulnerabilities, it makes sense to keep them up to date, and use them only when you really need them. ---- read/post comments: tweet this article: Find My (Wife's) iPhone ----------------------- by Adam C. Engst article link: 10 comments Don't get me wrong, I'm all in favor of privacy. But there are times and places when you very much want certain other people to know exactly where you are, without you having to do anything. The release of Find My iPhone with iPhone OS 3.0 came at a perfect time for us, since Tonya got an iPhone at the start of the summer, just as she was beginning to train seriously for the 100-mile AIDS Ride for Life, an annual fundraising event around here. As the summer progressed, Tonya needed to do ever longer training rides that would take 3 to 7 hours and cover 30 to 75 miles. (For the record, on 12-Sep-09, she did the full 100 miles - an amazing achievement!) During those rides, she always had her iPhone in her seat pack, turned on, but not attempting to run any special apps. When she stopped to drink or have a bite to eat, she would sometimes use Twitter to send me direct messages that would pop up on my iPhone courtesy of Boxcar, just so I knew she hadn't suffered a breakdown, injury, or accident. But she didn't stop often, and it wasn't always convenient for her to pull the iPhone out, particularly if it was raining. So although I didn't worry much, there were a few times when she was quite late in returning home because she'd decided to ride further than expected, or she stopped longer than she thought she would. On those occasions, and every so often during those long weekend rides, I'd log into her MobileMe account and use Find My iPhone to, well, find her iPhone. It was an easy way to check in and make sure everything was all right without interrupting her with a call or waiting for her to stop. Sometimes I'd even use Find My iPhone to display a message on her iPhone for the next time she pulled it out. (The most annoying aspect of Find My iPhone is that MobileMe times out your login quickly, so if you want to check an hour later, you have to log in again, and the entire Web interface for that is fussy. Another annoyance is that Apple prevents you from accessing the Find My iPhone Web page from an iPhone, so once when we were meeting at friend's wedding party 55 miles away, I couldn't find her because I had only my iPhone for Internet access. It would have been helpful that time too, since she took a wrong turn and needed a pickup, but luckily there was sufficient cell service for a call to get through. Since then, I've discovered a workaround, detailed in "Use Find My iPhone from an iPhone," 2009-09-30.) Before I hear any outraged gasps - how could I invade Tonya's privacy in this way! - let's be clear: she explicitly asked me to check up on her with Find My iPhone and made sure I knew her MobileMe password so I could log in to her account to do so. We're happily married and while we don't go poking into each other's computers on a regular basis, we're both entirely fine with the fact that the other should have full access to everything, just in case. I'd hope that's more the norm than the exception among married couples. Tonya was much more comfortable biking long distances from home on rural roads knowing that I would be likely to find her if she broke down in an area with extremely minimal cell service, and she felt less anxious about real threats like drunken target practice and hotrodding pickup trucks, not to mention intangible fears like swamp monsters. I wonder if this tension between wanting privacy and wanting certain people to know your whereabouts at any arbitrary time might be somewhat gender-based. As a guy, I don't often worry about making sure people know where I am when I go on long runs, and I'm not really afraid of anything out on the roads. But a number of the female athletes I know prefer to have someone know where they are when they're training alone, and if carrying an iPhone enables a spouse to check in from afar, that's a good thing. I'd go further and suggest that Apple should open up Find My iPhone slightly, so you could give select people access to it without letting them into your entire MobileMe account. Of course, you'd have to be able to revoke those privileges easily too, and it should probably alert you whenever your location has been requested, and by whom. Even better, Apple could make an iPhone app for Find My iPhone so you could use it easily while out and about with the people you trust. After all, if I'd had to go find Tonya 30 miles from home, it would be nice to be able to check easily if her location had changed from when I left the house, and in a scary accident scenario, I could see wanting updated location information quickly. Another nice addition might be a Map My iPhone feature that would display your iPhone's location at user-specified intervals, again, only to those to whom you'd given access. Especially in rural upstate New York, where cell service is often poor or nonexistent, being able to see a last known location with a time stamp could be useful. If you're looking for features along these lines now, AT&T does offer the FamilyMap service for locating your family's phones. It works with all AT&T phones, including the iPhone, though it doesn't take advantage of the iPhone's GPS capabilities and is thus limited to less-accurate cell tower trilateration. It costs $9.99 per month to locate two phones, or $14.99 per month for five phones. ---- read/post comments: tweet this article: Tracking Down Snow Leopard's Apple Events Bug --------------------------------------------- by Matt Neuburg article link: 15 comments No major system upgrade is without bugs, but it's surprising to find breakage in deep mechanisms that are crucial to the workings of the system as a whole and have operated perfectly well for many years. Surely, one thinks, Apple wouldn't mess with such a mechanism, on the grounds that (a) it's crucial and (b) it isn't broken so it's better not to fix it. Yet such is apparently the case with an Apple event bug that I isolated and reported to Apple on October 6th. What are Apple events, and why should you care about them? For a complete answer (with some really great diagrams), read the online book chapter I wrote some time ago on this topic. Briefly, Apple events are a messaging mechanism that allows one running process to communicate with another. Apple events are the underlying basis of application scriptability on Mac OS X; they are what allows AppleScript to work (for those who have forgotten, I wrote a book about AppleScript). Every AppleScript command directed at an application - asking the Finder for a folder's name, or asking iTunes for the tracks in an album - is an Apple event. But Apple events are far more fundamental than that; even something as simple as opening a document by dropping its icon onto an application's icon in the Finder relies on an Apple event. To be honest, although I'm proud of my detective work on this bug, I didn't have to think very hard, and my role in the story was rather passive. Here's what happened. On October 2nd, someone on the rb-appscript mailing list (which discusses rb-appscript, a bridge between the Ruby scripting language and AppleScript scriptability) posted a note complaining that his script, which drives iTunes rather intensively, worked perfectly well on Leopard but occasionally came to a grinding halt on Snow Leopard with an "Apple event timed out" error. Then, on October 4th, I noticed that someone on the AppleScript-Users mailing list was complaining that _his_ script, which drives Microsoft Entourage, worked perfectly well on Leopard but occasionally came to a grinding halt on Snow Leopard with an "Apple event timed out" error. At first I had been inclined to propose a theory that maybe some external force, such as a bad scripting addition, might be messing things up somehow. This was a reasonable guess, because the Snow Leopard transition to 64-bit has in fact caused existing 32-bit scripting additions to become troublesome. But the rb-appscript user (Nick Forge, who deserves a great deal of credit in this tale) was able to reproduce the problem even when all third-party scripting additions were removed from his system; moreover, he provided an extremely short, simple script that just looped so as to do one simple thing over and over, which he said would elicit the problem. So I tried his script on my machine. At first I couldn't reproduce the problem, but it turned out that this was just because I wasn't letting the script run long enough. When I allowed the script to run for 20 or 30 seconds, I got the same error message he did. Now my eyes were opened. We knew that the problem was not due to any particular scriptable application, because it didn't matter whether you targeted Entourage or iTunes. We knew that AppleScript was not the problem, because rb-appscript isn't AppleScript: they both use the underlying Apple events mechanism, but in different ways. And we knew that a perfectly good Apple event, if sent repeatedly enough times, would _eventually_ error out. But what did "eventually" mean? To find out, I wrote this script: set i to 0 try tell application "Finder" repeat -- forever set i to i + 1 count Finder windows -- this is the Apple event end repeat end tell on error errMsg number errNum display dialog i error errMsg number errNum end try In theory, this script should just run forever, repeatedly sending a single innocuous Apple event (one that asks the Finder to report how many windows it has open). Indeed, if you run it in Script Editor on Leopard, it _will_ run forever, and you'll have to force quit Script Editor (so _don't_ run it on Leopard; I'll present a "safer" version of the script in a moment). But in AppleScript Editor (the renamed Script Editor) on Snow Leopard, after about 60 seconds, the script freezes for an additional minute - because the "Apple event timed out" error is occurring - and then reports the error. The clever part is that the script also puts up a dialog reporting how many times we sent our Apple event before the error occurred. And here is the Really Interesting Part. In most cases, the reported number is somewhere around 65000. In fact, in some cases, it is extremely close to 65535. And that fact is highly suspicious, because 65535 is one less than 2 to the 16th power - the size of a "short integer" (a 16-bit value) in computer science. It's as if, behind the scenes, something _other than the script_ is counting our Apple events, and stumbling at the point where the count resets to zero. At that point, I wrote a "safer" version of the script and sent it to Apple. Here it is: set i to 0 try tell application "Finder" repeat -- forever with timeout of 5 seconds set i to i + 1 count Finder windows if i > 70000 then display dialog "No problem!" return end if end timeout end repeat end tell on error errMsg number errNum display dialog i error errMsg number errNum end try That version is "safer" because if by chance it gets past the 65535-event limit, it will come to a stop in good order all by itself. So you can try it on Leopard and on Snow Leopard and see the difference for yourself. Another feature of this version is the "with timeout" line, which shortens the frozen moment when our Apple event errors out from 60 seconds (the default) to 5 seconds. After I had sent the script to Apple, I posted it on the AppleScript-Users list, and a particularly knowledgeable user, Hamish Sanderson (who is, not coincidentally, the author of rb-appscript) wrote back and said: "I bet I know what's counting in the background: it's the increment of the return ID." That was the final piece of the puzzle. Here's what Hamish was saying. When a process sends an Apple event that expects a reply, there's no telling when the reply will come back. So there needs to be a way to associate the reply, when it does come, with the original Apple event. So when you send the Apple event, you specify a return ID - a "short integer" that identifies the Apple event. The reply is given the same return ID, so it can be matched up with the original Apple event. However, it is more common _not_ to assign your own return ID. Instead, you give a special return ID value called kAutoGenerateReturnID. This means that the system itself should dynamically assign the Apple event a return ID. And how does the system do this? By adding 1 to the _last_ return ID that it assigned. Thus, eventually, after enough Apple events have been sent, a moment will come where the next return ID in the sequence is hexadecimal FFFF, also known as decimal 65535. In a short signed integer, that value is the same as -1. And -1 _is_ kAutoGenerateReturnID. This fact, evidently, is confusing Snow Leopard in a way that no previous system was ever confused since 1991 (when Apple events were invented). When Snow Leopard assigns FFFF (-1) as the Apple event's return ID, it takes this as an invitation to increase the return ID _again_. So the Apple event goes out with a return ID -1, but the reply comes back with the _next_ return ID in the sequence, which is 0. The two return IDs don't match! Thus, the reply can't be associated with the original Apple event. So the sender thinks that _no_ reply has _ever_ come back - and, after waiting for a while, gives up and generates the "Apple event timed out" error. (I have also written a Cocoa application which repeatedly sends an Apple event and keeps track of the return IDs of both the sent Apple event and the reply, and proves that this account of the bug is correct.) The bug sounds minor, but it is really very important because Apple events are crucial to so much of what goes on under the hood in Mac OS X, and in any case it has caused everyone's scripts to break (whether written in AppleScript, rb-appscript, or anything else that sends Apple events). The underlying Apple event manager assigns a new return ID to every Apple event, and so sooner or later some Apple event is going to hit the magic FFFF value, and whatever sent that Apple event is going to error out, apparently randomly. You may even have seen such random errors on your machine without knowing it. Anyhow, it's an easy bug to understand, and there are already indications that Apple will roll a fix into the Mac OS X 10.6.2 update, whenever that comes out. What's hard to understand is how Apple came to inflict breakage on such a fundamental mechanism in the first place. ---- read/post comments: tweet this article: iPod nano Delivers Static in Radio Interface and Features --------------------------------------------------------- by Glenn Fleishman article link: 12 comments The iPod nano's user interface for analog FM radio tuning is atrocious. This statement has alarmed some of my colleagues, who see no problem with something that mirrors an old-fashioned radio dial, and which works precisely as expected. My strong dislike of the interface? It's unlike Apple to take a tedious and bad user experience and decide that's enough. Radio has a hoary history, dating back in the United States almost 80 years for AM and almost 70 years for FM. Despite the growth of streaming Internet radio, downloadable podcasts, subscription and purchase music services, and on-demand custom radio "stations," broadcast terrestrial radio still has tens of millions of regular listeners. Apple originally disdained the notion of embedding an FM radio receiver - AM requires too unwieldy an antenna - into its iPods. The iPod was about the future, in which clumsy analog transmissions were beneath Apple's dignity. Eventually, the company came around and started supplementing third-party FM add-ons with its own branded model. The iPod nano released in September 2009 became the first iPod to include a built-in FM tuner. That makes it likely we'll see FM tuners in more Apple devices. (Some colleagues, by the way, have suggested that the FM tuner is primarily for gym users who tune in to pick up in-gym audio from TV sets mounted over exercise areas.) But I'm confused about Apple's design choices in its first foray. Apple's Stan Ng told me in a briefing that Apple likes to bring something new to the table, and added FM tuning only when the firm had a unique take on the feature. But I don't believe the company delivered anything original, nor did it live up to its own design standards. Let me take that in two pieces: programming and storage options, and radio tuning, with a brief detour into digital radio. **Buffer Underflow** -- With the nano, Apple added iTunes Tagging directly within an iPod, something that previously required a dock and a digital HD Radio receiver. But this isn't particularly interesting or unique. iTunes Tagging is an Apple-specific method of linking an over-the-air song to a purchasable item in the iTunes Store. It's about commerce, and it's about Apple. One could argue it's also a memory aid - what was that song I was listening to? So far, only Clear Channel is using the specific format Apple requires - RT+ or RadioText Plus - although it sounds like there's now huge interest in providing this data. (RT+ isn't proprietary, but provides more metadata formatting than other options, which makes it simpler to match up songs listened to those that can be bought.) Microsoft offers a different form of tagging for the Zune HD that's far better at dealing with both analog FM and digital FM song and artist information. What's strange is that one company, Jump2Go, provides tagging technology for stations that powers both Apple and Microsoft's efforts. Microsoft clearly chose what must be a less precise but more inclusive method of matching song information than Apple. **The Pause That Distresses** -- The iPod nano also includes a pause button for radio, which can track as much as 15 minutes of audio history. This pause feature isn't as useful as that provided by Sirius in its portable satellite receiver, the $169.99 Stiletto 2. The Stiletto 2 can store up to 100 hours of programming that you can schedule it to record, plus 10 hours of individual songs, and it can rewind up to 60 minutes on a single channel you're tuned to. True, the Stiletto 2 requires a monthly subscription to Sirius (ranging from $6.99 to $19.99, depending on programming options), but broadcast radio is simply free, and thus not dependent on any particular provider. A monthly subscription shouldn't be part of any limitation. The Stiletto 2 is larger, roughly the size of an iPod classic. But that, too, shouldn't be an issue. With 8 or 16 GB of storage, it's hard to understand why an iPod nano can't buffer a selectable amount, up to 60 minutes or longer. Also an odd omission is the iPod nano's inability to record programming for later. Many writers described the iPod nano pause feature as "TiVo for radio," but TiVo can timeshift: record now, play later, not just pause. Scheduling might be tricky - yet another interface would have to be jammed into the already overflowing iTunes 9 - but it's certainly not impossible. Even something as simple as "record the next 2 hours on such-and-such preset station" could be easy enough from the iPod nano's scroll wheel. An inability to record programs, with scheduling or not, smells very much like Apple attempting to keep record companies happy. Satellite radio had a minor battle about recording music, and various compromises were put in place; Sirius pays licensing fees, too, which certainly helped. And music can't be exported from the Stiletto 2 player. **Highly Omitted** -- You might note that I don't complain that the iPod nano can't record digital FM, marketed under the name HD Radio by the sole approved U.S. format's owner, iBiquity. The Zune HD tunes in high-quality digital FM programming offered by about 15 percent of U.S. radio stations, including many public radio stations. Digital FM broadcasters can also choose to add additional lower-fidelity channels, and many stations now do. The FCC still requires that the first HD Radio channel for an FM station is a mirror of the analog broadcast. The reason is that the iPod nano is so tiny that's there no way to include the first-generation portable chips needed for HD Radio tuning. It's also unclear whether, beyond the digital aspect of HD Radio, there's much demand for the feature. In Seattle and most major metropolitan areas, all major commercial and public radio stations supplement analog with digital; but that's still just a fraction of the whole. It's possible that Apple might choose to put an HD Radio receiver in the iPhone, iPod touch, or iPod classic. Since Microsoft pulled off digital radio in a small form factor, one should expect that Apple could, too. **Dial Tone Deaf** -- We get at last to the nub of my complaint with the iPod nano. Yes, tagging; yes, pause; whatever. Many folks are and will be far less annoyed by limitations there (and some of those limits could be erased with radio station upgrades and firmware changes). But what got my goat when I fired up the radio in the iPod nano was how ridiculous it is in 2009 to use an interface that mimics an analog tuner. I don't need to see the frequencies. I don't even particularly need to care. The FCC licenses frequencies and assigns call letters to each broadcast radio station. Most radio stations send out their call letters via the low-speed data embedded in analog signals - Radio Data System or RDS. The iPod nano (and Zune HD) picks up this data, which can include artist and song information as well as road traffic updates, and displays it. If you tune to a station, the call letters are extracted when you create a preset and used for selection rather than the frequencies. The experience of tuning on the iPod nano would be fine, if it were a car radio. The scroll wheel is used to move around. Hold down the center button to get a menu that lets you add the station to favorites. Press Menu to get a menu that lets you bring up the favorites menu. Press rewind or fast forward to jump to the next station; hold down either button to scan up or down the dial. My gripe? There are discrete radio markets around the country. Apple could scan through a subset of frequencies to pick up active signals and station call letters, and then use a stored database likely of no more than 50 KB (yes, 50 _kilobytes_) that associated stations in all U.S. markets. (This would work in most other countries, too, for analog radio.) With as few as one or two radio stations and call letters, the iPod nano could offer - if the stations were other than what was stored - to load the radio with the local station map. You could customize that (removing stations you don't listen to). And when you took your iPod nano to a different city, the iPod nano could recognize that and say something like, "It looks like you're in Raleigh, North Carolina. Should I load the Raleigh station list?" The station's format (country, classics, news, public radio) could be noted, too. I could go one step further, and suggest that with the market known, other data could be loaded - schedule information for tuning, if not recording - although that would require constant updates and a lot more tweakiness on Apple's part. That information is commercially available, however, and Apple could relicense and shoot the small amount of data to an iPod nano updating it every few days during syncs. An advanced menu option or a button held down could bring up a tuner for low-power stations or repeaters, common in rural areas. This would also work for gym workout room tuning. This is just one approach to how this could work, and I don't claim to be as smart about interface design as the folks at Apple clearly are. But I simply ask: who cares about the cycles per second at which a station is exciting atoms in its tower? Aren't we really interested in the station name (if we know it) or the format (if we don't)? **Tune In, Tune Out** -- For another company, these would be either minor cavils, or laughable complaints, far beyond the infrastructure and software capabilities of the firm. Apple, however, appears to be able to build a phone that can integrate GPS-style data from multiple sources, make it available via an API; or, in an off afternoon, embed a video camera into a pack of gum. (I don't like the iPod nano's video quality, but it's still remarkable for its size.) For Apple to add any feature, it needs to be best in class, and a rethought-out way to carry out a process we've become so used to, we forget how much time we waste. Radio storage and tuning needs another trip to the whiteboard at Apple. ---- read/post comments: tweet this article: 1,000 Issues of TidBITS: It's All about Our Readers --------------------------------------------------- by Adam C. Engst article link: This marks our 1,000th issue of TidBITS, and we can barely believe that we've arrived at this point, more than 19 years after Tonya and I took our first tentative publishing steps in April 1990. But here we are, going strong and writing and publishing more than ever before. When we were chatting on our staff list about what to write about issue 1,000, Matt Neuburg jokingly said, "Nothing!" His point was that over the last few years we've transitioned our primary publishing unit from the weekly issue to the individual article, with articles going live on the TidBITS Web site as soon as they are ready for public consumption. Obviously, issues continue to exist; otherwise, there wouldn't be 1,000 of them. We still send out numbered email issues weekly, assembling them from the articles we've published on the Web over the previous week. Plus, we (specifically, Jeff Carlson, Joe Kissell, and I) edit each article again over the weekend and all day Monday so the email issue is polished to best reflect the current state of affairs. And with nearly 31,000 subscribers to our four editions (full text editions in both text and HTML, and announcement editions in text and HTML), more people read TidBITS in email than any other way. But thanks to the Web and our transition to an article-based model, email is slowly becoming less of a focus than it was in the past, when our Web site was merely an archive of what we sent out in email. Now, individual articles on our site are generally read by several thousand people, and our RSS feed is read by over 15,000 people each week. Sometimes, when an article is linked on an aggregator site like Daring Fireball or Slashdot, it might be seen by 20,000 or more people. As much fun as it is to pore over these large numbers - and everyone on the TidBITS staff certainly pays attention to them - we've started to think about what those numbers mean beyond how subscriber counts and page views can be converted to income. For example, although we do use Google AdSense to display a few ad units on our Web site, Web display advertising will never be a significant source of income for TidBITS. For instance, if we were to make somewhere between $350 and $450 per month from Google based on 250,000 to 350,000 page views, even doubling those numbers wouldn't bring in a single staffer's monthly salary. (Most TidBITS-specific income comes from our industry sponsorships, which are about connecting with a community and aren't tied to page view numbers.) No, what's always been important about TidBITS, and what we increasingly appreciate as Internet behavior seems to devolve ever further, is the quality of our readers. When I hear colleagues at other publications complaining about snide comments or irate email from readers, I thank my lucky stars that we don't have to deal with that sort of constant drama. And so it is to our readers that we're now looking when we try to determine whether we're doing a good job. Not in raw numbers, though obviously, if very few people use some feature we've provided, either the feature isn't helpful or we've done a poor job of alerting readers to its presence. Instead, we're looking at the quantity and quality of interactions with readers, and trying to figure out ways we can improve both. For instance, the TidBITS Commenting System that Glenn and Jeff and I designed has been, in our estimation, a huge success. Most articles receive comments, with 10 to 15 comments on an article being entirely common. (The most-commented article so far - with 91 comments in the 30 days we leave commenting open - was my "Have We Entered a Post-Literate Technological Age?", 2009-08-18). Even better, the comments often add helpful context or details, ask questions whose subsequent answers extend the utility of the article in unanticipated ways, or point out things that could use revision (we always leave another comment noting when we've revised the article to address such an omission). We don't publish comments in our email issues because the size would become unmanageable, but we show the number of comments on each article and link to them because we want to make it easy for you to read comments and leave your own. I'm actually not surprised at the quality of comments on our site, since the same has long been true of discussion in TidBITS Talk, where free-ranging conversations about Apple-related topics continue unabated, even after we unveiled the TidBITS Commenting System. We see the Take Control ebook series as a significant success for TidBITS as well. Obviously, with Take Control, sales are the primary marker of success, and those sales have helped fund many of the back-end changes that have modernized the TidBITS Web site and that are transitioning the Take Control Web site from a hand-coded, organically grown operation to a database-driven site with (coming soon!) user accounts. It is also gratifying that the ebooks have contributed significantly to the incomes of a number of our friends, helping them to remain self-employed, independent writers. Beyond the money, though, numerous readers have written in with grateful notes, so we know that the ebooks are appreciated by many for their unique qualities. Having readers who buy nearly all our ebooks or who are able to use their Macs much more effectively due to reading them tells us that we are doing a good job. We routinely see an incredibly high quality of question and comment on the books, which in turn allows us to refine and improve the books to reflect what people need to know. Although we don't have high follower numbers, the TidBITS Twitter account (it tweets headlines and links to new articles in real-time) continues to grow, closing in on 1,300 followers. But what I appreciate more is observing my search results for @TidBITS in TweetDeck, since I figure that any time someone retweets or mentions a TidBITS article in Twitter and credits us, that article must have been particularly useful or interesting. With Twitter, interpreting retweets as expressions of approval is important; Twitter isn't a significant source of Web traffic for us yet. Even when O'Reilly Media head Tim O'Reilly posted a tweet linking to my "Have We Entered a Post-Literate Technological Age?" article, it garnered only a handful of reads that I could track back to Twitter, despite theoretically being seen by Tim's 975,000 followers. Other initiatives haven't been as successful. TipBITS, which allows us and readers to post tips in the right sidebar of our site, gives us a handy means for providing tip-based content, but it hasn't received many submissions from readers. The interface is slightly more cumbersome than the TidBITS Commenting System, but I suspect the real problem is that people are more intimidated by publishing a standalone item than by leaving a comment. We'll continue to fiddle with it, but if it ends up containing mainly staff-generated content that Web site visitors find useful, that's acceptable. Colin Crawford, previously the president and CEO of Macworld Communications and now with IDG Ventures, recently commented to me via Twitter that "Value is in engaged communities - that's where media companies need to focus." Colin has been watching and working in the media industry for a long time, and I think he's right. That's why seeing how our readers jumped on the TidBITS Commenting System and - from the business standpoint - seeing how well-received our Take Control ebooks have been has been so satisfying. We've long since abandoned our tongue-in-cheek (and obviously missed) goal of world domination by the year 2000, and it's clear that TidBITS is unlikely to become the most-read publication on the Internet, or even in the Apple world, since we prefer to focus on the most important news and products, rather than covering every little thing or stirring up attention-getting controversy. And you know what? That's fine by me. If the business end of TidBITS via Take Control and TidBITS sponsorships can make it possible for us to continue publishing high-quality content that helps our readership to be more productive and to engage with the rest of the TidBITS community in a constructive fashion, I'm happy. As much as it seems almost unthinkable to say this, here's hoping we're still going strong in another 1,000 issues. Thanks to you, our readers, for making it possible, and thanks too to our sponsors, our editors, our translators, and everyone else who has contributed to TidBITS in some way. ---- read/post comments: tweet this article: TidBITS Watchlist: Notable Software Updates through 19-Oct-09 ------------------------------------------------------------- by Doug McLean article link: Acorn 2.1 from Flying Meat is a maintenance update to the simple image editor. Changes include support for AppleScript, a new Hex Color Picker, a refreshed interface, JSTalk support, 64-bit support, and raw image support. Also there's now an option to view rulers alongside your images, layers can be organized into hierarchical groups, and individual windows can be given their own layer when taking screenshots. Finally, various editing tools have been added including Dodge, Burn, Clone, Smudge, Perspective Transform, and a Clouds filter. ($49.95 new, free update, 8.1 MB) Nisus Writer Pro 1.4 from Nisus Software is a feature update to the increasingly powerful word processor. The latest version adds several built-in commands to replace macros that come with the reference manager Bookends. These menus enable you to scan documents, insert citations, locate references, and switch to Bookends without leaving the program. ($79 new, free update, 151 MB) Phone Amego 1.0.8 from Sustainable Softworks is a maintenance update to the software that enables users to control a Bluetooth mobile phone (including the iPhone) from a Mac. The latest version adds improved and expanded Google Voice login options, the capability to choose various numbers for a single contact in the Call window, support for landline phones using the Apple USB modem, the option to select a dial device from the Call window, and the capability to distinguish Google Voice calls from other incoming calls. ($20, free update, 1 MB) Snapz Pro X 2.2.1 from Ambrosia Software is a minor update to the popular still image and video screen capture utility. The update fixes a hotkey conflict with Japanese character input in Snow Leopard, addresses a console warning that erroneously appears when putting the display or computer to sleep, and reinstates recording support for PowerPC-based Macs running Mac OS X 10.4 Tiger. Also, performance has been improved when saving QuickTime movies, and several other minor unspecified bugs have been fixed. ($69, free update, 11 MB) Performance Update 1.0 from Apple "addresses intermittent hard drive related pauses reported by a small number of customers." The update is for Intel-based Macs (mostly laptop models, with a few iMac and Mac mini models thrown in), and is available via Software Update or from the Apple Support Downloads page. Installation steps can be found on Apple's Web site. (Free, 300 KB) Airfoil 3.4 from Rogue Amoeba is a significant update to the wireless audio distribution tool. The latest version improves hijacking capabilities for applications with audio sub-processes - including Google Chrome and Dashboard - by combining them into a single group. Hijacking in QuickTime Player, Safari, and other WebKit applications is now instantaneous and no longer requires that the application be restarted. Also, the Instant Hijack component has been improved, fixing several rare but serious Snow Leopard compatibility issues. Lastly, a new Radio Tuner window has been added for those using Griffin Technology's Radio Shark USB radio with Airfoil. ($25, free update, 10.1 MB) Cocktail 4.5.2 from Maintain is a maintenance and stability update to the general-purpose maintenance utility. The latest version addresses a number of problems including a bug that led to high CPU usage on 32-bit Macs, an issue that caused Cocktail to sometimes incorrectly report problems with disk utility, compatibility issues with QuickTime X, and a number of other minor unspecified bugs. ($14.95, free update, 2.0 MB) Evernote for Mac 1.5 from Evernote is a maintenance update to the note-taking and snippet-collecting utility. The latest version adds the capability to view Ink notes created with the Windows client, optional access to Evernote's beta program via Software Update, and localizations for the French, German, Italian, and Spanish languages. Also, your email address is now shown in the Account Info window, and several bugs have been fixed, including one that addresses a problem with the Safari toolbar button knocking other buttons off the toolbar and another that prevented words surrounded by punctuation from being located by search. (Free, 15.8 MB) Logic Pro 9.0.2 from Apple is a stability and maintenance update to the company's flagship audio recording program. Changes include the capability for Flex Markers to align and snap to MIDI notes, proper punch-in recording behavior with Replace Mode, an added option for latency measurement in the I/O plug-in, and the TDM plug-ins now work correctly. The full release notes are available on Apple's Web site. The update is available via Software Update or the Apple Support Downloads page. ($499 new, free update, 183 MB) iMovie '09 8.0.5 from Apple is a compatibility update for Apple's video editing program, a component of iLife '09. In addition to improving support for importing video captured using the latest iPod nano, this version introduces support for iFrame, a video format employing H.264 video and AAC audio compression. (Sanyo introduced the first two cameras this week that record in the iFrame format: the Sanyo VPC-HD2000A and the Sanyo VPC-FH1A.) What's notable about iFrame is the capability to edit the footage natively in iMovie; footage recorded to memory or to hard disks using the widely adopted AVCHD must first be transcoded to AIC (Apple Intermediate Codec) before editing. iFrame promises to reduce the time it takes to start editing and also reduce the amount of disk space used by the video. iMovie '09 8.0.5 also fixes an issue with resizing the application window during playback. (Free update, 35.56 MB) SuperDuper 2.6.2 from Shirt Pocket Software updates the backup and disk cloning utility with several new features and improvements. Changes include enhanced performance, a new Backup on Connect feature that kicks off a backup when the destination volume appears, a new Eject After Copy feature, and support for sparse bundle disk images. A full list of changes can be found within program by selecting Help > Revision History. The update supports both Intel- and PowerPC-based Macs running Mac OS X 10.4 or later. ($27.95 new, free update, 2.8 MB) Carbon Copy Cloner 3.3 from Bombich Software is a maintenance update to the long-standing backup and disk cloning utility. Changes include support for HFS+ filesystem compression, enhanced Finder and Disk Utility compatibility in Snow Leopard, and improved performance when backing up multiple files with extended attributes. Also, several issues have been addressed, including a bug that caused the program to incorrectly report an inability to delete a conflicting report on a target when using the "Archive modified and deleted items" option, a bug that caused the Time Machine database to be included when using the "Backup everything" cloning method in file-level mode, and a bug that prevented the source and target menus from being updated if a disk disappeared in the midst of a backup task. A full list of changes is available on Bombich Software's Web site. (Free, 3.2 MB) ---- read/post comments: tweet this article: ExtraBITS for 19-Oct-09 ----------------------- by TidBITS Staff article link: **A Snow Leopard Photo You Can't Miss** -- An amazing photograph of a snow leopard in its natural habitat has won photographer Steve Winter the prestigious Wildlife Photographer of the Year award for 2008. The stunning photograph was the result of 13 months spent tracking and photographing the cats in the mountains of Central Asia. (Posted 2009-10-19) **Sidekick Reversal: Microsoft Recovers Most User Data** -- Good news for T-Mobile Sidekick users: after a week of effort, Microsoft has said that it has recovered most, if not all, seemingly lost user data, including contacts, photos, and other material, and is starting a restore process. Microsoft also said it believes the problem affected only a minority of users. (Posted 2009-10-15) **iPhone Distracts Bear from Mauling Hiker** -- CIO.com's Tom Kaneshige recounts the story of Kris Rowley, chief information security officer for the State of Vermont, who encountered a young bear while hiking. With nothing else at hand, she threw her iPhone at the bear to distract it, then made her escape. The end result? She recovered the iPhone two days later, but apparently, iPhones are not bear-resistant. (Posted 2009-10-13) Hot Topics in TidBITS Talk for 19-Oct-09 ---------------------------------------- by Jeff Carlson article link: **Time Machine kills backups** -- Time Machine deletes old backups when the hard disk is full, but is this the proper behavior in unusual circumstances? (23 messages) **Is AT&T Unlocking iPhones after contracts up?** AT&T won't automatically unlock an iPhone, leading to discussion of whether it should and why one would want an unlocked iPhone. (14 messages) **Digital camera problem** -- Plugging a camera into the USB port of a keyboard may not provide enough power to transfer images. Learn how to work around the problem. (19 messages) **Quicken's Future?** When Intuit finally delivers a new version of Quicken, what will it be like, and what assurances to users have about the safety of data stored online? (5 messages) **Access denied problem syncing Macs** -- A permissions issue seems to be blocking synchronization between a reader's two machines, but will repairing permissions have any effect? (4 messages) **A "fusion" bug in iPhoto (8.1)** -- Merging events in iPhoto leads to unexpected behavior for a reader. (5 messages) **Webcam for my mother-in-law** -- A reader asks for opinions on buying a webcam that works better than the most inexpensive models. (3 messages) **Audio Interface for Mac Pro?** After accidentally damaging his Mac's audio-in port, a reader looks for a workaround for digitizing albums. In a related topic, opinions are offered about the Ion USB turntable. (5 messages) $$ This is TidBITS, a free weekly technology newsletter providing timely news, insightful analysis, and in-depth reviews to the Macintosh and Internet communities. Feel free to forward to friends; better still, please ask them to subscribe! Non-profit, non-commercial publications and Web sites may reprint or link to articles if full credit is given. Others please contact us. We do not guarantee accuracy of articles. Caveat lector. Publication, product, and company names may be registered trademarks of their companies. TidBITS ISSN 1090-7017. Copyright 2009 TidBITS: Reuse governed by Creative Commons license. Contact us at: TidBITS Web site: License terms: Full text search: Subscriptions: Account help: