[laumars]

FTP is neither sophisticated nor a network file system. Frankly I'd take Dropbox over FTP any day of the week - FTP needs to die.

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.

[rayiner]

I’m not talking about FTP, which isn’t a network file system. I’m talking about NFS, AFS, and sucessors in that line of development. E.g. https://www.slideshare.net/mobile/snehcp/coda-file-system.

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

[laumars]

In that case it might have been helpful if you stated that you were shifting the context away from FTP; as was the context in the GPs comment. ;)

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.

[LambdaComplex]

>you'd then need to tunnel your connection (eg via SSH or VPN)

Well, there is an sshfs FUSE filesystem, for what it's worth

[Fnoord]

Which works on Windows via Dokan [1]

[1] https://github.com/dokan-dev/dokan-sshfs

[laumars]

Yup, mentioned that in my previous post. Awesome project. I remember the first time I discovered it - I felt like a caveman who'd just discovered fire.

[batbomb]

AFS works fine over a WAN. Sometimes a little slow on metadata operations.

[pjc50]

Network file systems are harder than they sound, and writing additional file systems for Windows is a huge pain. Even Microsoft's own solution - OneDrive - they've had to walk back slightly on their "placeholder" implementation for detached operation, which was great when it worked but occasionally managed to blow up badly.

[asdkhadsj]

> Which is why we’re all using an internet powered by Javascript, Electron apps on the desktop, etc. Worse is better.

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.

[jwhitlark]

As my brother likes to say, "good enough is, otherwise they wouldn't call it that."

[MisterTea]

I think you mixed up worse is better. The idea behind the phrase is that quality does not increase with functionality. Functionality often means features along with bells and whistles. Sure that application looks pretty and offers tons of features but with that complexity and glut comes a steeper learning curve as well as possible security and stability issues in the code (more bugs).

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."

[rayiner]

I'm talking about these two points from the paper, regarding the "Worse is Better" philosophy:

> 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.

[raverbashing]

NFS is probably the most unreliable network file system that is still in use.

Even SMB is better

[scott00]

Dropbox may come through for you in the end. They've got a feature called "Smart Sync" that is a network file system implemented as a kernel driver. See https://www.dropbox.com/smartsync and https://www.dropbox.com/help/desktop-web/filesystem-integrat.... Not sure if it's doing block level diff or not though.