I actually built a similar system, but you lost me at

"run a backup utility... Norton Ghost to wipe the drive"

ImageX is built-in to Windows (in the AIK) and it does a fantastic job of backups, it even does compression and single-instance storage to save time and space. To wipe the disks, you can run any number of free/cheap utilities (Active KillDisk?) or you can just run 'diskpart' with 'clean all' to write zeros (good enough for 99.5% of cases).

"Linux dd doesn't have a problem doing the backups of anything as long as it is mounted"

Linux DD will also save all your deleted data as gobbledygook and lead to GIANT image files. If anything, you want these backups at the file-level, not block-level. Bonus points if you can backup to something with deduplication or single-instance storage.

Here's what we do where I work:

You'll need a Windows Server 2008 R2 with Windows Deployment Services role. You basically want to set up an isolated network with PXE booting, load a Windows PE disk into the PXE server. Modify the PE image to mount a drive off the server (to store your backups), then run a wipe script. As soon as the backup is done, you can actually fire up the next machine, you don't need to be 'connected' to wipe the disk.

For our purposes, we use Active Killdisk to wipe, and ImageX to backup.

You'll need PXE-enabled NICs or a gPXE boot disk. You can also do the exact same thing with a Samba server, a PXE daemon, and a basic Linux boot drive being served-up over PXE, but the learning curve is steeper. Also, ImageX is pretty awesome because it allows single-instance storage. You can append ALL you computer backups to one image file and only the different files will be stored more than once, cutting a massive amount of time and space from your backups.

This. If you can MITM and decrypt 500MB of HDMI data on the fly, you may as well do some basic video compression before dumping out to disk.

Also, for high-data linear loads like video dumps, HDDs are still superior to SSDs.

> I sure wouldn't like some guy touching my food before I eat it

I love this idea that people seem to have that food is somehow at all 'clean'. Everything about food except for the part when the server brings it to you or the stockboy puts it on the shelf is hands-on and 'unsanitary' by most people's understanding.

I've fished commercially before. Do you know what the back-end of that market is like? Imagine a football-field sized warehouse with two or three inches of fish-gut water flowing by while strange-looking dudes poke and prod your fish and offer prices.

Those bags of chickpeas at the falafel place are sitting on the sidewalk for a good fifteen minutes, where thousands of people walk, hundreds spit, and several piss or vomit every day.

It's not a big deal, the world is awash with benign germs, they're not going to kill you. The stuff that will make you sick is the real nasty germs found in spoiled meats and such, not the harmless stuff on all of our hands.

In reality, someone picking through a bag of M&Ms isn't at all unsanitary or unsettling.

In that case, it's time top open up some performance counters and figure out what's causing the bottleneck. It could be the VM or host choking on interrupts, latency in the network adapters (virtual or physical), or the TCP window being too small for the latency.

FireWire was also supposed to 'go optical' at some point, but market forces kept it copper.

Well yeah, I can saturate a gigabit link from a Windows 2000 box running a Pentium III, or on my embedded Linux-based consumer router. My guess is that the issue here isn't actual network performance, it's the underlying disk performance. 600-700mbits is remarkably close to the single-spindle speed of the average spinning media.

"And any 100+ connection is materially more useful today than the existing 10-20Mbps connections."

Do you really think so?

Nobody at my house (four users) even noticed when I changed from 5mbits to 20mbits. Hell, from the back yard the wireless only gets 3-5mbits anyways.

I noticed, but that's because I do a fair amount of large file transfers and remote backups. Most people don't. Most people just want to watch Netflix while Johnny browses. Netflix connections only stream at a few megabits anyways. Even raw blu-ray is only 36mbits, and any distribution medium is going to use a codec that squeezes a bit more, just for sanity.

I have a 20mbit uplink at home and a milti-GB uplink at work.

Honestly, I see almost no difference when it comes to 'regular stuff' like watching movies, browsing, email, and gaming. Home users generally don't need to upload or download multi-gigabyte archives to the 'net. When they do need to download huge files, it's usually in the context of streaming, where the downlink just needs to be fast enough to play the media without hosing the connection.

"...in a virtual environment where there's no possibility of crappy hardware or drivers."

Um, there's definitely going to be a performance hit running in a VM. Every packet between VMs generates an interrupt on each VM involved and at least one on the host. There also very much is the chance for crappy drivers to be involved, your CPU is likely emulating an ancient generic NIC. Try using the Paravirtual drivers if you can, they'll offload as much as possible to the host, which knows more about how to schedule and buffer things.

Cool, I've never heard of that before. Thanks!

Well yes, sort of, but the 'receive window' is the size of the data to be transmitted. TCP is designed to give reliability in near real-time, this kind of application needs nothing like that.

Well there's no point is using IP at all, IP is designed to allow for four billion addresses. What you need in this case is a point-to-point, like a serial cable, not a network stack. Having a network stack would seriously add to the overhead.

And you certainly don't need UDP, or FTP running inside it. Dropped data is a no-no, I believe, but there's no reason you can't just send commands and return data in the raw, then ask for corrupted blocks from the data to be sent again.

It would look like this:

E: Send me file 102.
M: Sends file....
E: Thanks, now send me sections x, y, and z of that file again because I missed it.
M: X, Y, Z...
E: Thanks, now delete the file, point the camera ten degrees left, and take another picture.

How do you know if the data is corrupt? Well you do CRC checking on the wire, and you split all file transfers into chunks and include hashes with them. The chunks need to be right-sized so there aren't too many retransmissions, but big enough not to incur massive latency and overhead.

"If it does not benefit me, then it does not need my support, and will cease to exist when it does not maintain my support."

Um, you aren't familiar with how government projects really work then, are you?

I won't engage much more, just pointing out that while you're spinning a tale of some magical utopia where everything is optimized through the government, the VAST majority of us in the USA feel very differently about it. In other terms: "Your ideas do not benefit us, so you don't have our support."