Apple has now released Aperture 3.0.1, claiming to fix significant reported problems with the new edition of the professional photo management tool. Although every new software release endures some bumps after being exposed to systems outside its testing pool, I heard from many photographers, TidBITS readers, and other colleagues that Aperture 3 seemed as if it was shipped too early. (I’ve used it a little following its release earlier this month – see “Apple Releases Aperture 3,” 9 February 2010 – and experienced one outright crash and sluggish behavior, but not enough to pass judgment.)

According to the release notes for version 3.0.1, the update improves overall stability and focuses on fixes for upgrading from earlier versions of Aperture and importing photos from iPhoto and directly from cameras. Memory usage is improved “when processing heavily retouched photos,” and there are improvements to the new Faces and Places features, which all seemed to be problematic flash points for users.

Other changes include fixes when printing multiple images or contact sheets, editing photos using an external editor, displaying photos with Definition and Straighten adjustments applied, accessing Aperture libraries on a network volume, and more. The update is available via Software Update or as a standalone 29.41 MB download.

What with all the emphasis these days on the iPhone, it’s always nice to hear that the Mac is still going strong. The latest data comes from the Enterprise Desktop Alliance, a consortium of enterprise software companies that focuses on the needs of multi-platform enterprises. The EDA’s just-concluded survey found that 66 percent of 322 IT administrators from large multi-platform organizations expect to increase the number of Macs at their sites in the coming year. (To be fair, that number is down a bit from last year, when 74 percent of respondents predicted increases, with 73 percent actually seeing increases.) The main reasons cited for choosing Macs come as no surprise: user
preference, increased productivity, and ease of technical support.

The survey also asked respondents about the major issues confronting IT administrators in multi-platform organizations. The top two issues, which ranked as “very” or “extremely” important to 79 percent of the respondents, were file sharing between operating systems and security, followed closely by client management, Active Directory integration, and cross-platform help desk and knowledge base support. Interestingly, although parity between Macs and PCs in the organization remained important to 81 percent of the respondents in 2009, that number is down from 94 percent in 2008.

You can download a PDF with more details about how the survey was conducted and with additional results.

If you’re working in a multi-platform enterprise, let us know in the comments if you’re seeing more or less emphasis on the Mac in your organization, and what the main issues are.

Google’s YouTube is dropping future feature upgrade support for certain older browsers, most notably Internet Explorer 6 for Windows. But reader Mike Lemon discovered and alerted us that the last release of Firefox for Mac OS X 10.3.9 Panther – version 2.0.0.20 – will also be dropped from supported browsers. Safari 1.3.2, the last version of Safari that works under Panther, is also too old for further development.

YouTube explains on a FAQ page that dropping support doesn’t mean videos will no longer play in older browsers. Rather, new features won’t be engineered to work on these ancient releases. YouTube will fully support Firefox 3.0+, Chrome 4.0+, Internet Explorer 7.0+, Opera (no version noted), and Safari 3.0+.

Panther users who want to have access to future YouTube improvements have just one choice that I can find: Opera 10, which is still compatible with both Intel- and PowerPC-based Macs.

While Panther users may be stuck in time, Mac OS X 10.4 Tiger users have access to the latest version of Firefox (3.6) and Safari 3.2.3, among other browsers. (The Mozilla Foundation that manages the code base used for Firefox, Camino, and other browsers said on 8 February 2010 that it would drop Tiger support in the rendering engine that will be part of Firefox 3.7.)

YouTube started inserting interstitial messages in mid-2009 to warn users of older browsers; the message requires a click to bypass and view a video. The messages were set to appear every two weeks – ostensibly relying on cookies to avoid repeating. This is the first I’ve heard of it, and there’s scant documentation on the Internet about it.

Google has also announced that, as of 1 March 2010, Google Apps will stop supporting older browsers too. Google will start by phasing out support in Google Docs and Google Sites, and the elimination of support will no doubt make its way out to other Google services over time as well.

