Šest prověrek, které skončily

Regionální zaměstnanci CISA už nebudou dělat Cyber Resilience Review, průzkum Cyber Resilience Essentials, Ransomware Readiness Assessment, Incident Management Review, External Dependencies Management Assessment ani Cyber Infrastructure Survey. Každá z těch prověrek mířila jinam. Cyber Resilience Review zjišťuje, jestli organizace udrží službu v chodu za krize. External Dependencies Management Assessment se ptá na dodavatelský řetězec, Cyber Infrastructure Survey na nasazená bezpečnostní opatření, Ransomware Readiness Assessment na to, jestli firma přežije nákazu vyděračským programem, a Incident Management Review na schopnost průnik odhalit a zastavit.

Že se ruší, oznámil zaměstnancům James Harrell, úřadující asistent ředitele divize integrovaných operací, na poradě 25. srpna. Stránka první z těch služeb na webu agentury dnes nese hlavičku „Archived Content“, tedy označení pro obsah, který už nemusí odpovídat současným programům.

Místo poradce dotazník

„CISA své služby a nástroje pravidelně vyhodnocuje a dělá potřebné změny, aby je zlepšila,“ řekl Cybersecurity Dive Chris Butera, úřadující výkonný asistent ředitele divize kybernetické bezpečnosti. Agentura podle něj vyřazuje starší dotazníková hodnocení, aby snížila zdvojenou práci na své straně i na straně žadatelů.

Náhradou mají být mezioborové cíle Cross-Sector Cybersecurity Performance Goals, ke kterým existuje dotazník. Butera tvrdí, že mají tytéž cíle i výstupy jako zrušená hodnocení a navíc umožní lépe sbírat a srovnávat data za celou zemi.

Jeff Greene, který dřív divizi kybernetické bezpečnosti v CISA vedl, tomu odporuje. „Hodnocení v CSET stojí na standardech a měří, kde jste,“ řekl. „CPG používáte spíš k tomu, abyste zjistili, kam zaměřit úsilí. Fungují dohromady.“ Podobně to vidí Denis Calderone ze Suzu Labs: CSET slouží k diagnóze, CPG k určení pořadí oprav, a jedno druhé nezastoupí. „Co už nedostanete, je regionální poradce CISA, který vám pomůže výsledky vyložit,“ napsal serveru Industrial Cyber.

Nástroj zůstává, doprovod k němu ne

Cyber Security Evaluation Tool, zkráceně CSET, je program s otevřeným zdrojovým kódem a nikam nemizí. Cybersecurity Dive píše, že jeho nejnovější verze možnost provádět zrušená hodnocení vypíná, kdežto starší vydání provedou uživatele celým dotazníkem a vygenerují zprávu i bez pomoci agentury.

V seznamu vydání na GitHubu se ale ta změna zatím nepromítla. Poslední tamní vydání je v12.4.0.4 z 18. července 2025 a jediná uvedená změna v něm je oprava zprávy z Cyber Resilience Review, tedy z jedné ze šesti zrušených prověrek. Modul pro Incident Management Review přibyl v CSET v září 2023. Novější sestavení, které by hodnocení zakazovalo, tam k dnešnímu dni není.

Úřad, který přišel o třetinu lidí

Škrty jsou souvislost, kterou uvádějí oba servery. CISA od začátku druhého Trumpova období přišla zhruba o třetinu zaměstnanců; podle Nextgov/FCW stav klesl z asi 3 300 lidí na zhruba 2 200. Pět demokratických poslanců proto v srpnu požádalo Účetní dvůr Kongresu (GAO) o přezkum, co se ztrátou lidí zmizelo za schopnosti. Úřadující ředitel Nick Andersen chce přijmout kolem 330 lidí, ministr vnitřní bezpečnosti Markwayne Mullin mluví o šesti stovkách a o náboru, který může trvat rok i déle. Rozpočtový návrh na rok 2027 přitom počítá se zrušením zhruba 870 míst.

Tatyana Bolton z koalice OT Cyber Coalition to shrnula tak, že tvrdé rozpočtové škrty zahnaly agenturu do kouta, kde už praktickou pomoc v dřívějším rozsahu poskytovat nemůže. Dodala, že omezovat přímou pomoc zrovna teď je nebezpečné. Michael Daniel, koordinátor kybernetické bezpečnosti v Bílém domě za Baracka Obamy a dnes šéf sdružení Cyber Threat Alliance, upozornil na cenu: hodnocení byla zdarma a není jasné, kdo by stejnou službu nabídl za peníze, které tihle provozovatelé mají.

Povinné hlášení přichází dřív než náhrada

Časově to padá k sobě s předpisem, který provozovatelům naopak povinnosti přidá. Nařízení k zákonu CIRCIA uloží zasaženým organizacím hlásit kybernetický incident do 72 hodin a zaplacené výkupné do 24 hodin. Návrh vyšel v dubnu 2024, zákonnou lhůtu pro finální znění CISA nestihla a podle přehledu advokátní kanceláře Hunton se hotové pravidlo čeká právě v září 2026. Agentura zároveň dál vede katalog aktivně zneužívaných zranitelností, do kterého letos zařadila třeba chybu v ověření hlavičky Host v knihovně Starlette.

Co se ztratilo, se přitom nedá spočítat. Calderone na to upozorňuje sám: veřejná data o tom, kolik provozovatelů hodnocení skutečně využilo a co jim to přineslo, neexistují, a jen malých vodáren jsou ve Spojených státech desítky tisíc. Regionální poradci CISA se k nim ke všem dostat nemohli. Zrušení šesti položek z nabídky je proto vidět hned, kdežto rozdíl v zabezpečení konkrétní čistírny odpadních vod se pozná až při útoku, a to zpětně.

Zdroje

• CISA scraps 6 free cybersecurity assessments for critical infrastructure operators, Eric Geller, Cybersecurity Dive, 1. září 2026, aktualizováno 3. září
• CISA retires six cybersecurity assessments for critical infrastructure, Anna Ribeiro, Industrial Cyber, 7. září 2026
• Cyber Resilience Review (CRR), CISA
• Releases · cisagov/cset, GitHub
• House Democrats ask GAO to review CISA workforce cuts, David DiMolfetta, Nextgov/FCW, 21. srpna 2026
• Lawmakers call for investigation into impact of CISA staffing cuts, Jonathan Greig, The Record, 21. srpna 2026
• CISA Plans to Finalize Cyber Incident Reporting Regulations in September 2026, Hunton Andrews Kurth, 17. července 2026

Proč rentgen překáží při počítání paliva

Uran, neptunium a plutonium vyzařují vedle gama záření i takzvané čáry K alfa. Je to rentgen, který vznikne, když elektron spadne do díry po vyraženém elektronu z nejvnitřnější slupky atomu. Energie těchhle čar padne u těžkých prvků do stejného pásma jako gama linky, podle kterých se materiál posuzuje. Čím hůř je rentgenové pozadí známé, tím větší chybu si člověk odnese z výsledku.

Na tom, jak přesně ten poměr vyjde, může hodně záležet. Uran-235 tvoří jen 0,7 procenta uranu v přírodě; pro palivo do reaktoru se obohacuje na jednotky procent, na zbraňový materiál na devadesát. Rozdíl mezi palivem a zbraní je tedy otázka čísla, které z měření vypadne. Kolik uranu se k tomu v USA vytěží, ukázala statistika za loňský rok.

„Naše měření podporují mezinárodní jaderné záruky tím, že umožňují přesnější evidenci materiálu v jaderných zařízeních,“ řekl ke svojí práci Jonathan Dean, fyzik NIST a Coloradské univerzity v Boulderu (přeloženo z anglického oznámení NIST).

Teploměr, který ucítí jediný foton

Měřilo se polem senzorů, kterým se říká transition-edge sensor, česky přechodový senzor, zkratkou TES. Je to v podstatě nesmírně citlivý teploměr. Tenká vrstva supravodiče se udržuje zlomek stupně nad absolutní nulou, a to přesně v místě, kde supravodič přechází v obyčejný kov s měřitelným odporem. Když do vrstvy uhodí jeden foton, předá jí nepatrné teplo, jenže právě v tomhle bodě stačí nepatrné teplo k prudké změně odporu. Velikost té změny je úměrná energii fotonu, takže senzor neřekne jen „něco přiletělo“, ale i „s touhle energií“. Pole, které tým použil, čítá zhruba 250 takových senzorů.

Za citlivost se platí chlazením. Aparatura, která udrží vrstvu těsně nad absolutní nulou, je podle NIST příliš objemná na to, aby se dala nosit v ruce. Pole detektorů může stát kdekoli, kde je dost elektřiny pro chladicí systém; kde takový přístroj není, odebere se vzorek a odveze do laboratoře. Obě cesty jsou podle Deana pro tenhle typ přístroje schůdné.

Co přesně se povedlo změřit

Předmětem měření byly přirozené šířky čar K alfa 1 a K alfa 2 u prvků s protonovým číslem 92, 93 a 94, tedy u uranu, neptunia a plutonia. Šířka čáry není maličkost na okraji: říká, jak rozmazaný ten rentgenový příspěvek ve spektru je, a bez ní se od gama linek odečíst nedá.

Relativní nejistoty vyšly podle abstraktu mezi 0,5 a 1,5 procenta a proti dosavadním hodnotám jsou lepší v poměru tři až osm ku jedné. Zpráva NIST uvádí totéž číslo obráceně, tedy že nejistota klesla na třetinu až osminu.

K měření autoři přidali i výpočet, konkrétně multikonfigurační metodou Dirac-Fock. Původně měl sloužit jako srovnávací měřítko, jenže vyšlo najevo něco jiného: mezi výpočtem z prvních principů a naměřenými hodnotami je rozpor, který se dá zahlédnout teprve při téhle přesnosti. Autoři to píšou rovnou do abstraktu, takže teorie a experiment si u aktinidů zatím neodpovídají a je to otevřená věc.

Studie stála na dlouhé recenzi. Redakce ji přijala k otištění 1. června 2026, přišla jí ale už 10. prosince 2025 a v březnu prošla revizí. Vyšla jako Phys. Rev. Lett. 137, 113001; číslo 11 ročníku 137 nese datum 11. září 2026. Pod prací je podepsáno devatenáct autorů z NIST v Boulderu, Coloradské univerzity v Boulderu, Národní laboratoře v Los Alamos, Houghton University a z laboratoře Kastler Brossel na pařížské Sorbonně.

Kde takové detektory už pracují

Přechodové senzory z NIST nejsou laboratorní kuriozita a několik jich stojí na místech, kde se s jadernými materiály opravdu zachází. NIST je podle svého oznámení ve spolupráci s Los Alamos nainstalovala ve třech laboratořích ministerstva energetiky právě kvůli evidenci materiálu. Další sady slouží výzkumu:

• urychlovačové centrum SLAC na Stanfordově univerzitě,
• synchrotron Advanced Photon Source v Argonnské národní laboratoři,
• zdroj záření National Synchrotron Light Source v Brookhavenu,
• urychlovač CERN ve Švýcarsku.

Tým teď podle NIST pracuje na tom, aby detektory dosáhly ještě vyšší přesnosti kvůli hledání nových typů základních částic, a chystá jeden pro Goddardovo středisko NASA. Vedle toho se v NIST řeší i ta nepohodlná půlka věci: jak chlazení zmenšit a zlevnit. Kompaktní chladicí systém navržený institutem už vyrábějí dvě americké firmy.

Kolik z toho uvidí provoz

Praktický přínos pro elektrárny popisuje NIST opatrně a stojí za to to číst přesně. Palivo se v několika krocích přepracovává a po každém kroku se musí znovu posoudit jeho složení; rychlejší rozbor by podle Deana měl zkrátit čekání mezi kroky a má potenciál zvýšit účinnost a snížit náklady. Jsou to podmiňovací věty, ne naměřená úspora. Doložené je zpřesnění laboratorního měření; kolik z něj zbude v provozu elektrárny, zatím nikdo nezměřil.

Zdroje

• NIST: NIST-Developed Quantum Sensors Improve Nuclear Monitoring
• A. Wessels a kol.: Measured and Theoretical K alfa X-Ray Emission Linewidths of U, Np, and Pu, Phys. Rev. Lett. 137, 113001
• Physical Review Letters: abstrakt a údaje o přijetí práce

Aktivní řízení proudění znamená, že do obtékání povrchu někdo průběžně zasahuje: malými klapkami, rotujícími prvky nebo tryskami, které vzduch u stěny přifukují a odsávají. Cílem bývá menší odpor, větší vztlak, tišší chod nebo odvod tepla. Autoři práce uvádějí, že aktivní snižování odporu by mohlo letecké dopravě ubrat až 15 procent spotřeby paliva a koordinované řízení větrných parků zvednout jejich výkon o 4 až 5 procent.

Proč se jednotlivé pokusy nedaly porovnat

Učení posilováním je postup, při kterém se program učí zásahům do prostředí podle odměny, kterou za ně dostane. Práce připomíná dva obory, kde s ním přišel velký posun – předpověď struktury bílkovin a řízení plazmatu ve fúzním reaktoru –, a společného jmenovatele vidí v tom, že v obou byly po ruce sdílené srovnávací úlohy. Dynamika tekutin nic takového neměla. Každý regulátor se ladil na jednu geometrii, jeden provozní bod a jedno numerické nastavení, takže se výsledky nedaly ani sčítat, ani poctivě srovnávat.

Jednašedesát prostředí a šest řešičů

HydroGym není vlastní simulátor, ale vrstva nad cizími. Úlohy sahají od dvourozměrných učebnicových případů po trojrozměrné turbulentní proudění s Reynoldsovým číslem až 400 000 a s různými Machovými čísly; největší simulace pracují s 1,6 miliardy buněk. Pod tím běží šest řešičů – od pomalé, zato dostupné konečněprvkové knihovny v Pythonu přes mřížkový Boltzmannův a konečněobjemový řešič na GPU až po plně diferencovatelné, které umí spočítat gradient přes celý průběh simulace.

Rozhraní odpovídá knihovně Gymnasium, takže prostředí přijmou běžné implementace algoritmů. Kód je na GitHubu pod licencí MIT. Referenční výsledky spočítal tým třemi zavedenými algoritmy – PPO, DDPG a TD3 – a jejich trénink dohromady spotřeboval přes 150 000 hodin strojového času na GPU.

Tam, kde je řešič diferencovatelný, jde gradient protáhnout i prostředím, ne jen politikou agenta. Na Kolmogorovově proudění to autoři zkusili: takto doplněné PPO potřebovalo podle práce nejméně o 65 procent méně tréninkových iterací než obyčejné a našlo přitom regulátor, který zasahuje mírněji.

Z kanálu rovnou na křídlo

Nejsilnější ukázka v článku se týká přenosu. Trénovat agenta přímo na trojrozměrném křídle při vysokém Reynoldsově čísle je výpočetně neúnosné, takže tým trénoval jinde: v turbulentním proudění mezi dvěma deskami, jejichž stěny mají otvory a agent jimi vzduch přifukuje a odsává tak, aby dovnitř i ven šlo stejné množství. Naučenou politiku pak bez jediného dalšího kroku učení pustil na sací stranu řezu křídlem NACA 0012 při Reynoldsově čísle 200 000.

Místní třecí odpor na křídle klesl zhruba o 38 procent a celkový odpor o 11 procent, tedy víc, než zvládne opoziční řízení, které se v oboru bere jako měřítko. Trénink v jednodušším prostředí proběhl podle tiskové zprávy Michiganské univerzity stokrát rychleji a vyšel desettisíckrát levněji než přímé ladění na křídle; text v Nature popisuje tentýž rozdíl jako čtyři řády.

Co práce nedokazuje

Přenos funguje proto, že obě úlohy sdílejí fyziku u stěny, a jak daleko taková podobnost sahá, nechává práce otevřené. Prostředí navíc pokrývají hlavně učebnicové případy a mezní vrstvy blízko rovnováhy. A všechno se odehrálo v počítači: v aerodynamickém tunelu ani na skutečném křídle HydroGym vyzkoušený není.

Práce sama ukazuje, kde je strop. Trénovat agenta rovnou na simulaci celého letadla by podle ní vyžadovalo přes 500 GPU a víc než 50 TB paměti na jediný běh. Náhradní prostředí je tedy odpověď na cenu, ne na to, že by kompletní simulace nebyla přesnější.

Kam s tím autoři míří

V závěru mluví o základovém modelu pro řízení proudění: jednom regulátoru předtrénovaném napříč všemi prostředími, který by se na novou úlohu doladil z pár pokusů, nebo vůbec. Přirovnávají to k jazykovým modelům, kde podle nich rozhodla dostupnost velkého a rozmanitého korpusu, ne jediný algoritmický objev.

Na platformě se podílely Washingtonova univerzita, Michiganská univerzita, RWTH Aachen a Technická univerzita v Mnichově. Vývoj platila hlavně americká National Science Foundation a Boeing.

Zdroje: The HydroGym reinforcement learning platform for fluid dynamics (Nature 657, s. 369–376, otevřený přístup), tisková zpráva Michiganské univerzity z 26. srpna 2026 a repozitář dynamicslab/hydrogym.

Co Reflex dělá a proč pod Linuxem drhl

Reflex je technika NVIDIA na zkrácení prodlevy mezi stiskem tlačítka a snímkem na obrazovce. Podle příručky k instalaci ovladače rozhoduje o tom, kdy má hra začít připravovat nový snímek, aby se zkrátila doba mezi čtením vstupu a zobrazením výsledku. Na Windows si hry pro Vulkan k tomu přibalují knihovnu NvLowLatencyVk.dll od NVIDIA. Pod Protonem běží ta knihovna ve Wine a s linuxovým ovladačem se sama domluvit neumí.

Překlad mezi windowsovou hrou a linuxovým ovladačem obstarává projekt dxvk-nvapi, který do Protonu dodává náhradu za rozhraní NVAPI. Reflex pro hry ve Vulkanu umí od verze 0.9.0 z 16. března 2025, jenže s podmínkou: uživatel si musel doinstalovat samostatnou vrstvu Vulkanu, tedy dvojici souborů VkLayer_DXVK_NVAPI_reflex.json a libdxvk_nvapi_vkreflex_layer.so, a zapnout ji proměnnou prostředí DXVK_NVAPI_VKREFLEX=1. Vrstva zůstává vypnutá i po instalaci, protože by mohla rušit programy, které Reflex nepoužívají. Bez ní dostane hra na volání Reflexu vymyšlené „ano“. Hra si pak myslí, že Reflex běží, prodleva se ale nezkracuje. Tenhle obchvat přibyl ve verzi 0.9.1 z ledna 2026 kvůli hře DOOM: The Dark Ages, která bez kladné odpovědi kreslila obraz do růžova.

Revize 2 je rozhraní pro překladové vrstvy, ne pro hry

Rozšíření VK_NV_low_latency vede registr Khronosu pod číslem 311. Ve své první podobě z února 2023 umělo jediné: říct hře, jestli je Reflex k dispozici. Nástupce VK_NV_low_latency2 ho nahradil a registr ho vede jako zastaralé. Přesto dostalo 26. června 2026 revizi 2, pod kterou je podepsaný Will Campbell z NVIDIA. Popis je stručný. Revize přidává vstupní body, které zpřístupňují „starou implementaci NVIDIA Reflex“, a ty jsou „určené jen pro kompatibilní vrstvy, aplikace je nemají volat přímo“. Specifikační text k nim neexistuje a Khronos rozšíření neratifikoval. Je to tedy rozhraní, které NVIDIA vystavila překladovým vrstvám, ne hrám.

Projekt dxvk-nvapi na to zareagoval commitem z 29. července 2026, který přidává druhou implementaci Reflexu postavenou právě na revizi 2. Podle README projektu tak existují dvě cesty. Nová jde přes ovladač s revizí 2 a winevulkan 1.4.357 nebo novější; stará přes vrstvu, která zachytává technicky neplatná volání Vulkanu, doplní je a předá rozšíření VK_NV_low_latency2. Nová cesta je podle autorů „do budoucna preferovaná“, má ale háček: spoléhá na to, že si hra rozšíření zapne sama. Red Dead Redemption 2 to nedělá, a proto touhle cestou bez dalšího zásahu nepojede.

Že se „bez dalšího nastavování“ zatím netýká každého, plyne z verzí. Poslední vydání dxvk-nvapi je 0.9.2 z 12. května 2026, tedy starší než commit s revizí 2, a Proton 11.0-2 nese podle seznamu změn právě tuhle verzi. Proton Experimental uvádí, že dxvk-nvapi aktualizoval „na poslední vývojové verze“, datum u toho záznamu ale není. Winevulkan 1.4.357 je ve Wine 11.14, jak stojí v souboru make_vulkan té verze. Kdo chce Reflex bez vrstvy hned, potřebuje ovladač 615, dost nové Wine a dxvk-nvapi z vývojové větve.

Co dalšího ovladač mění

