Reports from the MacTech Boot Camp in San Francisco last month indicate that it was a success, with the one-day conference selling out and garnering positive comments from attendees and speakers alike (though, apparently, there were no drill sergeants or pushup requirements). Building on that success, MacTech has now announced additional Boot Camp conferences for consultants and support techs around the United States. The new events are:

• MacTech Boot Camp Dallas, on 27 April 2011
• MacTech Boot Camp Boston, on 18 May 2011
• MacTech Boot Camp Los Angeles, on 27 July 2011
• MacTech Boot Camp Chicago, on 31 August 2011

The additional locations and dates should be welcome for those who couldn’t make the trip to San Francisco for the initial MacTech Boot Camp and the subsequent Macworld 2011 back in January.

MacTech has announced session chairs for each of the conferences, and although the sessions won’t be identical, the conferences will all cover roughly similar topics, including things like handling clients, support call techniques, remote support, backup systems, Windows on the Mac, networking basics and troubleshooting, marketing oneself, and resources for finding answers to tricky problems.

Registration for the one-day conference costs $495, and by registering early, you can drop that to $295.

Two-dimensional tags that provide a URL, address card, location coordinates, or plain text can now be easily decoded under Mac OS X with the new QuickMark release. The $2.99 QuickMark reads standard 2D codes (QR Code and Data Matrix) as well as its own format, also called QuickMark. These codes are increasingly found in newspapers, magazines, advertisements, and physical goods sold at retail. (We even provide QR codes at the bottom of each TidBITS article to let you transfer the URL between devices to continue reading; see “Tag, You’re in 2D!,” 1 October 2009.)

QuickMark’s eponymous Mac program, available through the Mac App Store, has three functions. It can use a camera (built-in iSight or FaceTime, or third-party) to recognize and carry out an action on a 2D tag. This includes opening a URL in a browser, switching to Skype for a phone call or to send an SMS, or using Google Maps via a browser to display a location. It can also take text you enter and produce a 2D code in any of the formats it reads. Finally, you can drag an image into the scanning window or select an
image from a menu, and QuickMark will decode any 2D tag that the image contains. The Mac app cannot read 1D barcodes, such as the kind used for ISBNs on books.

I have been using QuickMark’s $0.99 iOS app for some time quite happily on my iPhone for 2D code scanning and creation. The codes were put into wide use in Japan nearly a decade ago in a partnership between mobile phone companies, handset makers, advertisers, and publishers. They have finally taken off in the United States: there’s not a day that goes by that I don’t see several prominently displayed in store windows, see them in
newspaper and magazine ads, or note them on Web sites I visit. I even received an ad flyer yesterday in the snail mail that had a code on it. (The iOS app can read 1D codes.)

The Mac version unfortunately shows the developers’ lack of familiarity with Mac OS X: you cannot paste into the text field for creating a 2D tag, and, for that matter, it lacks copy and paste commands entirely. You can type in text, or drag text from a browser address bar into the text field. But these limitations should be easy to fix, and I’m sure user feedback will help QuickMark improve.

For subscribers to our free weekly mailing lists compiled from articles that appear at the TidBITS Web site, I’m offering an administrative heads-up about a change in how we will be sending out email. Starting with TidBITS #1065 next week, our issue email headers will be slightly different, a move that we didn’t anticipate, but one that has turned out to be necessary for bounce processing in our new system to work.

I’m providing this advance warning because if you have whitelisted email from [email protected] in your spam filter, it’s possible that next week’s issue—which will come from a different address at our domain—will be marked as spam. If TidBITS doesn’t arrive next week, that’s probably why, and you should go spelunking in your spam folder. Also, if you move TidBITS issues to another mailbox via a rule that keys off [email protected] appearing in the From line, that will need changing too. Sorry for any inconvenience!

In an ideal world, we would make the change and everything would just work with no need for you to do anything. But assuming that Murphy’s Law remains intact, here’s what you might need to know.

The From address in all editions of next week’s TidBITS issue will change from [email protected] to [email protected], as in:

From: TidBITS Editors <[email protected]>


