AI-harness helpt Linux-drivers; Gentoo zoekt uitweg voor Chromium

Een nieuwe hardwareharness laat een coding agent USB-traces en Windows-configuratiegegevens naast Linux-gedrag leggen; de maker toont er scanner- en camerapatches mee. Tegelijk heeft Gentoo zijn Chromium-ebuild in last rites gezet: zonder nieuw onderhoudsteam verdwijnt de source-package-route na 24 oktober.

Voor webteams geeft een nieuwe, beperkte vergelijking AVIF voorlopig de beste standaardpositie naast de pas toegevoegde JPEG-XL-browserondersteuning. En decomp.dev trekt zich terug als centrale decompilatie-index wegens de effecten van AI-gedreven forks en ports.

Een AI-harness maakt onbekende Linux-hardware beter vergelijkbaar met de Windows-driver

GNOME-ontwikkelaar Christian Schaller heeft hw-harness gepubliceerd, een werkwijze waarin een apparaat aan een Windows-VM wordt doorgegeven terwijl de Linux-host USB-verkeer met usbmon opneemt. Dezelfde handeling met een Linux-driver levert een tweede trace op; een Claude- of Codex-sessie kan vervolgens verschillen analyseren en probes voorstellen. Voor interne MIPI-camera’s zonder af te tappen bus gebruikt de opzet onder meer INF-bestanden, registry-informatie, ACPI-tabellen en apparaateigenschappen.

De interessante grens is dat het niet om blind gegenereerde drivers gaat. De maker beschrijft AI vooral als hulp bij het monotone werk — grote traces lezen, terugkerende bytes herkennen en testjes schrijven — terwijl hij zelf met fysiek apparaat controleert wat werkt. Hij stelt dat de aanpak gedrag observeert en configuratiegegevens extraheert, niet drivercode kopieert; dat is zijn juridische duiding, geen onafhankelijke beoordeling.

Hij koppelt er drie concrete resultaten aan. Voor een Plustek OpticFilm 8200i-scanner bouwde hij een SANE-backend met onder meer infraroodkanaal; in één eigen vergelijking duurde een volledige scan 34,6 in plaats van 54,4 seconden voor de inmiddels beschikbare upstreamroute. Hij maakte ook de Rust/Flatpak-app Negative Vibes, en diende patches in voor de MIPI-camera van een ThinkPad X1 Carbon Gen 14. Volgens zijn eigen low-lighttest steeg de framehelderheid daar van 31,1 naar 90,9; upstreamreview van de libcamera-patch liep nog.

Dit is dus een veelbelovende, reproduceerbare onderzoeksmethode, geen garantie dat iedere ongedocumenteerde USB- of camerachip snel ondersteund kan worden. De scannercijfers komen van één apparaat en frame, en de camera-aanpassingen zijn laptopspecifiek. Wie ermee experimenteert, doet er goed aan VM-passthrough, opgenomen traces en gegenereerde patches als gevoelige ontwikkelartefacten te behandelen en wijzigingen altijd op echte hardware te valideren.

Project, opzet en resultaten · HN-discussie

Gentoo zet Chromium op last rites

Gentoo heeft zijn www-client/chromium-ebuild in last rites gezet. Dat betekent dat het pakket is gemaskeerd zodat gebruikers het niet onbedoeld installeren of upgraden; een nieuwe maintainer of een team kan het nog vóór 24 oktober overnemen. Zonder zo’n duurzaam plan vervalt de door Gentoo onderhouden source-package-route.

De aanleiding is niet één buildfout maar de optelsom van snelle upstreamreleases, veel patches en compileerbare opties. Chromiums meegeleverde toolchain bestaat alleen voor x86-64; op andere architecturen is -bundled-toolchain verplicht. Maintainers noemen daarnaast nieuwe Go- en Rust-afhankelijkheden, onbetrouwbare release-tarballs en de noodzaak om uiteenlopende USE-flagcombinaties te testen. De bron noemt minstens drie maintainers als noodzakelijke schaal; één vrijwilliger blijkt historisch niet houdbaar.

Dit heeft een direct securityaspect: browsers hebben een hoog update-tempo. Alternatieve overlays of zelf compileren kunnen tijdelijk uitkomst bieden, maar zijn geen vervanging voor een door Gentoo geteste en onderhouden ebuild. De bron noemt ook Flatpak als distributiepad, maar dat is daar een door derden gebouwde, niet door Chromium-upstream geverifieerde package en helpt niet voor alle architecturen. Kijk dus eerst welke browser, architectuur en supply-chain-eisen een omgeving werkelijk heeft, in plaats van een losse overlay als structurele oplossing te behandelen.

