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?
"If you're a company that produces a product (and you stake your living on that product) ..." ... then you don't rely on the cloud to store your effing data in the fist place. Non-story. Moving along.
Why would an image editing program give 2 shits about: ext4, btrfs, GNOME, Mate, KDE and systemd?
Tinfoil hat time, maybe they or the government (to which they are beholden to) want access to scan your hard drive and the move towards encrypting file systems is getting in the way... so this is a way to encourage ext4 unencrypted only :o
Seriously? I purchased a third party tool called InSync to synchronize my Google Drive with my Linux laptop. Cost me a couple of bucks. And it works perfectly! So is that developer just smarter than everyone at Dropbox, a BILLION dollar company? Maybe they should hire that guy.
Lets be clear, they didn't drop support for linux, they dropped support for backups of weird specific filesystems. Clients still work ok and if you create a tar backup you can still upload it or push with API to your site.
I mean seriously, if Windows had 10 seperate choices with 5 different variations of each with 20 sub options, You'd find Windows support narrowed down to the top 2 enterprise required backup options as well. Silliness.
Plus if you have an encrypted filesystem chances are you aren't randomly uploading your files to a cloud provider for backup so this is probably a financial decision and not philosophical.
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.
Exists for a reason.
They could just support webdav and things would be good enough. Trusting dropbox applications or kernel modules seems like a bad idea.
Anyone who can't answer them on their own simply have no business writing any kind of software. Complete and utter ignorance.
Looks like a lot of fake excuses and no real substance - the app should be filesystem agnostic (as in, who cares about the FS?).
If you're writing apps that work on one FS but not another, then it's a shit app and should be avoided.
I say good riddance - there are a lot cheaper and better options (that do work on multiple filesystems, init, etc etc, like OwnCloud for example and that's properly free, as opposed to dropbox, plus, you can email the devs and actually get a human response back)
Plenty more fish in the sea. Goodbye dropbox - enjoy your MBA leadership as it continues to disintegrate you.
Don't support Linux, and you'll be dead in the long run.
aaaaaaa
From TFA:
For a company to support Linux, they have to consider supporting:
Multiple file systems
Multiple distributions
Multiple desktops
Multiple init systems
Multiple kernels
How the hell is that significantly different from supporting Windows?
FUD is FUD.
Microsoft has never been supportive of FOSS, they have pretended to be for a while but now they show us that they were just kidding... And of course they were kidding.. They did say after all, that Linux is a cancer.
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.
Why would companies need to care about fs. Even distro is barely relevant these days. As long as you support systemd (if you're a daemon) and aren't using undocumented apis you should be ok.
With snap and docker it becomes less relevent too.
In fact, a QT app I wrote worked on Windows, osx and Linux with only 1 line changed (after which it worked on all 3).
This is the same crap you hear from Apple users claiming that Android developers need to test every Android phone and version to confirm compatibility
And that is why 100% supercomputers and almost 100% servers use liGnux.
First: the writer is an ignorant, GIMP - adobe photoshop FOSS alike program - works even in MS WOS and Mac OS with small as many other FOSS. Even better than some other proprietary software made for MS WOS or Mac OS when they change versions.
Second: You only have to write code using cross OSs libraries, and then compile to the 3 main OSs, and if you make your own libraries make them compatible with the 3 main OSs, If you write code for liGnux you will have very easy to compile for Mac OS and MS WOS.
And remember NO virus, LESS space for programs, BETTER file systems, MORE control, MORE choice, MORE FREE software MORE bleeding edge LESS cost BETTER performance and almost the same or better performance in games than native MS WOS emulating with wine or proton.
If Dropbox wants only to focus in making a MS WOS client it is because they do not make enough money from liGnux users that know best than to pay them for cloud storage, not a big deal to lose a software almost nobody uses.
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.
Why does any application give two shits about the filesystem or booting procedure? We're not talking about MS DOS here ffs. Sounds like they want to hire somebody else who doesn't do Linux. Fine by me. I was going to spin my own anyways.
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.
Also ABIs don't vary much among versions of tools and libraries.
The only time compatibility is broken is among different kernel versions.
Different distributions are basically just a different collection of packages but those packages are all available across other distributions anyways.
So why is this difficult?
They can't work out how to use standard Linux APIs, but are happy to spend $100,000 on a silver panda?
Snaps let you ship everything as you would have it on your dev station and have it run on any system.
No, really. Doesn't bode well for that company.
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
TechRepublic.com is a publication owned by CBS Corporation.
Corporations make money if they promote Windows and bash free software OS'es.
The client will work fine in Wine regardless of what fucking file system you use....
I am starting to find it amusing just how low the bar is for being a leading tech provider. Maybe they should just leave the Linux things to the users, they'll figure it out.
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.
Pad with any technical explanation you want about file systems and whatnot. It is hogwash.
I worked on a cross-platform desktop application: Windows, Linux, Mac. Windows was about 94% of seats sold, Mac about 5%, Linux around 1%.
We would not have kept the Linux version around had it not shared about 85% of its code and testing harness with the Mac version (which itself was on shaky business case ground).
Long story short - we didn't make money on it directly. In one case it got us in the door with a customer... and then we simply proceeded to sell them Windows licences to make up for the loss we incurred shipping the Linux version.
How much does DropBox charge for their Windows desktop software?
They make their money in user subscription regardless if that user has a Mac, Windows, Chromebook, Linux, Android, iOS, Commodore64, ...
I think this has more to do with trying to guide the community into using more lenient distros that have partners who like to share meta data for the extra cash. This author smells like a large trout too. Just saying.
But this is conspiracy theory 101.
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.
When you develop high level software for an OS you donâ(TM)t need to worry about low level stuff such as the file system type or kernel version. But if your product depends on a particular version of some obscure package that is not up to date then you have a problem.
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.
They are already irrelevant
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?
Found theyâ(TM)d been hacked awhile ago, they didnâ(TM)t say.
Iâ(TM)m not surprised it canâ(TM)t support linux, it probably barely supports Windows and consists of piles of bandaid style hacks and workarounds. Obviously those messy hacks donâ(TM)t work so well on linux etc.
Or, more likely they ran out of ideas to make it work in a clean cross platform way.
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?
Here we go again. This issue of Linux not being a single platform, from a developer's viewpoint, has been a problem for a long time.
Say you want to create a moderately to very complex program (not some tiny, single-purpose utility) and release it as a single package for "modern" Windows, meaning 7, 8.x, and 10, targeting a single architecture, say x64. It takes a bit of work, some of it in packaging/installation, but it's not too difficult as long as you know what you're targeting at the start of the project.
Now create a similar offering for all the "major" current Linux distros. Good luck. Likely the best you can do, as we've seen numerous projects do, is create and maintain separate installation packages for different distros. Given the tiny user base, why would a developer bother?
And as for the people waving Android around as an example: Of course it works better. It eliminates a lot of the variation that makes regular Linux a nightmare.
Yes, this OP is BS. I do development for these any many other systems. The reality is that 95% of the coding and concerns he presents aren't relevant. A desktop app doesn't need to know about initd, or the file system, just about the winnow manager its written in. Dropbox may need lower level access to do some operations that could be FS dependent but again thats trivial as the logical flow is the same in each case.
Smart JavaScript does this instead:
if(typeof document.documentElement.getBoundingClientRect != "undefined");
{
rect = document.documentElement.getBoundingClientRect();
}
You mean buggy JavaScript?
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....
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.
If the whole point of Dropbox is syncing between different computers having symlinks on one computer does not imply support on the other, especially if you try to sync files between Linux and a windows version were symlinks are still admin locked.
My own direct experience with filesystem portability is limited to svn. I once had to get a svn checkout to run right on windows when the repo was previously only used under Linux and even something simple as that constantly hit file name collisions (as windows doesn't care about upper/lower case by default) and symlinks. Now if I have a file FOO and a file foo which file should end up on windows? Does the other one count as deleted? Will dropbox create a symlink using admin privileges that the user cannot delete or modify?
Syncing files between two identical systems is easy. Syncing files between systems that do not have anything in common isn't.
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)
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.
Dropbox is in control of one end and so can avoid the issue.
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.
Its actually not as simple as you all seem to think it is. At least not to work at the level Dropbox is probably attempting. I am just guessing, but I think it is a fair guess that they use inotify to get notifications to monitor file and/or directory access. Advanced Inotify functionality has dependencies on kernel features and filesystem features, enough so that I gave up something I wanted to do with it because it was inefficient with xfs vs ext4 (I forget exactly what I was trying, I think I wanted to monitor something at the directory level, maybe something else, I slept since then). I could be wrong, but I'm willing to give them the benefit of the doubt that they are legitimately trying to do something that requires more than a POSIX compatible filesystem to be done at the reliability and feature set they are attempting.
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.
The other day my MS Surface Pro failed. So I had to send it back for replacement/repair.
Of course I backed up all my data first.
Except I did not copy my User directory to a USB hard drive, I moved it. Important stuff is in repos elsewhere so I was not much worried if the move screwed up.
Next thing I know I have people from my company calling and asking how come all the companies shared files on Dropbox have disappeared. The whole business was stalled.
Of course, Dropbox synced my actions by deleting everything in the cloud.
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?
Not only that but any app can use its own filesystem container format.
If something is not supported, store it in some other files.
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?
If that were true, just open source the dang client. Those fragmented communities would help you if your product is useful to them. CAPTCHA: anarchy.
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?
Most companies that provide Linux ports of their binaries for sale (e.g. Autodesk's Maya) only support one or two distribution releases. E.g. most support Ubuntu LTS releases and some fewer also support Fedora or RHEL (depending on kernel requirements). This might be feasible for Adobe, since porting from BSD (/OS X) would be relatively straightforward, vs. the total rewrite needed if they only had a Windows version. So the argument that they MUST support all versions of Linux is completely moot.
It's arguable that the market for Adobe software on linux is too small to justify even that investment, however there may be other factors at work, such as competing, commercial OS vendors jealously guarding their turf by any means necessary (draw your own conclusions).
I suspect that, were Adobe software offered on Linux, you might see a considerable professional user migration to that platform.
It's called LYING. They are called LIES.
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.
. . . what linux user needs dropbox? Surely they have seen a lack of users.
Transferring files to and from a linux machine is easy - there is no need for a dropbox. There is rsync. There is scp & ftp for basic file transfers. For the well organized, there is git. Not merely syncing, but undo capability as well!
Linux is a server os. When you have it, third-party services is exactly what you have no need for. You can use Linux for desktop work - but when you need a service - you have a capable server os right there. Put it to use - no need to store copies of stuff at third parties who might snoop or might be 'down' now and then.
Strawman... obviously if Dropbox wants to preserve those xattrs they would support it on their end.
But if you're making your own system, where as a client you're sending files to a remote filesystem that doesn't support xattrs, or even if you're uploading them vis a website, you just need a convention for where to put separate files containing the xattrs of the main files. Like how apple file resource streams could be saved as multiple files for storing in a different fs. When you sync the data back you just grab the xattrs from the other location and set them on your file locally. This is not rocket science, it's basic problem solving. Surely there are other ways too, this was just one example.
It saves you from all this. WORA is real. It just works. So use it
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
First of all, dropbox IS NOT DROPPING SUPPORT FOR LINUX. They're just 'standardizing' on a single filesystem.
I have dropbox that I use on linux. A lot of the posters sound like they are not dropbox users. The original post summary *clearly* is not a from a dropbox (or linux??) user because it rails against things that are not actual factors.
Other posters have already covered why the filesystems, window manager, init system, etc., should be irrelevant.
The *issue*, and the likely reason that dropbox is standardizing, is that they want their application to trigger actions when the files are modified, to facilitate syncing files on the local disk with files in their cloud storage, with what you see on your cell phone, with what you see on your windows machine, etc. That dives deeper into the individual filesystems than is ideal. You can either hook into the filesystem so that you get notified when these changes occur, or you can poll the entire archive of Stuff on a regular basis. The former is far more efficient and avoids falling out of sync, the latter is far more portable but causes problems when you're touching files from multiple locations.
My linux system's dropbox is backed on ZFS; I'm concerned that this will stop working, because that's how I like to manage my storage pool. But I'm not so concerned that I plan to jettison dropbox -- they still support linux as well as my other platforms, and allow me to get a lot of my valuable stuff backed up off-site. I just have to move the dropbox filesystem backing to ext4. It's seriously not that big a deal, because the stuff is backed up (in dropbox!) and frankly I can rig a secondary sync with rsync or whatever if I still want ZFS snapshots or something.
Expecting them to support all the filesystems in this way is not sustainable, so cut them a break. They're still supporting linux, and in the meantime maybe they can figure out a better way to do this.
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.
When Nextcloud, Pycharm and Spotify can make snaps to run on every linux distro that supports snapd why can Adobe and Dropbox not do the same ?
Fragmentation into a million and one distro's sure is a problem but docker and snaps are invented to work around that problem.
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.
if you use BTRFS you're a fag
if you encrypt EXT4 you're a fucking cryptard (worse than a furry) storing nothing more than child porn and pictures of all the girls who friendzoned you
dropbox is trying to clean-up the smelly neckbeards, I don't blame them one bit (yes you smell you sausage-fingered fuck)
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.
1) Linux supports many file formats such as vfat, NTFS, etc...
2) Dropbox is trying to scan and mine the data that you are putting on their server/cloud.
3) encrypted data is like any other binary software & you cannot unlock it unless you have the key.
4) If it's not your own account/home then don't hack it and don't come in.
5) How is Dropbox planning on protecting your data that you put on their server/cloud platform, if you don't encrypted it yourself?
6) I put encrypted files attached to my email without the email company giving any grief about it.
7) Something is very wrong with the dropbox business model if they don't allow encryption by the file owner.
8) Many Linux distributions are the same?
* They use the core of the OS called Linux
* Most distribution of Linux use the same or similar graphic User Interface like Ubuntu Gnome, Fedora Gnome, etc
9) The file structure might be a little different but Dropbox app uses a folder in the home directory which is monitored by the Linux Distribution and owner.
10) The person that wrote the article about Linux and Dropbox and different Distro has no clue about the Powered of Linux.
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 Win32 and Win64 APIs change with every release and since Windows 10, you get two releases per yearr. What is worse is that the GUI style changes with every release and to keep up with that requires rather more work than a couple of OS changes.
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.
I had paid for a year of Dropbox for 1TB. Some stuff didn't matter if it was seen by other eyes but there was some stuff that was private and confidential.
I put the private stuff in a cryFS folder and used inotify and rsync to keep it all in sync. Worked great. Loved it.
After hearing about the changes that were coming I emailed Dropbox and it took about 5 emails going back and forth before they finally told me that cryFS will no longer be supported but that I could use LUKS instead.
I don't know why that chapped me but it did. That evening I paid for a life time subscription to pCloud which gives me 500G of storage( which is fine for me)
and they offer a Crypto folder which I will use for my sensitive files. The crypto will run me $5 a month. I liked what I had going on Dropbox but they can go pound it. They are not the only cloud service available. Nighty night bitches.
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.
Linode @5/month for 25gb or so
grsync with cron job
vpn, mail seems to do the trick if you dont have many file needs
Toss a cron job on your windows/mac/linux machines to sync as needed. Maybe use git in place of rsync
It says what everybody already knows: Linux users are not a viable market and it makes no economic sense to waste money in an effort to keep them. Pretty much everybody that matters has left linux fanatics out in the cold. They keep hollering about why they don't need Photoshop, they have GIMP (snicker) and assorted foolishness. Linux nerds are among the very worst scum around, self-entitled and arrogant. And stupid. Who would otherwise turn a simple OS choice into a holy war? Linux on the desktop has been stillborn a long time ago. The industry simply avknowledges that.
If you want an exact, bit-for-bit copy, you simply use exec to run dd. From a device if you have root access, to a file, or vice versa. From a device to another device. From a mount point to a file, whatever.
Just asking.
When all you have is a hammer, every problem starts to look like a thumb.
So return a fucking error on those file systems, not on ones that support them (all the ones mentioned currently work).
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
Explain rsync then please.
Found the systemd developer.
Hi lennart.
0 ;)
Post the code or stfu.
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
BWAHAHAHHAHAAAA! Do you even know any Linux users? I bet you'll say "Me, so your argument is moot". I don't hate to tell ya but, YOU are a cheapskate as well. I have never in my 37 years of computer design seen a Linux diehard be anything but a cheap ass. Your pointing to the TOP500 list supports my claim. The majority of those TOP500 computers are own and ran by government facilities, universities, etc. They HAVE to be cheap because of constantly slashed budgets.
You're a cheap ass and just don't want to admit it. For fuck's sake you rep old ass mopar engines. Talk about cheap garbage...
You are cheap and should feel cheap for being cheap.
OMFG. Today the truth comes out! P5 is a racist prick just like I've been telling everyone for years. I call you a conservatard or a libertardian almost every day but you always go "nuh uh, I'm an independant". You always play the nice guy. I think 2 posts up was the first time I've seen you type a curse word and it was motherfucker! Love it!
You are a racist, sexist, conservatard prick just like I've been telling everyone on /. for the past 5 years. Just because you're "nice" doesn't mean shit. Mike fucking Pence is a prime example of that. You 2 should hang out more.
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!
Ya but apple has made it so crappy as to be unrecognisable and unreliable.
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.
If your application is anything other than a filesystem tool, then it should be filesystem agnostic and should simply use the standard Linux calls to access files.
If your application is anything other than a desktop replacement, then it should use the standard system calls and should be graphics independent.
If your application uses audio - oops, yeah, you're screwed on Linux which AFAIK is still a scrambled mess with no standard OS calls for audio functions that can be used by open source and closed source apps alike. Printing still seems pretty bad too.
I don't see any valid reason why Linux would be a big problem for apps like Photoshop or Dropbox as long as the devs simply followed proper good practice. Now, if you're a crappy coder and you "write" your apps by pasting together lots of other people's code requiring a dozen different programming languages and fifty random libraries from the internet, then you're going to be in support hell as you try to handle all the different distros that each come with a different set of default stuff and at different version numbers. In the pre-internet days when you could not just grab somebody else's code from the web and glue it into your shambolic pile of crap, this was never a problem because applications were written ENTIRELY by the people tasked with writing them and there were no massive pile of install-time dependency resolution requirements.
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
Windows supports FAT, FAT32, exFAT, ISO9660, UDF, NTFS (multiple versions), ...
Same on MacOS
This is a terrible excuse.
Basically if this is your view, you're doing it wrong. You apparently only have MS-trained developers because that is a page out of their book. There are PLENTY of cross-platform libraries to do a simple thing like you want to do with DropBox (rsync comes with every Linux distro and can do it -- and that's just built-in software.)
Ah, good old "extended attributes". Whatever moron thought up that worthless turd should be shot.
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!
Google and Adobe provide repositories and Spotify has a snap.
There are standard interfaces in the Linux kernel and glibc. I fail to see the problem.
Dropbox sold for BILLIONS. They can afford apps.
It is bullshit to portray it as a technical problem.
And the idea of 'a single dev can support multiple but a big company just cannot' is so fucking backward...
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.
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 ?
Is it still the case that dropbox is "totally secure" because they have the keys? And dropbox is still not end-to-end encrypted except by keys they have access to?
So is your dropbox data really just secure from joe hacker and available to dropbox employees and all those with reasonable right to request?
If so why does anybody use this anyway? There are zero-knowledge providers in this space.