[flud-devel] [p2p-hackers] announcing Allmydata-Tahoe v0.3
alenlpeacock at gmail.com
Wed Jun 13 22:19:35 PDT 2007
On 6/13/07, David Barrett <dbarrett at quinthar.com> wrote:
> True, but there's something to be said for real simplicity versus
> "simplicity through encapsulation".
I'm a huge fan of simplicity too, because complexity is almost
always the enemy of good engineering. You are absolutely right.
But let me frame this issue from the viewpoint of the end user, who,
let's be honest, only cares about a couple of things in this scenario:
1) does the system backup my data securely?
2) can I recover my data when I need to?
3) how inconvenient is it to do #1 and #2?
#1 and #2 are given; without them the system is a non-starter. But
I will assert that #3 is /really, really, really/ important. The
great bit bucket in the sky is littered with solutions that fulfill #1
and #2 perfectly, but failed miserably at #3.
What does this have to do with FEC vs. replication? It has
*everything* to do with FEC vs. replication. In the remote backup
scenario, the biggest bottleneck for most users is still the network.
Taking several days to backup a few GB of data will always make the
user feel better than taking weeks. And that is what FEC gives you
over replication (as zooko already effectively pointed out).
I don't think this takes anything away from your main thesis that
"there are real advantages to keeping things simple under the hood."
But I will argue that the complexity of FEC is nothing to lose sleep
over, and that it is very easy to prove to oneself that the stuff
works. We are talking about +40-yr-old tech here, stuff that is used
today in everything from DVD players to cell phones to satellite
communications to hard drives to RAM. There just aren't that many
edge cases to test in the first place, and all are easily exercised
with unit and system tests.
btw, for me one of the funnest demos to do with flŭd is:
1) bring up ~70 flŭd nodes
2) backup a handful of files
3) show how efficiently we are consuming remote storage space
(using something like http://flud.org/images/fludtestgauges.png)
4) delete all the data locally (oh noes!!)
5) kill ~30 of the nodes randomly (oh noes v2!!)
6) restore *all the data* from the remaining nodes.
Doing the same demo with replication just isn't as impressive.
But, I'll also admit that the world at large is probably not quite
ready for this type of awesome. Seriously. Lots of people out there
are still leery of backing up their data remotely at all, let alone
backing it up to more than one computer, let alone backing it up to
stranger's computers, let alone trusting math to do the right thing
with their data. It's sort of an insane man's battle for mindshare.
Someday, however, our species will evolve and achieve enlightenment.
When that happens, something along the lines of Tahoe or flŭd (or any
of the other insanely ambitious systems out there) will be there for
humanity to embrace. And we'll all have a good laugh about how naively
we used to do this stuff. ;)
More information about the flud-devel