This is (yet another) "Dropbox replacement" project publicized in HN that grossly misunderstands what Dropbox is, why it's popular and is not a "replacement" in any meaningful way.

Here are just a few characteristics of Dropbox that this project doesn't have:

* cross-platform (windows, mac, linux)

* an easy to setup GUI client that is possible to setup by people who don't necessarily know how to enable inotify in linux kernel or copy autosync.py to location in $PATH

* won't fall over when a merge conflict happens (and a merge conflict will happen and even I, who uses git daily, would be unable to resolve it)

We are good at extrapolating and making connections but in this case extrapolating from "files, sync" to "my linux-only python script is a replacement of Dropbox" is about as valid as extrapolating from "wheels" to "my home made unicycle is a replacement of Toyota Prius".

At least he's making something. We should foster an atmosphere of encouragement, even if the idea seems silly. Who knows what it could grow into one day?

You might not have intended to be so mean-spirited. I know I've sounded that way in the past. What helped me was to offer some kind of suggestions for improvement along with whatever criticisms I was dishing out. (Rather than just pointing out all of the flaws.)

My suggestion for improvement would be:

"Don't advertise your project as a 'Dropbox Replacement' unless you actually are."

I think he advertised it as a 'Personal Dropbox Replacement' which suggests he probably just made it for himself and is releasing it to everyone if they wish to use it.

This project is open-source, has no domain name of it's own, no fancy video explaining how it works, no bullet-points explaining why people should dump Dropbox and start using his project, and the author doesn't seem intent on making money from it by advertising it as a 'personal Dropbox Replacement'. It's quite evident that only programmers are going to use this product, considering the dependencies and relative complexity of install procedure.

I don't see anything wrong with the way he has advertised his project as a 'Personal Dropbox Replacement'

Same as iPod/iPhone/iPad/Facebook/Twitter/email killer. You can call yourself the iPad killer after you've killed the iPad.

Criticism is a thing that's hard to do right.

If you're too kind, they think you aren't serious or are stupid, and they ignore it.

If you're too mean, people berate you for being mean.

Criticism is extremely valuable to a developer and they should be able to overlook any insults (intended or accidental) and absorb the mean of the criticism.

In this case, the criticism is that the project doesn't work as advertised. It is -not- a 'replacement for Dropbox'. You could probably stretch as far as 'Dropbox-like personal storage system using Git' or some such, but even mentioning Dropbox is iffy, since their whole model is user-friendliness.

These clones demonstrate why Dropbox is such a good idea imo. Good ideas are ones that make people think "that's easy, I could do that in a weekend!" Dropbox is great because it isn't just a really good idea, it's also a fantastic implementation.

The title alone says much about the simplicity of the product. "Dropbox" is more friendly and much easier to remember than the name of "DVCS-Autosync".

I looked through the source, and it doesn't seem to have any conflict resolution. As far as I can tell, it simply executes the push and pull commands without checking their exit codes to see if they succeeded.

Joey Hess just blogged[0] about ShareBox[1] which creates a fuse filesystem built on git-annex. I don't know either well enough to comment on them.

[0] http://kitenet.net/~joey/blog/entry/new_git-annex_use_cases/

[1] https://github.com/chmduquesne/sharebox

The dvcs-autosync author is also looking at making it use git-annex for large files.

What makes dropbox special is that I can access it on my home iMac, my work macbook, my linux netbook, my android phone, my iPad and the web interface when I feel so inclined. On top of that, I select different directories to sync on each machine and often share file between friends and colleagues.

An uber simple interface that supported on every major platform is what makes it so awesome.

Won't the space taken up by revisions monotonically increase? Deleting files won't free up the space, since the old revision is still tracked.

Dealing with gigabytes of files & revisions isn't git's forte.

You are right. It might increase very slowly if you actually store a source repository composed of many small files and then only some of them change periodically. But if you store large binary blobs and all of them change often then git won't work that well.

You'd at least want to have the option to blow away some history as you run out of space or become confident that you'll never need it -- can't do that in git without re-writting the whole commit history from scratch and filtering out some commits.

In think in this case there is some confusion between backup and synchronization, both can be thought of as separate and git might not do well for either one in the general case. It might not be as good for backup, because you might want to blow away old snapshots and in case of synchronization. As for general bidirectional synchronization, you'd need some way to plugin in custom merge conflict resolution (can git do that?). For example you might have a policy that whenever you modify a file on the your laptop it should take precendence over the same file modified on your iphone, or some text files can handle merging while others should be replaced based on timestamp, or something like that.

> But if you store large binary blobs and all of them change often then git won't work that well.

True, default git won't work well. But you can handle large changing files git-style with a different approach; the bup backup system using git comes to mind (see https://github.com/apenwarr/bup & http://lwn.net/Articles/380983/) where what is stored are chunks of files, where xdelta and other diffs work efficiently.

It's funny - I was reading up on Camlistore yesterday, and realize that what it proposes to do very much resembles Dropbox (and - to a certain degree, Git).

Have you considered making a personal Dropbox replacement using it? I hear Brad Fitzpatrick is writing it as his Dropbox replacement.

(Also: competition is bi-directional - it's interesting to take a look at Camlistore's suggested usecases http://camlistore.org/docs/uses and think that Dropbox can do the same ...)

What do you think about this is better than AeroFS (http://www.aerofs.com/, previous discussion at http://news.ycombinator.com/item?id=1538731)?

One thing that's better is that it's available now. I can't use aerofs. It's a closed beta.

I can get you an invite if you like. I got my code shortly after asking for one.

I'd love to get an invite aeontech :D

send me an email at my username@gmail

Seems like a similar approach as SparkleShare [1], albeit less/not focused on UI (and using XMPP for notifications to update the repository).

1: http://www.sparkleshare.org/

I would have thought the personal replacement for Dropbox is just rsync. I guess it depends if you want / need full history. But personally I never use the history features of Dropbox.

rsync isn't bidirectional (see unison: http://www.cis.upenn.edu/~bcpierce/unison/), but it can be hacked on to make it store snapshots (see http://www.mikerubel.org/computers/rsync_snapshots/, but it's a full volume snapshot, not a per-file versioned history).

Unison is a good bi-directional syncing utility: http://www.cis.upenn.edu/~bcpierce/unison/

Unison is great, I use it as a way to keep several machines in sync for large content (several gigs) using a personal server as hub.

http://gitorious.org/mist

It's not a dropbox replacement, but it does the syncing job nice and simple with nothing else but unison, ssh and a shell script. I will eventually make a daemon using inotify so that it can sync in the background as well.

Appreciate the reminder re: unison. Just made my desktop <-> laptop syncs. a whole lot easier.

History will save your ass at some point in the future. I'd bet money on it.

This looks promising: https://github.com/philcryer/lipsync#readme

Rsync doesn't work offline. Trying to send updates only would fail for differing timeclocks & deleted files.

Using a git backend for this kind of service is great since it would provide a common synchronization engine for all your files. Thus if I have 3 or 4 of these services pointing at the same folder everything should work.

What I love about this is that the project uses XMPP for server-to-server communication! Someone had poo-poo'd that idea in a previous post, but I think it has tremendous merit.

or just GitHub with private repos. then you can control exactly how and when the synchs across various clients occur. less moving parts too.

git doesn't really expose a great UI for this model of behavior. This needs a good UI for many things, for example, looking through history and cherry-picking old versions of files to revert to.

Also, it doesn't give you access from public computers the way dropbox does. You'd want a non-bare repository with gitweb or an apache directory listing, at the least.

There are a couple of FUSE modules that implement a filesystem based on a bare git repo.