Frankly, we’re entirely in favor of Google taking a stand on the use of these old browsers, Internet Explorer 6 in particular. The TidBITS Web site has never rendered well in Internet Explorer 6 because its support for basic Web standards was so lacking, and we couldn’t justify spending significant time and effort on such an old browser for a non-Apple platform. It’s a little too bad that those people left on Mac OS X 10.3 Panther will start to see a loss of functionality, but those older browsers simply don’t have the capabilities Web developers need to offer a modern Web site.

I just received a note from Adam Engst informing me that my Address Book “has gotten whacked and is sending messages to [email protected] instead of [email protected].” That seemed like an odd mistake to make, since the “sponsors” address (which he uses to prioritize communication with our sponsors and potential advertisers) doesn’t even appear in my Address Book database.

The actual culprit is Apple Mail’s Previous Recipients list, which stores recent email addresses for later auto-completion when you start typing someone’s name or address in a recipient field. In this case, I’d recently received a message from Adam when he was using [email protected], which was added to the list. When I typed “Adam” in the To field of an outgoing message, Mail auto-completed the entry as “Adam Engst, [email protected]”. I was typing quickly and didn’t notice the address before moving on to the next name – hence the puzzled reply from Adam.

To work around the problem, you can remove the address from the Previous Recipients list in one of two ways:

• Choose Window > Previous Recipients to display the list, then scroll or search the list to find the address you want to remove. Select the entry and click the Remove From List button.




• If you’ve already typed the address, click the down-facing triangle that appears in the name’s container to reveal a contextual menu. Select Remove from Previous Recipients List from that menu.

This removal feature is designed so that if you mistyped someone’s information at one point, you can remove that erroneous address so you don’t trip over it again.

However, those steps fix the problem only temporarily; the next time Adam includes me on a message from the sponsors address, it will again be added to my Previous Recipients list.

Also, there was another oddity: I would have thought that Adam’s regular address would appear first in any list, since I use it far more than the other address, but that wasn’t the case. Instead, the sponsors address appeared first because the name associated with it was “Adam Engst”, while the entry in my Address Book database is “Adam C. Engst”. Apparently, a name with no middle name is alphabetized higher than one with a middle name, which also gave me the clue as to how to fix the problem permanently.

Instead of removing the sponsors address, I chose Add to Address Book (available in either of the two methods mentioned above) and changed the name to “TidBITS Sponsorship Program” (to make sure I really don’t stumble on it later). Now, Adam’s main address appears first in the list. I can press the comma, right-arrow, or Tab keys to lock in the correct address and move on to the next field without wondering if I’ve misdirected the mail.

For safety’s sake, I use a different, randomly generated password for every Web form I encounter. Since I don’t know any of these passwords, I store them, password-protected, using a password keeper application. But this technique, although it’s pretty secure (unless someone sneaks into my house and bonks me over the head while the password keeper is open), works only if I’m sitting at my own computer. How can I access these passwords safely and securely from any computer?

Enter Clipperz.

I first heard about Clipperz on an IT Conversations podcast, and my immediate reaction was, “Why didn’t anyone tell me about this sooner?” Clipperz is a Web application, so you navigate to it in a browser; thus, you have access to your online passwords exactly when you need them, namely, whenever you’re online. When you arrive at the clipperz.com Web site, you enter your username and a master passphrase; the guessability of this combination is the weakest link in the chain, of course, so you should use a rather long and unnatural passphrase. However, the passphrase itself is not sent to clipperz.com during login. In fact, clipperz.com doesn’t know your
username, your master passphrase, or any of your passwords!

How can this be? Well, clipperz.com is what’s called a “zero-knowledge database.” It doesn’t store anything in cleartext; everything is encrypted, and clipperz.com doesn’t have the key. All of the stored data is encrypted; communication with Clipperz is also encrypted (doubly so, since it also is transmitted using SSL). All the encryption and decryption happens at your end – in the browser. This is possible because of the speed of modern computers and JavaScript implementations (JavaScript data is lost when you change Web pages, so Clipperz uses AJAX to refresh screens while keeping you on the same page). Moreover, the
apparent weakest link, the initial password-based authentication, uses Secure Remote Password (SRP) authentication, which is itself zero-knowledge (clipperz.com knows only a public key derived from your username and passphrase), and is as secure as password-based authentication can possibly be – probably vastly more secure than any other password-based authentication you ever do on the Internet. Finally, all of Clipperz’s code is open source – since, as you doubtless know, security by secrecy is the worst security of all.

