digikata

Interesting read keeping in mind this is two degrees of separation from NVMe queues and their atomic doorbell head/tail registers.

It's a reasonable demo, I could envision variable length wire/flex ribbon spacing segments for different arrangements. Also would be fun for custom buttons for custom panels - big red buttons, buttons w/ guards, etc.

This points back to a more general problem. I love to haul out the quote "All models are wrong, but some models are useful", and it's actually attributed to a statistician talking about statistical models. The quote was written well before AI, from a mathematician working in a time even before computer science dug into data science/eng.

As presented the Decoherence Trap is AI related, but as someone with a background in physical simulation and modeling, and applying math models & system controls algorithms, software in general has always had a connection-to-reality issue. It's always been able to go faster in building models faster than reality can be checked. People are always eager for the results and to take action on them, when the long run limiting factor is often, can I observe enough real data signal to make a good decision by any set of optimizing model rules. It's often harder and slower to collect real-world data, ideas, and samples than it is to rapidly process it. With AI, I think we can even more quickly build models (not in an llm sense, but in a operational sense) that give beautiful, precise results which may or may not be useful in a connected-to-reality way.

If the model operates on bad data, then the risk is always the temptation of having a precise-looking technical answer to apply. The practices need to be updated, but I think the mindset of systems engineering validation & verification, and software QA are going to be very needed going forward.

There is actually a related issue, in that I don't think we want an overly coherent of set of models running through our economy - it's a strong risk of central planning failings vs competitive/experimental markets, but that's a tangential discussion.

I've been using Qwen3.6-37B-A3B on an M1 Max w/ llama.cpp and for my practical uses I prefer it to qwen3.8. When 3.8 does answer its slower and, qualitatively, marginally better than qwen3.6, but 3.8 often ends up in unresolved thought loops and runs slower. The Moe 3.6 on my setup is much faster, 500t/s peaks, 30t/s typical, vs 3.8 150 peak, 4-9 t/s typical.

While I've spend a little time tuning, I'm assuming there will be deeper tuning for 3.8 that might close the gap.

Qwen3.6 27B is very usable, and dialing back thinking modes woth Qwen3.8 bring it close, but 3.8 stills feels slower. Unknown to me if the results are qualitatively better or worse overall - with the heavier thinking 3.8 felt worse in terms of coding tasks, but I think Im comparing a newly released model to one that has had a lot of harness tuning. 3.6 27B was easily a daily driver with only an occasional need to pop up to larger models for planning.

I would be cautious about relying on proprietary platform features from any AI vendor right now. They all have scaling headaches, and also are in the middle of mass feature churn.

For must work company services, I'd require multi-vendor/multi-model routing if it's any sort of automation, and if its more SaaS, lean towards a service with selectable backend provider/model for misc office work. Self hosted is nice for some situations too.

Are you running the direct data of your workload all through the AI? The number of tokens you're consuming can probably be reduced a lot. It seems like a good time to take a half step back and use the AI to build a workflow engine to shift more of the work out of the AI models and into more traditional scrape and analyze sw logic. For the more sophisticated decisions, even using a LLM grade AI to bootstrap more older machine learning algorithms and rules could AI use to updates of rules instead of something called inline on every working transaction.

For quite a while, I've have had a shell fcn that will take all the untracked files listed in a git status, and push them to .git/info/exclude. Generally applied after an add+commit of everything I do want to go generally into the repo.

Yes, it's a critical distinction that's important in many systems domains, but getting some form of ownership policy and method - even if implemented with a GC I think is a step forward in terms of building reliable code.

The thing about it being optional in some languages is that it's an experiment, but one that as a feature it really pays off the more code in the ecosystem is compliant to ownership tracking. For rust, it's the vast majority of it (with opt out explicitly findable..) For languages offering it optionally, it's harder to assemble the full benefit.

I had thoughts along similar lines, but there are other possibilities - it could be the older CPU models are built either on older lines and/or with more mature, higher yield processes, and this offering could in part take demand pressure off of top-of-the-line process M5/M4 parts.

Last I checked, and things might have changed, atuin runs a full posgresql database to store and sync the history, while mcfly is lighter, it also has a narrower feature scope.

One could run a docker container with claude code, with a bind to the project directory. I do that but also run my docker daemon/container in a Linux VM.

When writing tables in markdown files, text align data in the columns for readability with a plain text editor.

Go slow to go fast. Breaking up the PR this way also allows later humans and AI alike to understand the codebase. Slowing down the PR process with standards lets the project move faster overall.

If there is some bug that slips by review, having the PR broken down semantically allows quicker analysis and recovery later for one case. Even if you have AI reviewing new Node.js releases for if you want to take in the new version - the commit log will be more analyzable by the AI with semantic commits.

Treating the code as throwaway is valid in a few small contexts, but that is not the case for PRs going into maintained projects like Node.js.