211–220 of 429 posts
Earlier quoted context omitted.
None. 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.
But I (and I suspect quite a few other people) want a cloud backend to cover both the disaster-recovery cases and syncing while outside my LAN.
Earlier quoted context omitted.
I last used Dropbox in 2011 or so (I stopped using it because it killed my battery life). It may have gotten better since then. (But my point is addressed to what it takes to get popular, i.e. that its easier to make a “dumb” tool popular, and Dropbox was popular back then.) EDIT: Clearly not just me: https://news.ycombinator.com/item?id=12464901 (thread from 2016)
> i.e. that its easier to make a “dumb” tool popular, 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 connotatio…
For those interested in open source alternatives, syncthing, NextCloud (fork of ownCloud), and Seafile are some of the big names in this space, as others have mentioned. Personally I'm on syncthing. It's one of the best pieces of software I've ever used. My only complaint is it's not really instantaneous for me. In theory it works with inotify, but I've never quite been able to get it to work. I'm confident it will e…
I'd definitely throw Keybase in there as well. To me it has the easiest experience being cross platform, integrated with the filesystem, end-to-end encrypted, and having solved the identity proof piece.
It's not encrypted ext4, it's ecryptfs (which acts as a separate layer entirely, creating a virtual encrypted filesystem on top of ext4) - probably doesn't support some inotify feature or some extended attributes that aren't set correctly when used through ecryptfs. If instead you used dmcrypt and encrypted the whole device or partition you'd probably have no issue as it looks just like any other EXT4 FS to the syste…
Home directory encryption via ecryptfs is now the default in most Ubuntu variants, and it would be insane not to attempt to support it. That said, given that my Dropbox subscription just renewed (and that Linux is pretty much the only reason I'm still using it, since there is no OneDrive client I can rely on), I am really sad this seems to be a future direction for Dropbox.
Earlier quoted context omitted.
None. 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.
But I (and I suspect quite a few other people) want a cloud backend to cover both the disaster-recovery cases and syncing while outside my LAN.
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.
Earlier quoted context omitted.
On my "ideal" requirements list is the ability to sync, encrypted, to a standard cloud backend as well. https://github.com/syncthing/syncthing/issues/2647
Then use git-annex, which has had that for years :)
(Sure, "don't do that then", but I'd rather not have to remember to not do that)
Earlier quoted context omitted.
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…
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…
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."
Earlier quoted context omitted.
That statement is bit dubious. The next line also says: > A supported file system is required as Dropbox relies on extended attributes (X-attrs) to identify files in the Dropbox folder and keep them in sync. We will keep supporting only the most common file systems that support X-attrs, so we can ensure stability and a consistent experience. Certainly XFS supports xattr and hence ideally should be supported. I don't…
extN xattrs are fairly limited, because iirc all xattrs of a given inode must be stored in the same block. I don't think XFS has any serious limitations (count/size) for them, but the Linux kernel itself limits the size to 64K.
Earlier quoted context omitted.
Home directory encryption via ecryptfs is now the default in most Ubuntu variants, and it would be insane not to attempt to support it. That said, given that my Dropbox subscription just renewed (and that Linux is pretty much the only reason I'm still using it, since there is no OneDrive client I can rely on), I am really sad this seems to be a future direction for Dropbox.
I get a terabyte free with onedrive, because of the office subscription. I wish I had a good way to utilize it on Linux.
So, if other programs follow suit, will we start seeing options to lie about the filesystem type?