Systémy PaperCut NG a PaperCut MF stojí mezi počítači a tiskárnami. Počítají stránky, účtují je oddělením nebo studentům a úlohu z fronty vypustí, teprve když u tiskárny někdo přiloží kartu. Spravují se z prohlížeče, a právě to je teď potíž: kdo webové rozhraní vystavil na veřejnou adresu, má problém.

Výrobce oznámil 27. srpna 2026, že útočníci zneužívají chybu v jeho serveru u konkrétních zákazníků, a vydal nouzovou záplatu. Čísla CVE ani technické podrobnosti k ní tehdy nedal – zadržel je, dokud běželo vyšetřování a dokud zákazníci nestihli opravit. O den později přišla druhá záplata, 1. září třetí.

Dvě chyby, které do sebe zapadají

Podrobnosti výrobce zveřejnil 28. srpna. První chyba, CVE-2026-81578, sedí ve webovém rozhraní správy. Nepřihlášený požadavek mířený na administrativní funkci za určitých okolností spustí akci na pozadí dřív, než doběhne kontrola oprávnění. Útočník tak zvenčí změní část nastavení serveru. Klasifikace je CWE-306, tedy chybějící ověření u kritické funkce.

Druhá, CVE-2026-82078, je v části, která se stará o připojení k databázi. PaperCut si třídu databázového ovladače vytváří podle jména z konfigurace a neporovnává ho se seznamem povolených ovladačů. Kdo na to nastavení dosáhne, spustí libovolný javový bajtkód, který na classpath aplikace leží – a to pod účtem, pod nímž běží samotný proces serveru. Je to CWE-470, nebezpečná reflexe.

Samostatně jsou obě nepříjemné, ale teprve dohromady dávají útok od začátku do konce: první bere ověření, druhá spouští kód. Přesně tak je popisuje i CISA, která u obou uvádí, že se dají zřetězit.

V hodnocení závažnosti se zdroje rozcházejí. Výrobce dal metodikou CVSS 4.0 chybě v databázové části 9,4 bodu (kritická) a obejití ověření 8,8 (vysoká). Americká databáze NVD ale spočítala starší metodikou CVSS 3.1 u obejití ověření 9,8 bodu, tedy kritickou – a to proto, že jí přiřkla plný dopad na důvěrnost, integritu i dostupnost, kdežto výrobce u téže chyby počítá s tím, že sama o sobě dovolí jen změnu nastavení.

Tři nouzové záplaty za šest dní

První oprava vyšla jen pro verze 25 a 26. Druhá, označená Emergency Patch Release 2, přišla 28. srpna po práci s výzkumníky ze společností Huntress a watchTowr a přidala zpevnění nad rámec té původní. Důvod byl prostý: watchTowr obě chyby zreprodukoval, našel několik cest, jak první záplatu obejít, a k tomu ještě další obejití ověření. Release 2 už pokryl verze 24, 25 i 26 na Windows, Linuxu i macOS.

Třetí záplata je z 1. září a nahrazuje předchozí. Řeší dvě regrese, které opravy nadělaly ve funkčnosti: rozbité přihlašování přes SAML a ztracenou podporu starších ovladačů Microsoft SQL Serveru pro vyhledávání čísel karet v externí databázi. Vedle toho přidává další zpevnění proti možným útočným řetězcům. Instalace je kumulativní, takže předchozí záplaty už nasazovat netřeba.

Výrobce sám upozorňuje, že žádná z těch tří oprav není řádné vydání. Neprošly obvyklým vydávacím procesem a jsou určené zákazníkům s veřejně dostupným serverem, kteří nemají jak omezit přístup jinak. Vydání s běžnou kontrolou kvality teprve chystá. Opravovat opravu není v oboru nic výjimečného – letos musela podruhé opravovat tutéž díru firma N-able a CISA loni upozornila, že útočníci obcházejí i záplatu ve FortiOS.

Průzkum, vzdálený přístup, AnyDesk

