47 comments

[ 2.0 ms ] story [ 106 ms ] thread
> In the event of a power outage, one provider could only give us 30 seconds of emergency power—versus five minutes with a standard UPS setup—because they used an inertia wheel.

If a generator fails to start in 30 seconds, that almost always means it will also not start within 5 minutes.

Does dropbox have automation that attempts to gracefully shut down systems if a generator fails to start? Are systems then kept down until the battery UPS system is fully recharged? If not, the difference between 30 seconds and 5 minutes doesn’t seem important.

Our Indian Condo complex generator regularly takes more than 30 seconds to start up. Even the best case is likely at 10 seconds so only having such a small cushion sounds dangerous.
Some rough calculations on a fully loaded data center that I have worked on designing shows that you only have about a minute before the air gets to an overheating condition due to the low heat capacity. The HVAC doesn't keep running through a total power failure even if the computers have a lot of reserve power.
How does one make it known that they have a data center available to tender for these processes? Is there like a Craigslist for data Center space?
(comment deleted)
Talk to industry media like Data Center Knowledge.
From my understanding there's a lot of essentially commercial real estate brokers but focusing on selling (leasing) data centers and other industrial locations.

They even directly mention this in the article. Specialized real estate brokers will keep up to date on who is building what in a market. It's hard to hide a data center. They tend to need a shit tons of permits to construct, even if being built out in an existing industrial location. Not a lot of secrets for those paying attention. Hell, most tend to publish lots of attention getting stuff in local papers and trade mags and their own websites. Many are somewhat large-ish chains.

So if you're a data center owner wanting to increase leases you'd hire a broker like just about any other commercial space and they'd use their connections and marketing abilities to sell it to other brokers representing orgs like Dropbox and thousands of others.

You couldn't even imagine how many repurposed telco or other purpose-built buildings are now data centers. Some of them in very city centers as well, well within residential areas. One particular in my area is multi tenant building - a grocery shop, education facilities and Equinix on top of them. Unless you are able to see HVAC systems on rooftop there's no way to tell it's data center you're looking at.

It's basically like that building from Man in Black 1

It's sad to me that dropbox still exists in 2023. I was hoping many years ago that they would have died a slow, painful, miserable death ... that they very so much deserve. But here we are.
May I ask, why?
Like Steve Jobs said, DropBox is a feature not a product. They are barely profitable and in 2023, there are much better integrated solutions for most users - GSuite, Office365, iCloud, etc.

Why for instance would I pay $120 a year for 2TB of storage when I can get Office 365 for 6 users + 1TB for each user or combine the storage for $99 a year?

Apple and Google both also offer a better value proposition.

Dropbox's desktop client is STILL the only desktop client that doesn't suck or choke on multiple git repos. Aside from syncthing it is the only program that I can count on to get file synchronization right
Why would I use Dropbox for my git repos instead of just using - a purpose built hosted git server?
You're not hosting the repos on there, you're syncing changes between computers you frequently have to switch back and forth on, without all the git command ceremony

When I was doing embedded linux development I'd frequently have to get up from my seat to go test something on actual hardware. Necessitating a laptop and a desktop.

What git ceremonies?

git add .

git commit -am “…”

On the other computer

git pull.

I know that I have all of my changes synced to and from the server as one “transaction”. With Dropbox you are dealing with eventual consistency.

And besides you get all of the affordances of purpose built tools and hosting your git repository at a place that understands git.

A couple of things:

git add ., git add -u, etc, etc... bulk adds like that are bad git hygiene

Nonconstructive commit messages like "..." are similarly awful.

And don't forget to git stash/git stash pop

Put yourself in the shoes of another developer who has to parse all that crap in the commit log. At my last job that sort of thing would never pass code review.

To say nothing of the fact that you're typing all these commands potentially several times an hour, sometimes every day, for years, and adding an additional distraction to something that I got down to a pretty tight feedback loop.