• Opravuje chybu, kvůli které VK_NV_low_latency2 nezkracovalo prodlevu na swapchainech vytvořených pro Wayland (VK_KHR_wayland_surface) a pro přímý výstup na displej (VK_KHR_display).
• Odstraňuje zamrzání při startu a při přepínání oken se zapnutou funkcí Smooth Motion.
• Přidává rozšíření VK_EXT_cluster_acceleration_structure a zavírá únik popisovačů souborů při odpojení knihovny libGLX_nvidia.so.0.
• Opravuje chybu Xid 109 při načítání hry Pragmata na Waylandu a poškozený obraz při škálování výstupu na kartách generace Blackwell.
• Zavádí rozdělení paměti přes cgroups a nový parametr jaderného modulu RmDisableDisplayGlitchPerfLimit. Ten může snížit spotřebu v klidu u sestav s více monitory, ovšem za cenu, že se takty paměti přepnou i ve chvíli, kdy z ní čte displej, a obraz může na okamžik zaškubat.
• Opravuje probuzení z uspání po předchozí hibernaci. Oznámení odkazuje na pull request #1199 uživatele freenull z 12. června, který je ale na GitHubu dál vedený jako otevřený.
• Řeší vzácnou chybu správnosti výpočtů na Blackwellu u jader CUDA se dvěma a více vnořenými úrovněmi divergence vláken. Oprava může stát výkon; NVIDIA radí přeložit program překladačem NVCC 13.2.2 nebo novějším a chování jde řídit proměnnou CUDA_SELECTIVE_DEVICE_CODE_RECOMPILE s hodnotami DEFAULT, FORCED a DISABLED.

Oznámení na vývojářském fóru NVIDIA, které zveřejnil moderátor aplattner, má oproti stránce ovladače o řádek víc: volba NVreg_UseKernelSuspendNotifiers=1 je nově zapnutá ve výchozím stavu. Na stránce ke stažení tenhle bod chybí.

První hlášení z fóra

Den po vydání se na fóru objevilo hlášení, že na desce Radxa Orion O6 s čipem CIX P1 (architektura ARM64) a kartou GeForce RTX 5050 selhává s novým ovladačem hardwarový enkodér NVENC chybou 21, zatímco s předchozím vydáním 610.57.04 funguje. Je to jediný uživatel na nezvyklé sestavě a ve chvíli psaní bylo vlákno bez odpovědi. Jako připomínka, že jde o méně prověřenou větev, to ale stačí.

Balík ke stažení má na webu NVIDIA 530 MB. Distribuce si ovladač balí samy, takže záleží na tom, kdy ho převezmou.

Zdroje

• NVIDIA: Linux x64 Display Driver 615.71.09
• NVIDIA Developer Forums: 615 release feedback & discussion
• GitHub: vydání open-gpu-kernel-modules
• Khronos: VK_NV_low_latency
• GitHub: dxvk-nvapi, README
• Phoronix: NVIDIA 615.71.09 Linux Driver Released With Vulkan Improvements
• GamingOnLinux: NVIDIA driver 615.71.09 released for Linux

Zkouška napodobuje boční náraz se změnou rychlosti 30 km/h

Normu 213a zavedl NHTSA pravidlem z 30. června 2022, kterým plnil zadání Kongresu ze zákona MAP-21 z roku 2012. Návrh přitom úřad zveřejnil už v roce 2014. Do té doby musely americké autosedačky projít jen čelní zkouškou podle normy 213, která platí od sedmdesátých let.

Zkouška na boční náraz se dělá na saních. Podle rozboru Safe Ride News, časopisu pro instruktory dětské bezpečnosti, napodobuje náraz jiného vozu do boku auta na straně, kde dítě sedí, se změnou rychlosti 30,5 km/h. Sedačka sedí ve zkušebním sedadle SISA u napodobeniny dveří, které se během zkoušky vtlačují dovnitř. Pravidlo z roku 2022 upřesňuje, čemu to odpovídá: zkoušce vozidel podle normy 214, kde bariéra o hmotnosti 1 360 kg jedoucí 48,3 km/h narazí do boku vozu jedoucího 24 km/h. Sedačka musí figurínu udržet, utlumit síly a zabránit tomu, aby hlava narazila do dveří. Zkouší se každá sedačka pro děti do 18 kg nebo do výšky 1 100 mm, a to jak upevněná systémem ISOFIX (v USA LATCH), tak bezpečnostním pásem.

Norma pracuje se dvěma figurínami. Pro sedačky doporučené pro děti od 5 do 13,6 kg je to CRABI-12MO, figurína ročního dítěte o hmotnosti 10 kg. Pro sedačky pro děti od 13,6 do 18 kg vyvinul úřad figurínu Q3s, tříleté dítě s čidly pro boční náraz. U ní se navíc měří stlačení hrudníku. Větší figurínu, která by dávala spolehlivé údaje, úřad nemá, proto zkouška končí u 18 kg. Starší děti podle něj už sedí dost vysoko na to, aby je chránil boční hlavový airbag vozu.

O odklad žádali malí výrobci, velcí byli proti

Podnět k odkladu dala skupina výrobců s malým podílem na trhu; v připomínkách k návrhu ji tvořilo šest firem, Baby Trend, Babyark, Diono, Doona, KidsEmbrace a WAYB, spolu s poradenskou firmou DECA Consulting. Argumentovali tím, že nemají vlastní zkušebny a jsou odkázaní na komerční laboratoře, jejichž saně jsou přetížené. Výsledky se navíc podle nich liší mezi laboratořemi i uvnitř jedné, takže tentýž návrh musí zkoušet na víc místech. Bez odkladu by prý museli část modelů stáhnout z výroby. NHTSA na to reagoval návrhem z 30. května 2025 a od 30. června 2025, kdy měla norma začít platit, normu nevymáhal. Nové datum 5. prosince 2026 navrhli sami žadatelé; je to den, od kterého povinně platí i přepracovaná čelní norma 213b.

K návrhu přišlo patnáct připomínek a dvě byly proti. Dorel Juvenile Group a Graco Children's Products, tedy dva z největších výrobců, kteří mají vlastní laboratoře, napsali, že většina sedaček na trhu normu 213a splňuje už měsíce. Graco uvedlo, že obchodní řetězce chtěly mít k datu účinnosti v nabídce jen sedačky s certifikací 213a, nakupují je od podzimu 2024 a ostatní přestávají odebírat, takže žádný nedostatek nehrozí. Odklad podle něj „trestá na trhu firmy, které do plnění normy 213a investovaly podle původního tříletého harmonogramu“ (překlad redakce). Dorel dodal, že odklad nevyřeší rozptyl výsledků mezi laboratořemi, na to by byl potřeba další výzkum.

Úřad odklad přesto schválil. Zvažoval podle svých slov celý trh: kdyby malí výrobci museli odejít, ubylo by konkurence i výběru, kdežto výrobci, kteří normu plní, získají do prosince náskok, protože bez certifikace se do velkých řetězců nedostanou. Dopočítal také, že odklad na bezpečnosti moc neubere. Pravidlo z roku 2022 odhadovalo přínos normy na 3,7 zachráněného života a 40,9 vážných zranění ročně; protože sedačky velkých výrobců, které tvoří většinu prodejů, normu už plní, má se většina toho přínosu naplnit i tak. Úsporu pro spotřebitele, kterou návrh z května 2025 odhadl na 10,58 milionu dolarů, úřad přepočítal na 2,65 milionu. Nový odhad počítá s tím, že velcí výrobci s 60 % trhu certifikují před prosincem všechny sedačky, střední s 30 % trhu polovinu a malí s 10 % trhu žádnou.

Sedačky do školních autobusů zkoušku neprojdou, tak z ní vypadly

Druhou změnu si vyžádali výrobci IMMI a BESI. Jejich zádržné systémy pro školní autobusy, u IMMI se jmenuje STAR, jsou popruhy připevněné k tuhé základně, která se montuje na opěradlo a sedák autobusového sedadla. Nemají žádnou skořepinu, takže bočnímu nárazu nebrání a zkoušku podle 213a projít nemohou. IMMI i BESI napsaly, že by musely výrobu pro americký trh zastavit; systémy používají mimo jiné školky programu Head Start. Úřad uznal, že boční náraz do školního autobusu vypadá jinak než zkouška, která napodobuje náraz do malého osobního auta, a sedačky do školních autobusů z normy 213a vyňal. Zároveň je v normách 213 a 213b zprostil povinnosti mít úchyty pro kotvy ISOFIX, které autobusová sedadla nemívají (o odkladu nových požadavků na kotvy ve vozidlech jsme psali v srpnu), a upravil povinný text štítku tak, aby popisoval skutečný způsob montáže. Štítky podle normy 213 se mají změnit do 8. prosince 2026.

Figurína ročního dítěte už sedačky po směru jízdy zkoušet nebude

Třetí změna srovnává boční zkoušku s čelní. Norma 213b zakazuje doporučovat sedačku po směru jízdy pro dítě lehčí než 12 kg. Zkoušet takovou sedačku s desetikilovou figurínou CRABI-12MO tedy podle úřadu nedává smysl, protože jde o dítě, pro které se sedačka doporučovat nesmí. Figurína se od účinnosti pravidla použije jen u sedaček proti směru jízdy a úřad k tomu přepsal postup jejího usazení. Na bezpečnost to podle něj nemá vliv, výrobcům to ušetří asi 1,29 milionu dolarů ročně za zkoušky. Kdo chce, smí všechny tři normy včetně dnešních změn plnit dřív.

Pro rodiče v USA se toho mění málo. Consumer Reports už v červnu 2025 psal, že stávající sedačku není třeba vyměňovat a že výrobci nemají povinnost splnění normy 213a na obalu uvádět, i když někteří to dělají. Podle téhož textu s sebou nová norma nese i posun mezí: skořepiny pro kojence končí u 13,6 kg místo dřívějších 15,9 kg, které někteří výrobci uváděli, a spodní hranice pro sedačku po směru jízdy stoupá z 10 na 12 kg. Consumer Reports k tomu připomíná, že evropské sedačky podobnou ochranu při bočním nárazu podle unijních předpisů mají už dávno, takže americká norma v tom Evropu dohání.

Zdroje

• Federal Motor Vehicle Safety Standard No. 213a; Child Restraint Systems – Side Impact Protection; … Final rule, Federal Register, 9. září 2026
• Notice of proposed rulemaking; Grant of petitions for rulemaking, Federal Register, 30. května 2025
• Notice of enforcement discretion, Federal Register, 2. července 2025
• Federal Motor Vehicle Safety Standards; Child Restraint Systems, Child Restraint Systems – Side Impact Protection; Final rule, Federal Register, 30. června 2022
• Q & A: New Side-Impact Rule, FMVSS 213a, Safe Ride News, 18. září 2022
• What the New Child Car Seat Regulations Mean for Parents, Consumer Reports, 24. června 2025

Co konkrétně z jádra mizí

První patch bere procesory Intel StrongARM SA1100 a s nimi kapesní počítače z přelomu tisíciletí: v souborech, které série maže, jsou konfigurace pojmenované h3600 a jornada720, tedy Compaq iPAQ H3600 a HP Jornada 720. Druhý patch odstraňuje platformu Footbridge, což byl podle commitu, který ji loni v srpnu označil za zastaralou, hlavně síťový počítač Corel NetWinder a vývojová deska DEC EBSA285 z roku 1997. NetWinder byl v roce 1998 hlavním cílem první verze Debianu pro ARM; Debian ho přestal podporovat v roce 2011. Třetí patch maže Acorn RiscPC, poslední britský stolní počítač s procesorem ARM, který jádro dosud znalo.

Dál jdou pryč staré popisy desek pro čipy Marvell Orion, Dove a MV78xx0, soubory pro PXA včetně kapesních počítačů Sharp Zaurus (v jádře vedených pod jménem spitz), procesory TI OMAP2 (s nimi tablety Nokia N800 a N810) a Freescale i.MX31. Zbytek série se týká mikrořadičů bez paměťové jednotky: NXP i.MX RT, LPC18xx a LPC43xx, řady STM32 F4, F7 a H7 od STMicroelectronics, vývojové platformy Arm MPS2, Microchip SAM V7 a serverových čipů LSI Axxia. U mikrořadičů STM32 to znamená i vývojové desky Discovery, jejichž popisy série maže po jedné.

Proč se to děje právě teď

Označení „zastaralé“ dostaly tyhle platformy během slučovacího okna jádra 7.3. Bergmann to v žádosti o sloučení z 19. srpna zdůvodnil tím, že jde o kód, který „má sklon překážet úklidu a novým funkcím, ale má skoro nulové uživatele“. Konkrétně jmenoval 22 z 28 zbývajících popisů desek, které předcházejí dnešnímu devicetree; zbylých šest je pro TI OMAP1 a Samsung S3C64xx a všech šest má známé uživatele, takže zůstávají. K tomu přidal podporu jader Cortex-M3, M4 a M7 a ARM1136r0 s 25 stroji, které na nich stojí, a čtyři druhy binárek v uživatelském prostoru: be8, be32, OABI a iWMMXt.

V jádře 7.3 se nic nemazalo schválně. Sedmička trojka má být letošní verzí s dlouhodobou podporou, takže kdo některou z platforem opravdu používá, má na ní zůstat několik let. Text v konfiguraci jádra to říká přímo: podpora těchto strojů zmizí v roce 2027, „pokud se neozvou zbývající uživatelé“.

Plán je starší než letošní léto. Poprvé Bergmann tyhle platformy navrhl k odstranění v červenci 2024 a commit označující Footbridge nese datum ze srpna 2024. Podle Phoronixu pak v červenci 2026 sám přiznal, že to „nechal spadnout pod stůl“, a diskusi otevřel znovu s cílem odstranit kód počátkem roku 2027, tedy po letošní verzi s dlouhodobou podporou.

Třináct patchů je začátek, ne konec

V průvodním dopisu Bergmann píše, že úklid zastaralého kódu „se rozrostl na větší práci, než jsem čekal“; v jeho pracovní větvi je teď zhruba 300 patchů a hodně z nich se ještě musí rozdělit na menší. První série bere jen adresáře arch/arm/mach-* a ta místa, která na smazaných volbách Kconfigu přímo závisejí. Architekturní vlastnosti a ovladače zařízení, které po odstranění platforem nikdo nepoužívá, přijdou zvlášť. Část z nich může stihnout verzi 7.4, u většiny ale míří na 7.5, „aby zůstaly závislosti jednoduché“. Phoronix jeho slova čte tak, že se Bergmann kloní k 7.5 i u téhle první série; v dopisu samém stojí jen to, že 7.5 platí pro většinu toho, co následuje.

Odklad má i druhý důvod: dává lidem čas ozvat se, „kdyby se ukázalo, že některý z odstraňovaných kódů má přece jen aktivní uživatele, dřív než zmizí i všechny odpovídající ovladače“. Ve vlákně se do večera ozval jediný člověk. Randy Dunlap, který v jádře spravuje dokumentaci, se zeptal, proč v žádném z patchů nevidí dokument netwinder.rst a konfiguraci NetWinderu, a jestli může jít pryč i dokumentace k emulátoru plovoucí čárky NWFPE. O tři minuty později se omluvil, že mu druhý patch prostě ještě nedorazil. Zůstala otázka na NWFPE; Bergmann odpověděl, že emulátor používají všechny platformy se starým rozhraním OABI, takže jeho odstranění patří až do další série, která nejdřív zruší OABI.

Co v jádře zůstává na dlouho

Bergmann celou situaci popsal loni v září na konferenci Open Source Summit Europe; LWN jeho přednášku shrnul. Podporu starého hardwaru podle něj nejde odstraňovat po pevných lhůtách, spíš „po poločasech“: jednou za čas se ukáže, že polovina zbývajících platforem nemá uživatele, a ta jde pryč. Kolem 90 % vestavěných systémů s Linuxem běží na ARMu a 32bitové desky s architekturou ARMv7 se pořád vyrábějí, takže ty musí jádro podporovat nejméně dalších deset let. Kdo potřebuje spouštět 32bitové aplikace na 64bitovém procesoru, má podle něj sáhnout po 32bitovém uživatelském prostoru nad 64bitovým jádrem, ne po 32bitovém jádru.

Přesně tam tahle série sedí: ARMv4 s StrongARMem, rané ARMv6 a jádra Cortex-M patří k tomu, co Bergmann už loni jmenoval jako kandidáty na odstranění. Odstranění podpory vysoké paměti (highmem) plánoval zhruba na rok 2027 a systémů bez paměťové jednotky na rok 2028; první z těch termínů se právě s touhle sérií začíná plnit.

Zdroje

• [PATCH 00/13] ARM: deprecated platform removal, Arnd Bergmann, konference linux-arm-kernel, 8. září 2026, včetně odpovědi Randymu Dunlapovi
• Merge tag soc-arm-7.3, hlavní větev jádra, 19. srpna 2026
• ARM: mark footbridge as deprecated, commit v hlavní větvi jádra
• arch/arm/mach-sa1100/Kconfig, hlavní větev jádra
• The Linux Kernel Planning To Remove Around ~55k Lines Of Old ARM Platform Code, Phoronix, 8. září 2026
• Linux 7.3 Deprecates Many Older 32-bit ARM Platforms, Orphans Hundreds Of Drivers, Phoronix, 19. srpna 2026
• Linux Looking To Retire A Number Of Old ARM Platforms In Early 2027, Phoronix, 2. července 2026
• The future of 32-bit support in the kernel, LWN.net, 1. září 2025

Vykřičník na místě návratového typu znamená v Rustu, že se funkce normálním návratem nikdy neskončí. Shodí program panikou, zavolá std::process::exit, nebo se zacyklí. Ten vykřičník je přitom sám o sobě typ. Jmenuje se never a je to typ, do kterého se nedá uložit žádná hodnota, protože žádná hodnota toho typu neexistuje.

fn konec() -> ! {
    panic!("dál to nejde");
}

Návrh, který z vykřičníku měl udělat plnohodnotný typ, nese datum 19. července 2015 a v repozitáři překladače k němu od července 2016 visel sledovací záznam. Zavřel se 24. srpna 2026, kdy se do hlavní větve sloučila změna od vývojáře vystupujícího jako WaffleLapkin. Do té doby se ! mimo návratový typ funkce – tedy jako parametr generika nebo položka struktury – dal psát jen na vývojovém kanálu nightly a za přepínačem #![feature(never_type)].

Odvozování, kvůli kterému to trvalo

Sám typ problém nebyl. Potíž dělá odvozování, kterému se v Rustu říká never type fallback. Když překladač narazí na hodnotu typu ! tam, kde se čeká něco jiného, smí ji přetypovat na cokoli – ta hodnota totiž nemůže vzniknout, takže na výsledku nezáleží. Občas ale nemá z čeho poznat, na co ji vlastně převádí, a musí si nějaký typ dosadit sám. Léta dosazoval prázdnou n-tici ().

V edici 2024 už si na tom místě dosazuje !. Srpnová změna to rozšiřuje na všechny starší edice a právě tohle je ta nekompatibilní část. Projeví se hlavně u operátoru ?:

fn x<T: Default>() -> Result<T, ()> { Ok(T::default()) }

x()?;   // dřív se za T dosadilo (), nově !

Typ ! ovšem trait Default neimplementuje, takže se takový řádek přestane překládat. Opravou je typ vypsat: x::<()>()?;, nebo () = x()?;.

Sedm balíčků přímo, zbytek přes staré závislosti

Kolik cizího kódu změna rozbije, se v Rustu měří nástrojem crater, který zkusí přeložit balíčky z registru crates.io. Rozbor toho běhu je z 21. dubna 2026 a autor v něm počítá kolem tří tisíc pádů. Přímo, tedy vlastním kódem, jich ale selhalo sedm: mezi nimi čtyři balíčky, které volají knihovnu redis bez uvedení typu vrácené hodnoty, a jeden test v srt-tokio.

Všechno ostatní jsou balíčky, které do překladu vtáhla stará verze závislosti. Autor u nich píše, že opravená novější verze existuje prakticky u všech, a připomíná, že varování na tenhle vzorec chodí dlouho: ve vlastním kódu od změny 125289, v závislostech od změny 141937, tedy podle jeho slov skoro rok. Sám k tomu dodává, že delším čekáním by se čísla nejspíš nezlepšila.

Dvakrát už to stabilizované bylo

První pokus to není. V dubnu 2018 se stabilizace ! a traitu TryFrom vrátila zpět kvůli chybě, která souvisela právě s dosazováním typů. Podruhé se ! stabilizoval pro vydání 1.41: změna se sloučila 21. listopadu 2019 a 15. prosince téhož roku ji vývojáři zase vzali zpět, protože se objevily regrese.

Ve standardní knihovně ubyl jeden samostatný typ

Se stabilizací se mění i standardní knihovna. Typ Infallible, kterým se označuje chyba, jež nemůže nastat, je nově jen jiné jméno pro !. Lint dependency_on_unit_never_type_fallback mizí, protože po změně odvozování nemá na co upozorňovat. Úklid po stabilizaci se sloučil 28. srpna 2026.

Ke stabilnímu překladači to dorazí 12. listopadu