The screenshot shows the simple interface that you see once you’re logged in. It’s a straightforward “rolodex” of information. Down the left side run the names of your “cards”; click the name of a card and you’re shown its “fields.” I’m not afraid to show you this because the password field is always portrayed as six stars, which you can copy (using Command-C, not Control-C as stated in the screenshot) to paste into the password field of a Web form, which is presumably open in another window. (If you’re on a public machine, remember to copy something else onto the clipboard later, so as not to leave your password there in cleartext.) You can also “unscramble” the password, showing it directly in cleartext; this is safe as long as no
enemy spies are sitting behind you.

Naturally, online passwords are not the only data you might store securely this way. You could keep credit card numbers or anything else you might need while online. A card’s fields are customizable, so you can set up a card to display whatever might be appropriate for a particular datum.

Another cute feature is that you can set up “one-time passwords.” These are login passphrases for clipperz.com that are deleted as soon as they are used. As every reader of spy novels knows, a one-time pad is the most secure form of encryption. So if you’re in a public space, use one of your one-time passwords; even if a spy sitting behind you can memorize your finger movements on the keyboard, that knowledge will be useless.

And here’s the icing on the cake. I’ve said that the encryption and decryption happens in the browser; I’ve also said that the data stored at clipperz.com is encrypted. Hence, there is no loss of security if you store the data from clipperz.com on your machine. And that is just what Clipperz allows you to do. You can download a (very large) Web page containing the encrypted data and all the JavaScript. When you open that Web page with your browser, it’s exactly like talking to clipperz.com – you still have to log in with your username and passphrase – but you’re not talking to clipperz.com; you’re working offline. So this one downloaded Web page is doing for me everything that my password keeper application was doing
previously! The only thing missing is editability; you’re working with a read-only copy of your data. Pretty slick, eh?

Clipperz isn’t perfect. Copying the scrambled password doesn’t work reliably – but the Clipperz folks are working on a new Web interface, currently called the “gamma,” which solves that problem. The interface for some operations, such as entering multiple cards by importing from a text file, is highly confusing (I succeeded, but only after much experimentation). The overall interface is, alas, clumsy on an iPhone; there is a mobile version of the Web interface, but it doesn’t work for me at all. Finally, there’s a promising feature called “direct login” that lets you click a link and automatically, with no further action on your part, go to the target Web site’s login page, enter your username and password, and submit the form; but it
doesn’t work for all Web sites, and the interface for editing a direct login is somewhere between clumsy and non-existent (though this, too, is nicely solved in the new “gamma” interface).

Quibbles aside, I’ve found Clipperz a tremendous help in my daily Web life. It lets you access your online passwords, online, regardless of what computer you’re using. It’s free, it’s open source, it’s safe and secure, it’s ingenious, and it’s way cool. What more could you ask? Perhaps you’ll give it a try, and you, too, will be wondering why no one told you about this sooner.

A continuing complaint about the iPhone OS has been that Apple doesn’t allow multitasking, a staple of the Mac OS since System 5 first added MultiFinder in 1988. Apple’s stance is that allowing apps to run in the background would significantly hurt performance and battery life, but in iPhone OS 3.0, Apple added push notification, which addressed some – but by no means all – of the desires of those who were asking for multitasking.

For the most part, requests for multitasking capabilities had died down to a dull roar since the release of iPhone OS 3.0 and its push notifications. It wasn’t that the desire had disappeared, but more that the debate was at a standstill.

