I think you're framing it from the right angle. If FEC gives a better
user experience, then it's worth the effort. But even from a UE-centric
approach, I can't help but wonder if the easiest possible approach --
serverside replication -- still wins.
Again, I love p2p, it puts bread on my table. And I think flud is
uttely amazing technology. But I'm still trying to see the advantage of
all this versus just hosting on S3 for $0.10/GB/month. I sense that the
advantage exists, but I don't think I've heard it clearly enunciated
yet.
-david
On Wed, 13 Jun 2007 11:29 pm, Alen Peacock wrote:
On 6/13/07, David Barrett <[EMAIL PROTECTED]> 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. ;)
Alen_______________________________________________
p2p-hackers mailing list
[email protected]
http://lists.zooko.com/mailman/listinfo/p2p-hackers
