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.

You might be interested in:

https://github.com/cantino/mcfly - fuzzy shell history (feels lighter than atuin to me, in rust)

https://github.com/watchexec/watchexec - rerun on file change, knows about .gitignore/.ignore etc (in rust)

https://github.com/jonas/tig - instead of lazygit, mostly for easier git log viewing for me as I use straight git most of the time

Otherwise a lot of crossover in what I use too.

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.

Large PRs could follow the practices that the Linux kernel dev lists follow. Sometimes large subsystem changes could be carried separately for a while by the submitter for testing and maintenance before being accepted in theory, reviewed, and if ready, then merged.

While the large code changes were maintained, they were often split up into a set of semantically meaningful commits for purposes of review and maintenance.

With AI blowing up the line counts on PRs, it's a skill set that more developers need to mature. It's good for their own review to take the mass changes, ask themselves how would they want to systematically review it in parts, then split the PR up into meaningful commits: e.g. interfaces, docs, subsets of changed implementations, etc.

Crash? The software, or physically? A 200Hz as a min control loop rate seems on the fast side as a general default, but it all depends on the control environment - and I may be biased as I've done a lot more bare silicon controls than ROS.

A couple of historical notes that come to mind.

When washing machines were introduced, the number of hours of doing the chore of laundry did not necessarily decrease until 40 years after the introduction.

When project management software was introduced, it made the task of managing project tasks easier. One could create an order of magnitude or more of detailed plans in the same amount of time - poorly used this decreased the odds of project success, by eating up everyone's time. And the software itself has not moved the needle in terms of project success factors of successfully completing within budget, time, and resources planned.

Location: Portugal

Remote: Yes Willing to relocate: No

Willing to Relocate: No

Technologies: Rust, Python, C/C++, Typescript, LLM APIs, Distributed Systems, Embedded Systems, devops, Linux Kernel

Resume: https://uplinklabs.com

Email: alan@uplinklabs.com

Hands on builder, fractional CTO/Architect. 25+ years of US tech experience. Full stack with data intensive backend experience. Multi domain expertise, 0 -> 1 startup stacks, AI prototype cleanup for production, cloud, storage, embedded, autonomous vehicles, regulated industries. Problem solver with using tech and team leadership skills. Open to fractional and contract opportunities. US B2B invoicing available.

The easiest is to add short info in comments, and longer info in some sort of document and reference the doc in comments.

Lightweight ADRs are a good recommendation. I've put similar practices into place with teams I've worked with. Though I prefer to use the term "Technical Memo", of which some contain Architectural Decisions. Retroactive documentation is a little misaligned with the term ADR, in that it isn't really making any sort of decision. I've found the term ADR sometimes makes some team members hesitant to record the information because of that kind of misalignment.

As for retroactively discovering why, code archeology skills in the form of git blame and log, and general search skills are very helpful.

A fun use of this kind of approach would be to see if conversational game NPCs could be generated that stick the the lore of the game and their character.

To borrow some definitions from Systems engineering for verification and validation, this question is one of validation. Verification is performed by Lean and spec syntax and logic enforcement. But Validation is a question of is if the Lean spec encodes a true representation of the problem statement (was the right thing specced). Validation at highest levels is probably an irreplaceable human activity.

Also, on the verification side - there could also be a window of failure that Lean itself has a hidden bug in it too. And with automated systems that seek correctness, it is slightly elevated that some missed crack of a bug becomes exploited in the dev-check-dev loop run by the AI.

I would guess by now none have that internally. As a rule of thumb every major flash density increase (SLC, TLC, QLC) also tended to double internal page size. There were also internal transfer performance reasons for large sizes. Low level 16k-64k flash "pages" are common, and sometimes with even larger stripes of pages due to the internal firmware sw/hw design.

Garage is really good for core S3, the only thing I ran into was it didn't support object tagging. It could be considered maybe a more esoteric corner of the S3 api, but minio does support it. Especially if you're just mapping for a test api, object tagging is most likely an unneeded feature anyway.

It's a "Misc" endpoint in the Garage docs here: https://garagehq.deuxfleurs.fr/documentation/reference-manua...

Incidentally there is a open source S3 project in rust that I have been following. About a year ago, I applied Garage images to replace some minio instances used in CI pipelines - lighter weight and faster to come up.

https://github.com/deuxfleurs-org/garage

This seems around the durability that most databases can reach. Aside from more specialized hardware arrangements, with a single computer, embedded database there is always a window of data loss. The durability expectation is that some in-flight window of data will be lost, but on restart, it should recover to a consistent state of the last settled operation if at all possible.

A related questions is if the code base is mature enough when configured for higher durability to work as intended. Even with Rust, there needs to be some hard systems testing and it's often not just a matter of sprinkling flushes around. Further optimization can try to close the window tighter - maybe with a transaction log, but then you obviously trade some speed for it.

On Linux I'm using colima with docker compose and buildx and it seems to work ok for my limited cases.

On Mac it works ok to, but there are networking cases that Colima on mac doesn't handle - so orbstack for there

There are large bodies of work for optimization of state space control theory that I strongly suspect as a lot of crossover for AI, and at least has very similar mathematical structure.

e.g. optimization of state space control coefficients looks something like training a LLM matrix...

I don't know, it's all probability in the dataset that makes one optimization strategy better over another. Git annex iirc does file level dedupe. That would take care of most of the problem if you're storing binaries that are compressed or encrypted. It's a lot of work to go beyond that, and probably one reason no one has bothered with git yet. But borg and restic both do chunked dedupe I think.

I would think that git would need a parallel storage scheme for binaries. Something that does binary chunking and deduplication between revisions, but keeps the same merkle referencing scheme as everything else.