The announcement of the iPad changes everything, because it includes a faster CPU (though how much faster is as yet unknown), 10-hour battery life in comparison with the iPhone’s 5-to-9-hour battery life rating, and a screen with 1024-by-768 resolution that’s far more spacious than the 480-by-320 resolution of the iPhone and iPod touch. The longer battery life could reduce Apple’s concern that multiple apps running simultaneously would hurt battery life, and the larger screen raises the possibility of running apps side-by-side.

More generally, whereas the iPhone is aimed at short, focused tasks, the iPad is more likely to lend itself to longer, more general tasks that involve using multiple apps, just as we’re used to on the Mac. It’s easy to imagine wanting to use an iPad to read text in Mobile Safari, copy some text to a Pages document, and send that document to a colleague via Mail. That specific example may turn out to be possible with the current iPhone OS, but it points toward needing more ways for iPad apps to work together in the future.

Plus, if I’m on the right track with my suggestion that Apple’s long-term plans involve even larger iPhone OS-based devices (see “iPhone Developer License Points to New Devices?,” 28 January 2010), multitasking will be key – it’s hard even to imagine what using a large-screen Mac would be like if you could run only one application at a time.

But what do we mean when we say that the iPhone OS should support multitasking? If we define what we’re looking for more carefully, it might be easier to lobby Apple for support in iPhone OS 4.0 and beyond.

Push Notification — The simplest form of multitasking is the one that Apple has already made available to developers, push notifications. In essence, applications register with a push notification service that runs at the system level, such that when a notification arrives, the iPhone OS presents the notification as though it had come from the app.

Notifications are one of the primary things that people want from multitasking – for one program to be able to notify the user of an event even when the notifying app isn’t in active use. On the Mac, think about iCal – you want event alerts to pop up no matter what application you’re using, and that can happen only if another process is paying attention in the background and can interrupt the frontmost application.

The problem with push notifications with regard to multitasking is that they are all responses to some external change in a cloud-based service like AIM or Twitter, not an example of a background app notifying you of some change. That is possible in the iPhone OS, of course, such as with calendar or timer alarms that presumably schedule internal notifications for specific times, but Apple hasn’t opened that capability up to developers in any way that I’m aware of. It would be nice, though, and wouldn’t seem difficult to add.

Background State Updates — Another way we think about multitasking comes down to updating remote state in the background. This too is possible in the iPhone OS now, but only for Apple’s apps. If you have Fetch New Data in the Mail, Contacts, Calendars settings screen set to Push, new email messages and changes to your contacts and calendars appear automatically. That’s why you don’t have to refresh Contacts or Calendar to make sure you have the latest changes; with Mail, you still need to check for new messages (or wait for the timer to trigger another mail check) for accounts without push. (You can of course make calendar and contact updating a manual process by syncing only via iTunes.)

While Apple’s apps can make sure their state is always up to date by bringing data in while in the background, Apple hasn’t opened that capability up to developers. Twitter apps, for instance, and RSS news readers, could benefit from being able to update state in the background.

I do want to distinguish between scheduled updates for something like Twitter or RSS, and continuous background execution, which I’ll discuss later. You don’t care if a Twitter client or RSS news reader checks every second, since each refresh can bring in old messages as well, whereas an instant messaging app might miss messages entirely if they arrived at the wrong time (and the server didn’t maintain state with the client). That’s why a chat app, or a GPS tracking app, might want to run all the time, since scheduled updates wouldn’t be sufficiently fast or complete.

It would seem that updating background state on a schedule would be the sort of thing Apple could make available to developers, just as it’s available for a few of Apple’s own apps. Apps would have to register with the iPhone OS, which would mediate how often data was fetched, but that shouldn’t be either terribly hard or excessively demanding on battery life.

Inter-application Communication — On the Mac, we’re accustomed to applications talking with one another in a wide variety of ways, such as Entourage sending a double-clicked URL to Firefox, Twitterrific asking Growl to display a notification, an iTunes controller displaying the current song, or even the Finder telling BBEdit to open a document.

