the_paul

It's a female? How can you tell?

This is not true.

We (Space Monkey) intend to make the device usable on its own, without the Space Monkey service, for people who purchase the device and don't want to continue the service. It's unclear as yet how close we'll be able to get it to a turnkey NAS solution, but at least it'll have Linux installed and you'll be able to SSH to it, use the drive, install whatever software you need, etc.

No. Although being a distributed network with similar reliability and availability and performance requirements, there are some similar technologies/approaches at play.

There won't be hundreds of copies. A device may back up data to hundreds of other devices in total, though.

Space Monkey data will be resilient to considerably more than 3 nodes failing.

These are totally valid concerns. The average home internet upload cap, especially in the US, is not very generous. But the idea with Space Monkey is that most of your ongoing data access will be directly from your own device. If you're at home already, that will be especially fast. If not, it will be slower, but we're still able to watch movies in remote tests over a crappy home DSL uplink.

Other people's upload bandwidth only needs to come into play if your device isn't available: its hard drive breaks, it gets stolen, your house burns down, etc. In that case, yes, getting all of your data back probably will be slower than you want it to be, but you will get it all back.

Regarding redundancy, be assured that Space Monkey can provide much better numbers than RAID-6. We do assume that a decent percentage of devices will have poor network uptime, and we want your data to be available and redundant even in the face of that, even if the "fancy algorithms" take more processing power on the devices than we would need otherwise :).

(a) I think that's the same problem that all consumer devices have that "phone home" for updates; game consoles, TiVos, smart TVs, VoIP phone adapters, etc.

(b) If all you need is archiving of your stuff, and you don't want ongoing fast access to your movies, music, photos, etc., then sure. Glacier is probably a better fit.

Yeah, Space Monkey is a business, and we hope to be able to make at least some money off the whole deal in the end.

But also yes, there are nontrivial ongoing costs to keeping the network working and working right. For example, we need dedicated online servers to allow NATted devices to talk to each other, coordinate storage use, and deploy security patches and bugfixes, and we want to add more features over time.

The encryption is done on the device. Other people's devices (obviously) won't have your encryption key, but since Space Monkey will have a web interface to get at your files, you can tell that Space Monkey will have access to your key.

Regarding durability, the Kickstarter page mentions:

    Q: Is my data safe?

    A: Yes! Super safe. Here’s why: when you put files in
    Space Monkey, you not only have a copy of everything on
    your Space Monkey device, but each file is chopped up into
    tiny pieces, encrypted, then stored to dozens of locations
    outside of your home, in such a way that even if half of
    those locations were destroyed, all your files would still
    be safe.

The whole terabyte is yours. The device has extra capacity to account for the rest.

...a competently engineered Turing Machine can do everything NoSQL databases can, particularly limited databases like MongoDB. ... Emacs is just as fast as NoSQL du jour in the hands of someone that knows it.

FTFY.

The difference between using a good competently engineered distributed database and PostgreSQL is that when your prime concerns are horizontal scaling and operations costs, the distributed database can be an order of magnitude simpler and faster than PostgreSQL given the same amount of effort.

They sound like they should be, right? Mozy did storage, EMC did storage?

But as a Mozy employee during the time of the acquisition, I'd like to state for the record how emphatically and fantastically wrong this is. There is more of a "natural fit" between Sesame Street and Godzilla's wang than there was between Mozy and EMC. :)

It's not dissimilar to the legal ramifications of browsing HN, then. Look, encrypted data!

xQq84/+wpysSnUveVUX6592sHzGBptxysvtginJr2OFkDifXYtNCFg==

I submit that you're probably screwed anyway in those countries and/or jurisdictions, whether or not you have someone else's unreadable contraband. :)

In fact, here's an exercise. The following data represents a base64-encoded encrypted image:

