quick question, why not just make
- https://github.debug or
Just want to let you know (as I mentioned somewhere): this blog link doesn't load at all if I click from here (i.e. with the refer of news.ycombinator.com).
Should be most of the info.
Interesting, awhile back both Google and AWS engineers replied to a HN thread saying TTL of 30 seconds or so works pretty responsibly and can be trusted and used. Seems to be some disagreement on this.
> 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.
I was reading https://serverfault.com/questions/279482/what-is-the-differe... to understand what exactly is unicast, anycast, etc. It seems like TCP works with unicast.
With GeoDNS users requests will be resolved to single IP address with which they can establish a TCP connection.
How, will connection establishment (TCP specifically) work with anycast ? Where request (packets ?) can be routed to different machines ? Is there some other network protocol to use with anycast ?
I was going through: https://serverfault.com/questions/616412/how-does-anycast-wo... , not sure it is the 2018 way of doing these things.
Sorry for dumb questions, network newbie here.
Really it's like asking your favorite maps app where McDonalds is - it'll know to give you results close to you, since it knows there are many McDonalds. It would make sense for you to choose the closest, but it's not enforced by McDonalds. Similarly, if I do the same and we live in different cities, we'll get different results. The end result is that we both got to different physical places by specifying the same thing, and it's up to McDonalds to make sure the menu is the same :)
TCP builds a reliable stream on top of unreliable IP packets. Since which computer is “closest” rarely changes, your stream will keep being sent to the same server. When that server stops advertising the IP, then the data will get sent to a different server which will say “I don’t know what you are talking about, Reset your stream” and the tcp connection will close, basically.
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.
> 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)
No idea why though.
Copying the URL into another tab loaded the whole thing.
I don't really have time to dig into it further...
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...
They're exactly the type of cloud service that shouldn't be used by businesses or privacy-conscious individuals.
Security's also questionable. They had an incident where one could log into any account a long time ago. More recently they were presenting a fake admin dialog to syphon the admin password on macOS and perform some admin tasks on the machine.
Disclaimer: I used to work there on the Security Engineering team.
I'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.
That's going to be worse as a function of latency and packet loss so it's far more tolerable in an enterprise environment using wired networks with tons of bandwidth and, at least theoretically, a professional support team. Over WiFi or consumer-grade internet (i.e. probably a strong majority of Dropbox's customers) the gap in experience is going to be more substantial.
The main point was just that something like SMB or NFS is not a good fit for a network which is not extremely fast and highly reliable because too many programs do blocking I/O. Dropbox works really well in that situation because it's asynchronous and that advantage was huge when they came out because everything was even worse back in 2007.
Ars covered what Facebook do about 6 years ago, and even then I think they'd been using it for a few years:
I believe Twitter does something similar too.
Not sure they're still using this
And I'm sure someone did it before they did.
Messenger had lots of standalone binaries for different functions: CS, SB, DP, etc.
BitTorrent is used in Dropbox, Twitter, MSN, etc to distribute binaries throughout the server platform, not to end users.
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.
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
Once we've got all data from that experiment: performance, cost, and flexibility included, we've decided to start building our own PoPs.