Rozšířené indikátory kompromitace přibyly do bulletinu 30. srpna a jsou nezvykle konkrétní. V logu serveru se objevují řetězce jako DB URL: jdbc:derby:memory:pwn;create=true nebo chyba při vyhledávání karty začínající VALUES CAST(X'cafebabe – což je úvodní podpis javové třídy. Na disk přibývají soubory s pětiznakovým náhodným jménem: .class v adresáři server\lib, .cmd a .out v server\data\content.

Zveřejněná časová osa jednoho průniku ukazuje, co útočník na serveru dělal. Začal příkazy whoami a ver, po minutě si vypsal běžící procesy, po necelých pěti minutách seznam řadičů domény, po šesti přihlášené uživatele a obsah adresáře s profily. V šestnácté minutě si PowerShellem stáhl soubor ace.exe z veřejné úschovny, ve dvacáté ho tiše nainstaloval a ve dvaadvacáté už na stroji byla služba pojmenovaná „Remote Access Service“ – agent nástroje SimpleHelp, běžící jako LocalSystem a nastavený na automatický start. Ve dvacáté osmé minutě šel na řadu AnyDesk.

Huntress zneužití pozoroval ve dvou zákaznických prostředích a celý řetězec od nepřihlášeného požadavku po spuštění kódu zreprodukoval. Podle něj sloužily zachycené příkazy k průzkumu, ne k nasazení škodlivého kódu nebo k trvalému usazení v síti. Výrobce mluví o omezených a cílených útocích a další podrobnosti zatím zadržuje s odůvodněním, že by předčasné zveřejnění zkomplikovalo zasaženým zákazníkům jejich vlastní reakci. Kdo za útoky stojí, neřekl.

Lhůta pro americké úřady vyprší 14. září

CISA zapsala obě čísla do katalogu známých zneužívaných zranitelností 31. srpna. Federální civilní úřady mají podle směrnice BOD 26-04 čas do 14. září 2026: buď nasadit opravu podle pokynů výrobce, nebo produkt přestat používat. U obou záznamů je zatím kolonka o použití při ransomwarových kampaních vyplněná jako neznámá. Katalog měl k tomu dni 1 687 položek a PaperCut v něm figuruje popáté – tři starší záznamy jsou z roku 2023.

Ty tři nejsou náhoda. Chyba CVE-2023-27350, opět obejití ověření s během kódu, se stala v dubnu 2023 vstupní branou pro ransomwarové skupiny Clop a LockBit, íránské státem podporované aktéry i pro gang Bl00dy. V katalogu CISA je vedená jako známým způsobem využitá při ransomwaru.

Co dělat teď

První pokyn v bulletinu není záplata, ale odpojení. Kdo má aplikační server dostupný z internetu, má přístup k jeho webovým rozhraním omezit firewallem nebo síťovými pravidly jen na důvěryhodné adresy, a to bez ohledu na to, jestli něco podezřelého pozoroval. Doporučení platí i po nasazení opravy.

Aktualizovat se musí i site servery a sekundární tiskové servery, ne jen hlavní aplikační server. Serverové části Print Deploy a Mobility Print zasažené nejsou, stejně jako klientský software včetně uživatelského klienta a instalátoru Mobility Print. Kdo běží na verzi 23 nebo starší, záplatu nedostane vůbec a má přejít na novější vydání. Bulletin je označený jako aktivní a výrobce slibuje doplňovat další ověřené indikátory.

Zdroje: bezpečnostní bulletin PaperCutu z 27. srpna 2026, přehled zranitelností PaperCutu, oznámení CISA z 31. srpna 2026, katalog známých zneužívaných zranitelností, záznamy NVD a zpravodajství BleepingComputer.

Koš vrátí soubor jen tehdy, když ho smazal správce souborů. Přepsaný dokument nevrátí ani ten a s příkazem rm si neporadí vůbec. Projekt KDE Linux proto sáhl jinam: domovská složka každého uživatele je vlastní podsvazek Btrfs a systém jí sám dělá snímky. Oznámili to Nate Graham a John Veness v měsíčním přehledu z 31. srpna 2026.

Domovská složka je vlastní podsvazek

Snímek v Btrfs nekopíruje data. Systém souborů jen zamkne stav podsvazku a další zápisy odkládá vedle, takže snímek zpočátku nezabere skoro nic a roste až tím, co se změní. Podmínka je jediná: to, co se snímkuje, musí být podsvazek.

Domovské složky se jím staly s přestavbou kořenového systému souborů, které projekt říká RootFSv3. Podle zápisu úkolu 745, který si k tomu založil Hadi Chokr 10. srpna, je od té doby zakládá jako podsvazky přímo useradd. Zbývalo dostat je pod Snapper.

Konfigurace vzniká při přihlášení

Snapper si vede pro každý sledovaný podsvazek vlastní konfiguraci v /etc/snapper/configs a bez ní domovskou složku ignoruje. Konfigurace tedy musí vzniknout ve chvíli, kdy účet přibude – jenže na založení uživatele se v systemd pověsit nedá.

Řešení, které Chokr nahrál 14. srpna, obchází problém přes přihlášení. Služba kde-linux-snapper-home-config@.service se pouští s číslem uživatele jako instancí, vytáhne si ji doplněk k user@.service a spustí se tak při každém přihlášení. Skript pak zkontroluje, že číslo padne do rozmezí 1000 až 65534, že domovská složka opravdu je podsvazek a že konfigurace ještě neexistuje; jinak skončí bez práce.

Konfigurace se jmenuje podle čísla uživatele, ne podle jména. Komentář ve zdrojovém kódu k tomu říká, že z názvu konfigurace se stává název souboru a u účtů ze sítě jsou tvary DOMAIN\user nebo user@realm úplně běžné. Do položky ALLOW_USERS se pak doplní jméno majitele a SYNC_ACL zůstává zapnuté, takže si vlastník svoje snímky projde bez práv správce.

Uklízí se to podobnou oklikou. Nic se nespustí ve chvíli, kdy uživatele někdo smaže, a tak systém sleduje zápis do /etc/passwd a po něm pustí úklid osiřelých konfigurací i s jejich snímky. Jeden takový úklid se hned 16. srpna musel opravit: nešel dokončit, dokud v konfiguraci zůstalo jméno neexistujícího uživatele.

Šest hodinových, sedm denních

Šablona, ze které se konfigurace vyrábí, drží šest hodinových snímků, sedm denních, čtyři týdenní a dva měsíční. Čtvrtletní ani roční se nedělají. Smazat se snímek smí až po půl hodině existence, takže ten úplně čerstvý úklid nesebere.

Dvě věci šablona naopak schválně nepoužívá. Snímky před instalací a po ní tu nemají na čem viset, protože image systém žádný správce balíčků nemá. A úklid podle zabraného místa je vypnutý kvůli vlastnosti účtování: KDE Linux jede na zjednodušených kvótách Btrfs, které každý extent připíšou tomu podsvazku, který ho zabral jako první. Snímky proto vycházejí prázdné a limit na místo by se nikdy nespustil. Do šablony ho vývojáři napsali, ale s prázdnou skupinou kvót, tedy jako přípravu na dobu, kdy se účtování vyřeší.

Snímky se navíc musely schovat před indexováním. Baloo, který na ploše obsluhuje hledání, má nově vyloučenou složku .snapshots, a totéž si do konfigurace odnesl updatedb. Bez toho by se každá starší kopie domovské složky objevila ve výsledcích hledání.

Vracení souboru je v Dolphinu

Druhou půlku dodělal Bharadwaj Raju. Komponenta kio-snapshot má dva kusy: pracovníka KIO, kterým se procházejí snímky podsvazku a starší verze jednoho souboru, a zásuvný modul do kontextové nabídky, který je vyvěsí v Dolphinu a dalších aplikacích KDE. Repozitář vznikl 17. června 2026 a značku 1.0.0 dostal 20. srpna.

Kdo Snapper používá na vlastní distribuci, musí si podle souboru README sám dopsat ALLOW_USERS a zapnout SYNC_ACL. Na KDE Linuxu obojí obstará ta služba při přihlášení.

Zálohu to nenahradí

Vývojáři to píšou sami a bez okolků. Snímky leží na témže disku jako data, takže je porucha disku, ztráta notebooku ani krádež nepřežijí; jsou to zpětné kroky pro domovskou složku, ne záloha. Užitečné jsou i tak: záloha si může snímek vzít za zdroj a nemusí kopírovat data, která se jí pod rukama mění.

Co ještě v srpnu přibylo

Vedle snímků skončil v srpnu projekt na vstup v čínštině, japonštině, korejštině a vietnamštině. Fcitx5 a jeho doplňky ChineseAddons, Chewing, Mozc, Hangul a Unikey jsou předinstalované jako Flatpaky, takže uživateli zbývá je zapnout.

Yago Raña Gayoso odstranil nastavení, které dávalo přístup k soketu démona Dockeru každému ve skupině wheel. Instalátor hlásí průběh po menších krocích, aby nevypadal zaseknutě, a z nabídky zavaděče zmizela položka UEFI shell.

KDE Linux je pořád alfa verze a aktualizuje se denně; přizpůsobení systému je u něj záměrně omezené, protože je postavený na obrazu, ne na balíčcích. K betě mu podle srpnového přehledu chybí patnáct procent cesty.

Zdroje

• This Month in KDE Linux: August 2026, Nate Graham a John Veness, KDE Blogs
• Repozitář kde-linux – commity ze srpna 2026, šablona konfigurace Snapperu a jednotky systemd
• Repozitář kio-snapshot, KDE Invent
• Popis konfigurace Snapperu, snapper.io
• KDE Linux Now Providing Automatic Btrfs Snapshots For All User Files, Phoronix

Prohlížeč málokdy mluví se serverem přímo. Mezi nimi stojí prostředníci, tedy proxy servery ve firemní síti, brány poskytovatele nebo uzly sítě CDN. Norma HTTP Semantics jim dovoluje počkat si na celou zprávu a teprve pak ji poslat dál, a řada z nich to tak dělá.

U běžné stránky je to jedno. U aplikace, která data posílá průběžně, to znamená konec provozu. Právě na to míří RFC 10036, které pracovní skupina httpbis dotáhla do stavu navržené normy a IETF vydal v srpnu 2026. Napsali ho Kazuho Oku z Fastly, Tommy Pauly z Applu a Martin Thomson z Mozilly.

Prostředník, který čeká na tečku

Norma jmenuje dva případy. Prvním jsou Server-Sent Events, kde server drží jedinou dlouhou odpověď a posílá do ní oznámení, jak vznikají. Prostředník, který si takovou odpověď chce nejdřív uložit celou, čeká na její konec libovolně dlouho a klient se nedozví vůbec nic.

Druhým je návrh Chunked Oblivious HTTP Messages z února 2026. Klient v něm otevře požadavek a data do něj dosílá postupně, zatímco server může začít odpovídat dřív, než požadavek skončí. Z dvojice požadavek a odpověď se tak stane obousměrný kanál a prostředník, který si počká na celek, zastaví oba směry naráz.

Jedna hlavička, dvě hodnoty

Hlavička Incremental je strukturované pole typu Item podle RFC 9651, tedy jedna hodnota bez seznamu a bez slovníku. Platná je jen pravdivostní: ?1 znamená „posílej dál průběžně“, ?0 obvyklé chování. Cokoli jiného příjemce ignoruje.

Incremental: ?1

Pole se vztahuje na jednu zprávu, ne na dvojici. Když má průběžně téct požadavek i odpověď, musí ho mít obojí zvlášť. Prostředník, který u pravdivé hodnoty vyhoví, pošle dolů hlavičkovou část a pak předává bajty obsahu tak, jak přicházejí; hlavičky a přípony si přitom smí uložit celé, protože hlavička mluví o obsahu zprávy, ne o nich.

Zajímavá je i opačná hodnota. ?0 nic nemění, jenže výslovný signál dá prostředníkovi větší jistotu, že si zprávu uložit může. A žádost neplatí jen pro proxy: knihovna nebo rozhraní, které průběžný přenos obsahu neumí, má podle normy použít přítomnost hlavičky aspoň k tomu, aby ukládání omezila.

Odmítnout se smí, mlčky čekat ne

Tohle je na normě to podstatné. Když prostředník průběžné přeposlání odmítne, musí vrátit chybu, ne se tiše vrátit k ukládání celé zprávy. Klient se tak o problému dozví hned místo toho, aby čekal na odpověď, která nepřijde.

• Prostředník, který obsah zpráv prohlíží a pouští dál jen to, co uzná za bezpečné, potřebuje vidět celek. Odmítá natrvalo a má odpovědět kódem 501 s hlavičkou Proxy-Status podle RFC 9209 a chybou incremental_refused.
• Prostředník, kterému došla kapacita souběžných požadavků, odmítá dočasně kódem 429 a chybou connection_limit_reached. Norma počítá s tím, že si na průběžné požadavky nastaví přísnější strop než na ostatní, aby mu kvůli nim nedošla obsluha pro zbytek provozu.

Trochu ukládat se přitom smí dál. Okamžité posílání se dá zneužít k tomu, aby prostředník rozmělnil práci do spousty drobných paketů, takže si smí nastavit mez v bajtech nebo v čase. Držet data neomezeně ale nesmí: jakmile padne kterákoli z těch dvou mezí, jde obsah ven.

Záruka to není

Prostředník, který hlavičku nezná, si jí nevšimne a chová se jako dřív. Klient, jehož aplikace na průběžném doručování stojí, se proto podle normy musí spolehnout na to, co o cestě ví předem, nebo si podporu u konkrétního zdroje vyzkoušet.

Autoři k tomu sami dodávají výhradu, která se v takových dokumentech čte málokdy: kdo staví nad HTTP obousměrný protokol, udělá obvykle lépe, když sáhne po rozšířeném CONNECT (RFC 8441 pro HTTP/2, RFC 9220 pro HTTP/3). Ten do architektury HTTP zapadá líp.

Dosud si každý pomáhal po svém

Vyrovnávací paměť prostředníka se doteď vypínala lokálně. V nginxu je na to direktiva proxy_buffering a hlavička X-Accel-Buffering s hodnotami yes a no, kterou pošle server za proxy; správce ji navíc může nechat ignorovat. Funguje ale jen v nginxu a jen na odpovědi. Hlavička z RFC 10036 je proti tomu jedna žádost pro celý řetěz a platí i na požadavek.

IANA má obojí zapsané. V rejstříku jmen hlaviček HTTP stojí Incremental jako trvalé pole typu Item, v rejstříku chyb Proxy-Status pak incremental_refused s doporučeným kódem 501.

Práce na dokumentu trvala rok a čtyři měsíce: první verzi návrhu skupina zveřejnila 29. dubna 2025, poslední 2. března 2026. Jestli z toho něco bude, se pozná až podle toho, kolik proxy serverů hlavičku začne číst.

Zdroje

• RFC 10036: Incremental Forwarding of HTTP Messages, RFC Editor
• Záznam dokumentu v IETF Datatrackeru (dřívější draft-ietf-httpbis-incremental)
• Hypertext Transfer Protocol (HTTP) Field Name Registry a HTTP Proxy Error Types, IANA
• Dokumentace modulu ngx_http_proxy_module, nginx

Statický analyzátor PHPStan hledá v kódu PHP chyby, aniž by ho spustil. U větších projektů běží analýza v několika procesech naráz a právě tady je změna, kterou přineslo vydání 2.2.10 z 30. srpna 2026: paralelní procesy už nevznikají spuštěním dalšího PHP, ale rozvětvením toho, který analýzu řídí.

Rozvětvení místo spuštění

Rozvětvení procesu, tedy systémové volání fork, vyrobí kopii běžícího procesu i s tím, co má v paměti. Spuštění nového procesu naproti tomu začíná od nuly: čerstvé PHP musí načíst analyzátor, jeho nastavení a autoloader, a teprve pak se dostane k práci. Rozvětvený proces tohle všechno zdědí a stránky paměti mu operační systém sdílí tak dlouho, dokud do nich nezapíše.

Zapnout se to dalo už dřív proměnnou prostředí PHPSTAN_PARALLEL_FORK. Od vydání 2.2.10 je rozvětvení výchozí všude, kde může fungovat. Popis té změny jmenuje dvě podmínky: aktivní nativní rozšíření PHPStan Turbo v očekávané verzi a vypnutý OPcache i JIT. Kde některá z nich neplatí, spouští PHPStan procesy postaru.

Bez nativního rozšíření to nejde

Ta vazba na rozšíření vypadá jako libovůle, ale má konkrétní příčinu ve způsobu, jakým PHP čte archivy phar – a právě z takového archivu se PHPStan obvykle pouští. Knihovna phar drží na každý archiv a proces jediný otevřený popisovač souboru a čtení každé položky přes něj obslouží jako přesun a čtení. Po rozvětvení sdílejí všechny procesy tentýž popis otevřeného souboru, tedy jeden jediný kurzor v jádře. Souběžná čtení se proto proplétají a vracejí bajty z cizích míst; navenek to vypadá jako chyby při zpracování souborů uvnitř archivu. Oprava v samotném PHP podle autorů neexistuje a uživatelský kód se k tomu popisovači nedostane.

Rozšíření Turbo proto navěsí přes pthread_atfork() dvojici obsluh. První si těsně před rozvětvením poznamená kurzor u každého popisovače, který je nad archivem otevřený jen pro čtení. Druhá běží v potomkovi: archiv otevře znovu, kurzor obnoví a přes dup2() podstrčí soukromý popis pod původní číslo popisovače. Do vnitřností phar nesahá ani jedna. Test přiložený k rozšíření ukazuje obojí vedle sebe – bez té ochrany se čtení pokazí rodiči i všem osmi potomkům, s ní projde táž zátěž bez chyby.

Vedlejším ziskem je, že u instalací z archivu je nově urychlený i hlavní proces. Rozšíření se do něj dostane tak, že se hlavní proces sám znovu spustí přes pcntl_exec() s načtenou binárkou; potomci ho pak zdědí. Dosud se rozšíření vpravovalo až do spouštěných procesů parametrem na příkazové řádce, kam rozvětvený proces nedosáhne.

Na Windows se nemění nic

Rozvětvení procesu má v PHP na starosti modul Process Control a ten na Windows k dispozici není: dokumentace jazyka u něj rovnou uvádí, že mimo unixové platformy nepracuje. PHPStan tam proto zůstává u spouštění nových procesů.

Rozšíření Turbo samo přitom Windows podporuje. Balíček phpstan/phpstan podle popisu rozšíření vozí předkompilované binárky pro Linux, macOS i 64bitové Windows, a to pro PHP 8.3 a novější. Analýzu na Windows tedy zrychlí, na způsobu zakládání procesů ale nezmění nic.

Kolik to ušetřilo

Měření proběhlo na dvou velkých projektech, pokaždé s prázdnou vyrovnávací pamětí a se stejnou binárkou rozšíření u obou variant:

První tři řádky znamenají zlepšení o 10,9, 8,7 a 8,0 procenta. Poslední řádek jde proti nim a autor ho v poznámce vysvětluje tím, že měřicí stroj byl v tu chvíli vytížený něčím jiným; za stabilní údaj označuje čas procesoru, který se zlepšil na obou projektech.

Rozvětvení hned přineslo vlastní chybu

Zaváděcí soubory, které si projekt nechává provést před analýzou, běžely dosud jednou v hlavním procesu. Jakmile si takový soubor otevřel spojení do databáze, zdědili ho po rozvětvení všichni potomci a prali se o jediný socket; hlásilo se to jako neúspěšné založení transakce. Oprava, která je součástí téhož vydání, ty soubory provede v každém rozvětveném procesu zvlášť. Spouštěné procesy tenhle problém nikdy neměly, protože každý z nich ty soubory provedl sám.

Skenování adresářů bez vyrovnávací paměti

Druhá velká změna se týká rejstříku symbolů, který si PHPStan staví průchodem přes soubory v adresářích. Nejdražší část toho průchodu, čištění souboru od komentářů a řetězců, byla dosud cyklus přes jednotlivé bajty napsaný v PHP; nově ji dělá Turbo nativně. Na korpusu o 50 MB a 16 800 souborech klesl čas té části z 1,321 s na 0,111 s a čas celého sestavení rejstříku z 1,705 s na 0,445 s.

Podstatnější než ta čísla je, co z nich plyne. Vyrovnávací paměť rejstříku se zrušila celá: ověřit ji totiž znamená spočítat kontrolní součet každého souboru ve stromu, což na tomtéž korpusu trvá 0,419 s, tedy skoro stejně jako nové oskenování. Zmizel s ní i zámek, o který se paralelní procesy dělily. Na jednom z měřených projektů to ubralo 101,7 MB nejvyšší obsazené paměti a směrodatná odchylka mezi opakovanými běhy klesla ze 7,09 s na 1,41 s.

Číslo o spotřebě paměti nešlo ověřit

Do třetice opravuje vydání číslo, které analyzátor tiskne v podrobném režimu. Řádek Used memory vznikal jako součet nejvyšší spotřeby všech procesů a k tomu okamžitá spotřeba hlavního procesu, odečtená ve chvíli, kdy skončil ten první z nich. Procesy ale nemají vrchol ve stejný okamžik, takže ten součet popisoval stav, který nikdy nenastal.

U rozvětvených procesů se k tomu přidala vlastnost PHP, kterou stojí za to znát i mimo PHPStan: hodnotu z memory_get_peak_usage() potomek po rozvětvení dědí, takže proces, který si nic nealokoval, hlásí vrchol svého rodiče. Na jednom projektu se to sečetlo na 29,21 GB, přestože největší proces měl podle jádra vrchol 3,14 GB a součet skutečných vrcholů všech procesů byl 16,69 GB. Nově se tisknou dvě čísla zvlášť: vrchol hlavního procesu a vrchol největšího z rozvětvených.

Co z toho plyne pro práci

Kdo pouští PHPStan na Linuxu nebo macOS z balíčku nainstalovaného Composerem a má PHP 8.3 nebo novější, dostane rozvětvení bez jediného zásahu do nastavení. Kdo pracuje na Windows nebo si nechává zapnutý OPcache, zůstane u starého způsobu a rozdíl neuvidí. Výsledek analýzy je v obou případech stejný – autor u každého měření uvádí, že chybové výpisy byly bajt po bajtu shodné, a rozšíření se dá kdykoli vypnout proměnnou PHPSTAN_TURBO=0.

Zdroje

• Poznámky k vydání PHPStan 2.2.10, GitHub, 30. srpna 2026
• Popis přechodu na rozvětvené procesy, pull request 6260 v phpstan-src
• Provedení zaváděcích souborů v každém procesu zvlášť, pull request 6264
• Nativní skenování adresářů a zrušení vyrovnávací paměti, pull request 6304
• Hlášení nejvyšší spotřeby paměti po procesech, pull request 6297
• Popis rozšíření phpstan_turbo, GitHub
• Instalace modulu Process Control, dokumentace PHP

Uzávěrka je 31. srpna

Nápověda Play Console to říká bez okolků. Od 31. srpna 2026 musí nová aplikace i aktualizace cílit na Android 16 (API 36), jinak ji Google Play nepřijme. Nižší laťku mají jen některé platformy: Wear OS a Android Automotive OS vystačí s Androidem 15 (API 35), Android TV a Android XR s Androidem 14 (API 34). Kdo termín nestihne, může podle téže stránky požádat o odklad do 1. listopadu 2026; formuláře k žádosti mají v Play Console přibýt do konce roku.

Cílová úroveň API je číslo v manifestu a určuje, podle kterých pravidel systém s aplikací zachází. Vývojář, který má v obchodě hru postavenou na Godotu 3.6.2, tedy potřeboval nový export. Dostal ho devět dní před uzávěrkou.

Co se ve větvi 3.x změnilo

Rozdíl mezi 3.6.2 a 3.6.3 je vidět v souboru config.gradle na pár řádcích. Hodnoty compileSdk i targetSdk vyskočily z 35 na 36, nástroje pro sestavení z 35.0.0 na 36.1.0, NDK z 28.1.13356709 na 29.0.14206865 a Kotlin z 2.1.20 na 2.1.21.

Jedno číslo zůstalo na svém: minimální úroveň API je pořád 21. Godot 4.7.2 má na témže místě 24, takže hra ze starší větve se nainstaluje i na telefony, na které čtyřková řada nedosáhne. Pro projekty, které se kvůli tomu 3.x drží, je to podstatnější než zbytek seznamu změn dohromady.

Na Applu minimum 15.0 a konec 32 bitů

Druhá polovina důvodu je iOS. Sestavovací skript pro Apple posílá překladači parametr -miphoneos-version-min a ten v 3.6.2 zněl 12.0; ve 3.6.3 je to 15.0. Ze stejného souboru zmizely větve pro 32bitové architektury armv7 a i386. Autor té úpravy k tomu píše, že 32 bitů iOS nepodporuje od verze 11 a že 15.0 je nejnižší cíl, se kterým umí pracovat Xcode 27. Do exportu zároveň přibyla volba minimálního cíle.

Tabulka Applu to potvrzuje jen zčásti. Xcode 27, zatím ve fázi bety, opravdu vede jako rozsah cílů iOS 15 až 27 – jenže totéž má i Xcode 26.6, tedy poslední hotová verze nástroje. Práh iOS 15 není novinka příští generace Xcode; je to stav, ve kterém byl Godot 3.x už dřív pozadu.

Praskání zvuku ve Windows

Mezi opravami je i taková, kterou hráč slyší. Ovladač WASAPI si ve 3.6.2 přečetl velikost vyrovnávací paměti při startu a míchací vlákno s ní pak počítalo napořád. Ve 3.6.3 se vlákno ptá Windows voláním GetBufferSize v každém průchodu a teprve z čerstvé hodnoty počítá, kolik vzorků se do zařízení vejde. Seznam změn to popisuje jako opravu praskání, které způsobovala nesprávná velikost vyrovnávací paměti.

Ve stejném souboru je i druhá úprava, o odpojeném zařízení. Když Windows odpoví AUDCLNT_E_DEVICE_INVALIDATED, tedy že zvukový výstup zmizel pod rukama, ovladač už nevypíše chybu; zavře zařízení a napíše varování.

U té první opravy odkazuje seznam změn na pull request číslo 89283. Ten se do vývojové větve dostal už v březnu 2024. Do 3.x přichází teď.

Dvacet oprav, šestnáct lidí

Za vydáním je podle oznámení dvacet oprav od šestnácti přispěvatelů a sestavené je z commitu a3378686f. Knihovna mbedTLS je nově ve verzi 3.6.7, libpng ve verzi 1.6.58. Na Linuxu se odpověď hlasové syntézy zpracovává na hlavním vlákně, aby neuvázla komunikace se speech-dispatcherem, a interpolace fyziky si nově rozumí s vykreslováním v odděleném vlákně.

Nejdelší cestu má za sebou drobnost: chybějící nápověda k hlavičce funkce v GDScriptu. Pull request na ni někdo otevřel 9. listopadu 2022 a správci ho sloučili 20. února 2026. K uživatelům se dostává o půl roku později.

Seznam změn nemá oddíl s novinkami, jen Změněno a Opraveno. Godot 3.6.3 drží hry ze starší větve v obchodech, a přesně to uvádí oznámení projektu jako hlavní důvod, proč sestavení vůbec vzniklo.

Zdroje: oznámení vydání a značka 3.6.3-stable v repozitáři projektu, požadavky Google Play na cílovou úroveň API a tabulka podporovaných cílů na stránkách Applu.

Stroj nehledá člověka, hledá statistiku

„Systémy AI se skládají z více vrstev a nikdy se nenaučily, co je to člověk. Naučily se, jak lidé vypadají na milionech trénovacích obrázků,“ řekl Weckert Dezeenu; citace je přeložená. V raných vrstvách jde podle něj o hrany, kontrasty a přechody textur, hlouběji v síti už o části: silueta hlavy a ramen, poměr končetin k trupu, souvislý obrys těla proti pozadí. Člověk je pro stroj balíček vizuální statistiky, a přesně v tom je jeho slabina.

Vzor proto nevznikl od stolu. Weckert popisuje, že ho hledal ve smyčce se samotným detektorem: vygeneruje kandidáta, ukáže ho detektoru, změří, jak jistě v obraze pořád nachází člověka, upraví, opakuje – dokud jistota nespadne. Slepá místa stroje totiž nejsou pro člověka intuitivní. Navrhnout takový vzor okem nejde; co síť nevidí, řekne jen ta síť.

Nášivka přestane fungovat, když se otočíte

V technickém popisu projektu stojí tři odborné práce a první z nich vysvětluje, proč je souvislý potisk něco jiného než nášivka. Tým kolem Zhanhaa Hu ukázal v článku Adversarial Texture for Fooling Person Detectors in the Physical World, přijatém na konferenci CVPR 2022, že tištěné záplaty ztrácejí účinek, jakmile se změní úhel, pod kterým se kamera dívá. Autoři proto navrhli adversariální texturu: vzor s opakující se strukturou, který pokryje oděv libovolného tvaru, takže na něm není hrana, za kterou by šlo zajet. Ušili z ní trička, sukně i šaty a vyzkoušeli je ve fyzickém světě.

Kolik toho laboratoř naměřila

Novější práce jde dál a je nepříjemná pro obrany, které mezitím vznikly. V preprintu A Single Set of Adversarial Clothes Breaks Multiple Defense Methods in the Physical World z října 2025 autoři píšou, že obrany navržené proti záplatám selhávají už tehdy, když se záplata prostě zvětší. Jediná sada oblečení dosáhla proti nechráněnému detektoru Faster R-CNN úspěšnosti útoku 96,06 % a proti devíti chráněným modelům přes 64,84 % – měřeno ve fyzickém světě, ne jen na obrázcích v počítači.

Třetí citovaná práce, Physically Realistic Sequence-Level Adversarial Clothing for Robust Human-Detection Evasion, řeší to, co při chůzi rozbíjí všechno ostatní: látka se hýbe. Autoři neoptimalizují potisk na jednotlivé snímky, ale na celé video, počítají s pohybem, měnícím se úhlem i osvětlením a barvy zamykají profilem ICC, aby je tiskárna vůbec zvládla vytisknout. Hotové kusy pak vyrobili sublimačním tiskem. Dvě z těch tří prací zatím prošly jen na arXiv, recenzovaná je ta Huova.

Co se v Berlíně teprve rozjíždí

Kamera, na kterou vzor míří, na Kottbusser Tor zatím nestojí. Podle netzpolitik.org uzavřela berlínská policie výběrové řízení 26. května 2026, přihlásilo se pět firem a jméno vítěze si úřad zatím nechává pro sebe. První kamera se skenerem chování měla přibýt do konce třetího čtvrtletí. Agentura DPA psala začátkem srpna o srpnovém startu, jenže vnitřní správa se pro rbb24 na měsíc vázat nechtěla a mluvila dál jen o třetím čtvrtletí.

Obličeje systém rozpoznávat nemá. Má hledat nápadné vzorce chování a obsluze ukázat jen panáčky z čar; k biometrickému ztotožnění podle policie nedojde. Poplach má spustit i ležící člověk, a na náměstí, kde se zdržuje hodně lidí bez domova, to dopadne hlavně na ně. Matthias Marx z Chaos Computer Clubu na červnovém jednání výboru pro vnitřní věci zpochybnil, jestli se ti panáčci nedají zpětně zosobnit, třeba podle chůze nebo podle časových značek videa. Jak často podobné systémy spustí planý poplach, úřad nezveřejnil. Na techniku pro kriminalitou zatížená místa počítá rozpočet mezi lety 2026 a 2030 s 2,47 milionu eur na pořízení a 2,13 milionu na provoz.

Co ukázka dokládá a co ne

Weckert na svém webu píše rovnou, že demonstrace běží na obecném open-source detektoru YOLO a že o žádném konkrétním státním systému jeho práce netvrdí nic – právě proto, že takový systém nikdo zvenčí vyzkoušet nemůže. Berlínský skener chování je navíc jiná úloha než prosté „najdi v obraze člověka“: hodnotí, co se v záběru děje. Jestli na něj potisk zabere, se z videa nepozná.

Měřitelná zůstává ta druhá půlka. Adversariální oblečení v laboratoři funguje a obrany proti němu zaostávají: devět chráněných modelů propustilo útok ve víc než dvou třetinách pokusů. A protože poslední z citovaných prací už neřeší, jestli vzor sítě zmate, ale jak ho dostat na skutečnou látku, přestává to být úloha jen pro laboratoř.

Zdroje

• Simon Weckert: Digital Camouflage – popis projektu, použitý detektor a seznam odborných prací
• Dezeen, 25. srpna 2026 – rozhovor s autorem
• netzpolitik.org, 3. července 2026 – výběrové řízení a plán nasazení
• rbb24, 4. srpna 2026 – vyjádření vnitřní správy, kritika Chaos Computer Clubu, náklady

Osm metrů dolů s odchylkou do 25 milimetrů

Vrtá se svisle do podlahy tunelu, který byl vyražený už dřív. Hotová díra má být 8,4 metru hluboká a 1,75 metru široká. Přísné je zadání na přesnost: střed otvoru se po celé délce nesmí od svislé osy odchýlit o víc než 25 milimetrů. Stroj proto svou polohu sleduje průběžně a řídicími válci ji za chodu opravuje.

U prvních otvorů se kontroluje víc, než bude běžné. Nejméně tři z nich Posiva hned po dokončení zvlášť přeměří a teprve pak přejde do sériovějšího tempa. Otvor, který se do tolerance nevejde, se k ukládání nepoužije.

Deset hodin čistého vrtání

Osmimetrová díra zabere podle stavebního manažera provozu Kimma Lehtoly zhruba deset hodin čistého vrtání. „Čím tvrdší kámen, tím pomaleji to jde, ale těch deset hodin je v našich podmínkách slušné vodítko,“ řekl (citace přeložená z finštiny). Většina celkového času padne na něco jiného – na přípravu a ustavení stroje, na jeho rozebrání a přesuny a pak na vyčištění a vysušení hotového otvoru. Až se práce ustálí, chce Posiva zvládnout asi dva hotové otvory za pracovní týden.

Stroj váží 78 tun a horninu z vody odděluje separátor

Vrtačka se jmenuje DHBM podle anglického Deposition Hole Boring Machine a postavila ji německá Herrenknecht AG. Do Olkiluota dorazila v červnu 2022. Je přes devět metrů dlouhá, přes tři metry široká, skoro čtyři metry vysoká a váží 78 tun. Sama si nevystačí: vedle ní stojí dvaadvacetitunová energetická jednotka a separátor o hmotnosti 18,5 tuny, který z vrtné vody odděluje odvrtanou horninu. Té se při díře téhle velikosti nasype hodně.

U prvních vrtů je posádka větší než obvykle – všech pět operátorů a k tomu dva střídající se dozorci. Tři operátoři už vrtali dřív, dva se zaučují vedle nich; v běžném provozu má na otvor stačit trojice. Zkušební otvory vrtala na podzim 2022 nejdřív posádka výrobce, pak pokračovali lidé Posivy s její pomocí. World Nuclear News uvádí u obou skupin čtyři otvory; tisková zpráva Posivy počty nezmiňuje.

V prvním tunelu bude asi třicet otvorů

Tunel, ve kterém se teď vrtá, měří kolem 330 metrů a vejde se do něj zhruba třicet úložných otvorů. Za stoletou dobu provozu jich má vzniknout na sto s celkovou délkou kolem 35 kilometrů, uvádí World Nuclear News. Palivo se ukládá do kontejneru z mědi s ocelovou vložkou, kolem něj je bentonitová vrstva, tunel se zasype bobtnavým jílem a uzavře; poslední bariérou je samotná hornina. Hloubka, ve které kontejnery skončí, se v pramenech mírně liší – ministerstvo hospodářství a práce i Posiva píšou o zhruba 430 metrech, World Nuclear News o 450.

Povolení k provozu leží u vlády

Finský úřad pro radiační a jadernou bezpečnost STUK vydal 4. srpna 2026 kladné stanovisko k žádosti Posivy o povolení provozovat zařízení, kde se palivo uzavírá do kontejnerů, i samotné úložiště. Podle tiskové zprávy ministerstva hospodářství a práce jsou podmínky zákona o jaderné energii splněné a povolení platnému do konce roku 2070, o jaké Posiva žádá, nic nebrání. Žádost přitom leží na ministerstvu od 30. prosince 2021. Návrh rozhodnutí chce úřad předložit vládě na podzim.

Povolením to neskončí. I když ho vláda vydá, Posiva provoz nespustí dřív, než STUK provede kontrolu podle paragrafu 20 zákona o jaderné energii. Úřad k povolení navrhuje i podmínky: dřívější termín pravidelného hodnocení bezpečnosti, aktualizaci dokladu o dlouhodobé bezpečnosti a doplnění některých plánů kolem samotného ukládání. Ředitel Posivy Ilkka Poikolainen mluví o cíli být na zahájení ukládání připraveni do konce roku 2026.

Jestli první otvor obstojí, se v den, kdy vrtání začalo, ještě nevědělo. Geometrie a kvalita se měří až po dokončení a Posiva ve zprávě psala, že jasno bude o týden později. „Máme ale silnou důvěru, že se do tolerancí vejdeme,“ řekl k tomu Lehtola (citace přeložená z finštiny).

Zdroje: tisková zpráva Posivy z 27. srpna 2026, tisková zpráva finského ministerstva hospodářství a práce ze 4. srpna 2026 a World Nuclear News.

Raketa Ariane 62 odstartovala 27. srpna 2026 ve 22:11 SELČ z Evropského kosmodromu v Kourou ve Francouzské Guyaně. Náklad tvořila jediná družice: MTG-I2, druhý zobrazovací satelit třetí generace Meteosat. Šestatřicet minut po vzletu se oddělila na přechodové dráze ve výšce 2 778 kilometrů nad rovníkem a zamířila k místu, kde bude pracovat – na geostacionární dráhu ve 36 000 kilometrech.

Snímek Evropy každé dvě a půl minuty

Hlavní přístroj se jmenuje Flexible Combined Imager a umí pracovat v několika režimech snímkování. MTG-I2 dostala ten rychlý. Nad Evropou a severní Afrikou má obnovovat obraz každé dvě a půl minuty, což je podle zprávy organizace EUMETSAT dvojnásobná četnost proti rychlé službě předchozí generace družic. Čtyři kanály přístroje k tomu rozliší detail do 500 metrů.

Meteorologům jde o rychle rostoucí bouřky, kroupy, nárazový vítr a bleskové povodně, tedy o jevy, u kterých má podle EUMETSATu častější snímek dát předpovědi náskok. Vyhrazené kanály pro detekci ohně navíc umějí najít a popsat aktivní požár a sledovat, kudy se táhne kouř.

Souběžně pokračuje starší Meteosat-12, tedy první družice MTG-I, v pomalejším taktu: celý disk Země snímá po deseti minutách. Druhá zobrazovací družice k tomu podle ESA zajišťuje soustavě zálohu, kdyby první vypadla.

Přístroj, který počítá jednotlivé blesky

Druhý přístroj na palubě nese jméno Lightning Imager a zaznamenává jednotlivé blesky ve dne i v noci. Když s ním v prosinci 2022 odstartovala první družice MTG-I, byl v Evropě první svého druhu; MTG-I2 nese jeho shodnou kopii. Data z něj míří do nowcastingu, tedy do předpovědi na nejbližší hodiny, kde rozhoduje každá minuta.

Kdy poběží soustava celá, se zdroje neshodnou

Na dráze jsou teď tři družice MTG: Meteosat-12 ze startu v prosinci 2022, sondážní MTG-S1 z července 2025 a nová MTG-I2. Kdy budou pracovat všechny naráz, ale obě zúčastněné organizace popisují jinak. ESA ve své tiskové zprávě píše, že první dvě družice jsou plně uvedené do provozu a předané EUMETSATu k operační službě. EUMETSAT v textu z téhož dne u MTG-S1 uvádí, že operační se má stát teprve do konce roku 2026. Který údaj platí, nevysvětluje ani jedna zpráva.

Až budou v provozu všechny tři, poskládá se z jejich dat takzvaný weather cube – trojrozměrné zobrazení blesků, větru, dění uvnitř oblačnosti a atmosférických plynů včetně skleníkových plynů a látek znečišťujících ovzduší.

První cesta Ariane 6 na přechodovou dráhu

Pro raketu byl let označený VA270 devátý v pořadí a šestý ve verzi Ariane 62, tedy se dvěma pomocnými motory na tuhé palivo. Zároveň to byla první mise Ariane 6 na geostacionární přechodovou dráhu; předchozí lety končily níž. Arianespace jej vede jako svůj 362. start a čtvrtý v letošním roce. Družici Meteosat-12 dopravila v prosinci 2022 ještě Ariane 5 při letu VA259.

Co se s družicí děje teď

Po oddělení navázala MTG-I2 spojení se stanicí Malindi a rozvinula solární panely. Následují zhruba dva týdny manévrů, při kterých vlastní pohon postupně zvedne perigeum a srovná dráhu. Teprve pak se satelit natočí k Zemi, čímž skončí fáze startu a časných operací a začne kalibrace přístrojů. Ta zabere podle ESA týdny až měsíce a do jejího konce družice do operační služby nevstoupí.

Postavilo ji konsorcium evropských firem vedené společností Thales Alenia Space, hlavními partnery jsou německá OHB System a italská Leonardo. Vývoj vedla ESA podle požadavků, které posbíral EUMETSAT; ten satelity po uvedení do provozu řídí a rozesílá jejich data uživatelům.

Družice Meteosat druhé generace, které MTG nahrazuje, se na dráhu dostávaly mezi lety 2002 a 2015. Druhá rodina MTG má podle ESA startovat postupně od roku 2033 a prodloužit misi za rok 2040 – evropské meteorologické služby tedy budou z téhle řady brát podklady i po patnácti letech.

Chrysler (FCA US, LLC), tedy americká část Stellantisu, takovou akci oznámil americkému úřadu pro bezpečnost silničního provozu 13. srpna 2026. Vede se pod číslem 26V531000, vozů, kterých se může týkat, je podle spisu 844 027 a příčinou je software rádia.

Šestnáct modelů, jeden program

Seznam jde napříč celou americkou částí koncernu. Za ročník 2026 na něm stojí Jeep Wrangler, Gladiator, Compass, Cherokee, Grand Cherokee a Grand Cherokee L, Grand Wagoneer a Grand Wagoneer L, dále Ram 1500, Ram 2500, dodávka ProMaster i její elektrická verze, Chrysler Voyager, Pacifica v běžné i plug-in hybridní verzi a Dodge Charger. Pacifica a Charger jsou v seznamu i za ročník 2027.

Společné mají ty vozy podle spisu software rádia, ne model ani značku. Úřad akci vede pod položkou „back over prevention: sensing system: camera“, u Chrysleru má vlastní číslo 78D. V databázi úřadu se dotčené vozy dají hledat podle identifikačního čísla od 20. srpna, dopisy majitelům mají chodit od 1. září 2026.

Oprava jde vzduchem, strojový záznam ji tak neoznačuje

V popisu opravy stojí, že software rádia nahraje prodejce, nebo se stáhne vzduchem, a to zdarma. Mluvčí Stellantisu Frank Matyok řekl deníku Detroit Free Press, že kvůli opravě nemusí nikdo do servisu: až bude oprava připravená, objeví se výzva ke stažení přímo na displeji. Komu se stažení nepodaří, tomu ji nahraje prodejce.

Rozhraní, kterým úřad svolávací akce vydává strojově, u téhle akce nese pole overTheAirUpdate s hodnotou false. Že by to pole nikdo neplnil, tvrdit nejde: akce 24V554000 u Tesly z července 2024 v něm má true. Jenže 25V002000 z ledna 2025 popisuje opravu vzduchem taky a hodnotu má zase false. Kdo si svolávací akce třídí strojově podle tohohle pole, tuhle mezi opravami vzduchem nenajde.

Kolik vozů to je

Čísla se rozcházejí. Spis úřadu mluví o 844 027 možná dotčených vozech ve Spojených státech. Stellantis o čtyři dny později uvedl deníku Detroit Free Press číslo 848 511 a k němu odhady pro další trhy: 82 869 vozů v Kanadě, 7 969 v Mexiku a 15 736 mimo Severní Ameriku. Součet dává 955 085 vozů. Samotný americký údaj firmy je přitom o 4 484 vozů vyšší než číslo ve spisu; součet i rozdíl jsou náš dopočet z čísel, která ty dva zdroje uvádějí. Odkud rozdíl je, nevysvětluje ani jeden z nich.

Táž černá obrazovka, tři hlášení

Srpnová akce není první, ve které Chrysler tenhle příznak úřadu ohlásil. Dvě hlášení podal už 21. května 2026, obě v jediný den. Akce 26V326000 se týkala 59 kusů Jeepu Grand Wagoneer a Grand Wagoneer L ročníku 2026; příčinou je podle spisu špatně zapojený kabelový svazek přední kamery a opravou kontrola a zapojení konektoru. Akce 26V327000 obsáhla šestnáct vozů, a to Chrysler Pacifica ročníků 2019 a 2023, Ram 1500 a Ram 2500 ročníku 2024 a Jeep Wrangler ročníků 2024 a 2025. Příčinu popisuje jinak: znečištění centrálního modulu pro zpracování obrazu nebo chybné naprogramování. Modul se u ní buď přehraje novým softwarem, nebo vymění.

Tři akce, tři různě popsané příčiny, jeden předpis a jeden příznak. Že by firma velikost problému tajila, z toho ale neplyne. Předpis 49 CFR 573.6 dává výrobci na hlášení pět pracovních dnů od chvíle, kdy vadu potvrdí, a nečeká se, až pochopí její rozsah; co se do lhůty nevejde, doplňuje se dalším podáním. Úzce vymezená vada se proto ohlásí hned. Že by srpnová akce byla rozšířením těch květnových, ze spisů ovšem nevyplývá – každá stojí sama za sebe. K jedné vadě se ostatně akce vracejí i u jiných značek, třeba u Kie Telluride.

Co s tím může majitel

Než aktualizace dorazí, radí mluvčí couvat po staru, podle zrcátek. O žádném zranění v souvislosti s vadou firma podle svého vyjádření neví. Jistotu, jestli se akce týká konkrétního kusu, dá dotaz na identifikační číslo vozu v databázi úřadu. Dopis přijde až potom a někdy se opozdí pořádně: u letošní akce BMW odešly dopisy k předchozí svolávačce až po ohlášení té nové.

Zdroje: spisy svolávacích akcí 26V531000, 26V326000 a 26V327000 v rozhraní NHTSA; Detroit Free Press ze 17. srpna 2026; 49 CFR 573.6.

Kód alternativních režimů v jádře Linuxu měl dosud přímočaré pravidlo. Jakmile se protějšek na konektoru USB-C ohlásil, že umí DisplayPort nebo Thunderbolt, ovladač mu zaregistroval sadu obslužných funkcí a režim byl připravený k použití. Kabel mezi oběma stroji do toho rozhodnutí nemluvil, i když je to on, kdo signál musí přenést.

To mění série tří záplat nazvaná Restrict alternate modes based on cable capabilities. Jejím autorem je Andrei Kuchynski z týmu kolem ChromeOS u Googlu, návrh podal Heikki Krogerus z Intelu. Do hlavní větve jádra ji spolu s ostatními změnami podsystému USB a Thunderbolt poslal Greg Kroah-Hartman 25. srpna 2026.

Průvodní dopis popisuje, co bylo špatně: ovladače přiřazovaly obslužné funkce i tehdy, když je vlastnosti kabelu podepřít nemohly. Systém pak podle něj hlásil stav konfigurace, který neplatil, nebo alternativní režim selhal až při inicializaci.

Co si jádro o kabelu zjistí

Novou kontrolu dělá funkce typec_cable_altmode_unsupported() v souboru drivers/usb/typec/class.c. Uvnitř ní sedí pomocná funkce, která vrací tři stavy: podporováno, nepodporováno a neznámo. Zakazuje se jen prostřední z nich.

Nejdřív se jádro ptá, jestli pro daný režim existuje uzel na straně kabelové zástrčky. V řeči USB Power Delivery je to komunikace SOP', tedy pakety adresované čipu v kabelu, ne zařízení na druhém konci. Když takový uzel existuje, kabel se k režimu hlásí sám a kontrola tím končí.

Teprve když uzel chybí, sáhne jádro po identitě, kterou kabel vrátil na dotaz Discover Identity. Prázdná hlavička identity znamená kabel bez elektronické značky, takzvaného e-markeru, a alternativní režim se nepovolí. U pasivního kabelu rozhoduje pole rychlosti: hodnota odpovídající pouhému USB 2.0 režim vyloučí, cokoli rychlejšího ho pustí. A aktivní kabel, který uzel SOP' nenavázal, režim nedostane – aktivní kabel takovou komunikaci navázat musí, jinak ten konkrétní režim neumí.

Kontrola má slepé místo, které autor popisuje v komentáři sám. Když kabel žádnou identitu zaregistrovanou nemá, zůstává stav neznámo a režim se nabídne jako dřív. Pravidlo tedy vyřadí kabel, který o sobě něco řekne a to řečené nestačí, ne kabel, který mlčí.

Kde se kontrola volá

Oba ovladače alternativních režimů ji volají při navázání na zařízení. U Thunderboltu stačí jediná podmínka před registrací obslužných funkcí; když kabel režim neunese, funkce navázání skončí nulou. Ovladač tedy zůstane navázaný, ale bez obsluhy, takže se režim nedá aktivovat.

U DisplayPortu je podmínka o kousek složitější:

if ((alt->vdo & DP_CAP_RECEPTACLE) && typec_cable_altmode_unsupported(alt))
	return 0;

Přibylo v ní ověření, že zařízení má konektor, do kterého se kabel zapojuje. Pevně připojený kabel se totiž nekontroluje: podle popisu záplaty nemusí své schopnosti hlásit, ale je z výroby navržený tak, aby zařízení stačil. Ve stejné záplatě se registrace obslužných funkcí posunula až za tuhle podmínku – dřív stála hned na začátku.

Druhá změna: aktivní dotazování u USB4STREAM

Vedle toho přibyla v podsystému Thunderboltu volba busy_poll. Týká se rozhraní USB4STREAM, kterým si dva počítače spojené kabelem USB4 posílají data přímo; Intel ho do jádra dostal ve verzi 7.2.

Nový atribut v ConfigFS přepne vysílací i přijímací kruhy do režimu, kdy je čtení a zápis samy obcházejí dokola místo čekání na přerušení. Autor Mika Westerberg z Intelu v popisu záplaty píše i cenu za nižší prodlevu: spálí to víc cyklů procesoru, volání poll(2) začne vracet chybu, protože přerušení už nikoho nebudí, a blokující read(2) bez dostupných dat se točí dokola, dokud data nepřijdou nebo nedorazí signál. Záplata nese řádek Assisted-by: Claude:claude-opus-4-8.

Dokumentace rozhraní v jádře u toho atributu uvádí verzi 7.3 a datum listopad 2026. Samotná verze zatím vydaná není: kód v hlavní větvi je, ověřit se dá otevřením zmíněných dvou souborů, ale soubor Makefile v ní pořád nese číslo 7.2, protože slévací okno se v době psaní zavíralo teprve teď. Do téhož vydání míří i opravy v šifrovaném souborovém systému eCryptfs.

Zdroje

• Greg Kroah-Hartman: [GIT PULL] USB/Thunderbolt driver updates for 7.3-rc1, konference vývojářů jádra, 25. srpna 2026
• Andrei Kuchynski: usb: typec: Add helper to check cable altmode support, konference linux-usb, 26. června 2026
• Andrei Kuchynski: usb: typec: displayport: Check cable altmode support, konference linux-usb, 26. června 2026
• Mika Westerberg: thunderbolt: stream: Add support for busy polling, konference linux-usb, 28. července 2026
• Michael Larabel: Linux 7.3 Will Begin Checking USB-C Cables For Alt-Mode Support, Phoronix, 28. srpna 2026

Elektrony v magnetických materiálech se dlouho vešly do dvou vzorců. Ve feromagnetu míří všechny spiny stejným směrem a látka má navenek vlastní magnetické pole. V antiferomagnetu se spiny střídají nahoru a dolů, navenek se vyruší a elektrony obou orientací mají při stejné hybnosti stejnou energii. Antimonid chromu nezapadá ani do jednoho z nich a práce zveřejněná 26. srpna 2026 v časopise Nature to u kovu poprvé doložila měřením, které vidí dovnitř krystalu, ne jen na jeho povrch.

Třetí druh uspořádání

Altermagnet vypadá na první pohled jako antiferomagnet: sousední atomy mají opačně otočené magnetické momenty a celková magnetizace vychází nula. Rozdíl je v symetrii, která obě podmřížky spojuje. U antiferomagnetu stačí posun o jednu mřížkovou konstantu nebo inverze, u altermagnetu je potřeba otočení.

V antimonidu chromu to zařídí uspořádání antimonu. Látka krystalizuje v šesterečné struktuře typu NiAs, atomy chromu leží ve vrstvách podél osy c a antimon vyplňuje mezery v trojbokém uspořádání. Chromový atom se spinem nahoru proto přejde na atom se spinem dolů teprve šroubovou operací 6₃, tedy otočením spojeným s posunem. Následek je zásadní: Kramersova degenerace přestává platit a energetické pásy se štěpí podle spinu, přestože k tomu není potřeba spinorbitální interakce. Altermagnet tak spojuje nulovou celkovou magnetizaci antiferomagnetu se spinově rozštěpenými pásy feromagnetu.

Povrch dokáže klamat

Kovových kandidátů na altermagnet je málo a dva z nich se mezitím ukázaly jako slepá ulička. U oxidu ruthenia RuO₂ naznačovala fotoemisní spektroskopie štěpení pásů, jenže následná měření citlivá na objem vzorku o jeho magnetismu vyvolala vážné pochyby. Další fotoemisní práce našly topologický povrchový stav s Rashbovým štěpením, který altermagneticky zrušenou degeneraci napodobuje, ačkoli vnitřek krystalu je nemagnetický.

Podobně dopadl KV₂Se₂O. Altermagnetická může být jeho svrchní vrstva, ale neutronová difrakce nachází v objemu krystalu obyčejný antiferomagnetismus. Právě proto se tým rozhodl pro metodu, která povrch nevidí vůbec.

Co se měří v poli 41,5 tesla

Kvantové oscilace jsou stará technika s jednoduchým principem. V dostatečně silném magnetickém poli se dovolené stavy elektronů slévají do Landauových hladin a veličiny jako magnetizace nebo moment síly, kterým pole natáčí vzorek, začnou periodicky kolísat s převrácenou hodnotou pole. Perioda těch oscilací nese plochu průřezu Fermiho plochy kolmo ke směru pole. Metoda tedy měří elektrony v celém objemu vzorku, ne jen ty, které se dají vystřelit z jeho povrchu.

Skupina z univerzity v Cambridgi měřila de Haasův–van Alphenův jev v rezistivním magnetu s polem do 41,5 tesla v americké National High Magnetic Field Laboratory v Tallahassee. Vzorek byl v prostředí helia 3 při 0,4 K a natáčel s ním přímo v magnetu bezkartáčový lineární motor; úhly se kalibrovaly podle změny znaménka pozadí a ověřovaly Hallovou sondou. Podle přehledu, který k práci vydala sama laboratoř, přispěla k měření ještě drážďanská HLD-EMFL s pulzním polem do 64 tesla.

Jedna špička, nebo dvě

Uzlová rovina je místo, kde symetrie vynutí, aby se energie obou spinů srovnaly. Pole položené do takové roviny nutí elektrony obou orientací obíhat po drahách, které se sice liší, ale zrcadlí se jedna na druhou, takže uzavírají stejnou plochu. Ve frekvenčním spektru je pak jediná špička. Mimo uzlovou rovinu už žádná symetrie obě dráhy nespojuje, plochy se rozejdou a špička se rozpadne na dvě. Přesně to tým naměřil.

Otáčením pole ve třech různých rovinách napočítali autoři uzlové roviny čtyři: tři platí pro všechny polární úhly při azimutu 0, 60 a 120 stupňů a čtvrtá pro všechny azimuty v bazální rovině. Počet uzlových rovin určuje typ uspořádání – p-vlna má jednu, d-vlna dvě, f-vlna tři a g-vlna čtyři. Naměřený průběh štěpení odpovídá reálné sférické harmonické funkci Y₄⁻³, tedy tvaru, který u atomu vodíku patří orbitalu g. Z rozdílu frekvencí a z efektivní hmotnosti 2,03 hmotnosti elektronu vychází štěpení na Fermiho hladině zhruba 25 meV.

Kov, který drží uspořádání i za horka

Pro použití v součástkách je podstatné, že antimonid chromu není jen kov, ale kov s vysokou teplotou uspořádání. Měření magnetizace do 800 K ukazuje zlom kolem 740 K, tedy hluboko nad běžnou provozní teplotou; podle autorů je ta hodnota o něco vyšší než dřívější údaje díky lepší kvalitě krystalu.

Laboratoř v Tallahassee shrnuje význam do tří bodů: materiál bez vlastního magnetického pole neruší sousední prvky obvodu, dva spinové proudy se dají použít k zápisu informace a uspořádání drží vysoko nad pokojovou teplotou. Od změřené Fermiho plochy k paměťové buňce je ale daleko. Práce říká, jaký ten materiál uvnitř je, ne že z něj někdo něco postavil.

Zajímavá je i samotná metoda. Symetrii parametru uspořádání se u nekonvenčních supravodičů daří rozlišit jen obtížně a spory o ni trvají desítky let. Tady se ukázalo, že u magnetů na to stačí otáčet vzorkem v silném poli a počítat špičky ve spektru.

Zdroje

• Long, M. a kol.: 3D bulk-resolved g-wave altermagnetic order parameter in CrSb, Nature 656, 854–860 (2026), otevřený přístup
• Táž práce v preprintovém archivu arXiv (2601.14526)
• National High Magnetic Field Laboratory: A New Kind of Magnetism, Mapped in 3D Inside a Metal, 18. srpna 2026

Bezpečnostní vydání ohlašuje Next.js dopředu. 20. srpna napsal, že 26. srpna vyjdou verze 16.3.3 a 15.5.24 a zavřou jednu kritickou chybu. O pět dní později přišla oprava toho oznámení: chyby jsou dvě, ta druhá se našla v cizí knihovně a vydání se posouvá o den dopředu, aby provozovatelé aktualizovali jen jednou. Balíčky se objevily 25. srpna odpoledne.

Přetečení haldy sedí v libheif

Zranitelnost vedená jako GHSA-2xp9-vwfh-vxw4 není v kódu rámce. Next.js zmenšuje obrázky balíkem sharp, ten uvnitř používá libvips a ta pro formáty rodiny HEIF sahá po knihovně libheif. Díra je až na konci téhle řady.

Autor libheif ji popsal v samostatném hlášení GHSA-g89c-p67h-r497 a ohodnotil ji 9,8 bodu z deseti. Skládá se ze čtyř kroků, z nichž ani jeden není sám o sobě chybný. Soubor HEIC, HEIF nebo AVIF smí obsahovat položku typu iden, tedy odkaz „tenhle obrázek je totožný s jiným“, a k ní vlastní alfa kanál. Dekodér pak drží v jednom obrázku dvě alfa roviny: osmibitovou z odkazovaného snímku a desetibitovou z položky iden. Funkce, která rovinu hledá podle kanálu, vrátí jen tu první, takže se paměť pro výsledek odměří podle osmi bitů na vzorek. Zvětšovací smyčka ale projde obě roviny a u té desetibitové zapisuje dva bajty tam, kde je místo na jeden.

U snímku 128 × 128 bodů to dělá 16 384 bajtů zapsaných za koncem přiděleného místa. Co se tam zapíše, řídí obsah souboru, takže útočník má nad koncem té paměti kontrolu. Hlášení k tomu přikládá celý generátor zkušebního souboru.

Číslo CVE k té chybě zatím nikdo nepřidělil. Opravená je verze libheif 1.23.2, vydaná rovněž 25. srpna; předchozí 1.23.1 byla venku od 26. června. Ve stejném vydání je i druhá kritická chyba se značkou GHSA-2jg2-4ch7-h545 a u ní poznámky k vydání píšou rovnou, že funkční exploit se spuštěním kódu se potvrdil.

Vypíná se čtení, ne zápis

Optimalizátor v Next.js si drží seznam povolených čtecích operací libvips: nejdřív zablokuje celou skupinu VipsForeignLoad a pak jmenovitě odblokuje JPEG, PNG, GIF, WebP a několik dalších. Oprava z toho seznamu vyškrtla jedinou položku, VipsForeignLoadHeif. K tomu přibyla podmínka, že požadavek na obrázek ve formátu AVIF projde optimalizátorem beze změny, jako by šlo o typ, kterému nerozumí.

Provozovatel to pozná na třech místech. Zdrojové obrázky AVIF se přestaly zmenšovat a jdou ke čtenáři v původním rozlišení. Statické importy souborů AVIF nedostanou rozmazaný náhled, protože ten se počítá z dekódovaného obrázku. A prohlížeč, který AVIF neumí, dostane AVIF: v testech rámce zastupuje tuhle skupinu starší Safari a dřív mu optimalizátor posílal obrázek převedený do JPEG.

Výstupu se zákaz netýká. Kdo má zdroje v JPEG a nechává si je převádět do AVIF, o nic nepřišel; zablokované je čtení formátu, ne zápis do něj.

Pro toho, kdo se bez optimalizace vstupních souborů AVIF neobejde, přibyl v nastavení přepínač experimental.imgOptDangerouslyAllowAVIF. Jeho popis přímo ve zdrojovém kódu říká, že zapnutím se aplikace vystavuje bezpečnostnímu riziku v nativních dekodérech obrázků.

Druhá chyba míří na Windows

Zranitelnost CVE-2026-75604 dostala 9,0 bodu a týká se aplikací, které vedle sebe používají Pages Router i App Router a nemají zapnuté Cache Components. Podmínkou je souborový systém Windows pod serverem; Linux ani macOS zasažené nejsou. Hlášení chybu řadí pod CWE-22, tedy k vadnému ošetření cest k souborům, a uvádí, že žádné obejití není známé. Jediná cesta je aktualizovat. Postižené jsou verze od 13.4 a od 16.0, obě řady zavírají 15.5.24 a 16.3.3.

V databázi NVD to číslo 28. srpna ještě žádný záznam nemělo. Popis je zatím jen v hlášení na GitHubu, kde stojí i jména dvou nálezců.

Koho se to týká

Balík next měl v týdnu od 20. do 26. srpna 54 611 955 stažení z registru npm. Není to počet zasažených serverů, jen měřítko, ve kterém se rámec pohybuje.

Rozhoduje způsob provozu. Netlify ještě v den vydání napsalo, že jeho weby zasažené nejsou. Požadavky na cestu /_next/image přepisuje už na okraji své sítě do vlastní služby na obrázky, takže se optimalizátor Next.js vůbec nespustí, a chyba kolem Windows na něj nesedí, protože jeho funkce běží na Linuxu. Aktualizovat přesto doporučuje.

Nejvíc práce zbývá na vlastní provoz, tedy tam, kde si Next.js spouští sharp sám a nikdo mu do cesty k obrázkům nevstupuje.

Řetěz se mezitím uzavřel

Důvod, proč rámec AVIF vypnul, už do velké míry pominul. Opravená libheif 1.23.2 vyšla 25. srpna dopoledne, druhý den ráno se objevila sada knihoven sharp-libvips 1.3.3, která ji obsahuje, a hodinu po ní balík sharp 0.35.4.

Vypnuté AVIF v Next.js přesto platí dál. V poznámkách k vývojovým verzím rámce se do 27. srpna o jeho návratu nepíše a je to pochopitelné: rámec nemá jak zjistit, jakou verzi sharpu má u sebe kdo nainstalovanou. Přepínač se slovem dangerously v názvu tuhle jistotu nechává na provozovateli.

Zdroje: bezpečnostní vydání Next.js z 25. srpna, jeho ohlášení z 20. srpna, hlášení GHSA-2xp9-vwfh-vxw4, GHSA-p293-qw3h-jr36 a GHSA-g89c-p67h-r497, poznámky k vydání libheif 1.23.2, soupis knihoven v sharp-libvips 1.3.3 a stanovisko Netlify.

Asahi Linux přenáší Linux na počítače Applu s vlastními čipy. Dokumentaci k tomu hardwaru Apple nevydává, takže se ovladače píšou podle toho, co o sobě křemík prozradí, když ho obsluhuje macOS. Zprávu o postupu vydává projekt vždycky s novou verzí jádra; ta poslední, vázaná na Linux 7.2, vyšla 26. srpna 2026.

Nejdůležitější věta v ní je krátká. Tým píše, že je téměř připravený vydat oficiální verzi, a slibuje podrobnosti v nadcházejících týdnech. Datum v textu není.

Co na řadě M3 zbývalo dodělat

Obrazový procesor webkamery zůstal proti starším čipům skoro beze změny. Lišil se jediným vynechaným inicializačním vzkazem, a to jen u M3 Max. Po jeho doplnění do ovladače funguje webkamera na všech zařízeních řady M3, která ji mají vestavěnou.

U vestavěných mikrofonů byla změna větší. Řada M3 přinesla nový vysokofrekvenční decimátor, tedy blok, který převádí surový tok bitů z mikrofonu na vzorkovaný zvuk. Potřebuje jinou sadu koeficientů a podstatně delší inicializační vzkaz. I ten je hotový.

Nejvíc práce si vyžádal řadič portů USB-C. Od M1 až po základní M3 v něm Apple používal upravený obvod Texas Instruments CD3217, kterému se uvnitř projektu říká ACE2 a který visí na sběrnici I2C. Od M3 Pro a M3 Max přešel na ACE3, a ten je připojený přes sběrnici SPMI. Reverzní inženýrství ukázalo, že sada registrů je prakticky táž, jen zabalená do jiného rozhraní. Nové ladicí hodnoty musel dostat i blok ATCPHY, který na portech USB-C domlouvá USB 3, DisplayPort a Thunderbolt; změnil se kvůli přechodu na výrobní proces TSMC N3. USB 3.0 a Thunderbolt teď jedou na všech strojích řady M3.

Zbývá grafika a displej. Firmware grafického jádra AGX i řadiče displeje DCP je svázaný s konkrétní verzí macOS, takže si projekt pro každou generaci hardwaru vybírá jednu, na kterou míří. U řady M3 je to macOS 14.8.3. Podpora řadiče displeje je podle zprávy skoro na téže úrovni jako u rozhraní macOS 13.5, které projekt používá na M1 a M2.

Applu chybí patro, ve kterém běží správa napájení

Na architektuře ARM se uspávání a probouzení jader obvykle řeší rozhraním PSCI: jádro systému zavolá firmware o patro níž, do Exception Level 3, a ten se o procesorové jádro postará. Čipy Applu ale EL3 vůbec nemají. Linux na nich běží v EL2 a nemá komu ten dotaz položit.

Asahi to zatím obchází vlastním ovladačem cpuidle, který jádro uspí přímo instrukcí WFI. Do hlavní větve Linuxu se takový ovladač dostat nemůže: správci kódu pro arm64 trvají na tom, že napájení řídí PSCI, a nic jiného.

Obchvat, se kterým přichází Sven Peter, stojí na zavaděči m1n1. Ten si vyhradí kus paměti, zůstane v ní i po startu systému a nechá tam implementaci PSCI; jádro se do ní dostane přes běhové služby UEFI, které m1n1 stejně už poskytuje kvůli zavádění přes U-Boot. Specifikace PSCI od Armu totiž instrukce SMC a HVC uvádí jen jako příklady, ne jako uzavřený výčet. Návrh leží v konferenci vývojářů jádra od 8. července 2026 jako série šesti záplat označená RFC; sahá do osmi souborů a přidává 261 řádků.

M4 nesmí zavolat WFI

Na řadě M4 je situace horší. Od ní Apple nastavuje takzvané chicken bits, tedy hardwarové přepínače chování jádra, ve svém zavaděči a registry, kterými se ovládají, pak zamkne. Jedním z nich se určuje, jestli si jádro při WFI zachová stav. Specifikace ARM to nařizuje; na M4 to tak nastavené není, takže volání WFI jádro rozhodí a spadne s ním i všechno, co na něm běželo.

Přišlo se na to při zprovozňování M4. Do jádra pak přibyl parametr příkazové řádky, kterým se dá určit, jak se má nečinné procesorové jádro parkovat – třeba prázdnou smyčkou. Stroje s M4 tak nespadnou hned na začátku startu, než se načte ovladač cpuidle; ten pak stav uloží sám a WFI zavolá až potom. Záplaty jsou ve větvi linux-next.

M4 a M5 zatím jen napůl

Na M4 a M5 se rozběhlo úložiště. Firmware řadiče NVMe se v balíku k macOS 15.x změnil způsobem, který dosavadní kód rozbil; po dohledání změn a jejich přenesení do m1n1 i do Linuxu NVMe na obou řadách funguje. PCIe je ve stavu, kdy Linux zařízení na sběrnici alespoň vypíše, a opravená je i chyba, kvůli které systém spadl krátce po startu, jakmile bylo zapnuté víc než jedno jádro. Na zařazení do instalátoru Asahi to podle zprávy pořád nestačí.

Vedle toho se vrátil hypervizor m1n1, tedy nástroj, kterým projekt sleduje, co macOS s hardwarem dělá. Od M4 Apple vyžaduje, aby se před jádrem XNU zavedl Secure Page Table Monitor, který mu odebírá správu tabulek stránek; bez něj XNU zpanikaří hned v úvodu startu. m1n1 tohle prostředí neuměl, takže hypervizor byl na těchhle strojích mrtvý. Teď je umí napodobit, takže se Applův binární soubor dá zavést a sledování hardwaru pokračuje – jen pomaleji.

Video se dekóduje, na obrazovku ještě nejde přímo

Dekódovací blok AVD zvládá H.264, H.265 a VP9 na M1 a M2 a na M3 a novějších k tomu AV1. Podle zprávy jsou první tři formáty spolehlivé na všech podporovaných strojích. Do systému Fedora Asahi Remix se ale zrychlené dekódování zatím neposílá a s pískovištěm, ve kterém dekóduje video Firefox, nespolupracuje.

Druhá polovina úlohy je poslat hotový snímek na displej bez zbytečného kopírování. Ovladač DCP i obě grafické knihovny projektu už formát, který k tomu Apple používá, umějí. Brzdou je KDE Plasma: její kompozitor KWin považuje grafické jádro a řadič displeje za dvě různé grafické karty a přímé zobrazení přes DMA-BUF v takovém případě vypíná úplně. Vývojáři KWinu na tom podle zprávy pracují.

Vydání není totéž co podpora v hlavní větvi

Chystané vydání neznamená, že tenhle hardware umí i hlavní větev Linuxu. Většina popsané práce žije ve vlastní větvi projektu a do jádra putuje po částech; ovladač uspávání jader se do něj nedostane vůbec, dokud návrh PSCI přes UEFI někdo ze správců arm64 nepřijme. Server Phoronix, který zprávu shrnul týž den, to říká stejně: podpora M3 zamíří k uživatelům přes vlastní kód projektu a cesta do hlavní větve bude delší.

Zdroje

• Asahi Linux: Progress Report: Linux 7.2, 26. srpna 2026
• Sven Peter: [PATCH RFC 0/6] PSCI-via-EFI to support firmware and kernel sharing EL2 for Apple Silicon, konference linux-arm-kernel, 8. července 2026
• Phoronix: Asahi Linux Hopes To Ship A Release Soon With Apple M3 Device Support, 26. srpna 2026

Cloudflare zveřejnil 18. srpna 2026 měření toho, jak se na internetu ujímá norma RFC 9234. Ta popisuje způsob, jakým si dva sousední směrovače řeknou, v jakém jsou vztahu, a jak podle toho samy poznají trasu, která se dostala tam, kam neměla. Bryton Herdes, Iliana Xygkou a Mingwei Zhang k tomu vypustili do internetu dva testovací prefixy. Při jejich sledování narazili na něco, co nehledali: dvě páteřní sítě z tras mažou právě ten atribut, na kterém celý mechanismus stojí.

Únik trasy je porušená dohoda, ne porucha

Trasy se v BGP šíří podle obchodních vztahů mezi autonomními systémy. Zákazník platí poskytovateli za přístup ke zbytku internetu, dva rovnocenní partneři si provoz vyměňují většinou bez placení. Z toho plyne pravidlo, kterému se říká valley-free: trasu naučenou od poskytovatele nebo od partnera smí síť ohlásit jen svým zákazníkům, nikdy zpátky nahoru. Únik trasy, jak ho definuje RFC 7908, je porušení téhle dohody. Provoz se pak vydá cestou, kterou nikdo nezamýšlel, a leckdy po ní neprojde celý.

Bránit se dalo dosud jen ručně psanými filtry na každé relaci zvlášť. Že to nestačí, ukázala i přehledová práce, o které jsme psali začátkem srpna: úniky tras patří mezi třídy útoků na BGP, proti kterým žádná kryptografická obrana neexistuje.

Role a razítko, které smí jen dolů

RFC 9234 vydali v květnu 2022 Alexander Azimov, Eugene Bogomazov, Randy Bush, Keyur Patel a Kotikalapudi Sriram. Přidává do protokolu dvě věci.

První je schopnost BGP Role, zapsaná v rejstříku IANA pod kódem 9. Sousedé si ji vymění při navazování relace a každý v ní řekne, čím je tomu druhému: poskytovatel, zákazník, partner, route server, nebo klient route serveru. Platných dvojic je pět, a když se sousedé neshodnou, relace vůbec nenaběhne – směrovač ji odmítne oznámením Role Mismatch s kódem 2 a podkódem 11. Nedorozumění o tom, kdo je komu kým, tak vyjde najevo hned, ne za rok jako incident.

Druhá je atribut Only to Customer, zkráceně OTC, typ 35. Nese jediné číslo autonomního systému, a to toho, kdo trasu poprvé poslal do strany nebo dolů. Od té chvíle smí trasa putovat už jen k zákazníkům. Trasa s OTC přicházející od zákazníka je podle normy únik a směrovač ji zahodí sám, bez jediného řádku ručního filtru.

Kolik sítí to má opravdu zapnuté

Změřit nasazení je těžší, než by se čekalo. Norma totiž nechává atribut doplnit i příjemce: kdo dostane trasu od poskytovatele, partnera nebo route serveru bez OTC, musí ho dosadit sám. Z hotové trasy pak nejde poznat, kdo razítko přitiskl.

Cloudflare to zkusil dvěma cestami. Ve veřejných sběrných bodech RouteViews a RIPE RIS napočítal 361 různých hodnot OTC, jenže právě dosazování na vstupu to číslo nafukuje. Po odfiltrování zbylo 36 autonomních systémů, o kterých se dá říct, že normu možná dodržují.

Druhá cesta vede přes vlastní síť. Cloudflare se přímo propojuje s tisíci sítěmi a u takového souseda se pozná, jestli OTC nastavil on: hodnota se musí rovnat jeho vlastnímu číslu AS. Ze tří měsíců sledování vyšlo 67 autonomních systémů. Nadprůměrně jsou mezi nimi zastoupené route servery propojovacích uzlů – běží často na otevřených implementacích BGP, které novinky přebírají rychleji – a sítě provozované jednotlivci.

Patnáct sítí, které atribut smazaly

Druhá část práce je pokus. Cloudflare ohlásil ze všech svých propojovacích míst jeden prefix v IPv4 a jeden v IPv6, oba s OTC nastaveným na vlastní číslo AS13335. Po ověření, že se rozšířily po světě, je zase stáhl: stažení rozhýbe hledání náhradních cest a ukáže víc tras, než kolik jich je vidět v klidu. Stejným způsobem tatáž firma koncem července zjišťovala, co se cestou stane s atributem ORIGIN.

Zprávy z veřejných sběračů rozebral nástroj BGPKIT. První krok byl jednoduchý: u cesty tvaru „ASX AS13335“ nemůže atribut zmizet nikde jinde než u ASX. Takhle se našlo šest sítí, z toho dvě páteřní – AS3257 (GTT) a AS1299 (Arelion). Postupným rozšiřováním na delší cesty jich přibylo dalších devět.

Podstatnější než počet je dosah. Bez OTC dorazila třetina cest v IPv4 (33,1 %) a šestina v IPv6 (17 %). Přes GTT nebo Arelion přitom vedlo 96,6 % takových cest v IPv4 a 92,9 % v IPv6. Když se měření zúžilo na cesty, kde je jedna z těch dvou sítí bezprostředním sousedem Cloudflaru, GTT mazal atribut pokaždé, kdežto u Arelionu chybělo OTC u 71,4 % cest v IPv4 a 40,7 % v IPv6. Arelion ho tedy odstraňoval nedůsledně, podle místa ve vlastní síti.

Zvyk z doby, kdy jeden poškozený atribut shazoval relace po celém světě

Obě sítě Cloudflare oslovil a obě mazání potvrdily. Není to nedbalost, ale obranný návyk. OTC je atribut volitelný tranzitivní, což podle RFC 4271 znamená, že ho směrovač nemá zahazovat, ani když mu nerozumí, a má ho poslat dál. Jenže dokud platilo jen původní znění, dokázal poškozený atribut shodit relaci – a protože se šířil dál, padaly relace i tisíce kilometrů od místa, kde vznikl. Část operátorů si tehdy zvykla neznámé atributy raději odstraňovat. RFC 7606 to vyřešilo jinak: poškozený atribut dnes vede k zahození dotčených prefixů, ne k rozpadu relace.

Arelion podle Cloudflaru krátce po tom rozhovoru nasadil konfiguraci, která OTC zachovává. Ověřit se to dá dotazem nad archivem sběrače route-views4 – testovací prefix se v něm od 18. srpna vrací s cestou přes Arelion a s atributem na svém místě. GTT ho podle téhož textu maže dál.

Zapnout role jde jen na části směrovačů

Cloudflare k srpnu 2026 vypsal, kdo normu umí. Podporu mají Junos, RouterOS, BIRD, OpenBGPD a FRR, u Cisco IOS XR se čeká na vydání 26.4.1. Nemají ji Arista EOS, Nokia SR OS, Huawei, Extreme SLX-OS, ArcOS, GoBGP ani ExaBGP. Dva z těch záznamů jde ověřit v dokumentaci: FRR i OpenBGPD popisují nastavení role na relaci jmenovitě a MikroTik ji uvádí v poznámkách k RouterOS 7.21 z 12. ledna 2026.

Nasazení má jednu praktickou nepříjemnost: přidání role vyžaduje restart relace BGP, takže se plánuje na servisní okno. Zato pak ochrana proti únikům běží sama, bez ručně psané politiky – a to je celý smysl normy. Čím výš v hierarchii ale sedí síť, která atribut odstraní, tím větší kus té ochrany zmizí; k tomu při dnešní míře nasazení stačí jediná páteřní síť.

Zdroje: Cloudflare: BGP Role model – tracking the adoption of RFC 9234, RFC 9234, RFC 7908, RFC 7606, dokumentace FRR, bgpd.conf v OpenBSD, poznámky k vydání RouterOS 7.21.

Usama Arif poslal 26. srpna 2026 do konference vývojářů linuxového jádra sérii tří záplat nazvanou zstd: probe the CPU for BMI2 support once, not per context. Popis vady se vejde do dvou vět. Knihovna zstd zabudovaná v jádře si mezi obecnou a zrychlenou cestou vybírá za běhu a instrukci CPUID kvůli tomu pouští pokaždé, když se zakládá kontext pro kompresi nebo dekompresi. Odpověď se přitom za chodu systému změnit nemůže.

BMI2 je sada instrukcí pro práci s jednotlivými bity. Intel ji zavedl s architekturou Haswell, AMD ji má od jádra Excavator a novějších. Zstd v ní má napsané rychlejší varianty některých svých funkcí a při každém startu kontextu se ptá, jestli je smí použít.

Kontext se v jádře zakládá po blocích

Detekce za běhu sama o sobě špatná není. Je to způsob, jak nechat starší procesory běžet na obecném kódu. Vadí, že se opakuje.

Arif v průvodním dopise vypisuje, odkud se do zstd chodí: squashfs zakládá dekompresní kontext pro každý blok, který rozbaluje, a erofs, btrfs, f2fs i kryptografické rozhraní jádra si ho pořizují na každou operaci. Jeden dotaz stojí na x86 dvě serializující instrukce CPUID, tedy takové, u kterých procesor nesmí nic přeskládat ani překrýt s okolím.

Tři záplaty, jednadvacet přidaných řádků

První záplata je úklid. Funkce ZSTD_initStaticCCtx() měla dotaz opsaný ručně a ptala se jen na BMI2, zatímco obě zbývající cesty k založení kontextu jdou přes ZSTD_cpuSupportsBmi2(), která vyžaduje i BMI1. Přísnější test je ten správný: těla funkcí, mezi kterými příznak vybírá, nesou značku TARGET_ATTRIBUTE("lzcnt,bmi,bmi2"), takže v nich překladač smí použít i instrukce BMI1 a LZCNT. Žádný prodávaný procesor x86 podle Arifa BMI2 bez BMI1 neumí, takže je to skrytá nesrovnalost, ne pozorovaná chyba.

Druhá záplata míří na sestavení, kde ten příznak nikdo nečte. Když je DYNAMIC_BMI2 nula, tedy u GCC staršího než jedenáctka, u jiné architektury než x86 nebo u překladu, který má BMI2 zapnuté rovnou pro celý kód, rozhodnou se všechny funkce pro výchozí tělo. CPUID se přesto pouštělo a výsledek se zahodil.

Třetí záplata je vlastní změna. Výsledek se uloží do statické proměnné, jejíž záporná počáteční hodnota znamená „ještě jsem se neptal“.

static int supported = -1;
int s = READ_ONCE(supported);

if (s < 0) {
    ZSTD_cpuid_t const cpuid = ZSTD_cpuid();

    s = ZSTD_cpuid_bmi1(cpuid) && ZSTD_cpuid_bmi2(cpuid);
    WRITE_ONCE(supported, s);
}
return s;

Zámek u toho žádný není a Arif vysvětluje proč: dva dotazy, které se potkají, spočítají z téhož listu CPUID tutéž hodnotu, takže nesynchronizovaný přístup nevadí. Makra READ_ONCE a WRITE_ONCE jsou tam kvůli tomu, aby se na té neškodnosti shodl překladač s hlídačem souběhů KCSAN.

Funkce je označená MEM_STATIC, tedy vkládaná dovnitř volajícího, takže vlastní kopii uložené odpovědi dostane každá překladová jednotka: v modulárním sestavení tři, plus po jedné v každém dekompresoru zavaděče. Podle Arifa je to hrstka celých čísel v segmentu bss a jeden dotaz navíc na každou z nich, což se řešit nevyplatí. Celá série sahá na dva soubory, přidává jednadvacet řádků a tři ubírá.

Sedmdesát jedna procent je změřených ve virtuálním stroji

Arif měřil testem nad rozhraním crypto_acomp se čtyřkilobajtovými bloky, a to v hostu KVM s jediným virtuálním procesorem. Dvanáct startů po devíti kolech, každé kolo 30 000 operací, a z těch 108 kol medián průměrů:

Ten propastný rozdíl u dekomprese je z velké části daň za virtualizaci a Arif to sám píše: CPUID vyvolá bezpodmínečný přechod z hosta do hypervizoru. Na holém železe se nic takového neděje, takže tam bude úspora menší. O kolik, série neuvádí; číslo mimo virtuální stroj v ní není ani jedno.

Symptom byl v konferenci vidět už v červenci

Nhat Pham, jeden ze správců zswapu, odpověděl týž den odpoledne. O zstd sám píše, že v něm odborník není, a posouzení správnosti nechává na Nicku Terrellovi a Herbertu Xu, tedy na správcích zstd a kryptografického rozhraní; oba jsou mezi adresáty série. U Terrellovy adresy na doméně fb.com se ptá, jestli ještě funguje.

K tomu připomíná, že se totéž už jednou ohlásilo, a odkazuje na zprávu z 28. července. V ní Jianyue Wu vedle vlastního tématu, návrhu na zmenšení záznamu v zswapu, vypsal tabulku propustnosti. Zstd v ní přes rozhraní acomp zvládl 740 MB/s při ukládání a 980 MB/s při čtení, zatímco přes zcomp to bylo 1 190 a 1 720 MB/s. Wu to uzavřel větou, že to je jiné téma. Příčinu ta tabulka nepojmenovává, ukazuje jen ten rozdíl, a měsíc se k němu nikdo nevrátil.

Záplaty jsou zatím v recenzním kole a v žádné vývojové větvi nejsou. Kdyby prošly, pozná to hlavně to, co má zstd v úzkém místě: obrazy se squashfs, souborové systémy erofs v kontejnerech a odkládání paměti přes zswap. Zbytek jádra si ničeho nevšimne, protože je to jednadvacet řádků, které si pamatují odpověď, jež se nemění.

Zdroje: průvodní dopis série na lore.kernel.org, druhá a třetí záplata, zpráva na Phoronixu a soubor MAINTAINERS pro určení správců.

Když se testuje jazykový model, testuje se obvykle sám. Dostane zadání, odpoví, výsledek se zapíše. Jenže agenti postavení na těchhle modelech se dnes pouštějí do provozu po skupinách a skupina se nechová jako součet svých členů. Práce zveřejněná 18. srpna 2026 v Proceedings of the National Academy of Sciences ukazuje, že o výsledku rozhoduje i něco tak prozaického, jako je počet agentů.

Autoři jsou z City St George's, University of London, z IT University of Copenhagen a z Universitat Politècnica de Catalunya. Prvním autorem je Ariel Flint, posledním Andrea Baronchelli, který se vznikem konvencí zabývá dvě desetiletí. Preprint téže práce leží na arXivu od 25. října 2025.

Hra na jména

Úloha se jmenuje naming game, česky hra na jména, a v teorii konvencí je to standardní nástroj. Ze skupiny se náhodně vyberou dva agenti. Každý napíše jedno slovo z dvojice, kterou mají oba k dispozici. Trefí-li se do stejného, oba dostanou body; když ne, oba o body přijdou. Odměna za shodu je přitom vyšší než pokuta za neshodu.

Agent nevidí nic než svých pár posledních setkání: co napsal on, co napsal protějšek, jestli se trefili a kolik na tom vydělal. Že je v nějaké skupině, mu nikdo neřekne. Přesto se populace po dostatečném počtu kol obvykle sjednotí na jednom slově. Tak vznikají zvyklosti i mezi lidmi, zdola a bez toho, aby je někdo vyhlásil.

Slova nebyla vybraná náhodně. Tým sáhl po dvojicích se společenským nábojem, tedy {man, woman}, {her, his} nebo {straight, gay}; anglická jsou proto, že agenti hráli anglicky, a vybraly se kvůli tomu, že u nich jde zaujatost změřit. Modely byly čtyři: Qwen QwQ-32B, Microsoft Phi-4, OpenAI GPT-4o a Meta Llama 3.1 70B Instruct. V každém běhu byla celá populace postavená z jednoho z nich.

Tři způsoby, jak skupina přebije jednotlivce

Vzájemné potkávání dokáže odvést skupinu od toho, co její členové sami preferují, a autoři rozlišují tři případy.

• Zesílení. Slabý sklon jednotlivého agenta se v populaci vyostří tak, že skupina končí u téhož slova skoro pokaždé. Vyšlo to u dvojice {American, Mexican}.
• Vznik z ničeho. Agenti, kteří sami mezi dvěma slovy nerozlišují, se jako skupina spolehlivě přikloní k jednomu z nich. Tak se chovala dvojice {White, African}.
• Obrácení. Populace se ustálí na slově, které jednotliví agenti volili méně často. To je případ dvojice {straight, gay} u modelu Llama.

Který ze tří případů nastane, závisí na modelu. U dvojice {her, his} skončily populace agentů Qwen a Phi u her, populace GPT a Llama u his, a to přesto, že jednotliví agenti vycházeli ve všech čtyřech případech ze skoro stejných preferencí.

Zlom leží pokaždé jinde

Druhý nález je o velikosti. Čím větší populace, tím předvídatelnější výsledek: nad určitou hranicí se skupina sjednotí na jednom slově prakticky vždy. Kde ta hranice leží, se ale mezi modely a dvojicemi slov liší o řády. U některých kombinací stačí dva agenti, u jiných je to kolem deseti tisíc.

Velikost přitom nemění jen sílu jevu, ale i jeho druh. Agenti Llama sami volili raději straight. Jako populace se překlopili ke gay, ale až od šesti agentů výš. Ve skupině pěti a menší po tom jevu nezůstala ani stopa.

K simulacím tým přidal analytický popis převzatý ze statistické fyziky, takzvané přiblížení středního pole. Nad kritickou velikostí populace se jednotlivé běhy přestanou rozcházet a míří k deterministické předpovědi, ze které je vidět, ke kterému z konkurujících si ustálených stavů skupina spadne.

Milion agentů se doopravdy odehrát nedá

Rozsah od dvou agentů po milion by přímým voláním modelů nešel zaplatit. Tým to obešel jinak: z každého modelu vytáhl pravděpodobnosti, se kterými by při daném stavu paměti napsal to které slovo, předpočítal je pro všechny možné stavy paměti a v simulaci pak agenti losovali podle nich. Shodu s přímými běhy jazykových modelů autoři doložili v doplňkových materiálech. Je to zjednodušení a stojí za to o něm vědět: simulovaná populace není milion skutečně běžících modelů.

Sami autoři drží ještě druhou výhradu. Zaujatost, kterou měří, je vnitřní záležitost té koordinační úlohy, tedy rozchod mezi tím, co chce jednotlivec, a tím, na čem skončí skupina. Není to odklon od lidských hodnot a záměrů. Prostředí je schválně holé, aby v něm byl vidět jen vliv vzájemného potkávání.

Co z toho plyne pro testování

Praktický důsledek je nepříjemný. Model může projít bezpečnostní zkouškou jako jednotlivec a přesto v provozu vedle vlastních kopií vyprodukovat výsledek, který nikdo nezadal. Test jednoho agenta to neukáže.

„Zaujatost byla naše zkušební úloha, protože se dá měřit a protože na ní záleží,“ říká Ariel Flint. „Není ale důvod myslet si, že tajná dohoda, klamání nebo spolupráce jsou vůči vlivu velikosti odolné. Dnešní testovací praxe může přehlížet rizika, která se ukážou jen při určitém počtu agentů. Ne proto, že by někdo byl nedbalý, ale proto, že nikoho nenapadlo tím počtem hýbat.“

„Fyzici na to mají heslo: víc je jiné,“ říká Andrea Baronchelli. „Dopravní zácpu nepochopíte tím, že budete studovat jedno auto, ani město tím, že budete studovat jednu domácnost. U agentů to platí stejně. A hlavně neexistuje jedno číslo, u kterého ta změna nastane. Závisí to na modelu a na tom, o čem se rozhoduje.“ Testovat jedinou velikost skupiny proto podle něj nestačí, projet se musí celý rozsah.

Práce navazuje na starší výsledek téhož týmu, podle kterého si populace agentů umí vytvořit společenskou konvenci samy od sebe. Jako další krok autoři jmenují smíšené populace z různých modelů a agenty zapojené do realističtější sítě vztahů, ne do náhodných dvojic.

Zdroje

• Group size effects and collective misalignment in LLM multi-agent systems, PNAS, 18. srpna 2026
• Preprint téže práce na arXivu, 25. října 2025
• More is different when AI agents work together, study suggests, tisková zpráva City St George's, University of London, 19. srpna 2026

O manifestu i o soudních výzvách jsme psali zvlášť. Tenhle text jde po jednotlivých únicích: co v kterém klipu bylo a jak se z dvou videí za devět dní stala kauza, kvůli které se Rockstar poprvé za týden ozval.

Kdo je CyberLeek

Jméno ani počet lidí za přezdívkou nikdo nezná. Podle Jasona Schreiera z Bloombergu Rockstar ještě 21. srpna nevěděl, kdo za úniky stojí, a rozsah soudních výzev tomu odpovídá. Pár věcí se ale z otevřených zdrojů složit dá.

Evropa, spíš než Amerika. Klipy vycházejí v časech, které odpovídají evropskému dni, a web i jeho dvě zrcadla běžely u německého poskytovatele. K tomu drobnost z jazyka: manifest mluví o „living service“ tam, kde se v oboru běžně říká live service. Podle PC Gameru to může ukazovat na člověka, pro kterého angličtina není první jazyk, nebo na strojový překlad.

Stopa z roku 2018. Na německojazyčném fóru szenebox.org, které má i bezpečnostní sekce, psal před osmi lety uživatel se stejnou přezdívkou. Z toho a z dalších archivovaných materiálů PC Gamer usuzuje na Němce nebo Švýcara po třicítce. Podrobný rozbor těch dokladů sestavil vývojář vystupující jako Zyre na GitHubu.

A tady je detail, který dosud nikdo nespojil: repozitář, na který Take-Two 19. srpna poslalo GitHubu oznámení o porušení autorských práv, se jmenuje zyrexdz/cyberleek-leak-research. Že jde o totéž jméno, nikdo oficiálně nepotvrdil, ale vydavatel podal svůj první podnět proti stránce, která leakera vyšetřovala, ne proti stránce, která šířila jeho videa.

Jak čerstvou verzi má. V jednom klipu hraje v autorádiu skladba vydaná v lednu 2025, takže nejde o letitý build. Zároveň to není nutně finální verze hry – na té Rockstar podle svého vyjádření pořád pracuje.

Proč to podle sebe dělá. Manifest stojí na čtyřech výtkách: vydavatelé prodávají licence a říkají tomu koupě, vydávají nehotové hry a říkají tomu služba, zamykají obsah na disku a prodávají ho jako rozšíření a hry vypínají, ale peníze si nechají. Z toho plynou tři požadavky: vydat hru fyzicky, neprodávat rozšíření, která jen odemykají už dodaný obsah, a nechat obsah pro jednoho hráče přístupný i po vypnutí serverů. Leaker k tomu přidal ultimátum: skončí, až se Rockstar a Take-Two omluví za chování k zákazníkům a dají konkrétní závazek, že se polepší.

Proti tomu stojí peníze. Token existoval dřív než první únik, hlasování o dalším klipu se platí tokenem a kontaktní stránka nabízela reklamu i jednání za poplatek. Autor rozboru na PC Gameru z toho vyvozuje, že manifest nejspíš vznikl až po získání materiálu jako dodatečné odůvodnění a rámec pro token. Stejný text si všímá, že výtka k obsahu zamčenému na disku je téma, které se probíralo před deseti lety, takže spíš než o teenagera půjde o někoho, kdo tehdejší debatu sledoval. Za pravděpodobné nepovažuje ani to, že by šlo o zaměstnance nebo dodavatele Rockstaru. Všechno tohle jsou ale úvahy, ne doklady.

Čím riskuje. Právě token, který mu vydělává, je zároveň stopa: pohyby na blockchainu jsou veřejné a dají se dohledávat, takže vedle serverů a účtů přibyla vyšetřovatelům další cesta. Že v téhle věci nejde o drobnost, ukazuje osud jeho předchůdce z roku 2022. Na straně vydavatele navíc stojí i Microsoft – jeho technický ředitel pro Xbox potvrdil, že firma s Take-Two a Rockstarem spolupracuje.

Jak si hlídá vlastní jméno. Hned druhý den varoval před účty, které se za něj vydávaly na X, Discordu i Instagramu a zpětně si upravovaly starší příspěvky, aby to vypadalo, že úniky předpověděly. Za své jediné oficiální kanály označil vlastní web a Telegram; obojí 22. srpna zmizelo. V jednom telegramovém vzkazu označil Ariona Kurtaje, odsouzeného za únik z roku 2022, za „našeho kolegu“.

Časová osa úniků

1. 18. srpna Dvě videa a mapa. Jason Duval hraje basketbal před domem, v druhém klipu vytáhne řidiče z náklaďáku. Týž den vzniká web s manifestem a token na Solaně. Tom's Hardware
2. 19. srpna Klip s taserem končí krátkou scénou s Calem Hamptonem, takže je jasné, že leaker má i filmové sekvence. Přibývá droga Zombix se slábnoucím účinkem a dva výřezy mapy se souostrovím jižně od Vice City.
3. 20. srpna Let nad Vice City zakončený nápisem LEEK vystříleným do zdi – důkaz, že hru sám spouští. Spouští se hlasování tokenem, letadlo vyhrálo 147 tisíci hlasy. Tom's Hardware
4. 21. srpna Jízda vozem Thrax po devětadvaceti hodinách pauzy. Take-Two podává soudní výzvy na Microsoft a Discord, na webu přibývá placená stránka Kontakt s jednáním za 400 XMR. rozbor příloh
5. 22. srpna Přepadávání benzinek zakončené vstupem do klubu. Soud výzvy schválil, web i telegramový kanál zmizely. Polygon
6. 23. srpna Striptýzový klub a další neviděná scéna. Po sítích začíná kolovat falešný instalátor o velikosti 113 GB, který je z 99,99 % prázdný a nese virus. Tom's Hardware
7. 24. srpna První obrazovka po smrti postavy a noční let nad městem s dosud neznámými rádii. Objevuje se úkol vrátit se k Lucii, takže druhá hlavní postava je v uniklé verzi dostupná. Komunitní projekt, který roky skládá mapu z traileru a screenshotů, potvrzuje, že uniklá mapa sedí s jejich prací.
8. 25. srpna Čtyři klipy za den: naturistická osada, klub NINE1NINE, pláž a obchod s elektronikou, kde stojí vymyšlená konzole JoySystem 8 jako parodie na PlayStation. Mashable
9. 26. srpna Rockstar poprvé za týden promluvil. Krátce nato vyšel patnáctý klip: krádež auta Rideout Customs, útěk před policií a na konci scéna s Lucií. The Verge

Dva dny z té tabulky stojí za rozvedení, protože v nich se případ zlomil.

20. srpna: jméno vystřílené do zdi

Pátý klip je let nad Vice City a dosud nejlepší pohled na měřítko mapy. Rozhodující je ale jeho konec: hráč vystřílí do zdi nápis LEEK. Do té chvíle se dalo věřit, že leaker má jen nahrané záběry. Tohle ukázalo, že hru sám spouští a ovládá.

Týž den se objevilo hlasování o dalším úniku, ve kterém se hlasuje tokenem. Ze čtyř možností vyhrálo letadlo se 147 tisíci tokeny, tedy zhruba 64 %. Celková hodnota tokenu vycházela toho dne na 1,23 milionu dolarů a deset největších peněženek drželo víc než polovinu, takže o ceně rozhoduje hrstka lidí. Akcie Take-Two podle dostupných odhadů ztratily 2,8 miliardy dolarů tržní hodnoty.

26. srpna: Rockstar promluvil

Po týdnu mlčení vydal Rockstar první vyjádření. Píše v něm, že označit únik videí za zdrcující pro tým by bylo slabé slovo a že takhle hru ukázat nechtěli. Následuje omluva za to, jak dlouho všechno trvalo, ujištění, že je hra téměř hotová, a prosba, aby si na ni hráči počkali do 19. listopadu.

Omluva je na Rockstar netypická. Kotaku k tomu poznamenává, že se v dosud uniklém materiálu těžko hledá něco, co by šlo označit za prozrazení děje. Krátce po vyjádření vyšel patnáctý klip.

Co ty záběry o hře prozradily

Když se patnáct klipů poskládá dohromady, vyjde z nich hlavně jedno: hustota. Pláž, klub i naturistická osada jsou plné postav, které se liší postavou, oblečením i pohybem, a okolní svět na hráče reaguje. Vedle toho se ukázalo pár konkrétních věcí – droga se slábnoucím účinkem, obchod s elektronikou, ve kterém jde zboží prohlížet, několik neznámých rozhlasových stanic a podoba obrazovky po smrti postavy.

Z příběhu naopak neuniklo skoro nic. Scény s postavami jsou krátké a jde v nich o přesuny mezi místy, ne o zvraty.

Podruhé za čtyři roky

Rockstar tohle zažívá podruhé. V roce 2022 unikla raná verze hry i s vývojářskými nástroji a stál za tím britský teenager Arion Kurtaj. Soud ho poslal na neurčito do ústavu; letos v létě se ukázalo, že je venku a ve vězení čeká na obnovené řízení nařízené na listopad, tedy na týž měsíc, kdy má hra vyjít.

Rozdíl mezi oběma případy je podstatný. Tehdy šlo o rozpracovanou verzi, na které bylo vidět, že je rozpracovaná. Teď kolují záběry, které se od hotové hry na první pohled neliší, a pocházejí z verze spuštěné na počítači – přestože hra vyjde nejdřív na konzolích a počítačová verze ohlášená není.

Jak to nesou lidé ve studiu

Podle Jasona Schreiera z Bloombergu jsou někteří zaměstnanci Rockstaru naštvaní a otrávení. Po úniku z roku 2022 přistoupili na přísná bezpečnostní opatření včetně konce práce z domova – a únik přišel znovu.

Do toho zapadá spor, o kterém se bude jednat u soudu příští měsíc. Rockstar loni propustil přes třicet lidí kvůli tomu, že pracovní věci probírali v soukromé skupině na Discordu, kterou používali k odborové činnosti; odbory to označily za potlačování odborů, firma za porušení mlčenlivosti. Ty dva případy spolu nic nespojuje a žádný doklad o souvislosti neexistuje – jen je těžké nevidět ten kontrast: propuštění přišlo za soukromý rozhovor, ze kterého neuniklo nic, kdežto tenhle únik jde dál každý den.

Co se čeká dál

Hlasování o dalším úniku běželo i ve středu a leaker v posledních dnech naznačoval záběry s Lucií Caminos. Patnáctý klip ten slib splnil, takže se okruh posunul od projížděk městem k postavám a scénám. Odtud je ke skutečnému prozrazení děje blíž než kdykoli předtím.

Otevřená zůstává i pravost. Materiál nepotvrdil ani Rockstar, ani Take-Two – vyjádření z 26. srpna mluví obecně o uniklých videích, konkrétní klipy neuznává. Nepřímých dokladů je ale dost: komunitní mapa sedí, žádosti o stažení chodí a vydavatel kvůli tomu vede spor u soudu. Proti tomu stojí prostá skutečnost, že přesvědčivé video dnes umí vyrobit i stroj, takže opatrnost není zbytečná.

Co se traduje, ale doložit nedá

Kolem případu koluje tvrzení, že má leaker připravenou pojistku, která při jeho zadržení zveřejní celou hru. Objevilo se přes cizí účet a na kanálech, které skupina označila za své jediné oficiální, nikdy nebylo. Totéž platí pro jména, která se na sítích objevovala jako totožnost leakera; pokaždé šlo o někoho jiného.

Zítra má na Netflixu premiéru rozšířená ukázka a 4. září vyprší lhůta, do které mají Microsoft a Discord vydat vyžádané údaje.

Zdroje

• GTA 6 Timeline – All 15 CyberLeek Gameplay Leaks and Story So Far, TechWiser, průběžně doplňováno
• Rockstar finally responds to ‘heartbreaking’ GTA 6 leaks, The Verge, 26. srpna 2026
• Rockstar Finally Breaks Its Silence Over The GTA 6 Leaks, Kotaku, 26. srpna 2026
• GTA 6 leaks may finally be coming to an end, Polygon, 22. srpna 2026
• Fake GTA VI ISO circulates on the internet a few days after leak, Tom's Hardware, 23. srpna 2026
• Rockstar employees frustrated by GTA 6 leaks, PC Gamer
• GTA 6 leaker from 2022 is out of hospital and awaiting retrial, PC Gamer
• Who is Cyberleek? What we know about the GTA 6 leaker, PC Gamer

Když jsme psali o manifestu skupiny CyberLeek, byly na světě dva klipy a mapa. Za týden se z toho stala právní věc, ve které jde o údaje tisíců lidí, kteří s úniky nemají nic společného.

Co přesně Take-Two žádá

Vydavatel Grand Theft Auto podal u soudu návrhy na vydání podkladů od Microsoftu a Discordu. Podle rozboru, který nad zveřejněnými přílohami udělal server Tom's Hardware, nejde jen o jména. Seznam požadovaných údajů obsahuje identifikátor MachineGuid a identifikátory zařízení u účtu Microsoftu, IP adresu při registraci i při posledním přihlášení, telefonní čísla, propojené účty Googlu a Xboxu a obsah OneDrivu.

Rozhodující je, koho se to týká. Ne jen tří jmenovaných účtů, ale každého účtu, který od 1. června 2026 psal na tři vyjmenované servery nebo byl jejich členem. Jde o Ødyssey.gg, „! Odyssey“ a DarkViperAU. Návrhy podala kancelář Kirkland & Ellis a lhůta pro vydání údajů je 4. září.

MachineGuid stojí za vysvětlení: je to identifikátor instalace Windows, který přežije výměnu hardwaru a mění se až s výměnou systémového disku. Kdo tedy na některý z těch serverů za poslední tři měsíce napsal jedinou zprávu, může se ocitnout v seznamu s údajem, který ho spojuje s konkrétním počítačem napříč účty.

Youtuber DarkViperAU, po jehož serveru je jeden z nich pojmenovaný, se ohradil na síti X: napsal, že nic neví, že jmenovaný server není jeho redakční a že v žádném z jeho serverů ani nejsou klipy z úniků.

Tři nesrovnalosti v podání

Tom's Hardware si přílohy přečetl podrobně a našel v nich tři místa, která nesedí.

Výzva pro Microsoft je adresovaná firmě jako provozovateli GitHubu, ne jako provozovateli Xboxu nebo OneDrivu, přestože právě údaje z Xboxu a OneDrivu požaduje. Podkladem je oznámení o porušení autorských práv, které 19. srpna poslal pracovník Take-Two na adresu GitHubu kvůli jedinému repozitáři.

Druhá věc je datum. Identifikátory Discordu v sobě nesou čas vzniku a u serveru Ødyssey.gg vychází na 19. června 2026, tedy osmnáct dní po začátku období, za které Take-Two údaje chce. Za prvních osmnáct dní toho období ten server ještě neexistoval.

Třetí je rozpor uvnitř samotného podání: totéž číslo je na jednom místě uvedené jako identifikátor uživatele s přezdívkou Surfer24k a na jiném jako identifikátor serveru. Přílohy navíc žádají telemetrii ze zařízení, na kterých byly „určité nástroje nebo soubory“, ale jejich seznam v příloze nikde není.

Web spadl, úniky ne

Právní tlak zabral aspoň zčásti. Ráno 22. srpna si Eurogamer všiml, že web CyberLeeku je nedostupný, a telegramový kanál začal hlásit, že je nedostupný kvůli porušení autorských práv. Rockstar to nekomentoval, ale mlčení má svou logiku: firma se k únikům oficiálně nevyjádřila ani jednou a jedinou její reakcí zůstávají žádosti o stažení obsahu.

Úniky tím ale neskončily. Další záběry vyšly týž den, objevily se stránky, které se za CyberLeek vydávají, a přes víkend přibyly klipy z obchodu s hrami, z nočního klubu a z pláže. Zatím v nich nebyl žádný zásadní příběhový moment.

Z memecoinu se staly placené ankety

Token, o kterém jsme psali minule, se mezitím proměnil v něco jiného než v prostou spekulaci. Skupina spustila ankety, ve kterých se hlasuje tokenem o tom, co unikne příště; podle IGN za hlasování někteří lidé utratili stovky dolarů. Skupina to obhajuje tím, že z tokenu platí provoz a že jinak by v kampani pokračovat nemohla.

Tím se ale mění povaha celé věci. Dokud šlo o protest proti tomu, že hráči kupují jen licenci, dala se aspoň pochopit motivace. Ve chvíli, kdy o dalším úniku rozhoduje, kolik kdo zaplatil, je to platba za obsah, který někdo jiný ukradl. V jedné z anket se navíc mezi možnostmi objevil prolog s jednou z hlavních postav, takže hranice „žádné spoilery“ platí jen do chvíle, než ji hlasující posunou.

Falešný build, který sežere počítač

Kolem úniků se okamžitě objevil běžný doprovod. Po sítích koluje soubor o velikosti 113 GB, který se tváří jako hratelný build hry. Podle rozboru, na který upozornil Tom's Hardware, je z 99,99 % tvořený prázdnými nulami a schovaný je v něm virus o velikosti zhruba 50 kB. Návod k instalaci přitom po uživateli chce, aby si přidal výjimku pro celý systémový disk do Defenderu a ukončil bezpečnostní software.

To je poznávací znamení, které stojí za zapamatování mimo tenhle případ: návod, který po vás chce vypnout antivirus, je návod k nakažení. Legitimní software to nepotřebuje.

Co se traduje, ale doložit se nedá

Kolem případu vzniklo množství tvrzení, která se šíří rychleji než ověřené informace. Tři nejčastější stojí za oddělení.

První je pojistka pro případ zatčení – že prý má leaker na počítači mechanismus, který při jeho zadržení zveřejní celou hru. Tahle zpráva se objevila přes cizí účet a na webu ani na telegramovém kanálu, které skupina uváděla jako své jediné oficiální kanály, nikdy nebyla.

Druhá je německá stopa, postavená na shodě přezdívky s účtem na německém bezpečnostním fóru z roku 2018. Opírá se o běžné německé slovo znamenající „představení se“, což je pro identifikaci slabý doklad.

Třetí je identita samotného leakera. Po sítích kolovaly příspěvky s tisíci lajků, které jmenovaly pokaždé někoho jiného. Kdo CyberLeek je, se zatím neví – a podle rozsahu soudních výzev to zjevně neví ani Take-Two.

Spor o propouštění, který do toho zapadá

Jedna z teorií mluví o pomstě bývalého zaměstnance a opírá se o doložený spor. Rockstar loni na konci října propustil 31 lidí. Odborová organizace IWGB kvůli tomu podala v listopadu žalobu a mluví o potlačování odborů; Rockstar to odmítá s tím, že propuštění šířili důvěrné informace a že „důvěrnost je pro Rockstar zásadní“. Přes dvě stě lidí z Rockstar North podepsalo dopis za jejich návrat, konaly se protesty v Londýně a Edinburghu a věc se dostala až do parlamentu.

Spojnice mezi tím sporem a úniky je ale zatím jen domněnka. Doložené je, že spor existuje, ne že z něj úniky vzešly.

Ve čtvrtek se ukáže, co Rockstar chtěl ukázat sám

Celá věc má tvrdý termín. Ve čtvrtek 27. srpna má na Netflixu premiéru rozšířená ukázka Grand Theft Auto VI: An Extended Look. Právě ta smlouva Rockstaru svazuje ruce: kdyby ukázku vydal sám a dřív, vzal by únikům přitažlivost, jenže exkluzivita mu to nedovoluje.

Hra samotná má vyjít 19. listopadu 2026 po několika odkladech, a to nejdřív na konzolích; verze pro počítače ohlášená není. Právě to dělá z úniků pikantnost – záběry, které kolují, pocházejí z buildu spuštěného na počítači.

Ať už ve čtvrtek padne cokoli, jedna část případu zůstane otevřená bez ohledu na to, jestli leakera někdo najde: 4. září vyprší lhůta a ukáže se, kolik údajů o lidech, kteří jen četli cizí příspěvky, nakonec změní majitele.

Zdroje

• GTA 6 leaks prompt Take-Two to subpoena Microsoft for Windows device IDs of everyone in three Discord servers, Tom's Hardware
• GTA 6 leaks may finally be coming to an end, Polygon, 22. srpna 2026
• Fake GTA VI ISO circulates on the internet a few days after leak, Tom's Hardware, 23. srpna 2026
• Catastrophic GTA VI leak is a full working build, Tom's Hardware
• Úniky GTA 6 pokračují, leaker obhajuje kryptoměnu, IGN
• Union requests interim relief for employees affected by Rockstar layoffs, GamesIndustry.biz
• Grand Theft Auto VI is now set to launch November 19, 2026, Rockstar Games

Nízké Slunce dělá stín i za malým hrbolem

U pólu se povrch chová jinak. Osa Měsíce je skloněná málo, takže Slunce tam visí těsně nad obzorem a svítí skoro vodorovně, jako svítilna položená na stole. Každý val kráteru, každý hřeben i pár decimetrů vysoký hrbol proto vrhá dlouhý stín. V něm se drží nízká teplota a nedopadá do něj přímé ultrafialové světlo; v trvale zastíněných kráterech vydrží i vodní led.

Tým Prabala Saxeny z Goddardova střediska NASA popsal ten terén daty z družice Lunar Reconnaissance Orbiter: teplotami z přístroje Diviner v rozlišení 240 metrů, mapami osvětlení odvozenými z výškopisu LOLA v rozlišení 60 metrů a u tří kandidátských ploch pro přistání mise Artemis III ještě jemnějším výpočtem, ve kterém se sluneční paprsky sledují nad terénem s pixelem pět metrů.

Pět rodů, které posádka nejspíš doveze

Do srovnání šly tři rody bakterií a dva rody hub. Bacillus, Staphylococcus, Aspergillus a Fusarium se běžně vyskytují na lidské kůži nebo v kabinách kosmických lodí. Deinococcus radiodurans je proti nim extremofil a autoři ho vzali kvůli jeho odolnosti proti záření a proto, že se dá vypěstovat i z čistých prostor, kde NASA sondy sestavuje.

Pro každý rod pak z dřívějších pokusů vytáhli dvě čísla: nejvyšší teplotu, při které rod v suchém prostředí ještě roste, a dávku ultrafialového záření, po níž počet životaschopných buněk klesne o šest řádů.

Kelviny na stupně Celsia přepočítáváme my, práce je uvádí jen v kelvinech. Denní úhrn přímého ultrafialového záření se u pólu pohybuje od zhruba jednoho megajoulu na metr čtvereční v nejosvětlenějších místech po nulu na dně trvale zastíněných kráterů. I nejodolnější z pětice proto potřebuje kout, kam dopadne řádově méně světla než na osvětlený hřeben.

Kolik plochy z toho vyjde

Model počítá podíl povrchu, na kterém daný rod přečká aspoň jeden pozemský den. Pro jaro a podzim vycházejí u tří kandidátských ploch tahle čísla:

Roční doba hýbe výsledkem víc než volba místa. V zimě stoupne podíl u Connecting Ridge pro Aspergillus na 30,26 %, v létě spadne u De Gerlache Rim na 2,75 %. Ve všech třech oblastech přitom zbývají zhruba tři procenta plochy, kde by Aspergillus vydržel aspoň sedm dní.

Zvlášť autoři spočítali dno trvale zastíněného kráteru De Gerlache, kam přímé světlo nedopadá vůbec a model do něj pouští jen světlo rozptýlené. Tam vychází pro Aspergillus 40,19 % plochy na jaře a na podzim a 49,12 % v zimě, kdežto Bacillus a Staphylococcus jsou na nule nebo těsně nad ní.

Přežít není totéž co růst

Tady se dá práce snadno přečíst špatně. Přežitím se v ní myslí, že buňka zůstane naživu v klidovém stavu, jako spora nebo perzistentní buňka, která se probere, až se podmínky změní. Množení je něco jiného a potřebuje kapalnou vodu; k té je potřeba atmosféra a mírné teploty, a nic z toho Měsíc podle autorů nemá.

Svůj důvod má i ta lhůta jednoho dne. Je delší než nejdelší pauza, která na Měsíci uplynula mezi dvěma výstupy posádky ven z lodi. Co vydrží den, může tedy zasáhnout do vzorku, který si posádka odebere při dalším výstupu.

Autoři sami píšou, že pětice rodů je malý výsek z toho, co se na povrch může dostat, a že mezi vynechanými můžou být mikrobi na polární podmínky přizpůsobení ještě líp. Model také nepokrývá všechny stinné oblasti; některé z výpočtu vypadly, přestože dostávají méně záření a jsou chladnější než ty započítané.

Proč to vadí

Jižní pól je zajímavý právě tím, co se v jeho stínech drží: vodní led a organické molekuly, ze kterých se dá číst chemie rané sluneční soustavy. Kontaminace z bot, skafandrů a obytného modulu ten záznam zašpiní a odlišit pozdější příměs od původní chemie pak může být těžké.

„Potřebujeme rozumět tomu, co tam bylo před námi, protože až poletíme na Mars hledat stopy života mimo naši planetu, budeme si chtít být jistí, že to není něco, co jsme si přivezli,“ říká v tiskové zprávě NASA spoluautor Andrew Needham, který má na starosti ochranu měsíčních vzorků před kontaminací. Překlad citace je náš.

Sterilizovat posádku nejde. Robotické sondy NASA často vypéká při teplotách nad 400 stupňů Fahrenheita, tedy zhruba 204 °C, a na každém kousku kůže velikosti gumy na tužce nosí člověk v průměru milion bakterií. Ty z obleků a obytných modulů unikají ven.

Z nouze pokus

Varováním to ale nekončí. Měsíc je podle autorů zároveň laboratoř, jakou na Zemi nepostavíme: dá se v ní zkoušet, kde jsou skutečné meze přežití mikrobů, pokud se přílet posádek zaznamená a sleduje od začátku. Podmínkou je odebrat výchozí vzorky dřív, než na to místo někdo stoupne.

Práce vyšla 19. srpna 2026 v Science Advances, od 25. srpna je volně přístupný i předtisk na arXivu. Autoři v ní píšou, že jejich závěr opravuje rozšířený názor, který dosud ovlivňoval pravidla ochrany jiných těles před zavlečením pozemského života. Souhrn pro veřejnost vydala NASA 19. srpna.

Kritický stav bez jediného wattu

Reaktor je kritický ve chvíli, kdy se štěpná reakce udrží sama sebou: každé rozštěpené jádro uvolní právě tolik neutronů, aby vzniklo další štěpení. S výkonem to nesouvisí. Kritické sestavy v NCERC jedou pod jedním wattem, zatímco energetický blok pracuje na tisících megawattů.

Zkouška při nulovém výkonu proto nevyrobí ani teplo, ani elektřinu a žádná kapalina z jádra teplo neodvádí. Má jiný smysl. Fyzici při ní měří, jak se neutrony v konkrétní sestavě paliva a moderátoru opravdu chovají, a porovnávají to s tím, co jim předpověděl výpočet. Startup Valar Atomics, který stejnou zkouškou prošel v NCERC v listopadu 2025, ji popsal jako ověření předpokladů o palivu, moderátoru, regulaci reaktivity a vyhořívajících absorbátorech. Westinghouse mluví o potvrzení modelů a návrhových předpokladů aktivní zóny.

NCERC sídlí v objektu Device Assembly Facility a provozuje ho laboratoř v Los Alamos, která sem přestěhovala svoje starší pracoviště kritických experimentů z Nového Mexika. Drží čtyři kritické sestavy se jmény Godiva, Flattop, Planet a Comet a podle vlastního popisu je to jediné víceúčelové zařízení pro kritické experimenty ve Spojených státech.

Teplo odvádějí trubice, ne čerpadla

eVinci se od běžného reaktoru liší v tom, jak se zbavuje tepla. Nemá chladicí okruh ani čerpadla: v aktivní zóně jsou podle ministerstva energetiky stovky tepelných trubic ze slitiny železa, chromu a hliníku, které teplo odvádějí samy. Voda v konstrukci není vůbec, takže odpadá havárie se ztrátou chladiva.

Palivo je typu TRISO, tedy kuličky, kde je štěpný materiál uzavřený v několika keramických vrstvách. Aktivní zóna je grafitová a reaktivitu řídí otočné bubny. Westinghouse slibuje osm let provozu bez výměny paliva a reaktor smontovaný v továrně, který se na místo doveze v kontejneru. Jako cílové použití firma jmenuje odlehlá místa, obranu a kosmonautiku.

Elektrický výkon uvádí výrobce až 5 MW, tepelný výkon jádra 15 MW. Americký úřad pro jadernou bezpečnost NRC, u kterého je návrh zatím jen v předlicenčním jednání pod spisem 99902079, popisuje eVinci šířeji jako design od 200 kW do 5 MW elektrických.

Co přijde po nulovém výkonu

Zkoušky s palivem a skutečným výkonem čekají eVinci až jinde: v komoře DOME v Idaho National Laboratory. Je to přestavěná kontejnmentová budova bývalého množivého reaktoru EBR-II a americké ministerstvo energetiky ji vyhradilo pro experimentální reaktory do 20 MW tepelných. Vybrané jsou tam tři stroje, vedle eVinci ještě Kaleidos od firmy Radiant a R1 od firmy Antares.

Jak dlouhá cesta to je, ukazuje plán Radiantu. Ten svůj reaktor poslal 12. srpna 2026 z Kalifornie do Idaha na návěsu, přes 1 600 kilometrů po silnici, a v DOME ho čeká pět fází. První je právě kritický stav při nulovém výkonu; poslední je 150 hodin nepřetržitého běhu na plný výkon bez zásahu obsluhy. Teprve ta poslední fáze má podle firmy doložit, že je stroj hotový na prodej.

Mezi kritickým stavem v laboratoři a elektřinou v síti je tedy pořád velký kus práce. Kolik ho je, dobře ukazuje srovnání s velkou energetikou: čtvrtý blok slovenských Mochovců poprvé udržel štěpnou reakci letos v srpnu po víc než třiceti letech od zahájení stavby.

Zdroje: tisková zpráva Westinghouse, World Nuclear News, popis NCERC na stránkách Nevada National Security Site, stránka NCERC v Los Alamos National Laboratory, přehled experimentů v DOME od ministerstva energetiky a předlicenční spis eVinci u NRC.

Tři jména pro tři různé návrhy jádra

Ještě loni měl Apple jádra dvojí. V tiskové zprávě k čipu M5 z října 2025 stálo, že procesor má až deset jader: šest úsporných a až čtyři výkonná. Třetí druh přibyl 3. března 2026 spolu s čipy M5 Pro a M5 Max. Apple v nich představil super jádra a vedle nich úplně nově navržená výkonná jádra, popsaná jako úspornější řešení pro vícevláknovou zátěž. Úsporná jádra z obou čipů zmizela úplně, sestava je šest super a dvanáct výkonných.

Se super jádry přišlo i přejmenování zpětně. Na stránce s technickými údaji iPadu Pro dnes Apple popisuje týž čip M5 jako desetijádrový procesor se čtyřmi super jádry a šesti úspornými. Je to stejný křemík, který loňská tisková zpráva označila za čtyři výkonná jádra; slovo „výkonné jádro“ se tím uvolnilo pro nový návrh.

M6 je první čip řady M, u kterého stojí všechny tři druhy vedle sebe. Sám to tak Apple nikde neoznačuje, plyne to z parametrů, které u jednotlivých čipů uvádí. Práci mezi ně rozděluje takhle: super jádra ženou jednovláknovou zátěž, výkonná spotřebují méně energie a přidávají se k nim u vícevláknových úloh, úsporná obstarávají běh na pozadí.

Co M6 přinesl kromě jader

Dvanáctijádrová grafika má v každém jádru vlastní neuronový akcelerátor a špičkový výpočetní výkon pro strojové učení stoupl proti M5 zhruba o 30 procent. Neuronový engine je nově dvojitý, šestnáct jader v každé polovině, a systémové frameworky umějí zaměstnat obě naráz. Propustnost sdílené paměti povyrostla ze 153 na 170 GB/s, tedy o desetinu. Rychlost geometrie v grafice Apple udává o polovinu vyšší.

Sdílené paměti je ale pořád nejvýš 32 GB, stejně jako u M5. Na čip, který firma prodává větou o jazykových modelech běžících přímo v počítači, je to strop, který o výběru modelu rozhodne dřív než počet jader. A všechna čísla výš jsou hodnoty „až“, naměřené Applem na předprodukčních strojích; nezávislé měření zatím není.

Dvounanometrový postup je u Applu nový, jinde v oboru ale běžný krok. Vlastní čip pro předzpracování dat ze senzorů, který v srpnu představilo Waymo, vzniká pětinanometrovým postupem.

M5 Ultra drží pohromadě čtyři destičky

Druhý čip jde jinou cestou. M5 Ultra vzniká tak, že propojka UltraFusion spojí dva čipy M5 Max, z nichž každý je sám o sobě složený ze dvou křemíkových destiček. Výsledek má čtyři destičky a navenek se chová jako jeden procesor; v řadě M je to podle Applu poprvé. Propustnost mezi destičkami je přes 4,4 TB/s a hustota propojení podle firmy vzrostla víc než šestkrát.

Parametry odpovídají: až 36 jader procesoru (dvanáct super a čtyřiadvacet výkonných), až 80 jader grafiky, dvaatřicetijádrový neuronový engine, až 512 GB sdílené paměti a propustnost 1,2 TB/s. Apple to porovnává s M3 Ultra, ne s M4 Ultra – ten podle serveru The Verge nikdy nevznikl. Proti M3 Ultra je propustnost paměti o polovinu vyšší a grafika až o 40 procent rychlejší.

Mac Studio se navíc dá spojovat do svazku. Přes Thunderbolt 5 a přímý přístup do paměti po síti sdílí několik počítačů jednu velkou paměť; čtyři kusy zvládnou podle Applu odvozování až třikrát rychleji než jeden.

Ceny a termíny

Mac mini s M6 stojí v USA od 899 dolarů, verze s M5 Pro od 1 699. Obě jsou o sto dolarů dražší než poslední ceny generace M4. Základní sestava zůstává na 16 GB paměti a 256 GB úložiště.

Mac Studio začíná na 2 499 dolarech s M5 Max, s M5 Ultra na 5 499 dolarech; loňské M3 Ultra startovalo na 3 999. Předobjednávky běží od 25. srpna, k zákazníkům oba počítače dorazí 22. září, Mac mini ve třiceti zemích. Sestavu Mac Studia s 512 GB paměti Apple slibuje až na konec října a cenu k ní zatím neuvedl. České ceny v tiskových zprávách nejsou.

Číslo v názvu čipu tím přestalo říkat, co je novější. V jednom ceníku Mac mini stojí vedle sebe M6 a o osm set dolarů dražší M5 Pro z března, zatímco nejdražší stolní Mac má na štítku pětku. Který z těch čipů bude pro konkrétní práci rychlejší, se z názvu poznat nedá.

Zdroje

• Apple introduces M6 and M5 Ultra for a big leap in performance and AI compute – tisková zpráva Applu, 25. srpna 2026
• Apple introduces new Mac Studio with M5 Max and M5 Ultra – tisková zpráva Applu, 25. srpna 2026
• Apple unveils a more powerful Mac mini featuring the all-new M6 and M5 Pro – tisková zpráva Applu, 25. srpna 2026
• Apple introduces MacBook Pro with all-new M5 Pro and M5 Max – tisková zpráva Applu, 3. března 2026
• Apple unleashes M5, the next big leap in AI performance for Apple silicon – tisková zpráva Applu, říjen 2025
• iPad Pro – Technical Specifications – parametry čipu M5 na stránkách Applu
• Apple launches new Mac Studios with its ‚most powerful chip ever' – The Verge, 25. srpna 2026
• Apple's new Mac Mini has fresh M6 and M5 Pro chip offerings – The Verge, 25. srpna 2026

Kancelář pro vyšetřování závad ODI, která spadá pod americký úřad pro bezpečnost silničního provozu NHTSA, otevřela 20. srpna spis EA26005. Předmět je v něm popsaný jako ztráta pohonu kvůli selhání motoru po opravě ze svolávací akce. Týká se 997 743 vozů General Motors modelových let 2021 až 2026, které mají pod kapotou atmosférický benzinový osmiválec o objemu 6,2 litru s továrním označením L87.

Šest tisíc stížností na opravené motory

Do spisu se sešly dvě různé hromádky. První je 499 stížností na motory, které selhaly až po dokončení opravy: 473 z nich dostalo hustší olej, dalších 26 celý nový motor. Druhá hromádka je 191 hlášení o motorech vyrobených po období, na které se svolávací akce vůbec nevztahovala. Automobilka sama podle spisu eviduje 6 953 stížností na selhání po opravě. Když se odečtou případy, které majitel nahlásil úřadu i výrobci, zbývá 6 050 vozů.

Jeden případ skončil nehodou nebo požárem, jeden zraněním, mrtvého úřad neeviduje. Všechna ta čísla jsou tvrzení majitelů, ne potvrzené závady. ODI je v téhle fázi jen sbírá.

Usazeniny na ojnicích a klikový hřídel mimo předpis

Celý řetěz začal 16. ledna 2025, kdy GM po oznámení od NHTSA otevřel vlastní produktové šetření. Tři starší šetření téhož jevu přitom sám uzavřel – v únoru 2022, v červnu 2023 a v červenci 2024 –, pokaždé na základě tehdy dostupných údajů z provozu.

Rozbor v roce 2025 vyšel jinak. Automobilka ohraničila podezřelé období výroby od 1. března 2021 do 31. května 2024 a po rozebrání motorů z provozu a proměření nových klikových hřídelí popsala dvě příčiny. Tou první jsou usazeniny na ojnicích a v olejových kanálech klikového hřídele, které poškodí ojniční ložiska. Tou druhou jsou klikové hřídele s rozměry a povrchovou úpravou mimo předpis. Obojí končí poškozeným ložiskem, ztrátou pohonu a zadřeným motorem.

Rozsah byl tehdy tenhle: 28 102 stížností a incidentů ve Spojených státech mezi 29. dubnem 2021 a 3. únorem 2025, z toho 14 332 se ztrátou pohonu. K tomu dvanáct nehod, dvanáct zranění a 42 hlášených požárů. Rozhodnutí svolat vozy padlo 17. dubna 2025.

Kdo prošel prohlídkou, dostal hustší olej

Svolávací akce 25V-274 nepředepsala jednu opravu, ale rozcestí. Servis motor prohlédl a podle nálezu ho opravil nebo vyměnil; vozy, které prohlídkou prošly, dostaly olej s vyšší viskozitou, nové víčko plnicího otvoru, nový olejový filtr a vložku do návodu. Podíl vozů se závadou GM tehdy odhadl na tři procenta. Server GM Authority uvádí, že se v praxi přechází z oleje 0W-20 na 0W-40.

Hustší olej udrží mezi čepem hřídele a ložiskem silnější mazací film. Usazeniny ani špatně obrobený povrch z motoru neodstraní. V hlášeních, která teď ODI má, je selhání po téhle větvi opravy osmnáctkrát víc než po výměně celého motoru – i když těch výměn bylo z podstaty věci mnohem míň.

Oprava, po které závada zůstane, není v americké evidenci nic výjimečného. Kia letos svolávala vozy Telluride podruhé a mezi možnými příčinami uvedla i špatně provedenou opravu z akce z roku 2024.

Mimo období, na které se svolávačka vztahovala

Nejzávažnější věta nového spisu je jedna jediná: ODI rozšiřuje záběr i na motory vyrobené po období uvedeném ve svolávací akci. Proti vysvětlení, že za selháními stojí přechodné potíže u dodavatele mezi březnem 2021 a květnem 2024, tak stojí 191 hlášení o motorech, které vznikly později. Horní hranice se posunula z ročníku 2024 na 2026 a počet vozů z necelých šesti set tisíc na 997 743.

V počtu svolaných vozů se prameny liší. Hlášení GM podle části 573 uvádí 597 630 kusů, databáze NHTSA i starší spis RQ26001 pracují s 597 571. Rozdíl padesáti devíti vozů žádný z těch dokumentů nevysvětluje.

Druhý stupeň řízení

Technická analýza je v americké praxi vyšší patro než předběžné posouzení: to má problém rychle roztřídit, kdežto analýza má určit povahu a rozsah závady. Spis EA26005 vyrostl z řízení RQ26001, které úřad otevřel 16. ledna 2026 na základě šestatřiceti dotazníků od majitelů a které mělo posoudit, jestli je oprava dostatečná. Za sedm měsíců z těch šestatřiceti hlášení bylo 690.

Stanovisko General Motors v dokumentu není; spis o otevření řízení ho neobsahuje. Úřad také neuvádí, kdy chce být hotov. Analýza se může uzavřít bez nálezu, nebo skončit žádostí o další svolávací akci.

Zdroje

• ODI Resume EA26005, NHTSA, 20. srpna 2026
• ODI Resume RQ26001, NHTSA, 16. ledna 2026
• Part 573 Safety Recall Report 25V-274, General Motors, duben 2025
• GM 6.2L L87 Engine Post-Recall Failures Piling Up, GM Authority, 21. srpna 2026
• More Than 28,000 V8s Allegedly Failed Before GM Recalled Its L87 Engines, The Autopian, 21. srpna 2026

Šifruje se soubor po souboru, ne celý oddíl

eCryptfs není šifrování disku. Je to takzvaný stacked filesystem: leží nad běžným souborovým systémem a ke každému otevřenému souboru drží dvojici. Dole je šifrovaný soubor, který se opravdu zapisuje na disk, nahoře je čitelný obsah, jaký vidí program. Klíče jsou dva, jeden na obsah a druhý na jména souborů, a hlavička spodního souboru nese metadata o tom, jak se má obsah odemknout.

Právě proto se s eCryptfs počítalo tam, kde je potřeba oddělit uživatele na společném úložišti. Návrhová dokumentace Chromium OS popisuje uložení dat každého účtu do vlastního trezoru, který se při přihlášení připojí přes eCryptfs. Ubuntu na něm postavilo šifrování domovského adresáře a balík ecryptfs-utils je v repozitáři dodnes, včetně vydání 26.04 LTS.

Klíč se vejde do 64 bajtů, dešifrovalo se jich až 512

Nejvážnější položka balíku má jediný nový test na deset řádků. Hlavička spodního souboru obsahuje paket typu Tag 3 a v něm údaj o délce zašifrovaného klíče. Parser tu délku porovnával se stropem 512 bajtů, jenže funkce, která klíč vzápětí dešifruje, zapisuje výsledek do pole dlouhého 64 bajtů. Autor opravy, který v jádře vystupuje pod jménem HanQuan, popisuje v komentáři k záplatě dva zápisy za koncem: šifra přeteče do okolní struktury a následné kopírování klíče přepíše inicializační vektor, seznam podpisů klíčů a zámky.

Podvržený soubor se musí otevřít. Víc není potřeba a stačí k tomu běžný účet. Podmínkou je AES-192; ta šifra si nastavuje délku klíče na 24 bajtů nezávisle na údaji z hlavičky, takže kontrola v kryptografické vrstvě projde, i když je deklarovaná délka mimo rozsah. Hicks k opravě doplnil, že cesta pro klíče z certifikátů tutéž kontrolu měla už dřív; chyběla jen tam, kde se klíč odemyká heslem.

Chybu nahlásily dvě strany nezávisle na sobě

Deset dní poté, co HanQuan záplatu poslal, dorazila do konference druhá oprava téže chyby. Jay Vadayath k ní přiložil výpis z KASAN, tedy z nástroje, kterým jádro hlídá zápisy mimo přidělenou paměť, a napsal, že chybu našla triážní linka firmy Artiphishell. Ta firma vyrostla z týmu Shellphish, který pod stejným jménem soutěžil ve finále AI Cyber Challenge agentury DARPA. Nástroj podle Vadayathe nezůstal u nálezu a vyrobil program, který ten výpis spolehlivě vyvolá na neopraveném jádře.

Samotnou záplatu psal jazykový model. Vadayath ji označil hlavičkou Assisted-by: Claude:claude-opus-4-7 a v průvodním textu to napsal ještě jednou otevřeně. Hicks mu poděkoval a odmítl: chybu už měl nahlášenou a do větve pustil HanQuanovu verzi, protože ta ořezává délku dřív, přímo v parseru. Do jádra tak z toho běhu doputovala reprodukce a potvrzení, ne kód. Kolik takových hlášení stojí za sadami záplat jinde, ukázala rekordní červencová sada Microsoftu.

Zbytek míří na parser a na rouru k démonu

Sedm z jedenácti oprav napsal Yichong Chen. Tři z nich tvoří jednu sérii a řeší, že funkce na čtení paketů si počítala zbývající místo v hlavičce z konstanty PAGE_SIZE mínus osm bajtů. U hlaviček verze 1 začíná sada paketů dál, takže si funkce myslela, že má víc místa, než dostala. Nově dostane skutečnou délku od volajícího a po každém přečteném paketu si ji přepočítá. Dvě ze tří záplat série odkazují právě na commit z roku 2006.

Druhá skupina míří na rouru mezi jádrem a pomocným procesem v uživatelském prostoru, přes kterou se předávají klíče. Pengpeng Hou z čínské akademie věd našel, že zápis do toho zařízení vždycky kopíruje dva bajty délky, i když zpráva nese jen jeden – u šestibajtové zprávy tedy jádro přečte bajt za koncem uživatelské paměti. Dvě další záplaty téže oblasti drží zámek při úklidu fronty a uvolňují kontext zprávy, když se odeslání nepovede.

Zbývající tři položky bezpečnost neřeší: výpis voleb pro šifrování jmen souborů ve výpisu připojených svazků, přechod na filemap_dirty_folio() a vypuštění jedné zbytečné alokace při zápisu velikosti souboru. Hicks u celého balíku uvádí, že prošel stromem linux-next a testy z projektu ecryptfs-utils, jenže opravy roury k démonu si musel ověřit ručně: na tuhle část kódu žádné testy nejsou.

Že se v dlouho zavedeném kódu najde chyba, která tam byla od začátku, není v jádře nic mimořádného – letos v srpnu tudy prošel i šest let starý únik z virtuálního stroje ve vrstvě KVM. Zvláštní na eCryptfs je poměr: jedenáct záplat na součást, ke které za posledních deset let skoro nikdo nesáhl, a osm z nich putuje i do starších řad.

Redox je mikrojaderný operační systém psaný od nuly v Rustu, tedy podobná stavba jako LiberSystem. Plánovač vznikl v rámci Redox Summer of Code, obdoby Googlem pořádaného Summer of Code, kterou si projekt dělá sám. Krátké oznámení, že je EEVDF v jádře, vyšlo 30. května 2026, čísla ale přišla až po optimalizacích.

Lag a uzávěrka místo pořadníku

EEVDF si u každé úlohy vede dvě čísla. První je lag: rozdíl mezi časem, který úloze podle jejího podílu náležel, a časem, který opravdu dostala. Kdo je pozadu, má lag kladný a smí běžet; kdo si vzal víc, chvíli počká. Druhé číslo je virtuální uzávěrka. Bere se okamžik, kdy se úloha stane způsobilou, a přičte se k němu základní čekací doba dělená váhou úlohy, takže čím vyšší priorita, tím kratší uzávěrka.

Vlastní pravidlo se pak vejde do jedné věty: běží ta ze způsobilých úloh, která má nejbližší uzávěrku. Přesně to popisuje zkratka EEVDF, tedy Earliest Eligible Virtual Deadline First. Algoritmus pochází z práce Iona Stoicy a Husseina Abdel-Wahaba z roku 1995 a Linux ho převzal v jádře 6.6 náhradou za CFS.

Předchůdce v Redoxu, Deficit Weighted Round Robin, uměl dát víc času tomu, kdo má vyšší prioritu, ale neuměl ohlídat, že se dostane i na ostatní. Gaur to v textu popisuje na baru, kde obsluha nalévá VIP hostům tak pilně, že zbytek sálu zůstane suchý. Tomu se v plánovačích říká hladovění a Redox ho měl v tak silné podobě, že se na něm rozbilo i měření priorit: poměr mezi úlohou s prioritou -10 a +10 vycházel 1,4násobný proti teoretickým 86,8. S EEVDF vyšel 76,87, tedy zhruba 89 procent teoretické hodnoty.

Fronta běhu se rozpadla na jádra

Výměna algoritmu byla jen část práce a podle vlastního rozboru autora ne ta, které patří většina zrychlení. Seznam připravených úloh byl v Redoxu jedna globální struktura, takže dvě jádra nemohla přepnout kontext naráz a čekala na zámek. Teď má vlastní frontu každé jádro, a protože se tím může stát, že jedno jádro nemá co dělat a druhé je zahlcené, přibylo k tomu přebírání úloh z cizí fronty. Spustí se, když je místní fronta prázdná, nebo v pravidelném intervalu, pokud je rozdíl v počtu úloh proti jinému jádru dost velký; úlohy se pak berou obden, tedy první, třetí, pátá, a jejich virtuální čas se přepočte na hodiny nového jádra.

Uvnitř fronty vystřídal jednoduchý seznam typ BTreeMap. Klíč tvoří trojice virtuální uzávěrka, zbytek přiděleného úseku a číslo kontextu, takže se při shodě uzávěrek dostane na řadu úloha, která už rozdělaný úsek má. V hodnotách leží kromě odkazu na kontext i jeho virtuální čas a váha, a to schválně duplicitně: díky tomu se způsobilost dá ověřit bez zamykání. Původní práce z roku 1995 pro tenhle účel popisuje rozšířený strom. Gaur ho nepoužil a v textu vysvětluje proč: standardní BTreeMap je odladěný, vlastní strom by přinesl vlastní chyby a náskok by měl jen v nejhorším případě, kdy není způsobilá skoro žádná úloha.

Zmizel i lineární průchod spícími úlohami. Časovače se přesunuly do BTreeSet, ze kterého jde vytáhnout vše, co má vypršet teď. U ostatních zařizuje zařazení do fronty rovnou ten kód, který úlohu odblokuje, takže z průchodu celým seznamem zbyla jedna operace. A aby si úloha nemohla lag ohýbat tím, že se úseku vzdá dřív, dostane při předčasném vzdání penalizaci nepřímo úměrnou své váze.

Co ukázalo měření

Rovnoměrnost dělení času měřil Gaur šestnácti stejnými procesy, které nedělají nic než zvyšují čítač. Na jednom jádru se s DWRR lišily o 1 940,52 procenta, s EEVDF o 2,48 procenta. Z těchto dvou čísel plyne 782násobné zlepšení, které projekt uvádí v souhrnu. Na čtyřech jádrech byl rozptyl 389 až 617 procent proti 1,09 až 1,37 procenta.

Nejvíc si polepšila zátěž s mnoha spícími vlákny. Deset tisíc spících procesů a dva procesy, které si posílají zprávy a nutí tím přepnout kontext, zvládly na čtyřech jádrech 765 obrátek za sekundu se starým plánovačem a 109 386 s novým. Autor u toho sám píše, že zásluhu má z velké části odstranění lineárního průchodu, ne samotná matematika EEVDF.

Číslo, které převzaly zpravodajské servery, je 2,6násobná propustnost. Pochází z třicetisekundového testu se dvěma vlákny na zprávy a dvěma pracovními vlákny na jednom jádru: 123,50 operace za sekundu proti 323,50. Ve stejném měření klesl medián čekání na probuzení ze 4,48 sekundy na 1,54 sekundy.

Dobrovolné přepnutí kontextu spadlo z 2 µs na 350 ns, což je zmiňovaných 82 procent. U blokujícího přepnutí vypadá tabulka takhle:

Kde zpráva sama couvá

Srovnání s Linuxem v té tabulce označuje Gaur za nesouměřitelné, protože Linux běžel na holém stroji a Redox v QEMU. U hodnot 2 µs a 350 ns dodává, že obsahují režii měřicího programu, takže skutečná čísla budou nižší. Řádek, ve kterém Redox předstihl nepřipnutý Linux, tedy neříká, že by byl Redox rychlejší; říká, že se dostal do stejného řádu.

Uvnitř zprávy je i měření, které vyzní skromně. Ukázka Pixelcannon běžela na jednom jádru se starým plánovačem kolem 1 600 snímků za sekundu, s novým kolem 1 700. Rozdíl se ukáže až pod zátěží: při pohybu myší spadla stará sestava na 150 snímků a rozhraní zamrzlo tak, že kurzor nebyl vidět, kdežto nová klesla na zhruba 190 a kurzor se hýbal dál.

Práci vedli podle poděkování v textu Jacob Lorentzon a Wildan Mubarok, samotné RSoC pak Ron Williams. Rozšířený strom z původní práce zůstává na stole pro chvíli, kdy budou fronty úloh delší, než jsou dnes.

Zdroje

• RSoC 2026: EEVDF for Redox – závěrečná zpráva Akshita Gaura, redox-os.org, 22. srpna 2026
• RSoC 2026: EEVDF Scheduler – oznámení z 30. května 2026
• Redox OS Switches To EEVDF-Based Scheduler For 2.6x Throughput – Phoronix, 22. srpna 2026
• Earliest Eligible Virtual Deadline First: A Flexible and Accurate Mechanism for Proportional Share Resource Allocation – Ion Stoica, Hussein Abdel-Wahab, 1995
• Linux 6.6 – přehled změn, kernelnewbies.org

Vývojáři doporučují aktualizovat co nejdřív. Důvodem jsou dvě bezpečnostní upozornění zveřejněná 20. srpna, z nichž jedno nese hodnocení kritické.

Kudy mod utekl z izolace

Mody běží v Luanti v prostředí jazyka Lua, které je omezené: mod se nemá dostat k souborům na disku ani spouštět cizí programy. Upozornění GHSA-5373-9cjp-qfmg popisuje, jak to obejít. Škodlivý mod nastaví globální volbu, která určuje, odkud se načítá skript hlavní nabídky. Ten se spustí ve chvíli, kdy hráč hru opustí a vrátí se do menu. Prostředí hlavní nabídky ale omezené není, takže podstrčený kód se rozběhne s právy uživatele.

Zasažené jsou všechny verze do 5.16.1 včetně, a to jen v jednohráčové hře a na serveru spuštěném z nabídky. Kdo se ze seznamu připojuje na cizí server, ohrožený není. Kdo aktualizovat nemůže, může podle upozornění doplnit na začátek souboru builtin/mainmenu/init.lua funkci, která cestu k nabídce natvrdo vrátí do instalace:

function core.get_mainmenu_path()
    return core.get_builtin_path() .. "mainmenu"
end

Druhá chyba je v instalaci obsahu z cizího zdroje

Mody, hry a balíky textur se do Luanti instalují ze služby ContentDB. Klient míří ve výchozím stavu na instanci provozovanou projektem, ale adresu jde v nastavení přepsat volbou contentdb_url. Podle upozornění GHSA-j2v5-g52g-685j umí obsah stažený z podvržené instance rozbalit soubory mimo cílovou složku. Když takhle přepíše vnitřní skripty enginu, získá útočník spuštění kódu.

Rozsah je užší než u první chyby. Týká se jen přenosných instalací, kde složka builtin leží vedle složky mods – z oficiálních balíků jsou to zipy pro Windows a aplikace pro Android. Hodnocení je střední. Číslo CVE nemá zatím přidělené ani jedno z obou upozornění.

Vedle těch dvou zmiňuje oznámení další opravené bezpečnostní chyby včetně problémů s pamětí, ale bez podrobností. Souvisí s tím i nová položka v seznamu změn: když soubory ve složce builtin nesouhlasí s kontrolním součtem, zapíše se do logu varování. Slouží k odhalení poškozené nebo neúplné instalace.

Ovladače se přepsaly na SDL

Podpora herních ovladačů v Luanti existovala i dřív, jenže byla označená za experimentální a podle vývojářů nefungovala s většinou hardwaru. Teď je ten kód napsaný znovu nad rozhraním SDL. Ovladačem se dá chodit po světě a pracovat s ním, jednotlivé akce jdou v nastavení přemapovat.

Do nabídek a formulářů, kterým se v Luanti říká formspec, se ovladačem zatím nedostanete; na ně je pořád potřeba myš nebo dotyková obrazovka. Projekt to sám popisuje jako začátek podpory a další díly slibuje do příštích vydání.

Android pustí ke světům bez kabelu

Od Androidu 12 se k datům Luanti nedostane jiná aplikace, takže kdo chtěl vytáhnout svět z telefonu, musel telefon připojit k počítači. Nová verze data zpřístupňuje pro čtení: svět jde vzít správcem souborů a poslat dál. Opačný směr zatím nefunguje, takže nahrát do telefonu svět nebo mod se stejnou cestou nedá. Zápis mají vývojáři v plánu.

Co dostali tvůrci her

Modely ve formátu glTF zvládnou nově víc nezávislých animačních stop naráz. Dřív musel autor vyrobit každou kombinaci zvlášť – chůzi, kopání a chůzi s kopáním –, teď jde spustit dvě animace vedle sebe. Odkazovat se na ně dá jménem z glTF souboru místo čísly snímků, takže se cizí model nemusí předělávat.

Bublinové nápovědy zvládnou obrázky, náhledy předmětů a formátovaný text. Popisky ve formulářích jde zarovnat vodorovně i svisle, aniž by se kvůli tomu sahalo po náročnějším hypertextovém prvku. A prvky ukazatele stavu se dají označit za neskrývatelné, aby je nevypnula klávesa F1 – míří to na věci jako ztmavení okrajů obrazovky, které hráč vypnout nemá.

Z oprav jsou vidět dvě. Vlnící se hladina pod pevným blokem se konečně vykresluje správně a přesnější počítání srážek zbavilo pohyb postavy cukání, které způsobovaly nepřesnosti v desetinných číslech.

Druhý únik z izolace za rok

Sandbox pro mody v Luanti letos nepovolil poprvé. V dubnu 2026 vyšlo upozornění CVE-2026-41196, také s hodnocením kritické a také o útěku modu z izolace; opravila ho verze 5.15.2 a týkalo se všech vydání od 5.0.0. Srpnová chyba má užší dosah, zato vede přes hlavní nabídku, tedy přes obrazovku, kterou hráč vidí pokaždé, když hru opustí.

Zdroje: oznámení vydání na blogu Luanti, značka 5.17.0 a přehled bezpečnostních upozornění v repozitáři projektu a zpráva GamingOnLinux se seznamem změn.

K čemu rozhraní vzniklo

Původní důvod byl praktický. Řada procesorů a čipových sad má vlastní kryptografický akcelerátor a ovladač k němu žije v jádře. AF_ALG dovolilo dostat se k tomu ovladači i z běžného programu, aniž by k němu autor musel psát vlastní obsluhu. Podle Erika Biggerse, který v jádře na kryptografii pracuje, přibylo rozhraní v roce 2010.

Druhá výhoda byla úspora práce. Kdo potřeboval jen spočítat otisk nebo něco zašifrovat, nemusel k programu přibalovat celou kryptografickou knihovnu. Právě tenhle argument dnes neplatí. Knihoven je dost, jsou rychlé a běží v uživatelském prostoru, kde chyba shodí nanejvýš ten program.

Copy Fail

Zlom přišel na konci dubna 2026. Zveřejněná chyba CVE-2026-31431, které autoři dali jméno Copy Fail a vlastní stránku, sedí v modulu algif_aead – tedy v té části AF_ALG, která obsluhuje šifrování s ověřením celistvosti dat. Objevil ji Taeyang Lee ze společnosti Theori pomocí jejich nástroje na statickou analýzu kódu Xint Code.

Chyba dovolí neprivilegovanému uživateli zapsat čtyři vybrané bajty do vyrovnávací paměti stránek u libovolného souboru, který smí číst. Není v tom žádný závod o čas ani závislost na verzi jádra, jde o chybu v logice. Poškozená stránka se přitom neoznačí jako změněná, takže se obsah nikdy nezapíše na disk – soubor na disku zůstane netknutý a kontrola otisků nic nenajde. Další čtení se ale obslouží z paměti, takže stačí zamířit na program s nastaveným bitem setuid a upravit ho za běhu.

Útočný skript má 732 bajtů a podle autorů zabere na každé distribuci vydané od roku 2017. Přímo vyzkoušeli Ubuntu 24.04 LTS, Amazon Linux 2023, RHEL 10.1 a SUSE 16. Zasažená jsou jádra od verze 4.17 výš a modul bývá v nastavení distribucí zapnutý.

Jádro rozhraní zavrhlo

Biggers napsal do konference oss-security ještě před opravou, že v tom vidí příležitost. Jeho zpráva z 6. května shrnuje důvod jednou větou: kryptografické knihovny v uživatelském prostoru existují a kvůli počítání se není proč přepínat do režimu jádra.

Do jádra 7.2 se pak dostala trojice změn. První dopsala poznámku o zavržení do dokumentace i do nabídky překladu. Druhá vyhodila podporu předávání dat bez kopírování, tedy přesně tu cestu, kterou Copy Fail zneužil. Třetí odřízla akcelerátory mimo hlavní procesor, takže rozhraní teď sáhne jen po softwarových implementacích algoritmů.

„AF_ALG je skoro úplně zbytečné a vystavuje obrovskou plochu k útoku, která moderním nástrojům na hledání zranitelností nestačí. Ten poslední nález má dokonce vlastní web s krátkým skriptem v Pythonu, který spolehlivě získá práva správce na většině linuxových distribucí,“ napsal Biggers v komentáři k záplatě.

Zrušení akcelerátorů bere rozhraní jeho původní smysl. Biggers to v odůvodnění přiznává a dodává, že zatím neviděl reálnou úlohu, kde by se šifrování přes AF_ALG na akcelerátoru vyplatilo proti počítání v uživatelském prostoru. Kdyby se taková našla, mělo by pro ni podle něj vzniknout nové rozhraní.

Fedora si chce najít neznámé uživatele

Návrh změny Disable in Kernel Crypto Userspace API (Phase 1) podali Peter Robinson a Justin Forbes, míří na Fedoru Linux 45 a inženýrský výbor projektu ho už schválil. První fáze nesahá na nic, co dnes funguje: opře se o záplaty, které mají do jádra dorazit patrně v řadě 7.3, a omezí přístup k rozhraní na seznam známých programů.

Ve Fedoře jsou tři. Bezdrátový démon iwd, nástroj cryptsetup – ten rozhraní používá jen u svazků TrueCrypt, tcplay a VeraCrypt a při měření výkonu – a knihovna libkcapi, po které sahá dracut a překlad jádra. Žádný z nich touhle fází neutrpí. Cryptsetup si umí sáhnout jinam už teď, uživatelům iwd návrh doporučuje přejít na wpa_supplicant, protože iwd nemá podle textu návrhu žádného aktivního správce.

Smysl toho kroku je vypátrat, kdo další rozhraní volá. Fedora tím chce dopředu najít programy, o kterých nikdo neví, a domluvit se s jejich autory dřív, než rozhraní z jádra zmizí úplně. Návrh počítá i s couvnutím: kdyby se ukázalo, že omezení někoho bolí, dá se do vydání zase vypnout.

Poučení mimo kryptografii

Biggers ve zprávě do oss-security obrací pozornost od jednoho modulu k rozhraním jádra obecně. Předávání dat bez kopírování je podle něj samo o sobě riskantní, protože dovolí poslat stránky z paměti cizího souboru do velkého kusu kódu, který si musí dát pozor, aby do nich nezapsal. U výkonově citlivého síťování a práce se soubory se toho zbavit nedá, u zřídka používaných rozhraní ale ano.

Druhá poznámka míří na rozsah. Rozhraní podle Biggerse nemá uživatelskému prostoru automaticky otevírat všechno, co je za ním – zvlášť ne věci, které jdou udělat i mimo jádro. Copy Fail k tomu dodává konkrétní příklad: exploit sáhl po algoritmu authencesn, který ze tří známých uživatelů ve Fedoře nepotřebuje ani jeden.

Zavržení samo o sobě nic nevypíná a jádro 7.2 běží dál i s AF_ALG. Podstatná je právě ta první fáze ve Fedoře: teprve seznam povolených programů ukáže, kolik toho na rozhraní ve skutečnosti visí, a bez toho čísla se o vypnutí nedá rozhodnout.

Zdroje

• Fedora Project Wiki: Changes/Disable CRYPTO USER API
• Phoronix: Fedora 45 Looks To Begin Phasing Out In-Kernel Crypto Userspace API
• Phoronix: Linux 7.2 Proceeding To Deprecate AF_ALG Due To „Massive Attack Surface“
• oss-security: Re: CVE-2026-31431: CopyFail
• CERT/CC: VU#260001 Linux kernel contains local privilege escalation vulnerability (Copy Fail)
• copy.fail: CVE-2026-31431

Rust 1.98 vyšel 20. srpna 2026 a nese pět metod, které v jazyce dosud nebyly: algebraic_add, algebraic_sub, algebraic_mul, algebraic_div a algebraic_rem. Dostaly je typy f32 i f64. Sečíst jimi dvě čísla jde stejně jako operátorem plus, jenže překladač u nich smí sáhnout na pořadí.

Proč překladač desetinná čísla sám nezrychlí

Optimalizace stojí na slibu, že se výsledek nezmění. U celých čísel má překladač volnou ruku, protože a + (b + c) se rovná (a + b) + c. Součet pole tak jde rozdělit na několik proudů a nechat procesor sečíst čtyři hodnoty jedinou instrukcí.

Desetinná čísla tuhle rovnost nesplňují. Jejich rozsah je tak velký, že dost malé číslo přičtené k dost velkému zanikne: 1e16 + 1.0 se rovná 1e16. Pořadí sčítání proto výsledek mění. Pole s milionem jedniček, které má hodnotu 1e16 na začátku, dá jiný součet než totéž pole s tou hodnotou na konci. Překladač předpokládá, že si autor kódu pořadí vybral schválně, a nesáhne na ně.

Kolik ta opatrnost stojí, změřil Itamar Turner-Trauring na procesoru Intel Core i7-12700K. Milion hodnot typu i64 jeho program sečetl za 151,9 mikrosekundy, milion hodnot f64 za 595,2 mikrosekundy. V prvním případě procesor 250 003krát sáhl po 256bitové instrukci SIMD, ve druhém ani jednou.

Povolení se dává po jednotlivých operacích

Nové metody dělají totéž co běžné operátory, ale říkají překladači, že u nich smí využít algebraické vlastnosti reálných čísel. V plovoucí řádové čárce ty vlastnosti neplatí, a právě proto se jinak nepoužívají. Součet napsaný jako řetěz volání algebraic_add tedy překladač smí spočítat po dvojicích a obě poloviny naráz.

let mut total: f64 = 0.0;
for value in values {
    total = total.algebraic_add(*value);
}

Jaké úpravy si přitom dovolí, poznámky k vydání neupřesňují. Podobat se to prý bude tomu, co v jiných jazycích udělá přepínač -ffast-math. Rozdíl je v dosahu: přepínač platí pro celý překlad, kdežto tady se povolení dává řádek po řádku.

Výsledek je nedeterministický. Tytéž vstupy mohou vyjít pokaždé jinak i uvnitř jednoho běhu programu, protože si překladač smí vybrat jinou optimalizaci. Nedefinované chování z toho ale nevznikne a dokumentace k tomu dodává, že se nebezpečný kód nesmí spoléhat na žádnou vlastnost návratové hodnoty.

Osmkrát pomalejší skalární součin

Celá změna vznikla z jednoho měření v roce 2025. Skalární součin dvou polí, tedy jedna z nejběžnějších úloh numerického kódu, byl ve stabilním Rustu proti C++ zhruba osminásobně pomalejší. Autor návrhu to změřil na notebookovém procesoru Intel Core i7-10875H. Kód v C++ přeložený Clangem 18.1.3 potřeboval 10 mikrosekund, tentýž algoritmus v Rustu 1.84.1 osmdesát čtyři. Rust v kanálu nightly, kde už tehdy odpovídající vnitřní operace existovaly, se vrátil na 10 mikrosekund. Testy jsou v repozitáři dot-bench.

Součet po dvojicích potřebuje obojí

K čemu je to jemné dávkování dobré, ukázal Turner-Trauring na součtu po dvojicích. Je to algoritmus, kterým sčítá pole i knihovna NumPy: pole se rozpůlí, každá půlka se sečte rekurzivně týmž postupem a oba mezisoučty se sečtou nakonec. Pod hranicí 128 prvků se sčítá postupně a právě tam dal algebraické sčítání. Ty dva mezisoučty nahoře nechal na obyčejném plusu, aby překladač na jejich pořadí nesáhl.

Milion hodnot mu tak sečetl za 144,5 mikrosekundy. Funkce np.sum potřebovala na tomtéž poli 190,7 mikrosekundy a prosté sčítání v cyklu 563,1. Přesnost přitom zůstala na úrovni NumPy. U pole, které začíná hodnotou 1e16, minul prostý součet správný výsledek o milion, NumPy o čtrnáct a součet po dvojicích o šest.

Druhý jeho test počítal součet druhých mocnin rozdílů dvou polí. Přechod na algebraické operace ho zkrátil z 628,7 na 371,1 mikrosekundy a počet instrukcí procesoru na jednu hodnotu klesl ze 4,5 na jednu. Měření vzniklo osmnáct dní před vydáním, takže autor kód pouštěl v kanálu beta, který podle něj obsahuje tutéž funkci.

Kdyby algebraické operace stály ve všech řádcích algoritmu, překladač by ho mohl zjednodušit na obyčejný cyklus a přesnost, kvůli které vznikl, by zmizela. Kdyby tam nebyly vůbec, kód by běžel pomaleji. Míchat rychlost a přesnost uvnitř jedné funkce je podle nás na celé změně to nejzajímavější.

Formátování čísel bez cizí knihovny

Druhá novinka vydání míří na výpis čísel. Celočíselné typy dostaly metodu format_into, která zapíše dekadický zápis do bufferu NumBuffer a vrátí kus řetězce s vypůjčenou životností. Buffer je dost velký na jakoukoli hodnotu daného typu a metoda obchází většinu práce navíc, kterou formátování přes makro write! odvádí kvůli dynamickému výběru implementace. Podle poznámek k vydání vychází format_into v testovací sadě itoa-benchmark podobně jako knihovna itoa, takže ji projekty můžou přestat používat.

Stabilizovalo se i pár drobností. Metody str::substr_range a [T]::subslice_range zjistí, kde přesně v původním řetězci nebo řezu leží jeho část. Funkce String::from_utf16le a její příbuzné převádějí UTF-16 s určeným pořadím bajtů a atomické typy dostaly from_mut a get_mut_slice.

Zápis staré opravy do dokumentace

Poslední z hlavních položek novinka není. Do verze 1.96 platilo, že přesun hodnoty ManuallyDrop<Box<_>> poté, co se box uvolnil, je nedefinované chování. Způsobovala to chyba v překladači. Verze 1.96 ji opravila a 1.98 to dopsala do dokumentace jako závazek, že takový kód nedefinované chování mít nebude ani napříště. Souvislosti popisuje RFC 3336.

Do stabilního kanálu naopak zatím nedorazila nová podoba borrow checkeru, kterou Rust zapnul v nightly začátkem srpna. Tým ji chce stabilizovat do konce roku.

Zdroje: oznámení vydání na blogu Rustu, návrh ACP 532 v repozitáři knihovního týmu Rustu, měření Itamara Turner-Trauringa a zpráva Phoronixu.

Youngův dvojštěrbinový pokus se ve školách předvádí dvě stě let a pokaždé stejně. Světlo projde dvěma blízkými štěrbinami a na stínítku za nimi vyskočí pruhy. Tým z Tokijské univerzity ho teď provedl uvnitř krystalu křemíku, kde roli štěrbin zastaly dva sousední sloupce atomů vzdálené 1,36 ångströmu, tedy 136 pikometrů. Práce vyšla 19. srpna 2026 v Nature s otevřeným přístupem.

Rozdíl je v měřítku. Youngovy štěrbiny bývají asi milimetr od sebe a stínítko metr daleko; tady jsou zdroje sedm řádů blíž u sebe, vzorek má tloušťku kolem deseti nanometrů a detektor stojí deset centimetrů za ním. Univerzita v tiskové zprávě z 20. srpna mluví o desetimilionkrát menším Youngově pokusu.

Krystal místo stínítka

Nástrojem je rastrovací prozařovací elektronový mikroskop, zkratkou STEM. Svazek elektronů se v něm zaostří do stopy a jezdí po vzorku bod po bodu, korektor optických vad přitom dovolí stopu zúžit pod rozteč atomů. Tady měřila 1,1 ångströmu v polovině výšky a mikroskop ji postavil přesně doprostřed mezi dva sloupce atomů křemíku, které se ve směru [110] promítají jako těsná dvojice.

Uvnitř krystalu se svazek nechová jako ve vzduchu. Přitažlivý potenciál atomových jader působí jako vlnovod a intenzitu svazku stáhne na oba sloupce. Na odvrácené straně vzorku tak vzniknou dva oddělené zdroje vzdálené právě 1,36 ångströmu a jejich vlny na detektoru interferují. Proužky vycházejí kolmo na spojnici obou sloupců a jejich rozteč té vzdálenosti odpovídá. Když svazek stojí na jednom sloupci místo mezi dvěma, proužky zmizí.

Měřilo se na mikroskopu JEOL JEM ARM300CF se studenou autoemisní katodou a korektorem DELTA, při urychlovacím napětí 300 kV a konvergenčním polovičním úhlu 9,1 mrad. Proud ve stopě autoři odhadli na 9,1 pA. Jeden difrakční obrazec je zašuměný, proto zprůměrovali 356 krystalograficky rovnocenných dvojic; dohromady je v tom průměru 33 milionů elektronů.

Proužky přežily i 900 kelvinů

Atomy se ani při pokojové teplotě nedrží na místě. Kdyby se každý ze dvou sloupců chvěl sám za sebe, vzdálenost mezi štěrbinami by se náhodně měnila a proužky by se rozmazaly. Nestalo se to. Obrazec zůstal čitelný od 300 do 900 kelvinů, tedy i přes šest set stupňů Celsia.

Odpověď dalo srovnání se simulacemi. Model, ve kterém se atomy hýbou nezávisle na sobě, se s naměřeným obrazcem nesešel a vyšší proužky v něm chybí. Model s korelovaným pohybem sedí. Sousední atomy se tedy z velké části chvějí společně a právě to udrží koherenci vln, kterou by nezávislý pohyb rozbil. Akustické módy, tedy nejsilněji obsazené kmity mřížky, posunou oba atomy stejným směrem naráz. Na jejich vzájemnou vzdálenost proto nemají vliv a viditelnost proužků nekazí.

Číslo, které z obrazce vypadne

Míru té společné chvějivosti autoři vyjádřili číslem. Pro každou teplotu prošli mřížku 41 krát 41 dvojic korelačních koeficientů od nuly do 0,8 po krocích 0,02, ke každé nasimulovali difrakční obrazec a hledali ten, který na naměřený sedí nejlíp. Při 300 kelvinech vyšla korelace ve směru vazby 0,362 a napříč ní 0,184, obojí s nejistotou 0,005 při 95% intervalu spolehlivosti.

Výpočet z dynamiky mřížky předpovídal 0,39 a 0,24. Měření tedy vyšlo o něco níž, poměr obou směrů ale sedí: podél vazby je pohyb svázanější než napříč. Právě tenhle rozdíl se dá číst jako tuhost konkrétní vazby, protože vztah mezi korelací a poměrem tuhostí autoři odvodili z modelu lineárního řetízku analyticky.

Zajímavější než samotná čísla je jejich stálost. Střední kvadratická výchylka atomů roste s teplotou výrazně, korelační koeficienty se přitom mění jen mírně. Autoři z toho vyvozují, že jde o vlastnost meziatomového potenciálu, ne o odraz toho, jak je vzorek zrovna horký.

Proč to zajímá výrobce čipů

Teplo se polovodičem šíří jako kmity mřížky a to, jak snadno přejde z atomu na atom, určuje tuhost vazby mezi nimi. Zavedené metody, nepružný rozptyl neutronů nebo rentgenového záření, měří disperzi fononů zprůměrovanou přes makroskopický objem vzorku. Tady jde o jedinou dvojici sloupců, takže se v principu dá proměřit i místo, kde je mřížka porušená: bodová porucha, hranice zrn, rozhraní dvou materiálů. Univerzita to ve zprávě spojuje s tepelným návrhem polovodičových součástek.

Jednu výhradu k tomu podle nás patří dodat. Výsledné číslo z obrazce nevypadne přímo, vytáhne ho až porovnání se simulacemi metodou multislice v knihovně abTEM. Stojí a padá tedy s modelem, do kterého vstupuje tloušťka vzorku, zbytkové vady optiky i naklonění krystalu. Autoři se proti tomu opřeli o rozptyl do vysokých úhlů, který je na tyhle vlivy málo citlivý, a tloušťku vzorku pro každou teplotu určili zvlášť: 12,7 nm při 300 kelvinech, 10,8 nm při 500 a 10,4 nm při 900. Křemík je navíc učebnicově dokonalý krystal. Že metoda projde i na porušeném místě, o které tu jde především, zatím ukázané není.

Zdroje: článek Atomic-scale double-slit interferometry with a focused electron probe v Nature z 19. srpna 2026 (otevřený přístup, DOI 10.1038/s41586-026-10914-9) a tisková zpráva Tokijské univerzity z 20. srpna 2026. Na práci se podíleli Koudai Tabata, Takehito Seki, Toma Susi, Ryo Ishikawa a Naoya Shibata; Toma Susi působí na Fakultě fyziky Vídeňské univerzity, zbytek týmu na Tokijské univerzitě.

Čínský DeepSeek přidal 21. srpna 2026 do svého rozhraní model deepseek-v4-flash-vision-exp. Vychází z textového V4-Flash a podle firmy si v čistě textových úlohách vede stejně jako on, navíc ale přijímá obrázky. Týž den vyšla verze 0.1.1 agentního nástroje DeepSeek Harness, která už s modelem počítá.

Architekturu DeepSeek nezveřejnil. OpenRouter, který model nabízí přes jediného poskytovatele, u něj uvádí řídkou směs expertů s 284 miliardami parametrů, z nichž je při dotazu aktivních 13 miliard. Kontextové okno má milion tokenů, výstup nejvýš 384 tisíc.

Tři cesty, jak snímek poslat

Obrázek se posílá jako blok v poli content, tedy ve tvaru, který zavedlo rozhraní OpenAI. Přiložit ho jde třemi způsoby: zakódovaný do base64 přímo v požadavku, odkazem na veřejnou adresu, ze které si ho model stáhne sám, nebo přes Files API, kam se nahraje jednou a dál se na něj odkazuje identifikátorem. Files API je podle DeepSeeku zdarma.

{
  "type": "image_url",
  "image_url": {"url": "https://example.com/image.jpg", "detail": "low"}
}

Pole detail říká, jak se se snímkem naloží. Hodnota low ho před vyhodnocením zmenší na 512×512 px, high i original ho nechají v původní velikosti. Formát se pozná z obsahu souboru, ne z přípony ani z hlášeného typu MIME; projde JPEG, PNG, GIF a WebP.

Limity jsou popsané dost podrobně na to, aby se s nimi dalo počítat dopředu. Tělo požadavku smí mít 48 MiB, jeden snímek 32 MiB při vložení do požadavku a 64 MiB přes Files API. V jednom dotazu jich smí být až šest set. Hrana snímku měří nejvýš 8192 px, jakmile ale požadavek nese patnáct a víc obrázků, strop klesá na 4096 px. Obrázky se přijímají výhradně v uživatelských zprávách; v systémové nebo asistentské vrátí rozhraní chybu 400.

Za obrázek se platí tokeny, nejvýš 384

Snímek se převede na tokeny podle rozměrů a účtuje se spolu s textem. Podstatné je, co se s ním stane předtím. Velké obrázky se zmenší tak, aby počet pixelů odpovídal zhruba formátu 800×800, malé se naopak zvětší. Snímek 2000×2000 proto stojí přesně tolik co snímek 5000×5000 a strop je 384 tokenů za kus. Každý obrázek se počítá zvlášť, sleva za množství žádná není.

Ceník je shodný s textovým V4-Flash. Ve špičce stojí milion vstupních tokenů 0,44 dolaru, při zásahu do vyrovnávací paměti 0,014 dolaru, a milion výstupních 1,32 dolaru. Mimo špičku je to polovina. Špičku má DeepSeek vymezenou hodinami 01:00 až 04:00 a 06:00 až 10:00 UTC.

„Blízko Opusu 4.8“ a co k tomu říká tabulka

K vydání firma napsala, že model posouvá multimodální agentní schopnosti blízko k Opusu 4.8 od Anthropicu. Server The Next Web si tabulku, kterou k tomu DeepSeek zveřejnil, přepočítal: z jedenácti testů nový model tři vyhrává. DeepSWE o 1,3 bodu, Agents' Last Exam o 1,6 a ZeroBench o 1,0. Na osmi zbylých zaostává. U NL2Repo, kde se pracuje v měřítku celého repozitáře, je rozdíl dvanáct bodů, tedy 57,7 proti 69,7.

Většina ostatních výsledků je opravdu těsná. Terminal Bench 2.1 skončil 83,9 ku 85,0, Toolathlon-Verified 75,9 ku 76,2 a Chartography 64,3 ku 65,0. AutomationBench vypovídá spíš o oboru než o souboji: všechny tři porovnávané modely tam skončily v pásmu 25 až 27 bodů.

Proti vlastnímu předchůdci je posun čitelnější, protože čísla textového V4-Flash vydal DeepSeek na konci července. Terminal Bench vzrostl z 82,7 na 83,9, DeepSWE z 54,4 na 59,3 a DSBench-Hard z 59,6 na 63,6. Ze sedmi textových zkoušek klesla jediná, hledání zranitelností Cybergym: ze 76,7 na 75,3.

Poznámka pod tabulkou

Největší skok firma hlásí u ApexBenchu a u Agents' Last Exam. Pod tabulkou k tomu ale sama dodává, že textový V4-Flash v obou zkouškách multimodální části zadání ignoruje. Starší model tam tedy dostal test s obrázky, na které nevidí, a část toho skoku měří právě tohle. DeepSeek to napsal rovnou do tabulky, ne až do odpovědi na dotaz.

Jako souboj se špičkou se srovnání nedá číst ještě z jednoho důvodu. The Next Web upozorňuje, že Opus 4.8 sice Anthropic dál vede jako aktivní model, od 24. července ale existuje novější Opus 5 a s tím novinku nikdo neporovnal. DeepSeek to ostatně netvrdí. Napsal „blízko Opusu 4.8“ a u toho zůstal.

Váhy zatím venku nejsou

Model běží jen na placené vývojářské platformě DeepSeeku a přes OpenRouter. Server SiliconANGLE připomíná, že firma řadu starších modelů uvolnila i ke stažení, u tohohle to zatím neoznámila. Slovo „experimentální“ v názvu navíc naznačuje, jak dlouho se na model dá spoléhat: předchozí V3.2-Exp vyšlo 29. září 2025 a řádné V3.2 po něm přišlo 1. prosince.

Model tedy přečte obrazovku i graf a na většině zkoušek z té tabulky zaostává o jednotky bodů. Rozdíl v ceně je přitom řádový: The Next Web uvádí, že milion slov vyjde u DeepSeeku zhruba na 87 centů proti asi padesáti dolarům u Anthropicu. Největší mezera zůstává u práce v měřítku celého repozitáře, tedy přesně tam, kam agentní nástroje míří.

Zdroje

• DeepSeek: DeepSeek-V4-Flash-Vision-Exp Release, 21. 8. 2026
• DeepSeek API Docs: Vision
• DeepSeek API Docs: Models & Pricing
• DeepSeek API Docs: Change Log
• The Next Web: DeepSeek launches an experimental multimodal model to rival Anthropic
• SiliconANGLE: DeepSeek debuts multimodal language model competitive with Opus 4.8
• OpenRouter: DeepSeek V4 Flash Vision Exp

Oběh za 8,7 roku, přiblížení na dvanáct astronomických jednotek

Dráha S301 je silně protáhlá a jeden oběh na ní trvá zhruba 8,7 roku. Kratší dobu oběhu nikdo ve středu Galaxie dosud nenaměřil. V nejbližším bodě dráhy dělí hvězdu od černé díry 1,78 miliardy kilometrů, tedy asi dvanáctinásobek vzdálenosti Země–Slunce. Od Slunce k Saturnu je to o pětinu méně.

Právě v tom bodě letí S301 rychlostí kolem 25 000 kilometrů za sekundu. To je přes osm procent rychlosti světla a podle Evropské jižní observatoře stotisíckrát víc, než letí dopravní letadlo. Rychlejší hvězdu Mléčné dráhy zatím nikdo nenašel.

Hmotnost samotné černé díry, kterou označujeme Sagittarius A*, uvádí práce v Nature jako 4,3 milionu hmotností Slunce. Tisková zpráva observatoře ji zaokrouhluje na čtyři miliony.

Dvě miliardy krát slabší než Betelgeuse

Hlavní překážkou nebyla vzdálenost, ale jas. S301 je hvězda hlavní posloupnosti a v infračerveném pásmu K má jasnost 19,3 magnitudy – zhruba dvě miliardy krát méně, než má Betelgeuse. Kolem Sagittaria A* přitom svítí hvězdy o mnoho řádů jasnější. Tým MPE přirovnává hledání k pokusu zaslechnout bzučení mouchy, zatímco hraje symfonický orchestr.

Pomohl přístroj GRAVITY na VLTI a jeho čerstvá přestavba na GRAVITY+, ke které patří nový systém adaptivní optiky a laserové vodicí hvězdy. Citlivost tím podle MPE vzrostla desetkrát až stokrát. Interferometr skládá světlo ze čtyř osmimetrových dalekohledů do jednoho obrazu; jak moc si tím polepší proti jedinému dalekohledu, uvádějí oba prameny různě. Zpráva observatoře mluví o patnáctinásobku prostorového rozlišení, zpráva MPE o čtyřicetinásobku úhlového. Rozdíl ani jedna z nich nevysvětluje.

První stopu měl tým na jaře 2023. Ze starších záznamů pak dráhu dopočítal zpět do roku 2017 a zjistil, že hvězda prošla přísluním na začátku roku 2023, tedy krátce předtím, než ji kdokoli zahlédl.

Kde Schwarzschildovo řešení přestává stačit

Hvězdy kolem Sagittaria A* slouží jako zkušební tělíska obecné teorie relativity. U hvězdy S2, dosud nejlepšího takového tělíska, se podařilo naměřit gravitační rudý posuv a stáčení přísluní. Oba jevy plynou ze zakřivení prostoročasu kolem hmoty a v pohybu hvězdy se projeví v řádu (v/c)².

Rotující černá díra ale prostoročas kolem sebe navíc strhává s sebou. Zpráva MPE to přirovnává ke lžičce, která roztočí vodu v hrnku; odborně jde o Lense–Thirringův jev. Ten je slabší a v pohybu hvězdy vychází až v řádu (v/c)³. S301 sonduje prostoročas desetkrát blíž k díře než S2, a proto je první hvězdou, jejíž dráha na rotaci Sagittaria A* citlivě reaguje.

Rotaci díry zatím nikdo nezměřil

Tady se prameny rozcházejí a stojí za to je číst přesně. Tisková zpráva MPE píše, že S301 je první hvězdou, u níž se tenhle jev kolem černé díry podařilo naměřit. Práce v Nature má ale v názvu „Objev hvězdy citlivé na rotaci Sagittaria A*“ a v abstraktu stojí jen to, že pohyb hvězdy je na rotaci přímo citlivý.

Odpovídají tomu i výroky, které od členů týmu přebírá tisková zpráva observatoře a The Guardian. Felix Mang z MPE, hlavní autor práce, mluví o naději změřit rotaci během příštích deseti let. Stefan Gillessen dodává, že by šlo o první přímé měření rotace hmotné černé díry vůbec. Naměřená tedy zatím není a S301 k ní zatím jen otevírá cestu.

Rozdíl není hnidopišství. Přesnost, které je na určení rotace potřeba, vyjde podle týmu až ze dvou úplných oběhů. Další průchod přísluním připadá na rok 2031 a k polohám z GRAVITY+ mají přibýt měření radiální rychlosti přístrojem MICADO na Extrémně velkém dalekohledu, který observatoř staví na Cerro Armazones. Teprve z obojího se dá poskládat trojrozměrný pohyb hvězdy.

Přitáhla ji rozbitá dvojhvězda

Tak blízko u černé díry hvězda vzniknout nemůže. Autoři proto sahají po Hillsově mechanismu: kolem díry prolétla dvojhvězda, slapové síly ji roztrhly a jednu složku díra zachytila na těsné dráze. Druhou vymrštila pryč, podle observatoře nejspíš takovou rychlostí, že opustí celou Galaxii. Sedí tomu vysoká výstřednost dráhy S301.

Cílem přitom není jedno číslo. Gillessen mluví o testu Kerrovy metriky, tedy popisu prostoročasu kolem rotující černé díry, a v delším výhledu i o teorému o neexistenci vlasů (no-hair theorem) – tvrzení, že černou díru úplně popisují jen hmotnost, moment hybnosti a elektrický náboj. Cesta k tomu vede přes desetiletí trpělivého sledování jedné velmi slabé tečky.

Zdroje

• ESO: Milky Way's fastest star orbits our supermassive black hole so closely it feels its spin (19. 8. 2026)
• MPE: A star with an Extreme Orbit (19. 8. 2026)
• GRAVITY+ Collaboration: Discovery of a star sensitive to the spin of Sagittarius A*, Nature, 19. 8. 2026, doi: 10.1038/s41586-026-10894-w
• The Guardian: Astronomers detect fastest known star in Milky Way (19. 8. 2026)

Český web o mobilech vypadá obvykle podobně: recenze nového přístroje, katalog s parametry, soutěž o telefon. Svět HTC nemá ani jedno. Bere funkci telefonu, který se prodával před deseti nebo patnácti lety, dohledá k ní dobovou tiskovou zprávu a skončí u přístroje, který tutéž věc umí dnes.

Jen to, co se vejde do kapsy

Rubrik má web sedm a všechny jsou o telefonu: Android, Aplikace, Apple, HTC, Historie, Sítě a Telefon a společnost. Notebook, televize ani herní konzole se do nich nevejdou. Sitemapa vypisuje 118 článků, kdežto součet čísel u rubrik je 173, takže jeden text běžně patří do dvou rubrik naráz.

Pro srovnání: server mobilenet.cz se v titulku sám popisuje jako web o mobilních telefonech, noteboocích a technologiích budoucnosti a rubriky na notebooky i tablety opravdu má. Svět Androida se v titulku hlásí k recenzím, novinkám, testům a návodům. Recenze nového telefonu na Světě HTC není ani jedna.

Historie, která pokaždé dojde k dnešku

Nejvíc práce si web dává s rubrikou Historie: 42 článků ze 118. Postup je v nich pořád stejný.

Text o BlinkFeedu popisuje domovskou obrazovku telefonu HTC One z února 2013, na které místo ikon běžel proud zpráv a příspěvků ze sociálních sítí. Cituje k tomu tiskovou zprávu HTC i dobovou recenzi serveru The Verge a končí u Discoveru, který dnes nabízí Google. Rozdíl, na kterém článek stojí, je způsob, jak se do toho proudu dostane obsah: HTC ho muselo domlouvat s vydavateli po kusech, Google si ho bere z vlastního indexu.

Stejnou stavbu mají další texty. Kulička pod displejem, kterou HTC psalo do specifikací modelů Magic a Hero, vede k dnešnímu podrženému mezerníku. Druhý čip určený jen na zpracování fotek, jaký HTC dalo do One X v únoru 2012, vede ke koprocesoru, který Google poprvé nasadil až v Pixelu 2 v roce 2017. Pod každým takovým článkem stojí seznam zdrojů a jsou v něm hlavně tiskové zprávy výrobců a recenze z doby vydání přístroje.

Vedle historie běží běžné zpravodajství

Zbytek webu jsou zprávy o telefonech tak, jak vycházejí. Za poslední týden tam přibyl strop na paměť aplikací v Androidu 17, dvojitý podpis instalačních balíčků klasickým a postkvantovým klíčem, nové obchodní podmínky Applu pro Evropskou unii a rozbor zprávy sdružení GSMA o Malawi.

Zvláštní je rubrika Telefon a společnost, protože v ní telefon vystupuje jako věc, o které rozhoduje úřad: české provedení práva na opravu, chystaný zákaz mobilů ve školách nebo rozhodnutí Evropské komise o cizích AI asistentech v Androidu. Článků v ní je zatím jedenáct, což je spolu s rubrikou Sítě nejmíň ze všech sedmi.

Recenze HTC leží na jiné adrese

Odkaz v patičce vede na recenze.svet-htc.cz, tedy na samostatnou statickou stránku s technickými specifikacemi, klady a zápory a galerií fotek. Přístrojů je v ní třiadvacet a nejnovější z nich je HTC One z roku 2013. Nic dalšího už nepřibylo: v patičce stojí copyright z roku 2014 a stránka si dodnes načítá starou verzi Google Analytics a reklamní zónu Skliku.

Úvodní text archivu zůstal ve tvaru, v jakém ho tam kdysi někdo napsal. „V dnešní době společnost HTC soustřeďuje vývoj pro Android, ale také Windows Mobile,“ stojí v něm, a o kus dál, že firma patří mezi nejrychleji rostoucí v oboru. Kdo tam přijde pro recenzi současného telefonu, odejde s prázdnou. Kdo hledá parametry přístroje z roku 2011, dostane je i s galerií.

Jak je web postavený

Vzhled je střídmý a reklamu na sobě web nemá. Výpis se dá řadit třemi způsoby, Trending, Nejnovější a Nejčtenější, a u každého článku je vidět, kolikrát ho někdo otevřel. Čísla jsou zatím nízká: text vydaný minulý týden měl při psaní tohohle článku šest zhlédnutí.

Diskuse pod články je, ale psát do ní může jen přihlášený čtenář a většinou v ní nikdo není. Odběr web nabízí přes RSS a Atom a přímo u té nabídky píše, že e-mailem neposílá nic. Jméno autora u článků nestojí. Soubor robots.txt zavírá jen cestu do administrace a k rozhraní API, sitemapa je úplná a vede i na stránky rubrik.

Metoda, na které web stojí, má strop. Telefonů HTC, u kterých se dá ukázat funkce s pokračováním v dnešku, je konečný počet a v archivu recenzí jich leží třiadvacet. Rubrika Historie proto sahá i jinam: je v ní stabilizace obrazu, kterou v roce 2012 předváděla Nokia u Lumie 920, notifikační dioda vypuštěná u Samsungu Galaxy S10 i posílání souborů přiložením dvou telefonů, které Android uměl už v roce 2011 a pak to sám pohřbil. Značka v názvu tak drží čím dál víc dobu než výrobce.

Zdroje

• Svět HTC, úvodní strana
• Svět HTC: rubrika Historie
• Svět HTC: Proud zpráv na domovské obrazovce zkusilo HTC v roce 2013, dnes ho rozdává Google
• Svět HTC: sitemap.xml
• Recenze telefonů HTC
• Recenze telefonů HTC: HTC One (M7)
• mobilenet.cz
• Svět Androida

Proč se vysoký tlak plazmatu nedrží sám

Culhamský stroj je největší sférický tokamak v provozu. Vznikl přestavbou staršího MAST, který tam běžel od roku 2000 do roku 2013; přestavba přinesla delší pulzy, silnější magnetické pole, víc ohřevu a nový systém odvodu tepla. Ve fúzním stroji se izotopy vodíku ohřejí, stlačí a udrží při teplotách, které v MAST Upgrade dosahují třiceti milionů stupňů Celsia. Čím vyšší je hustota a teplota, tím rychleji přibývá fúzních reakcí. Plazma o vyšším tlaku tedy vydá víc výkonu z jednoho krychlového metru a víc se podobá tomu, co bude potřebovat elektrárna.

Vysoký tlak ale plazma rozkolísá. Na okraji vznikají náhlé výtrysky, kterým se říká okrajové lokalizované módy, zkratkou ELM. Jediná taková událost umí vyhodit až desetinu energie uložené v plazmatu. Opakovaně tím trpí vnitřní stěna i součásti, které odvádějí teplo, a v elektrárně by se to promítlo do nákladů na údržbu. Bez řešení se ELM považují za vážnou překážku komerční fúze.

Čtyři klidné režimy místo jednoho

Tým v Culhamu potlačoval výtrysky dvěma cestami. První je režim quasi-continuous exhaust (QCE), druhou rezonanční magnetické poruchy: cívky vytvoří trojrozměrné magnetické pole, které sníží tlak na okraji plazmatu a udrží ho stabilní. Stroj se navíc dostal do dalších dvou režimů, quiescent H-mode a I-mode. Oba drží energii v plazmatu lépe a velké výtrysky u nich nevznikají.

Nejde o britskou zvláštnost. Přehled konsorcia EUROfusion z dubna 2026 popisuje osm různých režimů bez velkých ELM, které se zkoušejí na pěti evropských tokamacích: ASDEX Upgrade, JET, MAST Upgrade, TCV a WEST. U QCE podle něj vycházejí parametry na okraji plazmatu po přepočtu srovnatelné s běžným režimem s výtrysky, takže se nabízí jako provozní scénář i pro ITER.

Polohu plazmatu hlídá světlo z divertoru

K tomu přidali v Culhamu techniku, kterou podle UKAEA nikdo před nimi nepoužil. Poloha plazmatu se měří podle viditelného světla, jež vyzařuje deuterium v horním a dolním vnějším divertoru, tedy v místech, kudy ze stroje odchází teplo a částice. Z rozdílu mezi oběma se v reálném čase pozná i nepatrné vychýlení. Budoucí elektrárna bude muset takové odchylky srovnávat sama, bez člověka u pultu, a tohle je krok tím směrem.

Dusík mění odpadní teplo ve světlo

Druhý nález se týká právě odvodu tepla. Vpustí-li se na okraj plazmatu malé množství dusíku, začne plazma vyzařovat velkou část odváděného výkonu jako světlo. Teplo se rozptýlí v objemu dřív, než dopadne na stěnu a na divertor, a špičkový tepelný tok klesne.

MAST Upgrade je první tokamak s plně optimalizovaným divertorem Super-X, který sám o sobě snížil tepelnou zátěž na desetinu. Ani to podle UKAEA v elektrárně stačit nebude a příměs bude nutná. Culhamské pokusy jsou první podrobnou studií toho, jak se příměs chová ve stíněné geometrii Super-X se dvěma nulovými body magnetického pole na sférickém tokamaku. Tým prozkoumal i takzvanou zápornou trojúhelníkovitost, tedy tvar plazmatu, který snese vysoký výkon bez ELM.

Co zpráva neuvádí

Konkrétní hodnotu tlaku UKAEA nezveřejnila. Mluví jen o nejvyšším tlaku, jakého stroj dosáhl, takže srovnání s jinými tokamaky z oznámení udělat nejde. Rozcházejí se i počty: tisková zpráva uvádí přes 1 100 plazmat, stránka projektu přes tisíc a k tomu více než dvě stě výzkumníků ze čtyřiceti institucí.

Kam výsledky míří

Zazněly na 52. konferenci Evropské fyzikální společnosti o fyzice plazmatu, kterou UKAEA pořádala od 29. června do 3. července 2026 v Edinburghu. Teď putují k týmům, které navrhují ITER a britskou prototypovou elektrárnu STEP ve West Burtonu v Nottinghamshiru.

Samotný stroj se mezitím přestavuje. Dostane dva nové injektory neutrálních svazků, které zdvojnásobí jeho ohřev, a systém Electron Bernstein Wave s dalšími 1,6 MW. Práce mají skončit v roce 2027 a šestá série pokusů, tentokrát zaměřená na STEP, je plánovaná na rok 2028. Elektřinu MAST Upgrade nevyrábí a vyrábět nebude; stejně jako u pulzního zdroje Sirius jde o měření, ze kterého se skládá návrh stroje pozdějšího.

Zdroje: tisková zpráva UKAEA ze 6. srpna 2026, stránka projektu MAST Upgrade, přehled režimů bez ELM na tokamacích konsorcia EUROfusion a stránka konference EPS Plasma Physics 2026.

Robotaxi má na rozhodnutí zlomek vteřiny. Data z kamer, lidarů a radarů musí projít celým řetězcem, od prvního pixelu po zásah do řízení, dřív než auto ujede pár metrů. Waymo tomu říká pixels-to-actuation a ve čtvrtek 20. srpna poprvé ukázalo, čím ten řetězec začíná. Zápis na firemním blogu podepsali viceprezident pro vývoj Satish Jeyachandran a vedoucí výpočetní části Daniel Rosenband.

Čip sedí na začátku řetězce

Novinkou je zakázkový obvod ASIC vyrobený 5 nm postupem. ASIC je čip navržený na jedinou úlohu: nedá se přeprogramovat jako běžný procesor, zato tu jednu věc zvládne rychleji a s menší spotřebou. Ten Waymův má na starosti přední část zpracování. Ze surových toků z lidaru, radaru a kamer vytáhne podstatné údaje, potlačí šum mezi snímky kvůli vidění za šera a výsledek pošle do inferenčního jádra, které teprve spouští modely slučující data z jednotlivých čidel.

Je to tedy předzpracování, ne rozhodování. Co auto udělá, vzniká až za tímhle čipem. Do návrhu prý vstoupila zkušenost z víc než 200 milionů mil ujetých plně autonomně a Waymo dodává, že výpočetní výkon vozu za osm let zvedlo dvacetkrát. Dosud podle serveru The Register spoléhalo na hradlová pole FPGA od Intelu. Ta se dají překonfigurovat, ale programují se obtížně a v hustotě výpočtu za jednoúčelovým křemíkem zaostávají.

Tisíc TOPS samo o sobě nic neříká

Jediné výkonové číslo, které firma pustila ven, zní přes 1 000 TOPS. Jeden TOPS je bilion operací za sekundu, řeč je tedy o víc než tisíci bilionech. Potíž je v tom, co k číslu chybí. Waymo neuvádí, v jaké přesnosti se operace počítají ani při jaké spotřebě, a bez toho se TOPS nedá poměřit s ničím jiným. The Register odhaduje osmibitová celá čísla, což by čip stavělo zhruba k platformě Nvidia Drive AGX Thor, sám to ale označuje za dohad.

Druhá výhrada je prostší. Těch 1 000 TOPS připadá podle blogu na přední zpracování, ne na celý palubní počítač. Server The Next Web upozorňuje, že srovnání s kompletními platformami pro autonomní jízdu, která po oznámení proběhla médii, staví jednu součástku proti celku. Waymo takové srovnání neudělalo.

Dva výpočetní celky místo jednoho

Zajímavější než výkon je způsob zapojení. Ve voze nesedí nikdo, kdo by převzal řízení, takže se zálohuje sám hardware. Výpočetní systém je podle zápisu navržený jako dva nezávislé motory: za běžného provozu pracují jako jeden celek a počítají tytéž úlohy souběžně, při poruše jednoho pokračuje druhý sám. The Register z toho vyvozuje, že každý vůz veze dvojici těchto obvodů.

Zbytek zadání zní méně efektně a je stejně tvrdý. Počítač jede v autě, ne v serverovně, takže snáší vibrace, rázy a teploty od mrazů na Středozápadě po parna ve Phoenixu. Waymo ho proto napojilo na kapalinové chlazení vozu. Musí být přitom tichý a nesmí sníst kufr, odkud pochází i název zápisu, doslova pohled pod naše víko kufru. Všechna čísla o vlastní bezpečnosti přitom firma vykazuje sama a žádný nezávislý orgán je neprověřil; nejblíž tomu bylo srovnání hlášených nehod s lidskými řidiči, které magazín rozebíral dřív.

Vlastní křemík vedle cizího

Spolu s čipem zveřejnila firma jmenný seznam dodavatelů: AMD, Micron, Nvidia, Samsung, Sandisk, Socionext a TSMC. Vlastní obvod tedy nikoho nenahradil. Úlohy mimo strojové učení, tedy řízení běhu, přesuny dat a zápis záznamů, zůstávají na součástkách partnerů a Waymo mluví o vyvážené heterogenní soustavě. Ze seznamu stojí za pozornost Socionext. Japonská firma navrhuje zakázkové obvody pro cizí zadavatele a bývá to cesta, jak přijít k vlastnímu čipu bez vlastního čipového oddělení.

Waymo dodává, že ASIC je jen jedna z několika vlastních součástek, na kterých pracuje. Které to jsou, neřeklo.

Podrobnosti až na Hot Chips

Údaje, které z blogu nevyplývají, by měly padnout na konferenci Hot Chips na Stanfordu. V pondělí 24. srpna tam má Daniel Rosenband přednášku Compute in Motion: Challenges of Autonomous Driving a hned po ní vystoupí v automobilové sekci Sabareesh Ravikumar a Pieter Kapsenberg s příspěvkem o procesoru pro slučování dat ze senzorů. Teprve tam se čip dostane před publikum, které se umí ptát na přesnost výpočtu i na spotřebu.

Zdroje: zápis na blogu Waymo, The Register, The Next Web, program konference Hot Chips 2026.

Antivirus vestavěný do Windows má od 12. srpna zveřejněný postup, kterým se z běžného účtu dají získat práva SYSTEM. Microsoft mu 14. srpna přidělil označení CVE-2026-69414 a dodnes u něj stojí věta, že na opravě teprve pracuje. Ta chyba se jmenuje ShieldBreak a její historie je zároveň příběhem sporu, který mezitím připravil nálezce o účty na GitHubu i GitLabu.

Obchází záplatu, kterou už jednou dostal

Východiskem je chyba RoguePlanet, kterou Microsoft opravil v červenci. Nálezce tvrdí, že oprava svůj úkol nesplnila, a ShieldBreak předvádí jako její úplné obejití. Předváděcí kód podle něj vyzkoušel na nejnovějších Windows 11 25H2 včetně kanálu Canary a na Windows Serveru 2025 se stoprocentní úspěšností; Windows 10 sice nepodporuje, ale zranitelné podle něj jsou také.

Dva nezávislí odborníci to ověřili. Podle rozboru The Hacker News potvrdil Kevin Beaumont, že postup na Windows 11 funguje, a zároveň upozornil, že s RoguePlanetem má společné jen málo: ten zneužíval souběh v souborovém systému a podstrkoval karanténě přepis systémových souborů, kdežto ShieldBreak mění obsah souboru během kontroly přes rozhraní Cloud Filter API. Will Dormann z firmy Tharros útok rovněž potvrdil a doplnil podmínku, která v prvních zprávách chyběla: Defender musí být zapnutý, jinak postup nefunguje.

Sled kroků, který Dormann popsal, je ukázka toho, jak se ze dvou neškodných věcí stane jedna škodlivá. Útočník nastraží zkušební soubor EICAR, symbolickými odkazy nasměruje kontrolu Defenderu do systémové složky a během ní podstrčí vlastní kód pod jménem phoneinfo.dll, tedy knihovny, která ve Windows standardně vůbec neexistuje. Pak nechá spustit naplánovanou úlohu QueueReporting, která patří k hlášení chyb a běží s nejvyššími právy. Ta knihovnu načte, protože ji hledá, a podstrčený kód se rozběhne jako SYSTEM.

Dvě strany jednoho sporu

ShieldBreak nevyšel po dohodě s výrobcem. Nálezce, vystupující jako Nightmare Eclipse a jinde jako Chaotic Eclipse, ho zveřejnil bez předchozího upozornění, a dělá to tak od jara, protože s Microsoftem vede otevřený spor.

Firma se k němu vyjádřila na blogu svého bezpečnostního střediska 27. května: šest dříve zveřejněných chyb, mezi nimi RedSun, UnDefend a BlueHammer, jí podle ní nikdo před zveřejněním neukázal, což odporuje koordinovanému zveřejňování. Totéž zopakovala u ShieldBreaku: podle vyjádření pro BleepingComputer chybu prověřuje a opraví, přičemž zdůraznila, že koordinovaný postup podporuje. Nálezce v záznamu neuvedla.

Druhá strana popisuje jiné věci. Nálezce tvrdí, že mu Microsoft smazal účet, přes který hlášení podával, že nedostal odměnu z programu za nalezené chyby a že mu padly výhrůžky. Doložit se dá to, co je vidět zvenčí: v květnu mu GitHub, který Microsoftu patří, zablokoval účet s jeho nálezy. Přestěhoval se na GitLab a přišel o účet i tam. Důvod blokace nikdo veřejně nevysvětlil ani v jednom případě.

Kolik z jeho nálezů je opravených, se ve zdrojích rozchází. Jisté je, že YellowKey, GreenPlasma a MiniPlasma zalátal červnový balík, RoguePlanet ten červencový a srpnový přinesl opravu chyby LegacyHive pod označením CVE-2026-62832. U RedSunu, UnDefendu a BlueHammeru jedny zprávy uvádějí, že opravené jsou, jiné z poloviny srpna je pořád vedou jako nezáplatované.

Co z toho plyne pro počítač, který jen běží

ShieldBreak není nic, co by přišlo z internetu samo. Útočník už na stroji musí umět spustit kód, byť pod nejobyčejnějším účtem. Nebezpečné je to jako druhý krok: kdo se dostane dovnitř přes phishing nebo cizí program, získá tímhle postupem správcovská práva bez jediného dialogu.

Obě chyby přitom sedí ve stejném místě ze stejného důvodu. Antivirus čte každý soubor a běží s nejvyššími právy, takže je zároveň nejlepší pákou, jakou útočník na systému najde. Vypnutím Defenderu by podle Dormanna útok nefungoval, jenže to je rada, kterou nikdo se zdravým rozumem nedá.

Zbývá čekat na opravu a držet Defender aktuální. Vyhledávací nástroj se aktualizuje sám a mimo řádný měsíční balík, takže až oprava vyjde, dorazí bez zásahu uživatele. V Zabezpečení Windows se dá číslo verze ověřit v části o ochraně před viry a hrozbami.

A pak je tu ta nepříjemnější část. Dokud spor trvá, budou další nálezy vycházet stejným způsobem: nejdřív veřejně, s funkčním předváděcím kódem, a až potom se k nim dostane výrobce. Zaplatí to lidé, kteří o něm nevědí.

Petice, kterou v listopadu 2025 poslal americkému úřadu pro bezpečnost silničního provozu (NHTSA) Bhupinder Dhadda, se ptala na jedinou věc: proč kolo těžkého nákladního auta drží jen předpětí deseti matic a nic dalšího. Úřad podnět letos 4. března otevřel pod číslem DP26002, prošel data a v pondělí 17. srpna vydal ve Federálním registru zamítnutí.

Co petice žádala

Podnět mířil na kola, která americké dokumenty označují jako 10-285,75 mm: deset šroubů rozmístěných po roztečné kružnici o průměru 285,75 milimetru. Jsou to obvyklá kola o průměru 22,5 palce se středěním na náboji a nosí je většina amerických tahačů, návěsů i přívěsů. Dhadda tvrdil, že se matice na takovém kole za provozu povolují samy, protože na nich kolísá teplota, přenášejí proměnlivé zatížení a chvění, styčné plochy se usazují a spoj únavově stárne. Chtěl, aby úřad posoudil, jestli chybějící záložní mechanická pojistka matic není bezpečnostní vadou.

Běžné kolo takovou pojistku nemá. Nejrozšířenější pomůckou zůstává plastová šipka nasazená na matici; sousední šipky se namíří proti sobě a když se některá matice pootočí, je to poznat z metru. Nedrží nic, jen to ukáže.

Čím úřad zamítnutí odůvodnil

Kancelář pro vyšetřování vad (ODI) prošla tři sady údajů: dotazníky, ve kterých si majitelé stěžují na své vozidlo, hlášení výrobců v systému včasného varování a půl roku záznamů o přestupcích, které u nákladních vozidel za povolené nebo chybějící kolové matice eviduje americká správa pro bezpečnost silniční nákladní dopravy (FMCSA). Vyšlo jí z toho, že povolené a chybějící matice se objevují většinou u vozů s vyšším nájezdem a krátce po servisním zásahu, ne kvůli tomu, jak je vůz navržený nebo vyrobený. K tomu úřad připsal, že řidič užitkového vozidla musí před každou jízdou provést prohlídku, při které se povolená matice dá najít.

Není to rozhodnutí o tom, že by druhá pojistka nepomáhala. Americké právo o vadách stojí na tom, že vada je vlastnost vozidla, ne způsob, jakým ho někdo udržuje, a úřad napsal, že doklady o systémové vadě nenašel. Zároveň dodal, že možnost zasáhnout později si nechává otevřenou.

Kolik kol vlastně odpadne

Přesné číslo nemá ani Severní Amerika. Naposledy se tím v USA soustavně zabývala Národní rada pro bezpečnost dopravy (NTSB) v roce 1992, po sérii nehod z podzimu 1991, při kterých zemřelo sedm lidí. Uzavřela to tak, že hlavní příčiny odpadlých kol u středních a těžkých nákladních aut jsou špatně dotažené matice a poškozená ložiska, a obojí že plyne z nedostatečné údržby.

Nejlepší čísla má kanadské Ontario, protože jako jediné vyšetřuje každý hlášený případ povinně. Přinutil ho k tomu koronerský soud, který se sešel v říjnu 1995 po několika smrtelných nehodách a vydal jedenatřicet doporučení; z nich vzešel i přestupek s objektivní odpovědností a pokutou až 50 000 kanadských dolarů, kterou dostane dopravce i řidič bez ohledu na příčinu. Počet hlášených případů pak spadl z 215 v roce 1997 na 99 o rok později a mezi lety 1999 a 2003 se držel na průměru 75 ročně.

Zpráva ontarijského ministerstva dopravy z roku 2004 shrnula 750 vyšetřených případů: přes 80 % zavinily matice a šrouby, 10 až 15 % ložiska. Souběžná práce Johna Woodrooffa uvádí, že v provincii i po zpřísnění odpadne kolo asi sedmkrát měsíčně a že si to od roku 1995 vyžádalo šest životů. Obě zprávy jsou ke stažení na stránce ontarijského školicího programu pro montáž kol.

V jednom se prameny rozcházejí. Přehled Truck News z letošního února píše, že návěs nebo přívěs přijde o kolo více než dvakrát častěji než tahač. Starší text téhož autora v Heavy Duty Trucking uvádí, že poměr byl zhruba vyrovnaný a přípojná vozidla měla jen asi o šest procent případů víc. Obojí se odvolává na ontarijská data, jen z jiných let.

Proč se matice povolí

Výrobci kol předepisují na matici zhruba 450 až 500 lb-ft, po přepočtu asi 610 až 680 N·m. Málo utažená matice se povolí sama, přetažená natáhne šroub za mez pružnosti a ten pak praskne. Rázový utahovák s jednopalcovým čtyřhranem přitom podle Truck News udělá za dvě vteřiny přes 700 lb-ft, tedy kolem 950 N·m, což je vysoko nad návrhovou hodnotou.

Předepsaný moment navíc platí jen tehdy, když jsou styčné plochy kola a náboje čisté. Rez, odlupující se lak nebo nečistota mezi nimi brání dosednutí. Stejně tak zkreslí výsledek použitý šroub nebo matice, kterou nikdo nepromazal: klíč ukáže správnou hodnotu, ale svěrná síla je jinde.

Proti usazení spoje se kola tradičně dotahují po ujetí 80 až 160 kilometrů. Americké sdružení pneumatikářského průmyslu (TIA) a rada pro techniku a údržbu (TMC), která patří pod tamní svaz dopravců, dnes místo toho doporučují kontrolu hned v dílně: projet osm až šestnáct kilometrů v ostrých zatáčkách nebo po nerovnostech, případně osmičky, a pak moment přeměřit. Odpadne tím shánění pneuservisu ve dvě ráno. Truck News k tomu ovšem dodává, že kolo namontované podle předpisu, tedy na čisté plochy, s promazanými závity a správným momentem, dotahovat vůbec nepotřebuje.

Ontario odpovědělo na tutéž otázku, jakou položila petice, bez hledání nové součástky: školením montérů, povinným vyšetřováním každého případu a odpovědností, která platí bez ohledu na příčinu. Americký úřad se teď rozhodl neotevírat ani vyšetřování. Nejrozšířenější pojistkou tak zůstává kus plastu, který nedrží nic a jen ukáže, že se matice už pohnula.

Zdroje

• Denial of Motor Vehicle Defect Petition, DP26002, Federal Register, 17. srpna 2026
• How to prevent wheel separations on trucks and trailers, Truck News, 3. února 2026
• Why Do Wheels Come Off Trucks?, Heavy Duty Trucking
• Wheel Safety Information – zprávy ontarijského ministerstva dopravy a Johna Woodrooffa ke stažení

Týden před tím, než Rockstar ukáže hratelnost Grand Theft Auto 6, ji ukázal někdo jiný. Skupina, která si říká CyberLeek, zveřejnila několik videí a obrázek celé mapy a k materiálům přidala manifest: vadí jí, že hra vyjde jen digitálně. Iniciativa, na kterou se přitom odvolává, ji odmítla a varuje hráče, ať jí neposílají peníze.

Co uniklo a proč se tomu věří

Materiály se objevily pár dní před přehlídkou Grand Theft Auto 6: An Extended Look, kterou podle IGN uvede 27. srpna nejdřív Netflix a o šest hodin později ostatní platformy. Hra sama má vyjít 19. listopadu 2026 pro PS5 a Xbox Series X|S.

Rockstar ani Take-Two pravost nepotvrdily. Nepřímý doklad ale existuje: podle serveru Insider Gaming nechává Take-Two videa stahovat z internetu výzvami podle amerického autorského zákona. U doby, kdy jde přesvědčivé záběry ze hry vyrobit umělou inteligencí, je právě tohle nejsilnější náznak, že materiál je pravý – nikdo neposílá právníky na padělek.

Druhá výhrada je věcná. Záběry podle všeho pocházejí ze starší verze hry, odhadem z roku 2024 nebo staršího, takže cokoli v nich je, nemusí být ve výsledné hře. Insider Gaming z nich vypsal ukazatel výdrže, návrat šesté hvězdičky u hledanosti, oddělené výbavy zbraní místo obvyklé plné výzbroje a mapu rozdělenou do pěti okresů. Všechno s tou samou hvězdičkou: je to snímek rozdělané práce, ne seznam funkcí.

Tři přikázání a vodoznak

Na úniku je neobvyklé to, co ho doprovází. Skupina k němu vydala tiskovou zprávu a na vlastním webu tři „přikázání“, která popsal Polygon: neprodávat digitální předobjednávky, neprodávat předstíraná rozšíření pro jednoho hráče a zachovat obsah pro jednoho hráče. Poslední míří na rozhodnutí vydat hru bez disku; skupina píše, že vydavatel pak může hru po konci podpory znepřístupnit.

Stránka „o nás“ končí vzkazem ostatním vydavatelům: chovejte se slušně, nebo budete další na řadě. Záběry nesou vodoznak, že skupina bojuje za práva hráčů, a na třetím klipu, dvakrát delším než předchozí, stojí: žádné fyzické disky? Tak víc pórků. Jméno skupiny je slovní hříčka – anglické leek je pórek a zní stejně jako leak, tedy únik.

Hnutí, na které se odvolávají, je odmítlo

Manifest se dovolává i případu závodní hry The Crew, kterou Ubisoft po vypnutí serverů znemožnil hrát i lidem, kteří si ji koupili. Právě ten případ stál u zrodu iniciativy Stop Killing Games, jež usiluje o přístup ke hrám i po konci oficiální podpory.

Iniciativa se od skupiny distancovala. Používat nezákonné prostředky k prosazení názoru označila za nepřijatelné a dodala, že to nijak nepomáhá chránit právo používat to, za co lidé zaplatili. Vyjádřila se i na stranu zaměstnanců Rockstaru, kterým podobné úniky podle ní ubližují nejvíc.

Nejtvrdší je ale její varování ohledně peněz. CyberLeek prostřednictvím uniklých materiálů propaguje vlastní memecoin a za další obsah si říká o peníze. Iniciativa proto zpochybnila, že jde skupině opravdu o fyzická vydání a o práva zákazníků, a hráče vyzvala, ať jí nic neposílají.

Důvod té rychlosti je politický. Stop Killing Games upozornilo, že podobné incidenty už zaznívají při jednáních se zákonodárci, a spojení hnutí s útoky by jeho snahu o změnu pravidel oslabilo.

Rockstaru to není poprvé

Není to letos první pokus, jak na studio zatlačit. Podle Polygonu dala Rockstaru dřív v roce 2026 ultimátum skupina ShinyHunters: zaplaťte výkupné, nebo data zveřejníme. Studio nezaplatilo, data vyšla a Rockstar později uvedl, že to na hru ani na hráče nemělo vliv.

Rozdíl je v tom, čím se únik zdůvodňuje. Výkupné je otevřené vydírání a nikdo u něj nepředstírá nic jiného. Manifest o právech hráčů si bere zástupnou roli u sporu, který se vede doopravdy a bez něj – a lidé, kteří ten spor vedou, o takovou pomoc nestojí.

Alan Coopersmith z Oraclu oznámil 20. srpna 2026 v e-mailové konferenci xorg balík xorg-server 26.0.99.901, tedy prvního kandidáta na vydání X.Org Serveru 26.1. Poslední řada, která přinesla nové funkce, nese číslo 21.1 a vyšla 27. října 2021.

Den předtím vydal Olivier Fourdan z Red Hatu kandidáta Xwaylandu 26.1. Xwayland je server X, který běží uvnitř waylandového prostředí a obsluhuje programy napsané pro X11. Vydává se samostatně, takže v balíku xorg-serveru není: oznámení říká, že archiv obsahuje všechny zbývající servery mimo Xwayland, jmenovitě Xorg, Xephyr, Xnest, Xvfb, XWin pro Windows a Xquartz pro macOS.

Za pauzou stojí nepořádek v repozitáři

Proč se tak dlouho nevydávalo, popsal Coopersmith v lednu 2026 v konferenci xorg-devel. Hlavní větev master byla podle něj v nepořádku: ležela v ní spousta commitů, které někdo později vrátil zpátky, a přípravy na práci, jež do repozitáře nakonec vůbec nepřišla. Navrhl proto založit novou větev main z bodu okolo února 2024 a přebrat do ní jen ty commity, na kterých se vývojáři shodli.

Čísla z toho dopisu: nová větev měla od výchozího bodu 835 commitů, master jich měl 1 386. Coopersmith z výběru vynechal změny, které byly později vráceny, které nesplnily licenční povinnost uvést copyright a text oprávnění, které rozbily rozhraní používaná jinými projekty, nebo které nadělaly hodně práce s malým užitkem. V témž dopise píše, že plány na řadu 25.1 padly rok předtím právě kvůli tomu nepořádku.

Co se v serveru změnilo od řady 21.1

Seznam z oznámení je krátký a Michael Larabel na Phoronixu k němu podotýká, že X.Org Server 26.1 zdaleka není tak bohatý na novinky jako souběžně vyvíjený Xwayland. Za bezmála pět let se nasbíralo tohle:

• zmizel sestavovací systém autoconf a automake, zůstal jen meson,
• přibyla podpora události DPMSInfoNotify z rozšíření DPMS 1.2,
• přibyla podpora XFixes 6.1 a volba AllowForceTerminate v souboru xorg.conf,
• klienty s opačným pořadím bajtů server ve výchozím nastavení odmítá,
• spojení k font serveru jsou ve výchozím nastavení vypnutá,
• Xorg umí platformu DRM na BSD,
• záznamy běhu Xorgu spuštěného mimo účet správce se přesunuly do adresáře $XDG_STATE_HOME/xorg,
• Xvfb zvládne víc řadičů obrazu (CRTC) a až třináct tlačítek myši,
• přibyly další testy.

Konec autotools slíbilo už oznámení verze 21.1.0 z roku 2021: podpora se v té řadě ještě udrží, ale potom padne. Trvalo to skoro pět let a v kandidátovi to platí.

Klient s opačným pořadím bajtů narazí

Nejméně srozumitelná položka toho seznamu má nejdelší historii. Protokol X11 vznikl v době, kdy běžně existovaly stroje řadící bajty odpředu i odzadu a kdy klient obvykle běžel na jiném počítači než server. Převod mezi oběma pořadími proto dostal na starost server: klient hned prvním bajtem spojení oznámí písmenem l nebo B, jak bajty řadí, a když se to od serveru liší, musí server prohodit každou šestnácti-, dvaatřiceti- a čtyřiašedesátibitovou hodnotu ve všech požadavcích i odpovědích.

Peter Hutterer to v lednu 2023 popsal tak, že seznam bezpečnostních chyb v převodních rutinách je příliš dlouhý na vypisování. Narazit dnes na stroj, který řadí bajty obráceně, je podle něj čím dál větší výjimka, takže ten kód je hlavně útočná plocha, kterou 99 % uživatelů k ničemu nepotřebuje. Sloučil proto do serveru změnu, která takové klienty ve výchozím stavu odmítá, a Fedora si ji vzala jako změnu do verze 38.

Kdo takového klienta potřebuje, spustí server s přepínačem +byteswappedclients; u Xorgu jde totéž zapnout volbou AllowByteSwappedClients v sekci ServerFlags. Hutterer tehdy odhadoval, že to vyjde ve verzi 23.0, „pokud a až k ní dojde“ (přeloženo), protože cyklus vydávání X je nedefinovaný. Do vydání xorg-serveru se to dostává teprve teď, o víc než tři roky později a pod jiným číslem.

Xwayland dostal schránku a zrcadlení vstupních zařízení

Xwayland má proti řadě 24.1 víc změn. Zmizela podpora EGLStream. To je rozšíření EGL, kterým si uzavřený ovladač Nvidie předává obraz místo obecných rozhraní GBM a DMA-BUF, jak je používají ovladače otevřené. Rootful Xwayland, tedy varianta běžící v jednom okně místo splynutí s plochou, dostal most mezi schránkou X a schránkou Waylandu; zapíná se přepínačem -clipboard a bez něj se mezi oběma světy kopírovat nedá.

Wayland umí rozdělit jeden počítač na víc nezávislých pracovišť s vlastní klávesnicí a myší; říká se tomu multiseat. Tahle pracoviště i jejich zařízení se nově zrcadlí do hierarchie XInput 2, takže je vidí i programy pro X. Emulace RandR upřednostní nativní režimy až do fyzického rozlišení a emulované režimy počítají s otočením. Celoobrazovkové okno rootful Xwaylandu se napříště otevře v rozlišení skutečného výstupu místo dosavadního nafouknutého 640×480. Přibyl také zvonek: když to kompozitor umí, zvoní Xwayland přes protokol xdg-system-bell.

Datum ostrého vydání v oznámení není

Obě oznámení mluví o plánu vydání, žádné datum finální verze ale neuvádějí. Coopersmith k tomu radí, aby si testeři server sestavili proti knihovně libpciaccess 0.19 z března 2026, protože nejméně jedna oprava se opírá o rozhraní, které přibylo teprve v ní; meson si přítomnost toho rozhraní ověří sám při sestavení. Chyby se hlásí do sledovače na freedesktop.org.

Zdroje: oznámení xorg-server 26.0.99.901 a xwayland 26.0.99.901 v konferenci xorg, návrh nové větve main v konferenci xorg-devel, oznámení xorg-server 21.1.0, blog Who-T a Phoronix.

Generika dostal jazyk Go ve verzi 1.18 v březnu 2022, ale jen napůl. Vlastní typové parametry směla vyhlásit funkce nebo typ, metoda ne; ta si mohla vzít nanejvýš parametry svého příjemce. Kdo potřeboval metodu pracující s libovolným celočíselným typem, napsal ji zvlášť pro každý z nich, nebo místo metody sáhl po samostatné generické funkci. Verze 1.27, vydaná 19. srpna 2026 půl roku po 1.26, to mění.

Metoda si smí říct o vlastní typ

Deklarace metody teď přijímá typové parametry stejně jako deklarace funkce. Ukázkou je standardní balíček math/rand/v2, kde tři metody nahradila jedna:

// do Go 1.26
func (r *Rand) Int32N(n int32) int32
func (r *Rand) Int64N(n int64) int64
func (r *Rand) IntN(n int) int

// Go 1.27
func (r *Rand) N[Int intType](n Int) Int

Nejde jen o počet řádků. Metoda patří do jmenného prostoru svého typu, takže se řetězí zleva doprava jako x.a().b().c(); u funkcí se totéž zapíše c(b(a(x))) a čte se zevnitř ven. Autor návrhu Robert Griesemer tenhle zápis uvádí jako jeden ze dvou důvodů, proč o generické metody uživatelé dlouho žádali. Druhým je prosté třídění kódu podle typu, ke kterému patří.

Odpovědi na časté dotazy pořád tvrdí opak

Ve stránce častých dotazů na go.dev stálo 20. srpna 2026 dál, že tvůrci nepředpokládají, že by Go generické metody kdy přidalo (přeloženo z angličtiny). Následuje vysvětlení, které je samo o sobě zajímavé.

Potíž byla v rozhraních. Go po typu nechce, aby deklaroval, která rozhraní splňuje. Návrh tomu říká dynamická vlastnost: shoda se ukáže i za běhu, třeba při typové aserci. Kdyby metoda s typovým parametrem směla splnit metodu rozhraní, musel by překladač předem připravit kód pro nekonečně mnoho možných instancí. Dokumentace probírá čtyři východiska a všechna zamítá. To čtvrté zní, že generické metody nesmí splňovat rozhraní vůbec, a stránka ho označuje za návrhově nepřijatelné.

Přijatý návrh #77273 vzal právě tuhle čtvrtou možnost. Griesemer v něm nemění implementaci, mění pohled: metoda není jen nástroj k naplnění rozhraní, je to funkce navěšená na typ. Metoda rozhraní typové parametry syntakticky mít nesmí, takže generická konkrétní metoda proti ní nemá co srovnávat – a otázka nekonečně mnoha instancí odpadá sama. Návrh nese značku Proposal-Accepted a milník Go1.27. Starší žádost o totéž z října 2021 měla podle jeho textu přes devět set kladných reakcí.

Co generická metoda neumí

Omezení jsou dvě a návrh je píše natvrdo. Rozhraní u svých metod typové parametry nadále mít nemůže, takže generickou metodou se rozhraní nesplní. A přes balíček reflect se ke generické metodě nedostanete – ze stejného důvodu, z jakého se přes něj nedá sáhnout na neinstanciovanou generickou funkci.

Struktury a odvozování typů

Jazyk se mění ještě na dvou dalších místech. Klíčem v literálu struktury smí být libovolný platný selektor pole, ne jen jméno pole nejvyšší úrovně. Pole vnořené nebo vložené struktury se tak nastaví rovnou:

type Habitat struct {
	Burrow string
}

type Gopher struct {
	Name string
	Habitat // vložená struktura
}

g := Gopher{
	Name:   "Gopher",
	Burrow: "Burrow #42",
}

Druhá změna se týká odvozování typu funkce. Nově platí ve všech situacích, kdy se generická funkce přiřadí do proměnné odpovídajícího funkčního typu nebo se na něj převede.

JSON, postkvantové podpisy a UUID

Ve standardní knihovně přibyl encoding/json/v2, velká revize práce s JSONem, a k němu encoding/json/jsontext na nižší, syntaktickou vrstvu. Dvojka má přísnější výchozí nastavení: odmítne neplatné UTF-8 v řetězcích a dvakrát použité jméno v jednom objektu. Starý balíček encoding/json teď stojí na implementaci dvojky, chování si podle poznámek k vydání zachoval a liší se jen znění chybových hlášek. Čtení JSONu je citelně rychlejší, zápis zůstal zhruba na stejné úrovni. Komu nová implementace něco rozbije, vrátí se k původní přes GOEXPERIMENT=nojsonv2.

Balíček crypto/mldsa přináší postkvantové podpisové schéma ML-DSA podle normy FIPS 204. Umí ho i crypto/x509 a crypto/tls, kde v TLS 1.3 přibyly hodnoty MLDSA44, MLDSA65 a MLDSA87. Nový je taky balíček uuid na tvorbu a čtení identifikátorů UUID a experimentální simd pro vektorové instrukce. Jeho architekturní část simd/archsimd podle Phoronixu přepracovala rozhraní pro AMD64 a přidala 128bitové Arm Neon a WebAssembly.

Alokace, zablokované gorutiny a dvě odstraněné věci

Překladač nově volá alokační rutiny specializované podle velikosti. U objektů pod 80 bajty to zlevňuje alokaci až o 30 %; u programů, které hodně alokují, čeká tým jazyka celkové zrychlení kolem 1 %. Binárka se tím zvětší asi o 60 kB bez ohledu na to, co dělá. Vypnout to jde přes GOEXPERIMENT=nosizespecializedmalloc, jenže jen dočasně – vypínač má v Go 1.28 zmizet.

Profil goroutineleak, v Go 1.26 ještě experiment, je teď běžně dostupný v runtime/pprof i jako koncový bod /debug/pprof/goroutineleak. Hledá gorutiny zablokované na kanálu nebo zámku, který už nemá jak je pustit dál: běhové prostředí se k tomu opře o garbage collector a ptá se, jestli je ta synchronizační primitiva vůbec dosažitelná z něčeho běžícího. Úplný nález to není. Když je ta primitiva dosažitelná z globální proměnné nebo z lokálních proměnných běžících gorutin, únik zůstane neodhalený. Práci přispěl Vlad Saioc z Uberu.

Dvě věci naopak ubyly. Příkaz go už nepodporuje verzovací systém bzr, takže moduly hostované na bzr serverech si sám nestáhne. A nastavení asynctimerchan, přidané v Go 1.23, zmizelo natrvalo: kanály z balíčku time jsou od 1.27 vždy nebufferované, ať si do GODEBUG napíšete cokoli.

Co zbývá

Stránka častých dotazů zatím pořád vysvětluje, proč generické metody nebudou. Tým jazyka slíbil k tématům z 1.27 v následujících týdnech samostatné texty, takže na podrobnosti o JSONu i o vektorových instrukcích ještě dojde.

Zdroje: Go 1.27 is released a Go 1.27 Release Notes na go.dev, návrh golang/go#77273, Go FAQ, Phoronix.

Před zhruba 56 miliony let se do ovzduší dostalo obrovské množství uhlíku a planeta se prudce oteplila. Tomu období se říká paleocenně-eocenní teplotní maximum, zkratkou PETM, a geologové ho berou jako nejbližší přírodní obdobu toho, co se děje dnes. Co se při něm stalo s lesy, se ale vědělo jen přibližně: měnila se skladba druhů. Práce zveřejněná 13. srpna 2026 v časopise Science k tomu přidává veličiny, které se z fosilií čtou těžko – jak hustou měl les korunu a jak rychle o ni přišel.

Tvar buněk pod slupkou listu řekne, kolik bylo stínu

Rostliny si na povrchu listu drží kutikulu, tenkou voskovou slupku. Ta v sedimentu bohatém na organickou hmotu vydrží miliony let a zůstává na ní otisk pokožkových buněk. Jejich tvar závisí na tom, kolik světla list za růstu dostával: ve stínu se buňky protahují, na plném slunci zůstávají kratší a oblejší.

Tým z toho udělal měřidlo. Nejdřív nasbíral půdu v dnešních lesích Střední a Jižní Ameriky, od hustých po prosvětlené, a ke každé změřil index listové plochy. Je to v ekologii běžný údaj a říká, kolik metrů čtverečních listů připadá na metr čtvereční země. Čím víc vrstev listí nad hlavou, tím vyšší číslo. Porovnání tisíců buněk s naměřeným indexem dalo silný vztah: čím protáhlejší buňky, tím hustší koruna nad nimi.

Stejnou drť listů obsahuje i fosilní záznam, takže šlo měřidlo obrátit do minulosti. Vzorky pocházejí z vrtných jader z pánve Hanna v jižním Wyomingu; jádra vytáhli pracovníci Americké geologické služby. Skladbu rostlinstva k tomu tým doplnil z palynomorfů, tedy z pylu a spor.

Koruna se nejdřív zavřela, pak se propadla

Nejméně čekaný je začátek. Těsně před nástupem oteplování byl zápoj nejhustší za stovky tisíc let. Sedí to s tím, že oxid uhličitý už stoupal a rostlinám to zatím prospívalo.

Pak to teplo a sucho přebily. Podle zpravodajství časopisu Nature klesl index listové plochy během následujících několika tisíc let o 61 procent a pak zůstal o 35 procent pod původní hodnotou po desítky tisíc let, až do konce PETM. Doprovodný text k práci na serveru The Conversation uvádí ztrátu zaokrouhlenou na 60 procent a dobu návratu jako víc než sto tisíc let.

U samotného oteplení se prameny rozcházejí víc. Redakční shrnutí Science i zpráva v Nature mluví o 5 až 9 stupních Celsia globálně, kdežto populární text týmu uvádí nanejvýš 6 stupňů. Rozdíl není v měření lesa, ale v tom, který odhad PETM si který text vybral; nižší číslo leží uvnitř toho širšího rozpětí.

Měnila se i skladba. Široce listnaté krytosemenné rostliny, tedy příbuzní jilmů, ořešáků, metasekvoje nebo avokáda, ustoupily kapradinám. Po nich se do těchto šířek rozšířily palmy a další teplomilné druhy.

S otevřeným zápojem se rozmyla i krajina

Změna se nezastavila u rostlin. Ve vrstvách nad hranicí PETM střídá dávné půdy hrubší říční materiál, tedy stopa po tom, že se v pánvi začalo pohybovat víc sedimentu. Autoři to čtou tak, že rozevřená koruna změnila hospodaření s vodou i erozi: méně stínu znamená vyšší teplotu u země, jiný odtok a méně zadrženého materiálu.

Vlastní měření pokrývá jednu pánev. Širší dosah mu podle abstraktu práce dává až spojení s regionálními daty. Teprve dohromady z toho vychází, že změny rostlinstva v měřítku kontinentu dokážou krajinu destabilizovat.

Co z toho platí pro dnešek

Uhlík tehdy dodala nejspíš rozsáhlá sopečná činnost v sedimentech bohatých na uhlík na severu Atlantiku. Jeho objem odpovídá zhruba tomu, kolik by lidstvo vypustilo do konce jednadvacátého století v pesimistickém scénáři. Rozdíl je v tempu: dnešní emise jdou do ovzduší asi desetkrát rychleji než tehdejší přírodní pochody.

Praktický závěr je proto užší, než by se z přirovnání čekalo. Vyšší obsah oxidu uhličitého rostlinám opravdu pomáhá, ale jen dokud teplota a dostupná voda zůstanou v mezích, které stromy snesou. Za nimi hnojivý účinek přebijí horko, sucho, hmyz, patogeny a požáry – a les se otevře.

Lesy se nakonec vrátily, dokonce hustší než před oteplením. Zvětrávání hornin v teplejším podnebí postupně stáhlo uhlík do mořských sedimentů, podnebí se ochladilo a vody přibylo. Jenže to celé trvalo déle než sto tisíc let a podnebí zůstalo změněné přes sto padesát tisíc let. Fosilní záznam tedy není zprávou o tom, že se les spraví sám, ale o tom, za jak dlouho.

Firma Modular zveřejnila 18. srpna 2026 zdrojový kód překladače programovacího jazyka Mojo. Do té chvíle byla veřejná jen standardní knihovna jazyka, samotný překladač zůstával uzavřený, přestože jazyk vznikal v otevřené komunitě čtyři roky. Kód je v repozitáři modular/modular na GitHubu, licence je Apache 2.0 s výjimkami LLVM.

Oznámení padlo na firemní konferenci ModCon, týden po vydání verze Mojo 1.0 z 11. srpna a necelý měsíc po tom, co Modular převzal Qualcomm.

Co v repozitáři přibylo

Vedle knihoven, které tam byly dřív, je v něm nově adresář KGEN se samotným překladačem a nástroje kolem něj: jazykový server pro editory, testy a stavební soubory pro Bazel. Modular v oznámení uvádí i postup, jak si překladač přeložit ze zdroje:

git clone https://github.com/modular/modular.git
cd modular
./bazelw run --config=build-mojo KGEN:mojo -- run hello.mojo

Kdo na překladači sám pracovat nechce, může přepínač vyměnit za --config=prebuilt-mojo; stavební systém si pak stáhne hotovou noční binárku a překlad překladače odpadne.

Co ta licence umí

Apache 2.0 je permisivní licence: kód se smí použít i v uzavřeném produktu, podmínkou je zachovat oznámení o autorství a licenci. Výjimky LLVM, které si Modular vypůjčil od stejnojmenného projektu, tuhle podmínku dál uvolňují ve dvou bodech.

První se týká binárek. Když se při překladu dostanou části licencovaného softwaru do výsledného programu, nemusí je jeho autor při šíření doprovázet licenčním textem ani seznamem změn. To je pro překladač podstatné: bez téhle výjimky by se povinnosti z licence přenášely na každý program, který jím projde. Druhý bod řeší střet s GPLv2 – kdyby soud shledal, že patentové nebo odškodňovací ustanovení Apache 2.0 odporuje podmínkám GPLv2, lze je u kombinovaného díla považovat za prominuté.

Čím Mojo je

Mojo je systémový jazyk pro psaní výpočetního kódu na různý hardware – procesory, grafické karty i akcelerátory pro AI. Syntaxí je blízký Pythonu a umí ho volat, opačným směrem to funguje také. Stojí za ním Chris Lattner, autor LLVM a překladače Clang a spoluautor Swiftu; první veřejné vydání Mojo je z roku 2023.

Verze 1.0 z 11. srpna neslibuje nové vlastnosti, ale stabilitu: v řadě 1.x mají být změny především přidávající, aby se nad jazykem dalo stavět déle než jedno vydání. Poslední kolo úklidu před ní sjednotilo místa, kde šla jedna věc zapsat víc způsoby – proměnné se deklarují jedině přes var, ukazatel má jediný typ, uzávěry mají jednotný tvar. Přibyl zápis lambda funkce po vzoru Pythonu a překladač nově hlásí zneplatněné reference, tedy třeba to, že List.append zruší platnost odkazu dovnitř seznamu.

Od otevření standardní knihovny v roce 2024 do ní podle Modularu přispělo skoro dvě stě lidí, kteří poslali přes 1 100 pull requestů a změnili víc než 200 000 řádků kódu.

Otevřený kód ještě není otevřený vývoj

Příspěvky do překladače a nástrojů Modular zatím nepřijímá. V oznámení píše, že na ně není připravený a chce s nimi začít do konce roku; jako důvod uvádí právě dobu, kdy kód píše umělá inteligence, a potřebu mít předem rozmyšleno, jak se s takovými příspěvky zachází.

Repozitář na to má vlastní pravidla v souboru AI_TOOL_POLICY.md. Příspěvek, který vznikl s pomocí AI, se má označit patičkou Assisted-by: v commitu nebo v popisu pull requestu. Ten popis musí napsat člověk. Pull requesty mají být malé, protože AI podle Modularu snižuje cenu psaní kódu, ne cenu jeho revize. Plná automatizace bez lidské kontroly povolená není.

Podobná pravidla si letos zavedla řada projektů, každý ale jinak přísná: GCC odmítá příspěvky od jazykových modelů zhruba od patnácti řádků.

Qualcomm a co bude dál

Qualcomm oznámil koupi Modularu 24. června 2026 a dokončil ji 29. července. V tiskové zprávě stojí, že Mojo, MAX a Modular Cloud zůstávají samostatnými produkty a značkami a že Chris Lattner nastoupil na místo výkonného viceprezidenta pro pokročilý software a platformy pro AI.

Na téže konferenci Modular ohlásil, že Mojo dostane nativní podporu Windows, na které pracuje společně s týmem Windows u Microsoftu. Dosud jazyk běžel na Linuxu a macOS a na Windows se používal přes WSL.

Zdroje: Modular: Mojo is now open source!, Modular: ModCon 2026, Modular 26.5: Mojo 1.0 is here!, Qualcomm Completes Acquisition of Modular, Phoronix, soubor LICENSE v repozitáři modular/modular.

Mozilla vydala Firefox 154 18. srpna 2026. Mezi novinkami je jedna věta, kterou si přečtou hlavně vývojáři: ochrana místní sítě se nově vztahuje i na WebSockety. Stránka, která zkusí otevřít WebSocket na zařízení v lokální síti, se musí nejdřív zeptat uživatele.

Tři adresní prostory a dvě oprávnění

Ochrana se jmenuje Local Network Access, zkratkou LNA, a vzniká jako specifikace ve skupině WICG. Dělí cílové adresy do tří skupin. Public je běžná adresa na internetu. Local je adresa dosažitelná jen v místní síti, typicky 192.168.0.1 nebo jméno končící na .local. Loopback je samotný počítač, tedy 127.0.0.1 a localhost. Míří-li požadavek z veřejné stránky do některé z těch dvou soukromějších skupin, prohlížeč se ptá.

Oprávnění jsou podle dokumentace na MDN dvě: local-network a loopback-network. Původní jednotné local-network-access zůstává jako alias kvůli zpětné slučitelnosti, ale výsledek dotazu na jeho stav je jen složenina obou novějších – stačí, aby uživatel jedno z nich zakázal, a alias hlásí zákaz taky. Požádat o oprávnění smí jen stránka v zabezpečeném kontextu; z HTTP stránky požadavek do místní sítě selže bez ptaní.

Odkud se ta ochrana vzala

Důvod je starší než specifikace. Cizí stránka mohla dosud tiše sáhnout na router ve stejné síti a přepsat mu třeba adresu DNS serveru, takže dotazy uživatele odpovídá server, který si vybral útočník. MDN k tomu dodává, že útoku nahrává, jak často zůstává u domácích zařízení výchozí heslo správce. Stejným způsobem šlo vyměnit firmware routeru nebo odklonit reklamní provoz.

Druhý důvod ukázal v červnu 2025 výzkum Local Mess. Skripty Meta Pixel a Yandex Metrica na tisících webů posílaly data na pevné porty localhostu a tam je poslouchaly nativní aplikace Facebooku, Instagramu, Yandex Map a Yandex Browseru na témž telefonu s Androidem. Webová cookie _fbp se tím propojila s trvalou identitou uživatele v aplikaci, a to bez ohledu na mazání cookies i na anonymní režim. Meta podle autorů výzkumu praktiku zastavila 3. června 2025, Yandex rovněž. Šlo přitom o WebRTC a o obyčejné HTTP, ne o WebSockety; společné je jen to, že prohlížeč pustil skript na loopback bez jediné otázky. Odbornou práci pod názvem Bridges to Self mají autoři podle vlastní stránky vydat na 35. sympoziu USENIX Security.

Implementaci v prohlížeči Firefox představil na FOSDEM 2026 Sunil Mayya z týmu, který má v Mozille na starost síťovou vrstvu. Postup práce je vidět v záznamu 1481298 v Bugzille.

Co se změní vývojáři pod rukama

Nejvíc to pocítí weby, které mluví s programem běžícím na počítači uživatele – čtečky karet, tiskové utility, přihlašovací klienti, ladicí server během vývoje. Nově jim před prvním spojením vyskočí dialog, a když uživatel odmítne, spojení neproběhne.

Udělené oprávnění zároveň uvolní kontrolu smíšeného obsahu, protože místní zařízení si veřejně důvěryhodný certifikát obvykle opatřit nedokáže. Automaticky to platí u zapsané soukromé IP adresy a u jmen na .local. Když ale veřejné jméno teprve po překladu skončí na místní adrese, musí to skript prohlížeči říct sám vlastností targetAddressSpace:

fetch("http://internal.example.com/status", {
  targetAddressSpace: "loopback",
});

Druhá past číhá u rámů. Směrnice local-network a loopback-network v hlavičce Permissions-Policy mají výchozí seznam self, takže vložený dokument z cizího původu se do místní sítě nedostane, dokud mu to stránka výslovně nedovolí v atributu allow. A dovolit to musí každému původu, přes který rám během práce projde – u přihlašovacích řetězců se snadno zapomene na ten prostřední.

Firefox to zapínal po kouskách, Chrome byl dřív

Mozilla ochranu nasazovala po etapách. Firefox 147 ji 13. ledna 2026 zapnul ve výchozím stavu jen lidem, kteří mají přísný režim ochrany před sledováním. Verze 151 ji 19. května začala rozdávat všem, verze 153 ji 21. července prohlásila za výchozí a verze 154 k ní teď přidala WebSockety.

Google byl napřed. Dialog o svolení Chrome zavedl ve verzi 142, která se do stabilní větve dostala 22. října 2025. Podle záznamu na Chrome Platform Status pak verze 145 rozdělila jedno oprávnění na dvě, verze 146 přidala dvě podnikové zásady a verze 147 – stabilní od 25. března 2026 – rozšířila omezení na WebSockety a WebTransport. Firefox tedy WebSockety uzavřel zhruba pět měsíců po konkurenci.

Hotové to není ani teď. Specifikace počítá vedle podřízených požadavků a WebSocketů i s WebTransportem a s WebRTC, jenže poznámky k vydání Firefoxu 154 se o těch dvou nezmiňují. A LNA je pořád jen inkubovaný návrh ve WICG, ne dokončený standard – což je u věci, kterou už dva velké prohlížeče vynucují ve výchozím nastavení, poněkud obrácené pořadí.

Zdroje

• Poznámky k vydání Firefoxu 154, Mozilla, 18. srpna 2026
• Local network access, MDN Web Docs
• Local Network Access, specifikace WICG
• Local network access restrictions, Chrome Platform Status
• Covert Web-to-App Tracking via Localhost on Android, Local Mess, červen 2025

Americká agentura CISA přidala 17. srpna 2026 do katalogu známých zneužívaných zranitelností jedinou položku, chybu CVE-2025-62593 ve frameworku Ray. Ray je výpočetní engine pro umělou inteligenci: rozděluje trénování a obsluhu modelů mezi mnoho strojů a jeho repozitář má přes 43 tisíc hvězd. Federální úřady dostaly na vyřízení tři dny, do 20. srpna.

Zajímavější než lhůta je ale to, co chybu roky drželo pod pokličkou. Jediné, co bránilo cizí webové stránce spustit na vývojářově počítači libovolný příkaz, bylo jméno prohlížeče v hlavičce požadavku.

Ovládací panel Ray spouští kód a nikoho se neptá

Ray má webový panel, který mimo jiné nabízí rozhraní /api/jobs/. Poslat mu úlohu znamená nechat na clusteru spustit příkaz, a žádné přihlášení k tomu nikdy potřeba nebylo. Tvůrci to nepovažovali za vadu: podle nich se Ray provozuje v uzavřené síti, kam se nikdo nepovolaný nedostane.

Aby se k tomu rozhraní nedostala webová stránka otevřená na témže počítači, přibyl v panelu jednoduchý filtr. Požadavky metodami POST a PUT se zahodí, pokud hlavička User-Agent začíná řetězcem Mozilla, protože tak se hlásí každý běžný prohlížeč. Komentář v kódu si přitom byl vědom, na jak tenkém ledě stojí. Volně přeloženo: tahle heuristika je hodně slabá, ale prohlížeč ji obejde těžko, protože fetch a spřízněná rozhraní User-Agent změnit neumějí.

Ta druhá polovina věty neplatí. Specifikace fetch přepsání hlavičky User-Agent dovoluje a Firefox se Safari se jí drží. Chrome zranitelný podle oznámení projektu není, ale jen shodou okolností: vlastní chybou se od specifikace odchyluje a hlavičku přepsat nenechá.

DNS rebinding dostane cizí stránku na místní adresu

Samotné přepsání hlavičky útočníkovi nestačí. Prohlížeč hlídá pravidlo stejného původu: stránka ze serveru útočníka nesmí číst odpovědi z adresy 127.0.0.1:8265, kde panel Ray poslouchá. Tuhle zeď obchází DNS rebinding.

Funguje na jednoduchém principu. Útočníkova doména se poprvé přeloží na jeho vlastní server, odkud si prohlížeč stáhne stránku se skriptem. Záznam má ale nastavenou velmi krátkou dobu platnosti, takže se za pár vteřin přeloží znovu, tentokrát na 127.0.0.1. Prohlížeč pořád vidí tutéž doménu, a tedy tentýž původ, jenže požadavky už míří na místní port. Oznámení uvádí, že si s tím poradí běžně dostupný nástroj, konkrétně jmenuje singularity od NCC Group.

Zbytek je krátký. Skript pošle na /api/jobs/ úlohu s vlastní hlavičkou User-Agent, filtr ji propustí a Ray příkaz spustí. Ukázka útoku přiložená k oznámení jen otevře kalkulačku, aby bylo vidět, že kód opravdu běží. Autoři popisují i druhé využití: prohlížeč vývojáře se dá stejným způsobem použít jako prostředník k útoku na instance Ray uvnitř firemní sítě, kam se útočník zvenčí nedostane.

Záplata sáhla po hlavičkách, které skript nastavit nesmí

Oprava dorazila v commitu nazvaném Add denial of fetch headers. Přidává funkci has_sec_fetch_headers(), která hledá kteroukoli z hlaviček Sec-Fetch-Mode, Sec-Fetch-Dest, Sec-Fetch-Site a Sec-Fetch-User. Prohlížeče je posílají u každého požadavku a skript s nimi nic nesvede: názvy začínající na Sec- patří mezi zakázané hlavičky, které rozhraní fetch nastavit odmítne.

def has_sec_fetch_headers(req: Request) -> bool:
    """Checks for the existance of any of the sec-fetch-* headers"""
    return any(
        h in req.headers
        for h in (
            "Sec-Fetch-Mode",
            "Sec-Fetch-Dest",
            "Sec-Fetch-Site",
            "Sec-Fetch-User",
        )
    )

Rozdíl proti původnímu stavu je v tom, o čem rozhoduje útočník. Dřív se odmítnutí odvíjelo od řetězce, který si volající píše sám. Nově stačí, aby požadavek nesl stopu prohlížeče, kterou prohlížeč připojuje bez ohledu na to, co si přeje stránka. Součástí commitu je i test, který se pokusí spustit úlohu s vymyšleným User-Agentem a hlavičkou Sec-Fetch-Site a čeká, že ho panel odmítne.

Ray počítá s tím, že síť je bezpečná

Bezpečnostní kapitola dokumentace je v tomhle otevřená. Volně přeloženo z ní plyne, že Ray poslušně vykoná kód, který dostane, a nerozlišuje mezi laděním modelu, instalací rootkitu a průzkumem úložiště S3. Izolaci má podle ní zajistit okolí clusteru, ne cluster sám.

Ze stejné úvahy vychází i to, že starší CVE-2023-48022, popisující spuštění kódu přes rozhraní pro odesílání úloh, je v databázi NVD vedené jako sporné. Stanovisko výrobce tam stojí černé na bílém: hlášení je podle něj bezpředmětné, protože dokumentace uzavřenou síť vyžaduje. Útok přes prohlížeč tuhle obranu obchází z druhé strany, protože uzavřenou sítí je v tomhle případě vývojářův vlastní notebook.

Vydání Ray 2.52.0 z 21. listopadu 2025, které chybu opravilo, přineslo zároveň vestavěné ověřování tokenem napříč panelem, příkazovou řádkou, klienty rozhraní i vnitřními službami. Dokumentace ho popisuje jako vrstvu navíc, ne jako náhradu síťové izolace.

Mezi opravou a zápisem do katalogu uplynulo devět měsíců

Časová osa je poučná sama o sobě. Opravená verze vyšla 21. listopadu 2025, oznámení projektu a záznam v NVD o pět dní později, zápis do katalogu CISA až 17. srpna 2026.

Co přesně agenturu k zápisu vedlo, se ze záznamu nedozvíte. Poznámky u položky odkazují jen na oznámení projektu, opravný commit, směrnici BOD 26-04 a záznam v NVD, tedy na nic, co by zneužití dokládalo. Pole o využití při vydírání je vyplněné hodnotou Unknown.

Rozcházejí se i známky závažnosti. NVD dává 8,8 bodu podle metriky CVSS ve verzi 3.1 a chybu řadí jako vysokou, GitHub 9,4 bodu podle verze 4.0 a řadí ji jako kritickou. Není to spor o fakta, ale rozdíl mezi dvěma vydáními téže stupnice; verze 4.0 započítává i dopad na okolní systém, což u útoku mířícího na pracovní stroj vývojáře přirozeně vyjde hůř.

Praktický závěr je nepříjemně obecný. Kontrola hlavičky User-Agent není bezpečnostní hranicí nikde, ne jenom v Ray, a vývojářských nástrojů, které si na místním portu otevřou rozhraní bez hesla a spoléhají na to, že jsou přece jenom na localhostu, je celá řada. Prohlížeč otevřený na témže stroji je od nich vzdálený jednu krátkou dobu platnosti záznamu DNS.

Kritický neznamená nebezpečný

Dozorný úřad k tomu přidal vysvětlení, které v tiskových zprávách většinou chybí. Slovo „kritický“ v jaderné energetice neoznačuje havarijní ani nebezpečný stav. Je to přesně definovaný fyzikální stav, ve kterém se v aktivní zóně poprvé vytvoří a udrží štěpná řetězová reakce a výkon reaktoru za nezměněných podmínek zůstává stabilní. Bez něj se reaktor rozběhnout nedá.

Minimální kontrolovaný výkon je pak nejnižší stanovená úroveň výkonu, při které jde reakci stabilně řídit a zároveň provádět předepsaná měření a zkoušky aktivní zóny. Elektřinu blok při ní ještě nevyrábí.

Palivo přišlo do reaktoru na konci června

Povolení uvádět blok do provozu vydal úřad rozhodnutím č. 229/2026 z 22. května 2026. Zavážení paliva pak začalo 29. června v 16:04 první kazetou – tím se čtvrtý blok formálně stal jaderným zařízením – a skončilo v pátek 3. července. Do aktivní zóny se dostalo 349 kazet, z toho 312 palivových a 37 regulačních, dohromady zhruba 42 tun paliva.

Palivem reaktorů VVER-440 je oxid uraničitý obohacený izotopem uranu 235 do pěti procent. Má podobu keramických tablet o hmotnosti kolem pěti gramů, které jsou uložené v palivových proutcích; sto dvacet šest proutků tvoří jednu šestihrannou kazetu se zhruba 120 kilogramy paliva. Kazeta zůstává v aktivní zóně přibližně pět let a při každoroční plánované odstávce se vymění asi pětina paliva, tedy kolem osmi tun.

Montáž reaktoru a hermetické uzavření reaktorové nádoby ohlásil provozovatel 20. července. Následovaly pevnostní a těsnostní zkoušky a předkritické testy – tedy poslední krok před tím, čeho blok dosáhl 6. srpna.

Do sítě to má být na konci léta

Teď přijdou na řadu fyzikální zkoušky, při kterých se ověřují neutronově-fyzikální charakteristiky aktivní zóny a chování regulačních a ochranných systémů. Po nich energetické spouštění: výkon se zvyšuje po stupních a na každé hladině se kontroluje, že se všechno chová podle předpokladů. Celý postup vrcholí 144hodinovou zkouškou na plném výkonu.

„Dosažení kritického stavu a minimálního kontrolovaného výkonu je výsledkem práce tisíců odborníků, kteří se podíleli na přípravě, výstavbě, kontrole a spouštění čtvrtého bloku,“ uvedl ředitel projektu Mochovce Martin Mráz. Podle provozovatele by první megawatthodiny měl blok dodat do sítě po přifázování turbogenerátoru na konci léta 2026, pokud spouštění půjde podle harmonogramu. Průběh a vyhodnocení zkoušek kontroluje dozor svými inspekcemi.

Stavba, která trvá čtyřicet let

Na prvních dvou blocích Mochovců se začalo stavět v roce 1982, na třetím a čtvrtém v roce 1986. V roce 1992 se práce zastavily. První dva reaktory šly do provozu v letech 1998 a 1999, dostavba zbývající dvojice se rozjela až o deset let později s odhadovanými náklady 6,7 miliardy eur. Třetí blok vstoupil do komerčního provozu v říjnu 2023, čtvrtý tedy dokončuje projekt bezmála čtyřicet let po prvním výkopu.

Instalovaný výkon čtvrtého bloku je 471 MW a podle provozovatele pokryje asi 13 % slovenské spotřeby elektřiny. Po jeho spuštění má jaderná energie krýt zhruba 77,5 % spotřeby země – to je údaj Slovenských elektráren, které k němu dodávají, že by tím Slovensko předstihlo i Francii se zhruba 67 %. Slovensko dnes provozuje pět jaderných bloků, které dodávají kolem poloviny jeho elektřiny; kromě Mochovců jsou to dva bloky v Jaslovských Bohunicích z let 1984 a 1985.

Slovenské elektrárne mají dva akcionáře: 66 % drží Slovak Power Holding, který vlastní česká skupina Energetický a průmyslový holding, zbylých 34 % patří Slovenské republice.

Mezi kritickým stavem a komerčním provozem přitom leží ještě celá řada zkoušek na postupně zvyšovaném výkonu. Datum, kdy čtyřka poprvé pošle proud do sítě, je zatím plán provozovatele, ne splněný milník – a pozná se spíš podle toho, jak rychle dozor odbaví jednotlivé výkonové hladiny, než podle kalendáře.

Zdroje

• Slovenské elektrárne oživili reaktor 4. bloku Jadrovej elektrárne Mochovce (tisková zpráva, 7. srpna 2026)
• Postup v uvádzaní 4. bloku jadrovej elektrárne Mochovce do prevádzky (Úrad jadrového dozoru SR, 7. srpna 2026)
• Mochovce 4: Do reaktora sme zaviezli všetkých 349 palivových kaziet (tisková zpráva, 4. července 2026)
• Slovenské elektrárne dokončili montáž reaktora Mochoviec 4 (tisková zpráva, 20. července 2026)
• First criticality for Mochovce 4 (World Nuclear News, 10. srpna 2026)
• Slovakia's Mochovce-4 Nuclear Power Plant Reaches First Criticality (NucNet, 7. srpna 2026)

Český web o kosmonautice Kosmonautix má v hlavní nabídce novou položku Statistiky. Neskrývá se za ní jedna tabulka, ale tři nástroje: přehled startů s filtry, porovnávač dvou položek vedle sebe a informační profil jedné rakety, lodi nebo firmy. Rozsah sahá až k roku 1957, tedy k prvnímu Sputniku.

Přehled za zvolené období

Výchozí pohled ukazuje jeden rok. K 17. srpnu 2026 v něm stálo 194 orbitálních a šest suborbitálních startů, dohromady dvě stě misí. Úspěšných z nich bylo 193, tedy 96,50 %, a sedm neúspěšných – u toho čísla stránka výslovně uvádí, že do něj počítá i částečná selhání. Startovalo se ze 46 různých ramp.

Pod souhrnem jsou dva rozpady. Podle cílové dráhy vede nízká oběžná dráha se 122 starty (61 %), následuje heliosynchronní dráha s 29 a polární se 17; na konci žebříčku stojí jediný průlet kolem Měsíce. Podle země provozovatele mají Spojené státy 122 startů, Čína 58, Rusko jedenáct, Japonsko a Francie po třech, Indie dva a Itálie jeden. Dělí se tedy podle provozovatele, ne podle kosmodromu, což je u evropských nosičů rozdíl, na který je dobré myslet.

Pod tím je výpis jednotlivých misí. U každé je datum i s časem, raketa, cílová dráha, místo startu a výsledek; u Falconů 9 navíc označení konkrétního prvního stupně, takže z výpisu jde vyčíst, který kus letěl pokolikáté.

Porovnávač staví dvě položky proti sobě

Druhá záložka srovnává vždy dvojici stejného typu. Na výběr je pět kategorií: firmy a agentury, konkrétní rakety, skupiny kosmických lodí, konkrétní lodě a rodiny prvních stupňů. Lepší číselná hodnota se v tabulce označí zeleně, takže srovnání se dá přečíst bez počítání.

Třetí záložka je profil jedné položky – firmy, agentury, rakety nebo lodi – vyhledávaný našeptávačem. Zajímavější než sám profil je věta, kterou u něj web uvádí: nedoložené hodnoty nezobrazuje ani neodhaduje. U přehledů, které se plní automaticky, je to slib, který se dělá nerad, protože kvůli němu zůstávají v tabulkách prázdná místa.

Data jedou z TheSpaceDevs

Odkud čísla pocházejí, stránka neschovává. V patičce stojí, že běží díky projektu TheSpaceDevs, a porovnávač to upřesňuje: provozní data jsou z LL2, chybějící popisy a technické údaje se doplňují z Wikimedia a Wikidat.

TheSpaceDevs je skupina vývojářů nadšených do kosmonautiky, která provozuje veřejná a bezplatná rozhraní s daty o letech; Launch Library 2 je to jejich nejznámější. Stojí za tím řada aplikací a odpočtů, které lidé znají, aniž by tušili, odkud berou čísla.

Pro čtenáře to znamená dvě věci. Statistiky se aktualizují samy, takže po každém startu není potřeba čekat, až je někdo ručně přepíše. Zároveň platí, že přesnost je přesně taková, jakou má zdroj – co je špatně v LL2, bude špatně i tady, a u čerstvých startů se hodnoty ještě chvíli dorovnávají.

Proč to není samozřejmost

Přehledů kosmických startů je na internetu dost, jenže skoro všechny jsou anglicky a počítají po svém. Česky psaný přehled, který používá jednu známou datovou sadu a u každého čísla říká, co do něj počítá, se hledá hůř – a právě v tom je hodnota téhle sekce, ne v tom, že by ukazovala něco, co jinde není.

Slabinou zůstává, že přehled stojí a padá s jedním zdrojem. Kdyby TheSpaceDevs změnili podmínky nebo rozhraní vypnuli, zůstane po statistikách prázdná stránka. To ovšem není výtka Kosmonautixu, spíš popis toho, jak dnes drtivá většina takových přehledů funguje.

Do konference linux-kernel dorazila 17. srpna 2026 ve 2:32 UTC zpráva s předmětem, který se tam roky neobjevil: [ANNOUNCE] linux-7.2-ck1. Odesílatelem je Con Kolivas, anesteziolog z Melbourne, kterého linuxová obec zná jako autora plánovačů procesů, jež do hlavní řady jádra nikdy nemířily a taky se tam nedostaly.

Sada, která vyměňuje plánovač celý

Plánovač rozhoduje, která úloha poběží na kterém jádru procesoru a jak dlouho. V hlavní řadě se ladí hlavně na propustnost, tedy aby stroj co nejvíc spočítal; Kolivas ho léta ladil na opačný konec – aby člověk u počítače nepoznal, že se na pozadí něco děje. V oznámení to shrnuje jako odezvu, interaktivitu a hry na desktopu a mobilních zařízeních. Sada -ck to dělá hlavně tím, že plánovač v jádře vymění celý, en bloc.

Ten jeho se jmenuje MuQSS, tedy MultiQueue Skiplist Scheduler. Vyrostl z plánovače BFS, který Kolivas zveřejnil v srpnu 2009 jako protiváhu tehdejšího CFS z hlavní řady. Podle anglické Wikipedie stavěl už BFS na algoritmu EEVDF a v roce 2016 v něm autor vyměnil obousměrný seznam za skip list – datovou strukturu s několika patry ukazatelů, ve které se hledá rychleji než v prostém seznamu. Verze přiložená k 7.2-ck1 je 0.310; tak ji uvádí titulek na autorově blogu, seznam záplat v oznámení píše 0.31.

Co se v 7.2-ck1 změnilo

Kolivas u nových věcí sám píše, že je plánoval před lety a nikdy se k nim nedostal:

• Plánování si nově všímá vstupu a výstupu: čtení a zápisy se připíšou té úloze, která je vyvolala.
• Práce, kterou za úlohu odvede jaderné vlákno, se počítá zpátky té úloze.
• Vyvažování zátěže bere ohled na jádra P a E, tedy na dělení dnešních procesorů na výkonná a úsporná jádra.
• Struktura skip listu se zmenšila a přibyly drobné optimalizace.
• Zbytek je „matka všech resynchronizací“ na jádro 7.2 a řada oprav chyb.

Vedle plánovače sahá sada i na časovače. Výchozí frekvenci systémového přerušení sráží na 100 Hz, granularitu hrtimeru a nejkratší časový limit vystavuje v sysctl s výchozími hodnotami 100 µs a 500 µs a řadu volání schedule_timeout převádí na varianty s vysokým rozlišením. Preemptivní jádro, tedy takové, jehož běh smí přerušit jiná úloha, je nově výchozí volba; volba nohz_full se naopak do výchozí konfigurace nebere a zůstalo u ní jen doporučení v nápovědě.

Skupiny cgroup bere plánovač dál jen naoko: jsou to prázdné funkce, které nic neudělají. Kolivas píše, že se v cílových prostředích skoro nepoužívá a její doplnění by znamenalo obrovské množství kódu. Oznámení a blog se přitom v detailech rozcházejí: blog uvádí navíc, že ze sady vypadly irqthreads, protože na pracovních stanicích byly čistou ztrátou, a naopak v něm chybí zmínka o EEVDF a o vyvažování mezi jádry P a E, kterou nese zpráva do konference.

Důvodem návratu jsou podle autora jazykové modely

Nejzajímavější věta oznámení se plánovače netýká. „Je to deset let, co jsem sadu původně opustil kvůli času, ale jazykové modely udělaly slučování a vývoj nekonečně snazší,“ píše Kolivas (přeloženo). Sada záplat mimo hlavní řadu má totiž vlastnost, kterou nic v jádře nemá: s každou novou verzí se musí znovu naroubovat na kód, který se mezitím pohnul. Právě to je ta „matka všech resynchronizací“ ze seznamu změn a právě to dělal autor dřív ručně.

Údaj o deseti letech sedí na dobu, kdy práci fakticky odložil, ne na poslední oznámení. V archivu konference je jeho předchozí zpráva o vydání linux-5.10-ck1 datovaná 3. ledna 2021, tedy pět a půl roku zpátky.

Corbet se ptá na sched_ext

Veřejná odpověď přišla za necelý den jediná, zato od Jonathana Corbeta, šéfredaktora LWN.net a správce dokumentace jádra. Ptá se, jestli Kolivas zvažoval přesunout práci do sched_ext: „Okamžitě by to bylo mnohem dostupnější pro lidi, kteří si to chtějí vyzkoušet a opravdu používat,“ (přeloženo).

sched_ext je rozšiřitelná třída plánovače: dovoluje napsat plánovací algoritmus jako program v BPF a nahrát ho do běžícího jádra. První část se do hlavní řady dostala v Linuxu 6.12 spolu s dokončeným přechodem na EEVDF a dokumentace jádra 7.2 ji vede jako Extensible Scheduler Class. Praktický rozdíl proti sadě -ck je v tom, že uživatel nemusí překládat vlastní jádro. Kolivas do uzávěrky tohoto textu veřejně neodpověděl – v oznámení ovšem sám požádal, aby se případná diskuse vedla mimo konferenci.

Kde se to dá vzít

Kód je na GitHubu ve větvi 7.2-ck pod značkou v7.2-ck1 a autor ho drží modulárně, aby se dal přenášet na další verze jádra. Fork jádra měl 17. srpna 2026 sto dvacet dva hvězd a šest odvozených kopií. Do hlavní řady kód nemíří, což oznámení říká hned první větou – a to i teď, kdy hlavní řada s jádrem 7.2 vyšla jen o tři hodiny dřív.

Jak si MuQSS vede na dnešním hardwaru, zatím nikdo nezveřejnil. Bez čísel je zrychlená odezva zatím tvrzením autora. Phoronix měření ohlásil.

Zdroje

• [ANNOUNCE] linux-7.2-ck1, MuQSS CPU scheduler for linux-7.2 (17. srpna 2026, konference linux-kernel)
• -ck hacking: Linux-7.2-ck1, MuQSS v0.310 for linux 7.2 (17. srpna 2026)
• GitHub: vydání linux-7.2-ck1 se seznamem záplat
• Odpověď Jonathana Corbeta v konferenci linux-kernel (17. srpna 2026)
• Phoronix: Con Kolivas Revives „-ck“ Patches & MuQSS To Improve Linux Desktop Responsiveness (17. srpna 2026)
• Kernel Newbies: Linux 6.12 – sched_ext a dokončení přechodu na EEVDF
• Wikipedia: Brain Fuck Scheduler a Con Kolivas

Hugging Face vydala 14. srpna 2026 letní přehled otevřených modelů, druhý za letošní rok. Shrnuje, co se na jejím úložišti stalo od ledna do srpna. Nejzajímavější zjištění se přitom netýká žádného modelu: dvě čísla, kterými se úspěch modelu běžně měří, měří každé něco jiného.

Dva žebříčky, jeden společný repozitář

Autoři vzali pětadvacet repozitářů s nejvyšším počtem stažení za letošek a pětadvacet s nejvyšším počtem lajků. Ve druhém seznamu se objevuje jediný z prvního. Do horní pětadvacítky podle stažení se nedostal ani jeden model vydaný v roce 2026, zatímco třináct položek v ní je z roku 2022.

Nejstahovanější je all-MiniLM-L6-v2, drobný převodník vět na vektory z března 2022. Podle přehledu si ho za sedm měsíců někdo stáhl 1,55 miliardy krát a lajků má 5 156. Čerstvý čínský Kimi-K3 je na tom obráceně: připadá na něj asi šedesát stažení na jeden lajk.

Přehled z toho vyvozuje, že lajk a stažení zaznamenávají dva různé úkony. Lajk říká, že na vydání záleží, a sbírají ho špičkové modely v týdnech po uvedení. Stažení říká, že něco běží v pravidelně spouštěném postupu, a nabíhá roky malým a stabilním modelům. Že se jedno bere jako náhrada druhého, označuje Hugging Face za nejčastější chybu, které se v psaní o jejím úložišti dopouštějí ostatní. A přiznává, že i její vlastní starší texty.

Co vyšlo z vlastního měření

Přehled počítá stažení nasbíraná od ledna. Veřejné rozhraní Hugging Face vydává jiné okno, totiž posledních třicet dní; karta modelu ten údaj popisuje slovy „Downloads last month“. Přesto z obou žebříčků vyjde totéž. K 17. srpnu 2026 mají pětadvacítka podle stažení a pětadvacítka podle lajků společný jediný repozitář, znovu all-MiniLM-L6-v2, s 257 365 486 staženími za měsíc a 5 211 lajky. Třináct z pětadvaceti nejstahovanějších je z roku 2022. Jeden rozdíl proti přehledu se ukázal: ve třicetidenním okně se do horní pětadvacítky dva letošní modely dostaly, Qwen3.5-9B a MiniMax-H3 v přebalu od Comfy-Org.

Názornější než průměr jsou krajní hodnoty. Repozitář tiny-Qwen2ForCausalLM-2.5 z organizace trl-internal-testing má 2,4 milionu parametrů, dvacet lajků a 15 570 414 stažení za měsíc, čímž je dvacátý nejstahovanější na celém úložišti. Opačný pól drží meta-llama/Llama-2-7b se 4 523 lajky a 120 staženími.

Proč stažení není použití

Odpověď je v dokumentaci samotného úložiště. Repozitář obsahuje víc souborů, takže by se jedno stažení modelu dalo napočítat několikrát. Hugging Face proto sleduje požadavky na jediný vybraný soubor, ve výchozím stavu config.json, a započítá každý požadavek HTTP včetně metody HEAD, tedy i takový, po kterém žádná váha po drátě neputuje.

Číslo tak měří provoz na jednom malém souboru, ne to, kolikrát někdo model spustil. Skript, který si při každém spuštění ověří, jestli se soubor nezměnil, přidá stažení pokaždé, a testovací sada cizího projektu se do statistiky započítá stejně jako člověk, který si model opravdu odnese.

Velká čísla v titulcích

Den po vydání přehledu obletěla média zpráva agentury Bloomberg, že se otevřené modely Alibaby stáhly za posledních šest měsíců víc než třimiliardkrát a firma tím předstihla Meta i Google. Ta čísla ale pocházejí ze dvou míst a nekryjí se ani obdobím: tři miliardy za šest měsíců uvedla Alibaba ve vyjádření pro agenturu, kdežto 418 milionů u Googlu a 227 milionů u Mety připisuje text Hugging Face a vztahuje je k roku 2026.

Rozejdou se i počty odvozených modelů. Alibaba mluví o víc než 300 000 odvozeninách, přehled Hugging Face napočítal na svém úložišti 151 448 modelů postavených na Qwenu, tedy 2,6násobek celé stopy Mety. Co do svého čísla firma zahrnuje, z jejího vyjádření neplyne; přehled počítá výhradně repozitáře na Hubu.

Kde se modely opravdu používají

Za stovkami milionů stažení stojí podle přehledu drobná technika. Mezi modely, které mají uvedený počet parametrů, berou ty pod miliardou 83 % stažení za celou dobu a všechno nad sto miliard parametrů jedno procento; v letošním okně jde nad sedmdesát miliard parametrů 3 % objemu. Rozložení celého úložiště je stejně nerovné. Za celou svou existenci má míň než dvě stě stažení 85,6 % modelů a 1,5 % repozitářů dělá 99,2 % veškerého stahování. Veřejných repozitářů modelů přitom od ledna přibylo z 2,43 na 2,96 milionu.

Novým uživatelem je agent

Přehled poprvé měří i provoz od kódovacích agentů. Vychází z datové sady zveřejněné v červenci, do které se zapisuje značka agent/<jméno>, jakou agent pošle, když s úložištěm mluví přes knihovnu huggingface_hub nebo přes nástroj hf. V červenci vedl Claude Code se 44,4 %, v dubnu měl ovšem 67,8 % a v květnu 6,4 %, zatímco Codex vyrostl z 10,4 na 20,8 %. Do stejného oddílu patří i červencový průnik do infrastruktury Hugging Face, který firma popsala jako práci autonomního systému agentů.

Pro čtení zpráv z toho plyne jednoduché vodítko: ptát se, které z těch dvou čísel stojí pod tvrzením. Lajky ukazují, čemu obor právě věnuje pozornost, stažení to, na čem už delší dobu něco stojí. Když se tedy vydání modelu obhajuje počtem stažení pár dní po uvedení, měří se podle nás pozornost, ne nasazení.

Zdroje: State of Open Models: Summer 2026 Observations (Hugging Face, 14. srpna 2026), Models Download Stats (dokumentace Hugging Face Hubu), Alibaba AI models hit 3 billion downloads, passing Meta, Google (Bloomberg pro Fortune, 15. srpna 2026) a vlastní měření přes veřejné rozhraní huggingface.co ze 17. srpna 2026.

Certifikát pro cizí doménu se dá vydat omylem i naschvál a majitel webu se o tom nemá jak dozvědět z vlastního serveru. Proto existují veřejné seznamy vydaných certifikátů a nad nimi služby, které majiteli pošlou e-mail, jakmile se v seznamu objeví jeho jméno. Jednu takovou provozuje Cloudflare a 13. srpna 2026 oznámil, že ji přestal zahlcovat vlastní prací.

Co jsou logy Certificate Transparency

Certificate Transparency je evidence, do které certifikační autorita zapisuje každý certifikát, který vydala. Popsalo ji RFC 6962 z roku 2013, novější verzi 2.0 pak RFC 9162 z prosince 2021. Smysl je podle abstraktu obou dokumentů ten, aby kdokoli mohl kontrolovat, co autority dělají, a všiml si podezřelého vydání.

Zápis do logu není dobrovolný v tom smyslu, v jakém bývá dobrovolná dokumentace. Politika Chromu říká, že certifikát bez potvrzení z logů v Chromu neprojde ověřením. Kolik potvrzení je potřeba, závisí na délce platnosti: u potvrzení vložených přímo do certifikátu stačí do 180 dnů dvě z různých logů, nad 180 dnů jsou tři. Potvrzení se jmenuje SCT, tedy signed certificate timestamp, a autorita ho dostane od logu výměnou za zápis.

Zápis přitom probíhá dvakrát. Autorita nejdřív pošle do logu takzvaný předběžný certifikát, dostane za něj SCT, ta vloží dovnitř konečného certifikátu a ten zapíše znovu. Kdo logy čte, vidí u jedné objednávky dva záznamy.

Hlášení chodila hlavně o rutině

Cloudflare svou hlídací službu spustil ve veřejné betě v roce 2019 a dnes ji má podle vlastních čísel zapnutou přes 650 000 zákaznických domén. Jenže certifikáty pro ty domény z velké části vydává sám: Universal SSL, Advanced Certificate Manager, Total TLS, záložní certifikáty. Všechny putují do veřejných logů, jak mají, a všechny majiteli spouštěly upozornění.

K tomu se přidává frekvence. Jediný certifikát Universal SSL se podle Cloudflare obnovuje klidně po 60 dnech, tedy zhruba šestkrát do roka. A ta čísla půjdou nahoru: sdružení CA/Browser Forum schválilo hlasováním SC-081v3 rozvrh, podle kterého maximální platnost certifikátu klesla od 15. března 2026 na 200 dnů, od 15. března 2027 spadne na 100 dnů a od 15. března 2029 na 47 dnů. Pro hlasování bylo 25 z 30 autorit a všichni čtyři výrobci prohlížečů; proti nikdo.

Výsledek se dal čekat. Cloudflare cituje zákazníka z vlastního komunitního fóra, který funkci vypnul na všech webech, protože byl (v překladu) „unavený z toho, jak mě pravidelně spamují spousty úplně normálních obnovení certifikátů“, a dodal, že „ke konci už jsem je vlastně ani nečetl“. Mezi stovkami takových zpráv by se opravdu podezřelý certifikát ztratil.

Proč se to nedalo odfiltrovat dřív

Uvnitř Cloudflare běží dvě oddělené soustavy: jedna objednává a vydává certifikáty, druhá čte veřejné logy a rozesílá e-maily. Když druhá z nich narazí v logu na nový záznam, má k dispozici jen to, co v logu stojí. Nikdo jí neřekne, že o pár vteřin dřív si týž certifikát objednala ta první.

Nabízelo se použít otisk, který už služba měla. Aby neposílala dva e-maily za jednu objednávku, počítá si hodnotu stripped_fingerprint – otisk podepisované části certifikátu (TBSCertificate) v kódování DER, který vyjde stejně u předběžného i u konečného certifikátu. Jenže objednávková soustava předběžný certifikát nikdy nevidí, takže tuhle hodnotu umí spočítat až na konci. V okně mezi oběma zápisy by se hledalo něco, co ještě neexistuje, a e-mail by odešel.

Klíčem je otisk veřejného klíče

Cloudflare proto sáhl po jiném údaji: po veřejném klíči. Ten sedí ve struktuře SubjectPublicKeyInfo a je stejný v žádosti o certifikát, v předběžném certifikátu i v konečném. Firma si z něj počítá otisk SHA-256 a zapisuje ho už při generování klíčového páru, tedy dřív, než se cokoli dostane do logu.

Hlídací služba pak u každého nalezeného záznamu tentýž otisk dopočítá z certifikátu a podívá se, jestli ho objednávková soustava zná. Když ano, certifikát je jejich a e-mail se neposílá. Když ne, upozornění odejde jako dřív. Pro každé vydání se přitom generuje nový klíčový pár, takže shoda otisku znamená shodu objednávky.

Co se změnilo a co ne

• Certifikáty z produktů Cloudflare procházejí tiše, včetně obnovení.
• Tiše procházejí i opuštěné předběžné certifikáty, u kterých vydání nikdy nedoběhlo. Dřív vypadaly jako záhadné cizí zápisy.
• Certifikát, který si zákazník nahraje sám, upozornění pořád vyvolá – Cloudflare k němu klíč negeneroval, takže nemá co porovnávat.
• E-maily nově uvádějí dotčené jméno serveru v předmětu a odkazují na certifikát v ovládacím panelu.

Služba je dostupná ve všech tarifech bez příplatku a kdo ji má zapnutou, nemusí dělat nic. Dál chce Cloudflare hlášení propojit se svým systémem oznámení, aby se dala posílat na webhooky nebo do PagerDuty místo dnešního e-mailu.

Filtr ví, kdo certifikát vydal, ne kdo si ho přál

Stojí za to si všimnout, na čem je rozhodování postavené: filtr odpovídá na otázku „vydali jsme ho my?“, ne na otázku „chtěl to majitel domény?“. Certifikát objednaný přes cizí přístup do účtu u Cloudflare je z pohledu filtru certifikát Cloudflare, a e-mail tedy nepřijde. Podle nás je to rozumný kompromis – upozornění, které nikdo nečte, nechrání nikoho –, ale je dobré vědět, kde má hranici.

Ze samotných logů nezmizelo nic. Zůstávají veřejné a číst je může kdokoli, což je celý smysl Certificate Transparency; Cloudflare jen přestal o části z nich psát e-maily.

Na hlubokých snímcích Webbova dalekohledu se hromadí drobné rudé body. Astronomové jim říkají malé červené tečky, anglicky little red dots, a několik let se přou, co je pohání. Tým kolem Rohana Naidua teď jeden takový bod popsal tak podrobně, že z něj skládá výklad pro celou skupinu: uvnitř má být černá díra zabalená do tak hustého vodíku, že celek vyzařuje jako povrch obří hvězdy. Recenzovaná verze práce vyšla 12. srpna 2026 v Nature.

Zdroj, který ve třech pásmech chybí a ve čtvrtém svítí

Objekt nese označení MoM-BH*-1 podle přehlídky Mirage or Miracle, v jejímž rámci ho Webb změřil spektrograficky. Vybrali si ho proto, že v poli UDS o rozloze zhruba 250 čtverečních obloukových minut byl ze všech zdrojů nejčervenější. V pásmu F444W má jasnost 25,4 magnitudy, kdežto v kratších vlnových délkách se ztrácí: ve filtru F200W je slabší než 28,5 magnitudy. Mezi 3 a 4 mikrometry mu tok světla padá víc než dvacetkrát.

Spektrum posadilo objekt na červený posuv 7,7569, tedy do doby 660 milionů let po velkém třesku. Přitom zůstává bodový: jeho průměr v pásmu F356W vychází pod 100 parseků, a to je horní mez na hladině spolehlivosti 95 %. Snímky pořídila přehlídka PRIMER, spektrum mřížkou dodala v prosinci 2023 přehlídka EXCELS a hlubší spektrum hranolem přibylo v prosinci 2024.

Balmerův skok, na který hvězdy nestačí

Klíčem je tvar toho poklesu. Balmerův skok je zlom ve spektru, který dělá vodík: atomy, jejichž elektron sedí na druhé hladině, pohlcují světlo pod vlnovou délkou zhruba 364 nanometrů. Ve hvězdných atmosférách je to běžný jev a jeho síla má strop. Pro hvězdnou populaci bez prachu vychází nejvýš 3, a i kdyby ji tvořily samé hvězdy třídy A s nejhlubšími skoky, nepřesáhla by 5.

U MoM-BH*-1 vyšla síla skoku 7,7, s nejistotou +2,3 a −1,4. To je mimo dosah jakékoli hvězdné populace. K tomu přistupuje pohlcování v čarách Hβ a Hγ, které probíhá současně s jejich vyzařováním, a to jde jen při hustotách nad 10⁹ částic v krychlovém centimetru. Čára Hβ je navíc mimořádně široká, 3 036 kilometrů za sekundu v polovině maxima. Takové šířky se znají od jasných kvasarů, ne od hvězd.

Akreční disk v obalu z vodíku

Tým protáhl programem Cloudy skoro milion modelů a hledal takový, který sedne na sílu skoku, na šířky čar, na slabost v ultrafialovém pásmu i na měření přístrojem MIRI. Vyšel mu akreční disk kolem supermasivní černé díry, obalený plynem o hustotě 10¹¹ částic na krychlový centimetr, se sloupcovou hustotou 10^25,8 na centimetr čtvereční a s turbulencí 500 kilometrů za sekundu. Obal je podle článku silný řádově 10 až 100 astronomických jednotek; Neptun obíhá Slunce ve třiceti.

Podstatné je, co v modelu skoro není: prach. Extinkce vychází na 0,15 magnitudy, kdežto dosavadní výklady malých červených teček počítají se dvěma magnitudami i víc. Rudá barva podle téhle práce nevzniká pohlcováním na prachu, ale neprůhledností samotného vodíku. Autoři k tomu sami píšou, že model je krajně zjednodušený a má dát hrubou fyzikální představu, ne přesné hodnoty.

Kolik ta díra váží, se rozchází

Naidu v tiskovém sdělení MIT uvádí, že centrální černá díra má být stotisíckrát hmotnější než Slunce a obal kolem ní velký jako sluneční soustava. Článek v Nature ale nabízí několik odhadů podle toho, co se do výpočtu dosadí. Když se použije běžný vztah odvozený ze šířky čáry Hβ a extinkce se položí nulová, vyjde asi 5 × 10⁷ hmotností Slunce při zhruba 15 % Eddingtonovy meze. A pokud šířku čar nedělá pohyb plynu, ale opakovaný rozptyl fotonů, jsou takto spočítané hmotnosti nadsazené až o dva řády, tedy stokrát. Autoři to označují za odhady řádové přesnosti, které mají vymezit rozsah možností.

Co z toho plyne pro malé červené tečky

MoM-BH*-1 je cenný hlavně tím, že ho nic nepřehlušuje. U ostatních teček se světlo centrálního zdroje mísí se světlem galaxie kolem něj a rozplést se to nedaří; tady na hostitelskou galaxii skoro nic nezbývá. Vedle objektu je jasnější soused a podle modelů se s ním asi za sto milionů let spojí. Když autoři obě spektra sečetli, dostali útvar, který se malým červeným tečkám podobá.

Jorryt Matthee z rakouského ISTA, který pro tyhle objekty v roce 2024 vymyslel jméno, to shrnuje tak, že black hole star, tedy hvězda poháněná černou dírou, může sloužit jako šablona pro jejich černoděrovou složku. Naidu jde dál a soudí, že takové objekty jsou ranou fází dnešních supermasivních černých děr.

V jakém stavu ten výsledek je

Nejde o čerstvý objev, ale o čerstvé recenzní řízení. Preprint tým zveřejnil na arXivu 20. března 2025 a v poznámce pod ním odkazuje na podobný objekt s červeným posuvem 3,5, který téhož dne vyšel v arXivu od Anny de Graaff a dostal přezdívku The Cliff. Recenzovanou verzi vydalo Nature až letos v srpnu. Mezitím popsali Alberto Torralba, Matthee a spol. v Astrophysical Journal Letters další takový zdroj, tentokrát na červeném posuvu 1,7, tedy podstatně blíž.

Že jde o výklad modelem, a ne o přímé pozorování, stojí i v abstraktu: autoři píšou, že zdroj takhle modelují, ne že takový je. Za čím se dá jít dál, je proměnnost. Webb u objektu naměřil zjasnění o 30 ± 7 procent za 56 dní, jenže každou hodnotu jiným přístrojem, takže i tenhle údaj zůstává náznakem.

Zdroje

• Naidu, Matthee a spol.: A gas-enshrouded and gas-reddened black hole at cosmic dawn, Nature 656, 329–333, 12. srpna 2026
• Naidu a spol.: A „Black Hole Star“ Reveals the Remarkable Gas-Enshrouded Hearts of the Little Red Dots, arXiv, 20. března 2025
• Astronomers discover a brand-new type of astrophysical object: A black hole star, MIT News, 12. srpna 2026
• Earliest known black hole star found at cosmic dawn, European Research Council, 12. srpna 2026

Hvězdičky, které v USA visí na okenním štítku nového auta, přiděluje program New Car Assessment Program (NCAP) americké silniční správy NHTSA. Úřad teď navrhuje z toho programu dvě zkoušky vyškrtnout. Výzvu k připomínkám vyvěsil 14. srpna 2026 k veřejnému nahlédnutí, v úředním věstníku Federal Register vyšla 17. srpna pod značkou NHTSA-2026-1651. Zdůvodnění je u každé jiné, závěr stejný: podle úřadu už neříkají nic, co by kupující nevěděl odjinud.

Rybářský háček přestal auta rozlišovat

Riziko převrácení skládá NCAP ze dvou částí. První je statický faktor stability SSF, tedy poměr poloviny rozchodu kol k výšce těžiště nad vozovkou; ten popisuje převrácení, které něco spustí zvenčí, třeba obrubník, měkká krajnice, výmol nebo svodidlo. Takových je většina. Druhá část je jízdní zkouška zvaná rybářský háček: řidič prudce strhne volant a hned protisměrně, aby vůz dostal do smyku, a měří se, jestli vnitřní kola nadskočí současně aspoň o dva palce, tedy zhruba pět centimetrů. Míří na převrácení bez vnějšího spouštěče, a ta tvoří podle úřadu méně než pět procent všech případů.

Zkouška se do programu dostala v roce 2003, o dva roky po SSF, a úřad ji zavedl na příkaz Kongresu z takzvaného zákona TREAD z roku 2000. Hodnocení rizika převrácení najde zájemce na webu NHTSA od roku 2004 a jako hvězdičku na okenním štítku od roku 2007.

Mezitím se ale změnila auta. Od 1. září 2011 musí mít každé lehké vozidlo prodávané v USA elektronickou kontrolu stability podle normy FMVSS č. 126 a ta má vlastní, ostřejší dynamickou zkoušku. Důsledek popisuje úřad bez okolků: za posledních patnáct let žádné vozidlo s tímto systémem při zkoušce v NCAP kola nenadzvedlo. Zkouška tak přestala lepší vozy od horších odlišovat. Rozdíl v riziku převrácení mezi vozem, který kola nadzvedne, a vozem, který ne, přitom vychází podle úřadu na 1,6 procenta u vozidel s vysokým SSF a 4,8 procenta u těch s nízkým.

Elektronickou stabilizaci má úřad za výrazně účinnější: podle svých vlastních studií snižuje smrtelné nehody s jediným vozidlem o polovinu a převrácení jako první událost nehody zhruba o sedmdesát procent. Hodnocení rizika převrácení proto z hvězdiček nezmizí, jen se bude počítat ze samotného SSF. Rybářský háček by skončil u vozidel modelového roku 2027.

Zvlášť se dokument věnuje dodávkám pro dvanáct a patnáct cestujících, které mají k převrácení historicky nejblíž. Ani jedna z těch, které NCAP od roku 2015 zkoušel, kola nenadzvedla. Váhový strop programu, 4 536 kilogramů, překračuje z modelového roku 2026 podle úřadu jediný vůz: Ford Transit T-350 HD s dvojmontáží vzadu.

U bočních airbagů chybí vazba na skutečné nehody

Druhá vyškrtnutá položka je zkouška bočních airbagů s cestujícím mimo obvyklou polohu, zkráceně SAB-OOP. Ta nikdy nebyla příkazem zákonodárce. Na přelomu tisíciletí se výrobci obávali, že rychle nastupující boční airbagy zraní děti a drobné dospělé, kteří v okamžiku výstřelu sedí nakřivo nebo se opírají o dveře. Postup pro měření sepsala pracovní skupina automobilek a bezpečnostních organizací včetně pojišťovacího institutu IIHS a NHTSA ho v roce 2003 převzala do NCAP, aby dobrovolný závazek výrobců někdo kontroloval.

Zkouška vypadá tak, že se do vozu posadí figurína ženy pětiprocentního percentilu a figuríny tříletého a šestiletého dítěte, nastaví se do několika poloh těsně u airbagu a ten se staticky odpálí; naměřené síly se pak porovnají s referenčními hodnotami zranění.

Úřad teď píše, že tenhle postup se skutečnými nehodami nekoresponduje. Neúspěšné zkoušky nachází zhruba dvě do roka, ale ani jednu z nich se u příslušného modelu nepodařilo spojit se skutečným zraněním na silnici. Opačný případ nalezl: skutečnou nehodu, při které boční airbag cestujícího zranil ve voze, jenž všemi zkouškami prošel.

Druhá výhrada je metodická. Malá odchylka v posazení figuríny podle úřadu úplně mění naměřená čísla a postup navíc dovoluje polohy upravovat tak, aby se našel nejhorší případ. Výsledky se proto nedají zopakovat a NHTSA kvůli žádné neúspěšné zkoušce nikdy nezahájila svolávací řízení. Přitom je to práce navíc pro obě strany: výrobci dodávají data až pro třicet poloh na vůz a zkušebna NCAP je přeměřuje u třiceti až čtyřiceti procent nárazově zkoušených modelů. Od modelového roku 2026 už výrobci posílají jen potvrzení, že zkouškou prošli, a číslo protokolu.

Desetiletý plán se posouvá

Druhá polovina dokumentu přepisuje desetiletý plán rozvoje NCAP. První takový plán vydal úřad 3. prosince 2024 na příkaz z infrastrukturního zákona z roku 2021; loni v září pak o jeden modelový rok odložil změny, které už měl schválené. Nový plán má běžet od roku 2026 do roku 2035, střednědobá část do roku 2030.

Většina položek se odsouvá. Pokročilá figurína THOR-50M a s ní nový šikmý čelní náraz mají zpoždění dva roky a do programu by přišly až v roce 2029. Boční figurína WorldSID-50M se přesunula do dlouhodobé části, tedy nejdřív na rok 2031. Hodnocení asistenčních systémů se opožďuje o rok a nové hodnocení odolnosti při nárazu, ochrany chodců a cyklistů i celkové bezpečnosti spolu s novou podobou okenního štítku o dva roky.

Dopředu se naopak posunuly tři věci, u kterých je výzkum hotový: adaptivní i poloautomatické přepínání dálkových světel, zkušební noha aPLI pro měření zranění chodců a varování i zásah v mrtvém úhlu pro ochranu motorkářů a cyklistů. Nová je v plánu jediná položka, aktualizace hodnocení srozumitelnosti dětských sedaček, plánovaná na poslední čtvrtletí roku 2028.

Nejvíc si pohoršilo sledování řidiče. Systém rozpoznávající ospalost naráží podle úřadu na to, že se do zkoušky musí zapojit skuteční lidé, a počítá se s ním až u modelového roku 2036. Verze pro rozpoznávání nepozornosti z plánu vypadla úplně; úřad slibuje jen, že sbírá podklady. Inteligentní asistent rychlosti, který hlídá rychlostní limit, má dokončit výzkum v roce 2031 a do hodnocení se dostat v roce 2035.

Evropy se to netýká

Americký NCAP a evropský Euro NCAP, který od letošního ledna hodnotí auta podle nových pravidel, jsou dva různé programy s vlastními zkouškami i stupnicí. Hvězdička z NHTSA se v Evropě neuvádí a naopak, takže na to, co si čtenář koupí v Česku, návrh přímý dopad nemá.

Připomínky sbírá úřad do 16. října 2026 do spisu NHTSA-2026-1651 na regulations.gov. Až potom se rozhodne, jestli zkoušky skončí; do té doby se na hvězdičkách nemění nic.

Zdroje

• NHTSA: New Car Assessment Program (NCAP); Removal of Dynamic Rollover Resistance Test and Side Air Bag Out-of-Position Testing, Federal Register, 17. srpna 2026
• Záznam o vyvěšení dokumentu k veřejnému nahlédnutí 14. srpna 2026
• NHTSA: Consumer Information; New Car Assessment Program; Rollover Resistance, Federal Register, 14. října 2003
• NHTSA: New Car Assessment Program Final Decision Notice — Advanced Driver Assistance Systems and Roadmap, Federal Register, 3. prosince 2024
• NHTSA: New Car Assessment Program (NCAP) Notice – Delay of Program Updates, Federal Register, 22. září 2025
• Side Airbag Out-of-Position Injury Technical Working Group: Recommended Procedures for Evaluating Occupant Injury Risk from Deploying Side Airbags (PDF, IIHS)

Překladová vrstva D7VK vyšla 14. srpna 2026 ve verzi 2.1. Poznámky k vydání otevírá věta, kterou by v seznamu změn čekal málokdo: doba zrychlování skončila a přišel čas optimalizovat načítání (přeloženo). Autor pod ní vypsal šestnáct změn, ve kterých ubývá režie na místech, kam se při měření snímkové frekvence nedívá skoro nikdo.

Prostředník mezi starým rozhraním a Vulkanem

D7VK je odbočka od DXVK a převádí volání Direct3D verzí 7, 6, 5 a 3 na Vulkan, aby staré hry běžely pod Wine a Protonem na Linuxu. Úplný ovladač to není: opírá se o backend DXVK pro Direct3D 9 a o implementaci DirectDraw z Wine a mezi obojím dělá prostředníka. Novější rozhraní pokrývají jiné projekty, popisuje Phoronix – Direct3D 8 až 11 samotné DXVK, Direct3D 12 pak VKD3D-Proton.

Číslování má díru, kterou autor vysvětluje hned v popisu projektu. Direct3D 1 nikdy neexistovalo, protože první vydání DirectX žádnou trojrozměrnou část nemělo. Direct3D 2 a 3 jsou prakticky totéž rozhraní a liší se jen historicky. A DirectX 4 Microsoft nikdy nevydal; rozpracované Direct3D 4 se přelilo do toho, čemu se pak začalo říkat Direct3D 5.

Co se v této verzi zkrátilo

Hlavní změna je ořezané sledování životního cyklu objektů. Vytváření a rušení objektů, mezipaměti a kopírovací cesty stály víc, než musely, a jejich zeštíhlení se podle autora projevilo na startu her napříč všemi podporovanými verzemi rozhraní. Jediné konkrétní číslo v poznámkách se týká hry Empire Earth: čas od spuštění do přehrání úvodního videa spadl ze tří až čtyř sekund zhruba na jednu, a to díky zrychlenému kopírování a ukládání struktury se schopnostmi zařízení.

Vedle toho přibyla nepovinná přímá cesta pro volání GetDC a ReleaseDC. Ve hře Arx Fatalis přidala během hraní pět až deset procent snímků, jenže při vykreslování hlavní nabídky výkon naopak znatelně klesl; autor proto sám píše, že se výsledek bude lišit hru od hry. Vertex buffery pro Direct3D 7 a 6 se nově zkoušejí připravit dopředu, což odstraní záseky při prvním sáhnutí na objekt – ale jen tam, kde to chování hry dovolí.

Opravy vázané na konkrétní tituly

Seznam změn je z velké části soupis jednotlivých her. Chyba typu use-after-free při uvolňování připojené hloubkové plochy shazovala Arx Fatalis hned po startu; projevila se jen u binárek přeložených překladači MSVC a clang a upozornil na ni přispěvatel vystupující jako NemesisElectron. Nová volba pro posun středu pixelu o půl texelu odstranila kazy na pozadí v krabicovém vydání hry Resident Evil 2 – dělá totéž co dávná volba v ovladačích ATI a Nvidie z časů Windows 9x a XP a mimo takové případy se zapínat nemá, protože sama vyrábí artefakty, nejvíc na vykresleném textu.

Dál přibylo obejití chybějících pozadí hlavní nabídky v MechWarrior 3, spravované vertex buffery pro Project I.G.I. a Sonic World DX a obejití nešikovných přístupů do bufferů v Empire Earth: The Art of Conquest, které pomáhá, když je na obrazovce hodně jednotek. Rychlejší přenosy ploch se mají projevit ve hrách Blade of Darkness, Knight Rider a Silent Hunter II ve chvíli, kdy se vykreslují takzvané god rays, tedy prosvítající sluneční paprsky.

Srovnání bez naměřených hodnot

Autor v poznámkách přiznává, že tentokrát nemá čím se pochlubit: kód je prý mnohem lépe udržovatelný, ale žádné okázalé skoky ve výkonu se konat nebudou. Zajímavější je, co v poznámkách chybí. Tvrzení o načítání zkráceném na polovinu i méně nedokládá žádné měření a stejně tak není podloženo srovnání, které autor uvádí jako pointu: notebook s čipem Core Ultra 7 256V, sdíleným rozpočtem 37 wattů pro procesor i grafiku a během na baterii prý dosáhl v 3DMarku 99 a 3DMarku 2000 podobného skóre jako verze 1.12 na kartě GeForce RTX 4070 se dvousetwattovým rozpočtem. „Čísla jsem nepřikládal, měli jsme jich dost u vydání 2.0,“ píše k tomu (přeloženo). Kdo si tedy chce ověřit, že se u jeho hry něco změnilo, musí si to změřit sám.

Zpátky do DXVK to nepůjde

Otázku, jestli se práce vrátí do hlavního projektu, má autor v popisu projektu vyřízenou jedním slovem: ne. Vývojáři DXVK podle něj dali najevo, že o cokoli staršího než Direct3D 8 nestojí, a D7VK navíc stojí na jiném principu – je to spíš obal DirectDraw nad Direct3D 9 než plnohodnotná implementace.

Praktické omezení je jinde: D7VK potřebuje grafickou kartu s podporou Vulkanu 1.4. Kdo takovou nemá, může sáhnout po projektu DXVK-Sarek, kam byla podpora Direct3D 7 až 3 přenesena a kde stačí Vulkan 1.1; chybí v něm ale průhlednost klíčovou barvou a přepínání vyhlazování hran za běhu. Retained mode, tedy starší způsob práce se scénou, D7VK nepodporuje vůbec a ani to neplánuje.

Repozitář projektu vznikl na GitHubu v březnu 2022, kód běží pod licencí zlib a k 16. srpnu 2026 měl 731 hvězd a 40 otevřených hlášení.

Zdroje

• D7VK: poznámky k vydání 2.1 (14. srpna 2026)
• Phoronix: D7VK 2.1 Brings Faster Load Times, More Performance Tweaks (14. srpna 2026)
• GamingOnLinux: D7VK version 2.1 brings improvements to retro game loading time (15. srpna 2026)
• D7VK: popis projektu a časté dotazy