That [email protected] address is what you’ll want to add to any spam filters that allow you to whitelist (approve automatically) messages from specific senders. However, it’s not the best way to filter TidBITS issues to a different mailbox. For that, I recommend using a rule that relies on the List-Id header. Our list headers are specific to each version of TidBITS; you can see which one you receive by viewing the full headers for the message.

List-Id: TidBITS Text Issue List <text.issue.tidbits.com>
List-Id: TidBITS HTML Issue List <html.issue.tidbits.com>
List-Id: TidBITS Text Announcement List <text.announce.tidbits.com>
List-Id: TidBITS HTML Announcement List <html.announce.tidbits.com>


Reply-To Changing Too — Also changing next week will be the Reply-To address in the issue. The new address will not be read by a person, but will instead generate an auto-reply that explains the best ways to contact us for different purposes.

Why the auto-reply? The simple fact of the matter is that there are a lot of different ways to contact us, and which is most appropriate depends on the situation. For instance, if you’re writing to comment on an article, we’d much rather have you leave a comment on the article itself than send us email. And if you’re really shy, you can always email an author directly—using a link next to the byline on every article—or ping them via Twitter (check our Contact Info page for staff details).

If you have a problem with our Web site or with our email issues, it would be great if you could ask on our TidBITS Get Satisfaction site, where we can reply in public and others with similar questions can benefit from our answer to you. If the problem is something you think I should know about right away, ping me via Twitter.

On the other hand, for questions about your account, where we can’t really help you unless we know your email address, private email makes more sense than Get Satisfaction. (The same goes for Take Control—general questions and suggestions are best sent to the Take Control Get Satisfaction site, whereas account-specific questions should be sent via private email.)

And if you have a technical question that’s unrelated to a particular TidBITS article or even TidBITS itself, you’d be best off asking in our TidBITS Talk discussion list, though it now limits posts to subscribers to block the constant onslaught of spam.

The MTA Behind the Curtain — I realize this next bit gets very specific, but since we were surprised by this situation, I wanted to share our findings in case anyone else were to run into a similar problem. (And if you don’t know or care what an MTA is, or how mail servers operate, there’s no need to keep reading.)

When we were using Web Crossing, it acted as both the mailing list software (generating the actual messages to send out) and as the mail transfer agent, or MTA. Because it wore both hats, Web Crossing was able to customize the headers of each individual message to identify and process bounces. In particular, Web Crossing added a customized Return-Path header, as in:

Return-Path: <[email protected]>


And notably, that header was different from the From line:

From: "TidBITS Editors" <[email protected]>


That’s important because only the MTA can insert the Return-Path header. Since our homegrown TidBITS Publishing System is acting as the mailing list software, and handing messages off to sendmail (via a library) to deliver, sendmail inserts the Return-Path header automatically, basing it on the From header. Thus, both the Return-Path and From pointed at [email protected]. Although it’s conceivable that sendmail could be configured to insert a different Return-Path header, that’s apparently not possible with the library that we’re using to connect sendmail to the TidBITS Publishing System.

Since we had always had the From address be [email protected] and didn’t change it for our first use of the new system, we were a little shocked when bounces came back to that address rather than to the address listed in the Errors-To header. It turns out that Errors-To is not a standard, unlike Return-Path, so it worked in some cases, but by no means universally.

Anyway, we believe the solution is simple—to set the From line to contain an address that will be replicated into the Return-Path header and that can receive and process bounces appropriately. But we figured that many people would either be whitelisting [email protected] or filtering based on it; hence this message. Glad you asked?

We now return you to your regularly scheduled issue of TidBITS.

Roughly every three years, I replace my MacBook Pro with a new model. That cycle gives me plenty of use out of each machine, but also means I leapfrog into features that appeared in intervening models.

Buying a new MacBook Pro (with a 2.66 GHz Intel Core i7 processor) last year was like a surprise birthday gift: It boasts significantly better battery life, the full range of multi-touch trackpad gestures, the aluminum unibody construction (which I’m surprised is one of my favorite features—it just feels so much more sturdy than previous models), and a high-resolution LED screen.

