No problem, you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem.
Thankfully your options are not limited to either Dropbox or FTP. Thus people who want simplicity can have Dropbox (or similar) and people who want control can have sshfs or any number of other tools out there that require some assembly but also don't suffer from the numerous problems that pre-TCP/IP protocols like FTP suffer from.
I’m literally talking about the theory of the paper by Richard Gabriel (https://www.dreamsongs.com/RiseOfWorseIsBetter.html) which is that worse solutions often win because it takes too much time to bring a good solution to market.
If you were trying to make a “good” solution to the problem addressed by Drop Box, it probably would not look like Drop Box. For example, you’d do a real network file system that wouldn’t need to do a binary diff of the file each time to see what changed, because it would have access to the block level changes at the file system layer.[1] You'd have file locking in the protocol (like CFS), and could sync data from a locked file instead of waiting for the lock to be released.[1]
It also probably wouldn’t have made Houston a billionaire because who is going to install a kernel driver off the internet? But on the flip side, Dropbox almost certainly killed much of the interest in real network file systems, because it is good enough.
Which is why we’re all using an internet powered by Javascript, Electron apps on the desktop, etc. Worse is better.
[1] https://www.dropbox.com/help/syncing-uploads/upload-entire-f...
[2] https://www.dropbox.com/help/syncing-uploads/stuck-syncing
NFS and AFS (from what limited I know of it) are more designed for local networks thus to leverage NFS over a WAN you'd then need to tunnel your connection (eg via SSH or VPN). So while there is obviously overlap between them and Dropbox I wouldn't really say the two are all that comparable.
However to answer your point, I don't think anyone would disagree with the specific part of your point regarding how simplicity is often better than something arguably more powerful. However just because something is simple it doesn't mean it isn't also good. "Good" is just a question of whether it meets requirements. If your requirement is that it can be installed and operated by layman then Dropbox is a far better solution than any other the other proposals you've mentioned.
Well, there is an sshfs FUSE filesystem, for what it's worth
That's being a bit alarmist, isn't it? It's not worse is better. It's the right amount of compromises is better. Or, "good enough is better".
Perfection usually has diminishing returns and is rarely obtainable. Worse is not better. Good enough is better; objectively so.
A good comparison would be comparing using make files and a simple text editor like vim to visual studio. Is visual studio truly better because it offers more features when a make file and vim can do much the same? A programmer used to VS might call the make file method worse, but the reality is that it is the simpler path which makes it better. Realize that simple doesn't mean "simple to use" but simple in terms of complexity (philosophical simplicity is at play here).
Worse is better is better translated as "A simple design is better, but not from the users perspective."
> Simplicity -- the design must be simple, both in implementation and interface. It is more important for the implementation to be simple than the interface. Simplicity is the most important consideration in a design.
> Correctness -- the design must be correct in all observable aspects. It is slightly better to be simple than correct.
Dropbox is simple in implementation, at the cost of simplicity in the interface and correctness. E.g. it is simpler to simply punt on locked files in Windows. Tell the user to quit Word if they want their file to sync, instead of handling file locking at the protocol level. Likewise, it's simpler to detect changed files after the fact than write a filesystem driver to knows what blocks are changed. But it degrades the user experience (their computer burns clock cycles re-figuring-out information a real filesystem driver would've had).
The upside of all that is that Dropbox was simple to implement, simple to port, and simple to deploy, which made it popular:
> Therefore, the worse-is-better software first will gain acceptance, second will condition its users to expect less, and third will be improved to a point that is almost the right thing.
Even SMB is better
How many files do you have? I've got 26000 files in my Mac's dropbox folder. (Granted, very few of them change more than once or twice a day; maybe 20 or so of those do.)
IIRC, there was a variable, hard limit for objects in a folder or locks in a folder where it would go wacky.
Docker (3.13) Dropbox (2.08) Outlook (2.03) Safari (2.02) Slack (1.57)
Total 131771 files currently on disk (I'm using Selective Sync, because SSD prices)
EDIT: Clearly not just me: https://news.ycombinator.com/item?id=12464901 (thread from 2016)
If this was your intent, then using the tired "worse is better" trope and claiming an issue from 7 years ago, that no one else has claimed to have seen is seems a far cry from it.
Dropbox became popular because it was easy, it worked, and did exactly what it said it did. That might be "dumb" in that it's not feature packed, but you use a lot of negative connotations when none are required.
This has aged gloriously, thank you!
This idea that we're always making sale predictions is a vice of the startup culture.
The 3G was the breakthrough model, but I lend that as much to the dock connector (which was available in USB and FireWire) and the growth of x-platform iTunes as anything.
The broader point that it required Windows support for the iPod to become mainstream is of course true. That said, the iPod was also the reason so many of us became Mac users in the early 00s because the “halo effect” was undeniable.
Slack has the better part of a billion dollars in funding for what's essentially resource-hungry IRC with pictures. Dropbox does little you couldn't accomplish with a server and rsync.
What I'm really eager to see is git for everyone else.
When you simplify and generalize git to the point where "everyone else" can use it, you get Apple's Time Machine and Windows' File History. I'm not that familiar with Time Machine, but if File History had a more visible interface that you could use to easily "checkpoint" individual documents or directories on demand, you'd pretty much be there.
Branching is too complicated for most people to work with and overkill for most scenarios.
Most cloud storage providers offer rudimentary versioning; are you referring to the idea of promoting commits to being first-class? It would need to be baked into Word, Excel and similar, and those tools already have builtin version tracking, as horrible(?) as it is, so... :/
Of course, a solution that works well with all the different binary file formats people in those fields use wouldn't be easy.
It would definitely need to work with large files though, which categorically precludes Git.
The first point, I think, would be building a delta engine with case-specific code for the most common ubiquitous file formats, like docx, xlsx, psd, etc. Of course it wouldn't be able to be perfect with everything but it would certainly be better than eg just recompressing each version or something equally naive.
The UX would be the next major hurdle. Time Machine is a good example of the kind of simplicity that would be needed, but it would need to be a have a bit more surface area to be applicable and useful to all scenarios.
One other feature that comes to mind, which would be incredibly difficult to get right but probably critical, would be useful version diffing. I think keeping this simple and just building something that can do $anything->SVG (with maybe cheats where bunches of the SVG is mostly just a bitmap in certain cases) and then doing something fast on the SVG (and/or its bitmap contents...) would probably be the most viable target.
No doubt there would be a learning curve. I think that's OK. The target market here is serious users who already dedicate time to learning professional tools like Photoshop.
:(
That would take years to get anywhere with ._.
The diffing idea I suggested above is just manageable, a la macOS Preview, with hacks. Branching requires folding-back-in, and that's not just a case of "A or B", it's a case of "A, B and C conflict with D and E, while F G and H are okay," where I could then say "save B and E but drop F". If B is a layer, E is an imported asset and F is a custom filter... you get the picture. You need a reimplementation of Photoshop (halting problem).
:/
Sad that everyone hates GIMP.
But... hmm, this could get folded into Blender, and then make the rest of the industry jealous.......
Also, to get more ideas:
echo "Make a startup with "$(ls /bin /usr/bin | sort -R | head -n 3)I intermittently maintain a list of these things at https://github.com/pjc50/pjc50.github.io/blob/master/secure-... ; none of them have ever been precisely what I wanted. The cheap alternative to Dropbox with Linux support you want was "Hubic" from OVH (edit: now discontinued)
Not meant critically, I love that they exist and found funding. It's just, as long as the model is "once the privacy shit hits the fan in some widely published scandal, we'll be the one that's ahead" there's only two outcomes: 1. It doesn't happen soon enough and Keybase runs out of runway, or 2. It happens, one of the many Keybase products becomes wildly popular because of it, and Keybase will ditch the others because "yada yada focus core business".
"These folders are encrypted using only your device-specific keys and mine.
The Keybase servers do not have private keys that can read this data. Nor can they inject any public keys into this process, to trick you into encrypting for extra parties. Your and my key additions and removals are signed by us into a public merkle tree, which in turn is hashed into the Bitcoin block chain to prevent a forking attack. Here's a screenshot of my 7 device keys and 9 public identities, and how they're all related."
Hubic has been discontinued recently as a non-core business to OVH[1].
Although it's arguably a more intelligent decission to share private files not with a company like dropbox.
You sync across your devices (or anything where you can run a standalone binary). Phone, PC, server, whatever. It's pretty good and very stable when your packager doesn't fuck up the service file (https://svnweb.freebsd.org/ports/head/net/syncthing/files/sy...).
> without the need to set up configure your home nas
That's only needed if you need access to your files from the outside world (which is probably a bad idea). For instance, my ~/Documents are syncthing-only, not available through my Nextcloud instance. Can't access my payslip from last year on my phone. Can't have it stolen through that channel either!
(Sure, "don't do that then", but I'd rather not have to remember to not do that)
I set my grandmother up with Synctrayzor and she doesn't know the difference between that and Dropbox.
It is missing the ability to share things with a direct link, or share a repository or folder "easily" (read: in the same way it's done with Dropbox), but the trade off has been worth it for me.
My instinctive reaction is not to trust any brand new effort without more evidence of its correctness.
Where can I find more information on this? Search is failing me.
You run it on your machines and they will sync among themselves. No need for any cloud backend.
Some people with Synology or QNAP run an instance on their NAS.
2) you can run your own off-site instance, that can be hosted with your favourite cloud provider.
How much would it cost to hire an admin to set up and maintain that instance?
The whole point of Dropbox is that I don't have to do any work.
For example, if you have Synology or QNAP, there are packages to sync with cloud providers, like Backblaze B2, Amazon S3, Azure Cloud Storage, etc. So if one of your syncthing sync instances (which you can make with few clicks) is such a device, with few more clicks you can choose your cloud platform and backup to that.
Or you can be using something entirely different. That's the beauty, you can use whatever fits your needs and budget, you don't have to fit yourself to limitations of one or two pre-packaged solutions. You can do something entirely different, e.g. if someone from your family also has some NAS, you can backup to each others devices and not rely on third parties at all. The possibilities are limitless.
Individuals don't, but most individuals have no clue about the repercussions of hosting their plaintext data on Dropbox in the USA. Its a ticking timebomb.
For every human being on the planet needs their own privacy. Its a common theme in the EU, but it isn't only important within the EU.
Therefore, there are two viable options:
1) You store your data locally (encrypted if you want to protect against burglars).
2) You store your data remotely, but encrypt it before you send it and decrypt it after you receive it (public key cryptography).
There is no other, viable, long-term option. Dropbox's solution is a short term solution.
Now, the question is whether you really need to sync to your LAN right away. You most likely don't. You can just sync in the evening and at night while your device(s) recharge. If you really need to sync ad hoc you have the option to punch holes in your firewall, or use a VPN. One opportunity for innovation here is to allow a user to define what must be synced right away over WAN and what shouldn't. Another opportunity is to make cloud backups easier. But these require the above requirement #2, and as you might know, public key cryptography just doesn't seem to be user-friendly.
Speaking of which, you can use such together with Cryptomator or GPG or whatever and synchronize your encrypted files. To any cloud. Or you can sync it to your NAS which stores them on an encrypted filesystem.
You can do that with Dropbox/Google Drive/etc as well. But I'd use that as yet another encrypted backup of my most important NAS content.
It is not like they are not implementing a feature but removing one.
And famously so.