Dropbox Sync does not natively support Apple Silicon(dropboxforum.com)
dropboxforum.com
Dropbox Sync does not natively support Apple Silicon
https://www.dropboxforum.com/t5/Dropbox-ideas/Apple-Silicon-M1-Desktop-Sync-Compatibility/idi-p/527743/page/18#comments
84 comments
I'm a tad confused. I use Dropbox on Linux and it works fine. Is there something I'm missing?
This feature is not available on Linux: https://www.dropbox.com/en/smart-sync
This is a support person that probably's not that familiar with Dropbox's technical and management roadmap.
Not having Apple Silicon support means that they're effectively telling everyone "we won't support Macs" in 5 years.
Apple will kill Rosetta 2 at some point, just like they did with Rosetta 1 and my bet is sooner rather than later.
If Dropbox doesn't support Macs, they seem to think that the work to bring Dropbox to Apple Silicon will be more expensive than the revenue they get from Mac users.
With all that - Dropbox does have some technical issues at the kernel layer that they need to address with Apple and that's also something that a support person can't really know.
Not having Apple Silicon support means that they're effectively telling everyone "we won't support Macs" in 5 years.
Apple will kill Rosetta 2 at some point, just like they did with Rosetta 1 and my bet is sooner rather than later.
If Dropbox doesn't support Macs, they seem to think that the work to bring Dropbox to Apple Silicon will be more expensive than the revenue they get from Mac users.
With all that - Dropbox does have some technical issues at the kernel layer that they need to address with Apple and that's also something that a support person can't really know.
>Apple will kill Rosetta 2 at some point, just like they did with Rosetta 1 and my bet is sooner rather than later.
The original version of Rosetta was based on QuickTransit and licensed from Transitive, so Apple paid for every version of MacOS that included it.
This version of Rosetta was created in-house instead of licensed from a third party, so there is no cost benefit to dropping it quickly.
The original version of Rosetta was based on QuickTransit and licensed from Transitive, so Apple paid for every version of MacOS that included it.
This version of Rosetta was created in-house instead of licensed from a third party, so there is no cost benefit to dropping it quickly.
> Dropbox currently supports Apple M1 through Rosetta. We have an internal build for native Apple M1 support, which we're currently testing and we’re committed to releasing in the first half of 2022. While we regularly ask for customer feedback and input on new products or features, this should not have been one of those instances.
source: https://www.dropboxforum.com/t5/Dropbox-ideas/Apple-Silicon-...
Does anybody really believe this?
source: https://www.dropboxforum.com/t5/Dropbox-ideas/Apple-Silicon-...
Does anybody really believe this?
I think this has been reposted several times within the last 24 hours:
https://news.ycombinator.com/item?id=29017086
https://news.ycombinator.com/item?id=29025027
https://news.ycombinator.com/item?id=29026270
https://news.ycombinator.com/item?id=29018650
https://news.ycombinator.com/item?id=29017086
https://news.ycombinator.com/item?id=29025027
https://news.ycombinator.com/item?id=29026270
https://news.ycombinator.com/item?id=29018650
My experience in the past has been that HN de-dupes links on submission. Perhaps that is not the case.
Who cares? For a Linux user, you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem. From Windows or Mac, this FTP account could be accessed through built-in software.
For people who might miss that this is basically a HN copy-pasta at this point: https://news.ycombinator.com/item?id=9224 - April 5, 2007
In general, not sure if we should keep posting this about every Dropbox mention. Comments like this is hardly intellectually stimulating and might fit better at Reddit rather than HN.
In general, not sure if we should keep posting this about every Dropbox mention. Comments like this is hardly intellectually stimulating and might fit better at Reddit rather than HN.
> intellectually stimulating
This 'news' isn't either, yet it keeps getting posted without moderation. I think it's better left in the Dropbox forums.
This 'news' isn't either, yet it keeps getting posted without moderation. I think it's better left in the Dropbox forums.
Right.
Enterprise software doesn't support feature X.
User requests feature X, gets told no.
User posts to a news site, to try and get more votes for feature X.
Enterprise software doesn't support feature X.
User requests feature X, gets told no.
User posts to a news site, to try and get more votes for feature X.
I think it’s a good example for people who haven’t seen it before.
Agreed, I hadn't seen anything on this subject before and wasn't aware it was a copypasta response. I get that hn doesn't want to turn into the cesspool of inside jokes that reddit has become, but a quick jab like this here and there never hurts, imo
I think it's a great reminder that 99% of these startups are really just scaled versions of free technology you already have. Maybe it's a little grating to hear if you're a Dropbox founder, but FTP is natively supported on Apple Silicon while Dropbox is not...
> these startups are really just scaled versions of free technology you already have
Dropbox clearly has a lot more going for it than "it's managed FTP!"
Dropbox clearly has a lot more going for it than "it's managed FTP!"
I agree. It was funny once or twice, but at this point I'd rather not see comments like the parent comment on hacker news.
‘In jokes’ or ‘running jokes’ can be quite valuable as part of a shared culture, for a sense of belonging.
I smiled.
I smiled.
That the GP post wasn't anihilated with downvotes is a great example of the continued memefication/ redditfication of HN. And this is a sad trend.
This is ridiculous. The features and interface dropbox offers are so far beyond the “solution” outlined here. And it is relevant that this stuff doesn’t work natively on Apple‘s new silicon. Because it kills the battery if it has to go through the Rosetta translation layer. The point here is that you have a public tech company that has one job, which is to support consumer cloud storage, and a big chunk of that consumer base is running on apple silicon, and their response is acting like they have no reasonable priority or responsibility to port to Apple silicon, despite that it has been out for one year and the interim solution is just that: a temporary, interim Rosetta translation.
> a big chunk of that consumer base is running on apple silicon
Here I was thinking that most Dropbox customers (at least the ones that pay big money) were on Windows, but maybe I'm wrong. Since you seem to have insights into Dropbox's userbase, could you share the raw numbers you're sitting on? Percentage wise of course.
Here I was thinking that most Dropbox customers (at least the ones that pay big money) were on Windows, but maybe I'm wrong. Since you seem to have insights into Dropbox's userbase, could you share the raw numbers you're sitting on? Percentage wise of course.
I don’t know what the numbers are, but most Mac users I personally know are using the service. Although I suspect that’s going to change, at least in my own personal case, if they don’t get this resolved.
Seems to be a huge leap to go from "Most people I know use Dropbox" to "Big chunk of their customer base is macOS", when you have zero insight into Dropbox.
And an even bigger leap through those macOS users being specifically on Apple Silicon.
It’s not a leap. The Mac is a major platform, and Apple silicon is soon to be the only Mac platform. All the other cloud storage providers in this service space are offering support for Apple silicon.
Now is it as significant as windows users? I’m sure it is not. But it seems silly that a major tech company would just dismiss it altogether.
Now is it as significant as windows users? I’m sure it is not. But it seems silly that a major tech company would just dismiss it altogether.
> The Mac is a major platform, and Apple silicon is soon to be the only Mac platform
Macs are ~15% of the market, and Apple silicon is a subgroup of that which will gradually increase until it makes up virtually the whole group over a timespan of several years (basically, how long do people keep machines running). It will never be the only mac platform unless you mean supported platform, which will still take quite a few years.
So no: Macs, and Macs on Apple silicon, are a part of the market, but they're a fraction and a fraction of a fraction.
Macs are ~15% of the market, and Apple silicon is a subgroup of that which will gradually increase until it makes up virtually the whole group over a timespan of several years (basically, how long do people keep machines running). It will never be the only mac platform unless you mean supported platform, which will still take quite a few years.
So no: Macs, and Macs on Apple silicon, are a part of the market, but they're a fraction and a fraction of a fraction.
> The Mac is a major platform
In some places. In others no. Depends on the industry really, and country.
> But it seems silly that a major tech company would just dismiss it altogether
We don't know how Dropbox's userbase looks like. If most of their profits come from large enterprises on Windows, then they will focus on those users mostly, since Dropbox is a company and companies always (most of the time) just follow the money.
In some places. In others no. Depends on the industry really, and country.
> But it seems silly that a major tech company would just dismiss it altogether
We don't know how Dropbox's userbase looks like. If most of their profits come from large enterprises on Windows, then they will focus on those users mostly, since Dropbox is a company and companies always (most of the time) just follow the money.
Note that you have now shifted the goal post to the future tense :/. The reality is that Apple Silicon only started shipping only in a subset of Apple laptops... they currently--which is all that matters, as in the future Dropbox isn't somehow prevented from compiling their software to be "native" Apple Silicon if that somehow actually matters in an important way--aren't a big chunk of anything, including macOS users.
> The reality is that Apple Silicon only started shipping only in a subset of Apple laptops...
Well, more than that. They recently discontinued intel MacBooks, entirely.
Well, more than that. They recently discontinued intel MacBooks, entirely.
[deleted]
Such a classic response hahaha
He's never going to live past this moment is he
I would hate for this to be my legacy.
Part of it's enduring quality is how we can all relate to being so retrospectively wrong like this (I know I can! A/B tests are a constant reminder). I think bringing it up now and then is a gentle reminder to keep a positive community :)
Part of it's enduring quality is how we can all relate to being so retrospectively wrong like this (I know I can! A/B tests are a constant reminder). I think bringing it up now and then is a gentle reminder to keep a positive community :)
[deleted]
[deleted]
This is a ridiculously simplistic view of things, to the point where it's not really worth any merit.
Mounting (s)ftp(s) and using it as a local folder does some things, but fails at the basics. Eg, if I upload a 50gb file (and actually manage to get it to upload all the way without crashing), how can I checksum verify what I uploaded without it costing me 50gb in downloading and time?
There's plenty more edgecases, but suffice to say, there's a reason why tools like rclone & rsync exist - copy and paste does not cut it for a lot of uses, especially when mixing large files, remote servers and (even good) internet connections.
Mounting (s)ftp(s) and using it as a local folder does some things, but fails at the basics. Eg, if I upload a 50gb file (and actually manage to get it to upload all the way without crashing), how can I checksum verify what I uploaded without it costing me 50gb in downloading and time?
There's plenty more edgecases, but suffice to say, there's a reason why tools like rclone & rsync exist - copy and paste does not cut it for a lot of uses, especially when mixing large files, remote servers and (even good) internet connections.
While you missed the joke, rclone and rsync are nice.
I totally missed the sarcasm - sorry, I'm far more used to it on other platforms than here. I also spent a few days fighting with <cloud storage provider> uploads from our NAS recently, so I'm a little bitter ;)
bravo, we should start a similar copypasta with Android users since many talk like that too, except it ends with their phone exploding when they try it
This reminds me of an old episode of The Screen Savers where RMS was interviewed. This was when BitKeeper was very popular, but not yet open source, and Git did not exist. RMS was questioned about this and his immediate response was "just use UUCP"
Stupid, out of touch, unrealistic.
Stupid, out of touch, unrealistic.
When I get my first M1 mac tomorrow I think I'm going to try using Maestral as my dropbox client. Does anyone else have experience using this and what are your thoughts?
[0] https://maestral.app/
[0] https://maestral.app/
I did the same and it is working fine. There’s just 3 things that are missing in maestral if you don‘t care for the productivity stuff like comments etc.:
1) No overlay icons in the finder (see https://github.com/SamSchott/maestral/issues/443)
2) No incremental sync for large files where just a few blocks change (the API does not provide this)
3) No support for extended file attributes (so you cannot sync .app bundles)
1) No overlay icons in the finder (see https://github.com/SamSchott/maestral/issues/443)
2) No incremental sync for large files where just a few blocks change (the API does not provide this)
3) No support for extended file attributes (so you cannot sync .app bundles)
Does it use the file provider api or something similar? Or does it just download everything whenever it changes?
Using it and it works quite well. No issues so far.
Same. Very lightweight, does its job.
This and the (apparent) issues with running React Native SDK on the new Apple chips are very concerning. I have a few weeks until mine is delivered but I’m hoping these things are resolved by then.
Is there a list of major devtools not functional on Apple Silicon?
Is there a list of major devtools not functional on Apple Silicon?
Not sure why people are downvoting you for a completely legitimate question. There is a list of apps that are not ready for Apple silicon[0], and probably quite a few more that I'm not aware of.
[0] https://isapplesiliconready.com/for/developer
[0] https://isapplesiliconready.com/for/developer
why do commercial software vendors even have a delay with this kind of thing? I would assume software written in C which isn't doing any dark magic with opcodes can normally just be compiled to the new platform without any major hurdles? or is there some kind of "dropbox has to pay Apple huge license fee for X" kind of thing going on ?
Some potential answers:
* Original programmer has since moved on, and as per industry standard there was no hand-off and code is poorly documented
* The team in charge of this is busy delivering features/fixing bugs for whale clients
* The product organisation down prioritizes it because the PM wants to build a shiny thing that gets them promoted
* Original programmer has since moved on, and as per industry standard there was no hand-off and code is poorly documented
* The team in charge of this is busy delivering features/fixing bugs for whale clients
* The product organisation down prioritizes it because the PM wants to build a shiny thing that gets them promoted
The short, simple answer is that pretty much every successful business has a combination of a shortage of technical resources and a priority list of things that matter to their customers. Some initiatives just don't get top priority at a given point in time. I can totally see why Dropbox might not prioritize this work right now because as of this moment, the client works as-is on M1 Macs.
Dependencies also are not migrated instantly or abandoned and they don't compile cleanly on new architecture.
Especially closed source tracking libraries from all over.
Especially closed source tracking libraries from all over.
They may be considering whether they should have separate downloads or a smart installer/runtime that figures out what to install/run for MacOS. Separate downloads would be close(ish) to what you're describing, but would drive support issues for some users. A smart installer would be new code, maybe.
The simple fact is that, unsurprisingly, a lot of devs don't care. Apple can lead a horse to water, but they ultimately can't make them drink. By chasing such a radical paradigm shift with their new computers, there are inevitably going to be developers who get thrown under the bus without chance for recourse. Look at Valve's Proton project, which was intended to support MacOS just as well as Linux for near-perfect translation of DirectX games. When they started transitioning to ARM, they threw away so many system-side libraries and OS interfaces that Valve simply had to scrap the version altogether, since the amount of work required to get it working on Mac would be astronomically higher than the effort it takes to maintain it on Linux.
I'm trying to remain impartial here, but so long as the majority of the desktop market share stays on x86, there won't really be much financial incentive for developers to port things to ARM. We had the same issue a decade ago when the Raspberry Pi hit markets, with hardly enough software to get it running desktop Linux. Fast forward to today, and people still don't really care all that much.
I'm trying to remain impartial here, but so long as the majority of the desktop market share stays on x86, there won't really be much financial incentive for developers to port things to ARM. We had the same issue a decade ago when the Raspberry Pi hit markets, with hardly enough software to get it running desktop Linux. Fast forward to today, and people still don't really care all that much.
I’m curious as to what the data actually shows about the client “annihilating the battery” when run under Rosetta translation, as opposed to a mere unsupported declaration/assumption that it does.
I've been running it on an M1 for quite a while now. At least while it's mostly idle I haven't noticed any effect on the battery. If you do a lot of syncing every day you might see more of an effect I guess.
s/Apple Silicon/ARMv8 AArch64/
A lot of times it is due to direct or indirect dependencies. Before the M1 there weren't many ARMv8 AArch64 users. Only a couple of distros starting providing ARMv8 AArch recently and even then not a lot of their packages could be built for that target.
A lot of times it is due to direct or indirect dependencies. Before the M1 there weren't many ARMv8 AArch64 users. Only a couple of distros starting providing ARMv8 AArch recently and even then not a lot of their packages could be built for that target.
Not the same thing. Apple uses a different calling convention, so code compiled for Linux AArch64 is not equivalent to code compiled for Apple "arm64".
Yeah, x86 is infamous for having a single, unique and consistent calling convention.
I guess Ryzen should be called "AMD Silicon" instead and any binary not compiled with at least `-march=znver1` features should be considered "Not having native support of AMD Silicon"
I guess Ryzen should be called "AMD Silicon" instead and any binary not compiled with at least `-march=znver1` features should be considered "Not having native support of AMD Silicon"
Wait, is that a CPU difference or OS difference? I though calling convention was set by kernel, not ISA.
[deleted]
The Dropbox client exists for iOS and writings were on the wall that macs would switch to arm. This is simply a sign of wrong priorities.
I started using MountainDuck and use Backblaze B2 as a storage provider. It helps me keep some stuff locally(and synced to B2) while other stuff only on B2 with the ability to simply pull down on demand. So far, it’s been great. Although I’m still on intel Mac. Don’t know whether they support M1 yet. Looks like they do.
https://mountainduck.io/
https://mountainduck.io/
No M1 for MountainDuck yet..
It wasn't that long ago that the dropbox sync client was python. So, still odd, but I am curious how much of an effect dropbox sync running on rosetta has.
I'm confused, because I have Dropbox installed on my m1 Mac and it works fine. Is Rosetta that transparent that I just didn't notice?
For something that only has to Sync files do I really need the full power of an m1 processor. Even if it's running slower by the emulation layer, I was not able to notice anything. I even did a bit of stress testing where I was editing a text file in two places at once to see what happened, and Dropbox synced everything within seconds.
For something that only has to Sync files do I really need the full power of an m1 processor. Even if it's running slower by the emulation layer, I was not able to notice anything. I even did a bit of stress testing where I was editing a text file in two places at once to see what happened, and Dropbox synced everything within seconds.
> Is Rosetta that transparent that I just didn't notice?
Yes! It’s 100% Intel code being emulated or transcribed. You can see which is which in your Activity Monitor.
Yes! It’s 100% Intel code being emulated or transcribed. You can see which is which in your Activity Monitor.
So would it be possible to fully emulate 64 bit Windows.
I really want the new M1 pro, but I'd really like to keep Microsoft Game pass as that's where I do most of my gaming. I need local game installs, while browser streaming is amazing it's not the same .
I really want the new M1 pro, but I'd really like to keep Microsoft Game pass as that's where I do most of my gaming. I need local game installs, while browser streaming is amazing it's not the same .
You can run ARM Windows in a VM, and Windows has an interpretation layer for x86 built-in. I think it's 32-bit only though, if I recall correctly.
They introduced x64 64 bit emulation in the Dev channel several months ago, but it didn't work well at all.
It also was more performant running in a VM on last year's MacBook Air than running natively on Microsoft's flagship hardware.
https://www.youtube.com/watch?v=OhESSZIXvCA
It also was more performant running in a VM on last year's MacBook Air than running natively on Microsoft's flagship hardware.
https://www.youtube.com/watch?v=OhESSZIXvCA
> Is Rosetta that transparent that I just didn't notice?
In my experience: yes. Photoshop under Rosetta (before their Apple Silicon release) was faster on my M1 than it was on my old 2016 MBP, despite the emulation.
In my experience: yes. Photoshop under Rosetta (before their Apple Silicon release) was faster on my M1 than it was on my old 2016 MBP, despite the emulation.
M1 hardware is just incredible.
> Is Rosetta that transparent that I just didn't notice?
Yes, this is such a non-issue.
Yes, this is such a non-issue.
If you have large Dropbox folder (lots of files, like tens or hundreds of thousands) it can use significant amount of CPU.
Issue is not the sync speed, but general use of resources.
Issue is not the sync speed, but general use of resources.
Looking for a Dropbox alternative? We were M1 native at launch (https://www.Sync.com).
I used to be a paying customer of Sync and hated every single thing about it I'm afraid. The web interface was so painfully slow to use that a simple file share task would take 10 minutes of waiting for things to load or, as was most often the case, fail to load.
Exchanging a problem for another. SyncThing ( https://syncthing.net/ ) is the definitive solution: free software, peer to peer and no data leaking anywhere.
They were one of the first who offered these 0-byte placeholders, and they rely on a kernel driver, which is only available on both Windows and macOS (but not Linux).
OneDrive [0] and Box [1] are moving away from their implementations and switching to Apple's File Provider API. Their motive might be less development effort, and the official API might be good enough. Still, I wonder whether the deprecation of 3rd party kernel extensions might also be a reason to switch to such a "thin client".
Interestingly, Apple did something similar on Windows [2]: They are now using Microsoft's OneDrive implementation for their iCloud file sync client.
Now I am wondering what Dropbox will do. Is maintaining their kernel extension still feasible on macOS?
[0] https://techcommunity.microsoft.com/t5/microsoft-onedrive-bl...
[1] https://blog.box.com/get-more-secure-seamless-box-drive-expe...
[2] https://blogs.windows.com/windowsexperience/2019/06/11/apple...