This laptop also includes two graphics cards (designated as GPUs, or graphics processing units): the integrated Intel HD Graphics, and a discrete Nvidia GeForce GT 330M. The former is designed for low power consumption, and therefore better battery life, while the latter kicks in to provide graphics horsepower when needed.

Earlier dual-GPU MacBook Pros required that you specify which graphics mode to use in the Energy Saver preference pane, and then log out and log back in to your user account. Starting with the mid-2010 models, the switching occurs automatically: when an application is launched that requires more graphics power, the discrete Nvidia GPU fires up. Otherwise, the integrated Intel GPU provides the graphics without burning through the battery’s charge. (You can turn off automatic switching in the preference pane, which leaves the Nvidia chip active all the time.)

When working away from my desk, I want to get the longest battery life I can. I would quit any obvious GPU hogs such as Photoshop, iPhoto, or iMovie, but I couldn’t easily tell whether my MacBook Pro had switched to the integrated GPU.

To determine which GPU is active, you have to open the System Profiler application (press Option and choose System Profiler from the Apple menu), click the Graphics/Displays item under Hardware in the sidebar, and select the Intel or Nvidia video card. The one being used includes a Main Display: Yes.

So, I would quit some obvious applications, go back to System Profiler, press Command-R to refresh the data, and see if “Main Display: Yes” appeared in the Intel GPU. I felt like I’d been transported back to the days of hunting disagreeable startup extensions in Mac OS 8.

However, it turns out the Nvidia GPU can be triggered by applications you wouldn’t think of as being traditionally graphics hungry, such as most Twitter clients and even stalwart Fetch (perhaps because of the running dog progress animation?). Sure, I still get better battery life on this machine when using the Nvidia GPU than I did on my old laptop, but that doesn’t mean I don’t want to take advantage of low-power integrated graphics.

Initially, I installed Cody Krieger’s free gfxCardStatus 2.0 because it adds a menu bar icon that identifies which GPU is in use: a simple “i” for Intel (or “integrated”), or “n” for Nvidia. That alone saved a lot of time and frustration.

But then I noticed that when you click the icon, gfxCardStatus helpfully reveals which applications are forcing the discrete GPU, listed under Dependencies.

The utility goes beyond just reporting, though. You can force the MacBook Pro to use just integrated Intel graphics, discrete Nvidia graphics, or stick with dynamic switching, by choosing one of the options in the menu.

Some applications don’t respond well to a live switchover from the discrete to integrated GPU. BusyCal, for example, loses its capability to move between months when it’s forced into Intel-only mode. However, quitting and re-launching BusyCal fixes the problem (since the software must also work on computers like the MacBook or Mac mini that include only integrated graphics).

gfxCardStatus 2.0 was released in December 2010 and adds a helpful new feature: it can switch GPUs based on whether you’re working on battery or AC power. If you need the most battery life when working on the go, you can force the integrated graphics automatically. This feature is disabled by default, to avoid problems with apps that don’t switch cleanly.

I haven’t timed the difference between running integrated and discrete graphics other than to notice that the battery estimate provided by Mac OS X’s menu bar item does increase significantly (up to an hour more) when I’m on battery and have quit all dependent applications.

gfxCardStatus works with the following recent MacBook Pro models:

• 2010 i5/i7 MacBook Pro with Intel HD/Nvidia GeForce GT 330M GPUs
• 2009 MacBook Pro with Nvidia GeForce 9400M/9600M GT GPUs
• Late 2008 MacBook Pro with Nvidia GeForce 9400M/9600M GT GPUs

gfxCardStatus definitely fills a narrow niche, but it’s an elegant, helpful way to eke out the most time from your MacBook Pro’s battery charge.

We’ve just released a new version (1.4) of the TidBITS News iOS app, containing two bug fixes you probably won’t notice and one new capability which, while subtle, has been requested by users and should make a lot of people happy. We’ll start by describing the new capability, which has to do with audio and TidBITS News’s interaction with other apps.

