3 ms·

Could Tahoe-LAFS be used for this purpose?

rsync 13y ago
A few comments about that... To be a Tahoe-LAFS "target" you do need to be running their code on the server side ... and it's python. We make a point to keep our environment as simple and sanitized as possible, which implies having no interpretors, so at this time you can't use rsync.net as a Tahoe-LAFS target. BUT! We've always been very excited about Tahoe-LAFS and are well acquainted with Zooko and his team, etc., and so we are experimenting with a frozen[1] implementation of it that we can place into our environment as a binary executable[2]. The two solutions aren't really that related, as Tahoe-LAFS (sort of) implies that rsync.net would be just one of many (perhaps ten) remote containers out there, whereas this solution is targeted to just one remote host... but since you asked ... [1] http://cx-freeze.sourceforge.net/ http://cx-freeze.sourceforge.net/ [2] We already do this with rdiff-backup, which is how we are able to support that ...
- cdjk 13y ago
  That's exciting, and something I might be interested in. My question and concern, however, is that Tahoe-LAFS seems better suited for distributed storage among unreliable nodes. I consider rsync.net to be fairly durable storage, especially since the way I use it is as backup and not the only storage location for a file. I have the same question about using S3 as a tahoe backend, which is another thing I've seen. Of course, you could just use Tahoe-lafs to store everything on one or two nodes when they're reliable and durable, but then why not just use gpg or encfs, which don't require custom clients or gateway/introducer nodes?
akama 13y ago
I believe so. If I understand Tahoe-LAFS, it can be used in a system where you don't trust the host of the data. The other benefit of using it is that it has data duplication incase one server fails.
cdjk 13y ago
I'm not sure how easy it would be to store git repos on Tahoe-LAFS, but there are two other options - 1) duplicity has native support for Tahoe-LAFS as a backend, or 2) use git-annex with a special remote [1]. [1] http://git-annex.branchable.com/special_remotes/ http://git-annex.branchable.com/special_remotes/
- rsync 13y ago
  ... and we are happy to be one of those special remotes: http://git-annex.branchable.com/devblog/day_22__gcrypt_on_rsync.net/ http://git-annex.branchable.com/devblog/day_22__gcrypt_on_rs... http://git-annex.branchable.com/forum/making_good_use_of_my_shiny_new_rsync.net_account/ http://git-annex.branchable.com/forum/making_good_use_of_my_... http://git-annex.branchable.com/special_remotes/rsync/ http://git-annex.branchable.com/special_remotes/rsync/

rsync 13y ago

A few comments about that... To be a Tahoe-LAFS "target" you do need to be running their code on the server side ... and it's python. We make a point to keep our environment as simple and sanitized as possible, which implies having no interpretors, so at this time you can't use rsync.net as a Tahoe-LAFS target. BUT! We've always been very excited about Tahoe-LAFS and are well acquainted with Zooko and his team, etc., and so we are experimenting with a frozen[1] implementation of it that we can place into our environment as a binary executable[2]. The two solutions aren't really that related, as Tahoe-LAFS (sort of) implies that rsync.net would be just one of many (perhaps ten) remote containers out there, whereas this solution is targeted to just one remote host... but since you asked ... [1] http://cx-freeze.sourceforge.net/ http://cx-freeze.sourceforge.net/ [2] We already do this with rdiff-backup, which is how we are able to support that ...

cdjk 13y ago
That's exciting, and something I might be interested in. My question and concern, however, is that Tahoe-LAFS seems better suited for distributed storage among unreliable nodes. I consider rsync.net to be fairly durable storage, especially since the way I use it is as backup and not the only storage location for a file. I have the same question about using S3 as a tahoe backend, which is another thing I've seen. Of course, you could just use Tahoe-lafs to store everything on one or two nodes when they're reliable and durable, but then why not just use gpg or encfs, which don't require custom clients or gateway/introducer nodes?

akama 13y ago

I believe so. If I understand Tahoe-LAFS, it can be used in a system where you don't trust the host of the data. The other benefit of using it is that it has data duplication incase one server fails.

cdjk 13y ago

I'm not sure how easy it would be to store git repos on Tahoe-LAFS, but there are two other options - 1) duplicity has native support for Tahoe-LAFS as a backend, or 2) use git-annex with a special remote [1]. [1] http://git-annex.branchable.com/special_remotes/ http://git-annex.branchable.com/special_remotes/

rsync 13y ago
... and we are happy to be one of those special remotes: http://git-annex.branchable.com/devblog/day_22__gcrypt_on_rsync.net/ http://git-annex.branchable.com/devblog/day_22__gcrypt_on_rs... http://git-annex.branchable.com/forum/making_good_use_of_my_shiny_new_rsync.net_account/ http://git-annex.branchable.com/forum/making_good_use_of_my_... http://git-annex.branchable.com/special_remotes/rsync/ http://git-annex.branchable.com/special_remotes/rsync/