This is not exactly the photo I intended to take...

Among the useful features and applications bundled into Mac OS X, Photo Booth is not exactly the most useful. Still, it’s handy to sometimes have an application to snap a photo of yourself or your surroundings while on the go. But Photo Booth has no preferences pane, and the default delay and BRIGHT screen flash can ruin your picture. Here’s a quick tip on how to use Photo Both with either (or both) turned off!

Eliminate the Flash

When Photo Booth takes a picture, it flashes the entire screen to white momentarily. I’ve never found this at all useful, and in fact have resorted to all sorts of unnatural acts to eliminate it – dimming the screen, moving away, and even covering it up. See the photo above for an idea why it’s particularly awful with the large, bright screen on the iMac!

But it’s easy to eliminate the flash. Just hold down the Shift key when you press the camera button! Note that you don’t need to keep holding it down, so you can get in position before the photo is taken.

Eliminate the Delay

I normally like having the delay, since it gives me a chance to see what I’ll look like. But there are times that you want to take a photo right now, and there’s a fix for that too.

Hold down the Option key when you press the camera button to take a picture immediately.

Use the Keyboard

As an avid keyboarder (and mouse hater) I was pleased to locate a shortcut to snap a photo. Command-T will take a photo with no click, and this can be combined with the options above as well!

© sfoskett for Stephen Foskett, Pack Rat, 2011. | How To Use Mac Photo Booth With No Flash or Delay
This post was categorized as Apple. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

It’s that time again, when everyone who thinks they’re a pundit (that would be everyone with a blog or Twitter account) has to make predictions for the coming year. But predictions are perilous: Get it right and you look like a mere trend-watcher; get it wrong and you look like a fool. It’s such a hassle! So I’m doing something different this year: I’m going to make predictions for 2009 now that it’s over, and reflect on just how smart I am (not) to have made them. Or something.

What I Would Have Gotten Right

I definitely could have predicted a lot of what happened in 2009. I mean, these were slam dunks!

1. Twitter rocks the world – I wasn’t early to Twitter, but I spent the early part of 2009 evangelizing its benefits to companies and co-workers alike. Considering how common Twitter is today, it’s hard to believe how roundly criticized and misunderstood it was this time last year. Yet here we are, on the verge of 2010, and Twitter has seeped onto our business cards, presentation templates, and web sites. I might not have predicted how stable (!) Twitter got by the end of the year, though.
2. Apple’s Macs and iPhones rule – I switched to the iPhone and the Mac in 2007 and 2008, respectively, but it looks like I wasn’t much of an iconoclast after all: By November, half of the Tech Field Day delegates were using MacBooks, and the Windows and Blackberry holdouts have started vocally defending their operating system choice. Pretty much like Mac folks used to do way back in 2008.
3. The recession is a serious pain – Companies put the brakes on spending and hiring, many even shifting both into reverse in 2009. This came as no surprise to humans capable of thought. The impact on enterprise IT companies was similarly predictable: Although most were able to survive, the impact of 2009 will continue to be felt for years. I might have predicted it would be worse, though I’m glad to say I would have been wrong.
4. EMC, NetApp, HDS, HP, and IBM continue to quibble – Surprise: Big company bloggers spend way too much time criticizing the products and actions of each other and way to little time talking about the true value of their own products.

Non-IT slam-dunk predictions: Obama was reviled by the right; the war in Afghanistan continues; people do stupid stuff in the name of reality shows.

What I Probably Could Have Predicted

Although some details would likely have been missed, I think I would have seen these coming.

1. Cloud compute and storage hits the enterprise – I was a believer in the cloud this time last year, and I bet my future on it by taking a position at enterprise cloud storage provider, Nirvanix, in March. I would have predicted that enterprise buyers would be putting serious thought to buying cloud products, but the scope has surprised me. We’re talking enough petabytes that the non-cloud players felt compelled to strike back with the private cloud pitch. Awesome!
2. Sun and Data Domain were acquired – My money would have been on Dell, IBM, or HP as buyers for this pair, but EMC wouldn’t have been outside my guesses. Still, Oracle buying Sun and vocally committing to keep it going, SPARC and all, would never have come to mind. But I wouldn’t have guessed against it either, so I’ll give myself a point here!
3. Cisco and EMC buddy up – I’ve long thought an outright merger of these two was in the cards, but even the recession couldn’t make the financials work. A partnership would have been on the list, and Acadia came as no surprise to anyone.
4. Cloud outages and data loss – I definitely could have predicted that high-profile cloud services would fall over throughout the year, and that some would lose data. Not all are enterprise-grade, after all. But the outages at Google, Rackspace, and Amazon, and Microsoft’s Danger data loss, surprised me. Don’t those guys have their acts together?
5. IT conferences falter – I spoke at Interop in 2009, but it lacked the 20,000-strong crowd it once had. Storage Decisions and Storage Networking World managed to fill their halls, but the old-school IT conference has lost its luster. Although VMworld remains strong, attendance was definitely off.
6. FCoE and SSD are still starting – I’ve been lukewarm on Fibre Channel over Ethernet and Solid State Drives, but I’m a bit surprised that storage vendors didn’t push them harder in 2009. I might have guessed there would have been more customer uptake to match the buzz.
7. SMB storage is hot – There’s a hole in the storage market between $1,000 and $20,000, and companies like Drobo and Iomega are rushing in to fill it. Now that ESX has solid iSCSI support, I expect a world of innovation here. (Oops, that sounds kind of like a 2010 prediction!)

