Maybe I'm being naive, but the policies needed here feel quite simple.
First, since data centers likely need some kind of treated (i.e. demineralized) water, and they want to use local municipal supplies, then they can do so only if they pay full market rate for that water. I would push for them to pay 1% to 5% above market rate to help offset other costs, but market rate at minimum. At no point should homeowners and/or residential customers subsidize this usage.
Second, commercial users (including data centers) should only get water produced by treatment plants in excess of residential needs. Plants can only treat so much, pipes can only carry so much, and priority goes to residential first.
Third, ground water is off limits for any commercial/industrial evaporative cooling uses. If data centers want to cool that way, then they need a different source of water.
Well, even if you're right, try proposing those bills and then reckon with the deafening wails of the "free-market-big-government-taxation-is-theft" crowd. And the politicians that are in the pockets of BigCo that will say that kind of stuff.
Policies are simple a lot of times. Politics against the interest of big money isn't.
If they pay market rate, the clearing price will go up making things more expensive for everyone. If they go off-grid they make the machines needed to produce water or electricity or whatever more expensive. If they borrow money, they make government bond yields go up and cause governments to start thinking about cutting pensions and stuff, not to mention increased mortgage rates for whoever wants to buy a home or is on a variable rate mortgage. There's no world in which this AI stuff doesn't increase costs for the rest of us.
The main thing is evaporative cooling is incredibly wasteful. The water should be returned to the system, if it's going to be used, and not sent into the atmosphere. This is especially important in regions with limited access to water, which, ironically, is where many data centers seem to be located.
I really hate lighting in modern offices. If there was one thing that folks actively worked to improve I would choose lighting. Having lights with a broader spectrum would go a long way in reducing eye strain and general fatigue, while likely allowing the lights to actually be brighter. Unfortunately I don't see this changing anytime soon.
I so agree! As someone into photography, light is everything. It can even turn oversaturated fabrics into more uniform and less screaming colors. The diffusion of the light flattens things, but the interesting angles create interesting shadows and shapes. So much can be done with light, but so many offices have the boring flat ceiling lights. It seems to be hard for the office space designers to invest a bit of time into islands that can have lamps. What's interesting is that many libraries seem to be more accomodating in this regard.
Either way, light is everything, but it is treated like an afterthought.
Bummer the link is broken. I read via UnfitFootprint's link.
This feels both like a good write-up, but an argument for why you often need to reach for multiple solutions when creating distributed system. Sure a fallback can have issues, but in the example given (website -> cache -> db) I can't help but feel that a circuit breaker pattern should also have been in play to catch other types of failures.
Distributed systems are dynamic systems and rarely will one type of solution or pattern cover the entire space of possible failures.
By the logic of the article, a circuit breaker for the DB query would act as a fallback for the fallback. A path that would be executed in production even less frequently, and which would be more difficult to test for its effectiveness. Surely, you can test whether the circuit breaker is triggered, but would it reduce DB load enough to keep the fulfillment system running?
Precisely! And this is true not just for managers but also higher-level ICs. Its ok for Senior and below to be team focused, but moving to the next level means broadening scope and that means talking with people, regularly!, outside your immediate team.
Location: Minneapolis, Minnesota, United States
Remote: Yes (10+ years working remote) (or hybrid/on-site in Minneapolis or St Paul)
Willing to relocate: No
Technologies: Scala, Java, Typescript (Effect TS), Python, C/C++, PostgreSQL, AWS, HLS, Real-time ABR
Resume: https://drive.google.com/file/d/19O9A3zMulkPWb61Ng9FsSZbCPHZms_Qy/view?usp=sharing
Email: mark.kegel@gmail.com
I used to work for the company that owned and operated GovDeals. That was a really interesting experience. I remember one of their many companies host the listing for and processed the sale of an oil refinery (or something similar) just like something random on ebay, except this sale was many 10's of millions of dollars.
I don't really like this article. There isn't anything particularly noteworthy to noticing that some computations have outcomes that allow some form of recovery, and other outcomes do not.
But there are some obvious follow up questions that I do think need better answers:
Why is recovery made so hard in so many languages?
Error recovery really feels like an afterthought. Sometimes that's acceptable, what with "scripting" languages, but the poor ergonomics and design of recovery systems is just a baffling omission. We deserve better options for this type of control flow.
Also, why do so many languages make it so hard to enumerate the possible outcomes of a computation?
Java tried to ensure every method would have in its signature how it could either succeed or fail. That went so poorly we simply put everything under RuntimeException and gave up. Yet resilient production grade software still needs to know how things can fail, and which failures indicate a recoverable situation vs a process crash+restart.
Languages seem to want to treat all failures as categorically similar, yet they clearly are not. Recovery/retry, logging, and accumulation all appear in the code paths production code needs to express when errors occur.
Following programming language development the only major advancements I've noticed myself have been the push to put more of the outcomes into the values of a computation and then further use a type system to constrain those values. That has helped with the enumeration aspect, leaving exceptions to mainly just crash a system.
The other advancement has been in Algebraic Effects. I feel like this is the first real advancement I've observed. Yet this feature is decried as too academic and/or complex. Yes, error handling is complex and writing crappy software is easy.
Maybe AI will help us get past the crabs at the bottom of the bucket called error handling.
First, since data centers likely need some kind of treated (i.e. demineralized) water, and they want to use local municipal supplies, then they can do so only if they pay full market rate for that water. I would push for them to pay 1% to 5% above market rate to help offset other costs, but market rate at minimum. At no point should homeowners and/or residential customers subsidize this usage.
Second, commercial users (including data centers) should only get water produced by treatment plants in excess of residential needs. Plants can only treat so much, pipes can only carry so much, and priority goes to residential first.
Third, ground water is off limits for any commercial/industrial evaporative cooling uses. If data centers want to cool that way, then they need a different source of water.
Did I miss anything?