As far as carbon neutrality goes, you’re drawing a conclusion about the value based only on the first derivative. If you hold livestock numbers constant (they’re increasing, alas, but let’s not worry about that yet) then there will be a rough equilibrium. However, the gas is in the atmosphere for some time until it gets fixed back into the soil, and continues to have a warming effect in the meantime.
Any carbon tax has to punish emissions. Net zero emissions isn’t enough anymore.
It’s both. I know banking and insurance companies that offered relocations last year, but IMO that’s to save effort hiring for the EU offices rather than moving existing jobs. Moving an entire department isn’t practical.
Practical forgery attacks against an arbitrary client are hard, but configuring a public WiFi AP to intercept your favourite repeating-digit DNS server is trivial. Lots of people use public WiFi!
In such a scenario a VPN is a more secure answer than DNS-over-TLS, but this isn’t a realistic answer for the average user. It has to be something that is free and easy to enable.
The two most common scenarios in my 3 years of experience are fan-in and first-error (executing stuff for their side effects only). It’s easy to mess up the latter, but golang.org/x/sync/errgroup is usually what you want.
Regarding the leap second bug, I suspect this is an example of perfect being the enemy of the good.
It appeared to me that the golang devs believed so strongly in the superiority of leap second smearing that waiting for everyone to adopt it was better than compromising their API or the implementation of time.Time.
The most generous interpretation is that it can work - if you're careful, and if you're using a kernel from 2016.
While I trust the author to do this (thankfully, as he's my coworker) there is a lot of Linux software that doesn't, even assuming it was updated in the last year and you're running something vaguely bleeding edge (not Debian).
There is only one listener bound to star, instead of 16k listeners for every IP. Thus, the hash bucket mapping to port 53 has only one entry instead of 16k.
It works out the same for the application: 1 fd or 16k fds doesn't really matter if you're using epoll, and that single fd can accept connections to any of those 16k IP addresses.
1. It's a charity tax; you have to convince people to incur the cost of Tor (i.e. CAPTCHAs everywhere) for activities that don't require Tor.
2. You can't neutralise a poison by diluting it.
Firstly, from the operators' POV, if there's a widespread agreement that people use Tor even though they don't need to, then they know voluntary users can be pressured not to use Tor through sheer inconvenience. Even if you wanted to boycott a service that blocked Tor, it's notoriously hard to make good on that threat unless you wield a lot of power or annoyed a very large number of people. So the consequences are minor.
Secondly, the percentage of malicious Tor traffic is a red herring. What operators care about is the origins of malicious traffic. If 50% of your attacks come from one particular country (or Tor) and the cost of losing that traffic is less than the cost of that malicious traffic, there is a real incentive to block that traffic. Combined with the first point, the cost of losing voluntary Tor users is insignificant if they can easily choose not to use it.