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?
I thought Slashdot of all places would be free of the old Microsoft FUD from the 90s about how supposedly fragmented Linux is and how Linux users don't want to pay for software because Linux itself is (usually) free... The reality is that from an application developer's perspective Linux is about as fragmented as Linux and OSX if you can use some pretty basic principles and Linux users do pay for software if good paid software is available. It's also kind of ridiculous for SystemD to be brought up here when application developers don't need to work with it and it's pretty much universally used at this point.
But hey, gotta bait those clicks somehow right?
"Why should I want to make anything up? Life's bad enough as it is without wanting to invent any more of it."
There is a ton of applications on Linux that all do not have these problems. It just requires a bit of experience and not using every damned feature some specialized installation may have. Apparently, Dropbox is lacking the skills for that though.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Let's take the case of Adobe porting Photoshop to linux.
1: ext4/btrfs - This does not matter at all. There is no case where photoshop cares about the filesystem it runs from.
Ubuntu/Fedora - Not really a problem. I personally run Fedora, but fedora don't have any problems running binary software developed for Ubuntu. Case in point: Most of the games I have in my Steam library are developed for Ubuntu, and have newer been tested on Fedora by the devoper at all. But they still run fine on Fedora.
Gnome vs Mate vs KDE - Again: Why should Photoshop care? None of my other apps really care so why should Photoshop?
Case in point: Even if I replace Kde which I currently use with a version of Enlightenment which I have compiled my self, none of my software will stop working. Apps don't care.
systemd: If Photoshop cares about my init system, something have gone really really wrong. No issue at all.
As of version 10, Windows is also a moving target.
https://www.microsoft.com/en-u...
If you're only worried about Linux being a moving target because you write poorly-coded crapware, then good news! Windows update always breaks SOMETHING on all the poorly-coded crapware IT installs on my work desktop. Seriously. Every. Time. It. Runs.
Linux is the new normal.
You did not understand anything I wrote. Servers do not change constantly, same thing for routers and cell phones. Now try making desktop applications like I do and you will understand the problem.
Religion: The greatest weapon of mass destruction of all time
You can always statically compile your libraries in, especially those that might end up being problematic.
Isn't Dropbox written in Python?
And if VS Code can be written in Javascript and run on Linux, why would it be so hard for Dropbox?
Those who do not learn from commit history are doomed to regress it.
You have FUD on your shoes and now you're traipsing it all over my nice clean carpet.
If you're a company that produces a product and you stake your living on that product then you hire somebody half-way competent and these issues are just totally non-issues.
If Adobe wanted to port their industry-leading product to Linux, how do they do that?
They write code in a portable way and compile it for a Linux target. it's really not hard. For more information, see any of the ten thousand "writing portable code" guides. As a bonus, portable code tends to be much cleaner and is less likely to have issues with things like newer versions of windows where compatibility changes are made, because you stop making assumptions about the operating system.
Do they spend the time developing support for ext4, btrfs
Why does an image editor need to care about the filesystem? What's wrong with just telling the operating system "I want to (read|write) file X" and letting it take care of that?
Ubuntu, Fedora
An approach that seems to be working just fine for valve and steam is to just support ubuntu, which also covers about a million derivative distros. If you want to be really nice you could also package for fedora and just with those 2 you'll cover something like 90% of Linux users. And the rest will be able to get your stuff working anyway, since they're smart enough to run obscure distros and generally know what they're doing (or can find a howto). I don't think any Linux user is going to complain if you're not packaging for their obscure distro.
GNOME, Mate, KDE
Pick one of the major toolkits like GTK or QT and you'll find that 99% of Linux users have it installed. Write your code to work with standards and you'll be just fine. Assuming you're doing something weird and wonderful enough for this to actually be an issue. But you're probably not.
systemd
Again, unless you're doing something weird and wonderful you will have no cause to know or care about systemd. Or openrc. or sysvinit. or any init system. And if you are doing something weird and wonderful where you actually do need to care you have many options: you can engage the community and they'll tell you everything you need to know, and maybe even write your systemd service files for you. Or you can just support the dominant platform and let the people using other systems sort it out themselves. And they will. And if they can they'll write howtos and send you patches to enable you to support the others if you want to.
You see how that might look from the eyes of any given company?
I sure can. If they hire morons they'll say "ooh Linux! scary!". Or they could hire skilled people who will see that these are all either total non-issues or trivially addressed.
It becomes even more complicated when companies consider how accustomed to the idea of "free" (as in beer) Linux users are
It depends on what you're trying to sell, and at what price point. If it's a system utility, we probably don't want it anyway because we probably have something better that's not only free as in beer but free as in freedom. But if you're trying to sell a good, easy to use, prosumer-grade nonlinear video editor, shut up and take my money, as long as you don't want $500 for it.
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
It's really not that much time and effort if you have competent developers.
I literally do not know a single Linux user that doesn't have a pretty reasonable list of games in their steam Library. Mine is about to hit 300.
As far as I can see the problem is not one of price but
l wrote software that creates and syncs and *bootable* copy of a Linux machine. To have the clone boot and run right, everything needed to be copied over exactly - extended attributes included.
It CAN be hard if you try to do it using the approach you are thinking of, but there is a much easier way. JavaScript programmers will recognize these two different approaches.
> does the file system support symlinks, does it support locking? Can we reliably see if the file changed while we tried to sync it?
stat() will tell you if the file is a symlink and when it last changed. If this file is a symlink, then it supports symlinks. You don't need to ask "does this filesystem support symlinks?", you just use stat() to find out what kind of file this is.
> How about basic or extended attributes?
Same thing. getxattr() will give you the extended attributes, if there are any. You don't need to start with detecting the filesystem and try to figure out if xattrs are possible, just use the getxattr() system call to read the extended attributes. You'll either get some or not.
> Try that with /dev/zero and wait for your server space to fill up. Then download the already uploaded contents of /dev/sdb onto the current system.
Remember when you called stat() earlier to get the file type and see if it's a symlink? That also tells you if it's a device file. So already done.
Let's say you have really dumb programmers who don't know, and can't learn, that you get file information with stat(). Devices are in /dev. Don't copy the contents of files in /dev. You don't have to think about /dev/zero, /dev/random, etc - just know /dev is device files. Our system skipped /dev and /proc. Or just use rsync - it does the right thing by default. If you don't want to USE rsync, spend 30 minutes reading the rsync man page and do what rsync does. Those are options if you're too dumb to use stat().
None of this depends on which filesystem, init system, or kernel is in use - you won't find a bunch if "if filesystem is reiserfs" in rsync.
Back in the day you used to see two types of JavaScript. Dumb JavaScript looked like this:
if(navigator.userAgent.indexOf('MSIE 5') != -1) //we think this browser is IE5 // Can't use document.documentElement.getBoundingClientRect, give up // Code for Safari ...
{
} elsif (navigator.userAgent.indexOf('Safari') != -1) {
rect = document.documentElement.getBoundingClientRect()
Smart JavaScript does this instead:
if(typeof document.documentElement.getBoundingClientRect != "undefined");
{
rect = document.documentElement.getBoundingClientRect();
}
Just see if the feature is available, don't try to guess which browser it is and then try to figure out which features it has bases on the useragent.
Linux is even easier. getxattr() is always there, it always works. If there aren't any extended attributes, it'll return none.
Linux is primarily used as a web server, as heavy corporate back-end infrastructure, or by hobbyists/enthusiasts. Dropbox's primary market are consumers on Windows, which only has the features you buy from someone, or the mobile market which needs, I guess, a place to store and share their dick-pics.
Nothing about a web server should want to have anything to do with drop-box. It's already public, and drop-box has their own web server.
The corporate world is highly allergic to drop-box as an enterprise storage medium. They all have other ways or other deals in place for any cloud storage they need, and it's not going to be public, nor part of their back-end infrastructure. Even for their end windows users, dropbox is usually forbidden under pain of termination.
Hobbyists/enthusiasts realize their linux already has scp (all the distributions at this point), and so does any machine they may use. So they have DIY dropbox. Add in that this particular market is somewhat more distrustful of cloud-anything, and often has a more privacy and "my data is mine" and "my personal information is mine" bent and the pool of good customers here gets pretty small.
So you have an OS that isn't going to ever be a big player on your product, and you're hurting for cash. So you can fire some devs and drop support for Linux. That's what I think this means.
Bottom line: Jack Wallen doesn't know what he is talking about. Nothing to see here, move along.
First of all: the premise of the article is completely wrong: Dropbox isn't actually dropping support for Linux! The author wrote this entire nonsense article, then when "cvoltz" commented and pointed this out, they added an UPDATE to the top clarifying. The update completely undermines the point of the article. Also, the article provides "reasons" that are just generalizations with no technical backing. I won't rebut them because other posters have already done so. Also note that this author does not represent DropBox. So really, there's no substance here.
While there are differences between Linux distros, and yes it can be a pain sometimes (mostly dealing with installation and dependencies, in my experience), none of the items listed are valid examples of those difficulties. The entire article should just be retracted.
From the comments sections:
P. B. Lecavalier • 7 days ago
I wrote a detailed comment demonstrating how this "award-winning" author has seemingly no idea of what he's talking about. It was swiftly deleted. Fine. I'll leave you with your spectacle of illusions.
Say a file originated on a computer whose file system with extended attributes and in fact has extended attributes. You want to sync it to the computer you're using, whose file system does not support extended attributes. How should the sync tool store the file on the computer you're using without removing the extended attributes when syncing it back?
I think "support" is the key problem. Developing a product for Linux is easy, the excuses given were lame. The real problem is Supporting the product.
Linux is difficult to support at Level 1 and Level 2 support, which is just the support people reading the scripts, then watching the person follow the items on the script. Ubuntu and Mint technically are nearly identical. However the UI is a bit different. So the script needs to be a little different for each one. Level 1 and 2 support has nearly 0 brains and flexibility. So Linux calls will need to automaticly go to the expensive level 3 and up. Where people with brains need to make a decision based on different UI to get to where they need to go.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
This is all bullshit:
For a company to support Linux, they have to consider supporting: Multiple file systems, multiple distributions, multiple desktops, multiple init systems, multiple kernels.
* You do not need to support multiple file systems. The kernel does that for you. Also most people use EXT-something.
* You need ONE deb and ONE rpm. If your build-system would be anything modern this would be done automatically. You could even cooperate with package maintainers from distributions. Beside that it is easy to package something for debian/ubuntu. And I cannot imagine that this is super difficult for Fedora, SUSE, etc.
* For a working desktop-service you do not need to support multiple desktops. You just need a running client service. Furthermore, you just need an open API, people will add tiny applets to ease shit. Also if you support Nautilus and Dolphin (or whatever it is called) then that would support almost everyone. For the rest see open API.
* You do not need to support multiple init system, because it is a user service. It should not run when not logged in.
* You do not need to support different kernels. You link with glibc. Period.
Instead of lying to us, just say the truth. Linux users are few, they often do not use you paid services, and they often use evil Nextcloud setups anyway. We need to make more revenue and cut costs. We also love to take from the OSS community, but we do not really care about them.
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.
Visual Studio Code works with primarily text files and perhaps executables. Dropbox has to be able to sync any file, including files that contain alternate data streams and extended attributes. That's a bit more of an involved job.
...of Linux on the DropBox?
The op is like every poor excuse I've ever heard on a Linux message board. Let's go through point by point and talk about some of this.
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.
No, that's simply untrue. Nobody in the commercial world supports all of Linux in this way. In fact, I don't know of many oss vendors that do either. If you're going to support Linux, what you're usually talking about in the real world is some major implementation of Ubuntu, and/or Cent/Redhat. That's it. Yeah, you really do need to think of it as two operating systems, because of differences in the package manager, but it's not terrible. It can be managed.
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?
Actually, they did it with Wine. Wasn't released but they did talk about having done it.
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?
My hope is that if Any Given Company were hiring people, and talking seriously about a project like this, that they would have actual Linux people who have experience in developing commercial projects for Linux. Even an entry level Linux developer straight out of highschool programming class could tell you the whole argument is bullshit.
That said, no, I could care less what Dropbox does.
This signature has Super Cow Powers
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.
The story is ignorant, and apparently written by someone who doesn't know squat about Linux. There is FUSE which is a stable way to add a filesystem driver. The desktop environments and file managers are irrelevant because they use the same filesystem API, and the same API for an app to draw to the screen (X and Wayland). You can use either Qt or Gtk for your GUI application, and it will work on any of the desktop environments. If you write your app for Qt it will run perfectly well on a Gnome desktop environment, if you write in Gtk it will run perfectly well on KDE, because they use the same underlying X or Wayland API. I don't know how many times this has been expained to tech journalists over the years but they still can't get it through their thick skulls. The filesystem variety is also irrelevant becuase the filesystems also support the same filesystem APIs. No userspace software should directly interact with a filesystem. We have flatpack, snapper, appimage, and docker for cross distro packages so that need is being covered. Because systemd supports Sys V Init files, you can use Sys V Init files to start a service and it should work on most distros, systemd or not. The service command is supported by most distributions. So increasingly there are cross distro common denominators for people who are writing applications. The variety of distros, desktop environments, filesystems and init systems is a strength, but there can exist a lowest common denominator cross compatible interface for applications to access.
Probably needing the ftype=1 feature that enables d_type support which was not available until a few years ago and requires a fresh run of mkfs.xfs to enable. With d_type you can find out if a file is a directory, link, FIFO, regular file, etc. straight from readdir() without an extra stat() call for every file in the directory, but not all filesystems support it so falling back to stat() when d_type == DT_UNKNOWN is mandatory. I fixed a bug in dupd caused by assuming d_type always returned a good value, which failed on an XFS v4 volume and rendered the program unusable.