Google is certainly the wrong target, but they are very well placed to capitalise on any forthcoming law. The correct way of dealing with content is, with sufficient justification, to require that it is removed from the sites. Who knows better than Google where that content is? What better influence to comply with such requirements than "you may be removed from Google". Search engines are in prime position to capitalise on any sort of mandate to remove or issue take-down notices provided there's a small fee involved. An analogy is credit rating - they don't lend the money but they have influence over those that do. You need to clear your name with the agency not the lender.

You actually should have your web "site" running in a DMZ with no connections other than back to your service layer. It is this layer in on a different LAN that has access to and DBs (ideally just enough, but in practice often to the entire DB) and other resources. The services can only perform operations intended to be used by the site, so unless there's a "give me a list of all users" requirement, it's not going to happen.

So in a way, yes, there is a request to & from web servers but it's software not people :)

It was not a manufacturing problem. It ran off a cliff because the development teams used two types of abacus and fucked up the calculations.

Maybe you can answer the question prompted by the post above - why were the intra-datacentre comms links ever unencrypted?

Exactly. No different to a fuel warning light. These things are not magic. Whatever it is, you need to keep your equipment maintained and functional if you have any expectation of being able to use it.

Or combine the two. Parking meters with an option for recharge (or chargers with an option for just parking if you prefer).
You could even use the car as a battery and sell power you harvested overnight back into the grid during the day in exchange for parking costs.

Very nice. Don't forget also that once introduced, each iteration is then actually hailed as something revolutionary rather than something missing and that was solved/commonplace years ago.

Spot on. What many managers see is people working long hours because they're excited and motivated about what they do. This in turn gets things done. That somehow translates as "working long hours is what gets things done". They completely overlook the true reason for the productivity.

Price of electricity matters. If your total electricity cost is $1000 per month you'd almost certainly find something else to concentrate on. If the same data centre costs $100,000 to run you'd be stupid not to look at it. Agreed the PUE doesn't change with cost, but the relevance does.

I always maintained that if I could persuade our testers to learn programming, we'd have much better software. In my experience, testers think about requirements, products, edge cases and scenarios a lot deeper than the devs. They also learn more about the business and how the product might be used.
In fact, now I think about it, many developers barely know the minimum tech to get an end-to-end application up & running, let alone all the stuff testers do. How many devs choose not to even learn about basic security, databases, algorithms (hash tables or unique dictionaries instead of generic lists) . These devs just know C#, HTML & CSS , jQuery (or whatever) and think it's enough.
Give me a good tester with an interest in programming any time.

That's pretty much true of every computer. Just because someone only ever uses Outlook, Word, Excel & IE doesn't mean it's not a computer (or a consumer device for that matter).