ossianericson

I daily for work (and private) use AI to develop this I hope will save me some time, Will test and cross reference when I work this week to see what gems I might have missed.

Strong for the downstream part.

Upstream rules should travel with your repository, never be locked to just one agent. I want to experiment, test different models.

I could never work in one model, it requires specific parts that work only in that specific snowflake implementation.

I remember two decades back when Games for Windows was introduced with Vista, I wrote an article that this was killing gaming. As a PC (master race) gamer back then, I didn't always find it appealing to think that PC games had to have gamepad support etc. To be called and have the Games for Windows logo.

Now seeing Linux just absorbing Windows APIs into the kernel to make gaming work better? That is the opposite direction. This is what PC gaming needs.

I got into PC gaming when I got my Ambra Hurdla SX25 in 1992. Back then it was the fantastic era of first for everything. We got Comanche, Alone in the Dark, Dune, Dig, etc. First of all game types, not just clones of the same concepts.

Cool I like it! Guns and a map? Now I want to play Jagged Alliance.

This type of content would never cross my path normally , way outside my skillset. But it is stil interesting and exactly why I keep coming back to HN.

Had a 486 SX/25 (Ambra Hurdla) back then. Accidentally bought 4x4MB server SIMMs instead of what I needed and ended up with 20MB which was kind of absurd in 1993. Ran the whole games directory as a RAM disk just because I could. Spent way too long learning the segmented memory model by breaking config.sys rather than reading anything. Would've been useful to have the actual source back then.

Even when the JSON pass rate is at 97% the real challenge is that the accuracy gap is invisible at the record level. Nothing flags it without a baseline to check against. Parse error is rarely where it goes wrong in my experience. 'Valid' but incorrect data is what actually reaches production.

The OIDC federation between the runner and the cloud resources it touches , that credential gets created once. Permissive enough to not block the first deploy, and it is not what is reviewed when a pinning incident happens. Every one is looking at the action. The identity it runs as just sits there.

The jemalloc feature flag setup is the part I will steal from this. Not the boxing. In previous platform work we had the same problem: measure in dev with the wrong workload, or add permanent allocator overhead to prod. Feature-gating the instrumented allocator means the binary you measure is the binary you ship. Harder to arrange than it sounds once you've got environment-specific build configs in the way.

Wondering if the verifier accounts for load induced variance, not just weight fidelity. Working on something recently where we sidestepped runtime inference entirely. Partly because even with identical weights, prefix caching and continuous batching can shift outputs enough on long-horizon tasks that you don't really know what you're measuring. A provider can pass on a quiet cluster and fail at 80% GPU utilization without touching the checkpoint.

The friction Cantrill describes does not go away, it just moves. In my experience, if you don't do the "lazy" thinking before the model touches anything, you pay for it when trying to maintain something you didn't mentally build. The spec becomes the place where the laziness discipline has to live now.

The CDN part is the easy half. In my work the harder problem has most often been internal service mesh, mTLS between services, any infra that doesn’t terminate at a CDN. Has a bad habit of longer certificate lifetimes and older TLS stacks, and nobody is upgrading it for you.

Maybe I am misreading this but it looks as alwaysGrants bypasses the rest of the controls.