A few of these behaviors are available on the iPhone, such as following a URL from an email message in Safari, creating an email message with a photo, and displaying an address in Maps. But for the most part, apps can only ask Apple’s apps to do things; the main counter-example on my iPhone is Boxcar, which can open a variety of Twitter apps in response to a tweet notification. But Boxcar is extremely limited; it can open a Twitter app, but it can’t reliably control that app in any useful way, such as to display the specific tweet in question, for instance.

The reason for this is that the main way apps can communicate with one another now is via URLs, and the width of that channel of communication depends on how robust the URL handler API of one app is, and how much of it is used by the developers of other apps. But this approach is limited, since the information must fit completely within a URL, and because it’s unidirectional – the receiving app can’t send any information back. Plus, in the current iPhone OS, files are private to each app, so one app cannot send a file reference to another app.

I could see a future version of the iPhone OS extend URL handling with the capability to send file references to documents in a shared space, and perhaps to return another URL to the sending app. Such communication without requiring both apps to be active wouldn’t hurt battery life or performance much, and might be better than the user flipping between apps manually now. But it would still be a clumsy way for apps to communicate, unlike the Apple Event system built into the Mac OS that enables applications to communicate with one another.

Apple Events can work only if the destination app is running, however, so it’s much harder to imagine a similar system in the iPhone OS, given its significantly more limited CPU and RAM resources. I wouldn’t expect to see this in the near future.

Of course, the other way to transfer arbitrary data from app to app is via copy and paste, a recent addition to the iPhone OS. Copy and paste solves many problems, but is entirely user-driven, unlike the URL approach or Apple Events on the Mac.

Quick Task Switching with Saved State — The first glimpse of multitasking in the Mac OS came with Andy Hertzfeld’s Switcher (from 1985), an application that almost made it possible to run two applications simultaneously, although under the hood it merely enabled switching between applications without quitting one and launching the other. Switcher was supplanted by MultiFinder in System 5 before System 7 made it a standard part of the operating system.

We’ve gone backwards with the iPhone OS, which forces you to stop using one app (by pressing the Home button) before you can launch another (by tapping its icon on a home screen). It does so for two main reasons: consistency of user experience and to eliminate the RAM and CPU requirements necessary for keeping two apps active at the same time. Luckily, quitting and launching are generally quick, which is why Apple has been able to get away with it so far.

Still, it’s frustrating to be forced back to the home screen constantly (especially for those of us who have lots of home screens to hold many apps), and Apple has even implicitly acknowledged that by providing a single shortcut action – a double press of the Home button – that you can set to display the first home screen, the search screen, the Phone Favorites screen, the Camera app, or the iPod app. And even the fact that Apple allows four apps to be docked and thus appear on all home screens shows that they recognize users want to move among some apps more fluidly than others.

I’d suggest that two changes are necessary to meet most of the needs of quick task switching. First, the iPhone OS needs a faster way to switch between user-selected or recently used apps – the display of a shortcut screen could even be tied to a double or triple press of the Home button. Second, both the iPhone OS and individual apps need to work harder at saving the user’s state, so every launch doesn’t involve starting from scratch. It’s not impossible; our TidBITS News app does it, so if you’re reading an article when you leave the app, the app puts you right back where you were when you next launch it. Perhaps the iPhone OS could “freeze” the state of apps automatically, if developers so wished, without having to do extra work.

Neither of these suggestions requires apps to be active simultaneously, and should thus be the sort of thing Apple would consider in a future version of the iPhone OS.

Simultaneous Execution — Here we come to the real nut of the problem – true simultaneous execution. But even here there are two actual scenarios: apps like iPod that need to run in the background, but which don’t need to take up any (or hardly any) visible space in the interface, and the future possibility of multiple apps running side-by-side on an iPad.

Obviously, this first scenario is possible with the iPhone OS because the iPod app does it, so it should be possible for other apps like the Pandora music app or a GPS tracker app to do so as well.

