WALoeIII

The large fleet operators do care about this and do go out of their way to improve aero. Look at a UPS 18-wheeler and you'll see trailer skirts, no bug deflectors, window buffeters, etc.

Ironically, the private owner/operators are most often the ones installing accessories to make their trucks look cool and sacrificing immensely for it.

Don’t the terms of service for nearly all consumer ISPs explicitly prohibit sharing or reselling?

Completely unrealized gains or had you actually lost capital you converted to BTC?

Frequently at design time you don't know enough. This is exactly why SQL is great, it is incredibly flexible, it can also allow you to get in your own way, this is just a feature to help detect that.

This is very useful for batch or cleanup jobs.

For example, imagine a system where items are soft-deleted immediately upon user action, but not actually deleted for a few days to facilitate restoration (recycle bin).

There is going to be some nightly/hourly/scheduled job that actually really deletes these records. Initially it will have little work to do, but over time as the system grows it may become slow. Typically this would be hard to separate from other slow queries, you would have to catch it running while causing other queries to pile up. Query time isn't necessarily useful here as you may have enough I/O to cover the slow query replacing pages in the cache, but that I/O would be better serving user facing requests instead of this cleanup job.

This feature allows for the "work" it really takes to serve the query to cause it to error, instead of time which may grind down for other reasons. At this point you know its time to re-think the soft-deletion strategy, you disable the job. Maybe you sweep more frequently? Maybe you keep a look-aside of things to sweep to avoid scans? Maybe you sweep during a low-traffic time? Whatever. It buys you time to think.

I wish there were something comparable for MySQL.

This is excellent, especially the diagrams.

I'd love to see a explanation of the security implications of each flow. As I understand it the "most secure" flow is OAuth 1.0a (three-legged), but its a total pain so it is mostly avoided. OAuth 2.0 is dramatically simpler, but there are bespoke additions (Google and Facebook come to mind) that you have to handle, typically in the name of security. I am ignorant of all the implications and would like a guide.

You don't have to re-learn puppet/chef/cfengine/bash script every time. You learn it once. It requires much less effort to "maintain" than manually updating more than 1 box.

Can you please post a picture of the server so we can see all the sweet LEDs on network cards?

I want this to work, and be real, but I'm skeptical. I don't know how to change that.

MySQL + Percona.

I have similar troubles with the mobile application when in "low signal" environments. It should decide to swap to local or do a better job buffering, but having 1 bar is not going to sustain a stream.