Docker maakt agents versieerbaar; ROCm 10.1 richt zich op data tussen opslag en GPU

Docker brengt een agentplugin die YAML-configuraties en OCI-registries als distributielaag gebruikt; dat is interessant voor teams die agentgedrag willen reviewen en versioneren, maar geen vervanging voor isolatie. AMD richt ROCm 10.1 intussen nadrukkelijk op de route tussen opslag, geheugen en GPU — inclusief een compilerupgrade die CI kan raken.

Verder: een experimentele Rust-port van de TypeScript-compiler claimt hoge compatibiliteit maar waarschuwt zelf voor vroege staat en ongelezen code. OpenAI’s wiskundecatalogus krijgt volgens een nieuw signaal een concrete correctie.

Docker Agent verpakt agentconfiguratie als YAML en OCI-artifact

Docker Agent is een CLI-plugin waarmee je agents in YAML definieert, lokaal draait en als OCI-artifact kunt publiceren of ophalen. De repository noemt modelproviders van OpenAI tot Mistral en Docker Model Runner voor lokale modellen; als bouwstenen zijn er onder meer ingebouwde tools, MCP-servers, retrieval, geheugen en multi-agentdelegatie. Docker Desktop 4.63+ zou de plugin al meeleveren.

Dat is vooral praktisch wanneer een team de instructies, modelkeuze en toolsets van een agent als code wil reviewen en uitrollen, in plaats van ze alleen in een UI te configureren. OCI-distributie maakt een agentdefinitie bovendien behandelbaar als een ander release-artefact. De keerzijde: YAML en een containernaam zijn geen securitymodel. De beschikbare projecttekst belooft geen universele sandbox; controleer dus per toolset mounts, netwerk, credentials, MCP-server en telemetrie voordat een agent buiten een wegwerpwerkmap mag werken. De repository meldt zelf anonieme usage telemetry.

Ook de omvang verdient een nuchtere proef: de bron noemt veel providers en functies, maar geen onafhankelijke compatibiliteits- of veiligheidsmeting. Begin met een minimale configuratie, lokale modelroute waar passend en expliciete allowlists voor tools. Repository en installatie · HN-discussie

ROCm 10.1 legt de nadruk op I/O, NUMA en een gewijzigde compilerbasis

AMD brengt ROCm 10.1 uit met uitbreidingen aan hipFILE, onderdeel van AMD Infinity Storage. De nieuwe asynchrone fast path draait read- en writeverzoeken volgens AMD rechtstreeks op een HIP-stream en slaat de staging via hostgeheugen over; een batch-I/O-API en uitgebreidere I/O-statistieken moeten duidelijker maken of een workload op compute, geheugen of datatoevoer vastloopt. HIP krijgt daarnaast NUMA-bewuste allocatie van hostgeheugen.

Voor grote lokale of server-inference is dat interessanter dan alleen een nieuwe kernel: checkpoints, KV-cache en gewichten passen steeds vaker niet in het snelste geheugen. Of deze route werkelijk helpt, hangt af van applicatie, opslag, PCIe/topologie en runtime; AMD geeft hier geen onafhankelijke end-to-end-metingen voor een specifieke LLM-stack. Meet dus koude en warme prefill, wachttijd op I/O en GPU-utilisatie, niet alleen decode-snelheid.

De release heeft ook directe beheerimpact. ROCm gaat naar LLVM 24; AMD raadt aan buildscripts en directe koppelingen aan libLLVM na te lopen. rocm-smi is nu vervangen door amd-smi, terwijl ROCm CLI 1.0.0 installatie, modelserving en telemetry bundelt. WSL2-ondersteuning is nog een tech preview. Plan daarom een stagingupgrade voor eigen HIP-extensies, profileringsscripts, monitoring en containerimages. AMD’s release-overzicht · Reddit-discussie

tsc-rs claimt snelle Rust-port van TypeScript 7, maar is nog nadrukkelijk experimenteel

Het project ts-rust (tsc-rs) presenteert een Rust-port van Microsofts native, in Go geschreven TypeScript-compiler. Volgens de repository is de port vastgezet op een ontwikkelrevisie van TypeScript 7.1 en doorloopt hij 181.711 overgezette Go-tests. De maker meldt gelijke diagnose-uitvoer voor enkele echte projecten en zegt op zestig open-sourceprojecten gemiddeld ongeveer half zoveel typechecktijd als de Go-baseline te meten.

Dat is een intrigerend experiment voor TypeScript-projecten die typechecking in CI of editor-workflows voelen knellen. Maar het is geen drop-in-default: de repository noemt bekende afwijkingen bij sommige monorepo’s en bij tsc -b; platformreleases zijn voorlopig beperkt. Belangrijker nog: de auteur schrijft expliciet geen regel van de gegenereerde code gelezen te hebben. Gebruik het dus hoogstens achter een optionele CI-taak of op een testbranch, met vergelijking van diagnostics, emit, taalservergedrag en reproduceerbare builds.

De prestatiecijfers, inclusief de vergelijking met tsc en Bun, zijn projectmetingen op één M4 Pro en met een specifieke versiepin. Ze zijn geen algemene garantie voor Linux-CI, grotere monorepo’s of een nieuwere TypeScript-versie. Repository met compatibiliteitsstatus en meetmethode · HN-discussie

Gemelde intrekking maakt OpenAI’s verificatiegrens concreet

Een nieuw HN-item meldt, op basis van een gelinkte post die in de opgeslagen crawl niet leesbaar was, dat OpenAI drie wiskundige resultaten heeft ingetrokken. Dat is een relevante concrete verandering na de middagupdate van woensdag 7 oktober: die behandelde de catalogus met 722 manuscripten juist als een verzameling met uiteenlopende verificatiestatus, niet als een lijst vaststaande doorbraken.

De primaire post is hier niet onafhankelijk te controleren; ook het aantal drie moet daarom als gemeld, niet als zelfstandig geverifieerd feit worden gelezen. In de discussie wordt bovendien gesproken over een nog beperkt aandeel geformaliseerde resultaten, maar dat is commentaarduiding en geen vervanging voor een officiële statuspagina.

De praktische consequentie verandert niet, maar wordt scherper: koppel iedere claim aan een specifieke versie, formeel artifact en reviewstatus. Een gepubliceerd manuscript of zelfs een formele vertaling is geen vrijbrief om de semantische koppeling met de bedoelde stelling over te slaan. HN-item met de gemelde correctie

Verder nog

• Chimera beschrijft cbuild als één distributiegereedschap: Chimera Linux legt uit hoe cbuild repositorybeheer, buildomgeving, signing, packaging, dependency- en metadatachecks, updates en bulkbuilds in één workflow probeert te verenigen. Builds draaien in een beperkte omgeving; netwerktoegang tijdens de build en wijzigingen buiten die omgeving worden volgens het project bemoeilijkt. Interessant als ontwerp voor een kleine distrocommunity die packaging toegankelijk wil maken, maar het is bewust op Chimera’s eigen processen gericht en geen kant-en-klaar generiek buildplatform. Uitleg en voorbeelden · Lobsters-discussie