Změna má v repozitáři milník 1.100.0. Podle plánu vydání se větev pro tuhle verzi oddělí od hlavní 25. září 2026 a stabilní vydání vyjde 12. listopadu 2026. Zatím je stabilní verzí 1.98 z 20. srpna, takže kdo nepoužívá nightly, na vykřičník ještě čeká.

Až se změna dostane ven, přestanou být potřeba prázdné výčty typu enum Never {}, kterými se ! na stabilním překladači obcházel. A zápis Result<T, !> začne říkat přesně to, jak vypadá: tahle funkce chybu vrátit nemůže.

Zdroje

• rust-lang/rust#155499 – stabilize never type
• RFC 1216 – bang type
• Sledovací záznam rust-lang/rust#35121
• Rust Forge – plán vydání
• LWN.net: Stabilizing Rust's never type (zatím jen pro předplatitele, volně od 17. září 2026)
• Rust Bytes #135: The Never Type Is Finally Stable!

Web za reverzní proxy má v $_SERVER['REMOTE_ADDR'] adresu té proxy, ne návštěvníka. Skutečnou adresu klienta nese hlavička, kterou k požadavku připojí proxy cestou k aplikaci – a protože je to obyčejná hlavička, umí ji poslat i klient sám. Knihovna Nette Http ve verzi 3.4.1 z 27. srpna 2026 přepsala, jak se z ní adresa čte, a zpřísnila výchozí nastavení.

Proxy svůj údaj připisuje na konec

Standardní podobu té hlavičky popisuje RFC 7239 z června 2014. Proxy, která chce přidat svůj údaj, ho podle něj připojí za čárku k tomu, co v hlavičce už stojí. Vznikne řetěz zastávek a nejlevější položka je ta nejbližší klientovi:

Forwarded: for=203.0.113.7, for=192.0.2.1;proto=https;host=example.org

Kdo chce z takového řetězu vyčíst adresu skutečného návštěvníka, musí od pravého konce odečíst zastávky, které patří jeho vlastním proxy, a vzít první zbylou. Samo RFC k tomu dodává, že se na obsah hlavičky nedá spolehnout: změnit ji může každý uzel po cestě včetně klienta, který požadavek posílá.

Původní kód bral levý kraj řetězu

Nette do verze 3.4.0 dělalo pravý opak. Z hlavičky Forwarded vybíralo první hodnotu for – jenže tu tam nezapsala žádná proxy, dorazila od klienta. Kdo poslal vlastní hlavičku Forwarded a proxy ji nesmazala, podstrčil aplikaci libovolnou adresu i tehdy, když byla proxy nastavená správně.

Rozbor, který k opravě vznikl, uvádí vady čtyři. Druhá je v rozebírání hlavičky: kód dělil řetězec výrazem preg_split('/[,;]/'), takže oddělovač zastávek slil dohromady s oddělovačem parametrů uvnitř zastávky. Struktura se tím ztratila a údaje proto a host nešlo přiřadit ke správné zastávce. Kód je proto bral, jen když byl v hlavičce právě jeden – a u každé poctivé vícezastávkové hlavičky o ně přišel.

Třetí vada: větev pro nestandardní X-Forwarded-For už tehdy uměla důvěryhodné proxy odečíst a vzít pravý kraj. Táž úloha tak měla v jedné knihovně dvě různá řešení, každé jinak nedodělané. A čtvrtá: RFC dovoluje místo adresy zapsat zástupný identifikátor for=unknown, který se z getRemoteAddress() vracel jako obyčejný řetězec, přestože ta metoda slibuje IP adresu.

Nette teď bere nejpravější zastávku, která už není jeho proxy

Přepsaný kód rozebírá hlavičku po zastávkách: nejdřív podle čárek na položky, pak podle středníků na parametry. Adresu klienta hledá společná metoda findClientHop(), kterou používají obě větve – odstraní z konce řetězu důvěryhodné proxy a vrátí nejpravější zbylou zastávku. Není-li v ní platná IP adresa, vrátí null; getRemoteAddress() tedy nově dává adresu, nebo nic.

Schéma a hostitele bere Nette ze stejné zastávky jako adresu, tedy z položky, kterou zapsala proxy obrácená ke klientovi. Podvrhnout je proto nejde a vícezastávková hlavička už nepotřebuje výjimku. Platí u ní k tomu pravidlo všechno, nebo nic: když se adresa klienta určit nepodaří, nepoužije se z hlavičky ani schéma, ani hostitel.

U rodiny X-Forwarded-* to takhle jít nemůže, protože tyhle hlavičky žádnou strukturu položek nemají. X-Forwarded-Host se čte na stejném indexu jako adresa klienta a bez ní se přeskočí, zato X-Forwarded-Proto a X-Forwarded-Port se použijí, kdykoli požadavek přišel přes důvěryhodnou proxy. Důvod je praktický: server, který jen ukončuje šifrované spojení, posílá právě jen X-Forwarded-Proto. Po hlavičkách rozdělenou důvěru zná i Symfony, kterému se v nastavení vyjmenuje, kterým hlavičkám od proxy věřit.

Výchozí nastavení už hlavičce Forwarded nevěří

Druhá půlka změny je konfigurace. Přibyla volba proxyHeaders se čtyřmi hodnotami – both, xForwarded, forwarded a none – a rozšíření pro Nette DI ji nastavuje na xForwarded:

http:
	proxy: 10.0.0.0/8
	proxyHeaders: xForwarded   # výchozí, dál forwarded, both, none

Aplikace za proxy tedy klientem poslané hlavičce Forwarded nevěří, dokud si to provozovatel nevyžádá. Komu ji proxy opravdu nastavuje, ten volbu přepne na forwarded nebo both – je to jediná změna, kvůli které se knihovna nedá aktualizovat naslepo. Volání setProxy() z PHP zůstává na both, aby se nerozbil kód, který si knihovnu obsluhuje sám. Bez vyplněného seznamu proxy se ostatně nečte žádná z těch hlaviček vůbec.

Zbytek rizika se rozborem hlavičky odstranit nedá

Kterou hlavičku knihovna použije, rozhoduje jejich přítomnost: když dorazí obě a věří se oběma, vyhrává Forwarded. Z pouhé přítomnosti se ale nepozná, jestli hlavičku napsala proxy, nebo jestli ji poslal klient a proxy ji jen propustila dál. Proxy, která spravuje X-Forwarded-For a cizí Forwarded předává beze změny, tak aplikaci podstrčí podvrženou hodnotu i po opravě.

Autoři to v rozhodnutí přiznávají natvrdo. Rozborem hlavičky se to vyřešit nedá a týká se to stejně Symfony i Laravelu; proti tomu míří právě výchozí xForwarded, které propuštěnou hlavičku Forwarded ignoruje. Zbytek zůstává na správci proxy, která by měla zahodit každou hlavičku pro předávání, kterou sama nenastavuje.

Skriptům z příkazové řádky přibyla adresa

Druhá novinka téhož vydání s bezpečností nesouvisí. Skript spuštěný z příkazové řádky – cron, údržbová úloha – nemá v poli $_SERVER žádného hostitele, takže adresa požadavku nedávala smysl a všechno od ní odvozené taky ne. Nová volba http: baseUrl a metoda RequestFactory::setBaseUrl() takovému běhu adresu dodají, aby fungoval generátor odkazů i cesty ke statickým souborům v šablonách. Uplatní se jen tehdy, když se hostitele nedá zjistit odjinud, takže požadavků z webu se to netýká.

Ve stejné knihovně přibyl v červnovém vydání 3.4.0 i nástroj proti útokům, kdy aplikaci někdo přiměje stáhnout adresu podle svého: dvojice IPAddress a UrlValidator umí adresu prověřit a vrátit i zjištěné IP adresy, aby se spojení dalo přišpendlit na ně. Nette Mail zase z podpisu DKIM vypustil údaj o délce těla, kvůli kterému šlo k podepsané zprávě připsat cizí text.

Zdroje: poznámky k vydání Nette Http 3.4.1, přehled vydání na nette.org, rozhodnutí o čtení hlaviček v repozitáři knihovny, RFC 7239, dokumentace Symfony k reverzním proxy.

Snímky z marsovských roverů necestují na Zemi přímo. Vozítko je vyšle nahoru družici, která zrovna přelétá nad ním, a ta je z výšky pošle do velkých antén na Zemi. Tuhle štafetu obstarává od roku 2004 hrstka sond, které u Marsu dělají hlavně něco jiného; přenos je jejich vedlejší práce. NASA teď zadala první stroj, který by u planety měl dělat výhradně to.

Smlouva s pevnou cenou a dvěma termíny

Úřad podepsal smlouvu v úterý 1. září a oznámil to v tiskové zprávě C26-010. Blue Origin má družici navrhnout, postavit, vypustit a provozovat; celku se říká Mars Telecommunications Network a spravovat ho bude program NASA pro komunikaci a navigaci ve vesmíru (SCaN).

Cena je pevná se stropem zhruba 700 milionů dolarů. Pevná cena znamená, že překročení rozpočtu nese dodavatel, ne objednatel. Termíny jsou dva a je mezi nimi víc než rok: hotový stroj má NASA převzít nejpozději 31. prosince 2028, u Marsu má síť fungovat v roce 2030. Poptávku po nabídkách vypsal úřad letos v květnu.

Základem je platforma Blue Ring

Družice vychází z Blue Ringu, univerzální nosné platformy, kterou Blue Origin vyrábí v Huntsville v Alabamě. Podle firemního popisu kombinuje solárně-elektrický pohon s chemickým, zvládne změnu rychlosti 3 000 až 4 000 metrů za sekundu, má až dvanáct bočních portů typu ESPA Grande a jeden velký čelní a unese přes 4 000 kilogramů nákladu, podle sestavení. Vypustit se dá na New Glennu i na jiné raketě s pětimetrovým krytem.

Ve vlastním oznámení firma dodává, že několik kusů Blue Ringu už staví a linka je dimenzovaná na čtyři stroje ročně, že družice ponese softwarově definovaná rádia a že umí měnit dráhu, takže se síť dá později rozšířit. Zakázku podle ní zaplatil Kongres ze zákona Working Families Tax Cut Act. Prezident divize Blue National Security Tory Bruno k tomu řekl, že orbiter bude páteří amerického programu průzkumu Marsu na příští dekádu a dál; je to hodnocení dodavatele, ne úřadu.

Blue Origin má s NASA rozdělaného víc: druhý stupeň rakety New Glenn se má zažehovat na zkušební stolici B2 ve Stennisově středisku.

Dnešní síť má čtyři sondy a nejstarší z nich létá od roku 2001

Mars Relay Network je společné dílo NASA a evropské ESA. Tvoří ji Mars Odyssey u planety od roku 2001, evropský Mars Express od roku 2003 v roli zálohy, Mars Reconnaissance Orbiter vypuštěný v roce 2005 a u planety od března 2006 a evropský Trace Gas Orbiter od roku 2016. Roveru se hodí proto, že sám na Zemi nedohlédne asi dvanáct hodin denně, jak se planeta otáčí, a přímé spojení by po něm chtělo velkou anténu a hodně elektřiny. S družicí nad hlavou si přitom vymění až dva megabity za sekundu.

Dolů na Zemi to jde přes tři skupiny antén: americkou Deep Space Network, evropskou síť ESA a ruský komplex, na který se váže jen Trace Gas Orbiter. Cesta signálu trvá podle vzájemné polohy planet od tří do 22,4 minuty, protože Mars je od Země vzdálený 54,6 až 400,2 milionu kilometrů. Každý snímek z povrchu Marsu, který svět od roku 2004 viděl, prošel touhle sítí.

Po ztrátě MAVENu veze nejvíc dat evropská sonda

Sonda MAVEN, která do sítě přispívala druhým největším objemem dat, se odmlčela 6. prosince 2025, když zmizela za planetou. NASA svolala v únoru komisi, ta uzavřela, že stroj není možné oživit, a 3. června 2026 úřad misi ukončil.

Jak se to projevilo, je vidět na vlastní tabulce NASA. Průměr do konce roku 2025 proti průměru za únor až květen 2026: Trace Gas Orbiter 1 562,7 → 2 228,1 megabitu denně, Mars Reconnaissance Orbiter 447,5 → 850,6, Odyssey 170,4 → 107,3 a MAVEN 897,5 → nula. Nejvíc dat z Marsu tedy dnes veze evropská sonda, ne americká.

Peníze byly na světě dřív, než MAVEN utichl

Souvislost mezi ztrátou MAVENu a novou zakázkou se nabízí, jenže data ji nepodpírají. Peníze na telekomunikační orbiter schválil Kongres už v červenci 2025, tedy pět měsíců předtím, než sonda ztichla, požadavky na stroj sepsala NASA v únoru 2026 a poptávku vypsala v květnu. Tisková zpráva úřadu MAVEN vůbec nezmiňuje.

O zakázku se ucházel i Rocket Lab, který svou verzi orbiteru popsal na vlastních stránkách a slibuje ji na rok 2028. Ty stránky tam po prohraném výběru zůstaly.

Co se z dostupných dokumentů zjistit nedá, je pořadí uvnitř hodnocení: NASA nezveřejnila, kolik nabídek dostala ani jak si vedly. Zůstává tak jediné tvrdé číslo o budoucnosti sítě, a to termín. Do konce roku 2028 má stát družice na Zemi, v roce 2030 pracovat u Marsu.

Zdroje

• NASA: NASA Selects Blue Origin as Mars Telecommunications Network Provider, tisková zpráva C26-010, 1. září 2026
• Blue Origin: Blue Origin Selected by NASA to Help Build America's Mars Telecommunications Network, 2. září 2026, a popis platformy Blue Ring
• NASA Science: Mars Relay Network – složení sítě, přenesené objemy dat a konec mise MAVEN
• Space.com: Blue Origin wins $700 million contract to build NASA's next Mars orbiter, 2. září 2026 – rozpočtová historie a druhý uchazeč
• Rocket Lab: Mars Telecommunications Orbiter – nabídka konkurenta

Jeden znak v hlavičce

Chyba má číslo CVE-2026-48710 a přezdívku BadHost. Starlette si adresu požadavku, kterou nabízí pod request.url, skládá ze tří kusů: schématu, hodnoty hlavičky Host a cesty z prvního řádku požadavku. Výsledný řetězec pak znovu rozebere. Do vydání 1.0.1 přitom nekontrolovala, jestli hodnota v Host vůbec odpovídá mluvnici, kterou pro ni předepisuje RFC 9112 v oddílu 3.2 – tedy jestli je to jméno stroje a nanejvýš ještě port.

Když se do té hlavičky dostane lomítko, otazník nebo křížek, posunou se při novém rozboru hranice mezi cestou, dotazem a fragmentem. Požadavek GET /foo s hlavičkou Host: example.com/abc?bar= se poskládá na http://example.com/abc?bar=/foo, a request.url.path z toho vrátí /abc.

Směrovač Starlette se ale řídí skutečnou cestou z požadavku, ne tou poskládanou. Obsluha se spustí ta pro /foo, kdežto mezivrstva, která si přečte request.url.path, vidí /abc. Kdo na tom postavil kontrolu přístupu, má ji obejitelnou. Doklad, který k chybě vydala německá firma X41 D-Sec, se vejde na dva řádky:

curl -i -H 'Host: foo'  http://target/admin    # 403 Forbidden
curl -i -H 'Host: foo?' http://target/admin    # 200 OK

Našlo se to při auditu serveru vLLM

Starlette je základ frameworku FastAPI a na FastAPI stojí velká část nástrojů kolem jazykových modelů. X41 D-Sec na chybu narazila 27. ledna 2026 při čtení zdrojového kódu serveru vLLM; ten audit platila nadace OSTIF z peněz projektu Alpha-Omega. Výčet dotčeného softwaru, který OSTIF k chybě zveřejnila, jmenuje vedle vLLM i bránu LiteLLM, Text Generation Inference, servery MCP a rozhraní pro správu modelů.

Že to není jen teorie, ukázala v červnu firma Horizon3. Její výzkumníci spojili BadHost s chybou CVE-2026-42271 v LiteLLM: dvě zkušební koncová místa pro servery MCP tam přijímala celou konfiguraci včetně pole command a spouštěla ji jako podproces. Původně se to bralo jako chyba, ke které je potřeba platný klíč k rozhraní. S BadHostem tahle podmínka padá a zbývá spuštění cizího kódu bez jediné přihlašovací údaje navíc. LiteLLM to opravil 8. května ve verzi 1.83.7 a záznam v katalogu CISA na ten řetěz výslovně odkazuje.

O závažnosti se prameny neshodnou

Kde se prameny rozcházejí, je vážnost. Hlášení správců Starlette dalo chybě podle CVSS 3.1 známku 6,5, tedy střední. X41 D-Sec počítá podle CVSS 4.0 sedmičku a mluví o vysoké závažnosti. Stránka badhost.org, kterou provozují X41 D-Sec, Persistent Security Industries a Bintech, i rozbor na secwest.net píšou rovnou o kritické chybě. OSTIF k odkazu na hlášení z GitHubu připsala, že jeho hodnocení „závažnost té chyby dál v řetězci silně podceňuje“ (v překladu z angličtiny).

Rozdíl dvou tříd není jen slovíčkaření. Podle známky se řídí i to, jak rychle oprava projde distribucemi a jak vysoko ji správce zařadí ve frontě. Vydání Starlette 1.0.1 vyšlo 21. května se seznamem změn o jediné položce a bez zvláštního upozornění, veřejné vyhlášení chyby přišlo den nato. Náskok na nasazení opravy tedy provozovatelé neměli žádný. Podle vlastní časové osy X41 uplynuly od nahlášení do opravy skoro čtyři měsíce, z toho necelé tři ležel navržený patch hotový.

Co s tím

Opravená verze je Starlette 1.0.1 a vyšší. Protože je to skoro vždycky závislost něčeho dalšího, nestačí se podívat na výpis pip list: OSTIF i secwest.net upozorňují, že nástroje kolem jazykových modelů si knihovnu běžně nesou zabalenou v obrazu kontejneru, takže se musí přestavět a znovu nasadit všechno, co ji má připnutou.

Trvalejší je druhá cesta. V mezivrstvách a všude, kde se rozhoduje o přístupu, se místo request.url.path má číst request.scope["path"] – tedy cesta tak, jak ji server ASGI dostal, bez skládání a nového rozboru. Třetí možnost je reverzní proxy, která vadnou hlavičku odmítne; nginx, Apache i Cloudflare to podle X41 dělají ve výchozím nastavení. Aplikace pouštěná přímo na uvicornu, hypercornu, daphne nebo granianu takovou ochranu nemá, a přesně tak bývají zkušební instalace kolem modelů nasazené.

Jestli je konkrétní adresa zranitelná, řekne volně dostupný skener na badhost.org. X41 D-Sec k tomu zveřejnila pravidla pro Semgrep a dotazy pro CodeQL, kterými se dá projet vlastní kód. Ve vlastních záznamech se pokus pozná podle hlavičky Host, ve které stojí lomítko, otazník, křížek, zpětné lomítko nebo zavináč – běžný klient tam žádný z těch znaků neposílá.

Lhůta je delší než u zbytku dávky

U Starlette a LiteLLM dala CISA federálním úřadům čas do 16. září, kdežto zbylým pěti položkám z téže dávky vypršela lhůta už 5. září. Delší termín u těch dvou dává smysl: vyměnit knihovnu schovanou v cizí závislosti trvá déle než nainstalovat záplatu k výrobku. Mimo americkou federální správu je celý katalog jen doporučení – ze zařazení do něj ale plyne, že CISA má doklad o zneužívání téhle chyby při útocích. Jaký ten doklad je, agentura neuvádí.

Zdroje

• CISA: CISA Adds Seven Known Exploited Vulnerabilities to Catalog (2. září 2026) a katalog KEV
• GHSA-86qp-5c8j-p5mr – hlášení správců Starlette
• X41-2026-002: Request Host Header not Validated in Starlette
• OSTIF: Disclosing the BADHOST Vulnerability in Starlette
• Horizon3: CVE-2026-42271 Chained with CVE-2026-48710
• Poznámky k vydání Starlette 1.0.1

Co Anubis dělá

Anubis stojí jako brána před webem a než požadavek pustí dál, nechá prohlížeč spočítat úlohu s ověřitelným výsledkem. Vlastní popis projektu na GitHubu zní „váží duši příchozích požadavků HTTP, aby zastavil crawlery AI“, což naráží na egyptského boha, po kterém se program jmenuje. Jádro je v Go, licence MIT, repozitář vznikl 17. března 2025 a 7. září 2026 měl 22 214 hvězd.

Metoda se jmenuje proof of work a Anubis ji odvozuje od Hashcashe, staršího návrhu proti spamu: pro jednoho návštěvníka je zátěž zanedbatelná, pro toho, kdo stahuje statisíce stránek, se sečte do částky vidět na účtu za výpočetní čas. Autor si o svém programu nedělá iluze a označuje ho za kompromis a za dočasné řešení, než bude čas na rozpoznávání bezhlavých prohlížečů podle jemnějších znaků.