qipN5pKHq+CCBm+yfHz0Y/NmkLd+1GjuowopHYWs3qjo6wuPsrulOBZJUXGt tsc465cM9p2qUZvKYxt/5M+2+zkjdbNMi447cLY4KUw3Xb934KDkyrviZYkh gryO3C5cPw0ZVitr/6e3pyQiEGga4SwbskCQhMw7XlqDYJowpCs/Qsh8ZQiR 2/+zQ/CGhYfU37dIQYVzqPCM7y5DHcDePGvzx2BCzu8OQThLnMWGiz5kODzY 49zrfoTQg8W0NKIC7rD529CnPVyfQok+u8L8LGqZSbOh2CUygWIF3mjmTGtd EnUBrkI49aVjeEa9/anCUw2nBRbmWWZZ5p1bvDYHGkEtlaFTJrSfVnuejBa1 NqNdMFIU6qAlpJ75Js8O2+jNi+qbVE/JUjYFtB45mf0B/E4GXbBcjg/gWhSi LvTOX7P8+HDMhg8jB2nnJ2Yf3l2CPopjKczWGZMUu3P8jamdp2kv67q0kIrE xGc3sr8r8R78StuQUVpp+5SexykhDOMQGowdBQ2yLYtRtoNDlWm47x7agM8i YP70n4wLhwZ03JH+2WmmVLVx2Yk4AZIU4t7XfdaoYaC33U58QeSaBJ4fdsJO PBp1L559jJTRrBk996gLN7V0oQSRMCWF67KezK3Bk2a07vzxjiXfwJOB5BDl ooSvoTdu5Slv9C+aIoa4ade7r7umC8Ac84XCfBY/UlmWIq0VogXuzOzZ2WkX 0uUpCnz2WX3rShKFFd8w9HhoxsOaR2S3sFbL7foqpx9SXYYjpM2vJHpEjMFQ W7Xmqlvb/2m1aUB2f6qFmqKPjo5/zIAOl90YDoDaQSin9C9/X6WRydHHcu1/ mrjo5LSdfouqOwVXMDnh95/YPvSGdO8GP35pRKUceidM4oYyQCRYGb3xKn0O TP/jKy3MXz/CeZsbxQtobq1DlC6NVVp5UifQM72ufdI5xcqObQSECFXKTTtt FuGdg+ZQ/0yLQ6WQde1B44LJML0MWIYPjrO74tOiCn4VZEsC9lakMMJZ2Qyp M1BRsh7xeQ0eVMOCEe5+yDV45uvchoGyAZsr2qTcgqTCKm4U9r1PUqBjWUjS AkVE3uIHjwL7D+gDvRuvNk4PdHpUX0p+oLp2ATmcR+TmhSNL8UEuAAw1ajgH SlhtS/BdXWkC5SFbfp6Dvt+WD+/2CwAZGgImAWXPv0YM+za80Q99au4NPR+L +KQW2wjChNkEKau9Jq5uGf36Vnt08dxVRoWzsWcPHmlFquXQrsBVsbe2Yu6v EfTAwaxFUB1kgLdTWJlxObfiBtzwf855yIggNcJZ9b/e9k6NpdJbCBYQJElf RN5qYGh4A6ASpZgZa86e2nPHvIJprm7IN9uqiI2EP9fPQp+zLorNKwxnZkv7 W//D28p0Wy5tS5F5p2ee7QI=

Is it pr0n? Is it an image of US gov't classified data? Is it hate speech? Who knows, but now it's on your computer. There are a lot of other ways someone could get data onto your computer without you knowing if it has a particular meaning.

This is one of the most straightforward possible applications for cryptography in data storage- no worries about key negotiation or cipher negotiation or PKI infrastructures. And yes, they're encrypting your data before sending it anywhere- that's pretty explicitly mentioned everywhere the service is explained.

So, if you're asking whether you're legally liable for the content of data on your hard drive which you have no possibility of decrypting, um, the answer is "no".

It's not exactly clear from the paper what CA should mean.

I've seen people claim it means "you guarantee both consistency and availability, as long as there are no network partitions (you don't have to handle those because you haven't chosen P)". That's a supportable claim. So you can do that, but it's kind of a useless choice, because as long as there are no network partitions, both CP and AP systems can also guarantee full consistency and availability.

I lay the CAP family out thus:

* CP: on network partition, lose availability

* AP: on network partition, lose consistency

* CA: on network partition, lose both

It seems to be a common thread among distributed systems engineers who claim to have beaten CAP: "network partitions don't matter for whatever reason, so therefore I can always guarantee both availability and consistency and so CAP must be wrong yaaay!!"

Sorry, no, nice try.

"Many concurrent algorithms are very easy to write with a GC and totally hard (to down right impossible) using explicit free."

This is not the same as:

"All concurrent algorithms are very easy to write with a GC and totally impossible using explicit free."

So if you've written a concurrent algorithm with an explicit free, congratulations, but that doesn't mean the statement is wrong.

A good way to support said finance reform is to follow Lessig's recommendation (http://www.huffingtonpost.com/lawrence-lessig/on-the-signifi...) and help out Buddy Roemer's campaign.

Er, 2012 - 1996 = 16, not 17?

I feel old already. I don't want to get charged for the extra year.

Macros were also the reason I wrote Noodle, which was a similar effort (Lisp compiling to Python bytecode) back around 2004. The project died when I couldn't figure out sane, easy-to-learn rules about how to make macros live with modules and imports, and I found I didn't like the syntax concessions I had to allow to make attribute access less of a terrible pain.

I still think something like this would be worthwhile, and I wish you the best of luck! I particularly like your (.bar.baz foo) syntax. And good on you for moving away from bytecode generation; I also found that to be a dead end.

So what are your plans for macros+namespaces? Will macros from imports live in the same namespace?

And what did you mean by "Python supports only two levels of lexical scope" at http://www.thibault.org/adder/ ? I don't recall any constraints regarding lexical scope levels in the VM.