Bill Bumgarner

50 cents per gigabyte seems to be the price of hard drives these days. In all cases, the only way to achieve 50 cents/gigabyte is to take advantage of rebates, so it isn't the "I want to build a data library and need 2,000 200GB drives" price. DealMac has several deals listed and Fry's has stacks of hard drives, several of which break down to 50 cents/gigabyte.

One year ago, the price was at least $1/GB and that was relatively slow drives. Now, 50 cents/GB buys you an 8MB cache on a 7,200 RPM drive with an 8 - 9 ms average seek time.

But the warranty period has been vastly reduced. Three to five years ago, drive warranties were typically 5 years. Then it dropped to 3. Now it is a 1 year warranty, but-- at least with Western Digital-- you can buy an additional 2 years for $15. Not sure I like that trend. Nope. Sure. Don't like it.

I picked up a 160GB Western Digital to be used as the backing store for my encoded CD collection. The CDs will effectively act as a backup and I use the "Purchased Music" group in BackUp.app to back up the songs purchased from the music store.

I'm disappointed by two particular details of the current hard drive market. First, the only effective means of backing up such a large volume is through the use of RAID. But since drives are only sold at the discounted price by taking advantage of a one-per-household rebate, the second device is expensive (Actually, this turns out not to be the case for the WD drive; WD will honor up to two rebates per household!). Secondly, no one seems to have built a decent 1394 case with two drive bays that isn't also significantly more expensive than a single device case.

How far we have come...

In 1987, I paid $1,400 for an 80 megabyte hard drive for my Mac Plus. Now, $1400 would buy nearly a terabyte without rebates (300 GB drives for $400) and 80MB is less space than the amount of RAM shipped in a typical system.

... an infinite # of miles to go.

I actually got off my ass and started riding my mountain bike this week. 1 mile on Tuesday, 2 miles on Thursday, 3.25 today. I used to ride all the time and was actually in really good shape. Somewhere along the line, my shape turned to "pear" and walking up a couple of flights of stairs became challenging exercise.

Pathetic. Hopefully not for much longer. I'm purposefully easing back into riding to avoid damaging myself severely due to my rather fragile current condition.

It isn't without its geek centered aspects. I'm using a Magellan GPS to track distance, speed and to ensure that I get home in time to do whatever is next in the morning schedule. I would like to be able to download the tracks to my Mac. I figure I'll solve the problem with the daily trivial rides such that when I'm actually doing interesting rides again, I don't have to face the stupidity then.

Dos Compadres Taqueria is located at 100 W. Hamilton (near Winchester) in Cambell, CA. Excellent mexican food, very cheap.

I had Camarones Rellenos, thinking "Shrimp. Healthy Seafood. Not too heavy.".

Ha! How wrong could I be?

Turns out that Dos Compadres' Camarones Rellenos is Shrimp wrapped in bacon and deep fried until golden brown. Quite spectacular, actually. I would recommend it to anyone.

I found this recipe: With cheese (sounds good, but the cheese isn't necessary though it does add a slight bit of extra heart stopping power). Honestly, you don't need a recipe. Just wrap bacon around shrimp and fry with an extremely light batter.

Unix has long had an EDITOR environment variable whose value would be used by many programs whenever the user was expected to edit a hunk of text. For example, CVS or Subversion use the program specified by EDITOR to edit commit messages.

bzero, my new weblog rendering/publishing tool, uses EDITOR to edit weblog posts.

Given our modern desktop environments, it seems kind of silly to limit EDITOR to just command line tools. It would be nice to be able to use TextEdit, Xcode, or BBEdit to edit files normally edited from EDITOR. Emacs or vi are perfectly capable editors, but they simply don't have the level of integration with the system that a GUI level editor has (yes, there are .app implementations of Emacs, but it is still not exactly "user friendly" in the classic Mac OS application sense).

While open can be used to easily open any random file in any random GUI application, it doesn't work in the context of EDITOR. When something like bzero, cvs, or subversion invokes the EDITOR, it expects the command to not exit until the editing is completed. open exits immediately after it has successfully passed the file off to the GUI app, long before editing has even started.

BBEdit provides a command line tool that does exactly that. With the --wait option, the command line tool will not exit until the associated editing window is closed in within the BBEdit application. Exactly what is needed.

If you happen to have BBEdit installed, you can install the command line tool by going to the "Tools" subsection of Preferences and click the Install "bbedit" tool.

It will install both the bbedit tool and a very nice man page.

Once installed, you can set EDITOR to bbedit --wait --resume and most things will work correctly. However, there are a handful of apps that don't like it when EDITOR is set to something other than just an executable. As such, you'll probably want to set EDITOR to point to a little shell script that invokes bbedit with the appropriate arguments. I created as script called bbeditwait with the following contents and shoved it in the bin directory within my home account:

#!/bin/sh

bbedit --resume --wait $*

Then set EDITOR to ~/bin/bbeditwait. Unlike the suggested script found on the BBEdit site, this one will allow you to edit multiple files. There is a bug, though, in that it will literally edit each file one after the other, opening the next after the previous has been closed. It should just open all files at once and exit from bbedit when all requested files have been closed.

Update:

Ben Hines mentioned that this would make a good Mac OS X Hints submission. There is already such an entry in OS X Hints, but it was rather generic and the suggested shell script in the comments doesn't quite work the way I wanted in that it only accepts single files.

This isn't new. Under OpenStep, I patched TextEdit such that an accompanying command line tool could edit files in the same fashion as 'bbedit --wait'. It also allowed one to edit files remotely. So, if I were logged into a Solaris or Linux dev box from my OS X Server / OpenStep machine, EDITOR based sessions would pop up on my local machine as a regular TextEdit document.

I probably still have the code around somewhere. I should probably dig it up and post it.