Úlohu nedostane každý. Anubis ji podle dokumentace posílá jen požadavkům, jejichž hlavička User-Agent obsahuje řetězec Mozilla, a vynechává /robots.txt, /favicon.ico, adresář /.well-known a adresy končící na .rss, .xml nebo .atom. Klienti gitu a čtečky RSS tak projdou bez zdržení.

Kdo Anubise používá, vede projekt sám v dokumentaci. Jsou v tom seznamu mimo jiné gitlab.gnome.org, gitlab.freedesktop.org, codeberg.org, wiki Arch Linuxu, sestavovací služba Hydra projektu NixOS a bugzilla WineHQ.

Tři nové funkce místo jedné

Předběžné vydání 1.28.0-pre1 vyšlo 30. srpna 2026 pod kódovým jménem Wuk Lamat a přidává tři výpočty ve WebAssembly: argon2id, hashx a sha256. Všechny jsou napsané v Rustu pro cíl wasm32-unknown-unknown bez standardní knihovny a v konfiguraci se volí u prahu nebo u pravidla:

thresholds:
  - name: moderate-suspicion
    expression:
      all:
        - weight >= 10
        - weight < 20
    action: CHALLENGE
    challenge:
      algorithm: argon2id
      difficulty: 6

Rozdíl proti dosavadní úloze není jen v jazyce. argon2id si vyžádá velkou souvislou oblast paměti, takže se u něj hrubá síla prodraží; hashx dokumentace popisuje jako odolný proti řešení na grafické kartě i na jednoúčelovém čipu. Autor Xe Iaso k tomu píše, že cesta „hele, Claude, zbastli mi řešič Anubise v CUDA“ je na dobré cestě k tomu být z principu mrtvá. sha256 zůstává jen jako záloha – dokumentace u něj rovnou uvádí, že na tuhle úlohu existují známé řešiče.

Druhá změna je organizační: klient i server nepoužívají stejný kód, ale týž binární soubor. Dosud měla rychlá úloha dvě implementace, v JavaScriptu a v Go, a každá oprava se musela udělat dvakrát.

Ve výchozím nastavení jsou nové metody vypnuté. Autor to v poznámkách k vydání zdůvodňuje tím, že si není jistý chováním v okrajových případech; zapnout je jako výchozí chce ve verzi 1.29.0.

Obtížnost rostla po šestnáctinásobcích

Při té příležitosti se opravila i vada, kterou dosavadní úloha vlekla od začátku. Porovnávala řetězce, a počítala tedy vedoucí nulové půlbajty, ne vedoucí nulové bity. Zvýšení obtížnosti o jedničku proto v nejhorším případě znamenalo šestnáctkrát víc práce. Nové výpočty počítají bity a dokumentace k tomu dává převodní tabulku: obtížnosti 4 u staré úlohy odpovídá 4 u argon2id, ale 16 u sha256 a 15 u hashx.

Proč to trvalo rok

Sám autor píše, že první verze byla hotová za pár dní a zbytek roku spolykaly podrobnosti. Anubis podporuje Chrome 75 a novější, protože na téhle verzi uvázla spousta telefonů, televizí a dalších přístrojů s Androidem bez možnosti aktualizace; JavaScript se pro jistotu překládá pro Chrome 66. Instrukce SIMD, které na telefonech znamenají velký rozdíl, ale prohlížeče umějí až od Chromu 91, takže se WebAssembly staví dvakrát a vybírá se podle toho, co zrovna běží.

Klienti, kteří mají WebAssembly vypnuté zásadou – autor jmenuje režim Lockdown v iOS a výchozí nastavení prohlížeče Vanadium v GrapheneOS –, dostanou nouzovou cestu. Hotový modul se nástrojem wasm2js z projektu Binaryen převede zpátky na JavaScript. Výsledek je objemný a běží bez překladače za běhu, takže je pomalý, a ukazatel průběhu se u něj nehýbe; projekt to vede jako známou vadu.

Aby se sestavení nerozcházela mezi vývojářským strojem, CI a distribucemi, přeložil autor sám wasm-opt a wasm2js z Binaryenu verze 128 do WebAssembly a výsledné soubory uložil rovnou do repozitáře. Vlastní věta o tom zní, že vaše nástroje se od jeho nemůžou lišit, když vám je pošle s sebou.

Právě tenhle krok vynesl na světlo chybu v překladači. Každé sestavení se lišilo asi o 29 bajtů a autor to 19. června 2026 nahlásil projektu LLVM jako hlášení číslo 204883. Že nejde o jeho vstupy, poznal podle toho, že vypnutí náhodného rozmisťování paměti (setarch --addr-no-randomize) dalo na jednom stroji pokaždé týž výsledek. Příčinou byly ukazatele použité jako klíče do slovníku ve WebAssembly části překladače, takže pořadí průchodu záviselo na tom, kam se struktury zrovna uložily. Opravu poslal Derek Schuff z týmu LLVM a 27. června 2026 se dostala do hlavní větve.

Zbývala poslední překážka: Chrome 75 modul odmítl s chybou o indexu tabulky. Standardní knihovna Rustu se totiž v rustup stahuje přeložená předem, takže se na ni volby vlastností nevztahují, a jedna její funkce používala referenční typy, které tak starý prohlížeč nezná. Pomohl až průchod přes wasm-opt s přepínačem -mvp, který z modulu vyhodí všechno nad rámec původní definice WebAssembly; zpátky se povolí jen to, co Chrome 75 umí.

Aby to nemusel zkoušet ručně v padesáti prohlížečích, postavil si zkušebnu jménem chromesweep: spouští v ní najednou mnoho verzí Chromu, každou v mikrovirtuálním stroji a se síťovým pravidlem, které jí dovolí jen dotaz na DNS a spojení s testovanou instancí Anubise. Sbírku prohlížečů zveřejnil v červenci 2026 jako repozitář TecharoHQ/gubal.

Co zůstává otevřené

Autor sám vypisuje, co ještě není hotové. Ukazatel průběhu u nouzové cesty se nehýbe. Nové výpočty jsou tak rychlé, že si správci budou muset obtížnost přenastavit. Rozpoznávání telefonů, které by jim podle pověsti adresy a otisku TLS dalo úlevu, je zatím prototyp. A programy s úlohami by chtěl vyměňovat za běhu, ne až při překladu Anubise.

K vlastnímu zápisu autor přiložil odkaz na dokument s historií psaní a poznámku, že se na textu žádný model nepodílel a použil ho jen na vykreslení jednoho diagramu. U programu, který vznikl kvůli robotům sbírajícím text pro modely, to sotva bude náhoda.

Zdroje

• Xe Iaso: It took a year to ship WebAssembly in Anubis, blog projektu Anubis, 6. září 2026 (text je i ve zdrojovém souboru v repozitáři)
• Poznámky k vydání Anubis v1.28.0-pre1, 30. srpna 2026
• Dokumentace: Proof of Work (WebAssembly) a How Anubis works
• Hlášení LLVM č. 204883 a oprava č. 205184
• Seznam známých webů s Anubisem

Když zdraží benzin, míří první otázka na cenu ropy. Letos v Americe sedí jen zpola. Podle rozboru, který americký Úřad pro energetické informace (EIA) vydal 4. září, se na účtu u pumpy stejnou měrou podepsalo rozpětí, které mezi ropou a hotovým palivem inkasuje rafinerie.

Rozpětí není zisk

Crack spread, česky rafinérské rozpětí, je rozdíl mezi velkoobchodní cenou galonu hotového paliva a spotovou cenou galonu ropy. EIA ho počítá z ceny benzinu v přístavu New York Harbor a ze spotové ceny ropy Brent. Je to ukazatel výnosnosti rafinerie, ne její čistý zisk: náklady na provoz, energie ani odstávky v něm nejsou.

Od letošního května bylo rozpětí u benzinu v New York Harbor v průměru asi o dolar na galon vyšší než v roce 2025, kdy vrcholilo kolem šedesáti centů. Dolar na galon dělá v přepočtu zhruba 26 centů na litr.

Kde se ztratily zásoby

Za tím jsou podle EIA napjaté světové zásoby benzinu po výpadcích rafinerií v Rusku, Číně a na Blízkém východě. Dovážené palivo tím zdražilo a poptávka po americkém vývozu vzrostla, takže obojí tlačí na tutéž stranu.

Východní i Západní pobřeží doplňuje vlastní výrobu dovozem, a ten letos vysychá. Od března je celkový dovoz benzinu do Spojených států, tedy hotového paliva i směšovacích složek, o 32 procent pod pětiletým průměrem let 2021 až 2025. Část výpadku nahradily zásilky z pobřeží Mexického zálivu. Ministerstvo vnitřní bezpečnosti k tomu vydalo 17. března omezenou výjimku z Jones Act a od té doby ji obnovuje. Ten předpis jinak žádá, aby náklad mezi americkými přístavy vozily lodě postavené ve Spojených státech, pod americkou vlajkou, v americkém vlastnictví a s americkou posádkou. Přeprava z Mexického zálivu na Východní pobřeží dosáhla v dubnu rekordních 1,2 milionu barelů denně.

Nafta táhne víc než benzin

U středních destilátů, tedy u motorové nafty a topných olejů, a u leteckého petroleje je rozpětí ještě vyšší. Vypadlé rafinerie dodávaly na světový trh větší objemy právě těchhle paliv než benzinu. Od března bylo rozpětí u destilátu v New York Harbor v průměru o 74 centů na galon vyšší než u benzinu a američtí rafinéři na to odpověděli tím, že posunuli výtěžnost pryč od benzinu.

Vidět je to na zásobách. V týdnu do 28. srpna byly podle týdenní zprávy o zásobování ropou zásoby destilátů 14 procent pod pětiletým průměrem, zásoby benzinu jen 6 procent. Rafinerie přitom jely skoro naplno: zpracovaly 17,5 milionu barelů denně, využití kapacity dosáhlo 98 procent, benzinu vyrobily 9,8 milionu barelů denně a destilátů 5,1 milionu.

Kolik to dělá u pumpy

Průměrná americká cena běžného benzinu byla 31. srpna 4,07 dolaru za galon, v přepočtu asi 1,08 dolaru za litr. Rozdíly mezi regiony jsou velké: Západní pobřeží 5,21 dolaru za galon, Skalnaté hory 4,27, Východní pobřeží 3,94, Středozápad 3,85 a pobřeží Mexického zálivu 3,62. Rozdíl dělá místní nabídka a poptávka, státní požadavky na složení paliva a státní daně.

Nejvíc podražila nafta. Přehled cen pohonných hmot u ní uvádí k 31. srpnu 5,599 dolaru za galon, meziročně o 1,865 dolaru víc. Benzin za tutéž dobu zdražil o 0,894 dolaru. V Kalifornii stál galon nafty 7,218 dolaru.

Rekordy padají i v Evropě

Americká čísla nejsou výjimka. Mezinárodní energetická agentura ve své srpnové zprávě o trhu s ropou píše, že sevřený trh s lehkými a středními destiláty vyhnal rozpětí a marže v atlantické oblasti na historická maxima a že v srpnu padaly nové rekordy v Evropě.

Rozhoduje o tom objem zpracované ropy. Světové rafinerie jí v červenci zpracovaly 80,9 milionu barelů denně, skoro o 5 milionů méně než rok předtím. Trvající výpadky vývozu produktů z Blízkého východu a útoky na ruské rafinerie srazily podle agentury odhad zpracování za třetí čtvrtletí o dalších 370 tisíc barelů denně. Vývoz nafty z Ruska, Blízkého východu a Asie byl meziročně nižší o 1,3 milionu barelů denně, což je zhruba pětina světového námořního obchodu s tímhle palivem. U leteckého petroleje činil výpadek asi 670 tisíc barelů denně, tedy třetinu obchodu. Vývoz z amerických rafinerií naopak stoupl o 700 tisíc barelů denně.

Co z toho plyne

Dokud se zpracovatelská kapacita nevrátí, nebude cena ropy sama o sobě dobrým vodítkem k tomu, co se stane u pumpy. Rozhoduje druhý článek řetězu, a ten je letos zatím dražší než ten první. Nejbližší nová čísla přinese aktualizace cen pohonných hmot 9. září a zářijová zpráva o trhu s ropou.

Zdroje

• EIA: Elevated crack spreads and crude oil prices contribute to higher prices at the pump (4. 9. 2026)
• EIA: Gasoline and Diesel Fuel Update (data k 31. 8. 2026)
• EIA: Weekly Petroleum Status Report (týden do 28. 8. 2026)
• EIA: Waterborne shipments from the U.S. Gulf Coast increased in April and May (17. 8. 2026)
• IEA: Oil Market Report – August 2026 (12. 8. 2026)

Tým Technologického institutu v Karlsruhe (KIT) a japonské univerzity v Cukubě popsal chladič, ve kterém není ani kompresor, ani elektromotor. Tah, který chlazení pohání, obstará teplo. Studie vyšla 28. srpna 2026 v Nature Energy a je volně přístupná.

Dvě fólie, dvě různé vlastnosti jedné slitiny

Obě hlavní součástky jsou pásky ze slitiny niklu a titanu, tedy z nitinolu. Každá z nich ale využívá něco jiného.

Hnací fólie je z TiNi, měří 22 mikrometrů, má klidovou délku 19 milimetrů a je předem protažená o 2,7 procenta. Když se ohřeje nad teplotu, při které se její krystalová mřížka překlopí zpátky do výchozí fáze, fólie se stáhne na svůj původní tvar. Je to jednosměrný tvarově paměťový jev, tentýž trik, kterým se nad plamenem narovná ohnutá nitinolová sponka. Fólie přitom urazí 368 až 415 mikrometrů a vyvine přes 5,5 newtonu.

Druhá fólie je z TiNiFe, měří 26,5 mikrometru a chová se superelasticky. Pod tahem se v ní mřížka mění na martenzit a fólie se ohřeje; po uvolnění se přeměna vrátí zpátky a fólie zchladne pod okolní teplotu. Tomu se říká elastokalorický jev a tahle fólie je vlastně chladivo celého zařízení, jen v pevném stavu. Její pracovní část má 7,5 krát 0,5 milimetru.

Cyklus má čtyři kroky. Hnací fólie se ohřeje, stáhne a napne chladicí fólii, ta se tím ohřeje. Chladicí fólie se přiloží k chladiči a teplo odevzdá. Hnací fólie zchladne, tah povolí a chladicí fólie se ochladí. Nakonec se přitiskne k tomu, co má chladit, a odebere mu teplo. Celé kolo trvá 1,2 sekundy a půl sekundy z toho zaberou samotné doteky s výměníky.

Proč vůbec nahrazovat motor fólií? Superelastická slitina potřebuje napětí ve stovkách megapascalů, ale protáhne se přitom jen o pár procent. Běžný elektromechanický pohon je stavěný obráceně, na dlouhý zdvih a menší sílu. Autoři to vyjádřili poměrem síly ku dráze: jejich tepelný pohon má 14,5 newtonu na milimetr, komerční elektromechanický pohon, se kterým ho měřili vedle sebe, 1,1.

Čtyři stupně a necelé tři miliwatty

Na chladicí fólii samotné se teplota při cyklování houpe o 12,9 kelvinu. Mezi teplou a studenou stranou hotového zařízení už zbývají 4,0 kelvinu; rozdíl spolykají tepelné odpory na dotycích a únik do okolí. Chladicí výkon při nulovém teplotním zdvihu je 2,79 miliwattu, přepočteno na gram aktivní slitiny 4,43 wattu.

Účinnost popisují tři čísla a každé měří něco jiného. Chladicí jednotka má proti mechanické práci, kterou dostane, chladicí faktor 2,61. Tepelný pohon má proti teplu, které pohltí, faktor 0,0327. Celé zařízení dohromady 0,0853. Chladivo tedy pracuje slušně, jenže převod tepla na mechanickou práci spotřebuje skoro všechno, co do systému vstoupí. Ani jedno z těch čísel nepočítá s rekuperací práce.

Elektřina z prototypu nezmizela

Tisková zpráva KIT má v titulku chlazení, které elektřinu nepotřebuje, a odborný tisk to převzal. Čtyři stupně a 2,79 miliwattu ovšem tým naměřil ve chvíli, kdy hnací fólii zahříval proud procházející přímo jí. Jouleův ohřev je v laboratoři nejjednodušší cesta na 86 stupňů Celsia, s odpadním teplem ani se sluncem ale nemá společného nic.

Skutečně tepelný pohon je v práci taky, jako ověřovací sestava. Místo proudu se hnací fólie ohřívala dotykem s měděnou destičkou, kterou drželo na 130 stupních platinové topítko. Zařízení pak udrží rozdíl 2,2 kelvinu a odvede 2,09 miliwattu. Vyšší potřebná teplota má fyzikální důvod: proud ohřívá fólii v celém objemu, horká destička jen od povrchu dovnitř.

Elektřinu si žádá i zbytek sestavy. Fólie se musí cyklicky přikládat k chladičům a ke zdroji tepla a ten pohyb obstarávají elektromechanické pohony. Do uvedených faktorů se nezapočítávají.

Recenzenti to napsali natvrdo

Nature Energy vydává k článkům i recenzní spis a u téhle práce stojí za přečtení. V prvním kole napsal jeden ze čtyř recenzentů, že ukazatele výkonu jsou nadsazené: naměřené jednotky miliwattů podle něj pokryjí jen vlastní vnitřní energii fólie a únik tepla do okolí, takže na úrovni systému vychází užitečný chladicí výkon nula. Vytkl také, že se do chladicího faktoru nepočítá elektřina na pohyb výměníků, a že Jouleův ohřev nezastupuje odpadní teplo, protože rozkládá teplotu ve fólii jinak.

Dva další recenzenti chtěli totéž z opačné strany: ať tým ukáže pohon opravdovým zdrojem tepla, i kdyby byl pomalejší. Sestava se stotřicetistupňovým topítkem vznikla právě proto. Ve druhém kole na ni kritický recenzent namítl, že 130 stupňů proti 86 už se za nízkopotenciální teplo vydávat nedá. Doporučení k vydání nakonec dali všichni čtyři a redakce práci přijala 20. července 2026.

Do datového centra je odsud daleko

Tisková zpráva jmenuje mezi velkými odběrateli chladu datová centra a část oborového tisku je dala i do titulku. Sama studie mluví opatrněji. Jako možné použití uvádí chlazení procesorů, které by k tomu využily vlastní odpadní teplo, a chlazení citlivé elektroniky v autech teplem od pohonu.

Rozdíl je v řádech. Serverový čip dnes vydá stovky wattů tepla, prototyp odvádí necelé tři tisíciny wattu. Recenzent v prvním kole připomněl, že komerční mikrochladiče pro elektroniku pracují v pásmu jednoho až sta wattů a stojí většinou na termoelektrickém jevu. Elastokalorika takové výkony v laboratoři zvládá, jen v jiné podobě: velká zařízení z trubek a tyčí ze slitin s tvarovou pamětí už předvedla teplotní rozdíl až 75 kelvinů a chladicí výkon 1 284 wattů, ovšem s elektrickým pohonem a hydraulikou.

Cesta ke spojení obojího vede podle autorů dvěma směry naráz: řadit fólie za sebe kvůli většímu teplotnímu rozdílu a vedle sebe kvůli výkonu. I na tohle recenzent upozornil. Rozvést teplo rovnoměrně do mnoha fólií zapojených vedle sebe přidá tepelný odpor, se kterým dnešní pokusná sestava nepočítá.

Proč to stojí za sledování

Elastokalorické chlazení láká proto, že teoreticky umí využít až 84 procent Carnotovy meze. Termoelektrické články, kterými se dnes chladí drobná elektronika, se pohybují na 10 až 15 procentech. Chlazení a vytápění přitom podle přehledů, na které se studie odvolává, spotřebují dohromady skoro polovinu světové energie.

Prototyp z Karlsruhe na tom sám nezmění nic a ani si to nenárokuje. Zajímavý je tím, že hnací část celého řetězce se dá udělat z téhož materiálu jako chladivo. Jestli se rozdíl čtyř stupňů někdy protáhne na čtyřicet, je otázka na jiných deset let.

Zdroje

• Y.-T. Hsiau, S. Miyazaki, M. Kohl, J. Xu: Heat-driven elastocaloric cooling with shape memory films, Nature Energy, 28. srpna 2026, DOI 10.1038/s41560-026-02122-6
• Peer Review File k téže studii, Nature Energy
• KIT: No Electricity Needed for Solid-state Cooling: Heat Becomes Cold, tisková zpráva 075/2026, 28. srpna 2026
• Electricity-free cooling system for data centers prototyped by scientists in Germany and Japan, Data Center Dynamics, 2. září 2026

Napětí roste s tloušťkou, polaritu určí iniciátor

