Thanks for that! I know what’s going on loop for the next few days (at least). Already had a fair few in my library but having the collection there as a playlist is awesome.
Wow that second link ("Reminiscences of the VLSI Revolution") turned out to be a 29 page rabbit hole providing a fantastic glimpse into the history and early days of chip design and engineering, thanks a lot for posting that! Here's a direct link to the PDF: https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.69...
A while ago I was picking a new SSG and I would have preferred something written in Python so I can hack on it more easily. I ended up moving on because of the license.
Thanks for educating me - I did not know about this.
Not sure I see it as a problem, though. I'm producing static files, and uploading them to a web server. At no point is a user communicating with the program - which I think is the key clause that triggers the AGPL. The whole discussion about templates being treated as code is enlightening - but again: No user is communicating with the templates either.
Furthermore, even if I'm wrong on this, I don't see the leap that the content of the blog has to be AGPL. At worst, I'd merely have to release my templates and any other modifications I've made to the code (custom plugins, etc).
Things like "not sure" and "I think" and "even if I'm wrong" suggests that it is not very clear what is covered and what isn't. A lawyer would probably have to sort that out.
The practical problem is that some organizations simply discourage or don't allow the use of GPLv3 or AGPL software. I don't want to learn one tool for personal projects and another for potential work projects, in case the opportunity comes up.
The easiest way to deal with that is to just switch to a tool that has a license that is more widely accepted.
> Things like "not sure" and "I think" and "even if I'm wrong" suggests that it is not very clear what is covered and what isn't.
No - it suggests that I'm not a lawyer. I would use those phrases for any license.
Let me put it concretely. Had I read the AGPL, I would have concluded that there is no problem in this use case - just as I would with the GPL or any permissive license. It's only because others disagree, for reasons that seem faulty to me, that I hesitate. Frankly, for me, this is a good example of (unintentional) FUD.
> The practical problem is that some organizations simply discourage or don't allow the use of GPLv3 or AGPL software.
I thought the issue was GPL vs AGPL. If you're avoiding GPL, then it makes it more understandable. In any case, I use it for personal reasons. Were I considering it for our work, we would consult with our lawyers (have done so in the past) - regardless of the license. My work does not involve the web, so I don't have the concern of having to learn two different tools.
That brings back fond memories. I used to package up a PHP installer (and a MySQL one) for macOS for many years, back when OS X was still new and it was a bit of work to build various UNIX open source projects from source.
My day job was Solaris/Linux work so I was used to it and I wanted PHP on my Mac, so I built the installer for myself and also put it on my website, where more and more people downloaded it from over the years.
I haven't used PHP in more than ten years and only recently started dabbling with web development again for fun. I am very happy with TypeScript + React on the client side and Python or Swift on the server side.
I found the first part, on regular expressions really excellent (though the accelerated pace made it difficult to fully grasp all the proofs). He's a still-enthused expert.
However, he didn't seem as passionate on the second part, decision languages. It's also a lot harder, yet is squeezed into even less time.
To help you assess my observation: I scored in the highest segment (IIRC 95%)... After taking the course, I would say I understand the regular expressions material fully, but not decision languages. I'm still confused about showing what complexity class something is in. e.g. the complexity class of determinng two polynomials are equivalent (PIT), like x(1 + y) + y and x + (x + 1)y.
I'm curious, do you know what scooter model Skip uses in SF? I've also seen Bird use it in San Jose and possibly elsewhere. It has a Segway label.
That model is fantastic. Very pleasant brake, and it is much more powerful than the one Scoot uses. The Segway one gets me up some of the hills in SF, whereas the Scoot one is woefully underpowered, a joke for a hilly city like SF.
They are decent scooters but I wish they had suspension + pneumatic tires. I still find the retail M365 to be much more pleasant to ride.
I actually fell pretty hard from a Skip scooter going slightly downhill in SF because their active breaking gave up on me while going downhill (maybe 20deg angle, not even too steep) I could have dealt with that but even worse it would keep turning itself on and off so the traction would keep changing, because the power connection must have been loose (or battery too low -- this was before they started warning you about a low battery on the app) or something.
They did at least add that battery warning, though. That was an important update.
New Zealand's Baldwin Street [2] is the world's steepest residential street, according to Guinness World Records, with a slope of 19°.
San Francisco's Filbert Street has a gradient of 17.5° [3] and that's that's steep enough that it has steps.
Of course, a road can be "very steep" and "normal for SF" at the same time! IMHO even if a road is very steep, if you're hiring scooters in a city the brakes (and geometry) should be good enough that an average rider can safely descend the city's steepest roads.
I've been a Dropbox user for many years but I'm looking for a replacement. What drives me nuts and hasn't gotten better over the years is their truly awful Python-based macOS client software.
It is constantly burning a ton of CPU/battery. It's always at or near the top of Activity Monitor's list in the Energy tab. It seems like their app constantly reacts to any file system activity, even if that activity is outside the Dropbox directory. My file system is busy all day long from building in Xcode and other things.
What I need is for Dropbox to improve that by making an efficient, battery-saving, native macOS client. What I don't need is what is announced in this post.
The two other things that I hate are the fact that they don't support symlinks and that they use a kernel extension. All of these things together made me start the search for a replacement.
Does anybody know how the CPU/power impact of Microsoft's and Google's offerings are on the Mac?
After receiving an email like:
> This is all for just $20.88 more a year
1. I never asked for anything more 2. you still charge me for more at a higher price
I just bought 2TB data on iCloud, moving everything there. Now I will have good photo application with face recognition which is awesome. Do not expect any move from Dropbox to make your personal life better, they won't. They are going towards enterprise customers.
I self-hosted a Nextcloud installation and used 2x 4TB drives. The first is full dedicated to the Nextcloud use while the second is rsync-ed to the first every night. Then I deleted my 8 years old Dropbox account. Currently my only cloud provider is iCloud just for the photos, contacts, iwhatever backup.
This is a timely post. I just set up NextCloud myself, to sync my external HDD to my own managed cloud storage service. I've got NextCloud running on a VPS, and linked to a series of storage buckets on Wasabi.
Sometimes all I want is a quick and easy replication of local data to an off site storage facility, and also an easy way to share links with third parties who need access to certain stuff. I am getting tired of storage providers who started off by doing these two things really well, but then decided they wanted to add a ton of bells and whistles that are really of no value to me as a user.
(To be fair, I think Box.Net is the only cloud storage provider I've used over the past decade that still retains their original premise).
It's been a stupid decision at the time of the setup. Now its already there, and any attempt to change it will have to erase the drives, and this is a huge pain in the arse.
I recommend Nextcloud as well. For anyone interested but without self-hosting a server, I've had great experience hooking it up with my Disroot (disroot.org) email account which offers 4gb (free) storage.
Some while back Seafile looked more promising than Nextcloud to me. Never got around to actually using either though. Not sure how things shape up now.
> Use iCloud that's it if you're in the apple word.
Does iCloud automatically save versions yet? One of the default features, IMO, of the Dropbox/Box/WorkDocs/OneDrive world is that a history of saved versions is easily accessible for a single document. Last I checked, iCloud didn't have this one feature.
I see this in other apps as well; I just checked iA Writer, for instance, and it shows me versions on iOS. (And, of course, if you have Time Machine enabled on your Mac, you can browse versions for everything on that system, but I don't know how that interacts with iCloud: I suspect it's doing local versioning of your cloud drive!)
The support note that I linked about iWork says that with iCloud, "versions of your documents across all devices are saved periodically as you work on them," which is why I suspect there is a versioning feature exposed at the application level. As I noted, I see this in iA Writer, too. Unfortunately this doesn't help your use case, though.
Yeah, they fucked me when they restricted free accounts to 3 devices. As someone who spent years preaching the gospel of Dropbox to my non-techie friends and family, the number of angry phonecalls I received was more than enough to never recommend them to anyone ever again.
The features are added to your account at no additional cost for your current term. However the renewal of your yearly contract will be at the new price.
> Dropbox Plus just got an upgrade. And a new price—starting on [xxx] , 2019 (that’s your next billing cycle), Dropbox Plus will be $119.88 a year (plus any applicable taxes).
Glad I'm not the only one that thought this. I just want a folder on my computer I can put stuff in and have it backed up / synced automatically. I don't use/want any other features.
I still use dropbox right now for YNAB4 (The nYNAB offering is terrible and expensive), but this looks enticing. I haven't looked into using iCloud but the prospect of syncing during power nap and not having to use burn my VPN quota for dropbox (GFW blocks dropbox now, super annoying) is really interesting.
2TB with iCloud also applies to a family, and serves as iOS backup storage as well.
$10 for 2TB is great compared to what Dropbox gets you. I'm guessing no notification spam for upgrading too...
I had the same inclination as you. Dropbox was cooking my 2015 Macbook Pro. What I can tell you might reduce research time.
Google Drive has no differential sync. Any changes you make re-upload the whole file. This is a hard no for me. Also Google.
I moved to Sync[0]. The pricing tier was more what I wanted (500GB). They support symlinks, differential syncing, selective sync as well as a 'Vault' for storing files in the cloud but not on your machine. I think it's end-to-end encrypted as well, not going to commit to saying anything specific in that regard. The Mac app is also a lot better, I find it spinning up a lot less for me and its a lot lighter in general. To be fair though, even with iCloud I get my fans whirring up when I start uploading lots of changes.
I've also heard good things about pCloud[1] but I don't see any reason to change my workflow now after have to already change it.
Sync claims that, if you have the Sync setup create your own encryption key on your device, files are end-to-end encrypted. I believe them. Moreover, Sync support confirmed that they do not have access to meta-data about your files either. Thus, their admins do not have access to your unencrypted files or information about them.
They support all the usual devices both on the desktop and mobile apps.
Their servers are located in Canada, not the U.S., if geography matters to you from a privacy perspective.
I will also second that Sync seems much speedier than Dropbox. Startup / connection time is maybe 50% faster on my dated machine. (Dropbox seems to say Connecting... forever!)
You can run both Dropbox and Sync.com at the same time if you want to migrate slowly. I use Dropbox for non-sensitive files (e.g. rando family pictures) and Sync.com for sensitive files (e.g. birth certificates, financial files). With Sync.com and their more thorough end-to-end encryption, I feel safer that my file data cannot be used for random studies or anything else Dropbox feels like they can justify [0].
At what piont do you see issues? I'm on the free tier and only have about 3GB of files and have never noticed any CPU usages issues with Dropbox on my Mac
Perhaps you haven't looked? Try cloning a git repo, or unpacking a tarball with many files (doesn't matter if it's inside Dropbox or not) and observe the CPU usage of the Dropbox process.
I checked right now and the Dropbox process on my machine has consumed a total of 39 minutes CPU time. That's 39 minutes of full-scale CPU usage. Even their "web helper" process (whatever that is) consumed two minutes and 41 seconds.
(Google) Backup & Sync currently shows 2:04.46 in CPU time on my Mac. I'm guessing that means 2 hours and 4 minutes. The machine was shutdown overnight and booted this morning.
Is this something that resets with each boot?
Sounds broken on user end. Never seen anything like this when using Dropbox on several versions of Windows and Ubuntu, on both low-end and high-end machines.
DropBox is the Electron client of file sharing. They could make native apps that use native apis and get vastly better performance in time, power, cpu, and probably memory — but then they’d have to create and maintain a bunch of native apps. I know it’s common to hear HN comments like “they have the money/skill/opportunity to trade up to a better platform for more effort”, but everything I’ve seen says that it’s much harder to make that choice than to stick with the tech-debt you already have.
Note: I’m not saying it’s literally an electron client. It’s an analogy. :)
It's particularly funny because they hired Guido (GVR) who is supposedly helping them migrate a million(s) lines of code py2->py3. Whereas a better solution in the long run would have probably been just rewriting the whole damn thing in Rust for all platforms.
They use Rust in the datacenter. The layer that actually writes bits to disk is written in Rust. I don't know why they haven't yet deployed a native desktop client that's a Rust core with a thin platform-native GUI wrapper.
Edit: at 30:05 in that video, he briefly talks about a forthcoming (as of 2017) "full redesign + rewrite of Dropbox's 'sync engine' in Rust." He claims it will use 10x less memory, and be 50x faster on key operations.
My previous experience with Google Drive was that it would chew up CPU and memory a lot more than I liked.
I've been pretty happy with iCloud Drive since I switched to it. Works seamlessly and effortlessly on my Mac and iPhone, affordable pricing fo storage which can be shared with family, and also solves my photo storage needs with Apple Photos. The only drawback is the lack of shared folders, but they just announced that is coming soon.
As soon as Shared Folder is released on iCloud, I'm moving everything out of Dropbox. I already pay for iCloud for my photos but have tons of unused space, that just makes more sense to consolidate, especially since Apple cares about optimizing for battery and CPU usage.
Yeah, I've never had a good experience with the Google Drive client. Heck, I remember when the Windows version would suck up all available file handles and basically make the machine unusable.
That being said, the whole point of Dropbox to me is that its cross-platform. iCloud Drive is basically worthless for the Dropbox use case unless your entire computing universe is on Apple equipment.
Funny enough just yesterday they announced a completely redone Windows client that they built collaboratively with Microsoft to use the right APIs etc. There’s a bunch of news chatter about it right now.
After reading some of the comments here I decided to give the Google Backup & Sync client another go on my MacBook Pro. The CPU fan has been blowing at full speed for the last 15 minutes. It's still terrible, extremely resource-hungry and slow.
(I work for Google, not on drive. Opinions are my own).
Have you tried the newer drive client? Backup & Sync[0] replaced the old client and I believe is a bit better than the older client. If you are on GSuite, there is the Drive File Stream[1] that is a lazy-load of resources from a drive folder (which is why it's targeted for businesses only).
Backup and Sync for MacOS at least is a disaster. It locked me out of my account because when backing up photos, if it can’t figure out how to convert files to normal quality JPEGs, it uploads them anyway and your quota is charged. Then a month later when you start wondering why nobody sends you email any more you might figure it out.
I posted above, but can elaborate in some more detail here.
I used the new Backup & Sync tool for the first time and had a poor experience.
Context: I have a paid MS OneDrive account but maxed out my storage and was seeking alternatives (specifically ones with easy family sharing). It turned out my wife was already paying for Google One so we just used that. I downloaded Backup & Sync just to transfer my photos from my local PC into Google Photos. Backup & Sync's UI is terribly sluggish on Windows. Clicking the system tray icon renders a blank dialog and then a second or two later the dialog is rendered (Surface Book 1). The UI responsiveness was a turnoff but not my primary concern.
In the sync tool and the Photos webapp preferences there are two checkboxes that affect syncing:
* Backup & Sync client (upon upload to Drive copy photo to Google Photos)
* Google Photos web app (automatically index Drive and copy images to Google Photos)
As an end user I liked the separation of Drive and Photos from the user experience. I do not want to upload photos to Drive and have them sync to Google Photos. And I definitely don't want Google Photos to index all images on my Drive account.
Simply using the Backup & Sync tool forces you to upload photos to Drive and have them sync over to Photos ruining that separation. And unfortunately in a case of bad timing there was some server outage on Google's end that affected the syncing of files from Drive to Photos. My photos successfully uploaded to Drive but did not appear in Google Photos web app, but no error is displayed to the user. I contacted Google One support and they informed me there was a problem they were aware of but also that I had to enable the latter checkbox in Photos webapp (have Google Photos index and parse all of my Drive images). I was incredibly hesitant to check that since I have a massive amount of images (not photos) in my Drive account (paper scans, tons of small icons, etc) and I don't want any of those appearing in Photos. I listened to support regardless, enabled that checkbox, and of course it did not work due to the server outage.
And I definitely don't want Google Photos to index all images on my Drive account.
I've had this happen and it's a nightmare to fix. Once I accidentally had a node_modules folder sync to Google and it had images in some of the subdirectories for some reason, another time I had something else with third-party resources like an HTML eBook and ended up with random images of charts and graphs all over my Google Photos.
It’s still terrible. Actually Google Drive (or Backup & Sync) client hasn’t improved one bit in the last 4 years. The only update we saw was “material design” revamp that was about it. It still spends 15 minutes “preparing for sync” every time I restart and consumes considerable CPU while doing that too.
As siblings say, it’s still terrible. I installed the business version on my Mac to give a look, I have zero files synced with it. After a few days I checked activity monitor and it had used tens of minutes of CPU time. For zero files and zero activity.
Backup and Sync is not so great. I wish the Photos backup client was still available, and I'd use that together with InSync.
InSync is great and works on most platforms. I've been using it since dropbox lost a bunch of my important files in 2014. (I have multiple backups now)
Yes, their symlink handling is absurd, and they have the usual sanctimonious defense when questioned about this. To be fair, most commercial cloud services overthink this, and also get it wrong.
A symlink is just a file, like any other. It is a user's responsibility to insure that a symlink will work elsewhere; cloud services should just copy the file, just like any other. The users who expect a symlink to trick a cloud service into special behaviour (like syncing folders elsewhere) are also wrong. You no more want a cloud service going off and "thinking" about a symlink, than you wanting it going off and "thinking" about porn it finds on your computer. These are just files; their contents or meaning are absolutely not any cloud service's concern.
For example, a MacOS application bundle typically includes internal symlinks that most users are unaware even exist. Yes, DropBox breaks these, too. They tell you that their service is not intended for synchronizing entire file systems, as if properly handling an arbitrary file is somehow rocket science. I'll grant them that this is over their heads, but it's not hard.
There's exactly one sync program that gets it all right: Unison, written by Benjamin Pierce, a world-famous computer scientist. Yes, he actually thinks about this more clearly than any of the programmers of commercial services, and the best community ideas are adopted.
Unison handles symlinks properly.
Atomic directories are a relatively new feature in unison: One can declare a directory atomic, forcing the user to choose at the directory level when there’s a conflict.
I declare .git directories atomic. A better example: A MacOS .sparsebundle disk image file appears as many files (bands) inside a directory, but is intended to be seen by the user as an atomic file, not a directory. This has the advantage of more efficient backups: If one makes a minor change to a large mounted disk image (say, a few MB to a multiple GB disk image) then backup software isn’t forced to make a new copy of the entire multiple GB disk image.
If one makes minor changes to the same mounted disk image on two machines, and then does a two-way sync, one could buy the farm. Most likely, there will be a conflicting root file alerting one to the problem. Far cleaner to simply be forced to choose one disk image directory over the other. Functionally, the entire disk images are in conflict, not specific files within.
The ability to declare atomic directories is not a feature of any other two-way sync software, and it should be. A good heuristic: If a naive user can’t easily open a folder to reveal its contents (say, a Mac application bundle, or a sparse disk image) then the supporting directory should be treated as atomic by default.
You are taking strong positions on what is right or wrong when there is no objective answer and tradeoffs both directions.
> It is a user's responsibility to insure that a symlink will work elsewhere; cloud services should just copy the file, just like any other. The users who expect a symlink to trick a cloud service into special behaviour (like syncing folders elsewhere) are also wrong. You no more want a cloud service going off and "thinking" about a symlink, than you wanting it going off and "thinking" about porn it finds on your computer. These are just files; their contents or meaning are absolutely not any cloud service's concern.
Unison seems to be more designed for personal sync'ing than collaboration. That informs decisions.
If you take your position that symlinks should be sync'd opaquely (as a file with a symlink target), collaborative relationships that involve symlinks are broken without much warning when a collaborator uses windows XP (the most popular OS when Dropbox came out!).
At least following them (which Unison does allow with a setting) ensures Windows collaborators can see them.
Dropbox could probably make the change now (few XP users remain), but you have legacy issues of existing users relying on the "follow" behavior to sync content outside of their Dropbox.
> One can declare a directory atomic, forcing the user to choose at the directory level when there’s a conflict.
Not forcing users to make choices before upsync occurs is an explicit design decision of Dropbox. It ensures that if I power on my computer after being offline, things will quickly sync to the cloud -- I don't need to spend time making decisions.
>symlinks to Windows (or at least WinXP since they didn't exist until Vista)
The version of NTFS in windows xp and the version of windows explorer both supported symlinks just fine. There was just no user-mode api to create them. You could use a kernel driver to make them, or even mount the disk offline and make them
I tried to use unison for serious production work a few years ago, and it fell short. It would fail or become incredibly slow with large (but not huge) amounts of data. A pity because the concept is great. I wonder if it has improved since.
I played with borg some in the early days and was unimpressed with some of the methodology and code quality displayed on public forums like GitHub. This is kind of archival work MUST be correct and carefully designed due to its sensitive nature. I hope I'm not giving the project an unfair shake here, but I checked it again recently and the first several lines of the GitHub page list 3-4 fairly recent versions that have caveats around data corruption and the like ...
This is not really isolated to borg, so I don't want to pick on them too much (plz shield your eyes in the direction of rclone...), but calling it the "holy grail" is a bit rich IMO. This kind of stuff is simply not industrial grade software.
Borg has a lot going for it, but I'm hesitant to call something a holy grail or one true way if it can't do compact diffs. Especially when it needs active server software, which makes pruning much easier.
I have always been intrigued by your service, and will probably try it at some point for a smallish setup for important data, but whenever I think of backups in the TB range, it gets way out of budget (even after accounting for borg or other discounts). Do you have any plans to compete on pricing with other popular cloud/storage providers? I understand that this is a different product for a different audience.
"Do you have any plans to compete on pricing with other popular cloud/storage providers?"
We try to keep out pricing very roughly inline with Amazon S3. If you know to look for the discount signup rates it should be very slightly cheaper than S3.
We can't promise customers support from real UNIX engineers and also match B2 pricing. I'm happy with that and plan to continue on that path ...
> The users who expect a symlink to trick a cloud service into special behaviour (like syncing folders elsewhere) are also wrong.
I use neither Dropbox nor Unison, but on the treatment of symbolic links, every program that somehow manages files have some sort of configuration option to decide whether or not to follow symbolic links. It's not about tricking a service into special behaviour. It's just that either handling by following or not following the links are both appropriate behaviour in different situations.
In the case of Unison, it chooses not to follow by default, but it also can be configured to follow as described here:
Furthermore, when the destination host is a Windows system, Unison refuses to not to follow a symbolic link, since Windows doesn't support symbolic links.
A file for which you exclusively use lstat() & readlink() instead of all the other usual functions in the standard library you use for regular files. What about named pipes? Or sockets? Or whiteout? Are they too just files since they have a filename?
I chuckled at the "TRAILER!!!". I wonder what other file formats have silly things like this.
From `man 5 cpio`:
> The end of the archive is indicated by a special record with the pathname “TRAILER!!!”.
This makes me wonder if this means that the cpio format can't reliably be used for files with the path "TRAILER!!!". Why would the format even need a special record to indicate the end of the archive? Is there any reason why one wouldn't be able to rely on the end of the file to indicate the end of the archive?
GNU tar uses entries where other tar implementations will overwrite previous files on extraction, AIX tar uses special four character names for binary blobs (plus xattrs as names, both after the affected entry), Solaris cpio uses another mode bit for sparse files, ACLs, and xattrs (I actually really like this, it extracts as a simple to parse text file[0] on other implementations), and most pax commands on Linux can't read/write PAX archive files.
FWIW I make use of TRAILER!!! to let me know in a pipeline that everything worked (imagine a command earlier in the pipe fails early and not every entry is processed but ends on a boundary), but here the two pages of zeros that tar uses makes more sense (about the only thing tar does better than cpio).
$ PAGER='col -bx' man 5 cpio | awk '$1 == "mode" { print; while (getline) print }' | head
mode The mode specifies both the regular permissions and the file
type. It consists of several bit fields as follows:
0170000 This masks the file type bits.
0140000 File type value for sockets.
0120000 File type value for symbolic links. For symbolic links,
the link body is stored as file data.
0100000 File type value for regular files.
0060000 File type value for block special devices.
0040000 File type value for directories.
0020000 File type value for character special devices.
$ echo /dev/urandom | cpio -o | dd bs=6 skip=3 count=1 | od -tc
1 block
1+0 records in
1+0 records out
6 bytes transferred in 0.000025 secs (239675 bytes/sec)
0000000 0 2 0 6 6 6
0000006
Yes, I love syncthing for many reasons. Those complaining about UI support will not love syncthing any more than other replacements. Also, setting up ST on phone, AWS, and my desktop was an exercise in patience. I now have a config I'm happy with, but it took a lot of effort that I wouldn't expect from just anyone.
Is this really true? wow. I'm shocked that a company of Dropbox's size hasn't built native clients for each platform (or rearchitected the core to be based on something like Go or Rust that is fast and cross platform, and just building the UI parts in the native frameworks)
From their POV whatever is in their data centers will be microscopically optimized and written in carefully handcrafted Rust and then later covered in blog posts.
For clients their unspoken answer is 'upgrade hardware and stop whining' or 'we have strategic direction to deliver uniform client experience across platforms' which would just mean write some JS/Electron crap.
I'm guessing you never used Google Drive's Backup and Sync on Windows. I used it for the first time a month or two ago. Simply clicking the system tray icon brings up a blank dialog that takes seconds to render. Both Drive and the sync tool have been around for quite some time so I expected it to be a polished experience.
I also expected the integration with Google Photos to be excellent since Photos is a major Google service, but in a terrible case of bad timing I just happened to attempt to use it when Google had a Drive -> Photos service outage.
The client used to be great when it was "Google Drive" but of course they had to rewrite and rebrand it to make it unbearable. Enterprise users, IIRC, still get to use the good client though.
Google's much larger and they moved away from some excellent native clients like Google Talk, which IMO took the crown from MSN and other chat clients a decade ago. It's the same story for photos and other apps. They've consistently killed native apps and replaced them with poorer-UX pure web apps.
Meanwhile Slack is happily sticking with their Electron app and wasting the resources of hundreds of users machines and who knows how much electricity in total.
For reasons I cannot fathom, it seems like bigger companies are far less likely to justify the resources to build multi-platform native software than smaller ones.
Seems logical (if depressing) to me: companies that do less work to customize their product to their target customers will find it easier to get big in the first place. Companies that care about craftsmanship above all else have to deal with being small. The violinmaker down the street from me does excellent work but he's never going to be as big as Toyota.
Companies like Dropbox tend to make the bulk of their money by selling to other businesses, as well, which by definition is the set of customers who care more about volume and price than craftsmanship.
Pretend you're a Dropbox salesperson, and your job is to go to other companies to sell them on enterprise Dropbox. How many times do you think you're going to hear someone challenge you on what version of Python the Mac client uses? It just doesn't happen.
There's many small ("indie") companies that make great Mac software, and do it by being Mac-only. That means they'll never be huge, but it also means they're never going to have a second-rate Mac client.
Yes, a company of dropbox's size definitely has an iOS team (not 1 iOS developer). They absolutely have the resources to do this.
But I suppose you're right. Even true of Slack. It's totally a meme that Slack's electron client is horrendous and bloated, but it probably hasn't stopped their growth, so where's the incentive for them to improve it?
What sucks is that server-side performance is their problem, and client-side performance is your problem. It becomes their problem if growth slows or if users leave, but it's often too late.
I'm starting a company and writing native clients. There isn't any reason not to. There are lots of cross-platform GUI libraries that are fine for business applications, you get native speed, there are plenty of languages that are both safe and fast. You get full access to the full power of the OS if you need it. I think the current craze of non-native clients is because of web-developers who don't know how to do anything else, so they just mimic a website on desktop.
It depends what they're using. Often, the cross platform libraries are abstractions that just call the native functions for that platform. Even in that case it's difficult because differences to that platform can cause minor layout issues.
There are cases where a custom, bespoke application for each platform is warranted, but that is rare. It's a continuum between the custom, bespoke and a UI/color scheme completely custom to your app.
I switched a few years ago. It works really well. Unless you are using Dropbox with a team or a corporate environment, iCloud is better. I use a combo of iCloud (love the desktop syncing between my machines btw), and Google File Stream for team documents.
To me, this mass exodus from platforms to iCloud is _scary_. I've been rolling my own solution for some time now based on Resilio Sync. I understand that I'm the minority and a power user, but honestly giving Apple (or Google, or Dropbox, or _____) control over my files like that does not appeal to me in the slightest.
On sort of a tangent, I'm also choosing not to use iCloud because I really feel like it gives Apple an excuse to establish anti-consumer practices when it comes to hardware repairability and data ownership. I had an amazingly terrible time at the Apple store recently and an employee tried convincing me that Google will sell my photos that I've uploaded to my G-Suite account. I believe what he said was "I just pay the $x/month for iCloud, because 3rd parties can't be trusted sometimes". To me, that is an amazingly terrible attitude that sounds like it came straight off the page of the language guidelines. As far as hardware repairability, Apple recently has moved to either soldered-on or proprietary connectors for their storage devices for most of their devices. In the 2016 MacBook Pros, they made an assembly to recover data via the lifeboat connector so if you had a logic board swap (which is what you get because they'd rather landfill/grind down than repair) your data could still be recovered.
This has disappeared on the latest models. Finally, Apple in the past year has discontinued their Time Capsule product and has not made any large improvements to Time Machine. It is still a nightmare to use with SMB environments, which seems to not align with Apple's silent killing of AFP in favor of Samba.
> control over my files like that does not appeal to me in the slightest.
Then self-host Nextcloud on your NAS.
> anti-consumer practices when it comes to hardware repairability and data ownership.
Hardware repairability? Agreed, but this goes hand-in-hand with security. IMO all hardware and data should be entangled with the Secure Enclave/T2 chip but Apple is a long way from that (looks, however, as if they are working towards it).
Data ownership? IMO Apple is pretty good with that. They care much more about privacy here than Google et al. If you truly want nothing on Apple's cloud, it's super easy to turn off iCloud too.
> I had an amazingly terrible time at the Apple store recently and an employee tried convincing me
I don't get tech people who do this. You go to a store, ask about a product that you are clearly more knowledgable than the employee on, and then complain that they aren't knowledgable? Unless you are lost there is zero reason for you to ask an employee about a product.
That said, I trust Apple not to datamine your photos. I don't trust Google on that.
> This has disappeared on the latest models.
T2 chip. Security/convenience tradeoff. I'll take the security every time.
Seriously, though, it looks like the only solution that you'll find palatable will be your own NAS with self-hosted Nextcloud - and, if you use a Mac, Time Machine.
> IMO all hardware and data should be entangled with the Secure Enclave/T2 chip
This is an absolutely terrible implementation of security. There is no reason that your data should be tied to a circuit board that does everything. Mac logic boards are ticking time bombs.
> I don't get tech people who do this. You go to a store, ask about a product that you are clearly more knowledgable than the employee on, and then complain that they aren't knowledgable? Unless you are lost there is zero reason for you to ask an employee about a product.
We as tech enthusiasts should care. What is shown and received by all consumers is what leads the industry. I went in because the baseband CPU had flexion damage in my iPhone 7. I went in for the out of warranty repair. They asked if I had a backup. I said yes. They asked if I did a local or iCloud, I just said no, I use Google Photos. I then got this obviously scripted sales pitch for iCloud.
> That said, I trust Apple not to datamine your photos. I don't trust Google on that.
They're _probably_ datamining your photos anyway. This trust that people have in Apple seems to be pretty blind.
My entire comment was lead with yeah I'm a power user and a different case. My comment was tackling how Apple's attitude is anti-consumer.
I have two major problems with it, what it's written in and how it manages files.
It's written in PHP. I'm not complaining about the language... I started as a PHP dev and fully recognize why an establishment might use it. The issue I have is PHP is always a pain in the ass to get configured properly. Of course there's always docker implementations, but even those haven't been constructed well imo.
Secondly, the way it manages files is absolutely terrible. Now I haven't really used it in about a year so I don't remember the specifics, but I now have a folder on my NAS that is pretty much not removable due to what I believe is an abuse of ACLs. What I really need is just something with a web interface that can sync with my other devices without imposing its own file/folder structure. At least with my experience in the past, this is a pain with Nextcloud.
Can't speak to your first point, as my only interaction with Nextcloud php configuration has been to comment in/out various php modules. I don't have too many modules though, so maybe that's why I haven't had any configuration issues.
Regarding file management, the working solution for me has been to mount any external storage with a fuse mount ( NAS, dropbox, etc. ), and then just use the Nextcloud "external storage" option. Other than Nextcloud's general slowness ( I'm running on an underpowered server ) I haven't had any issues.
Microsoft blog: “The new iCloud for Windows app introduces a new iCloud Drive experience for Windows 10 users powered by the same Windows technology that also powers OneDrive’s Files On-Demand feature, enabling users to be more productive offline on mobile devices and quickly share files on iOS.”
The parent poster should've made it more clear!
Because the Apple Support link posted does not mention this collaboration anywhere, unlike the Microsoft blog.
Edit: I'm trying the "updated" app now. No changes appear to have been made. It is still slow and buggy as hell, it still installs a ported and outdated version of half of the frameworks of OS X, as expected.
Collaboration has been heavily implied in all articles I've read about this. That Microsoft made a blog post[1] about it, saying "Apple and Microsoft", must mean something.
At least when I tried it a few years ago, the Windows client was also a crappy Python app that ate CPU and disk for around an hour after every startup.
Why? To detect changes, they were storing a snapshot and comparing everything on disk to the snapshot. Which is madness when Windows has methods that don't require reading every damn byte on the disk - at the least, they could use a filesystem minifilter driver, or the NTFS USN change journal.
As if that wasn't enough, after the startup scan they were using an unreliable method to detect further changes (same one as dotnet's FileSystemWatcher, I forget the name of the underlying Windows API).
And to top it all off, even with only 2 systems sharing the data, there were conflicts all the time that required manual resolution (and I seem to recall Dropbox wasn't very good about surfacing these when they happened). Then there was a data loss incident, I presume due to some kind of conflict snafu - Dropbox only support at the time was a forum, and they were completely uninterested in even acknowledging that there was an issue.
I switched to Seafile after that, and haven't looked back. I honestly don't understand why people would put up with that crap, but given the size of Dropbox they obviously do...
I've been hosting NextCloud on a $10/month Digital Ocean VPS for maybe 8-10 months now, and I've been super pleased with it. I'm not much of a devops person, but I found it fairly easy to set up and configure, and it runs smoothly enough that most of the time it's indistinguishable from using third-party cloud file sync service. I occasionally ssh in to apply updates (and renew the Let's Encrypt cert, since I've been having trouble getting it to renew through cron and haven't spent much time debugging why), but that's about it.
Fairly small; it's only about 5 GB, so I can't say for certain how well it would work with something that large. At least at the size that I have, changes propagate across my devices pretty much instantaneously .
I've used Dropbox since the beginning, and Nextcloud for the last few years. Nextcloud client seems to use %10 of the memory of Dropbox on my machines. I'm now in the process of switching to SyncThing. The advantage of Syncthing over Nextcloud, is you can used it centralized or decentralized (without a server), I dont need to manage SSL certs and I dont have to poke holes in my firewall. Syncthing client also uses very little memory (a bit more then Nextcloud, but hey Syncthing is both a client and a server). Each of these services have their own strengths, so it depends on the features you want.
The greatest power of Syncthing I've found is that once you get two devices to handshake, you're done.
Laptop, meet phone Id, phone, meet laptop Id. Laptop, meet desktop, desktop meet laptop. Oh I've got my server, server meet desktop meet laptop and vice versa.
Want some files to be available on all devices at once? Put it in the Bank Cannister folder which you've set as active for all devices.
Want to drop airdroid or plugging in your phone's internal storage to transfer media files to/from the phone? Setup phone<->laptop<->desktop folder named PhoneMusic and tell the syncthing app to store the contents of that file in the same directory as your already existing music root.
Want off-site backups but too cheap to pay for backblaze like me? Backup to Blu-ray, local external drive, and sync to off-site location (my dad's PC or DO droplet).
And when I say sync, I mean setup the syncing folders then let it background P2P sync on its own time. Eventual consistency might as well be instant for all but 1% of the time where you look for the file then see it written to the 'local' drive before your eyes.
I had a lousy experience setting syncthing up for the first time, but then a really pleasant experience using it. I would recommend it as a decent sync option
For those on Windows, I recommend the SyncTrayzor Syncthing wrapper. Made the thought of getting Syncthing initially configured a lot less daunting and made getting off Dropbox much easier.
Have you considered Keybase KBFS for this? You get 250 GB for free, public/private with not too much metadata getting leaked, FUSE for desktop and also access on mobile devices.
I haven't actually moved over to this myself yet, but it does look much better than Dropbox or Sync.com (which I stupidly am still subscribed for despite their client being even worse than Dropbox - but at least it's encrypted...)
Nextcloud mentioned previously is the obvious choice for the privacy-conscious, but does take some further responsibility to ensure integrity and availability.
I like KBFS a lot, but you have to be careful about trying to use it as a Dropbox-alike. KBFS is always-online. If you have no network connectivity, you have no files.
They have been working on this and you can actually do it today even if it's not very well documented (again, haven't tried myself):
$ keybase fs sync --help
NAME:
keybase fs sync - Manages the per-folder syncing state
USAGE:
keybase fs sync <command> [arguments...]
COMMANDS:
enable syncs the given folder to local storage, for offline access
disable Stops syncing the given folder to local storage
show shows the sync configuration and status for the given folder, or all folders if none is specified
help, h Shows a list of commands or help for one command
If you don't mind getting your hands a little dirty, you can basically just rsync a given local folder with your `/keybase` folder on a cron every so often.
It's obviously not a right-for-everyone kind of solution, but it does get you fast local offline sync functionality with very little effort.
> Nextcloud mentioned previously is the obvious choice for the privacy-conscious, but does take some further responsibility to ensure integrity and availability.
I'd recommend ownCloud over Nextcloud as Nextcloud doesn't have file checkumming during transfer.
Because it's web-based, I had huge difficulty getting ownCloud to sync web files like .htaccess. I ultimately abandoned the effort, and I don't know if that has improved any.
Google's is much worse for any significant number of files. It burns a bunch of CPU/battery like you described for Dropbox, but it also freezes eventually and has to be force-killed. I gave up trying to sync my former Dropbox files to Drive.
I had the exact opposite experience. I tried to sync about 700k files to Dropbox and it chewed up CPU for hours, never got past "Preparing to Sync" (or whatever is the equivalent), then crashed. I tried a number of things. Circa about 2 years ago.
Google drive does annoy me when it decides to do a "full scan" and won't sync anything new until it completes, BUT, it does sync all my data, and it doesn't crash or use tons of CPU.
I tried deleting a few thousand files from Google Drive and they just got stuck in the trash...had to manually select them all a screen at a time and delete them from the trash, since "empty trash" didn't work. I also ended up with several thousand "unorganized" files at one time--files that are visible to search but not shown in any folder.
> Does anybody know how the CPU/power impact of Microsoft's and Google's offerings are on the Mac?
It doesn't matter, because from your stated issues with Dropbox, neither OneDrive nor whatever-google-is-calling-it-this-week will provide a suitable replacement for you. They both suffer from the same (and worse) shortcomings as Dropbox.
Neither competitor qualifies as "a folder that syncs" and they both install all kinds of junk to your system.
Maybe this is heavily dependant on the file structure of what's being synced, but I've tried Google Drive, iCloud, OneDrive, and Dropbox, and all but Dropbox have exhibited the CPU melting issue you describe.
Dropbox was the only one that managed to sync 10s of gigs in a timely manner, without spending hours "analyzing files" before starting to upload.
the windows client constantly keeps a 3d rendering context (chrome) alive preventing my gpu from downclocking.
as long as the client is running, my GPU is tacted at 1.6 GHz, if i kill the client GPU settles at around 0.14 GHz. this makes quite the difference in power consumption of my machine when left idle for multiple hours the day.
nowadays i only start the client when i want to sync files or expect to receive some uploaded by my peers. after thats is done the client gets killed immediately.
but why does it have an 3d context running you ask? for the small notification window where i can track the sync progress. i still remember the "native" solution they used few years back, did not have drop shadows, but the entire functionality was present via an WinAPI menus. Considering one can, with some OwnerDraw work, put progress bars and scrollable lists in Menus, i don't get the point of using an whole web browser to display a 600x200 popup.
They really should take a look at bvckup2, how fast and efficient a backup/sync tool could be done in native way
At my small startup we tried using Google Drive as a Dropbox replacement a year or two ago. We are paying for Google apps so it made sense to try they're Dropbox-like service, and it had some seeming advantages too. We found it to be a lot less reliable than Dropbox in most senses. UI is worse, error handling is poor, you may easily end up losing data. Not worth it. Now we pay for Google apps for gmail, and for Dropbox for file sharing. Which btw has become a lot better now that there is cloud sync available in the pro subscription (not only in the business subscription), they raised the price from $10 to $12, but I'm so happy that I have been able to recover some much needed disk space in a convenient way!
I agree with the issues with the Mac OS client burning too much CPU/battery, I've learned to live with that as an inconvenience, since otherwise, it works great by fulfilling the top priority you want in a service like this: it is reliable.
Get your own NextCloud instance; you'd need to pay for some Linux VPS (<$5/month); installation takes 5 minutes and you have clients for all major desktop/mobile platforms.
Ultimately, after that $5/month plus storage costs, you still have to handle security patching, DR, and everything an infrastructure engineer does all on your own.
Not to knock it, I think it's a great option. It's just not for everyone, not for the dentist next door or anything.
There are oodles of managed nextcloud providers too, their pricing generally matches up favorably with standalone VPS pricing: https://nextcloud.com/providers/
I think it's a great idea for somebody that already runs their own VPS for their own homepage etc. Once you install NextCloud, you can continue by installing ActivityPub-based decentralized apps, replace most cloud offerings, and be happy about it ;-) I did that; arguably I am not a dentist but if some friend asked me to, I'd have done that for them.
Symlinks in general suck on OSX. Try symlinking a file from an NFS mount onto your desktop and see if you get a thumbnail for it in Finder. In Finder, you won't. Now you might think, "well that's NFS, it's probably not thumbnailing those files because the latency exceeds some timeout." That's what I thought. However if you add that same directory containing such symlinks to your dock, you will see thumbnails for symlinked files when previewing that directory from the dock. If MacOS can thumbnail those symlinks when previewing the directory from the dock, then why can't Finder thumbnail those same symlinks?
(Also in third party Finder alternatives, like Commander One, you will typically get thumbnails for symlinks.)
They suck on Windows, too. I've tried using junction points more than once to share a common library directory among several different projects, and have always ended up in makefile hell when some projects 'see' changes to files in the library directory while others don't.
I can understand why Dropbox doesn't want any part of the dumpster fire that is symbolic linking. Maybe they work great on Linux, where they are a core aspect of how the filesystem works under the hood. But Dropbox has to present unified behavior across all supported platforms, and the last thing they want is to be put in the position of providing tech support for filesystem bugs and quirks and race conditions.
Yeah, when it comes to cross platform stuff I'm pretty forgiving with this sort of thing. Finder botching it sends me up a wall though. It's probably only a few lines of code at most to fix it, but Finder is closed source so I can't investigate it myself, let alone fix it, let alone send my fix upstream.
(And frankly I'm hesitant to even report it as a bug, since for all I know Apple will decide that NFS/symlinks getting thumbnailed in the dock preview is the real bug, and "fix" that leaving me worse off than before.)
Edit: Also sort-by-kind also fails in Finder when symlinks are involved. When "keep folders on top" is set, symlinks will still sometimes (but not always) appear above folders.
They also just put the price up of the plus plan $20 a year. I already pay for iCloud so I don't know why I'm still a customer really. Laziness I suppose. I trust Apple with my data a lot more also.
I've also been in the process of moving off both Dropbox and Google Backup & Sync because they are such resource hogs on the Mac. iCloud drive isn't perfect, especially when it comes to sharing, but I'll accept that if it means my fans aren't going to be on full blast when it's running.
I can't remember a time when I've had Dropbox open and not found it at the top of the CPU tab of Activity Monitor. This may be because I have a couple symlinks (not many, just some dotfiles) or because I have a large number of files (nothing ridiculous, ~100k photos backed up) but the fact is, it's been long enough for Dropbox to have figured this out and fixed it.
It's bad enough to where I now leave Dropbox off all the time, then only turn it on when I need to sync something. With iCloud sync I don't even think about it, which is the way it should be.
I opened Dropbox before starting this comment to see the new UI and even after giving it enough time to catch up, it' still using between 48 and 127% CPU. It makes even Outlook feel breezy.
Might not be right for everyone, and it's certainly not the best thing for this, but it's cheeeeap and practical... I use AWS S3 for sending files to others. Basically no file size limits, and you just pay for what you actually use, which is typically less than a few bucks/month for me.
I've used Dropbox quite a bit and over the years via various promotions they ran worked up to over 8 gigs of space while still remaining on their free tier. A few months ago I switched from a combination of Dropbox and Google Drive to SpiderOak which has end-to-end encrypted storage. Been pretty happy with it thus far.
Agreed. Their iOS client is a huge pain too. Finding files is a bear. It’s so bad that Apple’s “File” app is a much better way to browse and search Dropbox files. I suspect in macOS Catalina we’ll be able to search files through a similar way.
Also, Dropbox Paper shows the same lack of attention to detail. The iOS client has all sorts of really stupid basic bugs like undo and copy & paste not working properly. It’s nuts.
It feels like Dropbox’s culture is to ship a product and not do the hard work that it takes to make the core basics rock solid on all devices and platforms. It’s really hard work, but it’s essential for a user base as large as theirs.
The even harder part is for their leadership and PMs to say “No” to new features until they hey the basics right; otherwise they are going to find themselves in the position of doing a lot of things not very well.
No battery issues with google filesync on my mac. I do wish however that they'd spend some time improving it. Sometimes files never leave the cache which end up taking up a lot of space.
Solution of course is to just use rclone and mount Google drive directly.
When you say 'support symlinks' what behavior would you expect the service to have with them?
I run a company with sync software, we treat them same as any other file so if you have one in a folder set to sync, we sync it, we don't follow the link and sync the linked file (as the link could go outside of the configured sync folder).
A well-written Python app using the respective platform's native events through say, watchdog[1] performs perfectly fine for huge numbers of files[t]. The language used isn't at all the problem with Dropbox's performance which has been a problem for as long as they've had a desktop app.
If there's one specific bottleneck (ex: hashing files) then that's a prime candidate for Cython[2] or the plain CPython C-API.
Even when you have dropbox restricted to a small folder with _no IO events at all_ it's still constantly working, which is the real problem and entirely an optimization/design problem.
Agreed, and I'm a big Python fan myself, I didn't mean to bash the language.
Somewhere between cool MIT dorm room side project and serious company there is a point where it's time to ditch it and reimplement it in in something that performs better.
Another drawback of it being Python is that when it is causing the fans to spin, I can't inspect what's going on with Activity Monitor's sampler. It's all opaque nameless Python stack frames.
I highly recommend Tresorit. I've been using it for just over a year and couldn't be happier. Simple interface and the app seems very performant (macOS). At least I haven't noticed it hogging resources.
Now try to have a Windows machine with Dropbox, Microsoft One Drive (very hard to turn off) and Google Drive! I've saved a lot of Windows machines just telling the owners to uninstall these services.
It’s a cautionary tale about Python. If you start there you will never get off of it. You can hire Guido but you still won’t be able to go from 2 to 3.
I find this sentiment amusing but inaccurate. going from 2 to 3 isn't that hard and going from python to something else also isn't that hard either. If there are tests that should handle all of the compatibility checks for a full rewrite.
That's true now, 6 months from EOL of Python 2, where all the common dependencies have upgraded, and there finally is agreement that Python 3 is the way forward.
That should have been true on the day Python 3 was released.
Going from 2 to 3 isn't that hard because Python 3 was released ages ago with the expectation that the changeover would be gradual.
The only ways I can see to make it that easy on the day Python 3 was released are (1) no backward-incompatible changes (but enabling such changes was the whole point of Python 3) or (2) doing all the preparatory work before "releasing" Python 3, which in practice would have taken just as long and required there to be a pre-release Python 3 to work with.
#1 misses the main point of having a Python 3 at all. #2 basically looks just like the way things actually are, except that Python 3 is labelled "alpha" or "pre-release" or something for years longer.
People like to complain about how slow the Python 3 changeover has been, but it seems to me that it's worked. The obvious point of comparison would be Perl 6, which hasn't exactly been a triumphant success. (Though there are many other differences between Python 3 and Perl 6, and it's not at all clear that Perl 6 would be widely used if they'd adopted a model more like Python 3's.)
Not to mention that just about all of the changes I've heard about in Python from 2 to 3 are changes that Perl5 has already handled in a backwards compatible way.
(In at least some cases the changes happened more than a decade ago.)
