Rezoning land is extremely difficult and likely requires changes to the Master plan for the city/county. If a citizen is unhappy with a zone nearby do not move there.
If an area is zoned for industrial and someone wants to build a datacenter there without variances I don't see why anyone should be able to say no. Same thing for building condos or single-family homes in areas zoned for those. There's almost always variances though which is why there is even an opportunity to say no.
This is what zoning is for. If you live near land zoned for industrial or commercial then you can't fight it when someone wants to develop the land. If you don't want to live near something like that you shouldn't have bought/rented next to that zone.
Depends. Is the alternative a loud, obnoxious factory? Or a warehouse with a constant stream of trucks? If you live near land zoned for industrial buildings then something is going to go there eventually.
Datacenters bring millions in tax revenue (I oppose giving them tax breaks, that's a politician issue not an issue inherent to DCs) and are much less of a nuance than factories or warehouses. The increased cost of electricity is a concern but can be helped by an upfront investment, a bond for future grid maintenance, or separate utility infrastructure.
Are the datacenter concerns actually AI fears and they somehow think that stifling datacenter construction will save their jobs from AI? I understand the fear but if there's money to be made, datacenters will get built somewhere, and another municipality will reap the benefits.
For the last 3 months I've been trying to get support from Google/gRPC/GCS teams to fix an issue with gRPC which results in thousands of connections and constant connection churn. The underlying issue appears to be a constant backend priority rotation with the endpoints for the client to connect to. The gRPC team seems unwilling to address why the gRPC client is opening several hundred connections when I'm not even using the client.
I was told to open a GCP support ticket and after many messages back and forth the ticket was closed because the discussion would continue on GitHub only for the issue to be closed a few weeks later.
I've been working on a solution to automate solar+battery use to arbitrage the market. I'm on a real-time utility plan but even if you're on TOU it can save you $1+ per day by strategically planning when to use the battery and when to conserve or charge the battery. So far it's limited to a few providers and only FranklinWH batteries but I'm eagerly looking for someone to help me get Powerwall support working and other ESS. It's open-source on GitHub as well.
On Mac binaries need to be signed and notarized and Apple could stop the spread of the malware once it's identified or even detect it before notarizing it.
I wouldn't say it's without pay. It's in the job description when you're hired and the pay should compensate for that. SREs are typically paid very well.
I'm not sure there's a realistic alternative. If you need to generate a key then it has to happen somehow on unsupported platforms. You can check Enabled() if you need to know and intend to do something different but I assume most of the time you run the same function either way you'd just prefer to opt into secret mode if it's available.
It can be more complicated depending on your environment but I'd prefer instead to use a Pub/Sub pattern instead. You can have a generic topic if you want to model it like the generic table but it handles retries, metrics, scaling, long-running, etc all for you. If you are running in the cloud then Pub/Sub is something you don't need to maintain and will scale better than this solution. You also won't need to VACUUM the Pub/Sub solution ;)
What's the payment threshold? I assume you're paying 2.9% and $0.30 (or around there) for the transaction. You charge that to the customer but what if their bill is $0.01, are you really going to make them pay $0.32 for $0.01 of usage? How do you expect SaaS providers to communicate that on their pricing page? If they charge $0.01 per request and the end-user makes 100 requests their bill is actually $1.33 which means the actual per-request charge is $0.0133.
Several years ago Stripe offered more favorable pricing for small transactions but it's my understanding that that pricing is no longer available to new Stripe businesses.
They MITM the real sign-in on NPM. So NPM actually sent them a 2FA but the user entered it on the phishing site. The attacker then relayed that to the real NPM.
If an area is zoned for industrial and someone wants to build a datacenter there without variances I don't see why anyone should be able to say no. Same thing for building condos or single-family homes in areas zoned for those. There's almost always variances though which is why there is even an opportunity to say no.