Vrstvy vznikaly metodou iCVD. Jako stavební kámen posloužily monomery s výrazným dipólovým charakterem, mezi nimi ethylenglykoldimethakrylát. Molekuly takového monomeru se při růstu srovnají tak, že jejich kladné konce míří na jednu stranu a záporné na druhou, a vrstva tím dostane napříč svou tloušťkou vlastní elektrické pole.

Kterým směrem pole zamíří, rozhodly radikálové iniciátory, které vznikají rozkladem na žhavených vláknech uvnitř komory. Volba iniciátoru tedy určuje, jestli je povrch hotové vrstvy kladný, nebo záporný. Povrchový potenciál přitom rostl lineárně s tloušťkou a nejvyšší uvedená hodnota je 24 voltů. Velikost jde ladit podmínkami nanášení.

Jak dlouho polarizace vydrží, se ve dvou částech téhož čísla uvádí různě. Redakční shrnutí Science mluví o týdnu za běžných podmínek, abstrakt práce píše jen o stabilitě za běžných podmínek a lhůtu neuvádí.

Co je nanášení z par s iniciátorem

Zkratka iCVD znamená initiated chemical vapor deposition, tedy chemické nanášení z plynné fáze s iniciátorem. Do vakuové komory se pustí páry monomeru a iniciátoru, žhavená vlákna rozštěpí vazby v iniciátoru a vzniklé radikály nastartují polymeraci až na povrchu podložky. Vrstva tak roste přímo tam, kde má být, a proces se obejde bez rozpouštědel.

Kielské pracoviště profesora Franze Faupela na téhle technice pracuje léta. Podle tiskové zprávy univerzity z května 2024 na ní dokáže vyrobit průhledné vrstvy o tloušťce nastavitelné od deseti nanometrů do deseti mikrometrů, s hladkým a rovnoměrným povrchem, a to i na členitých nebo porézních předmětech.

Dosud to chtělo vnější pole

Trvale polarizovanému tělesu se říká elektret; je to elektrická obdoba trvalého magnetu. Aby se polymerní vrstva takhle chovala, bylo ji podle autorů dosud nutné vystavit vnějšímu elektrickému poli nebo ji po nanesení dodatečně upravit. Obojí podle nich omezuje přesnost i výrobu ve velkém.

Práci doprovází v témže čísle na straně 980 komentář, který napsali Pengzhe Cai a Junjie Zhao ze Zhejiangské univerzity. Srovnané dipóly podle nich mění transport náboje, optickou odezvu i chování rozhraní mezi dvěma materiály, což se hodí v elektronice, senzorech, získávání energie a v biomedicíně. Dodávají, že dosavadní postupy se nedají použít na nerovinné podložky ani na složité trojrozměrné tvary, a že kielská metoda může otevřít cestu k další generaci materiálů, rozhraní a součástek.

Co se z veřejné části zjistit nedá

Plné znění je za předplatným. Veřejně je abstrakt práce, redakční shrnutí a abstrakt komentáře, a v žádném z nich nestojí, jak silná byla vrstva, na které se těch 24 voltů naměřilo. Bez tloušťky nejde dopočítat intenzitu pole uvnitř vrstvy, tedy právě tu veličinu, kterou má v titulku sama práce.

Chybí i to, kolik vzorků za výsledkem stojí a co se s polarizací děje po delší době než po týdnu. A hotová součástka v práci není: je to výsledek o materiálu. Komentář v Science mluví o možném směru, ne o produktu.

Zdroje

• Stefan Schröder, Torge Hartig, Kai Uwe Clausen, Thomas Strunskus, Franz Faupel: Spontaneous polarization in chemical vapor-deposited polymer films creates large electric fields, Science 393, číslo 6815, strany 1031 až 1035, 3. září 2026
• Pengzhe Cai, Junjie Zhao: Locking aligned molecular dipoles, Science 393, číslo 6815, strana 980, 3. září 2026
• Kielská univerzita: Customised production of antiviral coatings and cell culture surfaces, 16. května 2024

Tři jména v rejstříku IANA

Nové metody se v pozdravu SSH ohlašují těmito názvy:

• mlkem768nistp256-sha256 – ML-KEM-768 s křivkou NIST P-256 a hashem SHA-256,
• mlkem1024nistp384-sha384 – ML-KEM-1024 s křivkou NIST P-384 a SHA-384,
• mlkem768x25519-sha256 – ML-KEM-768 s Curve25519 a SHA-256.

Všechny tři už rejstřík IANA vede s odkazem na RFC 10042 a se známkou SHOULD ve sloupci „OK to Implement“. Ve stejné tabulce leží i tři čistě mřížkové metody bez eliptické části, tedy mlkem512-sha256, mlkem768-sha256 a mlkem1024-sha384. Ty se ale odvolávají jen na koncept jednotlivce a mají jen MAY.

Proč se stará matematika nevyhazuje

Útok, kterému má hybrid předejít, jmenuje dokument anglicky „harvest now, decrypt later“. Odposlouchávající strana si dnes uloží zašifrovaný provoz a rozšifruje ho později, až bude mít dost velký kvantový počítač. Klasická výměna klíčů v SSH stojí na diskrétním logaritmu, a ten by takový stroj vyřešil.

Řešení není výměna jedné matematiky za druhou, ale jejich složení. Bezpečnost obou částí je podle textu nezávislá, takže hybridní metoda je vždy aspoň tak silná jako ta silnější z dvojice. Kdyby se trhlina našla v ML-KEM, drží spojení eliptická křivka. Kdyby padla křivka, drží ML-KEM.

Sdílené tajemství se hashuje, ne skládá jako číslo

Každá půlka výměny vyrobí vlastní tajemství a RFC je spojuje předpisem K = HASH(K_PQ || K_CL), kde K_PQ pochází z ML-KEM a K_CL z eliptické křivky.

Zajímavější než ten vzorec je způsob zápisu obou vstupů. Starší výměny v SSH kódovaly sdílené tajemství jako celé číslo (mpint), jehož délka kolísá podle hodnoty. RFC 10042 obě dílčí tajemství zapisuje jako pole bajtů pevné délky, tedy 32 bajtů pro Curve25519 i pro secp256r1 a 48 bajtů pro secp384r1. Důvod dokument jmenuje: proměnlivá délka vstupu do hashovací funkce může prozradit nejvyšší bit tajemství nebo to, že nejvyšší bajty jsou nulové. Odkazuje u toho na časovací útoky Lucky Thirteen a Raccoon.

Od TLS 1.3 se SSH v tomhle bodě liší. Tam se obě tajemství pouze zřetězí a rovnou vstupují do rozvrhu klíčů, kdežto tady se zřetězená dvojice ještě prožene hashem. Text uvádí, že rozdíl je kvůli efektivitě. V TLS 1.2 přitom míří práce IETF opačným směrem: RFC 10015 z července 2026 tam výměnu klíčů přes RSA i přes Diffieho–Hellmana nad konečným tělesem zakázalo.

Dvě věci žádá bezpečnostní oddíl závazně. Klíčový pár pro ECDH i pro ML-KEM se musí vygenerovat pro každé spojení znovu a implementace nesmí při tvorbě šifrových textů ML-KEM sáhnout po téže náhodnosti dvakrát.

OpenSSH i PuTTY tu metodu nabízely dřív, než vzniklo RFC

Podle poznámek k vydání OpenSSH přibyla metoda mlkem768x25519-sha256 už ve verzi 9.9 z 19. září 2024, a to s odkazem na tehdejší koncept draft-kampanakis-curdle-ssh-pq-ke-03. Výchozí metodou pro dohodu klíče se stala v OpenSSH 10.0 z 9. dubna 2025. PuTTY přidal podporu ML-KEM ve verzi 0.83 z 8. února 2025.

Cesta k číslu RFC byla dlouhá. První verze individuálního konceptu má v datatrackeru datum 20. listopadu 2022, pracovní skupina sshm si dokument převzala jako svůj 29. ledna 2025 a poslední, desátou revizi odevzdala 26. února 2026. Mezi prvním konceptem a vydaným RFC tak uplynuly bezmála čtyři roky.

Není to ani první postkvantová výměna klíčů pro SSH s vlastním číslem. V dubnu 2026 vyšlo RFC 9941 o metodě sntrup761x25519-sha512, tedy o kombinaci Streamlined NTRU Prime a X25519, kterou OpenSSH zapnul jako výchozí ještě dřív. I ono je Informational a jeho spoluautorem je Markus Friedl z OpenSSH.

Co dokument nechává otevřené

Velikost paketů. RFC 4253 žádá po implementacích SSH, aby zvládly nekomprimovaný obsah do 32 768 bajtů a celý paket do 35 000 bajtů. Postkvantové výměny umějí posílat velké zprávy, jenže RFC 10042 výslovně píše, že jeho tři metody tyhle meze nepřekračují, a pro případ, že by je nějaká výměna překročila, žádné nové chování nezavádí.

Opatrně je psaná i příloha o FIPS. Prosté zřetězení tajemství ze schváleného algoritmu (secp256r1, secp384r1, ML-KEM) s tajemstvím z neschváleného (X25519) je podle NIST SP 800-227 přípustné a odvození klíčů v SSH schvaluje SP 800-135. Autoři z toho vyvozují, že kombinátor v dokumentu podle FIPS schválený nejspíš je, byť ho SP 800-227 jmenovitě neuvádí. Jistotu tedy nedávají a čtenář, který potřebuje razítko, si ji z textu neodnese.

Pro správce serverů z toho plyne málo práce. Kdo má OpenSSH 10.0 nebo novější na obou koncích, hybridní výměnu už používá, aniž o tom ví. Zbytek je papírování, které tomu stavu dodalo číslo.

Zdroje

• RFC 10042: Post-Quantum/Traditional Hybrid Key Exchange with the Module-Lattice-Based Key-Encapsulation Mechanism for Use in SSH, RFC Editor
• draft-ietf-sshm-mlkem-hybrid-kex, datatracker IETF
• Secure Shell (SSH) Protocol Parameters, IANA
• OpenSSH Release Notes, projekt OpenSSH
• PuTTY change log, Simon Tatham
• RFC 9941: SSH Key Exchange Method Using Hybrid Streamlined NTRU Prime sntrup761 and X25519 with SHA-512, RFC Editor

Co přesně vyšlo

Dokument se jmenuje Resetting NHTSA's Fuel Economy Program a vyšel v pondělí 31. srpna 2026 v americkém úředním věstníku Federal Register na stranách 55 788 až 55 793 pod spisovou značkou NHTSA-2026-1948. Není to novela předpisu, ale výklad: úřad v něm popisuje, jak rozumí zákonu, který sám provádí. Právě proto nemusel projít připomínkovým řízením ani třicetidenní lhůtou a platí ode dne vydání.

Týká se programu, kterému se v americké správní hantýrce říká MDHD. Spadají do něj podle zákona vozidla s největší povolenou hmotností nad 10 000 liber, tedy zhruba nad 4,5 tuny, a k nim takzvané pracovní vozy v pásmu 8 500 až 10 000 liber. Osobních aut se výklad netýká: pro ně úřad normy motorů nikdy nevydával a v poznámce pod čarou potvrzuje, že by to ani nesměl.

Motor není vozidlo

Celý argument stojí na jednom slově, které v zákoně chybí. Energy Independence and Security Act z roku 2007 ukládá úřadu stanovit průměrné normy spotřeby pro pracovní vozy a pro střední a těžká nákladní vozidla a dovoluje mu vydat zvláštní normy pro různé třídy vozidel. O motorech tam není řeč. Zato jinde v témž zákoně motory zmíněné jsou, třeba v pasážích o studii trvanlivosti motorů na bionaftu, a v čistě ovzdušném zákoně Clean Air Act má agentura EPA výslovně napsáno, že smí regulovat i motory. Podle úřadu je ten rozdíl záměrný, ne náhodný.

„Motor není vozidlo,“ píše se v dokumentu. Spotřebu ovlivňují i pneumatiky, převodovky a výfuk, a přesto nikoho nenapadlo, že by pro ně měl úřad vydávat vlastní normy. Kdyby pravomoc k normám vozidel zahrnovala i jejich části, žádná mez by neexistovala.

Oporu hledá úřad ve dvou soudních rozhodnutích. Odvolací soud pro District of Columbia v roce 2021 ve věci Truck Trailer Manufacturers Association zrušil normy pro návěsy s odůvodněním, že návěs není vozidlo, protože nemá motor a nespotřebovává palivo. Nejvyšší soud pak rozsudkem Loper Bright z roku 2024 skončil s praxí, kdy soudy přebíraly jakýkoli obhajitelný výklad úřadu; zákon má podle něj jediný nejlepší smysl a hledat se má ten.

Patnáct let opačného názoru

Zajímavé je, že úřad tenhle spor už jednou vedl a tehdy tvrdil pravý opak. Normy vznikly společně s EPA ve dvou vlnách. První, z září 2011, zavedla vedle limitů pro tahače a účelová vozidla i samostatné limity pro jejich motory, povinné zhruba od modelového roku 2016. Druhá, z října 2016, limity zpřísnila, rozložila je do tří stupňů s posledním pro modelový rok 2027 a přidala normy pro návěsy, které soud o pět let později zrušil.

Už při přípravě první vlny namítaly Volvo a Daimler, že zákon o motorech nemluví. Úřad tehdy odpověděl, že pravomoc k odlišným normám pro různé třídy vozidel si vykládá „široce“ a že mu zákon regulaci motorů nezakazuje. Dnes v témž dokumentu cituje vlastní tehdejší větu a označuje ji za natažení textu za hranici jeho přirozeného čtení.

Co to znamená pro výrobce

Prakticky se zítra nezmění nic. Výkladové pravidlo výslovně říká, že nemění existující normy ani žádná práva a povinnosti; jen připravuje půdu pro řádné řízení, ve kterém se program přepíše. Normy pro celá vozidla mají zůstat, protože je zákon požaduje. Do téže řady patří i srpnový návrh úřadu vypustit z hvězdičkového hodnocení nových aut test převrácení a zkoušky bočních airbagů. Zmizet má ta druhá vrstva, tedy limit uložený samotnému motoru, a úřad slibuje, že výrobcům nechá schůdnou cestu, jak normy vozidel splnit i bez ní.

Nejasné zůstává vymáhání. Dokument říká jen tolik, že do konce řízení bude úřad postupovat v souladu s novým výkladem, což si server Land Line vyložil jako oznámení, že se limity motorů vymáhat nebudou. Odborný list Heavy Duty Trucking upozorňuje, že úřad nikde nevysvětlil, jak přesně chce s normami, které v předpisech zůstávají, zacházet.

Druhá polovina původní dvojice mezitím padla jinak. Agentura EPA v únoru 2026 zrušila zjištění o ohrožení z roku 2009 a s ním i své emisní limity skleníkových plynů pro vozidla a motory. Emisní limity oxidů dusíku z roku 2023 pro modelový rok 2027 tím dotčené nejsou a nové motory podle nich přicházejí dál, byť EPA k nim v červenci 2026 navrhla úpravy.

Reakce

Ředitel úřadu Jonathan Morrison v tiskové zprávě řekl, že motory vozidel umějí nejlépe navrhnout američtí výrobci, a ne stát, a že narovnání programu se zákonem zlevní nákladní vozy. Sdružení výrobců motorů a nákladních vozů EMA přezkum uvítalo s tím, že současné normy motorů i vozidel podle něj citelně omezují, co si zákazník může nechat namontovat.

Ekologické sdružení Sierra Club naopak varuje, že uvolnění norem uzamkne dopravce v závislosti na naftě a vystaví je výkyvům její ceny, které nakonec zaplatí zákazník. Obě strany si tak stěžují na náklady, jen počítají jiné.

Za pozornost stojí, jak se ta změna dělá. Nejde o novelu ani o rozsudek, ale o šest stránek výkladu, které úřad vydá sám o sobě, bez připomínek a s okamžitou platností. Pravomoc, kterou si úřad patnáct let vykládal široce, si tím odebral týmž postupem, jakým si ji tehdy přisoudil.

Zdroje

• Resetting NHTSA's Fuel Economy Program: Commercial Medium- and Heavy-Duty On-Highway Vehicles and Work Trucks, Federal Register, 31. srpna 2026
• NHTSA moves to scrap truck fuel economy standards, Land Line, 1. září 2026
• NHTSA Moves to Rewrite Truck Fuel-Economy Rules, Heavy Duty Trucking, 31. srpna 2026
• Resetting the Corporate Average Fuel Economy Program, Federal Register, 11. června 2025

Přestavba trvala přes tři roky

Že se editor chystá na čtvrtou verzi, napsal tým už v dubnu 2023 k vydání Audacity 3.3: velká část práce podle něj šla na to, aby aplikace byla méně závislá na wxWidgets. Teď je na Qt přestavěné rozhraní včetně vestavěných efektů, generátorů a analyzátorů. Phoronix upřesňuje, že jde o Qt6. Rozhraní se vykresluje nativně i na displejích s vysokou hustotou bodů, lišty a panely se dají přesouvat, ukotvit nebo nechat plovoucí a hotové rozložení jde uložit jako pracovní prostor. Tři jsou předpřipravené: Modern, Classic a Music. Ke světlému a tmavému motivu přibyl vysoce kontrastní, k tomu barvy zvýraznění, barvy stop a několik stylů klipů. Po spuštění se ukáže domovská obrazovka s náhledy nedávných projektů.

Řada 3.7 přitom nezůstala stát. Dva dny před čtyřkou, 1. září, vyšlo opravné vydání 3.7.9, které do oficiálních sestavení pro Windows doplnilo ovladače ASIO a podporu FFmpeg 9 a opravilo několik příčin poškození projektu, třeba když se disk odpojí hned po zavření souboru. Obojí má i čtyřka.

Klip se vybírá kliknutím na záhlaví

Kdo v editoru stříhá, pozná nejdřív nový model práce s klipy. Klip se vybere kliknutím na jeho záhlaví, s klávesou Shift jich jde vybrat víc a přesun, oříznutí nebo časové roztažení pak platí pro všechny vybrané naráz. Klipy jde seskupit a skupina drží pohromadě při kopírování, vkládání i duplikaci. Klip se dá přetáhnout mezi mono a stereo stopou, a když se přesune přes jiný, přepíše překrytou část, místo aby se přesun zablokoval.

Rozdělování dostalo vlastní nástroj: stiskne se nebo podrží klávesa S a klikne do vlnového průběhu nebo na záhlaví klipu. Vkládání ze schránky umí založit stopu, když žádná nevyhovuje, přizpůsobit rozložení kanálů a vzít i zvukový soubor ze schránky operačního systému.

Zmizely samostatné režimy nástrojů Výběr, Obálka, Kreslení a Multinástroj. Obálka hlasitosti se teď ukáže v režimu zisku klipu a kreslení vzorků se zapne samo, jakmile je vlnový průběh přiblížený na jednotlivé vzorky. Pryč je i Sync-Lock. Místo něj mají mazání, vyjmutí a vložení výslovné varianty, které buď nechají mezeru, nebo posunou pozdější materiál, aby zůstalo časování.

Měřidla přímo v záhlaví stopy

Přehrávací kurzor zůstává vidět i při posouvání a dá se přetáhnout jinam; přeskočit na jinou pozici jde bez zastavení. Nahrávání se dá spustit kdekoli na časové ose a vytvoří klip na tom místě. Záhlaví každé stopy nese živé měřidlo úrovně pro přehrávání i nahrávání. Nastavení zvuku zná výchozí zařízení systému, obnovuje seznam zařízení, umí vlastní mapování kanálů a dokáže samo sledovat, když systém zařízení přepne. Zásuvné moduly jsou VST3, Nyquist, LV2 na Linuxu a Audio Units na macOS; když modul nemá vlastní rozhraní, Audacity mu ovládací prvky vygeneruje. Spektrogram dostal jasnější vodítka a rychlejší vykreslování.

Formát .aup4 je jednosměrný

Projekty se ukládají do nového formátu .aup4. Starší .aup3 se otevře a převede, původní soubor zůstane beze změny, jenže převedený projekt už do .aup3 uložit nejde. Projektový soubor nese i náhled a data o klipech a vzhledu, která trojka neznala. Importovat lze i staré projekty .aup.

Co z trojky chybí

Poznámky k vydání vyjmenovávají šest věcí, které v Audacity 4.0 nejsou a na kterých tým podle vlastních slov pracuje pro další vydání: časové stopy (Time Tracks), stopy s notami a MIDI, mixér, správce maker se skriptovací rourou, hostování modulů VAMP a LADSPA a přehrávání změněnou rychlostí. Vedle toho podle téže poznámky ve čtyřce chybí i některé exportní a renderovací funkce, analyzátory a efekty, které už tým nejmenuje. Kdo se o některou z nich opírá, má zatím řadu 3.7, jejíž poslední oprava vyšla 1. září.

Beta 4 z 28. srpna předtím přinesla sestavení pro ARM64 na Windows i Linuxu, menší instalátory a detekci modulů, které aplikaci shazují: takový modul se označí jako rozbitý, místo aby editor padal při každém startu. Stránka stahování nabízí 4.0.0 pro Windows jako instalátory x86_64 a ARM64, pro macOS jako univerzální sestavení a pro Linux jako AppImage pro x86_64 a ARM64. Zdrojový balík byl po vydání ještě jednou nahrán, aby obsahoval knihovny SoundTouch a sbsms.

