As a followup, Facebook Offers Scholarship to Female Computer Science Students - http://www.webpronews.com/topnews/2010/07/02/facebook-offers-scholarship-to-female-computer-science-students

I wrote a blog entry a few years ago discussing how to do this with ACDSee and Fotki here - http://frozenpixels.wordpress.com/upload-your-acdsee-photos-to-fotki-with-tags/ I still stand behind ACDSee, but recommend against the pro version, as I've yet to see any functionality there that requires most users to upgrade. ACDSee lets you tag/categorize photos and videos, and is still very fast with my 18,xxx photo collection. You can export the entire catalog database to an easily read XML file, so you aren't locked into a proprietary format for life. Additionally, the ability to embed your tags/categories into the images (or vice versa - import existing tag data into ACDSee's database) is a feature sorely missing from most other utilities. Some other nice features are the ability to sort just about any way you'd want to, simple and/or filters (show me pictures that have Bob AND Tom, etc.), calendar views, and decent basic editing to crop, fix red-eye, and so on. I think there's a trial version you can download and play with. I'm still running version 7.0, and haven't seen a compelling reason to upgrade. There are free alternatives out there, but none possess all of the features of ACDSee, and most are missing some key ones IMO.

I'm glad you posted an actual size. I'm always curious what others feel is a large database, to me, 150G isn't overly large at all. The company I work for processes phone records, where we receive about 6M new records each day. Depending on the database (some for KPI metrics, some for warehousing duties, etc.) the sizes vary dramatically, but our "monthly" databases are typically in the 250G range, while our largest is currently just under 3TB. I checked what I believe is our largest table, and it currently has just under a billion records. It's been higher in the past, but we've lowered the # of months of data stored there recently. We are a Microsoft shop, and all of this is in SQL Server. For normal storage/queries, a decent SQL box will suffice depending on how many users are hitting it, etc., but we built a custom distributed processing system to do the actually processing work.

You raise some excellent points, and if rolled out correctly, you're right, 21MB/s wireless will wipe the floor with wired connections for the masses. The problem is whether or not it's done correctly.

The iPhone ushered in the portable/handheld computer with internet access for the average person. You could get an add-in card from a carrier for your laptop, but most people wouldn't. If that same data plan was part of your existing phone bill and your phone had an actual (usable) browser...things get different.

If you look at how poor 3G is in a lot of the areas, it's clear something isn't right. In Springfield, IL 3G coverage is here, but regardless of phone type, network issues abound. Try doing anything remotely intensive w/the phone, and you'll see how slow their 3G implementation is. It's NO where near 3.6MB/s. If they couldn't roll that out right, what's to make me think they'll do it right at 7x faster?

But it may not be everything you're looking for. My requirements were:
1 - Mask the filename
2 - Encrypt the contents
3 - Add recovery data in case the file got damaged
4 - Ability to view unmasked filename from web

I put together a batch file I could drag/drop multiple files onto that used WinRAR to compress the files (individually), with encrypted filenames, a password (of course), and included archive recovery data. It then used ReNamer to encrypt the .rar filenames. After that, I simply FTP'd the files to the server.

I had a webpage that would accept a password, and unencrypt the filenames so they were viewable in readable form on the page. Each one was a hyperlink. There was an extra step required if you wanted the downloaded filename to be unencrypted as well.

After uploading 115G or so, my host alerted me to the fact that they didn't allow me to keep offsite backups there. :) So in the end, I'm not even using it at the moment.

My solution didn't allow me to search within the files, but it did allow me to store files on the server that they had no way of viewing the contents of, or guessing the contents of based on filename.

I also negated photo search sites, but it didn't stop cooliris, flickr, fotki, etc. Admittedly some of those aren't search sites, but they offer photo searching just the same.