Until recently they seemed to be deprioritizing features I cared about in favor of e.g. Paper, which seems designed for some other type of user. So, when my company was choosing a provider I didn't really have any compelling arguments I could make in favor of Dropbox. Maybe this signals that the tide has turned again.
But I've always wondered why they don't expand more on their storage basis for new features? Say email storage and backup (with say an optional web client interface) that supported regular email clients like Thunderbird/Outlook (ok, handwavy magic outlook support). Or a password service that sync'ed via Dropbox (1Passwd was great for a long time this way until I moved to a Linux desktop from a macbook). Their MS Office integrations are actually pretty great. Paper was cute at first, but doesn't build on their storage-first basis by storing say regular markdown files somewhere.
As clumsy as it is, its still great to be able to grab any devce in the world with an internet connection and access all my files in a few mins. Refining that would change the game for this type of service.
I've had good luck with pCloud. In particular, I can exclude file patterns, which has done wonders for my typical workflow (storing lots of code).
The only thing that might bring me back is Zero knowledge privacy. There are smaller competitors that have this as a value add, but I'd trust Dropbox more, since Dropbox is a household name.
Another e2e encrypted storage solution is keybase.io.
"In the context of distributed computer systems, popularly referred to as Cloud-based computing environments, zero knowledge privacy refers to client-server relationships where a server or service is incapable of viewing a client's plain-text data." - cybersecurityforum.com
I have no idea how long they've had this rule, but I'm absolutely certain that I used to sync between more than 3 devices at some time.
I mean, it's kind of Dropbox's thing to be able to do that. Three is also the absolute minimum to make Dropbox Dropbox. If it was two, it'd be a file transfer protocol between two machines. If it was one, it'd be storage.
Sure I'm not a paying customer so I guess they can technically do this ... But to silently downgrade a user's account to what basically amounts to the minimal setting to demo the service, nah that's just shitty. It's just squeezing out my free account to convince me to convert to a paid account.
Which I guess is their right, but the proper decent way to go about that is to make the paid option that much more desirable that you want to convert, not to squeeze out the features of the free users.
Anyone know when this changed? (It could be years, I don't install Dropbox that often)
There's no real justification for outrage over a free product/service. They've paid your cloud storage and associated compute bills, and continue to pay for it, for whatever your usage is - effectively paying you - which should be incentive enough.
VC funded startups have (wrongfully) conditioned users into expecting the moon for $0.
Just flipping the tables a bit - if you ever build your own product/service, wouldn't you want payment for the value it offers to customers?
Sure the UX can be improved a bit, but it's been rock solid so far and gets the job done.
If you’re a designer, we’re also always looking for contributors :) https://nextcloud.com/design/
Plus both my logins seem to be broken now anyway - in different ways. One just straight up refuses my pass manager saved password, the other accepts it then wants a 2FA then proceeds to refuse the password that it initially accepted.
I'll take somewhere else...
If you're saying Dropbox's password store process has been compromised, this would be a big accusation to make with your single data point.
(I'm speaking out of ignorance both on how Dropbox and filesystems work).
> A supported file system is required as Dropbox relies on extended attributes (X-attrs) to identify files in the Dropbox folder and keep them in sync. We will keep supporting only the most common file systems that support X-attrs, so we can ensure stability and a consistent experience. 
Given that extended attributes are available in most of the filesystems used in Linux today, Dropbox still hasn't answered why they decided to go "ext4-only" for a while.
I feel like in open source this tends to work itself out with community patches, but with closed source it can become a real pain.
My point being that the 0.1% of sales might be true per device, but "supporting Linux" might actually bring more revenue than just the devices themselves would indicate because the whole team's revenue would be lost if they didn't support Linux.
Typically Linux support in products like this is organic: It happens when the engineers themselves use Linux and push upwards to support it.
Anyway, with the amount of testing and verification we do on our product, desktop Linux is impractical. We try to verify on as many possible user configurations as possible. (Multiple Windows versions, 32-bit and 64-bit, Multiple Mac versions, remote desktop, ect). Linux is so heterogeneous that we could only really support it if it was a large customer where we targeted their typical configurations.
It's frustrating to me because academia is a major target for Box, and there are many of us linux users here. I wish the university admins that negotiate these deals would consider us.
It also feels like Box has a dismissive attitude towards us. Linux support has been a much requested feature for a long time, for example see this years-long thread: https://community.box.com/t5/Desktop-and-Mobile-Forum/Status.... IIRC mods encouraged people to vote for this feature request in BoxPulse, where it subsequently became one of the highest-voted features, but then labeled WONTFIX. Also annoying that Box supports linux-based Android, and also supported the less-used Windows phone. Yes there are a lot of linux distros out there, but Box could put out a snap, or just target one distro and let the other distros patch for themselves (like Steam does).
Thus, what happens is that so-and-so runs such-and-such which happens to be incompatible because of some whacky configuration alignment that no one considered.
The test matrix then becomes much more complicated than a traditional test matrix targeting common Windows and Mac configurations.
That's fine for expensive software where the end user might have a very close relationship with the vendor, but for "cheap" software the cost of supporting every possible way someone configured their computer is significantly higher than targeting Windows and Mac.
(Otherwise, the Linux version of a program might cost 2-10x what a Windows or Mac version will cost.)
I like to think of desktop Linux as a DIY hobby; but not something that you can expect commercial software vendors to support.
If you are targeting businesses, virtually nobody will run Mandrake (which does not exist anymore), Mandriva, Arch, or whatever. When you target Ubuntu LTS and Red Hat Enterprise Linux, you have probably covered most of the enterprise user base.
This surprises me, because Apple changes and breaks a lot of stuff every macOS release and Apple only supports one or two versions back for security updates. In the meanwhile, RHEL only releases every half-decade or so and supports every release for much longer. Ubuntu LTSes are only released every two years and are then more or less frozen as well.
I like to think of desktop Linux as a DIY hobby; but not something that you can expect commercial software vendors to support.
Except if you care about servers. Or developers for that matter.
Sure, for everyday end users, supporting Linux can be a pain, but if we’re still talking Enterprise, there are only a few distros that would need to be covered.
I don't use desktop Linux myself and I'm not usually a desktop Linux advocate at all, but I know that a lot of developers use desktop Linux professionally for good reason. Public administration in Europe is also very gradually moving towards using more Linux on the desktop (in spite of well publicised setbacks). There is a lot of public pressure in that direction.
Desktop Linux may not be important now, but it probably has more growth potential than anything else. And if it grows even just a little bit, the impact on Windows/Mac-only cloud solutions will be disproportionate. It doesn't take a huge percentage of Linux desktops to make Windows/Mac-only cloud solutions very cumbersome.
I think it's a smart move by Dropbox to occupy that niche now, even if it's loss making. There could even be a bit of a moat, because Microsoft and Google both have reasons (Windows/Chrome OS) to drag their feet.
As a Dropbox competitor I know that you've lost at least a couple of sales because with all the companies I worked thus far the only sync solutions used at the company level are Dropbox and Google Drive. And the later is only used because it's attached to Google Suite, but nobody pays for extra storage.
And all the companies I worked with have some Linux users. And I know, correlation is not causation, but I know that at least one of those companies haven't gone with Box because of missing Linux support.
If you haven't noticed lost sales it might be because companies with Linux users aren't even bothering to check you out.
How would you know if you were?
In which context it might actually be perfectly correct to say that you aren't losing any sales over it, even if there are thousands of users who would use Linux support, were it there.
“The sales team says that's a requirement for the companies they're talking to”
“Competitor X has Linux support and they're growing faster with no other obvious explanation”
I’ve been using Linux for around 25 years, some of that selling commercial software and most buying. There’s a very noisy contingent of the community who make a lot of noise but never actually buy anything. You’ll go broke chasing their feature requests because there’s always one more thing before they can switch.
And yet, there are many open source projects have the scale of a file synchronization tool or larger, that manage to work fine (and run a large battery of tests) across different Linux distributions, BSDs, and macOS.
I don't think it is impractical, it is probably just not a good business case.
(I don't necessarily agree, I think Linux users will typically send more fine-grained and useful bug reports and might help you shake out bugs more quickly.)
But using 'any' as an universal quantification is false, because some users like me are paying for products like pCloud precisely because they support Linux.
I work in a bioinformatics lab, and I access Dropbox through the command prompt and do a lot of file cleanup through scripts for dozens of researchers, which is impossible on Windows or Apple.
This BTRFS reversal last year was a nightmare for everyone's research even though I'm the only one who uses Linux.
Out of curiosity, why is that? macOS does provide a Unix environment and Bash & Zsh shells. (and Homebrew or MacPorts are package managers that can provide updated versions of whatever)
I use Linux because the scripts are easily moved between the cluster computers and my computers, but I suppose YMMV
You’d definitely want to use Hombrew: you can get the GNU utilities instead of the BSD ones Apple tends to ship, at the latest versions, and it’s a single command to update everything.
Or just use Python across all three platforms?
My point was more generally about: surely tools exist on the different operating system to achieve similar outcomes?
Even if they haven't and it's literally 0.1% Linux users, I think that it's unlikely a team will pivot on a sale because of a few users who insist on not using ext4. Instead, those Linux users will probably just end up creating ext4 partitions somewhere so everyone can get on with their jobs.
1. Dropbox isn't just storage. If it was just storage, it would never have taken off. The reason Dropbox makes tons of money is because it's actually selling a process. Still commoditized, but it's not as lightweight as toilet paper.
2. If you feel like creating an ext4 partition is analogous to remodeling your bathroom, I would question where you choose to hold strong opinions.
I think you have your analogy backwards. I'd happily switch out the toilet paper brand (the file system on one partition) in my bathroom (how my team and I manage shared documents) if that's what it takes to make the bathroom fit its purpose.
Besides, Dropbox didn't kill Linux support, they scaled it down to ext4, which is a perfectly inoffensive choice of file system for an end user.
Replacing this functionality on ext4 requires an entire stack of alternatives. Worse if you opt to use zfs and ext 4 you now need 2 complete stacks or to use an inferior set of tools to be compatible with a commodity service.
May be another explanation.
Also the number of bugs that get marked as Won't Fix that are real problems by upstream doesn't help so a lot of people like myself just don't bother after a while and just end up using something else or living with it being broken.
In the end this makes the code more robust for all users, not only Linux users.
Why would it make the code more robust for users on other platforms if they aren't experiencing those bugs?
Is exposing these bugs worth the extra development time? Surely just compiling with a different compiler is as likely to find bug in the compiler.
I am not saying you are wrong but you are making a lot of assumptions.
Because different compilers and different stdlibs do things in subtlety different ways, that may just work on one platform by chance. Memory alignment/layout is often slightly different for example.
Then IO behaviour is often quite different on Linux and OS X despite both being POSIX... (and once you need high performance or Async IO, you're using native APIs anyway).
Memory behaviour is also quite different in terms of buffering, when memory gets freed, etc - e.g. on Linux you often need some malloc_trim(0) calls to actually release recently-free'd memory), on other platforms that's not as necessary, so there are subtleties there.
Different platforms often have different includes as well (on Linux, you generally use GCC's STL/stdlib, on Windows it's a totally different set).
A new compiler / OS update / graphics card driver in the future might trip the bug on the platforms it seems to be working fine on currently.
If Pear OS 8.0 is release a month later and breaks my application because of an API change their end. I would just release 2.0.1 of Music Box that fixes the defects. If I was proactive get hold of a beta or release candidate of Pear OS 8.0 and QA my application on there to see if there was any obvious defects.
The same with a newer compiler or a newer hardware driver. I would just get hold of the beta / release candidate and fix it then. The one thing I wouldn't do is try compiling it on a completely different OS that none of my users use.
Tickets showing actual bugs not tech support requests from people that can't read directions are valuable resources.
Might be fair to note that these numbers are for a video game, not a file syncing app. Linux is relatively new territory there, let's say when Steam started supporting it.
It's great change though for those who are still on Dropbox. Their sync is top-notch.
Not really, occasional merge conflicts are par for the course with Dropbox. Never seen one after switching to Google drive with Insync. Dropbox is very inflexible, for example doesn't even let you choose your own folder name, doesn't work well when syncing across case-sensitive (Linux) and case-insensitive (Windows) file systems. It was a sucky experience overall. I am relieved I don't have to use it at work anymore.
And for what it's worth I've heard that google drive by itself often does the same thing.
My habit, of course, is to gently remind the reader of the existence of rsync.net which, I hope, is the service that perfectly matches your unix/linux use-cases.
But in this comment thread, and to my parent specifically: I am genuinely curious - have you not ever heard of our service ? Very interested to learn this ...
Edit: the platform link is lacking a right margin on mobile, and the landing page’s hero image resizes the page when the URL bar appears/hides, at least on iOS
No I hadn't heard of rsync.net before. I even browsed a few 'listicles' and didn't come across it. I admit even if I had, I'd tend to lean towards more established clouds. But I'll certainly take a peek now since it seems to fit my bill. Thanks for the reminder.
Early winter of this year will mark 18 years that we've been providing cloud storage ... although it wasn't called cloud storage until we created the "rsync.net" corporate entity in 2005 ...
We'll be around if you decide to check us out :)
I tried sparkleshare once but it only syncs to Linux, and you have to set up a sync server
Still rely on Dropbox for file sharing with others though (however, Firefox send is an alternative now)
https://github.com/astrada/google-drive-ocamlfuse is also a good alternative if you're happy with mounting your google drive folder. Gnome now also has pretty well working support for this built in.
In my experience with Insync it crashes a lot and it's very slow compared with Dropbox. And of course they have GDrive's limitations, for example the inability to do block-level sync.
Recommending third party solutions is fine, but can you manage a 300 GB archive of files with them? And can you trust those solutions to not corrupt your data?
I know I wouldn't because I have a hard time trusting the official clients of GDrive or OneDrive after noticing them actually corrupting my data, so no thanks.
As a counter-datapoint, it has never crashed for me and is faster than Dropbox. Though I don't have 300GB files (might explain your crashes and speed issues).
Obviously that's not suitable for everybody for a number of reasons, but for me it's totally erased the appeal dropbox or anything like it.
Their Linux client is great so far in my experience, considering I use it exclusively with Cryptomator (which syncs a lot more individual files).
Which is exactly what prevented me from switching even though I run Linux. I've tried other file synchronization products and the speed was always significantly lower.
I think that’s not only more than acceptable, but at least 10x the performance I’d get from Dropbox.
It appears newer versions of Android do not provide a way for apps to access _external_ storage using ordinary POSIX APIs. SD cards can be used to back and provide "internal storage" on Android, and I don't think that is a problem (yet).
The preferences and configuration panel is not what anyone thinks of when you say "Dropbox" and does not need to be "let's use css/html to create a custom UI that does not conform to the system ux guidelines so we can shove our branding down users' throats," in turn necessitating "now we need to use a full-blown browser engine to render the UI and an always-running standalone web server to interface with the background service to get backup status and information."
I've been using Dropbox since its first public (beta?) release on multiple different platforms, both supported and unsupported. I uninstalled the application three or four days ago when I found that background process lurking on my PC (in addition to the other background Dropbox processes which I did expect to see). If their application is turning into a web app, I can already use my main browser for that.
They were very much aware of their customers. They just didn’t care.
They intentionally decided to break working customer-setups, thinking it was somehow “ok” just because they got a heads-up warning.
Completely disrespectful. I left for Nextcloud, and I’m not coming back.
So for me that means Nextcloud. And that works pretty great too!
Luckily they haven't ported it to Linux yet :)
That is the one new killer feature. Paper and the rest are not interesting to me.
Oh, and they need to turn on full text searching inside files for paid Dropbox Plus accounts. That is a ridiculous crippling.