Elena' s AI Blog

26 June 2026

The week nobody shipped a model

Nvidia's moat springs a leak, and one tidy fix for Docker's favourite tantrum.


Dear Reader,

Two posts this week, pulling in opposite directions. One zooms out to a week where almost nothing that mattered was a model release — the action moved to the silicon, the money, and the trust boundaries underneath. The other zooms right in to a single Permission denied message and the one command that fixes it.

Big picture and small detail, but both turned out to be about the exact same thing: who actually owns what.


Qualcomm, RISC-V, and the Crack in Nvidia’s Monopoly https://daehnhardt.com/blog/2026/06/26/qualcomm-risc-v-and-the-crack-in-nvidia-s-monopoly/

If you only watched the leaderboard, this was a dull week. If you watched where the leverage actually sits, it was one of the busiest I have tracked.

Qualcomm is circling Jim Keller’s RISC-V startup Tenstorrent for somewhere between $8bn and $10bn, aiming not at Nvidia’s transistor count but at its software moat — rather like challenging a railway not by laying faster track but by confidently changing the gauge. The reason this attempt is worth a second look is that Qualcomm is reportedly paying for the open compiler, not just the cores, and the compiler is precisely where these “Nvidia alternative” deals usually go to die.

On the exact same theme, China drafted a $295bn plan to build a national AI data-centre grid on roughly 80% domestic silicon — pouring the slogan “sovereign stack” into actual concrete. The signal is not the spending; it is that a top-three compute market has decided, as a matter of policy rather than price, which chips its future runs on.

Meanwhile, OpenRouter’s Fusion made the cheekiest argument of the week: a panel of three cheap models plus a referee can out-argue a single frontier heavyweight, which is simply the old ensemble trick that won Kaggle for a decade, now dressed up for the LLM era.

Then came the part you should read twice. Agentjacking turns a fake Sentry error report into remote code execution on developers’ machines, by exploiting a habit we have all recently built: when the coding agent says “run this,” we run it. It does not break the model — it borrows on your trust in it, with an 85% success rate and a vendor who declines to fix it.

Cheekily, all this drama below the model arrived in the same fortnight that 42 state attorneys general subpoenaed OpenAI and named model “sycophancy” in a legal instrument, while Anthropic’s study of 400,000 sessions concluded the scarcest component in the whole stack is still the human in the chair who knows what “correct” actually looks like.


Docker Permissions Without Panic: Why I Ran chown Inside My Container https://daehnhardt.com/blog/2026/06/26/docker-permissions-without-panic/

From the geopolitics of silicon to a much smaller mystery on my own desk. Sometimes Docker does not fail loudly — the container is up, Nginx is serving, Flask is alive, and then your file uploads silently fail with a wonderfully unhelpful Permission denied.

The culprit is almost always an ownership mismatch: root created the folders during the build, but the app sensibly runs as the non-root appuser, so the two end up living in the same house without agreeing on who holds the keys. The fix is a single command that briefly borrows root to hand the right folders to the right user — root repairs the house; appuser lives in it.

The detail that trips up nearly everyone is that Linux does not actually care about the name appuser at all; it checks the numeric UID behind it. It is like a passport control officer checking your identity number, not the friendly label on your luggage.

That is why the same docker-compose.yml works happily on a Mac — where Docker Desktop does behind-the-scenes magic mapping your host files into the container — and then throws a tantrum the moment you deploy it to a Linux server. A bind-mounted folder owned by host UID 501 will never magically belong to the container’s user, which is why chmod 777 — the “leave the front door wide open” non-solution — should stay firmly in the drawer.

The post walks through the command piece by piece, then offers the permanent cure so you never type it again: own the folders at build time with COPY --chown, and repair mounted volumes once at startup with an entrypoint that fixes ownership as root before dropping privileges with gosu. Think of backups as the seatbelt here — you really do not want to discover the seatbelt was fake after the crash.

Set ownership first, drop privileges last, and permissions become boring again. Boring permissions, as I am fond of saying, are good permissions.

Take care, and do hit reply if either piece sparked a thought.

Elena


All issues