On NT, this style of problem would be slightly less likely. The job object, which is NT's memcg equivalent, is a handle based object that naturally goes away when the owning process dies.

I also bet systemd would have native mechanisms to clean this memcg state up if it was used for this purpose. Seems like a bug in the AWS ecs code.

Responding to the actual article: it seems like the author simply has a different set of values than what is assumed by the conventional incentives that he sees around him. If you choose your values then you can also choose your incentives.

Still I think their solution is a bit weird. I'd want to commit the reservation transaction with inventory decrement along with a payment key and then use a different transaction to drop the reservation when the transaction completes. If the transaction does not complete in a timely manner you probably need to query external systems anyway to resolve whether the payment actually occurred or not.

They talk about lock contention in this case, but I also wonder about latch contention since these rows are adjacent. If it's a small transaction that's not interactive, does mysql resolve it with just the latches on the needed tables?

The internal representations of this state and its projection back out to human language wouldn't be as concise as that of a practitioner or team that develop their own verbiage and ontology over time molded to their system.

This verbosity might get better as we figure out better ways for agents to learn long term and use that knowledge to adapt to the users and projects over time.

There might also be some good harness improvements we could consider like forked output streams or multiple long lived filter subagents to ensure that output appropriate for thinking is separate from code output and separate from output given to the user driving the session.

However the general idea of using hysteresis for signal conditioning seems transferrable to other non physical control systems. I suspect that people who think about what the article is saying rather than reflexively declaring it to be slop could learn something useful.

The ai doesn't have the same incentives as a human. It can also be applied to the repro where it exists.

Your mechanic analogy is a bit inapt. Sure they're experts and can replace your engine much better than you can. But tracking down a non obvious system level bug like this one is much less repeatable and much harder because the problem has already been filtered through a lot of reviews and testing. As a system becomes mature, the bugs become harder and harder individually to track down.

Claude is probably not right about the root cause here and is probably bsing, I agree. But it's collected enough raw data to point some expert humans at the right interaction. I'd take this bs bug report and start asking Claude some questions that would guide it to a more plausible actual answer, but that requires a little more experience in kernel development.

Once we've met our basic material needs, we're tending to consume things that are replicable with low marginal costs, and which do not interfere with the production of other goods. So maybe we can actually support a continually growing digital and entertainment economy, at least for a few more generations.

Maybe these mathematical contributions will also impact the efficiency and capabilities of our material production systems as well, which is another way to keep the economy growing.

I'm optimistic that we'll do more with our resources rather than trying to optimize for doing the same more efficiently with less resources.

Of course beating the code into shape for submission requires more manual work. But the draft stage is valuable to find unexpected friction points.

We have our core code in a weird dialect of C and rust. C I know well, but not rust. Our tests are in Python. The pipeline descriptions are in Yaml.

Outside of the core code there are so many arcana to learn. Writing syntactically and semantically correct yaml/Python test code would be a nightmare. The Agents have flaws, but they provide a huge leg up in improving the tests.

And they are great at providing a first pass review of the core code before bothering a human reviewer. Lastly we run some of our test failures through AI triage, which often enough finds the root cause or rules out simple failures.

This shows up in a higher checkin rate. I'm curious to see whether this will lead to quality end product since we have more support for the more manually written and reviewed core product code.

Intuition and other forms of knowledge are stock quantities while calibration and instructions are types of flows which change the stock. I'd love to know if there a better word for learning through trial and evaluation than calibration.