Slashdot Mirror
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.
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.
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?
Why would an image editing program give 2 shits about: ext4, btrfs, GNOME, Mate, KDE and systemd?
Actually some application might want to run user services too, that could apply to PS too. Currently systemd is the only distribution independent provider of some apis that are needed by modern applications. So it not only doesn't create more fragmentation but in fact lets applications have some features that were on all OSes except Linux before.
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.
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
The problem isn't the file system. It isn't multiple desktops. It isn't the fact that Linux users feel entitled to free (as in beer) stuff. It's the education level of Linux users.
As much as Linux has tried to make inroads with the common joe, the general Linux user still displays a higher level of computer competence than other platforms. Which means they are less likely to put up with Dropbox's shenanigans when they do stupid things to make you pay.
Example: Bob has used 1.5 out of his 2gb of free space. Alice, his sister, shares a folder of family history photos and documents. Bob subscribes, but finds out suddenly he has exceeded his free space. Dropbox says, delete, or pay you freeloader.
Now, inexperienced users, they are more inclined to shell out. They may not know how silly this is, or they may not want to bother climbing the learning curve enough to try and find an alternative. Or some combination of the two. Linux users, on the other hand, say hey, wait a minute. How are you justifying "charging" the entire size of a shared folder to the size limit of every recipient?!? I know what a soft link is, and that's not the way that works. I'm not paying for this shit. Moreover, most Linux users are smart enough to make moving to an alternative like Syncthing a prospect that's not so daunting.
Dropbox should have adjusted its method of enticing users to pay. Like charging for something that's actually value added. Depending on the laziness and/or inexperience of users to maintain your business model isn't sustainable. Cutting off the smart users, and then telling them its their fault and calling them entitled freeloaders, that's not good business. Because for those people, the recommendations they then make to other users suddenly becomes "anything but Dropbox".
It's also a slap in the face of the community who wrote most of the software making the stack they used to get where they are.
Just remember, once the goodwill is lost, it's not coming back. Dropbox, you've been warned.
Because that has never been a problem before, when dealing with oddball solutions of past filesystems. Deal with it the same way - a metadata file that holds the crap that the filesystem doesn't deal with well.
For example, we've all seed the .DS_Store files on any fileshare that a Mac has visited, which holds Finder metadata that would be written to the HFS file system if it were HFS, and otherwise sits in a metadata file everywhere else. No, it's not the cleanest way to work, but it's something that Dropbox could implement in about two hours and be done with it, because this is a long-solved problem, and we don't need a new shaped wheel.
Slashdot still doesnâ(TM)t support Unicode after it was added to the HTML standard in 1997.