Zdroje

• Audacity 4.0.0, poznámky k vydání na GitHubu (3. září 2026)
• Phoronix: Audacity 4.0 Audio Editor Released With Qt6 Based UI (3. září 2026)
• Audacity 3.7.9, poznámky k vydání (1. září 2026)
• Audacity 4.0.0 Beta 4, poznámky k vydání (28. srpna 2026)
• Audacity, stránka stahování
• Blog Audacity, příspěvek k verzi 3.3 (2. dubna 2023)

Třináct let na jednom páru rukou

Zakladatelé vystupují pod jmény xPaw a Marlamin. Marlamin od něj podle oznámení Nexus Mods před několika lety odstoupil a celá údržba pak zůstala na xPawovi. Ten to ve vlastním oznámení popisuje bez okolků: koníček se počtem odpracovaných hodin dávno vyrovnal plnému úvazku, ale pořád se platil z darů.

„Po covidu a s nástupem umělé inteligence je internet, který jsme kdysi milovali, pryč, a s ním i moje nadšení,“ napsal xPaw. Vyhoření podle svých slov nějakou dobu přecházel. Před několika lety už jednou hledal, kdo by projekt převzal, jenže nenašel tým, kterému by věřil, a pokračoval sám. Steam mezitím rostl v počtu her, hráčů i funkcí, které se do něj přidávají. Citace jsou přeložené z angličtiny.

Kupcem je majitel Nexus Mods

Chosen vznikla v lednu 2025 a Nexus Mods převzala v červnu téhož roku. Zakladatel Nexus Mods Robin Scott tehdy nové majitele v oznámení nejmenoval, takže si je čtenáři dohledali sami přes veřejné profily a diskusní fóra; teprve pak to firma potvrdila. Rock Paper Shotgun tehdy z jejích stránek vypsal, že předtím pracovala s komunitními databázemi kolem EA FC, jmenovitě FUTBIN a RenderZ.

Převzetí Nexus Mods provázely obavy z placených modů, z reklam i z kryptoměn. Victor Folmann, Marinus Elgaard a Nikolaj Nyholm na ně tehdy odpověděli slibem, že se model nemění: žádné placené mody a spíš míň reklam než víc.

Pro čtenáře se hned tak nic nezmění

SteamDB si podle Nexus Mods nechává jméno, značku, komunitu i vlastní tvář a zůstává samostatnou službou. Účet na Nexus Mods k jejímu prohlížení netřeba. Co je dnes zdarma, zdarma zůstane, rozšíření do prohlížeče se bude dál udržovat a Discord se skupinou na Steamu zůstávají prostorem komunity SteamDB. xPaw má s novým vlastníkem na přechodu spolupracovat ještě několik měsíců.

Změny mají přijít na pozadí. Místo jednoho člověka má na webu pracovat placený tým a s ním lepší infrastruktura i zabezpečení. SteamDB dosud spoléhalo na darované klíče ke hrám, bez kterých se k souborům a depotům nedostane; Chosen slibuje, že klíče k některým hrám začne kupovat sama.

Peníze bez reklam

Web se ale bude muset uživit. V odpovědích na časté dotazy k tomu Folmann píše, že reklamy jsou cesta, kterou jít nechtějí, a že hledají něco méně nápadného: partnerství, propojení se službami a provizní odkazy na hry, které si čtenář koupí po návštěvě SteamDB. Sám k tomu dodává, že se to dělá hůř, trvá to déle a výsledek nepřijde hned.

Proč o databázi stojí zrovna modderský web

Nexus Mods má na SteamDB praktický zájem a nezastírá ho. Mody bývají postavené na konkrétní verzi hry, takže po aktualizaci přestanou fungovat. SteamDB si přitom vede historii sestavení, depotů, manifestů i jednotlivých souborů roky zpátky. Kdyby správce modů poznal, kterou verzi hry má hráč nainstalovanou, dokázal by dopředu upozornit, že chystaná aktualizace nainstalované mody rozbije.

Je to zatím záměr, ne funkce. Nexus Mods v oznámení sám píše, že mezi převzetím webu a takovým stavem je spousta práce, a že nechce slibovat, co ještě neexistuje. Stejně tak dodává, že se ze SteamDB modderský web dělat nemá; kdo tam chodí na počty hráčů nebo na historii cen, má tam najít pořád totéž.

Cena nepadla, diskuse je zamčená

Za kolik SteamDB změnilo majitele, neřekla ani jedna strana. Diskuse pod oznámením na Nexus Mods má 204 příspěvků a moderátor ji zatím zavřel; v připnutém komentáři odkazuje na odpovědi na časté dotazy, protože se řada dotazů opakovala.

Nový vlastník si je vědom, že důvěru komunity nekoupil spolu s webem. V oznámení to píše natvrdo: xPawova volba mu ji sama o sobě nedává a musí ji teprve obhájit.

Zdroje

• Nexus Mods: SteamDB Joins Nexus Mods, 2. 9. 2026
• Oznámení xPawa na SteamDB
• Odpovědi na časté dotazy k převzetí
• Rock Paper Shotgun: SteamDB founders announce the database has been acquired by Nexus Mods' owners, 2. 9. 2026
• Rock Paper Shotgun: Nexus Mods' new owner is a company whose co-founder has already had to reassure folks that NFTs and crypto aren't incoming, 17. 6. 2025

Nejdřív pravidlo, pak nástroj

Pravidlo pro asistenty s umělou inteligencí má projekt od 7. srpna 2026, kdy do hlavní větve přibyl stejnojmenný oddíl v souboru CONTRIBUTING.md. Stojí v něm, že autor odpovídá za sto procent kódu, který posílá, a nemá posílat záplatu, kterou neumí vysvětlit ani si ji sám nesestavil a nevyzkoušel. Commit messages a popisy merge requestů si má psát sám, protože právě ty vysvětlují, proč změna vzniká, tedy to, co nástroj vědět nemůže. Na připomínky recenzenta má odpovídat taky sám: kdo o vlastní záplatě nedokáže diskutovat, sloučení se nedočká.

Licenční prohlášení, že se změna smí vydat pod LGPL-2.1-or-later, může podle téhož oddílu udělat jedině člověk. Rozsáhlé strojově vytvořené merge requesty, které nikdo řádek po řádku nepročetl, projekt zavírá.

Návnada v AGENTS.md

Instrukce pro samotné agenty leží od 3. září v souboru AGENTS.md. Má dvaašedesát řádků, odkazuje na CONTRIBUTING.md a vyjmenovává úkoly, které má agent odmítnout: psát nebo upravovat popis merge requestu, psát commit message, odpovídat na připomínky z code review a potvrzovat licenci. Místo toho má člověka odkázat na stránku stopsloppypasta.ai.

Za tím výčtem stojí věta, kvůli které se o souboru mluví: když model takový text navzdory zákazu vytvoří, musí do něj vpravit slovo biblioklept. Slovník Merriam-Webster je vede jako výraz pro zloděje knih a v diskusi o správci síťových připojení se omylem sotva objeví. Označení kanárek pro takhle nastraženou hodnotu je v softwaru zavedené a jméno má po ptácích, které horníci brávali dolů jako výstrahu před otravnými plyny.

Aby se soubor k agentům vůbec dostal, přibyly k němu symbolické odkazy CLAUDE.md, GEMINI.md a .github/copilot-instructions.md. Zdůvodnění v commitu je prosté: každý nástroj čte pokyny jen pod svým vlastním jménem, takže by AGENTS.md sám od sebe neotevřel, a odkazy místo kopií drží jediné znění.

Kontrola je obyčejné hledání řetězce

Vynucení obstarává nový skript check-mr-description.sh o šestadvaceti řádcích. Přečte popis merge requestu, který GitLab podstrčí v proměnné CI_MERGE_REQUEST_DESCRIPTION, a hledá v něm to slovo bez ohledu na velikost písmen. Když ho najde, úloha skončí chybou a výpis autora vyzve, ať popis přepíše vlastními slovy, přizná použití modelu a spustí pipeline znovu. Skript zároveň upozorní, že GitLab delší popis usekne na 2 700 znacích a zkontroluje se jen ta část.

Druhá polovina míří na commit messages. Skript check-commit-message.sh dostal tutéž kontrolu a běží i v místním hooku před commitem, takže na slovo narazí autor ještě před odesláním. Obojí visí v úloze check-patch, kterou má NetworkManager v prvním stupni CI.

Týž commit rozšířil i seznam zakázaných řádků s poděkováním. Řádek Generated-by projekt odmítá vždy, kdežto Co-authored-by a Co-developed-by shodí kontrolu jen tehdy, když je za nimi jméno nástroje. Regulární výraz v nich hledá mimo jiné Anthropic, OpenAI, Copilota, ChatGPT, Gemini, Cursor, Codex, Aider, Windsurf, řadu Claude Code a označení GPT s číslem. Šablona merge requestu má nově oddíl s otázkou, jak se v něm umělá inteligence použila, a odškrtávací položku, že je vyplněný pravdivě.

Co past chytí a co ne

Commit, který kontrolu přidává, si její dosah vymezuje sám. Chytí jedině agenta, který AGENTS.md přečetl a značku poslušně doplnil, přestože pravidlo o tom, že ten text nemá psát vůbec, porušil. Generovaný text sám o sobě nepozná.

Platí to i obráceně. Hledá se prostá shoda řetězce, takže kontrola spadne na každém příspěvku, ve kterém to slovo stojí, včetně commitu, jehož autor o samotné značce píše. A agent, kterému nikdo instrukce nepodstrčí nebo který je číst nemá, projde stejně jako dřív.

Podobná pravidla jinde

NetworkManager v tom sám není. Vlastní mez pro příspěvky psané modely zavedl letos GCC, pravidla pro kód od jazykových modelů řešil Debian a hostitel Codeberg zakázal projekty psané převážně modely. Rozdíl je v tom, kam každý míří: ostatní řeší hlavně kód, kdežto NetworkManager staví na tom, že text kolem změny, tedy commit message, popis a odpovědi recenzentovi, musí napsat člověk.

Zdroje: merge request 2536 a soubory AGENTS.md, CONTRIBUTING.md a check-mr-description.sh v repozitáři NetworkManageru, heslo biblioklept ve slovníku Merriam-Webster a zpráva serveru Phoronix ze 4. září 2026.

Severní šestiúhelník drží čtyři desítky let

Kolem severního pólu Saturnu leží stálá šestiúhelníková vlna se středem poblíž 78,5 stupně severní šířky. Objevila se na snímcích z průletů sond Voyager v letech 1980 a 1981 a od té doby ji sledovaly pozemní dalekohledy, Hubble i sonda Cassini, takže její doložená životnost přesahuje 44 let. Sedí na tryskovém proudu mířícím k východu rychlostí kolem 100 m/s a vůči soustavě III, tedy vůči rotaci rádiového signálu planety, zůstává skoro nehybná.

Jižní polokoule má dva obdobné podpolární tryskové proudy, na 60 a 73,6 stupni jižní šířky, takže se protějšek dal čekat. Nikdo ho ale nepopsal; Cassini v roce 2004 zahlédla jen krátkodobý útržek mnohoúhelníku.

Jedenáct let mimo dohled ze Země

Za tím tichem stojí sklon Saturnovy osy. Jižní polokoule zmizela pozemským pozorovatelům z dohledu v polovině roku 2012 a znovu se ukázala až v roce 2023. Zvlněného pásu podél jižního pólu si na pozemních snímcích všimli Sánchez-Lavega a amatérští pozorovatelé Trevor Barry a Jean-Paul Oger. Snímky pocházely z databáze Planetary Virtual Observatory Laboratory, kterou Univerzita Baskicka provozuje pro příspěvky pozorovatelů z celého světa.

Rozhodly ale až snímky Hubbla. Ten na rozdíl od pozemních přístrojů nemá mezi sebou a planetou zemskou atmosféru a zvládne odsledovat celé otáčky Saturnu. Pocházejí z programu OPAL, v jehož rámci dalekohled fotografuje vnější planety každý rok už přes deset let. V říjnu 2023 byla desetistranná struktura na 63 stupni jižní šířky patrná jen ve světle nad 600 nm, v srpnu 2024 vystoupily strany a vrcholy zřetelněji a na snímcích ze srpna a září 2025 už bylo vidět všech deset vrcholů. Stejně výrazné ovšem nejsou: tři vrcholy i s přilehlými stranami vystupují silně, čtyři slaběji a tři zůstávají rozmazané.

Vlna se plazí, proud pod ní uhání

Číselný popis útvaru dala měření z 26. června až 11. října 2025. Vlnová délka desetiúhelníku ve směru rovnoběžek vychází na 16 782 km s nejistotou 1 100 km, hřebeny a prohlubně se přitom v zeměpisné šířce rozkmitávají o 2,7 stupně, tedy o 2 645 km.

Samotný obrazec se posouvá k východu o 0,47 stupně za den, což na 63 stupni jižní šířky odpovídá rychlosti 2,5 m/s. Tryskový proud, ve kterém vlna sedí, se na 60,5 stupni jižní šířky pohybuje rychlostí 116 m/s, tedy víc než čtyřicetkrát rychleji. Jednotlivé vrcholy navíc kolem toho pomalého posunu kmitají s periodou 32,5 dne a s výchylkami od 4,6 do 8,4 stupně.

Nejde jen o kresbu v horní vrstvě mraků. Podobné zvlnění je vidět i v pásech na 53 a 58 stupni jižní šířky a v různých vlnových délkách se obrazec jeví posunutý: v červeném světle leží jeho střed na 63 stupni jižní šířky, v silném metanovém pásu na 889 nm na 60,5 stupni. Různé vlnové délky přitom prosvětlují různě vysoko položené vrstvy. Dohromady to znamená, že se útvar táhne od 53 do 66 stupně jižní šířky, tedy asi 13 000 km, a do hloubky sahá přinejmenším od tlaku 10 mbar po 2 bary.

Modely zatím rychlost netrefí

Autoři nabízejí výklad, který se pro severní šestiúhelník používá už dlouho: desetiúhelník by mohl být kvazigeostrofická Rossbyho vlna, kterou svisle drží a v zeměpisné šířce sevře zakřivení tryskového proudu. To zakřivení je tu asi osmkrát větší než změna planetární vorticity s šířkou, takže podmínky na to jsou.

Proti tomu stojí dva rozdíly. Desetiúhelník není po obvodu stejnoměrný, kdežto šestiúhelník má všechny strany i vrcholy stejně kontrastní. A hlavně: v předchozím saturnském roce tam nebyl a mezi lety 2023 a 2025 se teprve rozvíjí. Tým z toho usuzuje, že půjde spíš o nestabilitu tryskového proudu, a připouští, že útvar může být přechodný.

Ověřit to zkusil zjednodušeným modelem mělké vody ve třech variantách. Deset stejně rozmístěných poruch v trysce dá stabilní obrazec s deseti vrcholy, jenže se posouvá rychlostí 88 m/s. Sinusová vlna vložená do vrcholu proudu se rychle rozpadne na řetěz cyklon a anticyklon, který putuje rychlostí 46 m/s. Ani jedno není 2,5 m/s naměřených na obloze.

Třetí varianta počítá s anticyklonou. Kousek severně od vlny, na 55 stupni jižní šířky, leží načervenalá skvrna asi 4 000 km široká, která se posouvá rychlostí 23 m/s. Podobný útvar zahlédly Voyagery v roce 1981 a dostal přezdívku „Anne’s spot“. Vložení takové anticyklony do modelu proud rozkmitá a periodický vzor vznikne také, takže autoři nevylučují, že vlnu spustila právě ona. Napovídá tomu i to, že nejostřejší vrcholy má desetiúhelník poblíž skvrny, kdežto jeho nejrozmazanější část leží na opačné straně planety.

Co bude dál

„Nejzajímavější mi na tom přijde, že to podle všeho vzniklo teprve nedávno,“ řekla ke zprávě NASA spoluautorka práce Amy Simon z Goddardova střediska, která program OPAL vede. „Otázka je, proč se to objevilo právě teď, když jsme nic takového předtím neviděli.“

Tým chce Saturn sledovat dál a zjistit, jestli se desetiúhelník ustálí jako jeho severní protějšek, nebo se rozpadne. Kromě Hubbla k tomu má pomoct Webbův dalekohled a podrobnější vícevrstvé modely. Nabízí se přitom srovnání i mimo Saturn: polygonální uspořádání mají také polární cyklony Jupiteru za 80 stupněm šířky.

Co randstruct dělá

Randstruct při překladu zamíchá pořadí položek uvnitř struktur, které se skládají výhradně z ukazatelů na funkce, a uvnitř těch, které někdo ručně označil značkou __randomize_layout. Kdo se pak chce v takové struktuře trefit do konkrétní položky, nevystačí si s hlavičkovými soubory: potřebuje k tomu ještě druhou zranitelnost, která mu rozložení prozradí. Nápověda v Kconfigu u toho poctivě jmenuje i cenu, tedy mírné zpomalení, o něco vyšší spotřebu paměti a to, že nad takovým jádrem přestanou fungovat forenzní nástroje typu Volatility.

Semínko, ze kterého se pořadí počítá, leží v souboru scripts/basic/randomize.seed. Přežije make clean, aby se s ním daly přeložit i externí moduly, a zveřejňovat se nemá: kdo ho má, dopočítá si rozložení sám. Clang umí randomizaci sám od sebe, GCC jen přes zásuvný modul.

Kruh v závislostech

S Rustem se randstruct zatím nesnese. Brown to v popisu shrnuje jednou větou, totiž že randstruct Rust nepodporuje, a v souboru init/Kconfig je to vidět na volbě CONFIG_RUST, která má mezi podmínkami depends on !RANDSTRUCT.

Potíž je v tom, co z toho plyne pro allmodconfig, tedy pro sestavení, které zapne co jde, aby se ověřilo, že se celý strom vůbec přeloží. Zapíná i volbu COMPILE_TEST, a právě na ní dosud viselo předvolené zapnutí randstructu. Rust se pak kvůli své vlastní podmínce vypnul a rustové ovladače se v běžné pokrývací sestavě nepřekládaly. Ojeda k tomu napsal, že přijetím patche se dá udržet Brownovo testování Rustu v linux-nextu.

Napsat rovnou, že randstruct nemá být předvolený při zapnutém Rustu, nešlo, protože závislost by se zacyklila. Podmínka se proto ptá oklikou, jestli je vůbec k dispozici rustový nástrojový řetěz a jestli má daná architektura pro Rust podporu:

-	default RANDSTRUCT_FULL if COMPILE_TEST && (GCC_PLUGINS || CC_HAS_RANDSTRUCT)
+	default RANDSTRUCT_FULL if !(RUST_IS_AVAILABLE && HAVE_RUST) && COMPILE_TEST && (GCC_PLUGINS || CC_HAS_RANDSTRUCT)

Sám autor přiznává, co z takové okliky plyne: může vzniknout i konfigurace, ve které nakonec není ani Rust, ani randstruct. Podmínka se ptá na dostupnost Rustu, ne na jeho zapnutí.

Distribuční jádra to nepocítí

Obě podoby té podmínky, stará i nová, začínají u COMPILE_TEST. Jádro stavěné bez ní, tedy jakékoli, co má někomu opravdu běžet, dostávalo v téhle volbě předvolené RANDSTRUCT_NONE před změnou i po ní. Kdo randstruct chce, zapíná si ho v konfiguraci sám, a na tom se nemění nic. Změna míří na sestavy, které vznikají kvůli pokrytí překladu a nikdy se nespustí.

Obejití, ne oprava

Cook se nad první verzí 10. června zeptal, jestli se randstruct s Rustem nedá místo obcházení rovnou povolit. Ojeda ho odkázal na vlastní sérii rust: allow Clang-native RANDSTRUCT configs z 23. března 2026. Ta stojí na zkoušce, ne na úvaze: bindgen si pod kapotou volá libclang, randomizaci tedy zdědí a vygenerované vazby vyjdou se stejným pořadím položek jako céčková strana. Ojeda to v popisu dokládá čtyřmi ukázkovými strukturami a tím, u kterých z nich se položky prohodí a u kterých ne.

Proti sobě má ale nestabilitu. Pořadí, které Clang vyrobí, není zaručené napříč verzemi ani platformami, LLVM si dokonce vrátil zpět vlastní test, který přesné pořadí polí kontroloval, a modul do GCC míchá úplně jiným generátorem náhodných čísel. Série proto randstruct v Rustu povoluje jen s Clangem. Výkonnostní stránku k ní změřil Andreas Hindborg na rustovém ovladači null block: průměr přes 120 úloh se statisticky významně nezměnil, jednotlivé konfigurace se hýbaly zhruba o desetinu, a to na obě strany.

V hlavní větvi ta série zatím není. Volba CONFIG_RUST má obě zakazující podmínky pořád na svém místě, takže do jádra se dostalo obejití příznaku, ne odstranění příčiny.

