Qwen zet mobiele agentrollen neer; een BGP-hijack laat zien waar TLS en RPKI nog tekortschieten

Qwen heeft Qwen Intelligence aangekondigd: een product met afzonderlijke rollen voor planning, mobiele bediening en creatief werk. Tegelijk laat een gedocumenteerde gedeelde Qwen-server zien dat cachegedrag in echte agentbelasting minstens zo belangrijk is als piek-throughput. Het meest directe securitysignaal komt van een BGP-hijack die, samen met een geldig TLS-certificaat, een kwaadwillige update voor een klein aantal Virtualizor-installaties mogelijk maakte.

Qwen Intelligence splitst mobiele agenttaken op, maar laat cruciale productdetails open

Qwen positioneert Qwen Intelligence als persoonlijke AI met drie agentrollen: een Mobile Planner Agent voor plannen en orkestreren, een Mobile-Use Agent voor bediening en een Mobile Creative Agent. Qwen claimt voor de planner de eerste plaats op MobilePA-Bench, inclusief de Business- en Memory-variant.

De interessante ontwerpkeuze is de opsplitsing tussen plannen en uitvoeren. Voor agentbouwers is dat een concretere richting dan één algemene chat-agent: planning, UI-actie en creatieve productie hebben verschillende foutmodi en zouden dus ook verschillende rechten, evaluaties en menselijke goedkeuringen moeten krijgen.

Vooralsnog is dit vooral een leveranciersaankondiging. De beschikbare post geeft geen gewichten, licentie, ondersteunde telefoons, permissiemodel of externe reproductie van de benchmarkcijfers. Ook is niet duidelijk hoe context en verantwoordelijkheden tussen de drie rollen worden doorgegeven. Behandel de claims daarom als aanleiding om later op echte mobiele taken te testen — met expliciete actielimieten — niet als bewijs dat een agent veilig of robuust autonoom op een telefoon werkt. Qwen-aankondiging

Eén RTX Pro 6000 verwerkt volgens een praktijklog 2 miljard agenttokens in een week

Een ontwikkelaar rapporteert een week gedeeld gebruik van Qwen3.8-27B FP8 op één RTX Pro 6000 Blackwell met 96GB, via vLLM, prefix-caching en speculative decoding. Vier cijfers zijn hier nuttiger dan een losse topsnelheid: ongeveer 2 miljard tokens, geen gemelde preemptions of wachtrij, maximaal 38,6% KV-cachegebruik en 60–88 tok/s per gebruiker onder gedeelde belasting.

Dat is een concrete aanvulling op de middagupdate van vandaag, die vooral context- en decode-ruilen op twee RTX 5060 Ti’s behandelde. Hier verschuift de vraag naar een doorlopende coding-agentdienst. De auteur schrijft de lage prefill-kosten vooral toe aan prefix-caching: agents sturen dezelfde systeemprompt, repositorycontext en gespreksgeschiedenis steeds opnieuw, zodat die niet telkens volledig hoeven te worden verwerkt.

Trek er geen capaciteitsgarantie uit. De node was volgens de auteur nog niet verzadigd, het aantal gebruikers is klein en de werklast bestaat bijna geheel uit diens eigen agentische codinggebruik. De auteur noemt bovendien SGLang met DFlash2 als vermoedelijk sneller, maar koos voor een meer beproefde vLLM-stack. Voor een eigen dienst zijn dus cache-hitratio, time-to-first-token, KV-druk en doorlooptijd per afgeronde taak relevanter dan alleen de gerapporteerde decode-snelheid. Praktijklog en discussie

BGP-hijack bij Softaculous maakte route voor kwaadwillige update en geldig TLS-certificaat

Een analyse van APNIC beschrijft hoe een aanvaller eind augustus een specifiekere BGP-route voor een Softaculous-updateadres adverteerde. Daardoor kreeg de route naar 162.55.80.0/24 voorrang boven Hetzners reguliere /16. Volgens Softaculous werd de hijack samen met een technisch geldig TLS-certificaat gebruikt om een kwaadwillig Virtualizor-updatepakket aan een klein aantal installaties te leveren.

De belangrijkere technische les is dat de route ondanks RPKI-validatie kon circuleren. Het pad bevatte een vervalste oorsprong, terwijl Hetzners ROA een maximale prefixlengte tot /24 toestond. Omdat de kwaadaardige /24 daardoor niet RPKI-invalid was, konden netwerken die alleen ongeldige routes verwerpen hem niet vanzelf stoppen. De auteur benadrukt ook dat een wereldwijd zichtbare, niet-betwiste specifiekere route de multiperspectiefcontrole voor certificaatuitgifte kon omzeilen.

Er is wel een concrete verbetering ná het incident: Hetzner heeft voor dit bereik de maxLength teruggebracht tot /16 en ook enkele andere ROA’s aangescherpt; volgens het artikel bleven veel ruimere ROA’s elders bestaan. Voor beheerders volgt een praktische checklist: maak ROA’s zo precies als de werkelijk geadverteerde prefixen, monitor onverwachte meer-specifieke routes en afwijkende upstreams, en behandel TLS niet als bescherming tegen een al succesvol overgenomen routeringspad. De analyse noemt NexonHost als vermoedelijke oorsprong, maar houdt open of dat door compromittering of klantmisbruik kwam. APNIC-analyse · Lobsters-discussie

JSON rechtstreeks naar domeinobjecten: sneller in een proof of concept, niet completer

Een Haskell-experiment laat zien hoe een JSON-parser een tussenliggende JSON-AST kan overslaan. In plaats daarvan vult de parser tijdens het lezen rechtstreeks een domeinobject in en houdt een bitset bij om na afloop vast te stellen welke verplichte velden ontbreken. Template Haskell genereert de gespecialiseerde parsercode.

In de gepubliceerde microbenchmarks op twee Xeon Gold 6244-cpu’s kost een klein object via de eigen parser mét IR 922,7 ns en zonder IR 314,2 ns; voor een groter object met boeken is dat 2,813 tegenover 1,027 μs. De interessante les voor performancegevoelige deserialisatie is dus niet dat een AST altijd verkeerd is, maar dat deze extra allocatie- en conversielaag meetbaar kan zijn wanneer schema en doeltype vooraf vaststaan.

De auteur is ongewoon duidelijk over de grens: escaped strings en diverse getalformaten zijn onvolledig geïmplementeerd, en de benchmarks zijn microbenchmarks. De aanpak maakt validatie en parsing bovendien sterker verweven en complexer. Zie dit daarom als een ontwerpidee voor een smal, goed getest hot path — niet als vervanger voor een volwassen algemene JSON-library. Artikel en code-uitleg · Lobsters-discussie

Verder nog

• Lokale Git-uitsluitingen houden een werkboom schoon: .git/info/exclude werkt alleen voor één clone en wordt niet gecommit; core.excludesFile is de globale variant voor bijvoorbeeld editor- en OS-rommel. Handig voor persoonlijke notities of agentplannen, maar ignore-regels werken niet voor al getrackte bestanden en zijn nadrukkelijk geen geheimenbeheer. Uitleg · HN-discussie
• Een GNOME-ontwikkelaar pleit voor een LLM-verbod: de post stelt een beleid voor dat LLM-gegenereerde bijdragen aan GNOME-infrastructuur uitsluit en de sociale kant van collectief onderhoud centraal zet. Dit is geen vastgesteld GNOME-beleid; de auteur erkent dat bewijs en handhaving beperkt zijn. Het is vooral een scherp open-source-governancesignaal. Voorstel · Lobsters-discussie