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.
Don't support Linux, and you'll be dead in the long run.
aaaaaaa
the whole android is linux argument.
I don't see dropbox abandoning android support in the summary.
The good news? I'm sure there will be something to replace the client published in the near future.
The fundamental problem in programming professionally for Linux is that it is a moving target.
Let's say I made a complex image editor for Ubuntu. The following month it stops running because the lib "X" no longer supports for something that I assumed would be standard. Then it's the "Y" lib that crashes because the lib developer decided to rewrite it in a scripting language (and did a mediocre job at it). I as a responsible professional spent a few weeks changing my code (and this costs money) to get around the problems of libs X and Y, but then the next month is the lib Z that suddenly conflicts, and when I can fix the interaction with lib Z now is the Canonical who decides to redo the way the Ubuntu desktop works and my whole work goes down the drain.
Most companies simply do not have the time or resources to keep rewriting their applications indefinitely, so it's easier to just not support Linux.
Religion: The greatest weapon of mass destruction of all time
I think this thread explains the situation perfectly. All the potential users of Dropbox on Linux already know that:
1. Dropbox doesn't hire good developers or else this would be a non-issue
2. Dropbox are trying to back door the system, and if not show us the source and prove it.
That reduces their possible audience of happy customers to 8,000, all of whom are on corporate Linux deployments in Germany aren't aren't allowed to install Dropbox anyway.
Meanwhile:
1. Dropbox works really well.
2. WSL already.
-----
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.
People are used to "Free as in beer" by using their phones.
There are plenty of ways around the whole KDE/GNOME/XFCE/Whatever debacle.
You make one that works everywhere ok, open the API and let others make the ones for CLI and whatever they like.
So when you begin, you use something ugly that works. Later, when it grows in users and your developers are thinking of adding other things, you use them to make it distro specific.
If you make it for CLI, yopu probably will make one for bash or perhaps sh, but do you moan about the others as well?
And if the API is open and others develop the software for you, you can concentrate and charge for whatever service you are actually selling.
And then you will notice that your groundbreaking idea that will be the next Google is not actually such a great idea.
Don't fight for your country, if your country does not fight for you.
Personally, I hate Dropbox. I use NextCloud and do all of the hosting myself.
You saw that it's too expensive for companies to support multiple Linux systems, which is why only free software does it... Don't see a contradiction in your own terms here ?
Non-Linux Penguins ?
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
What the fuck.
Read file, write file, check timestamp. That's all Dropbox needs. All filesystems provide this through uniform OS calls. Why in the world does Dropbox care what filesystem it's running on? Where in their twisted designer minds did they come up with features that dig so deep below the basic userspace abstraction layer they'd rather lose users than just keep things simple.
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
...
I'll try to explain under assumption that you aren't trolling.
Multiple file systems: Windows as used in real world systems use NTFS, ReFS with optional and probably not relevant exFAT, FAT32, (FAT16, FAT12 - if that's still supported).
Multiple distributions: the differences aren't relevant other than the use of ReFS.
Multiple desktops: doesn't exist.
Multiple init systems: doesn't exist.
Multiple kernels: the likelihood that Dropbox uses anything that changes between the supported kernel versions is pretty damn close to zero,
for the rest? Windows uses a stable driver ABI. Last time there were a change in driver architecture was with Windows Vista, not that it would make a difference.
TL;DR It is very significant if Dropbox depends on those things.
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.
Yeah but the difference is you paid for a tool, most using Dropbox won't want to pay, the majority of users know how to block any ads so no revenue from that and why should a developer support an OS which requires more work than the one with the largest market share where they make a load of money?
I only please one person per day. Today is not your day. Tomorrow isn't looking good either. - Scott Adams
I moved from a paid Dropbox subscription to a Resilio Sync subscription last year after having multiple issues with git repos being corrupted by Dropbox sync. In my experience, Resilio has been more reliable and the feature set continues to grow. I also like that there is no cloud storage of my files... Of course, some people like Dropbox just for that reason. The only thing I still use the free tier of Dropbox for is public sharing of links I had published that I do not want to have to break and recreate.
Many good self-installed alternatives to Dropbox on linux. Maybe the problem is most Linux users know how to set up their own and they can make backups too.
Laws are rules for the court, but merely a bottom bar to hit for life. Think beyond laws in your actions always.
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.
So, let's drain the applications around them and force them to go to WIN10 spyware.
If that fail, let's build spyware and troyan systemd in the Linux, that will do.
Really, all company distros switched to systemd at the same time ?
Plenty of man hours to develop a complex, bynary only, piece of SW that literaly take over the machine ?
There is only one answer.
Let's consider Adobe (and Photoshop). If Adobe wanted to port their industry-leading product to Linux, how do they do that?
They don't. The potential number of paying customers on the linux desktop platform in total is in most cases too small to justify the effort even if somehow they could mitigate the problem (and cost) of supporting the multitude of different distributions. I honestly wish more companies would support linux directly but I understand why they don't. There simply isn't enough profit to be had to make it worth the bother for them. I'm not sure there is an easy answer to this problem.
That's not to say every Linux user is unwilling to shell out the cost for a piece of software. But many won't.
The word you are looking for is "most", not "many", at least when it comes to desktop applications. The number of desktop linux users willing to pay for a traditional proprietary license is vanishingly small and as long as the applications people want (yes people do want non-OSS apps) aren't available that will remain the case. It's the old chicken vs egg problem. No apps because of no linux users and no linux users because of no apps. The fact that linux is ludicrously fragmented compared to Windows or OS X or even Android merely worsens the problem.
These companies that use Linux as a base for their offering and then can't support Linux are just lazy. There may have been a time when they could have used the "it's too hard to support all these distros" argument, but that was the 1990's maybe up through 2004. It is 2018! We now have FlatPak, AppImage and Snaps. Hell, even Microsoft has released Skype as a snap image making it easy for the noob to install it on a fresh (gnu/)Linux desktop. My best guess is it's the managers either being clueless or having some agenda that keeps them from supporting *nix desktops. Vote with your wallets people. I haven't used DropBox in many years. Even then, I was evaluating it in parallel with SpiderOak. For backup I use rsync.net. For sync and collaboration I generally use G-Drive since that's what my clients seem to be using.
Any idea as to the number of Linux compatible FS pCloud supports?
It says that there's no Linux to speak of. When you're talking about any other mainstream OS (Windows, MacOS, iOS, Android) - they all have: 1) Universal packaging mechanism 2) A set of stable APIs/ABIs you can rely on 3) Some sort of UI stability.
All these these features are basically a swear word in the world of Linux distros.
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.
Not being a Linux expert myself - isn't there already containerization available for Linux applications? Give up a measly few percent of performance by not using cutting edge extension #3 and work in more distributions?
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?
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.
Linux users always boast of being able to configure their systems any way they want. Making it interface to Dropbox is just one more configuration issue.
You just need to make your Linux box look like a Windows box from the outside....
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?
Dropbox has this problem with filesystems and encryption layered over filesystems because they want to be a filesystem. They don't seem to have a problem with systemd vs. upstart, or GNOME vs KDE, or Ubuntu vs Fedora.
Photoshop doesn't need to be a filesystem, so they should have 0 problems due to supposed "fragmentation", just like:
* Gimp (https://flathub.org/apps/details/org.gimp.GIMP)
* Darktable (https://flathub.org/apps/details/org.darktable.Darktable)
Oh, you want proprietary examples, well how about:
* Slack (https://flathub.org/apps/details/com.slack.Slack)
* Spotify (https://flathub.org/apps/details/com.spotify.Client)
* Visual Studio Code (https://flathub.org/apps/details/com.visualstudio.code)
As a for profit business chasing corporate customers, it absolutely means Linux has such a small slice of the corporate pie, it's not worth it's time to develop and support. The verdict is in -Linux desktop is failure... sorry fanboyz.
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.
adobe CC DRM system will need to work on linux in a way that can't be easily bypassed
There is no case where photoshop cares about the filesystem it runs from.
This is because the Adobe Photoshop file format doesn't use alternate data streams or extended attributes. Dropbox, by contrast, has to sync arbitrary files created by programs that may use these optional file system features.
These same arguments have been trotted out every so often over the past 20 or so years about Linux. I remember a Cnet article in the late 90s saying the same things. If Adobe wanted to put their software onto Linux, they can and would have, but I don't think there's enough demand still to justify the cost of porting and maintaining it. Linux has commercial server software ported to it because it is a rock-solid solution for such tasks. Companies and consumers rely less on Linux for desktops because Windows or Mac OS is good enough to accomplish most tasks and are 'easy'. I could be wrong but I don't see this changing in the next 20 years either. The majority of businesses and consumers will use Windows/Macs for desktops which are where retail software developers will focus, and Linux will maintain its supremacy on the server side.
One difference is that a free software developer can often get an application packaged in the major GNU/Linux distributions' repositories, where fans of each distribution will do much of the integration work to keep an application running under that distribution. Proprietary software doesn't have that luxury.
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.
Maybe DropBox should just publish the cloud APIs that their client uses to read/write files from disk. Chances are that the open source community will produce something equivalent to their client relieving them of the effort of doing it themselves.
Read file, write file, check timestamp. That's all Dropbox needs.
That and making sure no other application is writing at the same time Dropbox is reading or vice versa.
All filesystems provide this through uniform OS calls.
Until the OS returns the error code meaning "The file system on which this path is stored does not support this operation." Some file systems might return an error code like this for locking, symlinks, alternate data streams, extended attributes, or whatever other "uniform OS calls" Dropbox tries. Restricting file systems to those that fully support the required "uniform OS calls" reduces maintenance costs.
Or how would you recommend to sync a file containing alternate data streams to a file system that returns an error code when an application attempts to write one?
If you write userland software, you most likely don't have to care about FS, GUI (there are framework that handle that for a vast majority of cases), init process or whatever. You write *userland* *software*.
The main issue is how to distribute your software. Then your concern become "should I support X, Y or Z distro". Just pick something like two of the "big" ones, and if people run something else, they can manage the details on porting a package from X to Y.
There's even relatively standard way to hook into stuff like "load on startup" through freedesktop. And as long as you officially support a restricted set of distributions, that's not a problem.
It appears that multiple third-party solutions to dealing with Dropbox on Linux exist, though I don't know if any are still actively developed. Hopefully these types of projects will see an uptick in activity.
There is no XUL, only WebExtensions...
...of Linux on the DropBox?
How would the Dropbox client application maintain the association between the parent file and "some other files" even if the user renames the parent file?
Windows and macOS both have full drive encryption and both work fine with Dropbox, OneDrive, etc.. Seems your conspiracy falls down pretty easily.
I can't tell you the number of times I've seen hacks like that because queries were failing due to performance issues and you couldn't get the suits to pony up for more RAM or a faster CPU (or nowadays another per-CPU license, thanks Oracle!).
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
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
less than 2%. Dropbox is a desktop - not server - service. If you can configure and run your Linux server - you already have WebDisk, FTP, and a host of other options. This is for desktop file sharing and storage, drag and drop from the desktop. And Linux is such a bit player in that market, it makes zero financial sense to support it.
Browsing at +1 - no ACs, I ignore their posts. So refreshing!
> That and making sure no other application is writing at the same time Dropbox is reading or vice versa.
Recheck the file after reading. Sync newest version. Currently, Dropbox most happily kept repeatedly syncing a file I was downloading, as it kept growing. It was most definitely open for writing the whole time. It was something annoying but not critical.
If Dropbox is currently writing a file, it's the reading program's (or the user's) problem to make sure the file is complete and synced.
> Or how would you recommend to sync a file containing alternate data streams to a file system that returns an error code when an application attempts to write one?
Two approaches.
1: don't care. Keep the record of the minimum set of features that is supported by every semi-sane filesystem, say, Fat32. Set the rest to defaults if fetching a new file from the server. Don't touch the attributes if you don't know them. 99% of users will be perfectly happy, the rest will choose a different solution.
2: maximum reach. Do add support for any features of the OS you may imagine. Record every meta-feature that is currently present in the file into database of files - on server and synced into .dropbox dir or wherever Dropbox holds its indices. When writing, apply any attributes that are present in the DB, don't worry if you can't. If the attribute is missing in the local copy, just don't overwrite it with NULL in the db so if you sync back into the 'featureful' FS it will have the extended attributes as before.
And 3. Anything in between. Store and retrieve as many attributes as you wish, fill the rest with defaults.
So your 'alternate data streams' file will have its primary data stream in the file on disk, the rest in DB if the devs want to support them. If they don't, the extra streams won't propagate across Dropbox cloud copy; will be left alone locally.
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
This brings up a curious question as to if this includes all filesystem derivatives with the exception of unencrypted ext4, and how does this reflect on origination Unix counterparts such as FreeBSD, FreeNAS, and MacOS that may take part in such filesystems?. What is the limitation of what file system types that will continue to be supported from the Dropbox service going forward, and how will it affect it's user base going forward? Will this also trickle down to Windows-based machines using encrypted NTFS, and will this request that NTFS encrypted filesystems be decrypted before backups are possible? Will this include APFS as an exception to stay in business with the Mac user base?
Will any supported file systems need to be unencrypted explicitly in order for the service to work going forward?
These are things that raise concerns, and will have an impact on such a service.
If you don't have dropbox deamon running in the background, It's hard to tell if was a rename, or a delete+ new file with the same data, but different metadata. If it is, you use inofity to keep be able to tell which of the two occurred. You may also be able to store the inode and checksum somewhere as a hint.
So your 'alternate data streams' file will have its primary data stream in the file on disk
Unless the file on disk gets renamed. Then how will the client continue to keep track?
Why did they grant you write access to all of the files?
If it is, you use inofity
Do you mean inotify? And if so, does inotify work with all local file systems (not counting NFS)?
You may also be able to store the inode and checksum somewhere as a hint.
Provided the file system supports inodes, which usually means one that supports hard links to files. FAT doesn't, unless you count a file's first cluster as its "inode". So Dropbox drops extended attributes upon rename on a FAT volume. This is documented.
I am a Linux user that uses and pays for Dropbox.
Just like it did so far. Detect the file got deleted, detect a new file was created, sync the new file.
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
I gave up on Dropbox after multiple times it would lock a new newly downloaded file from Chrome and I'd lose the file. Chrome (at least at the time) would download files to a temporary name, and then rename. Silly hair trigger Dropbox would lock the temp file before Chrome could rename it and then I'd end up with a zero byte file.
Additionally, Dropbox would have this incessant inability to properly detect changed files - I still have a multitude of "conflicted" files in my folders. I had ONE computer connected to this Dropbox account. There were no other updates to conflict.
Don't even get me started on the stupid plugin thing they shoved into Office and I couldn't permanently turn off.
They've been at this for 10 years? I don't get it.
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.
It should work for any on-disk filesystem, it's implemented on the kernel/ c-library level. NFS, procfs, debugfs.,tempfs.. are special cases that can either be modified by other systems/kernels, or be modified by calls within the kernel itself. Perhaps dropbox is doing funny things directly to the block layer, but it shouldn't be able to do that without root permisions or setgid somewhere, and that's sketchy for all sorts of reasons.
I'd believe this, except for the whole android is linux argument.
Android is not Linux, it is merely hosted on Linux. If Android provides sufficient APIs an app doesn't know or care about Linux, the hosting kernel underneath could be switched to BSD (or Fuchsia someday) and the Android app would not care. Admittedly, dropbox probably does use the NDK but ...
I don't see dropbox abandoning android support in the summary.
If dropbox needs to use the NDK and access Linux directly there is only one distribution to be compatible with. That is quite different than supporting desktop Linux in general.
I just though of this... The reports that inotify creates may not be completely standard across different filesystems.
Supporting an application on various distros of Linux? At most, some environment variables, like PATH or LD_LIBRARY_PATH.
The rest is pure bs. Unless, say, you're M$* Maybe it's just they can't charge as much.
* True story, from Macaholic friends: when the Mac went from, I think it was Moto chips to PPC, Word for Mac broke. That turned out to be because it was such a dog that M$ had committed a Cardinal Sin: they were not making operation system calls, they were talking directly to the hardware.
Free open-source software supporter by a small number of dev without monetary incensive can do it. So now, how can you explain that a profitable company can't ?
You answered your own question: "devs without monetary incentive" vs "profitable company". The former are unconcerned with their efforts being profitable. The ability to do something is a secondary issue for the later, profitability is the primary issue.
How about these explanations: 1) If a user has a wierd problem, a professional developer has to fix it promptly or give a refund. An open source developer doesn't have to do anything.
The open source developer is free to say: you have the source code, fix it yourself. Or hire me to fix it, or hire someone else to fix it.
Btrfs in favor of EXT4, when even EXT4 fails their own "test" at time?
Sorry, DropBox, you lose. I'll never drop Btrfs, but I've dropped you. There are just too many other vendors and technologies available for you to attempt to muscle me into exposing my data to your sifting.
Running with Linux for over 20 years!
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?
This is why all you arrested-development FOSSie children, who can't even agree on, well, ANYTHING, will NEVER see the MYTHICAL :"Year Of The Linux Desktop".
Never.
File with attributes or alternative data streams was deleted, new file without either is created, new file no longer works in a program relying on those.
And this is why Linux (or Unix in general) will never reach the consumer saturation level that the Mac and PC have (yes, I know OSX is Linux)
macOS is NOT, repeat NOT, Linux.
macOS is a CERTIFIED UNIX; something NO wannabee-Unix Linux will EVER be.
https://en.wikipedia.org/wiki/...
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.
What if they just provide their application in a virtual machine instance? That way they can write to only one OS but run anywhere the hardware supports.
"I believe in Karma. That means I can do bad things to people all day long and I assume they deserve it." : Dogbert
Excellent explanation and you expose why this idea that "we HAVE to detect the flesystem being used" nonsense shows they don't know what they are doing. Just use xattr calls and if the exist, you can copy them over. no need for low level calls and dirty tricks.
And this is why Linux (or Unix in general) will never reach the consumer saturation level that the Mac and PC have (yes, I know OSX is Linux)
What you "know" and what is true are not the same. OSX is derived from Unix not Linux.
This story reminds me some of the Nero Burning Rom story. Back in the day, Nero Burning Rom was THE software for burning CDs on a Windows machine. Droves of Linux users mused how they wished the company behind Nero would produce a version for Linux. After some time, the company did just that and released Nero Burning Rom for Linux. Those same Linux users who so desperately wanted the software created were ready to take up arms because Nero had the nerve to charge actual money for it, just like they did for the Windows version. Nor would Nero make it open source. And at least that that time, it was amazing how many Linux people were under the delusion that one could not sell Linux software for money (I still see this now, too).
I want a new quote. One that won't spill. One that don't cost too much. Or come in a pill.
A commercial vendor would supply either statically linked binaries or dynamic libraries with install+LD_LIBRARY_PATH if a different version. Eliminates concerns with distro and gui.
Systemd has helped code for legacy rd.d scripts, so you only need rc.d and a check.
Applications don't interact with file systems, they interact with the abstraction API.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
My experience with dropbox is that it is an absolute piece of steaming shit. They are obviously trying to LEVERAGE this and MONETIZE that, and so many things, to the point of it being unusable. Good riddance to bad garbage I say. may the door hit them smartly on the ass as they depart.
I wonder if Dropbox (not the article author) means encrypted ext4. ext4 itself supports file-level encryption since linux 4.1.
https://wiki.archlinux.org/ind...
That has its own ioctls and policy management.
Just asking.
When all you have is a hammer, every problem starts to look like a thumb.
Who uses Dropbox aside from some clueless PEBKACs? Definitely not that many from the Linux camp, that's for sure. We know how to handle ssh and scp. Seriously, I'm surprised they even offered a client in the first place. Didn't know until now, couldn't create less either way too.
I bet it's the same for most Linux users.
We suffer more in our imagination than in reality. - Seneca
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.
Filesystems are designed to abstract file handling. Applications need not know if the FS is Etx4, Xfs, Btrfs, etc. They all have a standard POSIX interface to manipulate files. If this were not the case, we'd live in utter chaos. So that was a bogus point. As for apps like Photoshop, we already have better Linux equivalents; InkScape and GIMP for example. High-level applications like Dropbox need not worry about the FS, and should not worry about distribution so much. There are many development platforms that can help build distribution and platform agnostic applications. Take Microsoft Visual Code for example. And if the application has a web interface, then the OS and distribution make no difference. I can access my Google Drive with any web browser, or via apps. Google Drive has a native app for Windows, but not for Linux. However, I use my web browser to access my files in Drive under Linux every day. For Dropbox to drop Linux application support is really not such a big deal. There are already open source clients that can access Dropbox in Linux. From Dropboxes perspective, why not let the open source community create the applications?
Jamey Kirby
What? where's the racism? :(
Avantgarde Hebrew science fiction
And all of the filesystems typically used for linux installations (xfs, jfs, reiserfs, ext2/3/4, btrfs) do support the same calls, it's only when you get to simplistic filesystems like FAT or special purpose filesystems that there are significant differences.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
I don't think I am nice. I am subtle. I insult people in less direct ways. Lately I've been trying to be nicer. Fail today, I admit.
"First they came for the slanderers and i said nothing."
Trade secret. I am not even allowed to admit I worked on this for them. Are you clueless as to how commercial coding works?
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
I use lots of applications that work on Windows, Linux, Android, iOS and whatever Mac is using now. Why would anyone be using something that is limited to Windows in the area of file backup and transfer? If you're talking about CAD or even Point of Sale, sure, sticking to a single OS might make sense. But file storage? This is a loser strategy.
What program relies on those, **and** would benefit from files placed in Dropbox directory?
Remember Dropbox is for storing/sharing your personal data files. It normally resides as a subdirectory of your ~home or "My Documents". It's not NFS or Samba where you can share the same binaries between many computers, share printers and other shit. It's for storing data you expect to share between different devices.
If you moved the data from the computer you renamed it on, to the one where it "broke", using a thumb drive, you'd lose these attributes too.
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
Another possible reason for Dropbox to discontinue Linux support is that Linux users are experts who will luse whatever capacity they pay for to the maximum. Their business model likely depends on people paying for more than they need.
It's a moo point (as the great and wise Joey once said). DropBox was never that good with Linux anyway. There's NextCloud and OwnCloud... but most of the time, I just use git. What does a cow think about it? Who cares!
I've been a very adamant user of Dropbox for many years now. I think since they first started. I've run it on Android, Linux and Windows. If they want to drop a platform that is very important to me then I believe I may be dropping them. And I'm a paying customer which makes me wonder how many paying customers they are going to lose.
Even with extensive portability across UNIXes, any responsible company should quality-test on all of the platforms they claim to support. That does require considerable resources and time.
you mean NSAOS and NSAOS Lite?
I think the OP is over thinking the DropBox decision. It comes down to one simple thing, not enough of their target audience are using Linux as a client OS.
they can't hack a tree with a chainsaw and it says nobody wants it ?
Free speech was meant to be free for all... how can anyone grow up in a nanny state ?