Specifically, if you're serving it as a "Model as a Service" business you need a license. Other uses do not.

Prompt injection in hardware! What could possibly go wrong?

TLDR for those who gave up reading:

The distributed repos and "commit-then-push" metaphor might be due for a replacement since we're always online anyways and repos grow larger and larger. Perhaps using VFS where all files are always instantly available with copy-on-write semantics.

There are several players working on systems that work on thousands of commits per second scale, some based on Git and others not.

Love to hear more about the Git implementation. In using S3, are you going the walgit route or more like git-remote-s3?

It's closer to walgit as it stores the packs in S3, but it uses Postgres for locking a repo during a push instead of using the Cursor/Walgit trick of using a WAL+CAS in S3. I've evaluated CAS on the Scaleway S3 service, but writing the WAL adds 240ms to every push, a cost we don't have with Postgres where it's a fast row lock. I also evaluated whether keeping a WAL would be useful, but ultimately decided against it because we can track everything the WAL tracks through the git history + audit logs without the write cost overhead.

Would be interesting to see how much a PTP-aware switch would impact the jitter, and whether 802.1AS is possible.

In general? It doesn't, at least negatively. Aristas are great.

I wish I had a switch that supported both PTP boundary clock and transparent clock configurations, so I could test the two side by side. My guess is either mode would add somewhere around 10 ns per switch, maybe a bit more depending on the hardware, but I haven't measured it myself.