As you may know, the TidBITS News app enables you to play the recorded audio versions of our articles. (These are the same audio versions to which you can subscribe in iTunes as a podcast.) Because it has the capability to play its own audio, the TidBITS News app has to declare an “audio session policy” so the system knows what to do in case there is any background audio. This was necessary even under iOS 3.x, before multitasking, because the iPod app (or, on some devices, the Music app) could play background music.

Since TidBITS News could play its own audio, and since it was originally written for iOS 3.x, it declared its audio session policy in a simple-minded way. When the app launched, it halted the playback of any background audio. Admittedly, that wasn’t ideal, since if you were happily listening to your favorite tunes via the iPod app, the music would stop when you launched our app, even if you weren’t planning on listening to any of our recorded articles. Clearly, it would have been better for our audio session policy to declare itself only if you actually did start listening to one of our recorded articles. We were aware of this (especially because several users of our app pointed it out to us), but it wasn’t a high enough priority
to tackle immediately.

However, iOS 4 introduced both some new ways of specifying an audio session policy and a new capability for other apps (such as Pandora) to play background audio; so the time had clearly come to straighten out this situation. After some experimentation, it turned out that we could actually change our audio session policy as you start listening to an article recording, and change it back when you finish. There were, in fact, two different ways we could do this:

• TidBITS News could “duck” the current background audio (play it more quietly) when a user started playing one of our recorded articles, and restore the background audio’s loudness when our recorded article stopped playing. This worked perfectly, but some people might have had difficulty hearing Adam’s dulcet tones quietly reading an article while their favorite heavy metal band was wailing away in the background.

• TidBITS News could halt the current background audio altogether when a user starts playing one of our recorded articles. This worked fine too, but unfortunately our app could not reliably resume playing the halted background audio. In theory, such resumption is possible, and TidBITS News attempts to do all the right things, but actual resumption only takes place about five percent of the time. This is probably due to a bug in iOS itself.

So our choice was between an option that worked perfectly but might strain the user’s ability to listen to two things at once, and an option that only half worked. We chose the latter. Ducking is not really suitable for a lengthy, important sound like the reading of an article, as opposed to, for instance, a brief audio notification of an upcoming turn from a navigation app. And the fact that background audio couldn’t reliably be resumed after pausing wasn’t terribly important, because in a multitasking world it isn’t hard for the user to fix this manually.

So that’s the one obvious new feature in TidBITS News 1.4. When you enter the app, any audio that’s playing continues to play. If you start to listen to the audio version of one of our articles, your previous background audio will pause, and, if you’re incredibly lucky, will resume again once you’re done listening to our article. But if it doesn’t resume, then just use iOS 4’s multitasking capabilities to resume it yourself. The simple way to do this is:

1. Double-press the Home button to show the app switcher interface.

2. Swipe the app switcher to the right. This will bring in the stuff from the left, which includes sound control buttons.

3. Tap the play/pause button to resume background audio.

4. Tap in the TidBITS News interface to dismiss the app switcher interface.

On the user side, that’s probably all you’ll notice about this new feature. On the developer side, however, this change was remarkably difficult to accomplish. It turns out that our previous audio session policy wasn’t just annoying; it was actually broken, thanks to the advent of multitasking. Not only were we turning off sound on launch, but also we were failing to turn off sound when the user switched away from our app and returned. So it was actually possible for the user to subvert our annoying audio session policy. This goes back to a point I made months ago, when iOS 4 and multitasking first appeared (see “What is Fast App Switching?,” 23 June 2010): merely
making your app participate in multitasking is trivial—just recompile the app under a current version of Xcode—but making it behave properly under multitasking is hard.

The trouble is that as soon as your app starts to do multitasking, things that worked just fine before can come crashing down about your ears. The reason is that multitasking introduces lots of new ways in which the user can leave and return to your app. Before multitasking, there was only one way to arrive at the TidBITS News app, namely by launching it, and only one way to leave it, namely by quitting it. So, while it was annoying that our app turned off background sound on launch, at least in a non-multitasking world this was clear and definitive. But under multitasking, the user can do lots of strange things: switch to another app and return to our app, summon the app switching interface and return to our app, and so forth. And it
turns out that your app must actively defend against all these possibilities by reasserting its audio session policy in every case. TidBITS News, however, was failing to do this.

