lclarkmichalek

Isn’t it a fairly natural (and useful) capitalist outcome that as prices rise incentives to increase supply increase? What’s technocratic about responding to a demand change?

Hilarious. The code being produced previously was crap - it was just your crap. Baseline agents produce something similar, but can at least be guided, durably, towards producing less crap code.

In absolute terms, yep. In marginal terms, not so much. See also: paradox of value

Highways are pretty safe. The road is designed from start to finish to minimise the harm from collisions. That’s not true of urban streets

I think if you regulated coal on a linear no threshold risk model, you'd find the costs to be somewhat closer.

There's also the converse argument, to governments that look to infrastructure as the secret to all prosperity - America succeeds without infrastructure, somehow.

Natural monopolies exist, for sure. Your insurance example is odd though - insurance markets are generally highly competitive. The recent cases where we’ve seen a loss of competition in the market (CA home insurance, for example) have been driven by regulators imposing price controls.

The issue with healthcare is that providers have leverage over insurers, not that there is a lack of competition for insurance.

The usual issue is the addition of control loops without much understanding of the signals (CPU utilization is a fun one), and the addition of control loops without the consideration of other control loops. For example, you might find that your cross region load balancer gets into a fight with your in-process load shedding, because the load balancer's signals do not account for load shedding (or the way they account for the load shedding is inaccurate). Other issues might be the addition of control loops to optimize service local outcomes, to the detriment of global outcomes.

My general take is that you want relatively few control loops, in positions of high leverage.

What does this have to do with the topic being discussed?

There is a limit on reliable usage of the FS. Call it what you want. The user doesn't particularly care.

It does happen in prod. Usually due to virtual FSes that rely on get_next_ino: https://lkml.org/lkml/2020/7/13/1078

I think a fair few of them were created because they knew a bit too much about FOQS

You rather explained the value prop of this product then. The benefits of isolation without the 1 business day wait.

Personally, there's no way I'd want a customer initiated operation to trigger something like terraform or mess with DB schemas. On the security side, it would significantly complicate the permissions structure from the application to the database. And on the performance side, I have absolutely no mental model for how operations like that scale, and how trivial of a DoS I'm exposing myself to. At the same time, I love the isolation (mostly operationally, the security & privacy side is also nice) that db-per-customer would bring. If this product helps bridge the gap, then it sounds good to me.

Doesn’t astronomy already use TAI, which has no leap seconds?

Penalties for being on your phone while driving are fairly different between different countries. In the UK it's 6 points and £200 if you're caught. It's a fair deterrent

The impact on the energy market always seems a tad misstated in these articles. Datacenters are often funded through corporate power purchase agreements, committing them to purchasing power directly from the generator over periods of multiple years. Those CPPAs are often tied to the development of new renewable energy generation (ex: https://www.matheson.com/insights/detail/matheson-advises-br...). Now, that still puts pressure on the grid for transmission, raises the marginal cost of renewable energy, and in cases where the generator cannot meet demand, presumably increases demand on other generation sources. But it makes the “40% of energy being used by DCs” stat seem a little misleading - a reasonable amount of generation exists because of these DCs.

(I work for Meta, who’s Clonee datacenter is mentioned in this article)

Never used Bazel in my life, so while I can appreciate your passion, I guess I don't share your perspective. Generally the pattern I've seen has been providing a skylark interface to allow folks to define rules or configurations, which are then consumed through by whatever service via starlark-rust or similar implementations.

In a competition with sky/starlark, I feel skylark would win here. “Safe subset of python” is what a lot of people presented with this problem want, and skylark gives them almost exactly that.

OTOH, curious to see what advantages Pkl gains from not having the constraints of maintaining familiarity with another language.

I mean, they can and should be both. Local decisions can be cheap, and very simple to implement. But global decisions can be smarter, and more predictable. In my experience, it's incredibly hard to make good decisions in pathological situations locally, as you often don't know you're in a pathological situation with only local data. But local data is often enough to "do less harm" :)

This still isn't what I'd call "safe". Retries are amazing at supporting clients in handling temporary issues, but horrible for helping them deal with consistently overloaded servers. While jitter & exponential backoff help with the timing, they don't reduce the overall load sent to the service.

The next step is usually local circuit breakers. The two easiest to implement are terminating the request if the error rate to the service over the last <window> is greater than x%, and terminating the request (or disabling retries) if the % of requests that are retries over the last <window> is greater than x%.

i.e. don't bother sending a request if 70% of requests have errored in the last minute, and don't bother retrying if 50% of the requests we've sent in the last minute have already been retries.

Google SRE book describes lots of other basic techniques to make retries safe.

I wonder why they didn't do that in the 14 years since VPCs were introduced?

Bronze age collapse wasn't exactly great though.

It models wiggling forward. It models wiggling backwards. And occasionally it models fucking itself. That’s it.

Unbundling is a real thing, with some pronounced second order affects. The first order effect of charging for in flight food service and checked bagged is purely redistributive, but rise of low cost, heavily unbundled airlines has increased the total market for air travel, increasing net economic activity in the sector.

Setting up a hardware platform of this kind that is useable in production costs significantly more than a couple of million

There are also things that are unmitigated improvements.

A bit before my time, but maybe a physical capacity order, to a non fungible pool. The infra is quite different now (mostly to avoid this kind of inefficiency)

I mean, that's not true in the general case. That'd be incredibly wasteful.

(Work at Meta, mostly on capacity)

There are an incredible number of websites that have incredible read:write ratios. I would suggest doing everything you can to avoid writing to the database on every request.