That's good news. Happy to see Dropbox thinking about the people who stuck with them from day 1. In the past few years they have been all over the place, trying to find their next big thing and in the process also neglecting their non-enterprise customers. Their core product is still the best in the market and an important alternative to Google.
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.
Exactly, I've always preferred Dropbox because unlike Google Drive, Box, etc they handled files and handled them well. The aesthetics were clean and simple (the new site looks like someone killed an eggplant and based a website on it).
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.
I still think the killer feature that will actually stratify these perfectly similar services will be seamless entire device sync. I have my files clumsily positioned behind my onedrive folder and use shortcuts, but macos insists on the default folder locations for some things.
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.
Just in case you've not thought or knew about it, have you tried using folder symlinks on macOS? Might be an answer to those situations where you have to have files in a special folder or its subfolder, but unfortunately will require setup on each device. On Windows there are different folder symlink types available as well (an `mklink` command line program makes them), plus the common things like documents and pictures are actually "collections" where you can add several folders for the Explorer to combine when viewing these collections
Too late. I already moved to a different service and it was a pain.
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.
Zero knowledge privacy requires a trusted third-party to act as escrow, i.e. to write and distribute the software. Without that, you have no guarantee that the zero knowledge crypto cannot simply be reverted.
Spideroak one. Use them for quite some time... never had any real trouble but I use it more as a backup service tbh. Customer support is pretty good though!
I think Megasync supports this too, and you can sync any files/folders on your machine, not having to be limited to just "the Dropbox/OneDrive/... folder".
"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
A few weeks ago I was setting up my new laptop, and I found out that my (free) Dropbox account had gotten downgraded to only be able to sync between 3 devices ... ?!
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?
It's literally half than Dropbox, which costs €10 per month (so €30 per quarter) in its Plus variant. And that's if you pay per year; monthly payment costs €12 per month.
It's an OpenVZ virtualized VM. I can run whatever I want on it.
I personally do my versioning on my master backup, which has btrfs. Then I ship a copy to the cloud, which is my machine at time4vps.
Yes, my point being that you are comparing a fully-managed service to something which requires you to perform regular operational work. Since the price is the same, that seems like you're effectively valuing your time as free while getting less protection.
Dropbox squandered all their initial goodwill & completely lost sight of what made them appealing in the first place.
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.
Can someone explain to me why the choice of filesystem mattered? I would have thought that Dropbox could exist entirely in userspace with FUSE and wouldn't need anything as low-level as direct filesystem stuff.
(I'm speaking out of ignorance both on how Dropbox and filesystems work).
xattrs was their reason, IIRC (even though other filesystems also support xattrs).
ETA:
> 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. [0]
> The reason cited for this was that "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".
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 think what they may not consider is teams that have a small number of Linux users. In that case, Linux support could be required for the team to use Dropbox, even if the actual number of Linux devices is small.
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.
Doubtful. I work for a major Dropbox competitor and we don't have any Linux support. We aren't loosing any sales over Linux, nor are we under any pressure for Linux support.
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.
Not sure who you work for, but I'm going to talk about Box since that is the competitor I'm familiar with. I'm in academia and to my annoyance have to interact with Box which has no linux support (and has also deprecated existing workarounds like WebDAV).
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).
The problem with supporting Linux, for commercial desktop software, is that it's extremely heterogeneous. Some user might be on Ubuntu, another on Redhat, another on Mandrake; all with very different details.
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.
The problem with supporting Linux, for commercial desktop software, is that it's extremely heterogeneous. Some user might be on Ubuntu, another on Redhat, another on Mandrake; all with very different details.
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.
(Otherwise, the Linux version of a program might cost 2-10x what a Windows or Mac version will cost.)
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.
In an enterprise, even Linux on the desktop is standardized and you’re likely to find that the LTS options (Ubuntu LTS or RHEL) will cover most of the Linux users. And those that aren’t covered are probably used to finding their own way, if given the appropriate tools.
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 like to think of desktop Linux as a DIY hobby; but not something that you can expect commercial software vendors to support.
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.
Yes, I have a "free" "unlimited" Box storage via UChicago but I never think to use it since I'm a Linux user and it's such a pain to use from the browser. Supporting Ubuntu and EL would support the vast majority of users on campus.
As a Linux and MacOS user I would never recommend a solution that does not work on Linux, unless it's effectively a free complement to something else the company is paying for.
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.
In enterprise sales, there's often a huge disconnect between who you're selling to, and who is actually using the product.
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.
This very much depends on the product but note that is exactly why I listed other possibilities. If Linux support was a big opportunity they’d know — maybe not precisely but enough to know it was hurting them.
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.
It's shorthand for, "We might be losing sales, but we assume they're a negligible amount of total potential revenue", which is a fair assumption to make.
Anyway, with the amount of testing and verification we do on our product, desktop Linux is impractical.
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.)
I'm sure you don't lose a significant number of sales over Linux. The number of sales could probably be smaller than statistical error, and I think your company made the right decision.
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.
Yes, this. I often have this same conversation with restaurants who don’t have gluten free options. You certainly aren’t obligated to do so, but if you don’t have any and there is a single person in our dinner group who needs them...our entire group goes elsewhere.
While this is true, I think a more subtle reason to support Linux is the open-source scripts devs setup that may be mission critical.
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 suppose it's possible in the sense that anything is possible. But, in my experience, Mac versions of Linux tools are not A) Posix compliant, B) outdated, C) don't have the exact same functionality, and/or D) Abandoned.
I use Linux because the scripts are easily moved between the cluster computers and my computers, but I suppose YMMV
> But, in my experience, Mac versions of Linux tools are not A) Posix compliant, B) outdated, C) don't have the exact same functionality, and/or D) Abandoned.
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.
Honestly it's not really feasible to use Python when basic Linux tools like comm, or dos2linux, which take literally just a few characters, recreating the functionality in Python would be a headache.
Yep, I am not a user of any of these services yet... but if I did go with one it would definitely require linux support and knowing I can trust the company wouldn't screw me. Just because the current sales are low does not mean there's no ability to make good future sales.
On the one hand, that might be true, but I doubt that it's true enough in practice. Presuming competent PM's and data analysts, they've likely accounted for individuals vs. teams to begin with.
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.
Storage is a commodity like toilet paper. If your preferred brand of toilet paper required you to remodel your bathroom would you do so or buy different toilet paper?
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.
Zfs has a lot of features over ext4 its not remotely equivalent.
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.
I would beg to differ. There are a lot of people / kids using it that don't really understand what is going on under the hood.
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.
yet another explanation may be the fractured nature of the eco system. Every time I look at linux software bug trackers a good portion is distro related.
Multiplatform code when tested tends to show more bugs than single platform code. Also, using different compilers (when it is possible) will help find obscure but real bugs.
In the end this makes the code more robust for all users, not only Linux users.
This has been my experience as well writing cross-platform software (some of it proprietary in the past).
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).
Particularly around alignment - it could be that your compiler is emitting instructions that can deal with it, but in a sub-optimal way such that there is a performance penalty. On other platforms, that sort of behavior may cause a compilation failure, or the bugs they cause create bigger (and more noticeable) issues.
I understand this. Think more along the lines of "If a tree falls down in a forest, does it make any sound if there is nobody there to hear it?". If there is a defect on Linux, but nobody is running it on Linux, is there really a defect?
It's quite possibly a silent bug on the other platforms as well (i.e. relying on undefined or compiler-defined behaviour that just happens to work currently).
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.
Lets pretend a few things, because I don't think you understand what I am getting at. I have application called "Music Box", I am release version 2.0.0 and it is QA'd before release against Pear OS 7.0.
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.
> Relevant discussion: “Linux users were only 0.1% of sales but 20% of crashes and tickets”[1]
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.
I wish it worked it self out with community patches - more likely is a github mega issue, with people suggesting their forks as solutions if the original maintainer doesn't reply for 24 hours, or during the UTC+8 9am-5pm window.
Too late. I have left Dropbox because of their stance on Linux filesystems, price bump with unnecessary features, and the continuous badgering to upgrade to Dropbox business.
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.
Same. Inertia kept me with Dropbox all these years. It was easier to pay them than to figure out how to operate the alternatives. I'm not going to get those hours I spent migrating back--it's sunk cost now.
I'm also a Dropbox on Linux user, are there other cloud storage services with better Linux client support? I was considering Google Drive but it doesn't seem to support Linux at all.
"are there other cloud storage services with better Linux client support?"
My habit, of course, is to gently remind the reader of the existence of rsync.net[1][2][3] 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.
"I admit even if I had, I'd tend to lean towards more established clouds."
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 ...
I’m using syncthing for file sync, and testing out spideroak for backup (plus just a hard drive locally). I like the idea of spideroak because it’s e2e encrypted, or so I understand, and syncthing has just worked decently well the last few years.
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)
I'm using Google drive with insync which is really good but not free.
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.
Many people recommend Insync and while it may be good enough for people stuck with Google Drive on Linux, it doesn't match Dropbox's sync.
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.
> In my experience with Insync it crashes a lot and it's very slow compared with Dropbox.
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).
GVFS (https://wiki.gnome.org/Projects/gvfs/backends) now provides a package that lets you log in to your Google Drive account and access it from Nautilus, but you have to be on GNOME for it.
This is very cool and I use it from time to time, but it's not actually keeping anything synced afaik (it's equivalent to the web ui, but very nicely integrated in gnome).
Do you need it to be a commercial service? I just use nfs over wireguard, hosted at home on some old hardware I already had. Total cost: $0 Setup took no more than a few minutes.
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.
I also went with OneDrive--mostly because I hadn't realized how substantially superior OneDrive has become compared to Dropbox on Windows (particularly with selective sync).
I've had good luck with pCloud on linux. And you can exclude file patterns, which has been a big improvement for storing my code (ignore all node_modules directories).
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.
What did you move to? I like Dropbox I just find it crazy that they (or no other company AFAIK) allows me to sync folders on my SD-card on my Android phone.
syncthing is a great choice, I've been happily using it for 2 or 3 years across Linux, Android, and Windows. I've never had to do anything special to use an SD card on Android.
> I've never had to do anything special to use an SD card on Android.
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).
I used Nextcloud/Owncloud in the past, but it's a mediocre product from an engineering perspective. I've found several bugs, the most ridiculous of which was to get a conflict on a file... while using only one client.
though nextcloud definitely is a lot more than: "a folder to sync your files". but hey, apparently even VC in search of growth sometimes notices that their path is not the best.
Google basically made it impossible for file syncing software to work on SD cards in modern versions of Android (IIRC since Marshmallow or maybe Nougat) unless you use the 'SD as internal storage' option which many manufacturers have disabled entirely.
Yep. I removed them from my life after the 3 device limit and will.nit fo back. I will give a few bucks to Apple, Google and Microsoft for their file services for a while as I decide which one I like best.
And now Dropbox runs a background web server so they can serve their web-based UI, at least on Windows. I can’t believe how none of these huge companies that burn through cash like there is no tomorrow can’t afford to pay an intern to write an easy-to-maintain native UI for these simple “dashboard” applications. Ugh.
What makes you think an intern would be able to do this? A few of them might, but I imagine most wouldn't. Being able to make something easy to maintain means knowing what is difficult to maintain. Except for the sharpest, who actively learn from others, the best teacher is experience.
I fully intended that as hyperbole, but the idea was "use ready-to-use native widgets/controls to represent options/state" with as little "custom" UX as possible. The user-visible Dropbox UI is nothing more than a preferences dialog, the real "app" can be written by experts with 30 years of service and systems software expertise under their belts: it runs as an invisible background service using APIs for which well-supported cross-platform abstractions are readily available for all non-interpreted (and most interpreted) languages (inotify, channels, network io, encryption, compression, database serialization, etc).
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.
What a mess. Product mistakes like this generally show that the company is either desperate, or unaware of their customers.
I use xfs on Arch, and dumped Dropbox for Google Drive (with Insync) the second they made this announcement. It would be a pain to migrate back, so I won't.
I use Arch too, with BTRFS, but made a mounted sparse file for Dropbox, which has been an utter nightmare setting up on all my computers. I'm tempted to just keep it in case they reverse course again.
I realize there’s a lot of speculation happening here, but as a long time (since beta) user who was not looking forward to moving because of the plummeting Linux support...Thank You.
Also too late here. As a big fan I was bummed to be forced to leave the free plan. This and the 3 device limit were a deal breaker. Now I'm onto syncthing and keybase FS.
To compensate for supporting more filesystems on Linux, they are now switching to a file manager-like application instead of the unobtrusive just-sync current option:
Interesting. I absolutely love DB sync on Linux, but I cleared my data yesterday. I got tired of dealing with the ecryptfs situation and couldn't go all in on DB because of the 2TB cap. I ended up going with Amazon Drive plus ExpanDrive for now.
Seems to be working just fine on the eCryptFS setup I have on an older laptop (which I stopped using a few months back). All we need now are ARM versions of the client.