LWN: achtergrond, tijdlijn en alternatieven · HN-discussie

AVIF blijft volgens nieuwe vergelijking de webdefault; JPEG XL heeft niches

Sinds de namiddagupdate van 7 oktober, waarin Chrome 155 JPEG XL-ondersteuning kreeg, is de relevante vraag niet alleen welke browsers het formaat lezen, maar welk formaat een beeldpijplijn moet schrijven. Jake Archibald vergeleek AVIF met JPEG XL via libjxl en jixel, op een M4 Pro en met meerdere foto’s, screenshots, transparantie en kwaliteitsmetingen.

Zijn conclusie: voor lossy foto’s produceert AVIF meestal kleinere bestanden; de beste JPEG-XL-uitvoer was in zijn tests bij standaardinspanning vaak 15–25% groter. Er zijn uitzonderingen: bij één foto met een wezel kon JPEG XL wel winnen. Voor screenshots en illustraties viel het verschil sterker uit in het voordeel van AVIF, en voor transparantie eveneens. JPEG XL behoudt volgens de test wel duidelijke troeven voor verliesloze compressie en het zonder verder kwaliteitsverlies kleiner maken van bestaande JPEG’s.

Ook de encoderkeuze blijkt niet cosmetisch. jixel maakte vaak compactere JPEG XL-bestanden dan libjxl, maar de hoogste instellingen kostten fors meer tijd en geheugen. AVIF decodeerde in de meeste geteste gevallen sneller; JPEG XL kon bij heel hoge kwaliteit in Chrome soms inlopen of winnen. De Lobsters-discussie wijst bovendien terecht op de afhankelijkheid van de kwaliteitsmetriek: een alternatieve meting schoof enkele uitkomsten in het voordeel van libjxl.

Dit is één auteursbenchmark, geen universele codecstandaard. De praktisch bruikbare conclusie is daarom beperkt: houd AVIF 4:4:4 als uitgangspunt voor gewone webafbeeldingen, maar meet eigen foto’s, transparantie, encodebudget, CDN en browsermix. Vergelijk JPEG XL gericht voor lossless assets, JPEG-transcodering of concrete uitschieters — niet alleen omdat browserondersteuning nu breder is.

Vergelijking, versies en meetopzet · Lobsters-discussie over metriek en encoders

decomp.dev sluit de centrale index voor nieuwe projecten

decomp.dev stopt met zijn hoofdpagina als centrale index en laat geen nieuwe projecten meer toe. Bestaande projectpagina’s en historische data blijven beschikbaar. De site was sinds 2024 bedoeld om voortgang bij matching decompilation te verzamelen en zichtbaar te maken.

De maker noemt de snelle vooruitgang van recente modellen als achtergrond: met goede documentatie, menselijke sturing en review kunnen ze decompilatiewerk volgens hem aanzienlijk versnellen. Maar hij zegt ook dat AI-gegenereerde output nog menselijk opschonen en controle nodig heeft, onder meer tegen code die wel dezelfde machinecode oplevert maar geen geloofwaardige broncode is.

De directe reden voor het afsluiten van de index is sociaal en organisatorisch. Volgens de maker leiden AI-forks die projecten snel ‘afmaken’, en haastige ports die op andermans decompilatiewerk voortbouwen, tot druk op de onderzoeksgemeenschap. Hij wil niet als individuele hobbymaintainer een grens voor ‘goede’ AI-bijdragen definiëren of handhaven. De publicatie is zijn eigen verklaring; zij bewijst niet hoe vaak zulke praktijken voorkomen, maar de productwijziging zelf is concreet.

decomp.dev over de afsluiting en wat beschikbaar blijft · Lobsters-discussie

Verder nog

• Sill streamt één Mac-venster naar iPhone of iPad: het Apache-2.0-project encodeert een venster of desktop op Apple Silicon als HEVC en stuurt invoer terug. Het gebruikt volgens de documentatie rechtstreeks TLS 1.3, per-device pairing en sleutelpinning, zonder account of tussengeplaatste server; toegang op afstand loopt via eigen VPN of port-forwarding. Let scherp op de rechten voor Screen Recording en Accessibility, verwijder verloren gekoppelde apparaten en update oude versies: vóór Mac-versie 0.4.0 waren lokale verbindingen volgens de maker niet versleuteld en niet gepaird. Projectdocumentatie · HN-discussie