Also, there are APIs for acquiring real-world mailing addresses inside of "subdivided" warehouses. The only way to verify that a person isn't a bot is to make babies with them.
I'm sure Azure has great stats on paper, it's not the simple, easy-to-measure data that concerns us. I'm also sure that Azure is currently treating their clients really well, in the spirit of "the first hit is free". What is concerning, is not the effects of their current actions, but rather what their current actions say about their future plans, given MS' history of "embrace, extend, extinguish".
With MS, the EEE process should be your null hypothesis when you are trying to predict their behavior.
Having said that, I am not against the idea of taking advantage of an opponent who prostrates themselves, just make sure that you can safely extricate yourself from the trap. If you want to deploy on Azure, make sure it's a multi cloud deployment with some insulation above the infrastructure, like Mesos or Kube. Which precludes using the more specialized services, but seriously, who pipes unencrypted data through 3rd party message queues? That's just crazy.
In Qatar, which has a national firewall, I was able to use Tor to browse torrent sites, and then use a regular bittorrent client to fetch the contents of the magnet links (encrypted connections only). That worked great for the few years that I was there. The Qatari internet was a fair bit faster than what I am used to from Canada, about 30 - 50 MB/s at max torrent.
A CEO once told me, "If you owe someone $1 million, then they own you. If you owe someone $1 billion, then you own them." I think that the orgs who are owed by US are primarily concerned with maintaining the status quo, rather than gutting the golden goose.
It reflects poorly on us that this is being downvoted. The parent shared a simple cautionary tale without baiting or flaming or anything like that. It is a good thing, to be aware of the worst case scenario; IME, projects that fail badly do so mainly for people-reasons / org-reasons, just like this.
Yep, and personalization and A/B testing can be accommodated with query params. By whitelisting those AB params in the caching layers, you can mostly prevent a performance difference between A and B, something that may have messed up our results with a 3rd party AB testing service.
Yes, just like Intel. We engineered our way into this, we'll engineer our way out, and then smooth it all over with more engineering. Entropy wins again.
I've been ranting here occasionally about the infuriating unprofessionalism of a web app that can't operate without JS. There is very little that you can do with JS that can't also be done with the help of a server, unless you start making up overly-specific requirements about what technologies are used, or writing user stories for robots. As a diehard NoJS guy and a developer who uses React professionally, my community's willingness to accept of the problem, and obliviousness to the solutions established by the React devs themselves, are pretty embarrassing. And it's not like I hate the language, Node has been my go-to application server for years now (Clojure is displacing that for me, but I digress).
Last year, I was building a simple SVG based chart dashboard for internal usage. Being a NoJS guy, I would sometimes disable JS while developing, on purpose or otherwise, and aside from forcing me to manually hit refresh in the browser, things generally worked. I added a couple links (styled as buttons) for zooming, to supplement the JS based drag-window zoom, and let the browser scroll the potentially very wide SVG chart within a div. If necessary, I could have even embedded the whole thing in an iframe, to avoid triggering whole page reloads, but our caching story was tight enough to compensate. Also, the React-rendered SVG represented the bulk of the markup on the page anyway.
Interactive visualisation, no JS needed. It added maybe an extra 10% to my workload (we already had the SSR stack), and helped me to avoid a variety of little glitches that plague many client-only apps, glitches that users learn to tolerate with mild disgust. The satisfaction of seeing our in-house dashboard pop up "instantly" with data, while Parsely and New Relic were still churning spinners or stuttering while waiting on JS, or even waiting for initial data after waiting on JS, was very cathartic. TTI can equal TTR, we have the technology, we've had it for a decade or so.
The parameter you are looking for is delta-V, the total change in velocity that the craft can accelerate to. It relates to inverse specific thrust, which is the parameter discussed earlier, comparing slow heavy exhaust to fast light exhaust.
Yeah, we should probably not do this in LEO, where orbits decay and half of the potential acceleration vectors lead back down to Earth. Fortunately, it takes a lot of energy and precision to de-orbit anything heavy that is in geosynchronous orbit or beyond.
If the fissile material could be acquired by asteroid mining, then it would never need to pass through the Earth's atmosphere. I know that still sounds way out there, but I think that uranium or thorium would actually be a great material for kicking off asteroid mining. A small amount will pay off in a big way, it is a very dangerous thing for humans to mine on Earth, and, like the parent mentioned, we really don't want to fly it around where it can fall on us.
In a small toroidally shaped universe, your radio is also your memory. All emissions eventually return to their origin, but you can reorder memory transmissions by moving while the data is in flight.
Wow, just thinking about C++ while slacking, was enough to inspire a solution to a race condition in my Clojurescript project.
Earlier, I made some notes and walked away from the problem, because it was getting frustrating. Then, while I was checking this out, I started thinking "Imagine how complex this would have been if I had done it in C++" Then the immediately following thought was "Well, in C++, I would instead build it like so, because it needs to be thread safe." Problem solved, obvious-in-hindsight solution.
Even though my problem wasn't caused by a low level threading mistake, thinking about the problem in the context of a more primitive tool helped me to better understand how my own tools are working.