What Dropbox Dropping Linux Support Says (techrepublic.com)

Jack Wallen, writing for TechRepublic: For a company to support Linux, they have to consider supporting: Multiple file systems, multiple distributions, multiple desktops, multiple init systems, multiple kernels. If you're an open source developer, focusing on a single distribution, that's not a problem. If you're a company that produces a product (and you stake your living on that product), those multiple points of entry do become a problem. Let's consider Adobe (and Photoshop). If Adobe wanted to port their industry-leading product to Linux, how do they do that? Do they spend the time developing support for ext4, btrfs, Ubuntu, Fedora, GNOME, Mate, KDE, systemd? You see how that might look from the eyes of any given company?

It becomes even more complicated when companies consider how accustomed to the idea of "free" (as in beer) Linux users are. Although I am very willing to pay for software on Linux, it's a rare occasion that I do (mostly because I haven't found a piece of must-have software that has an associated cost). Few companies will support the Linux desktop when the act of supporting means putting that much time and effort into a product that a large cross-section of users might wind up unwilling to pay the price of admission. That's not to say every Linux user is unwilling to shell out the cost for a piece of software. But many won't.

Comments

Why is the FS a problem?

[Tomahawk]

Surely the OS is providing standard access to every FS, so from an application perspective everything looks the same. So why is it a problem for applications to support ext4 and btrfs when, via the OS, they should look the same?

fopen() will still work, regardless, surely... no?

Re:Why is the FS a problem?

[marcelus]

I think that lower-level calls may be necessary to ensure a seamless performance. I don't know for Linux (where file locking rules are different), but as a Windows Dropbox user, I find it *very* nice that I can work on big Photoshop files, save them often and *never* have Dropbox get in the way by locking the file (and, furthermore, Dropbox only uploads or downloads chunks of the file that have changed) Google Drive, on the other hand, is a PITA when it comes to this: I was using it before and saving files often resulted in Photoshop complaining... a lot! (Google Drive is OK for backups or very small files, though) It might be that the naive approach of using posix-level calls is not really enough Just my $0.02

Re:Why is the FS a problem?

[BigBlockMopar]

That exposes a basic misunderstanding of how software in Linux is built. The program which presents a remote filesystem should be separate from the program which synchronizes files. That's the unix way.

It also makes Dropbox's job simple: a fuse (filesystem in userspace) driver and then let folks stack whatever other Linux software they want to on top of it.

Yeah, I was confused about that argument about fractured filesystems (among other things) in the original post. How and why does that matter to them, unless they're doing something at a lower level than userspace?

Yes, I agree, the Linux community is horribly fractured and must be a big nightmare for some applications to be ported. But if it's available for anything Apple, or anything Android, porting it to Linux should be relatively easy.

From article:

Although I am very willing to pay for software on Linux, it's a rare occasion that I do (mostly because I haven't found a piece of must-have software that has an associated cost).

Mostly because we're accustomed to having enterprise-grade software free. Linux users aren't cheapskates, and consider that ALL the computers in the TOP500 list are running Linux. Linux users can shell out money.

I'd be a lot more receptive to AutoCAD, for example, if they put out a Linux version. But why bother? There's FreeCAD and a host of others. Photoshop? GIMP. And let's not even get going on Blender.

Dropbox - isn't it, really in the end, just rsync being run within a script? I liked the name for the credibility, but again, Linux has credibility in its own right.

Re:Why is the FS a problem?

[Wrath0fb0b]

Surely the OS is providing standard access to every FS

They are trying, and largely succeeding. Nevertheless, all non-trivial (and filesystems are highly nontrivial) abstractions are leaky

fopen() will still work, regardless, surely... no?

A service that offers background sync (i.e. changes are pushed to the cloud in the background) which doesn't just poll (polling is evil) needs an API much more complicated that fopen. Specifically, it needs a notification stream where it can create a 'watched' folder and be notified when:

• A file in the watch was opened for writing was closed
• A new file or directory entry was created
• A file or directory was deleted
• A file or directory was moved, either from outside the watch to inside, inside to outside or inside to inside. Note that this is essential to allow users to rename or reorganize their folders without retransmitting the entire file each time
• Probably more I'm not thinking of . . .

This is a (somewhat) solved problem, in the sense that inotify exists within some limitations described on the wikipedia page (and further in the man page). One really obvious limitation is that the kernel will not do this recursively for you, meaning that the client has to manually add/remove folder watches. The other is that rename events are clunky, coming in two halves with a linking identify. Anyway, if you read the history, you'll note this is the third or so attempt at getting this right, which at least suggests that it's non-trivial enough that we had to can the original (dnotify) interface and start over once.

What was the point of this side-track into filesystem watching? Well, for one, we started with "how hard is fopen/fread" and now ended up with "holy crap, that's highly non-trivial to be async notified of changes within a directory tree (recursively!)". It also raises the question of whether the interface really is an airtight abstraction, or whether filesystem implementation details leak into the caller to be dealt with. Even answering that question for all supported Linux filesystems is non-trivial.

If you take nothing else away, just remember that this is a far more complicated problem than rsync ;-)

Postscript: rsync is 50K LOC

Re: Why is the FS a problem?

[GameboyRMH]

These are rare corner cases though, and not really a problem with rsync or the filesystem. By default rsync compares datestamps to check for changes and will skip over files where the datestamps match. Sometimes a file will be altered but its datestamp won't - the only situation I'm aware of like this is Linux filesystem container binary files. In my rsync scripts I have to touch each of them first if I want them to be seen as updated. Somewhat more commonly there are a few programs that will update the Modified datestamp on files they open even if they've only been read and not changed.

I blame the way these programs handle datestamps. Linux/mount should update the datestamps of filesystem container files when they're written to, and programs shouldn't update the datestamps of files that are not changed.

Are you retarded?

[dnaumov]

Why would an image editing program give 2 shits about: ext4, btrfs, GNOME, Mate, KDE and systemd?

Re:This old FUD?

[SharpFang]

Dropbox made some really dumb design decisions early on, tying the program way deeper into the OS works than it really needed, and suddenly they discovered that if you dig all the way through the one uniform friendly abstraction layer meant to be used by everyone and sufficient to everyone, you suddenly discover there are many different variants of works down below, of things you weren't supposed to touch in the first place. And they change a lot, and are hard to use.

And now they try to pin the blame on someone else.