Build An Opensource Dropbox Clone • Hacker News Board

Re: Build An Opensource Dropbox Clone

#11

Post by michaelbuckbee » Wed, Sep 01, 2010, 6:06 PM UTC

edanm wrote: post #9

xxpor wrote: post #8

Earlier quoted context omitted.

2 things that I can think of immediately 1. Would increase adoption on Linux clients 2. Increased security (the whole security though obscurity doesn't work thing)

Well, I don't think the Linux market is big enough to make it a compelling argument (but I really don't know; I could be dead wrong). As for security, I'm not sure how big a problem Dropbox has with security. And I would't open-source a client just to get better security for it, but maybe that's just me. Open sourcing the client is betting on the fact that the client doesn't matter. Maybe it doesn't matter, but maybe…

Linux as a desktop client is potentially too small a market to address, I'm not sure the same could be said about the Linux server market.

Re: Build An Opensource Dropbox Clone

#12

Post by beza1e1 » Wed, Sep 01, 2010, 6:06 PM UTC

dododo wrote: post #4

lsyncd does the brunt of the work. it uses inotify, which is a facility of the linux kernel, to tell which files should be copied. but i think there is a problem. inotify is not guaranteed to see every file system access. in fact, it often misses them when the file system is busy because there is an upper bound upon the number of inotify events that can be queued, set in /proc/sys/fs/inotify/max_queued_events. i.e.,…

Well, Ubuntu One seems to rely on checking every so often alone ...

Re: Build An Opensource Dropbox Clone

#13

Post by fluidcruft » Wed, Sep 01, 2010, 6:10 PM UTC

please wrote: post #10

except that it misses 90% of what dropbox does. like multi client sync, cross platform, shared folders, web interface and so on

except that it covers 99% of what I actually use dropbox for.

Re: Build An Opensource Dropbox Clone

#14

Post by edanm » Wed, Sep 01, 2010, 6:20 PM UTC

michaelbuckbee wrote: post #11

edanm wrote: post #9

Earlier quoted context omitted.

Well, I don't think the Linux market is big enough to make it a compelling argument (but I really don't know; I could be dead wrong). As for security, I'm not sure how big a problem Dropbox has with security. And I would't open-source a client just to get better security for it, but maybe that's just me. Open sourcing the client is betting on the fact that the client doesn't matter. Maybe it doesn't matter, but maybe…

Linux as a desktop client is potentially too small a market to address, I'm not sure the same could be said about the Linux server market.

Good point, I hadn't thought of that.

Are people using Dropbox on servers, though? A lot of the benefits of Dropbox don't strike me as helping for servers, for the most part. I don't have too much experience, but it seems to me servers are one place you have to actively manage your backups, and can't rely on the "it just works" philosophy of Dropbox.

Re: Build An Opensource Dropbox Clone

#15

Post by patrickaljord » Wed, Sep 01, 2010, 6:37 PM UTC

tommynazareth wrote: post #3

I don't plan on ditching Dropbox, but I'm definitely interested in having a similar sort of automatic backup with diffs that I can host myself. This looks like it might be an option. Does anyone else handle this in a different way?

I just use http://rdiff-backup.nongnu.org/

Re: Build An Opensource Dropbox Clone

#16

Post by gvb » Wed, Sep 01, 2010, 6:55 PM UTC

tommynazareth wrote: post #3

I don't plan on ditching Dropbox, but I'm definitely interested in having a similar sort of automatic backup with diffs that I can host myself. This looks like it might be an option. Does anyone else handle this in a different way?

I use rsnapshot (also built on top of rsync/ssh) http://www.rsnapshot.org

Re: Build An Opensource Dropbox Clone

#17

Post by gvb » Wed, Sep 01, 2010, 7:00 PM UTC

What about using unison http://www.cis.upenn.edu/~bcpierce/unison/ instead of lsyncd? It seems like it would be more resilient. It does look like unison would require a cron job or human trigger where lsyncd is triggered by a file/directory change. On the plus side, it seems like unison would work better in an offline mode.

Re: Build An Opensource Dropbox Clone

#18

Post by noja » Wed, Sep 01, 2010, 7:00 PM UTC

dododo wrote: post #4

lsyncd does the brunt of the work. it uses inotify, which is a facility of the linux kernel, to tell which files should be copied. but i think there is a problem. inotify is not guaranteed to see every file system access. in fact, it often misses them when the file system is busy because there is an upper bound upon the number of inotify events that can be queued, set in /proc/sys/fs/inotify/max_queued_events. i.e.,…

Any files not moved elsewhere within X seconds can be handled by a cleanup daemon.

Re: Build An Opensource Dropbox Clone

#19

Post by tofumatt » Wed, Sep 01, 2010, 7:01 PM UTC

xxpor wrote: post #5

I don't understand why dropbox doesn't open source their client. Their business isn't built off of their technology, which, while nice, isn't exactly novel. They make their money from selling storage. Open sourcing their client doesn't change the fundamental fact people need the space to store stuff.

Open sourcing the client could mean I run it off my own server, sitting in my apartment, for free. Granted, mostly geeks would be doing that, but I get the impression that many of Dropbox's user base _are_ geeks.

Like someone else said: it's not just whether or not it would HURT Dropbox (though, as I've said, I'd argue it could), but whether or not open-sourcing their clients would actually HELP them. I doubt it would.

Re: Build An Opensource Dropbox Clone

#20

Post by SwellJoe » Wed, Sep 01, 2010, 7:16 PM UTC

edanm wrote: post #14

michaelbuckbee wrote: post #11

Earlier quoted context omitted.

Linux as a desktop client is potentially too small a market to address, I'm not sure the same could be said about the Linux server market.

Good point, I hadn't thought of that. Are people using Dropbox on servers, though? A lot of the benefits of Dropbox don't strike me as helping for servers, for the most part. I don't have too much experience, but it seems to me servers are one place you have to actively manage your backups, and can't rely on the "it just works" philosophy of Dropbox.

I think I'm more likely to pay for a service like Dropbox on the server than on my desktop.

Reliable backups are a big deal on a server, and maybe not as much on the desktop. I mean, I'm not too fussed if my mp3 collection gets stomped by a hard disk failure (I just download it again from emusic), but if tens of thousands of forum and ticket tracker posts are lost, I'm gonna be devastated. And, having it in a shared location that makes it easy to copy the database and website to a development machine might be cool. (I'm kinda talking abstractly here, as my own products provide tools to solve all of these problems in different ways, but they're things I've had problems with in the past. And, if Dropbox had a server product, we'd probably add it as a backup target option.)