Dropbox Tech Blog

> So swapping languages, yeah maybe, but I expect of more practical use would be the situation where you inherit a legacy codebase in an ancient version of a language or framework that hasn't been loved in a long time. I saw this so many times when doing dev team for hire work.

I'm exploring this problem space - this is a wide spread pain point across almost all companies that are older than 3 years old. I've seen this at tech startups as well as very large companies and anything in between. Dropbox is arguably a top tier engineering organization that probably manages tech debt as responsibly as can be expected and they still had to make major investments to move their codebase forward from various eras of web tech
1) https://dropbox.tech/frontend/the-great-coffeescript-to-typescript-migration-of-2017
2) https://dropbox.tech/frontend/edison-webserver-a-faster-more-powerful-dropbox-on-the-web
Everyone else is much worse off so the investment required to move forward is usually immense. This leads to full rewrites. Which is nice but error prone and sometimes entails huge opportunity costs

> Obviously you'd want to do boat loads of testing and there may well be manual work left to do afterwards, but I think it would be the kind of manual work that felt like you were polishing something new and clean and beautiful rather than trying to apply bits of sticky tape to something unmaintainable.

Agreed. In my opinion, now's a great time to get started with a semi automated approach…

This was 5+ years ago so I'm a little hazy on the details. A lot of it was just plugging into our infrastructure for config, service discovery, rate limiting, logging, etc.

- Logging the exact metrics we wanted to our metrics service. (We wrote a bunch of Lua code to do this.)

- Loading the set of backend services from Zookeeper. (We had a sidecar process that would periodically sync from Zookeeper to a config file, then call `nginx reload`.)

- Routing requests to different datacenters based on where the user's data was homed. (We had Go libraries to do this, and it would have been nice to be able to just call into that. I think we ended up putting this functionality in the sidecar.)

- Changing the way we streamed a response based on an HTTP header from the application. (We ended up writing a C module for this.)

- Changing the backend selection algorithm from "least connections" to "best of 3 random choices". Nginx added support for this in 2018, apparently.

There were ton of things we solved with Lua, which wasn't ideal. Since that's the only Lua in our codebase, everyone who touches it has to make a mental switch to remember all the weird edge cases (as you do with any language), plus 1-based array indexes, plus no static types.

Plus, any Lua or C you write has be contorted to fit Nginx's multi-stage request/response architecture. If you're writing a plugin that is meant to play nice with other plugins, then the contortions may be worth it. But for us, a proxy…

> They're always renaming and moving files and folders to keep things organized.

Ah, there we go! It's their won fault for assuming a filesystem can be used for basic file and folder changes. /s

On a serious note, it turns out that replicated filesystems as seen in OneDrive or DropBox are hard to engineer. Astonishingly difficult to get right. "Formal proof verifiers" level of difficult, otherwise customers will lose data in everyday circumstances. It's happened to me, it happened to all of my coworkers, and it has happened to your customers.

Data loss with a poorly engineered replication system isn't some rare corner-case, it's the typical case, and it is a miracle if data isn't lost!

A few years ago DropBox rewrite their sync engine and wrote a great blog article about all the complex scenarios they had to handle: https://dropbox.tech/infrastructure/rewriting-the-heart-of-our-sync-engine

OneDrive has done none of this. NONE. I guarantee it.

It loses data if you look at it wrong. If you call Microsoft Support they'll tell you not to look at it like that.

I do all of my work on local C:\ paths and copy files to SharePoint or OneDrive only if forced to collaborate with colleagues. This rare interaction with OneDrive causes data loss about 5% of the time, often enough that I notice.

Model testing and swapping is one of the surprises people really appreciate DSPy for.

You're right: prompts are overfit to models. You can't just change the provider or target and know that you're giving it a fair shake. But if you have eval data and have been using a prompt optimizer with DSPy, you can try models with the one-line change followed by rerunning the prompt optimizer.

Dropbox just published a case study where they talk about this:

> At the same time, this experiment reinforced another benefit of the approach: iteration speed. Although gemma-3-12b was ultimately too weak for our highest-quality production judge paths, DSPy allowed us to reach that conclusion quickly and with measurable evidence. Instead of prolonged debate or manual trial and error, we could test the model directly against our evaluation framework and make a confident decision.

https://dropbox.tech/machine-learning/optimizing-dropbox-dash-relevance-judge-with-dspy

> E.g. postcriptaluminumengagement vs kug45l2wx

If you pick from a dictionary of 250,000 words, that is around 18 bits. So three randomly chosen words strung together give you around 54 bits. On the other hand, an alphanumeric character is around 6 bits, so 9 of them strung together is about 54 bits.

Assuming your dictionary was 250,000 words, both of the passwords you posted were about the same quality (until you posted them - now they're again about the same quality, but much less).

> Or are there also dictionaries that contain combos of words?!

Your software just concatenates words and other well known sequences (123, zxcvbn).

Check out the great password entropy checker called zxcvbn:

https://github.com/dropbox/zxcvbn

https://dropbox.tech/security/zxcvbn-realistic-password-strength-estimation

https://www.bennish.net/password-strength-checker/

(Note: don't enter production passwords into random websites, needless to say...)

Elsewhere in the comments someone linked to this: https://dropbox.tech/infrastructure/lossless-compression-with-brotli

It looks like dropbox experimented with disabling bounds checks in their huffman coding impl, and found that using the unsafe pattern increased throughput from 224 MB/s to 249 MB/s (11%-ish faster.) We don’t even need to hypothesize about whether webp would have elminated bounds checking, we can see that other companies arrived at the same conclusion: Disabling it can be worth it if you’re quite sure you’ve gotten the up-front checking right. We can imagine that if Dropbox went to prod with the unchecked huffman implementation (never mind that that article isn’t about webp in particular), we could imagine they could easily have the same bug. And I don’t think a naive code review saying “unsafe is bad” would have stopped them from doing it: they clearly did the work to show why it’s worth it.