Tři měsíce, čtyři verze

Brown poslal první verzi 5. června 2026 a druhou ještě týž den; přibyl do ní dotaz na HAVE_RUST, tedy na architekturu. Třetí verze z 2. července a čtvrtá z 1. září pak měnily jen to, na jaký strom patch sedí. Cook si ji vzal jedenáct minut po odeslání té čtvrté, Torvalds si ji stáhl o den později.

Nvidia 3. září, den před otevřením berlínského veletrhu IFA, zveřejnila betu programu Personal AI Router, zkráceně PAIR. Přes jméno nejde o žádnou krabičku: je to software, který se nainstaluje na každý počítač v domácnosti a dotazy na lokálně běžící jazykové modely rozděluje mezi ně. Zdrojový kód leží na GitHubu pod licencí Apache 2.0, instalátory jsou pro Windows 11, Linux v podobě balíčku .deb a macOS. Repozitář vznikl 2. července a první dvě vydání, 0.1.0 a 0.1.1, na něm visí od 26. a 28. srpna, tedy týden před oficiálním oznámením.

Router sedí na portu Ollamy a agent si ničeho nevšimne

PAIR sám žádný model nespouští. Na každém zapojeném stroji musí běžet Ollama nebo LM Studio, dva rozšířené programy pro lokální jazykové modely, a PAIR jim umí obě věci sám nainstalovat a stáhnout k nim modely. Pak si vezme port, na kterém Ollama nebo LM Studio normálně poslouchají, a tváří se jako ony: nabízí rozhraní shodné s Ollamou i s API OpenAI. Agent nebo aplikace tak posílá dotazy tam, kam je posílala doposud, a nemusí o clusteru vůbec vědět.

Každý příchozí dotaz PAIR přečte, zjistí, který engine a který model žádá, a vybere jeden vhodný stroj. Rozhoduje podle toho, jestli je stroj online, jestli má engine zapnutý a přesně ten model stažený, kolik má rozdělaných úloh a jak je zrovna vytížená grafika, třeba hrou. Dotaz pak celý proběhne na vybraném stroji a odpověď se vrátí stejným rozhraním zpět. Stroje se hledají přes mDNS, tedy stejným ohlašováním na místní síti, jaké používají tiskárny; jde je přidat i ručně podle IP adresy. Párování potvrzuje šestimístný kód a další provoz jde přes mTLS, tedy šifrované spojení, kde se oba konce prokazují certifikátem. Podle Nvidie zůstávají dotazy i odpovědi na domácí síti, pokud jsou na ní i všechny modely a klienti.

Paměť grafik se nesčítá

Nvidia sama v článku na vývojářském blogu vyjmenovává, co PAIR nedělá: neslučuje grafiky do jedné větší, nesčítá jejich paměť, nerozřezává model mezi stroje a jeden dotaz nikdy neběží na víc počítačích naráz. Model se musí vejít do paměti každého stroje, který ho má obsluhovat, a různé stroje mohou mít různé modely. Program tedy nepomůže tomu, kdo chce spustit model větší, než jaký se mu vejde na jednu kartu. Pomůže tam, kde je dotazů hodně najednou: agent, který si úkol rozdělí mezi pět podřízených agentů, vyrobí desítky nezávislých volání modelu, a ta se jinak řadí do fronty na jedné grafice. Sekvenční práce, kde jeden dlouhý dotaz čeká na druhý, podle Nvidie mnoho nezíská.

Jediná čísla, která firma zveřejnila, pocházejí z ukázky s agentem Hermes od Nous Research a modelem Qwen 3.6 35B A3B. Úloha s pěti podřízenými agenty trvala na jediném notebooku RTX Spark v průměru 18 minut; na trojici strojů, tedy notebooku RTX Spark, stanici DGX Spark a počítači s GeForce RTX 5090, 8 minut a 48 sekund. Nvidia u toho výslovně píše, že jde o neoficiální ukázku na jedné sestavě, ne o obecné měření, a že se výsledek mění s modelem, sítí i s tím, kolik strojů je zrovna volných.

Pro koho to je

Podporované jsou grafiky GeForce RTX od řady 20 výš, pracovní karty RTX PRO od architektury Turing, stanice DGX Spark a Macy s čipem M4 nebo novějším. Stránka produktu k tomu chce 8 GB paměti a doporučuje 20 GB místa na disku; mezi platformami vedle Windows 11, DGX OS a macOS Tahoe uvádí i Ubuntu 14.04, tedy vydání z roku 2014, zatímco README na GitHubu mluví jen o balíčku .deb a o překladu ze zdrojáků na ostatních distribucích. Windows na procesorech Arm nese označení experimentální.

Produktový manažer Nvidie Seth Schneider na tiskovém setkání, o kterém píše The Verge, vykreslil domácnost s notebookem RTX Spark a stanicí DGX Spark u otce, notebookem s RTX 5090 u matky, herním počítačem u dcery a MacBookem Pro u syna a spočítal v ní kolem 165 teraflops nevyužitého výkonu. The Verge to označuje za krajní případ; typického uživatele PAIRu si Nvidia představuje s jedním notebookem a jedním herním počítačem. „Je to opravdu poklad tokenů zdarma, které dnes jen tak leží v domácnostech,“ řekl podle The Verge (překlad z angličtiny), a to i po započtení ceny elektřiny v běžné americké domácnosti. V oznámení na firemním blogu Nvidia dodává, že víc než polovina amerických domácností má dva a víc počítačů; odkud to číslo bere, neuvádí.

PAIR byl jen jednou z položek berlínského oznámení. Nvidia zároveň ohlásila, že kompaktní počítače s Windows označené RTX Spark přijdou v říjnu od Lenova a Aceru, a že nové optimalizace v llama.cpp a vLLM zrychlují lokální inferenci na jejích grafikách až 1,9krát. Agenti Perplexity Portable Computer, Hermes Agent a OpenClaw mají dostat zjednodušenou instalaci na Windows s grafikami Nvidia.

Zdroje

• NVIDIA PAIR Virtual Inference Router Expands Available Compute on Your Local Network, NVIDIA Technical Blog, 3. 9. 2026
• Repozitář NVIDIA/Personal-AI-Router, GitHub, vydání 0.1.0 z 26. 8. a 0.1.1 z 28. 8. 2026
• Personal AI Router for Local Inference, stránka produktu, NVIDIA
• Sparks Fly: NVIDIA Accelerates Local AI at IFA 2026, NVIDIA Blog, 3. 9. 2026
• Nvidia launches free tool that links idle computers into a personal AI data center, The Verge, 3. 9. 2026

Přední počítače u techniky

Řídicí vrstva urychlovačů stojí na strojích, kterým se v CERNu říká front-end computers. Sedí blízko techniky, kterou obsluhují. Je jich kolem 2 200, připojeno k nim je asi 17 000 zařízení a to číslo dál roste. Komplex se rozkládá na 43 km², má zhruba 36 km trubek se svazkem a asi 70 000 kabelů mezi elektronikou a počítači. Většina těch strojů nemá disk a zavádí se ze sítě, hardware je z velké části vlastní a ovladače k němu píše CERN sám.

Rozhodl přepínač překladače

Důvod přechodu není v tom, že by se někomu líbil jiný logotyp. Red Hat Enterprise Linux 9 se podle dokumentace Red Hatu staví pro architekturu x86-64-v2, desítka pro x86-64-v3. Jsou to úrovně instrukční sady: každá další předpokládá novější procesor, a co ji nesplní, přeložený systém na sobě nespustí. Přednášející to ve slidech shrnují jako vynucené zastarání pomocí přepínače překladače a označují za poslední kapku, po které tým řízení urychlovačů Red Hat Enterprise Linux opustil.

Cena za setrvání

Riziková analýza z druhého čtvrtletí 2023 spočítala, co by stálo zůstat. Vyšlo z ní zhruba jedenáct desek k přepracování, nábor dvou elektroniků, dvou programátorů a dvou techniků, přerovnání a překabelování racků a zásah do většiny systémů při oživování. Odhad nákladů 5,4 milionu švýcarských franků, termín konec roku 2026, odhadovaná úspěšnost optimistických 20 % – a to za předpokladu, že by nová řešení byla bez chyb.

Tým to uzavřel tím, že softwarový problém se má řešit softwarem. Místo přepracování desek přešly počítače urychlovačů na jinou distribuci.

Plán B, který se stal plánem A

Původní záměr byl v ekosystému zůstat. CERN chtěl ověřit CentOS Stream 9, přejít na desítku, jakmile vyjde, případně později na jedenáctku, a používat ji v provozu od dalšího restartu urychlovače až do roku 2033. Souběžně ale svou integrační vrstvu odpojil od konkrétní distribuce a připravil si záložní systém. Tím byl Debian.

Předtím vedla cesta CERNu jinudy. Řídicí systémy urychlovačů jely nejdřív na Scientific Linuxu, který organizace spoluudržovala, potom na CentOSu; slidy zmiňují jeho cernovskou podobu CC7. Konec klasického CentOS Linuxu přišel dřív, než se počítalo, a tým řízení si položil otázku, jak moc chce na tom ekosystému viset.

Vydání se musí trefit do harmonogramu urychlovače

Urychlovač se nedá aktualizovat, kdykoli se to hodí. Provoz má pevný rozpis období běhu, technických zastávek a dlouhých odstávek, takže i distribuce pod řídicí vrstvou do toho rozpisu musí zapadnout. Přednášející to pojmenovali jako výběr vydání, u kterého nebude potřeba záplatovat běžící urychlovač za provozu.

Slidy proto rozebírají tři varianty. Vývoj na Bookwormu a nasazení Trixie od roku 2026 do roku 2030 s přechodem na Debian 15. Nebo Trixie s rozšířenou podporou až do roku 2033. Nebo rovnou Bookworm s rozšířenou podporou do téhož roku. Dlouhodobá podpora je pro CERN podle vlastních slov zásadní a organizace kvůli tomu začala sponzorovat firmu Freexian, aby komunitu kolem Debianu posílila.

Kde Debian zdržel

Prezentace nekončí u chvály. Tým vypsal i to, na čem uvázl: chybí standardní nástroje na automatické sestavení a zveřejnění balíčků, oficiální nástroje jako buildd nebo dak jsou podle něj příliš úzce zaměřené a pro binární moduly jádra nemá projekt závazné pravidlo, takže si CERN musel vymyslet vlastní. Řada nástrojů si navíc neporadí s několika verzemi téhož balíčku, což znamená zvláštní repozitář pro každou revizi. Cesta balíčku do distribuce má ostatně svá úzká místa i na straně samotného projektu.

Debusine ani OBS se pro tenhle případ nehodily. CERN proto napsal vlastní zásuvný modul do Koji, aby uměl i balíčky Debianu, a použil tak dál svoji stávající infrastrukturu na stavbu RPM.

Čeho se změna netýká

Datová centra a výpočty pro experimenty zůstávají na Red Hat Enterprise Linuxu a AlmaLinuxu; CERN to po zveřejnění zprávy upřesnil pro Phoronix. Odpovídá tomu i jeho vlastní dokumentace. Stránka Linux @ CERN uvádí, že Debian je podporovaný jedině na předních systémech urychlovačů, a to na základě dohody mezi odděleními; na stolní počítače, notebooky ani na stroje v datovém centru se podpora nevztahuje. Ze smlouvy jsou přitom kryté jen dva balíčky, cern-ca-certs a cern-get-keytab. Zrcadla Debianu a denní snímky Bookwormu i Trixie má organizace na vlastním serveru, přičemž Debian 13 se do 31. března 2026 nesnímkoval vůbec.

Poučení, které si oba inženýři z celé práce odnesli, znělo prostě: nepředpokládej, že co běží na verzi X distribuce, poběží i na X+1. A přenositelnost mezi distribucemi je dobrá věc.

Zdroje

• Controlling CERN's Accelerators with Debian – přednáška Federica Vagy a Nikose Tsipinakise, MiniDebConf Winterthur, 30. srpna 2026, včetně slidů a záznamu
• Debian (Limited Support) – dokumentace Linux @ CERN
• Debian micronews, zápis z 1. září 2026
• RHEL 9.0 Release Notes: Architectures a RHEL 10.0 Release Notes: Architectures
• CERN Transitioning Industrial Computers To Debian After Being A Longtime RHEL Institution, Phoronix, 2. září 2026

Americké úpravny vyrobily v roce 2025 asi 2,1 milionu liber uranového koncentrátu U₃O₈. Proti 657 000 liber z roku 2024 je to víc než trojnásobek a podle roční zprávy americké energetické informační správy (EIA) největší objem od roku 2017. V kilogramech jde asi o 950 tun; libra má 0,4536 kilogramu a přepočet je náš, EIA uvádí jen libry.

Uran vyrábí jedna klasická úpravna a pět loužicích závodů

U₃O₈ je oktaoxid triuranu, sypká žlutá látka, které se v oboru říká žlutý koláč. Vzniká z rudy hned v úpravně a je to první pevný meziprodukt na cestě k palivu. Teprve po něm přijde převod na fluorid uranový, obohacení, lisování pelet a montáž palivových souborů.

Zpráva jmenuje tři klasické úpravny a dvě z nich na konci roku 2025 stály. Shootaring Canyon v Utahu a Sweetwater ve Wyomingu čekaly v pohotovosti s celkovou kapacitou 3 750 krátkých tun materiálu denně, výrobu obnovila jen White Mesa v Utahu. Vedle nich pracovalo pět závodů na loužení na místě, tedy na metodu, která uran vyplavuje roztokem přímo z ložiska a ražbu vůbec nepotřebuje: Alta Mesa, Lost Creek, Smith Ranch-Highland, Ross a Willow Creek. Jejich společná kapacita 13,3 milionu liber ročně přitom meziročně klesla ze 14,1 milionu, takže víc uranu vzniklo na užším zařízení. Dalších pět takových závodů zůstalo odstavených a sedm se plánuje ve třech státech.

Vrtů bylo nejvíc od roku 2012

Průzkumné vrty, kterými se ložiska hledají a mapují, daly v roce 2025 dohromady 1 824 otvorů a 1 016 000 stop délky proti 1 324 otvorům a 613 000 stop o rok dřív. Rozvojové vrty, které měří velikost, tvar a bohatost už objeveného ložiska, přidaly 3 708 otvorů a 1 302 000 stop proti 2 462 otvorům a 1 260 000 stop. Tolik otvorů se podle EIA nevyvrtalo od roku 2012, tolik metráže od roku 2013.

Stejným směrem jdou peníze a lidé. V odvětví se odpracovalo 711 osoboroků, o 41 % víc než 506 v roce 2024 a nejvíc od roku 2014. Výdaje na pozemky, průzkum, vrtání, těžbu a rekultivaci vyšly na 234,7 milionu dolarů proti 160,0 milionu; taky nejvíc od roku 2014.

Skoro polovinu národní výroby má jedna firma

Kolik vytěžila která společnost, EIA tají, aby z čísel nešly odvodit obchodní údaje jednotlivých firem. Jednu velkou položku ale zveřejnila sama těžařská společnost: Energy Fuels ve výsledcích za rok 2025 uvádí 1 015 000 liber hotového U₃O₈, tedy skoro polovinu toho, co EIA napočítala za celé Spojené státy. V dolech Pinyon Plain, La Sal a Pandora firma vytěžila rudu a mineralizovaný materiál s obsahem asi 1 720 000 liber uranu; samotný Pinyon Plain z toho dal 1 530 000 liber při kovnatosti kolem 1,62 %.

Zpracovatelskou kampaň na klasickou rudu spustila Energy Fuels ve White Mese ve čtvrtém čtvrtletí 2025 a počítala s tím, že poběží do druhého čtvrtletí 2026. Prodala 650 000 liber uranu za průměrných 74,21 dolaru za libru, dohromady za 48,2 milionu dolarů. Rok přesto uzavřela ztrátou 86,1 milionu dolarů, mimo jiné kvůli nákladům po převzetí australské Base Resources na konci roku 2024 a kvůli spotové ceně uranu, která byla podle firmy loni v průměru zhruba o 13,8 % níž než v roce 2024.

Domácí těžba stačí na necelou dvacetinu nákupů

Trojnásobek zní silně, ale zajímavější je poměr k tomu, kolik uranu americké elektrárny doopravdy potřebují. Jejich provozovatelé nakoupili v roce 2025 celkem 46,9 milionu liber ekvivalentu U₃O₈, tedy o devět milionů méně než v roce 2024, a zaplatili za ně váženým průměrem 58,46 dolaru za libru – o 11 % víc než rok předtím. Domácí výroba tak vystačila na necelou dvacetinu nákupů; ten podíl je náš, obě čísla jsou od EIA. Ten vážený průměr navíc pokrývá i dodávky ze starých dlouhodobých smluv, takže se s cenou, za kterou prodá jedna firma v jednom roce, přímo srovnávat nedá.

Ještě zřetelněji mluví původ dodaného materiálu. Nejvíc ho přišlo z Kanady, 32 % všech dodávek; následoval Kazachstán s 28 % a Austrálie s 15 %. Na materiál amerického původu připadlo sedm procent. Ztrojnásobená domácí těžba je tedy zatím spíš obrat trendu než změna toho, odkud se palivo bere.

Zprávu z června EIA v srpnu dvakrát upravila

Za čerstvou zprávou je starší dokument. Roční přehled o domácí těžbě uranu s daty za rok 2025 vyšel 23. června 2026, EIA ho pak 20. srpna a 27. srpna vydala znovu. V oznámení o opravě obě změny označuje za upřesnění: poprvé u věty o 2,1 milionu liber proti 657 000 z roku 2024, podruhé u věty o vrtech a rekordech od roku 2012 a 2013. Jak ta místa vypadala předtím, oznámení neuvádí. Souhrn v přehledu Today in Energy, ze kterého většina zpráv o americkém uranu vychází, nese datum 28. srpna – tedy den po druhé opravě. Ze stejného přehledu je i srpnový odhad rekordní americké těžby zemního plynu.

Zdroje

• Těžba uranu v USA se v roce 2025 víc než ztrojnásobila, Today in Energy, EIA, 28. 8. 2026
• Roční zpráva o domácí těžbě uranu, data za rok 2025, EIA, vydáno 23. 6. 2026, znovu vydáno 27. 8. 2026
• Oznámení o opravách zprávy za rok 2025, EIA, 20. a 27. 8. 2026
• Výsledky Energy Fuels za rok 2025 a výhled na rok 2026, Energy Fuels, 26. 2. 2026

Vývojová větev překladače GCC dostala 2. září 2026 sedm změn naráz. Zavádějí podporu rozšíření ACE, tedy AI Compute Extensions, což je nová sada maticových instrukcí pro architekturu x86. Autorem je Haochen Jiang z Intelu, u první z těch změn je jako spoluautor podepsaný Dipesh Sharma z AMD. Dohromady přidávají zhruba 2 160 řádků kódu a dokumentace.

Zvláštní na tom není objem, ale to, čí to rozšíření je. ACE nevydal Intel ani AMD, ale x86 Ecosystem Advisory Group, poradní skupina, kterou obě firmy založily na podzim 2024 kvůli tomu, aby se x86 nerozjíždělo do dvou nekompatibilních větví. ACE je první velká věc, kterou skupina vydala.

Sedm změn a jeden nový přepínač

Pořadí těch změn odpovídá tomu, jak se překladači obvykle nová instrukční sada přidává. Nejdřív základní rozpoznání rozšíření: příznak v CPUID, položka v seznamu vlastností procesoru, volba na příkazové řádce. Pak fiktivní registr tmm, blokový měřítkový registr BSR0, instrukce převzaté ze starší intelovské sady AMX a nakonec vlastní jádro věci, instrukce vnějšího součinu.

Nový přepínač se jmenuje -macev1 a podle dokumentace v souboru invoke.texi zapíná vedle ACEv1 také MMX, SSE až SSE4.2, AVX, AVX2 a AVX10.1. Kdo chce rozšíření zapnout jen pro jednu funkci, má na to atribut target("acev1").

__attribute__((target("acev1")))
void nasobeni_matic(void);

Dlaždice, vnější součin a osm registrů

Co ACE dělá, popisuje specifikace verze 1.16.2 vydaná 28. července 2026 a doprovodný zápis na blogu skupiny. Běžné vektorové instrukce počítají výsledek matice po jednorozměrných kusech. ACE místo toho zavádí operaci vnějšího součinu, která výsledek hromadí do dvourozměrné dlaždice, takže jedna instrukce vyrobí rovnou celý kus výstupní matice.

Dlaždicových registrů je osm a každý má šestnáct řádků po 512 bitech, tedy kilobajt na registr a osm kilobajtů celkem. K nim patří ještě blokový měřítkový registr. Ten je tam kvůli formátům s nízkou přesností: ACE umí INT8 a BF16, ale hlavně OCP FP8 a OCP MX, konkrétně MXFP8 a MXINT8. U nich sdílí skupina malých čísel jedno společné měřítko, což šetří paměť i propustnost.