Here’s where we come back to Apple’s claims that allowing background apps would hurt performance and battery life. Let’s say you’re playing a game on your iPhone, and it’s taking most of the available CPU cycles. Running another app at the same time, like iPod, isn’t going to hurt battery life significantly because all the CPU cycles are already in use, so if the game would have drained the battery in an hour, the game plus iPod would do so only slightly more quickly.

However, let’s assume you’re not using a game, and whatever app is active is using relatively few CPU cycles. In that case, adding another process like iPod would increase overall CPU usage and would undoubtedly drain the battery more quickly. That’s not ideal, but it seems like the sort of thing that should be a user decision – much as Apple warns that fetching new data more frequently drains the battery more quickly.

A more serious problem revolves around performance. Let’s say you’re a passenger in a car, and you want to play a game, listen to iPod in the background, and have a GPS app tracking your location and speed, all while new messages are pushed to Mail. Now the iPhone’s CPU would have to share cycles among all the apps, and if it did so poorly, performance in the game might drop below acceptable levels. Tweaking how much CPU time to give to background tasks while keeping the foreground task responsive is a black art in all operating systems. And that assumes the iPhone’s CPU is even up to the task at all – it may simply not have the power to keep the frontmost app responsive under the load of multiple apps. And that, I believe, is anathema
to Apple – the magic of the iPhone OS’s direct manipulation interface is that it’s so responsive that it seems natural. Introduce lag or stuttering, and the illusion would fail.

Thus, the only way I can see Apple allowing background apps is if it could in some way limit the portion of CPU cycles an app was allowed to use in the background, and the app would have to accept only occasional cycles if other things were going on. It’s not inconceivable, but it feels like a hard problem that Apple is unlikely to solve soon.

A more serious problem may revolve around RAM limitations. Apple stays very quiet about how much is in each iPhone OS device, and it’s entirely possible that there isn’t enough for multiple simultaneous apps whose RAM requirements Apple doesn’t control. Tweaking how much CPU time to allot to background apps may be difficult, but it’s doable. Relying heavily on virtual memory (particularly if it’s backed by relatively slow flash memory) instead of physical RAM could drastically hurt performance.

The second simultaneous execution scenario is more speculative, put possibly more easily answered. The iPad screen is large enough to display two (or even four, for that matter) classic iPhone apps simultaneously. Even with iPad-savvy apps, it would seem likely that if they were made to be resolution independent or could switch down to an iPhone-sized display when sharing a portion of the screen, it would be reasonable to run two side-by-side, with both being active at the same time. And, if the iPad’s A4 processor is sufficiently fast and there’s sufficient RAM, perhaps there would be enough resources to do that.

Here’s where we start to move into the world of the Mac, because it’s entirely commonplace to have two applications visible at the same time (and it’s nearly impossible to avoid for those of us who prefer to work on dual-display systems). I constantly refer to a Web page while I’m writing an email message in Mailplane or working on an article in BBEdit. And if someone sends me email asking to schedule a meeting at Macworld Expo, I can show my calendar in BusyCal without obscuring the message or its reply. That’s huge, and makes me more productive than I would be if I had to switch between them with Command-Tab. And the equivalent task on an iPhone OS device would be even worse, requiring me to quit Mail, launch Calendar, figure out what
times I have available, quit Calendar, launch Mail, find the right message again, reply to it, and then try to remember which times were available.

Although allowing multiple apps to run side-by-side on an iPad seems like a stretch for Apple (I can imagine an interface a little like iPhoto’s photo comparison approach), it would be a boon for anyone trying to use the iPad instead of a Mac for a lot of tasks that require visual access to data in multiple apps.

The main advantage this scenario has over the previous one, where the secondary apps are executing but not taking up interface space, is that with side-by-side apps, it may not be necessary that one continue processing while the other is active. The calendar could become essentially frozen in place while I’m replying to my email message, and activate only when I tap on it to switch to the next month, at which point the email app would freeze until I tapped back on it. That approach could address the performance problem, since only one app would actually be using CPU cycles at a time.

Putting It All Together — Let’s see where we are, now that we’ve broken down “the iPhone should have multitasking” into its component parts. Some are here today in only Apple’s apps, others are purely speculative.

