gVisor verhuist naar CNCF, terwijl Linux op M4 alle cores bereikt en een Git-hookaanval credentials viseert

gVisor gaat van Google naar de CNCF, met een overgang naar maintainer- en later organisatiegestuurd bestuur. Voor Linux op de M4 is een fundamentele WFI-workaround inmiddels upstream, maar randapparatuur blijft werk in uitvoering. Tegelijk beschrijft een ontwikkelaar een gerichte poging om via een meegeleverde Git-hook een binary op zijn laptop uit te voeren.

gVisor krijgt een CNCF-route en opener bestuur

Google draagt gVisor — de userspace-kernel en container-runtime voor sterkere isolatie — over aan de Cloud Native Computing Foundation. De CNCF accepteerde de aanvraag op 28 september; de komende weken moet het project Sandbox-status krijgen, de CI naar GitHub Actions en Buildkite verhuizen en een maintainersmodel krijgen met merge-rechten voor niet-Google-bijdragers. Op langere termijn is een model met organisatie-stemmen voorzien, zodat Google geen eenzijdige zeggenschap houdt.

Dat is relevant voor teams die agents, code-executie of multi-tenant containers isoleren. Volgens de projectauteurs bleef brede adoptie mede achter doordat gVisor eigendom van Google was en omdat sommige I/O-zware workloads zonder interne patches minder goed presteren. De overdracht verandert die technische grenzen niet direct, maar kan de onderhouds- en integratierisico’s voor externe gebruikers verkleinen. De auteurs noemen onder meer Ant Group, Modal en Tines als toekomstige maintainers; OpenAI, Tencent en Nvidia zouden blijven bijdragen.

Zie dit niet als een securitycertificaat voor een eigen agentomgeving. Isolatie blijft afhangen van mounts, netwerk-egress, credentials en runtimeconfiguratie. Maar voor een runtime die eerder in een editie van 22 september slechts als extra laag in een sandbox werd genoemd, is dit wel een concrete governance-ontwikkeling. gVisor over overdracht, tijdlijn en plannen · Lobsters-discussie

Linux op M4 bereikt alle cores, maar nog geen bruikbare volledige machine

Een Asahi-bijdrager beschrijft waarom Linux op M4- en latere Apple-chips kon vastlopen zodra cores WFI/WFIT uitvoerden: in de waargenomen configuratie ging daarbij architecturale registertoestand verloren. Een simpele vervanging door no-ops bracht Linux eerder wel tot een shell, maar zonder energiezuinige idle. De uiteindelijke route is een nieuwe mainline-Linuxoptie om WFI-idle uit te schakelen, die m1n1 conditioneel meegeeft op getroffen bare-metalmachines.

Volgens het verslag zijn de benodigde wijzigingen in zowel mainline Linux als m1n1 gemergd. Daardoor kunnen recente versies native booten met secundaire cores op M4; dezelfde workaround zou ook op M4 Pro, M4 Max en M5 werken. Dat is een belangrijke enablementstap: het gaat van een single-core of crashende bring-up naar een shell met alle cores.

Dat is nadrukkelijk geen algemene Linux-support voor een M4-Mac. De auteur noemt camera, displaycontroller en GPU als nog te reverse-engineeren onderdelen, en ook energiebeheer is nog niet op het niveau van macOS. Een HN-reactie wijst er bovendien op dat Asahi-power-management zelfs op eerdere generaties niet gelijkstaat aan macOS. Voor experimenteerders is dit vooral een reden om kernel en m1n1-versie nauwkeurig te controleren, niet om een M4 al als volledig ondersteunde Linux-laptop te beschouwen. Technisch verslag · HN-discussie

Gerichte Git-val gebruikte een post-checkout-hook als uitvoerpad

Een ontwikkelaar beschrijft een gerichte benadering die begon als normale aanvraag voor webwerk, met een Dropbox-map vol Markdown en een verzoek om een NDA uit een aparte Git-branch te halen. In de map zat volgens hem echter ook een .git-directory met een echte post-checkout-hook. Die hook zou via een Vercel-app een OS-specifieke binary downloaden, uitvoerbaar maken, draaien en daarna verwijderen.

De praktische les is specifieker dan ‘Git is gevaarlijk’: een werkmap die niet via een normale clone komt — bijvoorbeeld een gedeelde archiefmap of uitgepakte repository — kan al bestanden onder .git/hooks bevatten. Bij een branchwissel kan zo’n hook dan code uitvoeren. De auteur zegt de hook slechts te hebben geïnspecteerd en Dropbox en Vercel te hebben gewaarschuwd; er is in de beschikbare context geen onafhankelijke incidentanalyse of bevestiging over slachtoffers.