And that, in fact, is why we changed our audio session policy. We didn’t really do it just to be nice to users who were listening to music in the background. (After all, when you’re reading one of our articles, you should be giving it your undivided attention!) We did it because we discovered that our audio session policy wasn’t working as it stood. Changing our audio session policy and its behavior was, in fact, just something we did in the course of the much more urgent change of unifying the app’s behavior against the multitasking hydra.

There isn’t an Apple document that says, “Hey, if your app switches to using multitasking, watch out! Here’s a list of things that can go wrong, and sound is one of them.” But there should be. In our case, multitasking broke our audio session policy and we didn’t even notice initially. Nor did Apple’s vaunted approval process alert us to this fact. This is probably true up and down the line of apps. Lots of apps think they have adopted multitasking just by linking against the iOS 4 SDK and recompiling, maybe with a few simple obvious additions like saving state on backgrounding instead of saving it on termination. But multitasking is much, much more complicated than that, and Apple has not made it easy either to
become a safe multitasking citizen or to discover how to become one.

Oh, and what about the other two things we fixed in this release? One was just a good old-fashioned mistake. Images in our articles that had been acceptable on iPhone were appearing at the wrong size on the large iPad screen; this was merely an unnoticed consequence of converting the app so that it ran natively on iPad (see “TidBITS News App Updated for iPad”, 4 January 2011). We also tried to work around a mysterious cosmetic glitch that can appear in low-memory situations; with luck, you won’t encounter the situation that causes this glitch (none of us had, which is why we didn’t know about it), but the truth is that this problem is not really fixed, and likely won’t be until
we tear the app’s code completely apart and rewrite the whole thing from scratch.

The next Internet revolution is approaching. That’s right, in about two years, we will no longer be forced to remember horridly difficult URLs like britneyspears.com, and instead will be able to go to much easier Web sites like britneyspears.music.

Doesn’t sound like much of a revolution to you? Me neither. But others beg to differ, and differ at great length.

The Root of All Evil — I caught the tail end of the .nxt conference, an event for businesses looking to join the “Internet land rush” of new generic top-level domains (gTLDs). A TLD is the part of a domain name following the last dot in a URL—i.e., “com,” “net,” or “org,” to name the three that probably dominate your Web surfing experience. TLDs are divided into country codes, generic, and a few technical and experimental areas. The generic TLDs originated in the United States, and were restricted to U.S. use before the commercial Internet began in the mid-1990s. Those who
wanted domains elsewhere had to rely on country code TLDs.

This resulted in a still-persistent historical imbalance: a major American chocolate outfit might be found at http://www.hersheys.com/, while a major British confectioner relies on http://www.cadbury.co.uk/. Discerning readers will note that there’s nothing inherently American about .com. We just take it for granted that the top-level in American URLs gets to be a category of American organizations, rather than the entire country. This eventually led to .com becoming the default domain for any business in the world, and later for pretty much anyone else who wanted their Web site to have a “normal” address.

Consider for a moment how silly it would be if everyone in the world suddenly clamored for a phone number starting with 6, and all other phone numbers were déclassé. That’s essentially what happened on the Internet. Plug in a single word on almost any browser in the last ten years (excepting those with integrated search bars), and if they can’t find a site there, they’ll add a .com to see if that’s what you wanted.

This has long struck many observers as ranging between a wee bit odd and yet another blow by American hegemony against the nations of the world. American organizations, it’s said, are the Animal Farm first-among-equals in this system, further proven by the domain system’s long-standing inability to have anything but non-accented Roman characters used in names. The issue of using characters other than those found in English has been partly solved (not yet for TLDs). But the larger problem—the concentration of the world’s mindshare into the .com space—remains on the docket.

That is, if it’s actually a problem at all.

Master of Your Domain — Domains are created and administered by the Internet Corporation for Assigned Names and Numbers, or ICANN, a nonprofit organization that attempts to be the United Nations for governments, technical organizations, and Internet citizens. It has a very simple and straightforward organizational structure, depicted below:

