Ori File System
ori.scs.stanford.edu
ori.scs.stanford.edu
My question is:
Ori is a distributed file system built for offline operation and empowers the user with control over synchronization operations and conflict resolution. We provide history through light weight snapshots and allow users to verify the history has not been tampered with. Through the use of replication instances can be resilient and recover damaged data from other nodes.
Does a user actually want to do any of these things? Not a techie user, but a user. Someone who cares about their photos, for example.
One big use case, which I often run into, is that Dropbox is very valuable because it serves your files through a website. Yes, that means Dropbox and governments have access to that data. On the other hand, it's fine for Dropbox and governments to access my "chatlog with my ISP where I complain about a late fee and ask for a refund" that I saved to Dropbox but need to pull up on my laptop which doesn't have Dropbox installed. That type of thing is where Dropbox really shines, so I'm not sure I'd want to put my docs into a system which doesn't have a web interface.
Those kinds of "casual documents" are extremely common. I'd say most of my stuff in Dropbox isn't actually sensitive, whereas a small percentage is highly sensitive. It'd be great to store the highly sensitive into a filesystem like this, since I could control it directly, but that involves quite a lot of effort to set Ori up and to understand it. And it's not entirely clear that it's more secure than, say, encrypting my Dropbox files directly.
In summary, what precisely is the value add that Ori brings to the user? I'm trying hard to see it, and I want to believe there is one.
I know a few families, for example, who are now using their own social-media apps built by family members, and for which there is no outside access - yet they have their own network, trust system, shared media and data, and so on.
It is completely within their control.
So there are people out there for whom Ori and its peer technologies are very important. Not everybody wants to just genuflect in front of the ultra-corporate ruler(s). Its quite possible to continue using computers unhindered by third parties; tools like Ori assist that - technologically as well as culturally. Get all your friends on their own p2p networks.
I sure want this. Setting multiple nodes might be cumbersome, but it should be worth it for important data.
Also, the use case you are presenting is for overly casual cases. People just caring about their photos could use Flickr or just about any random photo service with a private setting.
Dropbox users are already a step or two further down the line, and there are files like password databases (keepass databases for instance), and other sensible things you'd want to synch seamlessly but wouldn't want to be accessible to anyone else, even with just a warrant [0]
[0] I think you still can refuse to give a password if I'm not wrong
Can't speak for the US, but in the UK and Australia at least it's a crime to withhold a password. Seems the US varies depending on jurisdiction. See http://en.wikipedia.org/wiki/Key_disclosure_law
I think I like this world.
It's not the presumption of innocence that's the problem, it's being forced to be a witness against yourself.
I agree use ability could be improved and I would really like getting more developers involved so we can finish a Windows port, iOS app, and a graphical interface to help make the whole system easier.
~ Ali
[1] http://dl.acm.org/ft_gateway.cfm?id=2522721&ftid=1403940&dwn...
I've also played with SparkleShare, which has been working well in my very limited testing. The downside is that it is written in .net which has a large footprint (pre-paid if you are in the Microsoft world). With SparkleShare, I'm using my own git repositories (gitolite) which works well but requires some hand editing of the configuration file to make it work.
Use something others have used and configured with documentation and all.
Take a look at distributed files systems. Those usually come with their own share of failure scenarios:
Some I know of are GlusterFS, Ceph (both made by Redhat I think) and Luster.
But as I said now you'll be in the business of understanding and configuring these. Especially how failures can happen.
See first if you can somehow improve the bandwidth between the sites, improve VPN settings, setting QoS flags. Separate networks.
Then take a look of FS-Cache/CacheFS.
http://en.wikipedia.org/wiki/CacheFS
It is a way to use local cache to improve _some_ access patterns. Specifically if you look here:
http://www.linux-mag.com/id/7378/
---
The goal of FS-Cache and CacheFS is to reduce network traffic because some of the data requests will be satisfied by local storage (CacheFS) reducing the amount of network traffic. The load on the server should also be reduced since it will not have to satisfy all data requests. Consequently, this reduction may make up for the increased file lookup time and file read time due to the cache.
---
A key for convenience, which DropBox delivers, is to fetch the data before you need it. 200GB is not that much in the grand scheme of things today - if you only have 1GB/day of changing data, it could be viable.
Interesting. Git is mentioned as well. I guess i have to read the paper after i finished cleaning the house ;)