Storage is Cheap, Don't Mutate - Copy on Write

There's a problem here in going from their specific case to where this may make sense, to the more general case they're trying to make, where it doesn't.<p>For instance, if you're mapping disk space to memory addresses and have large blocks of data, this would mean that every time you needed to update a single byte, you'd either have to duplicate the entire block (possibly several mega- or giga-bytes) or give up linear access. Yuck. There are a lot of use cases that would absolutely be miserable for.<p>You can get away with such things a lot further if you're implementing these things at the file-system level.

I'm all for finding ways to avoid locking and using immutable objects is one way to help, but this:<p><pre><code> Remove the mutation part and now you have a version history, allowing conflict resolution. </code></pre> is a little too "hand-wavy" for my tastes. Conflict resolution is not an easier problem than resource contention.

I followed the link at the bottom, and it made me pretty angry. Hashbo is a very neat example of the kind of bullshit I hate in upcoming software products and services.<p>The only information available before asking for signup is this;<p>&#62; Hashbo is a simple innovative, new way to communicate, collaborate and curate.<p>What the hell is that supposed to mean? Is it a blogging system? Microblogging? A social network? IM? Is it some combination, or a new thing?<p>People come to a site like this with the question "What is this and <i>why should I care?</i>". At the end of that (quite nice) animation, I have no idea, and that doesn't make me intrigued and curious, it makes me annoyed and frustrated at not getting a straight answer.<p><i>Nobody cares about your buzzwords</i>, they care about what your site is, and what it can enable them to do that they couldn't do before.

Ironic that SQL is mentioned here - I think the idea is close to Multi-version concurrency control, which "real" databases have been doing for years now.<p><a href="http://en.wikipedia.org/wiki/Multiversion_concurrency_control" rel="nofollow">http://en.wikipedia.org/wiki/Multiversion_concurrency_contro...</a>

This is what bugs me about state machines (like <a href="https://github.com/pluginaweek/state_machine" rel="nofollow">https://github.com/pluginaweek/state_machine</a>).<p>Adding a history or audit always seems like a giant hack.

One of the most versatile ways to have scalability and partition tolerance while also having consistency is having eventual consistency.<p>And having eventual consistency with MVCC implemented with vector clocks really rocks.<p>Riak takes Brower's CAP theorem seriously and even lets you configure the values per bucket so that you can get more of C, more of A or more of P.<p>You don't need to store all the history, just the contentious history. Riak pretty much rocks in the sense that you can add nodes to it and it just works, or take them away and it just works. Just like Dynamo. (Not like Cassandra.)

Just thinking out loud: does doing copy on write result in less filesystem fragmentation (assuming the data is not held in RAM)?