# Why would your project be hard for someone else to duplicate?
This idea requires executing well in several somewhat orthogonal directions, and missteps in any torpedo the entire product.
For example, there's an academic/theoretical component: designing the protocol and app to behave consistently/recoverably when any power or ethernet cord in the chain could pop out at any time. There's a gross Win32 integration piece (ditto for a Mac port). There's a mostly Linux/Unix-oriented operations/sysadmin and scalability piece. Then there's the web design and UX piece to make things simple and sexy. Most of these hats are pretty different, and if executing in all these directions was easy, a good product/service would already exist.
I'd find it hard to believe that there isn't some very tricky stuff being done in the clients which gives them a big competitive advantage over competitors that pop up.
well, be careful with such claims. many technologies don't seem novel at first glance, but i'm sure there are lots of novel tricks they play under-the-hood to get their system to run quickly and reliably.
e.g., google's pagerank is now well-known and public, but i'm sure that they have lots of 'secret sauce' internal algorithms to make their search index work even better, and they definitely don't want to share those secrets
1. Would increase adoption on Linux clients 2. Increased security (the whole security though obscurity doesn't work thing)
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.
This is not my impression at all. Basically everybody I know uses dropbox, and very few of them are geeks. I was actually introduced to Dropbox by a non-geek boss I had who thought it was the greatest thing she'd ever used and insisted I also get it so we could share files.
Dropbox seems to have done a very good job of penetrating the general market, thanks in no small part to their pretty amazing and minimal UI. It's at the point now where I hear 'normal' people saying things like "can you share it to my dropbox" with the automatic assumption that the other person will know what it means.
It's a combination of having to understand app-filesystem interactions as well as user expectations, both of which are largely undocumented and unspoken -- but if you mess with either in the slightest way, somebody will freak out.
Shoot me if this is how the web is heading. (Recent browsing suggests maybe it is...) We get not only the insufferable "bottom bar" (is there a standard name for those yet?), but also a "top bar", a hover "Click Here to Share" box and a pop-up "Learn More, Instantly" box (not to mention the general clutter and overdense design).
Man, that's foul.
# Web toolbars/widgets
127.0.0.1 wibiya.com
127.0.0.1 cdn.wibiya.com
127.0.0.1 apture.com
127.0.0.1 www.apture.com
127.0.0.1 cim.meebo.com
I can get at the content there with no trouble, and don't have to worry about any of those toolbars.
Just added these to the "Adblock Plus" Preferences in Firefox (under Tools).
Worked like a charm.
"Foul" is not a strong enough word for that. Maybe "vile" is better?
A good rule of thumb I have is that if you "have to put a bag over the head" of something in order to make that thing pleasant to digest or access (whether it's a UI or a bureaucracy or paperwork or a person or physical widget or whatever), then really the source thing itself should be designed that way in the first place. In this case, my own ideal style of web design is very close to what Readability/Reader produces. Thus making it redundant to the extent I've achieved my ideal.
EDIT:
I just realized that Chrome devs have apparently already decided that it's not worth fighting the idiotic bars, so Chrome scrolls less than one page.
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., you could get data loss using this mechanism alone. you need to also run rsync every so often, i think.
the lsyncd guys are aware of this: http://code.google.com/p/lsyncd/
(maybe this is how dropbox works under linux too, if so it presumably has the same problem..)
As is often the case, you learn a lot about a company through its jobs page. Their latest challenge for applicants looks very much like this problem.
Does anyone else handle this in a different way?
If you're using Dropbox to back up some of these other solutions might make more sense. Crafting up a script using hard links and rsync can give you daily snapshots of any filesystem at only the storage cost of the delta (which can be easily turned into a cron job) .. here's a decent resource for that:
I think if you try to use this like a real dropbox, ie changes occurring on multiple hosts at or around the same time you are going to run in to issues. Also does lysnc handle deleting data on the remote end and propagting those changes out (rsync --del). Also I'm wondering how it will handle conflicts and open files (which it says isn't recommended). I see the .dropbox dir using some type of uuid's or sha1 sigs so I'm sure its doing something more sophisticated to keep things in sync. I've noticed my daemon has died on my linux box every once in a while, and it somehow tracks multiple changes from multiple hosts and replays those transactions correctly and everything rolls up fine.