[tahoe-dev] Tahoe-LAFS is widely misunderstood

[Chris Palmer]

Thank you Shawn, your example clarified things for me. I had a dim intuition
that you might say something like what you did; specific numbers help me.
Thanks much.

> Reliability and cost are independent and largely opposing parameters, so I
> don't really know how you can evaluate that.

Really? I find their opposition "natural" and hence not independent. All
other things equal, the more reliable version costs more. There are
obviously areas between the curves drawn by various erasure coding schemes,
including extreme examples like k = 1 and k = M, and you can win at both
cost and reliability in the margins. As you show, the "margin" can actually
be significant. But as you note,

> * Ignoring failures avoided by simplicity.

we win the margin by changing the form of our payment: we save dollars, gain
reliability, but pay in usability and development/debugging time. For
example, if a user finds they mis-tuned the erasure coding paramters and
needs to re-tune them later, they may actually have a net loss in dollars or
even in reliability.

In my experience at least ;) human error is much more likely than hardware
error, and person (developer, sysadmin, user) time is much more expensive
than hardware. Additionally, although I now see why you say k = 1 is the
least reliable at a given cost, I suspect there is a cut-off point at which
cost and reliability are good enough, and yet we save a margin of person
(developer, sysadmin, user) time and error costs.

Especially in an open source project, it's the latter savings I want to
maximize.


-- 
http://noncombatant.org/