Oh, right, I'd forgotten about https://news.ycombinator.com/item?id=9224 It's definitely comical in retrospect for not even understanding the state of the technology at the time.
I know the comment is today taken as the high of HN negativity, but to me the comment seems very reasonable.
- Back then there were FTP clients that automatically kept server and client in sync, which is the main feature of Dropbox. Dropbox adds a website, but Windows Explorer already supports FTP nativly. Of course easily creating shared links turned out to be a major thing, but I don't think we can blame people for not predicting that (especially since public folders are a feature of FTP servers, so it's not a new feature, just a lot more convinience). And of course Dropbox makes all that convinient and approachable, but that's easily overlooked by the technical user.
- The comment points out that contrary to the headline Dropbox will not replace USB drives. And here we are, a decade later, and Dropbox indeed didn't replace USB drives.
Of course in hindsight it's clear that Dropbox was a great idea with great execution, but that wasn't obvious at the time at all.
I was just thinking that having used various FTP/SFTP-as-a-filesystem, not to mention NFS and SMB, over a decade or so before Dropbox arrived made the sales pitch immediately obvious: do you want everything to be slow and unreliable, with frequent jank even on fast networks, or not?
This has to be HN at its worst. Reducing a complicated file sharing and collaboration tool to an insecure and highly technical protocol.
Dropbox: I can upload a file super easily and share a simple & secure link with someone who just has a web browser.
FTP: I can upload a file to an FTP server I've either configured on my server or rented online. I'll then provide an FTP url to friend with instructions on how they should login and what FTP client they should use on their chosen device.
EDIT: This could be sarcasm, if I didn't pick up on then feel free to downvote me to hell.
EDIT 2: Thanks to the comments, this is sarcasm. I messed up. Sorry rakoo.
It does indeed, but I feel like it's an important part of HN (some people arrive here allthc time) and retrospecting about it is something all engineers should do, so I felt the need to point at I again.
It's probably in reference to a HN comment on Dropbox's original announcement post that said the product was a glorified version of Rsync. To be fair to that commenter, he congratualted the company in it's IPO post.
That's an interesting implication. If they distribute the same cert so widely geographically, any host country could technically request it for "lawful intercepts".
You don't have to keep keys on boxes in random countries if you use a TLS oracle [1]. Another option is deploying the keys onto an HSM and pointing your frontends at that.
I wonder which definition of "Edge" is going to win out because right now it's being used interchangeably to mean either: 1) CDN or 2) On-premise machines/IoT.
Are these really two competing definitions or just manifestations of the same concept? What is considered an edge device depends on the boundaries of whatever network is under discussion.
I've never heard it used with that second definition. It's pretty consistently used to refer to running close to the user, as opposed to having a big data center which most of your users aren't near.
The second definition could be a confusion of ownership — i.e. are you paying a CDN to do higher-level service or running the services yourself?
> Most CDN providers will provide their services over a varying, defined, set of PoPs [...]. These sets of PoPs can be called "edges", "edge nodes" or "edge networks" as they would be the closest edge of CDN assets to the end user"
I work on an Edge Platform team as part of an Edge Foundation that manages both external CDN and internal Tier 1 WAF/Ingress systems. We do Edge computing at both CDN and Tier 1 layers via tenant plugins running LUA/go. We also have an SDN team building Tier 2 solutions, so basically systems operating at the edge of each layer of the HTTP stack.
Those aren't completely distinct. We've started calling the edge everything between app servers and user devices. The boundary is "where your users are in control", but the edge itself is pretty fat.
This article is about neither of those things, though. https://en.m.wikipedia.org/wiki/Edge_device is the term that's relevant to this article. It's about the network edge itself.
Would be great to know how exactly they store all the customer data on this edge network. Is it encrypted with a customer-specific key? If yes, when and how do they decrypt it?
> DNS TTL is a lie. Even though we have TTL of one minute for www.dropbox.com, it still takes 15 minutes to drain 90% of traffic, and it may take a full hour to drain 95% of traffic.
Interesting, awhile back both Google and AWS engineers replied to a HN thread[1] saying TTL of 30 seconds or so works pretty responsibly and can be trusted and used. Seems to be some disagreement on this.
It really depends who your clients are. If they are servers, 30s can work okay. If they are end users, caching happens all over. It's a huge PITA, especially since you'll run into podunk ISPs that have their own custom caching setup, but you have a customer with a shop there. Not that I'm still bitter.
It really depends on the clients, here is an excerpt from the article:
> Here we also need to mention the myriad embedded devices using Dropbox API that range from video cameras to smart fridges which have a tendency of resolving DNS addresses only during power-on.
They did, but I imagine it was really expensive vs building their own stuff at that scale. Plus they probably don't want to be reliant on a competitor in many ways.
They were using AWS. They have moved off of it within the last couple years because they now have the scale where it makes financial sense to build their own infrastructure and also to provide a better, faster service. They've had improved read/write + sync speeds since switching over to their own infrastructure. Having those checkboxes in a table showing that you have the fastest cloud storage works really well in B2B, which has been a big focus for them recently.
Good find, I like this pattern. I could see a niche startup or open source solution providing this as a service, similar to statuspage (acquired by atlassian). It could also help keep the layout consistent, for user familiarity.
50 comments
[ 2.4 ms ] story [ 77.8 ms ] threadI'm eagerly waiting for the blog post about how bazel and torrents are used.
- Back then there were FTP clients that automatically kept server and client in sync, which is the main feature of Dropbox. Dropbox adds a website, but Windows Explorer already supports FTP nativly. Of course easily creating shared links turned out to be a major thing, but I don't think we can blame people for not predicting that (especially since public folders are a feature of FTP servers, so it's not a new feature, just a lot more convinience). And of course Dropbox makes all that convinient and approachable, but that's easily overlooked by the technical user.
- The comment points out that contrary to the headline Dropbox will not replace USB drives. And here we are, a decade later, and Dropbox indeed didn't replace USB drives.
Of course in hindsight it's clear that Dropbox was a great idea with great execution, but that wasn't obvious at the time at all.
Dropbox: I can upload a file super easily and share a simple & secure link with someone who just has a web browser.
FTP: I can upload a file to an FTP server I've either configured on my server or rented online. I'll then provide an FTP url to friend with instructions on how they should login and what FTP client they should use on their chosen device.
EDIT: This could be sarcasm, if I didn't pick up on then feel free to downvote me to hell.
EDIT 2: Thanks to the comments, this is sarcasm. I messed up. Sorry rakoo.
https://news.ycombinator.com/item?id=9224
Unfortunately, similar parodies are posted as a reaction to many Dropbox-related posts, so gets a bit repetitive.
For completion sake and closer on the story, here's the same account 11 years later reflecting on himself: https://news.ycombinator.com/item?id=16661824
Ars covered what Facebook do about 6 years ago, and even then I think they'd been using it for a few years:
https://arstechnica.com/information-technology/2012/04/exclu...
I believe Twitter does something similar too.
1. Here is CloudFlare's implementation (and pats themselves on the back for "inventing" it): https://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-tec...
The second definition could be a confusion of ownership — i.e. are you paying a CDN to do higher-level service or running the services yourself?
Wikipedia's definition primarily focuses on the local/IoT version as a distinctly different from utilizing a CDN.
https://en.wikipedia.org/wiki/Content_delivery_network contains
> Most CDN providers will provide their services over a varying, defined, set of PoPs [...]. These sets of PoPs can be called "edges", "edge nodes" or "edge networks" as they would be the closest edge of CDN assets to the end user"
There's also https://en.wikipedia.org/wiki/Edge_device which uses yet another idea of what The Edge is (in this case routers to a bigger network)
Interesting, awhile back both Google and AWS engineers replied to a HN thread[1] saying TTL of 30 seconds or so works pretty responsibly and can be trusted and used. Seems to be some disagreement on this.
[1] https://news.ycombinator.com/item?id=17553043
> Here we also need to mention the myriad embedded devices using Dropbox API that range from video cameras to smart fridges which have a tendency of resolving DNS addresses only during power-on.
Once we've got all data from that experiment: performance, cost, and flexibility included, we've decided to start building our own PoPs.