• Push Notification: It’s here today, and while it’s possible Apple will tweak it slightly in the future, it does what it needs to do in terms of reporting external changes, and people generally like it. Notification of scheduled events from iPhone applications which aren’t active is currently restricted to Apple’s apps, but doesn’t seem as though it would be hard to open up.
• Background State Updates: Apple currently reserves this form of multitasking for a few of its own apps, but I see no reason it couldn’t be opened up to developers, assuming a few restrictions to avoid abuse that could impact performance or battery life.
• Inter-application Communication: Some forms of inter-application communication are possible on the iPhone OS now (sending URLs from app to app, and copy and paste), but they’re quite limited. Apple could enhance URL-based communication quite significantly without too much difficulty, but I don’t expect an Apple Events-like system to appear on the iPhone any time soon, and I doubt it’s worth asking for.
• Quick Task Switching with Saved State: The iPhone OS would need some interface changes to enable this, but most of the responsibility lies with apps to save their state and restore it as quickly as possible. In the meantime, I think it’s worth agitating with Apple for some app-switching shortcuts and perhaps OS-level support for freezing state.
• Simultaneous Execution, Background Apps: Although this is here today, at least with the iPod app and some of Apple’s other apps, I don’t expect Apple to provide this more generally soon, since ensuring that the frontmost app’s responsiveness doesn’t suffer is paramount to the iPhone user experience. You can ask all you want, but it’s going to be a while (or a more-capable device) before we see it.
• Simultaneous Execution: Side-by-Side Apps: I doubt we’ll see this in the initial release of the iPad, but if enough people start using the iPad for real work, where you need to see two apps at the same time, it could become a priority for Apple to add. It’s worth requesting, but may appear only in a task-switching context until the hardware can handle it.

As always, the best (and only) way to submit feedback to Apple is via the Product Feedback page. The iPad isn’t yet there, but I’d suggest making your wishes known for the iPhone or iPod touch, whichever you currently own.

And of course, tell us what you think in the comments!

Digital Camera Raw Compatibility Update 3.1 — When companies release new camera models that are capable of capturing raw images (where the sensor saves the original image data as it was recorded, without compression or optimization), the raw format used by each is slightly (and annoyingly) different and proprietary. Apple incorporates support for the cameras at the system level, rolling them into bulk updates such as the recently released Digital Camera Raw Compatibility Update 3.1. This round adds support for the following cameras: Hasselblad H3DII-50, Leica M9, Leica X1, Olympus E-P1, Olympus E-P2, Panasonic Lumix DMC-GF1, Pentax K-7, Pentax K-x, Sony Alpha
DSLR-A500, Sony Alpha DSLR-A550, Sony Alpha DSLR-A850. (Free update, 6.77 MB)

Read/post comments about Digital Camera Raw Compatibility Update 3.1.

PDFpen 4.6 and PDFpenPro 4.6 — The latest versions of SmileOnMyMac’s PDF editing utilities PDFpen and PDFpenPro come with brief release notes, but include at least one substantial improvement. Both editions now support OCR for 11 new languages including German, French, Spanish, Italian, Portuguese, Catalan, Dutch, Swedish, Finnish, Danish, and Norwegian. The upgrades also reportedly include a number of minor bug fixes and improvements, though they aren’t enumerated. ($49.95/$99.95 new, free updates, 45.9 MB/46.1 MB)

Read/post comments about PDFpen 4.6 and PDFpenPro 4.6.

Keyboard Maestro 4.1 — Stairways Software has released a substantial update to its popular macro utility Keyboard Maestro. In version 4.1, support within the program has been expanded to include improved documentation, an in-app tutorial, and a Help section for activating and targeting macro groups. Also, the program’s menus have been improved with added commands and a new Select Menu editor that enables users to choose from any current menu item. Finally, name- and trigger-based searches for macros are now available, the behavior of Typed String triggers has been fine-tuned, and canceling a Google search now returns you to the program window. ($36 new, free
update, 8.8 MB)

