You folks might want to eves drop on the conversations taking place in VolunteerGrid2. You might learn something about how your software is actually being deployed in the wild.<br clear="all">----<br>- Think carefully.<br>


<br><br><div class="gmail_quote">On Wed, Feb 2, 2011 at 12:10 PM, Brian Warner <span dir="ltr"><<a href="mailto:warner@lothar.com">warner@lothar.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

On 2/1/11 5:36 PM, Greg Troxel wrote:<br>
><br>
> After looking at your Octavio page, I think your simplifications<br>
> relative to tahoe can be divided into several groups<br>
><br>
>   no erasure coding; just replication. This gives up some performance,<br>
>   but seems like a reasonable tradeoff for many.<br>
<br>
Note that it also gives up reliability: according to my math, 5-of-10 is<br>
much much better than 1-of-2 when the servers are good (say >90%<br>
availability). (on the other hand, 1-of-2 is much better when the<br>
servers are bad). But yeah, it makes repair trivial, and is easier to<br>
explain to users.<br>
<br>
>   Removal of CLI and WUI, and using only FUSE. This is the aspeect I'm<br>
>   most in favor of.<br>
<br>
My problem with FUSE as the primary entry point is that it loses the<br>
whole least-authority model. The POSIX filesystem APIs don't expose<br>
things like retrieving a dircap for the subdirectory that you want to<br>
share with a friend, so the easiest thing to do is to share your whole<br>
rootcap with somebody, the equivalent of sharing passwords from the<br>
bad-old-days. It also doesn't let you write programs that are restricted<br>
to interacting with just a subset of your filesystem, so all the usual<br>
Confused Deputy vulnerabilities are still around.<br>
<br>
>   Removal of introducer; presumably each client has to be configured<br>
>   with all servers; I'm not sure this is a win.<br>
<br>
Yeah, I think we need something easier than manual configuration<br>
(especially if you want to maintain proper security between the nodes,<br>
which means you need to copy some cryptographic material from one box to<br>
another). I'm not convinced that Tahoe's Introducer is the best approach<br>
either, particularly with respect to grid-membership management: I'm<br>
looking forward to experimenting with Invitations and similar<br>
create-or-join-a-grid approaches.<br>
<br>
cheers,<br>
 -Brian<br>
_______________________________________________<br>
tahoe-dev mailing list<br>
<a href="mailto:tahoe-dev@tahoe-lafs.org">tahoe-dev@tahoe-lafs.org</a><br>
<a href="http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev" target="_blank">http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev</a><br>
</blockquote></div><br>