• she/her

System of five. Currently we mostly reblog stuff from friends, but we may also post our art when we've got the spoons to make some.


NireBryce
@NireBryce

if you really want to strike a blow to Google you gotta stop vilifying printers because the single biggest use of Google docs in aggregate is sending office documents to people when both parties are unwilling to use a printer, scanner, or fax.

and, why? a fax has a certain gravitas.

a fax is a threat.


catball
@catball

fun fact regarding printers and blows against google:

when google discontinued the Cloud Print API and they began turning the service off, they noticed a large, sustained increase in traffic to the defunct api

printers with Cloud Print would normally reach out to the google servers to check connectivity, transmit metrics, etc

a huge number of these printers operated under the assumption that if the Cloud Print API was down, it was probably an intermittent network issue, and that it should try again after a short time without getting a reply

the timeout periods were short, static intervals (as opposed to like exponential backoff) and would retry indefinitely

by shutting down the cloud print API, printers globally began impatiently and relentlessly pinging the api. and the google load balancers had to read every request and decide to drop it.

google caused a huge, costly DDOS attack on themselves. People don't often update the software on their printers, and getting vendors to patch this would be time-consuming and difficult. The only end in sight was when every printer was eventually unplugged and thrown in the garbage

Quickly, a stub service was put in place to respond to connectivity and update checks with a polite acknowledgment. The time between periodic connectivity checks was far longer than the time between reties for failed requests. It was decided that it would be much cheaper to run the stub indefinitely than to bear the brunt of eager printers aching for acknowledgement from the cloud print api


You must log in to comment.

in reply to @NireBryce's post:

in reply to @catball's post:

this even happens with first-party SaaS systems. i saw a self-DDOS happen because a mobile app team decided to constantly poll a backend service for updates for a feature, regardless of whether that feature was even enabled by the user of that device (actual users of that feature were a very small percentage), because the normal server-driven push notifications were deemed to be too slow