Vstupy si ACE bere z vektorových registrů AVX10. Program tak může daty pohnout a přeformátovat je běžnými vektorovými instrukcemi těsně předtím, než je pošle do dlaždic. Osm dlaždic navíc dovolí držet naživu víc výstupních bloků naráz a méně sahat do paměti. Vlastní maticové instrukce dostaly v GCC jména podle konvence, jakou má VNNI pro skalární součin – vnější součin je jim podle popisu autora dost podobný.

Podobnou cestou jde AMD i mimo x86. Začátkem srpna zveřejnilo příručku k instrukční sadě CDNA5, kde u akcelerátorů Instinct nahradily maticové operace MFMA instrukce WMMA a přibyla jednotka na přesun dlaždic.

AMX zůstává, ale používat se má jedno, nebo druhé

Dlaždicový model zavedl Intel už v AMX, tedy Advanced Matrix Extensions. ACE se od něj neodstřihává: software ho uvidí jako novou „paletu“ v rámci téhož rámce, takže se dá znovu použít systémový programovací model i podpora stavu dlaždic v operačním systému. Část instrukcí ACE je z AMX rovnou převzatá – jedna dávka pochází z AMX-TILE, druhá z AMX-AVX512.

Zároveň ale v popisu jedné ze změn stojí, že se ACE a starší AMX nemají používat pohromadě. Autoři to v GCC vyřešili tak, že převzaté instrukce dostaly vlastní jména vestavěných funkcí s vloženým _ace_, zatímco vnitřní builtiny překladače zůstaly sdílené.

Zajímavý je i ten fiktivní registr tmm. U starého AMX řeší GCC vestavěné funkce vloženým assemblerem, protože dlaždice stejně nepřiděluje. U ACE se šlo jinou cestou a instrukce se popisují běžnými vzory, aby překladač viděl závislosti mezi nimi. Skutečné přidělování registrů to zatím není – autor v popisu píše, že chybí rozumný způsob, jak dlaždici odložit do paměti, a bez toho přidělování nemá smysl. Fiktivní registr je příprava na dobu, kdy se to vyřeší.

Čip zatím žádný

Procesor, který by ACE uměl, se zatím neprodává; Intel i AMD mluví o budoucích generacích. Ani vydání GCC s tou podporou hned tak nebude. Podle tabulky vydání vyšlo GCC 16.1 na konci dubna 2026 a 15.1 na konci dubna 2025, takže se sedmnáctka dá čekat na jaře 2027.

Druhý velký překladač je pozadu. Podpora ACE pro LLVM a Clang leží v žádosti o sloučení číslo 208408, otevřené od 9. července 2026, a samostatně se řeší typ pro blokový měřítkový registr. Ani jedna zatím sloučená není.

Skupina píše, že práce běží i na ladicích nástrojích a profilerech a že se počítá se zapojením do knihoven a rámců jako PyTorch a TensorFlow. To je zatím plán, ne hotová věc. Náš odhad: na tom, jestli se ACE ujme, rozhodne právě tahle vrstva, protože ručně psaný maticový kód píše málokdo.

Zdroje

• Historie repozitáře GCC – sedm změn s podporou ACEv1 z 2. září 2026
• AI Compute Extensions (ACE) Specification Version 1.16.2, x86 Ecosystem Advisory Group, 28. července 2026
• ACE: A Shared Path to Faster Matrix Math on x86, x86 Ecosystem Advisory Group, 27. dubna 2026
• GCC 17 Compiler Merges Initial Support For Intel/AMD AI Compute Extensions „ACE“, Phoronix, 2. září 2026
• GCC Releases – termíny dosavadních vydání

Kdo chce blokovat, musí si o to říct. Přepínač sedí v nastavení pod Settings → Browsing → Ad Blocker a ve výchozím stavu je vypnutý.

V poznámkách k vydání o něm není řádka

Ve zdrojovém kódu drží novou funkci příznak ad-blocker-feature systému Nimbus, kterým Mozilla zapíná věci na dálku. Výchozí hodnota je false a natvrdo zapnuto to má jen beta a vývojářský kanál. Tím se vysvětluje, proč se přepínač objevuje postupně. A taky proč o něm mlčí poznámky k vydání: nezmiňuje ho 154.0 ze 16. srpna ani 155.0 z 30. srpna.

Na iPhonu blokuje WebKit, ne prohlížeč

Na počítači a na Androidu si do Firefoxu doinstalujete uBlock Origin nebo AdGuard a je hotovo. Na iOS to nejde. Pravidla pro App Store v bodě 2.5.6 žádají, aby aplikace procházející web používaly „the appropriate WebKit framework and WebKit JavaScript“; o oprávnění k vlastnímu jádru se dá požádat jen v EU a v Japonsku. Firefox na iPhonu je tedy nadstavba nad WebKitem a rozhodnutí jeho vývojářů dopadají i na něj, naposledy třeba u rozhraní WebMCP.

Blokovat se proto dá jedině deklarativně: prohlížeč předá WebKitu seznam pravidel v JSONu a ten si ho přeloží do bytekódu. Pravidlo má dvě části, trigger říká kdy se použije a action co se stane. Akce jsou podle popisu od vývojářů WebKitu tři: block zahodí načtení, block-cookies ustřihne z požadavku cookies a css-display-none schová prvek stránky. Čtvrtá akce, ignore-previous-rules, sama nezablokuje nic. Ruší všechna pravidla, která stojí před ní.

Seznam má 63 730 pravidel a chodí ze serveru

Firefox si ten seznam nenese v aplikaci. Stahuje si ho ze služby Remote Settings, kterou Mozilla používá na nastavení doručované za běhu: kolekce tracking-protection-lists-ios, záznam ad-block, příloha merged.json o velikosti 7 750 897 bajtů. Ostatní blokovací seznamy se pořád čtou z lokálních souborů, jak upozorňuje komentář ve třídě ASAdBlockerListFetcher.

Ten záznam je veřejný, takže jsme si přílohu stáhli a pravidla spočítali sami. Je jich 63 730: z toho 57 056 typu block, 5 916 typu css-display-none a 758 typu ignore-previous-rules. Podmínku if-domain nese 6 170 z nich, resource-type 4 749, load-type 2 159 a unless-domain 2 152. Filtry pocházejí z EasyListu, jehož licenci GPLv3 a CC BY-SA 3.0 doplnila Mozilla do aplikace 20. července.

Než seznam doputuje do WebKitu, přilepí Firefox na jeho konec stránky, které si uživatel z blokování vyřadil ručně. V kódu to vypadá tak, že se najde poslední hranatá závorka a nahradí se vlastními výjimkami a závorkou novou. Přeložený výsledek si prohlížeč drží podle otisku, takže se při každém spuštění nepřekládá znovu; nový překlad si vyžádá až seznam, který se na serveru změnil.

Proti dosavadní ochraně přibylo skrývání prvků

Reklamní domény blokoval Firefox na iOS i dřív, v rámci Rozšířené ochrany před sledováním postavené na seznamech Disconnectu. Rozdíl je vidět v číslech ze stejné kolekce: disconnect-block-advertising.json má 2 730 pravidel a všechna jsou typu block. Ani jedno neschová prvek stránky, takže po zablokovaném banneru zůstane prázdné místo.

Právě tohle uživatelé Mozille vytýkali, když si o blokátor obsahu psali na GitHubu: ochrana před sledováním sice reklamu ubere, ale s uBlockem Origin a standardní sadou filtrů se srovnávat nedá.

Na 259 doménách blokovač neudělá nic

Mozilla v oznámení píše, že reklamám ve výsledcích vyhledávání a reklamám, které si server servíruje sám, se blokovač vyhne. V seznamu to má velmi konkrétní podobu. Úplně poslední pravidlo celého souboru je ignore-previous-rules s filtrem .* a se soupisem 259 domén; protože stojí na konci, ruší na nich všechno, co je nad ním. Je mezi nimi 179 národních domén Googlu, dále Bing, DuckDuckGo, Ecosia a Baidu, dvacet domén Amazonu, čtrnáct eBaye a ze zdejších webů Seznam.cz a Mapy.cz. Kdo si blokovač zapne a otevře Seznam, nepozná tam žádný rozdíl.

Stranou zůstávají i sponzorovaní zástupci na nové kartě Firefoxu. Mozilla je v oznámení odděluje od reklam na cizích stránkách a píše rovnou, že se jich blokování netýká.

Žádost z roku 2019 tehdy skončila jako neplatná

O blokátor obsahu si na GitHubu někdo řekl 27. června 2019. Hlášení zavřel ještě týž den jeden z vývojářů projektu s tím, že Firefox reklamy blokuje ochranou před sledováním; ohlašovatel oponoval, že jsou to dvě různé věci. Táž žádost skončila 1. července 2019 v Bugzille se stavem INVALID. Práce začaly až letos: přepínač s příznakem přibyl do hlavní větve 20. května a odznak v nabídce 13. srpna.

Že seznam chodí ze serveru, má následek i mimo délku filtrů. Mozilla ho může vyměnit bez aktualizace v App Storu a stejnou cestou umí blokování zase vypnout. V kódu k tomu leží poznámka, že na týž mechanismus mají přejít i seznamy Rozšířené ochrany před sledováním, které se dnes načítají lokálně.

Prohlížečové jádro Servo vyšlo 31. srpna 2026 ve verzi 0.5.0. Shrnuje 488 commitů, které v něm přibyly za červenec. Nejlépe je z nich vidět oprava přednačítání obrázků: úvodní strana vyhledávače DuckDuckGo se v Servu kreslila bez kachny, kterou stránka vkládá jako obrázek SVG. Teď se kachna objeví.

Servo není prohlížeč, ale jádro k vestavění do cizího programu. Vzniklo v roce 2012 ve výzkumné části Mozilly, v roce 2020 nad ním převzala patronát Linux Foundation a od roku 2023 ho hostí Linux Foundation Europe. Napsané je v Rustu. Okno s adresním řádkem, kterému projekt říká servoshell, slouží hlavně jako ukázka toho, co jádro umí.

Kachna a Gumroad

Za chybějící kachnou stála drobnost v síťové vrstvě. Servo si u přednačítaných požadavků neschovávalo původní odpověď, takže obrázek, na který si stránka řekne dopředu, se pak neměl z čeho vykreslit. Opravu přinesl záznam č. 46668 sloučený 21. července.

Druhý příklad, který projekt uvádí, je obchod Gumroad. Ve verzi 0.4.0 se z něj kromě úvodní strany nevykreslilo skoro nic, ve verzi 0.5.0 se stránky produktů i přehled Discover zobrazí téměř bez vad. Jak si Servo vede na dalších webech, sbírá projekt od uživatelů: úspěchy chce hlásit ve vlákně na Zulipu, nezdary do evidence chyb.

Plátno ve více vláknech

Kreslení dvojrozměrného plátna (canvas) běží nově ve více vláknech. Podle zápisu k vydání to zvedlo snímkovou frekvenci až o 55 % a snížilo spotřebu energie na jeden snímek až o 42 %; paměti si plátno bere také méně.

Druhé zrychlení se týká sazby textu. Když se na stránce opakuje tentýž text v různých velikostech písma, vysází ho Servo až desetkrát rychleji než dřív. Rozvržení podle flexboxu je v měřeních rychlejší až o 3 % a úprava metody getElementsByClassName() zrychlila některé weby o procento.

Zranitelnosti v knihovnách a novější ANGLE

Verze 0.5.0 zavírá tři zranitelnosti v knihovnách, na kterých Servo stojí. Dvě jsou v rozboru XML: RUSTSEC-2026-0194 je kvadratická složitost kontroly, jestli počáteční značka nemá dvakrát týž atribut, a RUSTSEC-2026-0195 je neomezené přidělování paměti deklaracím jmenných prostorů, kterým jde paměť vyčerpat. Třetí, RUSTSEC-2026-0204, je v knihovně crossbeam-epoch: při formátování ukazatele se sáhne na paměť, na kterou míří, i když už neplatí.

Vedle toho Servo povýšilo ANGLE, vrstvu překládající volání OpenGL ES na grafické rozhraní systému. Dosud používalo podobu odvozenou z Firefoxu 115 ESR, nově z Firefoxu 140.12.0 ESR. Projekt sám dodává, že s tím nejspíš přišla i řada bezpečnostních oprav; jejich seznam neuvádí.

Pro ty, kdo Servo vestavují

Rozhraní pro vestavění má jednu nekompatibilní změnu. Metoda ServoBuilder::webxr_registry() zmizela a nahradila ji Servo::register_webxr_registry(). Registr se díky tomu zakládá až ve chvíli, kdy je ho potřeba, a servoshell si tím zkrátil start na polovinu.

Verze servoshellu pro Android běží nově na Androidu 10 a novějším, dosud to bylo až od Androidu 13. Projekt to podkládá podílem na trhu: 91 % proti dosavadním 68 %. Přibyly také sestavené soubory pro Linux na architektuře aarch64, do minulého vydání projekt zveřejňoval jen x86_64.

Co se rozdělalo

Označený text je v Servu nově vidět, což verze 0.4 ještě neuměla; vybírat ho myší zatím nejde, to má přijít později. Začala práce na titulcích ve formátu WebVTT: jádro soubor stáhne, rozebere a zpřístupní skriptu, vykreslit ho ještě neumí. Strom přístupnosti, který čtečkám obrazovky popisuje obsah stránky, se nově aktualizuje po částech místo přestavování celého; zapíná se přepínačem, mezi hotové funkce tedy nepatří.

Na konci zápisu projekt uvádí, že dostává 7 824 dolarů měsíčně v pravidelných darech, o 1,8 % víc než v červnu. Platí z nich servery pro průběžnou integraci a měření výkonu a část práce správců.

Zdroje

• July in Servo: more platforms, faster canvas, web fonts in SVG, and more!, servo.org, 31. 8. 2026
• Servo v0.5.0, GitHub, 31. 8. 2026
• Servo 0.5 Released: DuckDuckGo Properly Rendering, Up To 10x Faster Text Rendering, Phoronix, 31. 8. 2026

Přestupná sekunda je skok o jednu sekundu, kterým se koordinovaný světový čas UTC drží nablízku času podle otáčení Země. Vkládá se od roku 1972, a to pokaždé, když rozdíl mezi UTC a stupnicí odvozenou z otáčení planety (UT1) hrozí překročit 0,9 sekundy. Naposledy se to stalo na konci roku 2016. Od 1. ledna 2017 tak UTC zaostává za mezinárodním atomovým časem TAI o 37 sekund a Bulletin C z 6. července 2026 potvrdil, že ani letos v prosinci se přidávat nebude.

Teď má ten mechanismus skončit. Mezinárodní výbor pro míry a váhy (CIPM) rozeslal státům Metrické konvence návrh rezoluce C, podle kterého se UTC stane spojitou stupnicí 20. května 2027 a nejvyšší přípustná hodnota rozdílu |UT1-UTC| bude 3 600 sekund. Delegace o něm budou hlasovat na 28. Generální konferenci pro míry a váhy, která zasedá 13. až 15. října 2026 v Palais des Congrès ve Versailles.

V roce 2022 padlo rozhodnutí, chybělo k němu datum

Konec přestupných sekund sám o sobě novinka není. Rezoluce 4 z 27. konference v roce 2022 rozhodla, že se strop na rozdíl mezi UT1 a UTC zvýší v roce 2035 nebo dřív, a uložila výboru, aby na letošní konferenci předložil konkrétní hodnotu i plán zavedení. Nové je proto číslo a den. Místo krajní meze 2035 mluví text o květnu 2027.

Za tím posunem stojí odhad rizika ze semináře, který v březnu 2025 uspořádaly BIPM a Mezinárodní služba rotace Země a referenčních soustav (IERS). Rotace Země se zhruba od roku 2015 zrychluje a délka otáčky se srovnala s délkou atomového dne. Poprvé v historii by tedy mohlo být potřeba sekundu ubrat, ne přidat.

Tři skupiny odborníků na rotaci Země sestavily nezávisle na sobě stochastický model a došly k velmi podobným výsledkům; společný model pak ověřily na měřeních z předchozích staletí. Vyšlo z toho zhruba 30 % pravděpodobnosti, že do deseti let bude potřeba záporná přestupná sekunda, a k tomu asi 50 % pravděpodobnosti té obvyklé kladné. Popisuje to zpráva poradního výboru pro čas a kmitočet (CCTF) z července 2026.

Zápornou sekundu nikdo nikdy nezkoušel

Kladná přestupná sekunda znamená minutu o 61 sekundách. Záporná by znamenala minutu o 59 sekundách a za celou dobu existence UTC k ní nedošlo ani jednou. Studijní skupina 15 ITU-T, která má na starosti synchronizaci telekomunikačních sítí, ve stanovisku pro BIPM schváleném 24. října 2025 v Ženevě píše, že nedávné zkoušky s vysokou pravděpodobností ukázaly, že starší systémy zápornou sekundu správně neošetří. Připomíná u toho, že se přestupná sekunda ohlašuje jen půl roku dopředu.

I s tou kladnou si přitom každý provozovatel poradí po svém. Rezoluce z roku 2022 to říká bez obalu: postupy operátorů digitálních sítí a družicových navigačních systémů se neřídí žádnou dohodnutou normou a ta nejednotnost ohrožuje odolnost synchronizace, o kterou se opírá kritická infrastruktura. Google podle Nature sekundu rozmazává postupně přes celý den, jiné firmy ji přidají k jedné konkrétní minutě a část burz kvůli tomu posouvá obchodní hodiny.

Formální stanovisko poslal úřadu vedle ITU-T i radiokomunikační sektor ITU-R, pracovní skupina IEEE 1588 kolem protokolu PTP a sama IERS, která se zavázala provoz i ohlašování přestupných sekund podle rezoluce změnit. Průmysl podle zprávy CCTF vzkázal, že příprava na zápornou sekundu by byla srovnatelně náročná jako příprava na přelom tisíciletí.

Hodina, ne minuta

Pracovní skupina zvažovala tři meze: minutu, hodinu a žádnou pevnou hranici. Uživatelé vzkázali hlavně to, aby se UTC upravovalo co nejméně, nejraději nikdy. Systémy, které rozdíl mezi UT1 a UTC rozesílají dál, ale potřebovaly znát pevný strop, aby na hodnotu vyhradily dost bitů, takže třetí možnost padla. Ze zbylých dvou vyšla hodina.

O délce té záruky se v jednom dokumentu píše dvakrát jinak. Ve výčtu možností stojí, že hodina udrží UTC spojité zhruba tisíciletí; v závěrečném návrhu se mluví o několika staletích. Rozdíl zpráva nevysvětluje.

Slovo přestupná hodina, které se objevuje v titulcích o novince, v textu rezoluce nestojí. Návrh určuje strop, ale neříká, co se stane, až se k němu rozdíl přiblíží.

UT1 zůstane dostupné

Kdo skutečný sluneční čas potřebuje, o něj nepřijde. Rozdíl mezi UT1 a UTC dál rozesílají navigační zprávy družicových systémů, které už dnes umějí hodnotu větší než jedna sekunda, dále internetové služby IERS a národních metrologických ústavů a nakonec i rozhlasové časové signály, jakmile ITU-R doplní kód. Na jeho podobě se pracovní skupina WP7A shodla v březnu 2026.

Vysílačů, kterých se to týká, je málo. Průzkum CCTF z roku 2025 našel pět zemí, které rozdíl mezi UT1 a UTC pozemním rádiem ještě šíří: Argentinu, Kanadu, Rusko, Spojené království a Spojené státy. Všechny kromě Ruska podle zprávy kód nejspíš aktualizovat nebudou, protože tuhle techniku pokládají za překonanou. U Kanady si zpráva protiřečí: v poznámce pod čarou uvádí, že stanici CHU zrušila v červnu 2022, a v seznamu ji přesto vede.

Co se stane v říjnu

Rezoluce C je jedna ze sedmi, o kterých se ve Versailles hlasuje. Hlasuje se po státech a každý stát má jeden hlas; svolávací dopis nese datum 13. ledna 2026. Projde-li návrh, žádná další přestupná sekunda už nepřijde. Vkládat ji lze jen ke konci června nebo prosince, letošní prosinec IERS už vyloučil a nejbližší další termín, konec června 2027, leží až za dnem přechodu.

Den přechodu se kryje se Světovým dnem metrologie. Metrická konvence byla podepsána 20. května 1875 a UNESCO to datum vyhlásilo za svátek oboru; proč byl vybrán zrovna on, text rezoluce neuvádí.

Zdroje

• Návrhy rezolucí pro 28. zasedání CGPM, BIPM (PDF, rezoluce C na straně 23)
• Report from the CCTF on Draft Resolution C, červenec 2026 (PDF)
• Svolání 28. zasedání CGPM, 13. ledna 2026 (PDF)
• Rezoluce 4 z 27. zasedání CGPM (2022), BIPM
• Bulletin C 72, IERS, 6. července 2026
• The leap second is dead. Long live the leap hour?, Nature, 31. srpna 2026

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