I kid about ICANN—and many times, it is eminently deserving of kidding—but if you think about it, the above diagram isn’t all that complicated considering what ICANN has to do. Someone has to be in charge of the system that turns www.apple.com into 69.192.205.15. That someone has, by definition, a global constituency. And that global constituency, also nearly by definition, may not all be in agreement about things like free speech and who should be able to access and publish on the Internet.

ICANN has the job of resolving the .com problem, and they’ve done so by opening up the gTLDs. Any organization can apply for a gTLD, which is essentially a request for the equivalent of .com, from which they can assign as many domains as their servers (and bank accounts) can handle. Over 100 groups are known to have applied, and there will probably be many more when the entire list is published in October 2011.

If you want your own .com domain, all you have to do is head to your favorite registrar online, pony up around ten bucks, and pick a name that’s never been thought of before by anyone in history. If you want your own gTLD, it’s a little more involved, starting with the $185,000 application fee. That’s right, application fee. You can still be turned down. gTLDs must be approved by ICANN, and they’re looking for gTLDs which match their guidelines, such as being existing communities or global brands. For full details, refer to the New gTLD Applicant Guidebook Version 2, which is due to be replaced next month with the final edition.

The premise behind both the fee and the application process is to prevent Internet domain naming from becoming a free-for-all; if any word can become a gTLD, it’s the equivalent, some would say, to having U.S. phone numbers which could be any number of digits between 10 and 30.

Which brings us to the .nxt conference, where around 100 people gathered in a room to debate the Internet and party like it’s 1999. Own your own gTLD, with a domain that becomes a hot Internet address, and you can set pricing for organizations and people who wish to set up shop there. Alternately, if you’re of a more communitarian bent, you can use your gTLD to cultivate the community of people who host there.

Three of the domains in the latter category were regularly brought up in discussion, especially when the would-be proprietor of .music had his cell phone go off, playing a merry tune and interrupting the panel when someone called out, “Great branding!” But the other two domains give some idea of how complicated this issue can be: .gay and .green. Give out the .green gTLD, and now there’s an organization empowered to bestow the green name, literally, on its applicants.

Meanwhile, the .gay domain is expected to be vigorously opposed by quite a few nations on the stance that gay people shouldn’t be out in public, and certainly shouldn’t be allowed to talk to each other. And after the domain is established, it provides a handy method for these countries to shut down access to these sites all at once.

Gold Rush, or Fool’s Gold? — The tone of the conference was aptly captured with the presentation by Juan Diego Calle, CEO of .CO Internet S.A.S. and proprietor of Colombia’s .co country TLD. In his opinion (and in his marketing materials), .com is a “typo,” and there’s a massive marketing opportunity for his company in recapturing the historical abbreviation of “Co.” for corporations around the world. Beyond the marketing, though, his most salient point was his defense of why he’s in favor of expanding the gTLD space: until the market is flooded with new domains, no one will ever know that there’s anything beyond
the .com.

Nearly everyone in the room was in agreement that the new gTLDs would create a new boom in business, the land rush that’s heralded by the .nxt conference Web site. They were there to debate the details—and from the discussion, the details of running a gTLD registry can be extremely difficult, and there was little doubt that many players in the space would fail, but others would go on to be the next Internet billionaires.

This is where I apply my rather skeptical wet blanket perspective. There’s one major problem with all this, and it can be summarized in the one word that has become so ubiquitous that no one even bothers adding the .com appendix: Google.

The idea that .com is the Nob Hill of the Internet dates back to a time when a smaller and more tech-savvy Internet populace memorized URLs; today, it’s far more common that your average Internet user will toss the company they’re looking for into Google—and do so repeatedly rather than memorize a URL. I wish I could remember or reference where I heard this, but it’s not uncommon for people to get to Google’s own home page by Googling for Google in the Google search bar. For these people, it doesn’t matter if the site they’re landing on is google.com, goo.gl, or letmeGooglethatforyou.com. The search is what matters. [Editor’s note: My father, now an experienced Internaut, spent at least his first year online in
the 1990s without a location bar to enter URLs nor the knowledge that URLs existed. He used Alta Vista as his home page. -Glenn]

