Hi Bryan: good job experimenting to improve your own health and happiness, and thanks for posting so others can learn from your experiments. My wife and I have started a blog about this sort of diet, which is sometimeas called a "ketogenic diet": http://www.ketotic.org/
For what it is worth, I think a keto diet is probably a very healthy way to live long-term. I wouldn't want you to just take my word for it, though. Eventually I hope to write enough on our blog to explain why I think that.
You know, I have to admit that the main reason academic researchers don't appreciate the sophisticated proof-of-work/proof-of-retrievability features in Tahoe-LAFS is that I didn't write it up. The 5-page paper that I linked to -- http://scholar.google.com/scholar?cites=7212771373747133487&... -- doesn't explicitly mention that it has proof-of-work/proof-of-retrievability properties at all, much less do the sort of thorough, precise specification and proof that, for example, the HAIL paper has.
Hi -- I'm one of the authors of Tahoe-LAFS. I haven't read your RACS paper before, but it looks pretty good. I appreciate the emphasis on real-world economics and on the costs of vendor lock-in. I haven't yet completely digested your results numbers to see how they inform my business, but I definitely will.
It's too bad that you weren't aware of, or didn't cite, Tahoe-LAFS when you wrote that paper! Even though you used my zfec library, which I created (by copying Luigi Rizzo's feclib) for Tahoe-LAFS's use. Heh heh heh.
I tried to get Tahoe-LAFS's existence registered in the official academic research world by publishing this: http://scholar.google.com/scholar?cites=7212771373747133487&... but it didn't really work. Most of the subsequent research that probably should have cited Tahoe-LAFS still didn't.
Perhaps that 5-page paper was too telegraphic to communicate a lot of the important properties. For example, it does not spell out the fact that Tahoe-LAFS includes a kind of proof-of-storage/proof-of-retrievability protocol. Also, perhaps, I chose too obscure of a venue to publish it in. I'm not sure.
For your reading pleasure here is a big rant by me on my blog, whining that Tahoe-LAFS is deserving of more attention than HAIL (which you do cite):
"It is frustrating to me that the authors of HAIL are apparently unaware of Tahoe-LAFS, which elegantly solves most of the problems that they set out to solve, which is open source, and which was deployed to the public, storing millions of files, and summarized in a peer-reviewed workshop paper before the HAIL paper was published."
> how many of the supported options boil down to Amazon S3?
That's a really good question. Diego's experiment used:
• memopal: I don't know if it uses S3
• SugarSync: I don't know if it uses S3
• syncplicity: I don't know if it uses S3
• googledrive: not using S3
• UbuntuOne: yes, it uses S3
• DropBox: yes, it uses S3
By the way, my startup, Least Authority Enterprises is working on a future product which also goes by the codename "Redundant Array of Independent Clouds". Our project is no relation to Diego Righi's experiment, except perhaps we inspired him by talking about it.
We've received a research grant from DARPA to implement it. The backends we're developing for are all guaranteed to be separate backends from each other -- none of them turn out to be front-ends for another one!
Tahoe-LAFS performance leaves a lot to be desired, for various reasons, but the erasure-coding levels (i.e. the degree of distribution of each file via "RAID"-like math) aren't necessarily the most important component. Brian Warner did some thorough benchmarks using dedicated servers on a LAN, and specifically look at how increasing the number of shares ("K") affected throughput:
The different colors of the samples there are for three different settings of how many shares the file was erasure-coded (RAIDed) into: 3, 30, or 60 shares. This type of file ("MDMF" type) seems to go about as fast at any of those three levels of distribution, but this older and more common type -- https://tahoe-lafs.org/trac/tahoe-lafs/attachment/wiki/Perfo... -- ("CHK" type, which is for immutable files) performs much worse for larger levels of distribution. There's probably just some dumb bug which causes this slowdown. This page has some ideas as to what's causing it: https://tahoe-lafs.org/trac/tahoe-lafs/wiki/Performance/Sep2...
Amen!! Patrick "marlowe" McDonald has really given us a gift by publishing the Tahoe-LAFS Weekly News every week. We're coming up on the Tahoe-LAFS Weekly News one-year anniversary next week. ☺
I'm working on a Free/Open Source startup named "Least Authority Enterprises". We contribute all of our work (so far) to the Tahoe-LAFS project and we sell secure cloud storage service. I, too, am eager to learn about this topic, as I feel like a babe in the woods and need any glimmers of insight I can find.
By the way, I should point out that our overall strategy of how to deal with "packaging and installation" issues is to use automation. The creation of packages such as Python .egg's, Debian .deb's, and Mac .dmg's is done automatically by our buildbot, and we also have tests run automatically by buildbots to see whether the resulting packages can be installed and run.
I'm sure that it isn't all there yet, and your bug reports would help, but you might be interested in the overall approach -- applying the principles of test driven development (if it isn't automatically tested by your buildbot, then it isn't done) to packaging.
Was this with our most recent release -- Tahoe v1.4.1? Could you tell me more about what went wrong? Perhaps by opening a ticket on http://allmydata.org so that the other people who are responsible for making it easy to install can see the issue.
If you find a security flaw in Tahoe, the Least-Authority Filesystem, we'll give you a customized t-shirt with a big thank-you from us and a working copy of your exploit printed on the front. (See site for pictures of people receiving their t-shirts.)
