Related video: https://www.youtube.com/watch?v=v33nbi7gKcY

Even without that, it's possible to accidentally leak entropy into the build output. For example, readdir() doesn't guarantee any kind of ordering, so without sorting the list of files it is possible for a binary artifact (or even tar) to produce different output from the same input.

This hasn't given me great confidence in the accuracy of the reporting for things that I don't have direct knowledge of.

Though Speedtest on your cell might show your connection speed as 100 megabits/sec down, cell networks special-case video by identifying it as video and rate-limiting it to something like 1 megabit/sec. This is considered "efficient network management". For T-Mobile, this based on the plan (https://www.t-mobile.com/cell-phone-plans), they sell either "SD streaming" or "4k UHD streaming". "SD streaming" is a fancy way to express that they rate-limit identified video streams to 1 megabit/sec.

They identify video streams by watching the IP your phone is connecting to and/or the hostname mentioned in the TLS SNI header and checking if it is Youtube, Netflix, etc. Sending video content over a VPN removes their ability to understand what the content is.

It would probably be clearer that they exist if the console redirected to the regional URL when you switched regions.

STS, S3, etc have regional endpoints too that have continued to work when us-east-1 has been broken in the past and the various AWS clients can be configured to use them, which they also sadly don't tend to do by default.

Running a quick port scan from my phone against one of my machines works, so it doesn't look like they are restricting this too heavily.

And I'm not logged into this app and haven't granted it additional permissions, so I'm not sure they have any idea who I am here.

When I asked for detail about why they don't use Anycast, the Cloudfront engineering team basically said their customers care more about uptime than latency and that full Anycast was too sketchy. Apparently amazon.com disagrees, at least. I'm also happy getting much lower first page view latency out of Cloudflare.

In the most recent example, we were occasionally hitting Java heap OutOfMemory under our workloads and wanted tuning or even architectural advice. It turns out that ElasticSearch didn't limit ingestion rate to control memory pressure and was happy to accept writes under load until it exploded. Heavy users of ElasticSearch commonly have to watch ES memory pressure and throttle their own writes client-side.

I would've loved to hear these limitations from elastic.co, be offered some tips on appropriate techniques for throttling, or have them accept a feature request to better handle this server side. We never got anywhere near that level of depth of understanding our problem, after months of trying. It felt like we were talking to first-level support who didn't understand the product much better than we did.

Having given Elastic's support two tries at different companies, it doesn't surprise me that their business model is failing. Their support was _terrible_ both times; at no point were we ever in touch with anyone who seemed like they understood the product, cared about our issues, or were in any hurry to fix them. We were locked in year long, 6-figure support contracts in both cases, and issues dragged on for months until we basically gave up. We got better answers out of random Google searches and a 20 minute conversation with a friend of a friend.

AWS's hosted ElasticSearch only recently is able to handle the data set sizes we were dealing with, and their enterprise support on this (and other products) is vastly better than anything we ever got out of Elastic.

They've tried to avoid lock-in, specifically mentioning avoiding any Google technologies in their mobile apps. However, they are using Route53 for DNS, Cloudfront as a CDN, and ALB for load balancing, so there are a few commodity services they'll need to swap out.

Perhaps in another decade, MongoDB can shed its well-earned reputation for eating data.

If I feed this user-supplied keys such as IP address or cookies, doesn't this mean it will grow without bound?

While the sniffing could've happened at any Tor exit node, Tor2web is an insecure public interface into the Tor network and is uniquely positioned to sniff any traffic passing through it. Aaron Swartz could've had tor2web.org record any requests made through it and supplied any interesting results to Wikileaks.

This is called DNS64/NAT64 and has some small performance penalty. Making content directly accessible by IPv6 removes the penalty.

Interestingly, their first large-scale field tests were at Burning Man (http://openbts.sourceforge.net/FieldTest/), where there were thousands of active GSM handsets but no cell coverage. They were able to provide limited SMS support between local participants and in later tests allowed some outgoing VoIP calls.

There's a not well-known component of Google ranking that acts sort of like a slow-moving, domain-wide PageRank. And because they launched domains.google.com as a subdomain of google.com, which contains PageRank 10 pages and is therefore very trusted, the assumption is that domains.google.com is also very trusted, even though it currently seems to have no inbound links from other google.com pages.

This effect is usually hidden because it's rare to have a highly ranked page with no obvious inbound links competing on an established keyword.