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.
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.
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...
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.
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.
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.
> 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.
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.
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 :)
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.
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"
My guess: Porting their kernel extension to ARM is not that trivial.
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?
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.
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?
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.:
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.
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 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.
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?
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.
I could really care less, but as a developer I'm not buying a laptop without Vulkan support. It's a little silly that Apple can even market it as 'Pro' without support for the graphics API that pros actually use.
> 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.
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.
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 .
> 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.
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"
That does not change the fact that Dropbox could have made the Mac UI easy to port as soon as it was foreseeable that apple eventually will go arm only. So they had at least 2 years.
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.
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 ?
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.
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.
