Then I saw that it's not available on Linux. Which is really surprising, since supporting arbitrary filesystems is IMO dead-easy on Linux, and the easiest of the three desktop OSes. And since our company uses only Linux workstations (except for the designers), this is immediately unavailable to us. This is disheartening.
This is low level enough that it'd have to be implemented as a FUSE layer, which could add quite a bit of complexity. I wonder how they're going to deal with Linux. Will it still just sync everything?
And then they could have used the same codebase for Windows with Dokan (which has FUSE compatibility) and OSXFuse, although those two aren't installed by default. (FUSE is).
The mere use of FUSE doesn't make an fs complicated or things "severe". It's just a really simple API made available to userspace processes. In fact, you can build an fs in FUSE that does overlaying itself, using multiple, isolated processes. Or you can use a single, simple, small process to implement a simple fs. FUSE is literally just the glue that would allow something like dropboxd to send/recieve file info/data to/from the VFS.
So if Dropbox doesn't keep supporting Linux, I'll drop them like they are a hot potato. I do hope they won't make that mistake, because their continued Linux support has been the main sign that they care about me, their customer. And I don't want half-baked support either. I want it to be a first class citizen. Because I'm paying 14 EUR per month for my Dropbox account, amounting to 168 EURs per year, which isn't cheap at all. Yeah, yeah, it's the price of 5 coffees, but if I'd pay that price for everything I use, I'd be broke.
> Electron and nw.js
These would take care just for the UI, which for the purpose of doing file synchronization amounts next to nothing.
Plus, when it comes to data/file sync tools like Dropboox, we need interoperability with existing tools: File Managers, filesystems etc. Not GUIs. Electron et al. are good for cross-platform GUIs, not CLIs or daemons.