Also in the predictable category: Goldman Sachs and Bank of America thrived while others fell; Ford is the strongest of the remaining US automakers; Boeing finally got the 787 off the ground.

What I Never Would Have Guessed

I’m not perfect, even in retrospect. Some of the Tech news from 2009 was just completely off the wall.

1. Microsoft Bing: This time for sure! – Seriously, Microsoft should stick to in-house thinking instead of trying to copy its rivals. Yet somehow, miraculously, Bing appeared and did not suck. In fact, I’m hearing regular (non-techie) folks around town talking about using the search engine. I’ve even used it! Could they actually have a winner?
2. Windows 7 rocks – Really? Seriously? Could Microsoft have come up with a solid replacement for Windows XP?
3. Ship it! – It’s not even 2010, and enterprise storage buyers can go out and purchase NetApp’s OnTap 8, EMC’s FAST, EMC Atmos Compute, and unicorn tears. Well, maybe not unicorn tears.
4. Still no GDrive – Seemingly every company has a cloud storage platform, from Amazon to Rackspace, Nirvanix to EMC, so why not Google? Could GDrive join Duke Nukem Forever as the most famous vaporware of the decade?
5. The executive shuffle – Dave Donatelli was supposed to lead EMC, not HP. Alan Atkinson was supposed to launch another startup, not take over Xiotech. At least NetApp was gentle.
6. Mac OS X (still) lacks iSCSI and ZFS – Come on, Cupertino, what’s wrong with you guys? I’ve been hyping ZFS for years, and iSCSI is commonplace. Yet Snow Leopard is stingy with both. Makes me want to hiss like one of those blue folks in Avatar.
7. Gestalt IT is a success – On a personal note, Gestalt IT didn’t even exist this time last year, and now we have a successful IT infrastructure blog and social media event. Amazing!

Other total shockers: Everyone loves Michael Jackson again; digital Beatles tunes are available everywhere but iTunes; Obama’s Nobel Peace Prize arrives 10 years early.

© sfoskett for Stephen Foskett, Pack Rat, 2009. | My 2009 IT Industry Predictions
This post was categorized as Apple, Computer History, Enterprise storage, Everything, Personal, Terabyte home, Virtual Storage. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

Does data encryption throw storage efficiency out the window? Not always!

One of the great ironies of storage technology is the inverse relationship between efficiency and security: Adding performance or reducing storage requirements almost always results in reducing the confidentiality, integrity, or availability of a system.

Many of the advances in capacity utilization put into production over the last few years rely on deduplication of data. This key technology has moved from basic compression tools to take on challenges in the fields of replication and archiving, and is even moving into primary storage. At the same time, interconnectedness and the digital revolution has made security a greater challenge, with focus and attention turning to encryption and authentication to prevent identity theft or worse crimes. The only problem is, most encryption schemes are incompatible with compression or deduplication of data!

Incompatibility of Encryption and Compression

Consider a basic lossless compression algorithm: We take an input file consisting of binary data and replace all repeating patterns with a unique code. If a file contained the sequence, “101110″ eight hundred times in a row, we could replace the whole 4800-bit sequence with a much smaller sequence that says “repeat this eight hundred times”. In fact, this is exactly what I did (using English) in the previous sentence! This basic concept, called run-length encoding, illustrates how most modern compression technology functions.

Replace the sequence of identical bits with a larger block of data or an entire file and you have deduplication and single-instance storage! In fact, as the compression technology gains access to the underlying data, it can become more and more efficient. The software from Ocarina, for example, actually decompresses jpg and pdf files before recompressing them, resulting in astonishing capacity gains!

