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.
Or I can fight to rezone that land because a single pass of zoning, shockingly, isn’t fucking permanent.
Y’all do vaguely understand how government works, right? Planning and zoning is a core function. This is hardly rocket science, except, I suppose, when your vibe-code shit start-up depends on building data centers in other folks’ backyards.
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.
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.
I can't find an official source, but I suspect the blast radius isn't limited to the AZ.
I have systems running in us-east-1, and over the course of the incident, I noticed unexplainable intermittent connectivity issues that I've never seen before, even outside of az4.
spent the evening looking at SLI graphs waiting for the region to blow up but it never did. only a few envs across many had some degraded EBS vols in the single AZ. it was absolutely a single az (use-az4).
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 suppose so. The company invested pretty heavily in security tooling, though I think it wouldn't have been hard to do something to bypass the security for internal servers.
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've downloaded and installed too many packages where the developers didn't bother with this, but I uncritically went to Mac's security settings to let it do its thing anyway.
I don't know if developer utilities can be distributed through the app store, but they should be so that Apple can review them properly. Criticisms aside, the iOS App Store and the iOS security model has been the best thing for software security (especially for lay-people), ever.
Apple controlling CLI utilities is a bad supposedly good idea.
They can’t stop themselves from tightening their grip ever tighter, and always want to ensure you have no functionality above what they deemed sufficient.
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.
This is not what secret.Enabled() means. But it probably illustrates that the function needs to be renamed already. Here's what the doc comment says:
// Enabled reports whether Do appears anywhere on the call stack.
In other words, it is just a way of checking that you are indeed running inside the context of some secret.Do call; it doesn't guarantee that secret.Do is actually offering the protection you may desire.
One of the goals here is to make it easy to identify existing code which would benefit from this protection and separate that code from the rest. That code is going to run anyway, it already does so today.
