TurningCanadian

From the page you linked to, it depends on the MIME type of the POST

> "[...] for HTTP methods other than GET, or for POST usage with certain MIME types"

MySQL makes some of the same assumptions about memory. You have to tune it if you want optimal performance.

https://www.percona.com/blog/2016/05/03/best-practices-for-c...

You clearly have never talked to GCP support. They're in a different league from AWS support.

"Known vulnerabilities in application libraries are just as risky as those in the server dependencies, and the responsibility for addressing vulnerable app libraries falls to you – the function developer."

This isn't any different from the non-FASS world, but it is a good reminder that you still need someone doing regular maintenance.

Why use TIFF? It supports layers, so I'm not sure it'd guarantee that redaction blobs are effective.

Give the marketing team a performance budget to work within?

They might be able to crossreference the result from their crawler with metrics from Chrome users that opt-in.

Maintaining your own server might be hard because there's no incentive to make it easy for technophobes to do. If there were software that was dead easy to use, there'd still be roadblocks: NAT, $ for a domain, ISPs blocking port 80, etc.

As a tech worker straddling the border with non-gold-plated coverage in the states, Canada's medical services all-told are FAR cheaper.

Their competitors that sell info will be cheaper, so there's a good chance that the trustworthy ones will be pushed out of business. Then you're left with only cheaters, but you won't know that at the time. You'll only find out that everyone is cheating long after your info has been sold.

It's sacrificing the open web in exchange for a is-this-fast indicator. If the search engine just made note of the site's speed during its crawling, and made that information available to the user, then sites everywhere would find their own ways of speeding up their whole site instead of just some proprietary search result.

Sorry, I meant that as an additional reply to

"If so, this change amounts to not protecting user privacy as much as insisting that only the NYT can monetize their users' privacy."

The cookie is now hidden from the MITM. Before, not only could they see what pages you see, but they could login as you.

They'll come around. And in the meantime, at least Chrome users can benefit.

Is that better in any way than using example.com?

And your session cookie..

Random coffee shop / hotel / etc wifi owners and other users on the network will only know that you're reading nytimes.com, and not which particular section/article.

I wonder why browsers don't use subresource integrity to share cached items across origins. Maybe they do? If hash collisions is a problem, they could limit it to certain hash algorithms.

Side note:

In addition, Google Public DNS engineers have proposed a technical solution called EDNS Client Subnet. This proposal allows resolvers to pass in part of the client's IP address (the first 24/64 bits or less for IPv4/IPv6 respectively) as the source IP in the DNS message, so that name servers can return optimized results based on the user's location rather than that of the resolver. To date, we have deployed an implementation of the proposal for many large CDNs (including Akamai) and Google properties. The majority of geo-sensitive domain names are already covered.

from https://developers.google.com/speed/public-dns/faq

Likely need to enable and/or tune opcache

I skipped around a bit in the article, but didn't see them consider having database updates simply trigger a cache invalidation (i.e. set it null) of the denormalized data instead of doing a full recomputation every time the data changes. That way you only pay the price when you need it, and it still allows for caching. You can prewarm the cache with a cron while still allowing for ondemand calculation if the cache is cold.

> Personally, I only care about when the code hit master.

So just look for the merge commit on the master branch that brought it in.

By having 300 separate commits (which you were doing anyway) it helps us know what your thought process was on the day that a given line changed. Maybe you were refactoring function X to do Y. If you don't mention that you were accounting for changes happening in someone else's branch, then we know we have to look closer at that code. Without the individual commit, all we know is that giant-project-x was accomplished with this commit, and the change to that line may or may not have the necessary update.

The TOS that Google follows is published in the robots.txt file. If you don't want Google to scrape your site, then that's all you need. There's no double standard.

I'm curious to know whether there's a difference if you break it down into mobile vs desktop users.

AFAIK Apache Traffic Server does zero-downtime reload http://trafficserver.readthedocs.org/en/latest/reference/con...

If Google had been less afraid of the GPL, Samsung would've been forced to share-alike. Instead, they can just grab the fruits of Google's labors, put some icing on top, and leave Google with a lesser product.