Read/post comments about Keyboard Maestro 4.1.

Camino 2.0.2 — The Camino Project has released a minor update to the Mac-focused Web browser Camino that addresses several security and stability issues by updating the program to version 1.9.0.18 of Mozilla’s Gecko rendering engine. Also, users can reassign Command-arrow key combinations to activate the menu items of their choice, the Flash-blocking code has been upgraded to Flashblock 1.5.12, Google’s Safe Browsing information pages are now available in Norwegian, ad-blocking has been improved, and the colors in the Bookmark Bar will appear accurately on displays with a gamma other than 1.8. (Free, 15.8 MB)

Read/post comments about Camino 2.0.2.

Our Web explorations this week ranged among many different topics, including Apple acknowledging iMac display issues, more on Macworld Expo and Google Buzz, the winner of Apple’s iTunes Countdown to 10 Billion Songs, a survey suggesting that the iPad may prove initially more popular than the iPhone, how Apple interacts with external suppliers, a look back with one of the Mac’s earliest developers, and Wal-Mart buying the Vudu video service.

Apple Acknowledges iMac Display Issues to Gizmodo — In a statement to Gizmodo, Apple publicly acknowledged the vexing display issues plaguing its latest iMac models. The symptoms of these issues, which mostly affect the 27-inch model, include yellow discoloration and screen flickering. In its statement Apple said, “We’ve addressed the issues that caused display flickering and yellow tint. Customers concerned that their iMac is affected should contact AppleCare.” While the company has been too slow in addressing this problem, better late than never.

Read/post comments

Adam Discusses Macworld Expo and the Google Buzz Debacle on Tech Night Owl — On the Tech Night Owl Live podcast, Adam talks about the success of Macworld Expo with host Gene Steinberg, after which the discussion veers off to Google’s privacy missteps with Google Buzz.

Read/post comments

10 Billionth iTunes Song Sold — Apple has announced the winner of its iTunes Countdown to 10 Billion Songs. The lucky iTunes shopper is Louie Sulcer of Woodstock, Georgia, whose purchase of Johnny Cash’s “Guess Things Happen That Way” has earned him a $10,000 iTunes Gift Card. The winning song may come as a surprise when iTunes’s current list of top songs is dominated by recent pop and hip-hop singles, but it just goes to show that the iTunes Store continues to serve a wide spectrum of fans and tastes.

Read/post comments

Initial iPad Sales to Outpace Original iPhone? — Despite the skepticism we’ve heard from some people about the iPad, All Things Digital is reporting on an RBC/ChangeWave survey that found 13 percent of respondents were somewhat or very likely to buy an iPad, compared to 9 percent who said they’d buy the original iPhone in a similar survey before its launch. The difference is being attributed to the iPad’s entry-level $499 price.

Read/post comments

Apple Releases Supplier Responsibility Report — As Apple sells tens of millions of devices each year, increased attention has been focused on the company’s outside suppliers and the conditions of the workers in those companies. Apple has now released its 2010 Supplier Responsibility Progress Report, outlining what Apple requires of suppliers, how the companies have fared in audits, and how Apple deals with lack of compliance. It of course paints Apple in a positive light, but is indicative of how Apple is trying to be a good corporate citizen.

Read/post comments

Macintosh Past and Future With Jim Rea — Jim Rea’s ProVUE Panorama was one of the first ready-to-market applications when the Macintosh premiered in 1984, and it’s still going strong. Hear and see Jim reminiscing at Macworld Expo about those early days, with some hints about the upcoming Panorama 6, in this short pair of YouTube videos from TUAW. It’s just like having lunch with Jim, but without the food!

Read/post comments

Wal-Mart To Buy Vudu — The New York Times reports on Wal-Mart’s acquisition of Vudu, a company behind the eponymous online movie service incorporated into many HD televisions and Blu-ray players. While specifics on the deal haven’t yet been released, it seems clear that Wal-Mart is attempting to embrace the future of media distribution in a climate of dwindling DVD sales.

Read/post comments