One alternative, the one I like the most, is you link your folders with some kind of sync mechanism (Dropbox) and can then freely (within limits) switch back and forth, and you can do all your surgical commits at once, at your leisure, once the code is ready to be backed up. If the system is reliable it is quite pleasant to experience. As a bonus you're not encoding every harebrained idea into your organization's permanent memory

Why not use branches, and squashing in the end? Then it is not permanent, your commit messages do not matter, but you also do not need external synchronization with a third party.
5 commands that when you forget them or when they go wrong you have to manually fix. And where when you automate them you realize on your laptop that something went wrong and you have to go back and fix it, possibly losing hours depending on where your other computers are.

Who would want that, possibly over many repos? Git isn't even working well with large files to be synced. Think about git submodules. So much can and does go wrong because Git is not designed to sync that way. Not worth the hassle for most people.

You sound like the old guys (I’m 50) who are saying who needs all this git stuff instead of just putting the code on a network share.

> So much can and does go wrong because Git is not designed to sync that way. Not worth the hassle for most people.

Git isn’t worth the hassle for most developers???

And you really don’t see the issue with non atomic syncing for code repositories using DropBox?

I get that you really really love git, but I am not you, nor is anyone else. We all have our own preferences. I don't like typing in tons of commands do so something simple when other tools exist. I like neat commits with a tidy explanation as to why they are there (preferably including the ticket/issue number), and I like them to persist through the life of the software.

> And you really don’t see the issue with non atomic syncing for code repositories using DropBox?

The only problem that ever came up in five years of this was that I could occasionally get a conflict if I switched too quickly. But that was easy to resolve, and Dropbox would always sync within 5 to 10 seconds. And no we did not have a network share to work from. The wifi in the building was horrendous so it was preferable to have everything local.

> We all have our own preferences.

Your preference literally goes against every agreed upon best practice by every organization I’ve worked for for over two decades.

> The only problem that ever came up in five years of this was that I could occasionally get a conflict if I switched too quickly

This is literally the problem that git tools solve with merging changing.

What environment are you working in where single-user file sync has the same requirements as a thousand-tenant database? Why do I need atomicity here?
Really?

If I change 10 files as one logical change. I want to ensure that when I go to the other computer I have all 10 of those changes. DropBox by definition is eventually consistent. You don’t know if all of your changes are synced.

That’s not even to mention when I use an automatic refactoring tool that can literally change dozens of files.

You wait for the little icon in the system tray to stop spinning, and you can look in the window at the sync log if you don't trust it. It would take about 10 seconds.

My whole original point to this thread was that the dropbox client can handle tens of thousands of little file changes without breaking a sweat. You could replace text in the entire codebase with one command and it will swallow it all no problem. Yes it is eventually consistent, and yes dont touch the code on any other devices until it's done, but even if you are somehow refactoring your entire codebase every day, the change will be made manifest, and quickly.

I don't know if you've ever peeked under the hood of a git repo, but it creates literally thousands upon thousands of tiny little files. Far more than whatever the repo is actually storing.

For my uses, where I would run over to a machine and maybe tweak a line or two of code on the laptop and re-run it then return to my desk, there were literally never any problems if I didn't jump the gun (and it was easy to resolve if I did).

> You wait for the little icon in the system tray to stop spinning, and you can look in the window at the sync log if you don't trust it. It would take about 10 seconds.

And this compares to knowing that when I do a git add/git commit/git push, I know my code is on the server.

When I do a git pull, I know my code is on the second computer.

> Yes it is eventually consistent, and yes dont touch the code on any other devices until it's done

Again, this is literally a problem that git was purpose built to solve and used by millions of developers every day across the industry from the smallest shop up to largest companies.

(comment deleted)
I want commit messages to matter. I want to be able to pull up a line on git blame and see why it was there, and commit messages tell you that.

In any case, I wasn't the engineer responsible for merging things to the development branch. And that person worked by doing the merge in github, without squashing anything. If you git hygiene sucked your PR gets rejected.