Now let’s look at compression’s secretive cousin, encryption. It’s only a small intellectual leap to use similar ideas to hide the contents of a file, rather than just squashing it. But encryption algorithms are constantly under attack, so some very smart minds have come up with some incredibly clever methods to hide data. One of the most important advances was public-key cryptography, where two different keys are used: A public key used for writing, and a private key to read data. This same technique can be used to authenticate identity, since only the designated reader would (in theory) have the key required.

Cryptography has become exceedingly complicated lately in response to repeated attacks. Most compression and encryption algorithms are deterministic, meaning that identical input always yields the same output. This is unacceptable for strong encryption, since a known plaintext attack can be used with the public key to reveal the contents. Much work has focused on eliminating residues of the original data from the encrypted version, as illustrated brilliantly on Wikipedia with the classic Linux “tux” image. The goal is to make the encrypted data indistinguishable from random “noise”.

What happens when we mix these powerful technologies? Deduplication and encryption defeat each other! Deduplication must have access to repeating, deterministic data, and encryption must not allow this to happen. The most common solution (apart from skipping the encryption) is to place the deduplication technology first, allowing it access to the raw data before sending it on to be encrypted. But this leaves the data unprotected longer, and limits the possible locations where encryption technology can be applied. For example, an archive platform would have to encrypt data internally, since many now include deduplication as an integral component.

Why do we prefer compression to encryption? Simply because that’s where the money is! If we can cut down on storage space or WAN bandwidth, we see cost avoidance or even real cost savings! But if we “waste” space by encrypting data, we only save money in the case of a security breach.

A Glimmer of Hope

I had long thought this was an intractable problem, but a glimmer of hope recently presented itself. My hosting provider allows users to back up their files to a special repository using the rsync protocol. This is pretty handy, as you can imagine, but I was concerned about the security of this service. What happens if someone gains access to all of my data by hacking their servers?

At first, I only stored non-sensitive data on the backup site, but this limited its appeal. So I went looking for something that would allow me to encrypt my data before uploading it, and I discovered two interesting concepts: rsyncrypto and gzip-rsyncable.

rsync is a solid protocol, reducing network demands by only sending the changed blocks of a file. But, as noted, compression and encryption tools change the whole file even if only a tiny bit has been altered. A few years back, the folks behind rsync (who also happen to be the minds behind the Samba CIFS server) developed a patch for gzip which causes it to compress files in chunks rather than in their entirety. This patch, called gzip-rsyncable, hasn’t been added to the main source even after a dozen years, but yields amazing results in accelerating rsync performance.

The same technique was then applied to RSA and AES cryptography to create rsyncrypto. This open source encryption tool makes a simple tweak to the standard CBC encryption schema (reusing the initialization vector) to allow encrypted files to be sent more efficiently over rsync. In fact, it relies on gzip-rsyncable to work its magic. Of course, the resulting file is somewhat less secure, but it is probably more than enough to keep a casual snooper at bay.

Both of these tools are similar to modern deduplication techniques in that they chop files up into smaller, variable-sized blocks before working their magic. And the result is awesome: I modified a single word in a large word document that I had previously encrypted and stored at the backup site and was able to transfer just a single block of the new file in an instant rather than a few minutes. My only real issue is the lack of integration of all of these tools: I had to write a bash script to encrypt  my files to a temporary directory before rsyncing them. I wish they could be integrated with the main gzip and rsync sources!

If you are interested in trying out these tools for yourself, and if you use a Mac, you are in luck: Macports offers both tools as simple downloads! Just install macports, type “sudo port install gzip +rsyncable” to install gzip with the –rsyncable flag, then type “sudo port install rsyncrypto” and you’re done! I’ll post more details here if there is interest.

© sfoskett for Stephen Foskett, Pack Rat, 2009. | Compression, Encryption, Deduplication, and Replication: Strange Bedfellows
This post was categorized as Enterprise storage, Personal. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

I do expect that Apple will get the bugs worked out and that MobileMe will become a useful tool, maybe even by November. But I still don’t see the compelling value in the service that makes it worth $99 (or $76.99) when Google, Yahoo, and Microsoft offer similar services for free.

I suppose it would be nice to have a “single sync” cloud service, but it doesn’t work all that well at this point. Maybe I’ll pay when they get it right. Or maybe I’ll just keep getting free extensions forever!

Note: Some of these links include affiliate codes that help pay for this blog. For example, buying an Amazon Kindle with this link sends a few bucks my way! But I don't write this blog to make money, and am happy to link to sites and stores that don't pay anything. I like Amazon and buy tons from them, but you're free to buy whatever and wherever you want.

© sfoskett for Stephen Foskett, Pack Rat, 2008. | Longest Trial Period Ever!
This post was categorized as Apple. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.