Behandel onverwachte projectmappen daarom als onbetrouwbare input: inspecteer verborgen .git-inhoud vóór checkout, gebruik voor onbekende prospects een wegwerp-VM of -account, en laat nooit bestaande developer-credentials in zo’n omgeving beschikbaar zijn. Gewone git clone weigert volgens een Lobsters-reactie doorgaans een checkout naar .git/hooks/..., maar dat beschermt niet tegen een al aangeleverde werkboom. Oorspronkelijk verslag · Lobsters-discussie

WHIRL brengt een smalle R9700-route naar native Windows

WHIRL is een nieuwe Apache-2.0-engine in C++/HIP voor precies één doel: Qwen3.5-architecturen op een Radeon AI PRO R9700 onder Windows 11, zonder WSL of Linux-VM. De eerste release biedt een OpenAI-compatibele server, prefixcache, MTP- plus n-gram-speculatie en een getrapte KV-cache waarbij inactieve sessies naar RAM en SSD kunnen worden verplaatst. De actieve decode blijft volgens de maker in VRAM.

De auteur vergelijkt op één R9700 met llama.cpp en meldt voor een Qwen3.8-27B-Q4 onder meer 1,36–1,38× snellere prefill bij 8K/32K en 1,76× snellere decode op Chinese codeprompts met MTP en n-gram. Zonder speculatie is de decodewinst op de dichte modellen slechts 1,1–1,18× — een nuttige aanwijzing dat het grootste verschil uit de speculative route komt. De eigen metingen noemen ook sneller herstel van sessies vanaf SSD dan opnieuw prefillen.

Dit is een nieuw runtimepad naast eerdere R9700-werkzaamheden, maar niet een algemene AMD- of Windows-oplossing: één GPU, één besturingssysteemfamilie en voorlopig twee architecturen. De cijfers zijn makersmetingen; de engine gebruikt bovendien 3–5 GiB meer VRAM dan llama.cpp voor dichte modellen. Test dus tokenpariteit, lange context, herstelgedrag en je eigen prompts voordat je een bestaande server vervangt. Projectpost en benchmarkdetails

Microsoft zet compacte FrogNano-codeagent open, met duidelijke grenzen

Microsoft heeft FrogNano-4B-2609 gepubliceerd onder Apache-2.0. Het is een circa 4,66B-parameter afgeleide van Qwen3.5-4B, specifiek na-getraind met reinforcement learning op ongeveer 1.500 synthetische repositorytaken. De agent werkt met de vijf tools van de Leaf-harness voor bestanden lezen, zoeken, wijzigen, shellcommando’s en tests; de gedocumenteerde evaluatieopzet gebruikt circa 131K tokens context en maximaal 150 interactiestappen.

Interessant is niet alleen de kleine omvang, maar de expliciete afbakening. De kaart stelt dat de training Python-zwaar en primair Engelstalig is, geen sterke-modeltrajecten of patchdoelen gebruikte, en dat patches foutief of onveilig kunnen zijn ondanks passerende tests. Voor BF16 is alleen voor de gewichten al ongeveer 9,3 GB nodig, exclusief KV-cache en runtime-overhead; gequantiseerde formaten en desktop- of CPU-onlygebruik zijn volgens de kaart nog niet gevalideerd.

Gebruik het dus als onderzoek- of developer-assistent in een geïsoleerde repository, niet als autonome productie-actor. Microsoft adviseert zelf netwerk standaard uit, minimale rechten, resourcegrenzen en menselijke review plus regressie- en securitytests vóór merge. Modelkaart, code en technische vereisten · Reddit-discussie

Verder nog

• Lokale ondertiteling met mlsubgen: dit nieuwe open-sourceproject maakt .srt-bestanden in 45 talen en gebruikt aanwezige tekst- of bitmapondertitels vóór het audio opnieuw transcribeert. Als audio nodig is, combineert het lokaal Qwen3-ASR en Whisper, en laat het een lokale LLM discrepanties en vertaling verwerken. De praktische beperking is fors: Linux, CUDA en minstens 8 GB Nvidia-VRAM; de volledige opzet vraagt 30–65 GB opslag. De kwaliteits- en snelheidsmetingen komen van de maker en deels van één clip, dus zie het als een bruikbare lokale proefroute, niet als een algemene kwaliteitsranglijst. Repository en hardwareprofielen · Reddit-discussie