> I want commit messages to matter. I want to be able to pull up a line on git blame and see why it was there, and commit messages tell you that.

That’s the entire idea behind squashing commits before you merge them or request a pull request.

I’m reasonably confident the comment was using those commands as general workflow examples, and not exact, concrete commands to issue.

Nobody is suggesting you have to push this to stuff to main, use a branch if you don’t want to get in everyone else’s way or require code reviews?

No, I don't think so, git add . / git add -u are what you use when you quickly want to vacuum up all your changes and commit them in one fell swoop
You should be working on a branch anyway and doing a git squash and then merge it.

And that’s just it. When you go to your other computer you don’t know that Dropbox has synced all of your changes.

At my last job we did exactly that (no squash though), then our branch got merged to the development branch and the commit messages would be all stacked on top of each other. But we had a policy to include the jira ticket in all commit messages so the commit messages were still useful.

Imagine if it was just lines of ... and "checkpoint" and what not.

If YOU want to go back and clean up after the fact, that's fine. I don't want to do that.

> And that’s just it. When you go to your other computer you don’t know that Dropbox has synced all of your changes.

That's what I meant about reliability. You CAN trust that dropbox syncs it after a few seconds. You don't need guarantees of atomicity, you just need to be sure that you're only using one machine at a time. Which was an easy rule for me. That is the whole point.

Also, you are very consistently making a lot of assumptions about me and how I work that are incorrect. I suggest you think on this.

> At my last job we did exactly that (no squash though), then our branch got merged to the development branch and the commit messages would be all stacked on top of each other. But we had a policy to include the jira ticket in all commit messages so the commit messages were still useful.

This is against every best practice since I started using git over a decade ago.

> You don't need guarantees of atomicity

Am I really having this argument in 2023 that you should be using a code syncing process that guarantees atomicity?

GSuite. Do you trust Google to not shut it down?

ICloud. Does it have good clients for Android, Linux and Windows?

Do I trust DropBox not to implode when it’s always on the edge of profitability and losing money?

I purposefully mentioned four alternatives to not get into an OS holy war.

Sounds like you’ve never used OneDrive. The sync client sucks on every platform, will eat all of your memory and delete your documents.
I haven't used OneDrive but the iCloud Drive and Google Drive clients are similarly terrible. I one time had 5 GB of complex nested file structure in iCloud Drive and it totally froze up. I tried 2 different Mac's, an iPhone, and an iPad and none of them were able to sync up with the server to get those 5 GB out of the cloud. I had to request a GDPR to get a .zip file of my data... this was the impetus for me to switch to Dropbox although after the way they handled their layoffs I am looking to switch to Syncthing as soon as I have the time to set it up and get familiar.
dropbox is a marvelous piece of software.

I have installed it once and forgot about its existence, it’s happily churning in the background without driving any kind of attention to itself.

none of those alternatives supports linux, and on mac google’s equivalent software didn’t exist for years and deprecated not one but two clients in that timeframe.

dropbox is an example to be followed, it’s software that just works and doesn’t assume that your lifestyle revolves around them.

I agree. I've been using dropbox for years now and it just works for me. I never have to think about it and I've used it across multiple laptops and desktops over the years.

I know they tried to chase other business products over the years to little success but their core product just works.

Dropbox is thoroughly analysing every piece of your data in real time. If you rely fully on them to back up your data, just wait until they block you for some silly reason without any possibility to recover.
Hence why I use Cryptomator to encrypt my data. Apparently OneDrive marks this as ransomware and sends you scary emails but does not lock your account. So far Dropbox does not seem to care about Cryptomator at all.

Edit: Not to defend Dropbox, but just saying there is a mitigation if you need it.

In logistics, there is 3PL, third party logistics where you outsource your warehouse. Are there similar things for datacenters? Also, if it existed, would that differ from general cloud providers?
There are colocation facilities, which sounds like what you're describing?
Cloud is more like "fulfillment by Amazon". PaaS is almost drop shipping, even.