Meanwhile, this is being presented in a roomful of people who applauded and laughed when Calle referred to his initial marketing as, and I quote, “We created a digital orgasm.” I remember when I was drinking that sort of Kool-Aid, and it was when I was an Internet entrepreneur in the 1990s. So my impression from the meeting is that I was at the start of something—and it’s a business niche where companies are going to create something new and then try to sell it to each other, because few outsiders will come along for the ride. Addresses and branding are important, but we’re past the point where “the right URL” will make a business.

However, there is one major proviso.

The Real Next Thing — It’s easy to judge from the perspective of 2011, having weathered both the NASDAQ implosion and the Great Recession, and to think that we were all a little batty in the 1990s. But the fact remains that many of the technologies we use daily were built or invented during that time—even if the people who ended up selling them to us weren’t the people who lost their shirts bringing them to market.

I’m reminded of my thought process back when I purchased the jeffporten.com domain. I’m an old-school Internet user, so I remember the days when TLDs actually meant something. Once upon a time, you actually had to run a network to be a .net, or have an actual nonprofit to be a .org. Then open registration came along and all three of these TLDs became a free-for-all.

Even so, I spent some time debating whether I should use jeffporten.com for my personal domain. Sure, I run my own business, but “Jeff Porten” isn’t the business; I’m just the engine. The domain, I thought, should be something that reflected my personhood rather than my role in a free market. .org and .net were even less apropos—so should I go with jeffporten.info? Or even jeffporten.name, the “official” TLD for individuals?

Of course, I went with jeffporten.com. Why? Because who the heck uses .name? (And as I say in my Web site’s tag line: “Because jeffporten.info is even more conceited.”) But by doing that, I’m buying into the Nob Hill theory that I ridiculed earlier. There is cachet to having the .com with your name on it, as a buddy named Greenberg will tell you since his own named domain was snapped up by a real estate agent.

This brings me to another bit of technology history. Way back in the 20th century, when area codes were assigned across the country, the technology of choice was something called a “rotary phone.” When you “dialed” a number, you turned an actual dial. Dialing a 9 took roughly nine times longer than dialing a 1. What’s less well-known is that this meant that some area codes were “better” than others: 212 was assigned to Manhattan because it was the fastest to dial. You can roughly rank the perceived importance of American cities at the time from their area codes: 212, Manhattan; 213, Los Angeles; 312, Chicago. (908: northern New Jersey.)

Zoom forward to the end of the 20th century, and we start running into an addressing problem: phone numbers after the area code can’t start with 1 or 0, so there are roughly 8 million phone numbers in any one area code. Start handing out fax machines and cell phones like candy, and that’s not such a large number anymore. Wikipedia now lists five different area codes for New York City alone. When the time came to stop giving out new 212 numbers, or to take away the area codes of people who had them already, folks fought tooth and nail to keep the better virtual real estate.

Today in the 21st century, I just Skyped a friend at his 404 Atlanta number, he texted me back at my 202 Washington DC number, and both of us are currently in San Francisco. Neither one of us lives in our area code—and there are enough people like us that there’s no longer much geographical meaning assigned to an area code. (Nor are long-distance fees a concern in the way they were when I was growing up.)

I expect that the current sense of normality surrounding .com will eventually go the way of the 212 pride of place. And it may very well be that one of the entrepreneurs in the .nxt conference room that day will be the one who creates the new normal, the next virtual Nob Hill. But I don’t expect that will happen by picking out the perfect word for the gTLD, nor with brilliant marketing, nor anything else in the usual bag of business tricks. In fact, I have no idea how it will happen.

Nevertheless, it will happen, so perhaps not everyone is batty for believing that they’ll be the one to do it.

Skitch 1.0.3 — The screenshot-editing software Skitch has been updated to version 1.0.3. Various bugs are fixed: key combinations no longer trigger an upload when they shouldn’t, an issue where Skitch misbehaved when you dragged files into it has been corrected, and a crash affecting some newer Macs is resolved. Free users of the Skitch service now have access to three additional image manipulation options: Rotate, Flip, and Fonts. (Free, 6.3 MB)

Read/post comments about Skitch 1.0.3.

Digital Camera Raw Compatibility Update 3.6 — Apple’s latest Digital Camera Raw Compatibility Update extends Aperture 3 and iPhoto ’11 support to six more cameras and fixes processing issues for four others. Newly supported cameras include the Canon EOS Rebel T3/1100D/Kiss X50, Canon EOS Rebel T3i/600D/Kiss X5, Olympus E-5, Panasonic Lumix DMC-FZ100, Pentax K-r, and Pentax K-5. The update also improves the processing of images from the Nikon D7000, Nikon Coolpix P7000, Panasonic Lumix DMC-GF1, and Panasonic Lumix DMC-GH2. The update is available via Software Update and the Apple Support Downloads page. Apple also
publishes a full list of supported cameras. (Free, 6.45 MB)

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

Evernote 2.0.4 — Memory storage software Evernote has been updated to version 2.0.4. The new version improves PDF handling, both preventing issues with waiting for large PDFs to load and making it easier to drag PDFs out of the program. The update also includes what the developers call “lots of bug fixes.” (Free, 15.9 MB)

Read/post comments about Evernote 2.0.4.

CopyPaste Pro 3.0 — Plum Amazing describes its multiple-clipboard utility CopyPaste Pro as “Time Machine for your Clipboard.” New in version 3.0 is the capability to search your clip archives, enabling you to find anything in any clip. The Clip Revolver feature—which existed in much older versions of the software—is restored. Extracting email addresses from clips is improved. And new preferences allow for enhanced control over CopyPaste’s general behavior. ($30 new, free update, 4.3 MB)

Read/post comments about CopyPaste Pro 3.0.

1Password 3.5.7 — Agile Web Solutions has bumped 1Password to version 3.5.7. Most notably, the software now no longer quits when you close the main window. Also new is a success message after adding attachments, easier Dropbox sync setup, and better password strength reporting. Auto-correction and credit card filling are also improved. Rounding out the release are extensive enhancements to the software’s Google Chrome compatibility, and minor fixes for Firefox 4 and Safari. ($39.95 new, free update, 19.7 MB)

Read/post comments about 1Password 3.5.7.

iWeb 3.0.3 — Apple has updated iWeb—the iLife ’11 hanger-on that isn’t iDVD—to version 3.0.3. The update addresses an issue with the iSight Movie widget on certain Macs, and corrects problems publishing iWeb sites via FTP. Apple also says that the update “improves compatibility with Mac OS X,” which is good news I suppose, since that’s the only operating system that iWeb supports. ($49 new as part of iLife ’11, free update, 177.12 MB)

Read/post comments about iWeb 3.0.3.

Adobe Acrobat/Reader 10.0.1 — Adobe has released updates to its PDF authoring and reading tools, Acrobat and Reader. The new versions of each address critical security vulnerabilities and improve overall stability. The Reader update also improves Protected Mode, along with QTP, Flash, and SCCM support. (Free updates, various sizes)

Read/post comments about Adobe Acrobat/Reader 10.0.1.

Just a couple of quick links to check out this week: an article over at The Economist by Glenn about Readability, and Lex Friedman’s Macworld article about his backup strategy.

Readability Service Aids Readers and Publishers — Readability has added a subscription service akin to Instapaper, letting you convert Web pages to stripped-down versions and archive those for later reading from a Web account. Glenn Fleishman writes at The Economist about how this service for readers will also benefit publishers.

Read/post comments

Lex Friedman’s Backup Plan — Over at Macworld, Lex Friedman details his backup strategy for keeping his Mac’s data secure, and the paranoia that motivates his approach. The short version: Time Machine, plus a bootable clone via SuperDuper, plus offsite backup with CrashPlan, plus Dropbox, plus Google Docs. And did we mention the heavy helping of data-loss paranoia?

Read/post comments