NASA oznámila 7. srpna, že vědecká data ze sondy IMAP jsou volně ke stažení. Jde o měření sedmi z deseti přístrojů nasbíraná do 30. dubna. Stáhnout se dají ze dvou míst: z archivu Space Physics Data Facility v Goddardově středisku NASA a ze stránek mise na Princetonské univerzitě.

IMAP je zkratka z Interstellar Mapping and Acceleration Probe. Sonda má popsat heliosféru, tedy bublinu, kterou kolem sluneční soustavy nafukuje sluneční vítr a která ji odděluje od okolní Galaxie, a k tomu sledovat, jak se v okolním prostoru urychlují nabité částice. Nese na to deset přístrojů a podle NASA měří všechny.

Co je ve zveřejněné dávce

Sedm přístrojů, jejichž data jsou venku, měří převážně to, co k sondě přiletí přímo:

• MAG je magnetometr od Imperial College London a měří meziplanetární magnetické pole pocházející ze Slunce.
• SWAPI z Princetonské univerzity počítá ionty ve slunečním větru a zachycené ionty, které do soustavy přilétají zvenčí.
• HIT z Goddardova střediska NASA je teleskop na ionty o vysoké energii.
• GLOWS od Centra kosmického výzkumu Polské akademie věd sleduje ultrafialovou záři, kterou budí sluneční vítr, a z ní se odvozuje, jak se vítr v čase mění.
• SWE z Los Alamos National Laboratory měří elektrony ve slunečním větru.
• CoDICE ze Southwest Research Institute určuje hmotnost a elektrický náboj iontů ze slunečního větru i z mezihvězdného prostoru.
• IDEX z Laboratory for Atmospheric and Space Physics v Boulderu rozebírá složení mezihvězdného a meziplanetárního prachu.

Vedle vědecké dávky jede dál proud I-ALiRT. Je to měření kosmického počasí v téměř reálném čase, vysílané nepřetržitě a určené těm, kdo vydávají výstrahy před slunečními bouřemi.

Kamery na neutrální atomy zůstaly stranou

Nezveřejněné zůstávají IMAP-Lo, IMAP-Hi a IMAP-Ultra. Ta trojice snímkuje energetické neutrální atomy: částice, které na hranici heliosféry přijdou o svůj náboj, a proto pak letí rovně bez ohledu na magnetická pole. Ze směru, ze kterého dorazí, a z jejich energie se skládá obraz té hranice. Právě kvůli němu má mise ve jméně mapování.

Přístroje se dělí o rozsah energií, které jednotlivá částice nese. IMAP-Lo bere atomy pod 2 keV, IMAP-Hi od 0,4 do 15,6 keV a IMAP-Ultra od 3 do 300 keV; keV je kiloelektronvolt, jednotka energie jedné částice. Lo sedí na otočné plošince, Hi a Ultra jsou zdvojené a míří 45 a 90 stupňů od osy rotace sondy. Dohromady tak vidí skoro celou oblohu.

Proč data z těch tří ještě nejsou venku, NASA neuvádí. V oznámení stojí jen, že zatím nejsou připravená k vydání, a hned vedle toho věta, že sbírá data všech deset přístrojů.

Datum vydání se liší podle toho, kde se ptáte

Oznámení NASA nese 7. srpen. Stránka mise na Princetonu ale u dávky Release 1 uvádí, že je dostupná od 29. července, a totéž datum má i v patičce jako den poslední úpravy. Výpis archivu SPDF s tím sedí: šest složek přístrojů nese datum 29. července, jen GLOWS má 7. srpen. Datum u složky je čas poslední změny, ne nutně den, kdy se soubory objevily, takže z něj nejde vyčíst přesně, kdy se dávka otevřela. Většina dat ale byla na serveru zhruba deset dní předtím, než o nich NASA napsala.

Odkud sonda měří

IMAP odstartovala 24. září 2025 spolu s observatoří Carruthers Geocorona a s družicí SWFO-L1 americké NOAA. Do cíle dorazila 10. ledna 2026 a od té doby obíhá kolem Lagrangeova bodu L1 mezi Zemí a Sluncem. NASA jeho vzdálenost uvádí jako zhruba milion mil, což je v přepočtu asi 1,6 milionu kilometrů. Odtud má sonda nezacloněný pohled na Slunce a stihne varovat před nebezpečným zářením asi půl hodiny předem.

Hlavní část mise začala 1. února 2026 a je plánovaná na dva roky. Vede ji David McComas z Princetonské univerzity, sondu postavila a řídí Laboratoř aplikované fyziky Univerzity Johnse Hopkinse a na misi se podílí 27 institucí. V programu Solar Terrestrial Probes je IMAP pátá v pořadí. U bodu L1 není sama: kotví tam i sondy Wind a ACE od NASA a evropsko-americká SOHO.

Zveřejněná data končí 30. dubnem, takže za dneškem zaostávají o víc než tři měsíce. Kdy přibude novější dávka a kdy se otevřou tři chybějící kamery, NASA neuvedla.

Co Wine dělá

Wine je vrstva, která na Linuxu, BSD i macOS spustí program napsaný pro Windows. Nejde o emulaci celého systému: Wine překládá volání do knihoven Windows na volání, kterým rozumí Linux, takže se aplikace tváří, že běží na svém domácím systému. Odtud i jméno – je to zkratka z „Wine Is Not an Emulator“. Kopii Windows ani jejich licenci k tomu Wine nepotřebuje; chybějící knihovny píše znovu podle veřejného popisu rozhraní.

Nejvíc lidí Wine potká, aniž o něm ví: stojí pod vrstvou Proton, kterou Valve pohání hry ze Steamu na Linuxu a na konzoli Steam Deck. Proton k Wine přidává překladače grafiky DXVK a VKD3D-Proton; jeho verze 11 z července přešla právě na řadu Wine 11.

Chyba, která čekala dvacet let

Nejnápadnější položka v seznamu oprav nese číslo 4811. U projektu, kde čísla chyb dávno přerostla statisíce, tak nízké číslo samo prozrazuje stáří: hlášení je z března 2006. Týká se komponenty MSXML3, konkrétně objektu XMLDOMDocument, přes který programy pro Windows čtou a zapisují dokumenty ve formátu XML. Po dvaceti letech je chyba zavřená.

Že tak stará hlášení v evidenci pořád jsou, není u Wine výjimka. Projekt dohání rozhraní, které se samo mění, a na okrajové funkce starších knihoven se dostane až po letech.

Co ještě vydání přináší

Vedle jedné prastaré chyby má 11.15 i nové funkce. Wine nově zvládne místní ověřování NTLM přímo ve svém procesu; když narazí na potíž, umí se vrátit k dřívějšímu postupu přes samostatný nástroj ntlm_auth. NTLM je starý přihlašovací protokol Microsoftu postavený na výzvě a odpovědi – server pošle náhodné číslo, klient ho podepíše heslem a pošle zpět, samotné heslo po síti neputuje.

Knihovna BCrypt, tedy napodobenina šifrovacího rozhraní Windows, dostala další algoritmy KDF. Zkratka označuje odvození klíče – postup, který z hesla nebo ze sdíleného tajemství spočítá klíč pro šifrování. Přibylo taky víc převodů obrazových formátů v knihovně WindowsCodecs a podpora sestavení ARM64EC v režimu MinGW; ARM64EC je způsob, jak na ARM verzi Windows míchat v jednom procesu nativní kód pro ARM s emulovaným kódem pro x64.

Ze 41 oprav míří dvě na Wayland, novější zobrazovací systém Linuxu. Jedna spravuje vybledlé barvy, které vznikaly dvojím převodem do barevného prostoru sRGB, druhá posunutý obraz u aplikací běžících přes celou obrazovku v poměru 4:3. Zbylé opravy sahají od her po kancelářský WordPerfect 7 a účetnictví QuickBooks 2009.

Kam řada 11 míří

Wine 11.15 je vývojové vydání. Ta vycházejí zhruba po čtrnácti dnech – tohle přišlo výjimečně v sobotu místo obvyklého pátku – a postupně se v nich sbírá to, co pak uzavře stabilní verze. Stabilní řadu vydává Wine jednou za rok; jedenáctku uzavřel letos v lednu a od té doby na ni přibývají vývojová vydání s číslem za tečkou. Podle serveru GamingOnLinux se stabilní Wine 12 čeká začátkem příštího roku.

Zavírání tak starých hlášení má i druhou stranu: ukazuje, kolik práce v evidenci Wine pořád leží. Další vývojové vydání vyjde za dva týdny a fronta oprav se přesune do něj.

Vydání ohlásil projekt na stránkách WineHQ; seznam změn a oprav rozebral server Phoronix.

Harbor je open source registr kontejnerů – místo, kam si organizace ukládají obrazy kontejnerů, balíčky Helm, artefakty OCI i modely pro strojové učení. Patří k nejrozšířenějším řešením mezi těmi, kdo si registr provozují sami, a v nadaci CNCF má status graduovaného projektu, tedy nejvyšší stupeň zralosti. Od začátku k němu patřil ještě jeden kus techniky, o kterém se moc nemluví: Redis. Ve verzi 2.15.2 ho Harbor vyměnil za Valkey.

K čemu je registru rychlé úložiště

Harbor není prostý souborový server. Při každém nahrání nebo stažení obrazu odbavuje několik věcí zároveň a část z nich by hlavní databázi zbytečně zatěžovala. Proto k sobě od začátku měl Redis, rychlé úložiště, které data drží v paměti. Podle týmu Harboru na něm stojí čtyři věci:

• přihlašovací sezení uživatelů,
• vyrovnávací paměť manifestů, aby se popis obrazu (OCI manifest) při stažení nemusel pokaždé číst z databáze,
• fronta úloh na běh na pozadí – kontroly zranitelností, úklid nepoužitých dat a replikace mezi registry,
• počítadlo kvót, které hlídá, kolik obrazů se do jednoho projektu nahrává naráz.

Po výměně dělá Valkey přesně totéž. Uživatel ani provozovatel na sobě změnu nepozná, protože obě úložiště mluví stejným jazykem.

Co se stalo ve verzi 2.15.2

Tým Harboru otevřel návrh #22935 v březnu 2026 s jednoduchým zadáním: nahradit Redis Valkeyem ve všech místech, kde ho registr používá, a zařídit hladký přechod. Vlastní změnu přinesl pull request #23157, který se do hlavní větve dostal 28. dubna. K uživatelům ji tým poslal později, přenesením do opravného vydání: v poznámkách k verzi 2.15.2 je vedená jako přenesený commit „replace redis with valkey as cache backend“.

Technicky šlo o výměnu obrazu vnitřní cache. Harbor nově staví na obrazu valkey-photon, tedy Valkey postaveném nad distribucí Photon OS, ze které skládá i ostatní své součásti.

Proč pryč od Redisu

Důvod tým shrnul stroze: Redis v posledních letech opakovaně měnil licenci, a to je pro projekt, který na něm závisí, riziko. Redis si tou licenční houpačkou vážně prošel. V roce 2024 opustil svou původní licenci BSD a přešel na dvojici zdrojově dostupných licencí SSPL a RSAL, které Open Source Initiative za svobodné neuznává. Právě tehdy vznikl Valkey jako fork spravovaný nadací Linux Foundation. V květnu 2025 se Redis vrátil k otevřené licenci, když k osmé verzi přidal jako možnost AGPLv3, kterou už OSI schvaluje. Vývoj Redisu se od té doby nezastavil – v řadě 8 přišel třeba úspornější způsob ukládání hašů.

Přesto Harbor zvolil Valkey. Za rozhodnutím je podle týmu souběh několika věcí: permisivní licence BSD 3-Clause klade na uživatele méně omezení než copyleftová AGPL, projekt vede Linux Foundation s předvídatelným cyklem vydání a Valkey je zpětně kompatibilní na úrovni protokolu. Používá totiž stejný protokol RESP jako Redis, takže Harbor nemusel v kódu, který s úložištěm mluví, přepsat ani řádek; upravily se jen šablony obrazů.

O rychlost přitom nešlo. Valkey se sice chlubí tím, že se od svého základu ve verzi 7.2 zrychlil – jeho autoři uvádějí u verze 9.1 až dva miliony požadavků za sekundu ve vlastních měřeních, tedy víc než dvojnásobek –, jenže to je číslo výrobce a Harbor ho jako důvod přechodu neuvádí. Rozhodla licence a způsob správy, ne benchmark.

Přechod zatím není úplný

Jedna věc kulhá: oficiální šablona Helm, kterou většina lidí Harbor instaluje, se zatím neupravila a pořád jako výchozí stahuje obraz Redisu. Kdo chce Harbor s Valkeyem hned, musí obraz vnitřní cache přepsat ručně. V praxi to jsou dva parametry navíc při instalaci:

helm install harbor harbor/harbor \
  --set redis.internal.image.repository=goharbor/valkey-photon \
  --set redis.internal.image.tag=v2.15.2

První parametr říká šabloně, ať místo Redisu vezme obraz valkey-photon z Docker Hubu, druhý určuje jeho verzi. Až se výchozí hodnota v šabloně změní, odpadne i tohle.

Co z toho plyne

Výměna je z pohledu uživatele nenápadná a právě to je na ní podstatné: díky společnému protokolu šla provést, aniž by se venku cokoli pohnulo. Zapadá do širšího obrázku – Valkey dnes nabízejí jako spravovanou službu Amazon, Google i menší poskytovatelé a Harbor je jen jedním z větších projektů, které k němu od Redisu přešly. Kdo registr provozuje, si zatím vystačí se dvěma parametry navíc; zbytek se stane sám, až se doladí šablona.

Zdroje

• Harbor Chose Valkey, blog projektu Valkey, 28. července 2026
• Replace Redis with Valkey, návrh #22935 v repozitáři goharbor/harbor
• feat: replace redis with valkey as cache backend, pull request #23157
• Harbor v2.15.2, poznámky k vydání
• Redis is now available under the AGPLv3 open source license, blog Redisu, květen 2025

Alzheimerova choroba se v mozku pozná podle dvou věcí: podle amyloidových plaků, tedy shluků bílkoviny beta-amyloid mezi buňkami, a podle neurofibrilárních klubek uvnitř buněk. Studie zveřejněná 29. července v Nature Neuroscience k nim přidává třetí útvar, o kterém se dosud nevědělo. Autoři ho nazvali mitochondriální plaky.

Elektrárny buňky, které se nahromadí

Mitochondrie jsou drobná tělíska uvnitř buňky, která vyrábějí energii; říká se jim elektrárny buňky. Nervová buňka jich potřebuje hodně a rozváží si je i do svých dlouhých výběžků. Nový útvar je právě hromada takových mitochondrií, navíc poškozených, nacpaná do výběžků neuronu. Vědci ji popsali na myších, které mají Alzheimerovu chorobu uměle vyvolanou a zároveň nesou značku, jež mitochondrie ve tkáni rozsvítí podle toho, v jakém jsou prostředí.

Úklid, který nestíhá

Poškozenou mitochondrii má buňka odklidit. Slouží k tomu proces zvaný mitofagie: buňka vadné tělísko obalí a pošle ho do lysozomu, což je váček plný trávicích enzymů. Podle studie se u nemocných buněk lysozomy k hromadě mitochondrií dostávají opožděně a navíc nefungují, jak mají. Rozklad se proto nedokončí a mitochondrie se hromadí dál, ty čerstvě uzavřené v kyselém prostředí lysozomu i ty, které se do něj ještě nedostaly.

Nejdřív myši, pak lidská tkáň

Že nejde o zvláštnost jednoho myšího kmene, ověřili autoři na druhém, nezávisle vyšlechtěném modelu, kterému se říká 5xFAD. Mitochondriální plaky pak našli i v posmrtných vzorcích mozků lidí, kteří Alzheimerovou chorobou trpěli. Zdůraznit se sluší, oč jde a oč ne: je to pozorování na myších a na odebrané lidské tkáni, ne pokus na pacientech a ne léčba.

Vztah k amyloidu

Mitochondriální plaky se často objevují společně s amyloidovými a tvoří s nimi smíšené útvary. Podstatné ale je, že se umějí vytvořit i samy, v raných fázích nemoci, a podle tiskové zprávy Minnesotské univerzity možná dřív, než se vůbec začne ukládat beta-amyloid. Navíc obsahují hodně bílkoviny APP, tedy amyloidového prekurzorového proteinu, což je molekula, ze které beta-amyloid vzniká. Autoři z toho vyvozují, že by hromadění poškozených mitochondrií mohlo vznik amyloidových plaků pomáhat rozjíždět, ne být jen jeho následkem.

Proč na tom záleží

Na rozdíl od amyloidových plaků, které leží mimo buňky, zasahují mitochondriální plaky přímo do neuronů. To z nich podle autorů dělá možný cíl pro léčbu. „Tím, že pochopíme, jak tyhle plaky vznikají a jak přispívají k postupu nemoci, bychom mohli najít nové způsoby, jak Alzheimerovu chorobu zpomalit, nebo jí dokonce předejít,“ uvedl v tiskové zprávě Paul Robbins z Minnesotské univerzity (přeloženo z angličtiny). Dalším krokem má být hledání ukazatelů, podle kterých by šly plaky rozpoznat, a pak zkoušení látek, které by jejich hromadění zabránily.

Zdrženlivost je namístě. Práce je pozorovací a popisuje mechanismus, ne lék; cesta od nového cíle k funkční léčbě bývá u Alzheimerovy choroby dlouhá a plná slepých uliček. Doložený je zatím samotný nález a jeho mechanismus u myší a v odebrané tkáni; že plaky nemoc opravdu pohánějí a že se dají lékem ovlivnit, teprve čeká na ověření. Co studie přináší, je další kus obrázku toho, co se v nemocném mozku děje, a místo, kam se dá příště zamířit.

Běžná webová stránka se serveru ptá pořád stejně: pošle požadavek, dostane odpověď, spojení se zavře. Když má ale ukazovat něco, co se mění každou chvíli – zprávu v chatu, upozornění, číslo na živém přehledu –, tenhle model naráží. WebSocket ho řeší jinak: otevře jedno spojení a nechá ho otevřené oběma směry.

Proč se opakovaný dotaz nehodí na živá data

Nejjednodušší cesta k „živé“ stránce je HTTP polling: prohlížeč se v pravidelném intervalu ptá, jestli nejsou nová data. Každý dotaz je celý požadavek i s hlavičkami, i když odpověď zní „nic nového“, a interval se nedá nastavit dobře – krátký znamená spoustu prázdných dotazů, dlouhý zprávu se zpožděním. Navíc je to jednosměrné: server čeká, až se stránka zeptá. Šikovnější long polling (server odpověď drží, dokud nemá co poslat) zpoždění odstraní, ale je to jen obcházení toho, že HTTP na obousměrný provoz stavěné nebylo.

WebSocket: jedno spojení oběma směry

WebSocket je samostatný protokol popsaný v RFC 6455 (vydané v prosinci 2011). Spojení začíná jako obyčejný HTTP požadavek, který serveru řekne „přepni tohle spojení na WebSocket“ (handshake). Když server souhlasí, totéž TCP spojení zůstane otevřené a obě strany po něm můžou kdykoli posílat zprávy – bez nových hlaviček, bez čekání na dotaz. Adresa má schéma ws://, pro šifrovanou variantu wss://.

V prohlížeči se s tím pracuje přes objekt WebSocket: vytvoří se konstruktorem, poslouchají se události open, message, error a close, posílá se metodou send().

// Klient v prohlížeci
const socket = new WebSocket("wss://example.com/chat");

socket.addEventListener("open", () => {
  socket.send("ahoj");
});

socket.addEventListener("message", (event) => {
  console.log("prislo:", event.data);
});

socket.addEventListener("close", () => {
  console.log("spojeni se zavrelo");
});

Stav spojení drží vlastnost readyState. MDN u toho upozorňuje na jednu věc: WebSocket API neumí takzvaný backpressure – když zprávy chodí rychleji, než je stránka stíhá zpracovat, hromadí se v paměti a tempo si musí program ohlídat sám. Server se píše v Node.js, Pythonu nebo čemkoli jiném přes knihovnu pro daný jazyk.

Co k WebSocketu přidává socket.io

Holý WebSocket funguje, ale pár věcí neřeší: co když spojení spadne, co když ho podniková proxy nebo antivirus vůbec nepustí a jak zprávy rozlišovat podle druhu. Tyhle mezery zaplňuje socket.io, knihovna pro Node.js a prohlížeč, která nad WebSocketem staví pohodlnější vrstvu.

Uvnitř se dělí na dvě části. Spodní, Engine.IO, se stará o spojení a výběr přenosu. Má tři: HTTP long-polling, WebSocket a novější WebTransport. Trik je v pořadí: spojení se ve výchozím nastavení naváže nejdřív přes long-polling, který projde skoro všude, a teprve pak se po tichu povýší na WebSocket, pokud to jde. Tomuhle záložnímu chování se říká fallback a je to důvod, proč socket.io funguje i tam, kde čistý WebSocket neprojde. Horní vrstva pak přidává znovupřipojení, frontu neodeslaných zpráv, potvrzování doručení, skupiny (rooms) a jmenné prostory (namespaces).

Server se namontuje na HTTP server a poslouchá událost connection. Zprávy jsou pojmenované události – místo jednoho anonymního proudu dat má každý druh zprávy své jméno, na které se navěsí obsluha.

// Server (Node.js)
const { createServer } = require("node:http");
const { Server } = require("socket.io");

const server = createServer();
const io = new Server(server);

io.on("connection", (socket) => {
  console.log("klient se pripojil");

  socket.on("zprava", (text) => {
    io.emit("zprava", text); // rozesle vsem pripojenym
  });

  socket.on("disconnect", () => {
    console.log("klient odpojen");
  });
});

server.listen(3000);

Klient v prohlížeči je zrcadlo: zavolá io(), poslouchá stejné události přes on() a posílá je přes emit().

// Klient v prohlizeci
const socket = io();

socket.on("zprava", (text) => {
  // vykresli prichozi zpravu
});

socket.emit("zprava", "ahoj");

Volání io.emit() rozešle událost všem připojeným. To se ale hodí málokdy – zprávu z jedné chatovací místnosti nemají dostat všichni na webu.

Rooms: vysílání jen části klientů

Room je pojmenovaný kanál, do kterého socket vstoupí a zase z něj vystoupí. Je to čistě serverová věc – klient o seznamu svých místností nic neví. Vstup zařídí socket.join(), vysílání jen do dané místnosti pak io.to("nazev").emit(...).

io.on("connection", (socket) => {
  socket.join("mistnost-42");
});

// odejde jen do klientu v teto mistnosti
io.to("mistnost-42").emit("zprava", "ahoj mistnosti");

Vysílání z jednoho socketu přes socket.to("nazev").emit(...) dostanou všichni v místnosti kromě odesílatele – přesně to, co chatovací okno potřebuje. Při odpojení socket opustí všechny své místnosti sám. Rooms se hodí i na adresování jednoho uživatele: socket se přidá do místnosti pojmenované jeho identifikátorem a upozornění pak dorazí na všechny jeho karty a zařízení najednou.

Když spadne spojení

Jestli spojení žije, hlídá tlukot srdce (heartbeat): server v pravidelném intervalu (ve výchozím nastavení po zhruba 25 sekundách) pošle paket ping a čeká na pong; když se nevrátí, spojení se považuje za zavřené. Po výpadku se socket.io ve výchozím nastavení sám snaží připojit znovu – opakovaně a s prodlužujícími se odstupy, aby po pádu serveru nepřišla záplava dotazů naráz. Neodeslané zprávy počkají ve frontě.

Kdy stačí jednosměrné SSE

WebSocket ani socket.io nejsou vždycky potřeba. Když data tečou jen jedním směrem, ze serveru do prohlížeče, stačí lehčí nástroj: Server-Sent Events (SSE). Jede po obyčejném HTTP, v prohlížeči se obsluhuje objektem EventSource a znovupřipojení zvládá samo. Podle MDN je to jednosměrné spojení – klient přes něj serveru nic poslat nemůže.

const zdroj = new EventSource("/udalosti");

zdroj.onmessage = (event) => {
  console.log(event.data);
};

Na živé skóre, průběžné výsledky výpočtu, tok upozornění nebo streamování logu je SSE často přesně akorát: méně kódu než WebSocket a projde i přes prostředí, kde WebSocket vázne. Jakmile ale potřebujete posílat data i od klienta – typicky psát zprávy –, jednosměrný kanál nestačí a jste zpátky u WebSocketu.

Kdy realtime sáhnout

Ve zkratce tři případy. Když se data mění zřídka a pár sekund zpoždění nevadí, stačí obyčejný dotaz nebo občasný polling. Když server jen posílá a klient poslouchá (přehledy, upozornění, průběh), sáhněte po SSE. A teprve tam, kde spolu obě strany mluví oběma směry a na zpoždění záleží – chat, spolupráce v jednom dokumentu, hry, komunitní a chatovací weby –, se vyplatí WebSocket; a pokud chcete fallback, znovupřipojení a skupiny bez ručního dopisování, socket.io nad ním.

Za tu pohodlnou vrstvu se platí: socket.io přenáší data ve vlastním formátu, takže na druhém konci musí být zase socket.io, ne holý WebSocket klient. Kdo potřebuje mluvit s cizí službou nebo si vystačí s jedním druhem zpráv, bývá s čistým WebSocketem jednodušší. Co si vybrat, je hlavně otázka toho, kolik z přidaných funkcí opravdu využijete.

Zdroje

Zdroje: dokumentace socket.io, oddíl How it works (rozdělení na Engine.IO a socket.io, tři přenosy a povyšování spojení), tatáž dokumentace k rooms (rooms jsou serverový pojem, join a io.to().emit()), MDN: WebSocket (události, readyState a chybějící backpressure), RFC 6455 (standard protokolu, prosinec 2011) a MDN: Using server-sent events (SSE je jednosměrné).

Vite je nástroj, který stojí mezi vývojářem a prohlížečem: v jednom režimu obsluhuje kód, na kterém se právě pracuje, ve druhém z něj skládá balík pro nasazení. Ty dva režimy fungují každý jinak a právě v tom je jádro toho, proč je Vite rychlý. Vývojový server se rozjede skoro okamžitě i u velké aplikace, produkční build projde celý kód a zoptimalizuje ho. Následující řádky popisují, jak obojí funguje a kde jsou meze.

Vývojový server nad nativními ES moduly

Starší nástroje – bundlery jako webpack – musely před prvním zobrazením stránky projít celou aplikaci a slepit ji do jednoho souboru. Čím větší projekt, tím delší čekání. Vite tuhle práci rozdělí. Zdrojový kód aplikace, který se mění často, podává prohlížeči přes nativní ES moduly (ESM). Prohlížeč si o každý modul řekne sám ve chvíli, kdy ho potřebuje, a Vite ho v tu chvíli přepíše do podoby, které prohlížeč rozumí. Načte se jen to, co je pro aktuální stránku nutné, takže start serveru je takřka okamžitý bez ohledu na velikost projektu.

Výjimkou jsou knihovny z node_modules. Bývají jich stovky a nativní ESM neumí importy typu import { x } from 'knihovna' bez cesty k souboru. Vite je proto jednou předzpracuje (pre-bundling): převede starší formáty CommonJS a UMD na ESM a přepíše importy na platné adresy. Ve Vite 8 tohle dělá Rolldown, bundler psaný v Rustu; podle dokumentace je díky němu studený start výrazně rychlejší než u bundleru psaného v JavaScriptu. Výsledek se drží v mezipaměti, takže se předzpracování při dalších startech přeskočí.

HMR: výměna jednoho modulu za běhu

Když se soubor uloží, Vite nezahodí celou stránku. Přes rozhraní HMR (Hot Module Replacement, výměna modulů za běhu) vymění v prohlížeči jen ten modul, který se změnil, a nechá aplikaci ve stavu, v jakém byla – rozepsaný formulář zůstane vyplněný, otevřený panel otevřený. HMR jede taky přes nativní ESM. Frameworky se na něj napojují: Vite má vestavěnou podporu pro Vue single file components a pro React Fast Refresh. Aktualizace se podle dokumentace projeví v prohlížeči do 50 ms.

Produkční build: z modulů jeden balík

Pro nasazení se přístup obrací. Poslat do prohlížeče stovky samostatných souborů přes ESM by na produkci znamenalo stovky požadavků, takže tady Vite naopak bundluje. Build projde závislosti, vyhodí nepoužitý kód (tree-shaking), rozdělí výstup na části (code splitting), zmenší ho (minifikace) a do názvů souborů přidá otisk kvůli cachování.

Historicky na to Vite používal dva různé nástroje: esbuild pro rychlý překlad ve vývoji a Rollup pro důkladnou optimalizaci v produkci. Dvě odlišné pipeline ale znamenaly drobné rozdíly v chování a dvojí systém pluginů. Vite 8 je proto sjednotil do jednoho bundleru, Rolldownu. Ten je psaný v Rustu, k parsování a minifikaci používá Oxc a zůstává kompatibilní se stejným rozhraním pluginů, na které byl ekosystém Rollupu zvyklý. Nastavení buildu se ladí přes build.rolldownOptions.

import { defineConfig } from 'vite'

export default defineConfig({
  build: {
    rolldownOptions: {
      input: {
        main: 'index.html',
        admin: 'admin.html',
      },
    },
  },
})

TypeScript: přepis bez kontroly typů

Soubory .ts umí Vite importovat rovnou, bez další konfigurace. Důležité je vědět, co přitom dělá a co ne: typy jen odstraní, nekontroluje je. Přepis (transpilaci) obstará Oxc, což je řádově rychlejší než klasický tsc – ale typová kontrola se přeskočí.

Není to nedodělek, ale záměr. Přepis běží po jednotlivých souborech a sedí na model, kdy se každý soubor zpracuje ve chvíli, kdy si o něj prohlížeč řekne. Kontrola typů oproti tomu potřebuje znát celý graf modulů; nacpat ji do téhle pipeline by srazilo rychlost, kvůli které Vite existuje. Typy se proto hlídají zvlášť – při buildu příkazem tsc --noEmit, během vývoje v editoru nebo přes tsc --noEmit --watch v samostatném procesu.

Protože Oxc přepisuje soubor bez znalosti typů z ostatních souborů, dokumentace doporučuje zapnout v tsconfig.json volbu isolatedModules a u importů, které slouží jen pro typy, používat import type.

// tsconfig.json: "isolatedModules": true

import type { User } from './types'

export type { User }

SCSS a další preprocesory

Vite zpracuje .scss, .sass, .less i .styl bez zvláštního pluginu – stačí doinstalovat samotný preprocesor. Pro Sass a SCSS je to jeden balíček:

npm add -D sass-embedded

Dokumentace zároveň u nových projektů doporučuje spíš nativní CSS proměnné a PostCSS než plný preprocesor; vestavěné SCSS je tu hlavně pro projekty, které ho už mají. Přípona .module.scss spojí preprocesor s CSS moduly.

Entry pointy a konfigurace

Vstupním bodem Vite není soubor s JavaScriptem, ale index.html. Vite v něm najde značky <script type="module"> a <link> a odtud sleduje, co všechno do aplikace patří. Víc stránek znamená víc HTML souborů zapsaných do pole input v konfiguraci (viz ukázka výše).

Celé se to ovládá třemi skripty v package.json, které do projektu vloží už zakládací nástroj:

{
  "scripts": {
    "dev": "vite",
    "build": "vite build",
    "preview": "vite preview"
  }
}

dev spustí vývojový server s HMR, build vyrobí produkční balík a preview ten hotový balík lokálně naservíruje ke kontrole, než se nasadí. Konfigurace přitom bývá pár řádků: u běžného projektu si Vite vystačí s výchozími hodnotami a do vite.config.ts se sahá jen kvůli pluginům, více vstupům nebo úpravě buildu.

Za rychlostí Vite tedy nestojí jeden trik, ale rozdělení práce – ve vývoji se nebundluje skoro nic a kód jde do prohlížeče tak, jak je, kdežto při buildu se bundluje naplno. Že je to rychlejší než starší celobundlové nástroje, ovšem stojí zatím hlavně na číslech z dokumentace samotného Vite; nezávislé měření tenhle text nepřebírá.

Zdroje

• Dokumentace Vite – Features: z ní text bere předzpracování závislostí Rolldownem, chování TypeScriptu (jen přepis, ne kontrola typů), podporu preprocesorů a skripty v package.json.
• Dokumentace Vite – Why Vite: odtud pochází historie dvojice esbuild a Rollup a jejich sjednocení do Rolldownu ve Vite 8.
• MDN – JavaScript modules: standard nativních ES modulů, na kterých vývojový server stojí.

Heslo je sdílené tajemství. Jeden řetězec zná uživatel i server a kdo ho získá, vydává se za majitele účtu. Podle průvodce webauthn.guide stojí za ukradeným nebo slabým heslem 81 % průniků spojených s hackingem. Heslo se dá vylákat podvodnou stránkou, vytáhnout z uniklé databáze nebo uhodnout, když ho uživatel použil i jinde.

Passkey tenhle model obrací. Místo jednoho tajemství vzniká dvojice klíčů a server nikdy nedostane nic, co by šlo zneužít. Standard, který to řídí, se jmenuje WebAuthn a píše ho W3C společně s aliancí FIDO.

Dvojice klíčů místo sdíleného tajemství

Passkey stojí na asymetrické kryptografii. Při registraci autentikátor – čip v telefonu, notebooku nebo v hardwarovém klíči – vytvoří dvojici matematicky svázaných klíčů. Soukromý klíč zůstane bezpečně uložený v zařízení a nikdy ho neopustí. Veřejný klíč spolu s náhodným identifikátorem přihlašovacího údaje putuje na server, který si ho uloží k účtu.

Veřejný klíč není tajný: bez odpovídajícího soukromého klíče se s ním nedá přihlásit. To má dopad na bezpečnost celé databáze. Únik tabulky s veřejnými klíči útočníkovi nepomůže, protože chybí ta druhá polovina páru. Vývojář navíc nemá co hašovat ani solit – veřejný klíč se ukládá tak, jak přišel.

Klíč patří jen jedné doméně

Nejdůležitější vlastnost passkey je, že klíč je svázaný s konkrétním původem (origin). Při registraci server uvede pole rp.id, takzvané relying party ID – identifikátor strany, která uživatele ověřuje. Musí to být doména, na které se stránka právě nachází, nebo její nadřazená doména. Dvojice klíčů vytvořená pro webauthn.guide se nedá použít na evil-webauthn.guide.

Odtud plyne odolnost vůči phishingu. Když uživatel omylem přistane na podvodné kopii přihlašovací stránky, prohlížeč jednoduše žádný klíč pro cizí doménu nenajde a podpis nevznikne. Autentikátor totiž do podepisovaných dat vkládá skutečný původ stránky; server pak ověří, že sedí s tím jeho. U hesla stačí, aby ho uživatel napsal do falešného pole. U passkey není co napsat a podvodná doména podpis nedostane.

Registrace: navigator.credentials.create()

Přihlašovací údaj vzniká v prohlížeči voláním navigator.credentials.create(). Server k němu dodá parametry – hlavně náhodnou výzvu (challenge), která musí mít aspoň 16 bajtů a brání přehrání zachycené odpovědi.

const publicKeyCredentialCreationOptions = {
  challenge: challengeFromServer,          // >= 16 nahodnych bajtu
  rp: { name: "Moje appka", id: "example.com" },
  user: {
    id: userIdBytes,                       // ne osobni udaj
    name: "lee@example.com",
    displayName: "Lee",
  },
  pubKeyCredParams: [{ alg: -7, type: "public-key" }], // ES256
  authenticatorSelection: { authenticatorAttachment: "platform" },
  timeout: 60000,
  attestation: "none",
};

const credential = await navigator.credentials.create({
  publicKey: publicKeyCredentialCreationOptions,
});

Hodnota alg: -7 odkazuje do registru COSE a znamená ECDSA nad křivkou P-256 s hašem SHA-256 – nejběžnější volba. Pole attestation říká, jak moc server stojí o doklad původu autentikátoru; hodnota none znamená, že se o něj nezajímá, a pro většinu webů je to správně. Výsledný objekt obsahuje veřejný klíč zabalený v response.attestationObject a posílá se na server k uložení.

Přihlášení: navigator.credentials.get()

Při přihlášení uživatel dokazuje, že soukromý klíč vlastní. Server pošle novou výzvu, prohlídač zavolá navigator.credentials.get() a autentikátor výzvu podepíše – vznikne assertion, tedy podepsané tvrzení.

const publicKeyCredentialRequestOptions = {
  challenge: challengeFromServer,
  allowCredentials: [{
    id: credentialIdBytes,                 // ulozene pri registraci
    type: "public-key",
    transports: ["usb", "ble", "nfc", "internal"],
  }],
  timeout: 60000,
};

const assertion = await navigator.credentials.get({
  publicKey: publicKeyCredentialRequestOptions,
});

Server podpis ověří veřejným klíčem uloženým při registraci. Zkontroluje tři věci: že podepsaná výzva odpovídá té, kterou vydal, že sedí původ stránky a že sedí relying party ID. Když všechno platí, přihlášení je hotové – a po síti přitom nikdy neproletělo žádné tajemství.

Autentikátor v telefonu, nebo na klíčence

Autentikátory se dělí na dva druhy a výběr řídí pole authenticatorAttachment:

• Platform autentikátor je zabudovaný v zařízení – Windows Hello, Touch ID nebo Face ID. Je po ruce, ale je vázaný na ten konkrétní přístroj.
• Roaming (v API cross-platform) je přenosný. Typicky hardwarový klíč, který se připojí přes USB, NFC nebo Bluetooth a dá se použít na víc počítačích.

S tím souvisí ještě jedno dělení. Discoverable přihlašovací údaj (dřív se říkalo resident key) si autentikátor pamatuje celý včetně jména účtu, takže uživatel nemusí zadávat login – prohlížeč sám nabídne, s kterým účtem se přihlásit. Passkey je z definice vždy discoverable. U non-discoverable údaje se naopak klíč ukládá zašifrovaný na serveru a uživatel musí nejdřív říct, kdo je.

Kde do toho zapadá FIDO2

WebAuthn není osamocený. Je to browserová část většího celku zvaného FIDO2, který tvoří dvě specifikace. WebAuthn od W3C pokrývá API mezi webovou stránkou a prohlížečem. Druhá půlka je CTAP (Client to Authenticator Protocol) od aliance FIDO – protokol mezi prohlížečem a samotným autentikátorem. CTAP řeší, jak si spolu povídá počítač a bezpečnostní klíč nebo telefon.

Na CTAP stojí i přihlášení napříč zařízeními: passkey z telefonu jde použít při přihlášení na notebooku. Alliance FIDO tomu říká Cross-Device Authentication a jede po přenosu „hybrid“, který přes Bluetooth Low Energy ověří, že obě zařízení jsou opravdu blízko sebe. Pro vývojáře webu je podstatné, že CTAP implementují prohlížeče a autentikátory, ne server – ten vidí jen WebAuthn.

Ověření na serveru v PHP

Klientská část je jen půlka práce. Odpověď autentikátoru musí server rozebrat a ověřit, a to není triviální – specifikace popisuje u registrace vícebodovou proceduru. V PHP tuhle práci obstará knihovna web-auth/webauthn-lib od Spomky-Labs, dostupná i jako balíček pro Symfony.

composer require web-auth/webauthn-lib

Nejdřív se sestaví serializer, který převede zakódovaná data z prohlížeče na objekty, a správce podpory attestation. Pro běžný web bez potřeby dokládat model autentikátoru stačí typ none.

<?php

declare(strict_types=1);

use Webauthn\AttestationStatement\AttestationStatementSupportManager;
use Webauthn\AttestationStatement\NoneAttestationStatementSupport;
use Webauthn\Denormalizer\WebauthnSerializerFactory;

$attestationManager = AttestationStatementSupportManager::create();
$attestationManager->add(NoneAttestationStatementSupport::create());

$serializer = (new WebauthnSerializerFactory($attestationManager))->create();

Vlastní kontrolu obstarají dva validátory – jeden pro registraci (attestation), druhý pro přihlášení (assertion). Oba dostanou takzvaný Ceremony Step Manager, který v sobě nese jednotlivé ověřovací kroky.

<?php

use Webauthn\AuthenticatorAssertionResponseValidator;
use Webauthn\AuthenticatorAttestationResponseValidator;
use Webauthn\CeremonyStep\CeremonyStepManagerFactory;

$csmFactory = new CeremonyStepManagerFactory();

$attestationValidator = AuthenticatorAttestationResponseValidator::create(
    $csmFactory->creationCeremony()
);
$assertionValidator = AuthenticatorAssertionResponseValidator::create(
    $csmFactory->requestCeremony()
);

Validátor pak nad přijatou odpovědí ověří podpis, výzvu, původ i relying party ID a vrátí záznam přihlašovacího údaje k uložení. Tím se kruh uzavírá: klíč vytvořený v prohlížeči má na serveru protějšek, který ho umí zkontrolovat, aniž by kdy potřeboval znát nějaké heslo.

Zdroje

• MDN: Web Authentication API – průběh registrace a přihlášení, discoverable klíče, platform vs. roaming autentikátor.
• webauthn.guide – vázání klíče na doménu, ukázky volání create() a get(), údaj o 81 % průniků přes hesla.
• FIDO Alliance: FIDO2 – že FIDO2 tvoří WebAuthn a CTAP a jak funguje přihlášení napříč zařízeními.
• web-auth/webauthn-lib – serializer, správce attestation a oba validátory pro ověření odpovědi v PHP.

Každý objekt v aplikaci něco potřebuje: úložiště článků potřebuje databázi, odesílač pošty připojení k SMTP, kontroler potřebuje obojí. Otázka je, odkud si to má vzít. Špatná odpověď zní, že si to objekt obstará sám – zavolá globální funkci, sáhne na singleton nebo si spojení vyrobí uvnitř metody. Tím vznikne skrytá vazba, kterou z hlavičky třídy nikdo nepozná.

class ArticleRepository
{
    public function save(Article $article): void
    {
        $db = Database::getInstance();  // skryta vazba na globalni stav
        $db->query('INSERT INTO articles ...', $article);
    }
}

Kdo tuhle třídu čte, netuší, do jaké databáze se ukládá ani jak ji vyměnit. Dependency injection je na to jednoduchá odpověď: co třída potřebuje, to jí předáte zvenčí jako parametr. Úvodní kapitola dokumentace Nette to shrnuje do jednoho pravidla – ať je vám to podáno. Žádná magie, jen předání argumentů.

Hned na začátku je dobré nesplést si dva pojmy. Dependency injection je návrhový vzor, tedy způsob, jak psát kód. DI kontejner je nástroj, který to předávání za vás obstará. Jedno jde použít bez druhého: injektovat závislosti můžete i bez kontejneru, ručním předáním v konstruktoru.

Závislost je jen parametr

Nejběžnější způsob předání je přes konstruktor. Hodí se pro závislosti, bez kterých objekt nemá smysl – když je nedostane, nedá se vůbec sestavit. Od PHP 8.0 se dá zkrátit takzvanou promocí parametrů, kdy se vlastnost deklaruje rovnou v hlavičce konstruktoru, a od PHP 8.1 ji jde označit jako readonly, aby se po sestavení už neměnila.

class ArticleRepository
{
    public function __construct(
        private readonly Nette\Database\Explorer $db,
    ) {
    }

    public function save(Article $article): void
    {
        $this->db->table('articles')->insert([
            'title' => $article->title,
        ]);
    }
}

Teď je z hlavičky vidět všechno: třída potřebuje databázi a dostane ji zvenčí. Kdo ji použije, ji taky sestaví, a při tom rozhodne, kterou databázi dostane. Vedle konstruktoru zná Nette i předání přes setter (metoda set*()) pro nepovinné závislosti a zápis přímo do veřejné vlastnosti; ten se ale nedoporučuje, protože vlastnost musí být veřejná a stává se součástí rozhraní třídy.

Od ručního skládání ke kontejneru

Předávat parametry je hezké, dokud jich je málo. Jenže úložiště potřebuje databázi, ta potřebuje spojení, kontroler potřebuje úložiště – a než sestavíte jeden objekt, musíte ručně poskládat celý řetěz pod ním:

$controller = new EditController(
    new ArticleFactory(
        new Nette\Database\Connection($dsn, $user, $password),
    ),
);

Přesně tuhle práci dělá DI kontejner. Je to objekt, který umí vytvořit a nastavit ostatní objekty – v terminologii Nette se jim říká služby. Poprosíte ho o výsledný objekt a on si sám dohledá, co k jeho sestavení potřebuje. Aby přitom nevznikala pokaždé nová databáze, drží už vytvořené služby stranou a podruhé vrátí tutéž. Dokumentace to ukazuje na kontejneru napsaném ručně; skutečný kontejner v Nette (balíček nette/di, řada 3) si ale kód generuje a aktualizuje sám, takže ho nikdo nepíše ani neudržuje.

Autowiring hledá závislost podle typu

Služby se popisují v konfiguraci ve formátu NEON, což je čitelný textový formát podobný YAMLu. Bez další pomoci byste u každé služby museli vypsat všechny její závislosti:

services:
    articles: App\Model\ArticleRepository(@database, @cache.storage)

To je práce, kterou umí odvodit stroj. Slouží k tomu autowiring: podívá se na typy parametrů konstruktoru a dosadí odpovídající službu sám. Zápis se pak scvrkne na jméno třídy:

services:
    - App\Model\ArticleRepository
    - App\Model\ArticleFactory

Podstatné je, čím se autowiring řídí: výhradně typy, nikdy jmény služeb. Ví proto i o tom, že třída splňuje rozhraní, která implementuje, a třídy, ze kterých dědí. Jméno služby je jen pomocný štítek a jeho přejmenování nic nerozbije.

Má to jednu podmínku: každý typ smí být v kontejneru právě jednou. Kdyby byly dvě služby téhož typu, autowiring by nevěděl, kterou podat, a vyhodí výjimku. Řeší se to buď vyřazením jedné služby z autowiringu (autowired: false), nebo upřednostněním jedné z nich:

services:
    mainDb: PDO(%dsn%, %user%, %password%)
    tempDb:
        create: PDO('sqlite::memory:')
        autowired: false           # tempDb je z autowiringu vyrazena
    articles: App\Model\ArticleRepository   # do konstruktoru tedy dostane mainDb

Továrny, které Nette dopíše samo

Kontejner drží službu jako jeden sdílený kus. Někdy ale potřebujete vyrábět nové objekty za běhu – třeba nový článek pokaždé, když ho někdo napíše. K tomu slouží továrna: objekt, který jiné objekty vytváří a dodává jim jejich závislosti. V Nette ji nemusíte psát. Stačí rozhraní s jedinou metodou create() a deklarovaným návratovým typem a implementaci dopíše Nette DI za vás:

interface ArticleFactory
{
    function create(): Article;
}

services:
    - ArticleFactory

V kódu si pak vyžádáte objekt podle rozhraní a zavoláte create(). Když metoda přijme parametr, předá ho továrna do konstruktoru – podmínkou je, že se parametr jmenuje stejně jako parametr konstruktoru, podle čehož si je Nette spáruje.

class EditController
{
    public function __construct(
        private ArticleFactory $articleFactory,
    ) {
    }

    public function add(): void
    {
        $article = $this->articleFactory->create();
    }
}

Proč se to testuje líp

Výhoda, kterou injektování přináší zadarmo, se ukáže až u testů. Když třída dostává databázi zvenčí, můžete jí v testu místo ostré databáze podat náhradu – třeba SQLite v paměti nebo prázdnou atrapu – a sestavit ji přímo, bez kontejneru:

$repository = new ArticleRepository($fakeDb);
$repository->save($article);
// zadna ostra databaze, zadny globalni stav k prepsani

U té první, skryté verze to nešlo: Database::getInstance() uvnitř metody se v testu těžko obchází, protože sáhne na globální stav, který test neřídí. Úvodní kapitola dokumentace na to míří stejnou otázkou – do jaké databáze vlastně skrytý objekt ukládá, do ostré, nebo testovací, a jak se to změní. S injektováním je odpověď v hlavičce třídy a test si dosadí, co potřebuje.

Kontejner tedy není to hlavní. Hlavní je pravidlo, že si objekt závislost nebere sám, ale dostane ji podanou. Kontejner to jen zautomatizuje ve chvíli, kdy objektů přibude natolik, že by je ruční skládání pohřbilo.

Zdroje

• Nette: What is Dependency Injection? – pravidlo „ať je vám to podáno“ a rozdíl mezi vzorem a kontejnerem.
• Nette: Passing Dependencies – konstruktor, setter a property injection včetně promoce parametrů a readonly.
• Nette: Autowiring – řízení podle typů, podmínka jedné služby na typ a autowired: false.
• Nette: Generated Factories – generování továrny z rozhraní s jednou metodou create().

K čemu byl COW fixup

Když aplikace zapíše do souboru na btrfs, projde ten zápis odloženou alokací: souborový systém si rezervuje místo, založí takzvaný ordered extent, tedy záznam o chystaném zápisu, a teprve potom data putují na disk. Drží se u toho pravidlo, že každý blok označený za změněný má buď rezervaci, nebo ordered extent. Jenže stránku v paměti umí označit za změněnou i kód mimo souborový systém. Pak rezervace chybí a zápis nemá kam jít.

Přesně pro tyhle případy přibyl do btrfs v roce 2008 asynchronní pomocník, který chybějící rezervaci dodělá dřív, než se blok pošle na disk. To je COW fixup.

Proč se rušil

Qu Wenruo ze SUSE napsal 14. dubna záplatu, která mechanismus odstranila. Argumentoval tím, že chyby ve funkci get_user_pages(), kvůli kterým fixup vznikl, vyřešila správa paměti zavedením pin_user_pages(). V experimentálních sestaveních se navíc takové zápisy už delší dobu rovnou odmítaly a fungovalo to.

Druhý důvod mířil dopředu: původní fixup uměl jen celé stránky a nepočítal s tím, že blok souborového systému může být menší než folio, tedy než skupina stránek, se kterou jádro pracuje jako s jedním celkem. To překáželo práci na velkých foliích. V popisu záplaty přitom Qu Wenruo přiznal, že warningy, které mu při vstřikování chyb do cesty vstupu a výstupu naskakovaly, vysvětlit neuměl: podle vlastních slov se mu příčinu nepodařilo najít. David Sterba záplatu zařadil 8. června a do hlavní větve se dostala v otevíracím okně jádra 7.2.

Hosté KVM na s390 se zasekli na hodiny

21. července ohlásil Christian Borntraeger z IBM do konference linux-btrfs, že jim v denních testech náhodně tuhnou virtuální stroje, jejichž paměť leží v souboru na btrfs. Na hostiteli s390 s jádrem 7.2.0-rc3 uvázly ve stavu D dvě vlákna vCPU, obsluha irqfd, dva pracovníci zápisu, khugepaged i volání syncfs z balíčkovače dnf, a to na hodiny.

Rozbor výpisu paměti ukázal jediné folio o 64 stránkách, tedy 256 kB, patřící souboru s pamětí hosta o velikosti 1,25 GB. Zůstal na něm viset zámek, bitmapa změněných bloků byla prázdná a žádný zápis na disk neběžel.

Přímé čtení do sdílené mapy

Souběh za tím popsal Boris Burkov v záplatě, která fixup vrací. Folio je sdíleně namapované do paměti procesu a zároveň slouží jako cíl čtení s přímým přístupem. Čtení na začátku vidí folio jako změněné, takže ho jen připne a samo neoznačuje. Než ale doběhne, btrfs stihne folio uložit na disk a označit za čisté. Dokončení čtení pak folio označí za změněné znovu, tentokrát mimo souborový systém a bez rezervace.

Qu Wenruo k tomu 25. července poslal do sady testů fstests regresní test a popsal projevy střízlivěji než pozdější pull request: zaseknutý zápis dat, nebo přepnutí souborového systému do režimu jen pro čtení. Stačí k tomu čtení s přímým přístupem do namapovaného rozsahu a současné volání sync_range nad ním. U běžného btrfs, kde má blok i stránka 4 kB, jde podle něj o regresi v 7.2; u bloku menšího než stránka se to neošetřilo nikdy.

Návrat, ale postavený jinak

Burkovova záplata starý kód nevrací. Detekce se přesunula z ukládání na disk do funkce dirty_folio(), tedy do okamžiku, kdy někdo folio zvenčí označí za změněné. Ta událost nenese rozsah, takže se za podezřelé označí všechny dosud čisté bloky folia uvnitř souboru. Ukládání je pak přeskočí a předá pomocníkovi, který dodělá rezervaci, a běžný zápis, který mezitím rozsah pokryje, příznak zruší.

Sledovat se to musí po blocích, ne po foliích. Burkov v popisu rozebírá případ, kdy jedna půlka folia čeká na zápis do už rezervovaného ordered extentu a druhá potřebuje fixup: kdo to nerozliší, buď zapíše nerezervovaná data, nebo se zablokuje. Dohromady jsou to dva commity a 651 přidaných řádků v osmi souborech, přičemž polovina je podle Sterby ladicí a pomocný kód. Jako recenzent je pod ní podepsaný Qu Wenruo, tedy autor odstranění, a commit nese značku Assisted-by: LLM. Borntraeger už v hlášení napsal, že mu s rozborem výpisu i s návrhem opravy pomáhal jazykový model.

Kdy to bude ve vydání

Sterba změnu poslal Torvaldsovi 6. srpna jako samostatný pull request a ostatní opravy týdne oddělil do druhého se slovy, že je to pro jistotu (přeloženo z angličtiny). Pull request s fixupem přijal Torvalds ještě týž večer. Označkované vydání 7.2-rc7 v neděli dopoledne ještě nebylo, kód už ale v hlavní větvi je; stabilní jádro 7.2 vyjde podle Phoronixu ještě v srpnu.

Odstranění fixupu mělo uvolnit cestu velkým foliím a ta cesta zůstala volná i po jeho návratu: nový mechanismus s bloky menšími než folio počítá od začátku, na rozdíl od toho z roku 2008. Zaplatilo se za to tím, že regrese seděla v jádře od prvního kandidáta 7.2 do šestého, a 651 řádky nového kódu v sedmém, tedy ve fázi, kdy se do jádra obvykle přidávají jednořádkové opravy.

Kdo dnes napíše pro agenta dovednost a k ní server MCP, má hotovou jen půlku práce. Obě části jsou přenositelné samy o sobě, jenže obal kolem nich si každý klient vymyslel po svém: jiné rozložení adresářů, jiný manifest, jiný zápis konfigurace serveru. Autor tak balíček rozdvojí a od té chvíle udržuje dvě kopie něčeho, co se nikdy nelišilo. Ten obal popisuje specifikace Agent Plugins 1.0.0, zveřejněná ve čtvrtek 6. srpna 2026. Nic víc nepopisuje.

Plugin je adresář a manifest má dva řádky

Plugin je složka, ve které v kořeni leží povinný soubor plugin.json. Nejmenší platný manifest obsahuje odkaz na schéma a jméno:

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
  "name": "reports-plugin"
}

Všechno ostatní se hledá na pevných místech. Dovednosti leží v podadresáři skills/, každá ve vlastní složce se souborem SKILL.md, ve tvaru, který popisuje samostatná specifikace Agent Skills. Servery MCP vypisuje soubor mcp.json a u každého záznamu musí stát typ přenosu: stdio, Streamable HTTP, nebo starší HTTP+SSE. Klient tedy nemusí hádat, o jaký přenos jde, podle tvaru konfigurace.

Manifest schválně neumí dvě věci: přesunout součásti jinam a napsat je rovnou do sebe. Není proto co nastavovat ani v jakém pořadí to skládat. Když adresář skills/ chybí, klient načte to, co v balíčku je, a jede dál. Když se nepodaří spustit server z mcp.json, klient ten záznam přeskočí, chybu ohlásí a dovednosti z téhož balíčku zůstanou funkční.

Poslední složka v předepsaném rozvržení se jmenuje po obrácené doméně, třeba com.example.client/. Patří jedinému konkrétnímu klientovi a ten si do ní smí dát cokoli, co přenositelné jádro nezná: háčky, příkazy, vlastní agenty. Ostatní klienti ji ignorují.

Zvlášť specifikace řeší, kam smí balíček sáhnout. Cesta, kterou označuje za relativní vůči pluginu, musí začínat ./ a po vyhodnocení zůstat uvnitř kořene balíčku; symbolické odkazy a spojky, které vedou ven, musí klient odmítnout. Argumenty příkazů a hodnoty proměnných prostředí se přitom za cesty nepovažují, takže se tohle pravidlo na ně nevztahuje.

Nic nového nevymýšlí, jen to obaluje

Obě součásti, které formát balí, existovaly dřív. Dovednost je složka se souborem SKILL.md, ve kterém stojí jméno, popis a instrukce; agent si při startu načte jen jméno a popis a celý text až ve chvíli, kdy na úkol dojde. MCP je protokol, kterým se agent za běhu připojuje k databázím, prohlížeči, správě zdrojového kódu nebo cloudové službě.

Agent Skills podle serveru The Register vznikly v roce 2025 v Anthropicu; MCP je podle nadace Agentic AI Foundation její vlastní projekt. Agent Plugins ani jedno z toho nenahrazují a nemění jejich formát, píše se v oznámení řídicího výboru. Jediné, co přidávají, je krabice, do které se obojí vejde.

Distribuci, oprávnění ani podpisy verze 1.0 neřeší

Totéž oznámení vypočítává tři okruhy, které formát vědomě nechává mimo sebe. Distribuci, tedy registry, tržiště, instalaci a aktualizace. Běhové prostředí, tedy oprávnění, schvalovací postupy, sandbox a uživatelské rozhraní. A důvěru, tedy totožnost vydavatele, původ balíčku, podpisy a firemní politiku.

Soubor FUTURE_CONSIDERATIONS v repozitáři jde do podrobností a jmenuje konkrétně, co ve verzi 1.0.0 chybí: deklarace oprávnění v manifestu, ověřování kryptografických podpisů, řetězce potvrzení vážící vydaný balíček k jeho zdrojovému repozitáři, práci s hesly a klíči pro servery MCP, seznamy povolených a zakázaných pluginů pro firmy, schéma auditních událostí a závislosti mezi pluginy. Hned v úvodu ale stojí, že dokument je nezávazný a žádná z položek není pro budoucí vydání slíbená.

Podle nás je právě tohle nejcitlivější místo celého formátu. Soubor mcp.json smí spustit libovolný místní příkaz, kdežto otázku, kdo za balíček ručí, specifikace odsouvá jinam. Riziko se tím celé přesouvá na klienta, tedy na editor nebo nástroj v příkazové řádce, který plugin načte.

Za specifikací stojí pětice firem, projekt nadace to není

Řídicí výbor tvoří podle seznamu v repozitáři pět lidí: Clare Liguori za Amazon, Roshan Sadanani za Cursor, Harald Kirschner za Microsoft, Gav Verma za OpenAI a Jonathan Hefner za Vercel, který je zároveň vedoucím správcem. Google v den vydání oznámil, že se k výboru připojuje jako další správce a zastupovat ho bude Kevin Hou; v seznamu v repozitáři zatím není. Napsal to na svém blogu pro vývojáře spolu s tím, že podporu formátu začíná stavět do vlastních produktů.

Vztah k nadaci Agentic AI Foundation, která spadá pod Linux Foundation, se ve zdrojích rozchází. Oznámení vyšlo na blogu nadace, hned v prvním odstavci ovšem stojí, že jde o hostovaný příspěvek řídicího výboru a že Agent Plugins projektem nadace nejsou ani o zařazení nepožádaly. The Register naproti tomu píše, že formát nadace rychle přijala za svůj, byť bude fungovat samostatně, a citovanou větu o tom, že se sdílený formát drží předvídatelný, připisuje nadaci, ne autorovi příspěvku. Autorem je přitom Harald Kirschner, tedy člen výboru za Microsoft.

Text specifikace a dokumentace jsou pod licencí CC BY 4.0, schémata a kód pod Apache 2.0. Repozitář nemá ani jedno vydání ani značku; verze se vede jen číslem uvnitř dokumentu.

Formát dnes umí pět klientů

Stránka kompatibilních klientů jmenuje VS Code, Cursor, Kiro, GitHub Copilot a dvojici ChatGPT a Codex. U každého je uvedeno, které součásti umí načíst a jaké přenosy MCP zvládá: první čtyři všechny tři včetně staršího SSE, ChatGPT a Codex dva z nich. Google k tomu oznámil, že formát podporují jeho Agents CLI a Data Agent Kit.

Otevřená zůstává otázka, která vrstva nakonec převezme rozvoz hotových balíčků. Vedle balení běží v komunitě kolem MCP práce na tom, aby se dovednosti daly objevovat a rozdávat přímo přes server MCP. Autoři obou směrů je popisují jako doplňkové, míří ale na stejné místo v řetězci mezi autorem a agentem.

Americký energetický úřad EIA zveřejnil 7. srpna přehled bateriových úložišť v tamní elektrizační soustavě. Podle něj rostl jejich jmenovitý výkon poslední tři roky v průměru o 70 procent ročně. Na konci roku 2025 měla velkoprovozní úložiště 43,6 GW, za prvních šest měsíců letošního roku přibylo dalších 8,3 GW a celek se přiblížil 52 GW. Čísla pocházejí z předběžné měsíční evidence zdrojů, do které provozovatelé úřadu hlásí, co mají a co staví.

Gigawatt neříká, jak dlouho baterie vydrží

Výkon udává, kolik elektřiny umí úložiště dodat najednou. Neříká ale, jak dlouho to zvládne – to je energie a měří se v gigawatthodinách. Přehled EIA pracuje výhradně s výkonem, takže z něj samotného se nedá poznat, jestli baterie pokryjí večerní špičku, nebo jen krátký výkyv.

Druhé měřidlo nabízí zpráva U.S. Energy Storage Monitor, kterou vydaly 23. června asociace American Clean Power a analytická firma Wood Mackenzie. Za první čtvrtletí 2026 v ní stojí rekordních 3,3 GW a 8,4 GWh nově instalovaných baterií, z toho u velkoprovozních projektů přes 2,3 GW a 6,8 GWh. Poměr obou čísel vychází na dvě a půl hodiny provozu na plný výkon u celého trhu a na necelé tři hodiny u velkých projektů. Je to náš vlastní výpočet z údajů ve zprávě, sama poměr neuvádí.

Sečíst obě statistiky dohromady nejde. EIA počítá jen velkoprovozní úložiště, kdežto ACP a Wood Mackenzie k nim přidávají komerční, obecní i domácí instalace – samotné domácnosti podle nich v prvním čtvrtletí nasadily rekordních 1,3 GWh.

Rekordní čtvrtletí má podle ACP prozaické vysvětlení: část staveb se protáhla z roku 2025, kdy vývojáři honili lhůty pro daňové úlevy. Nejvíc baterií přibylo v Texasu, Kalifornii a Arizoně, nově se ale přidávají i státy, kde elektřinu vyrábějí a rozvádějí tytéž společnosti, jmenovitě Michigan a Georgia. U rodinných domů roste podíl fotovoltaik doplněných baterií: v prvním čtvrtletí 2026 to bylo 45 procent instalací proti 38 procentům o rok dřív.

Největší baterie stojí u solárních elektráren

Podle EIA nemají největší jednotlivá úložiště vlastní areál, ale sdílejí ho s fotovoltaickou elektrárnou. Farma Bellefield v Kalifornii, spuštěná v prosinci 2025, spojuje 500 MW panelů s 500 MW baterií a dodává do soustavy CAISO. Provozovatel plánuje obojí do letošního listopadu zdvojnásobit; pokud to vyjde, bude Bellefield největší americké úložiště. Druhý největší bateriový projekt je podle EIA floridské Manatee Solar Energy Center v provozu od roku 2021, které má 75 MW panelů a 409 MW baterií. Nevadské Gemini Solar Hybrid, spuštěné roku 2024, spojuje 690 MW panelů s 380 MW baterií.

Důvod toho spojení je obchodní. Provozovatel nabije baterie v době, kdy je velkoobchodní cena elektřiny nízká, a vybíjí je, když cena stoupne. EIA to popisuje bez obalu jako způsob, jak vydělat víc.

V plánech je dalších 54 GW

Na následující dva a půl roku hlásí provozovatelé úřadu záměry na dalších 54 GW: 14 GW do konce letošního roku, 26 GW v roce 2027 a 14 GW v roce 2028. ACP a Wood Mackenzie počítají do roku 2031 s 200 GW a 655 GWh instalovaných celkem, přičemž 85 procent nových instalací má připadnout na velkoprovozní sektor.

Obojí jsou ale plány, ne postavená zařízení. Analytici Wood Mackenzie sami upozorňují, že omezení nákupů od takzvaných foreign entities of concern (FEOC) budou příští dva až čtyři roky brzdou; koho přesně americké předpisy pod tenhle pojem řadí, zpráva neuvádí. Sehnat bateriové články a další díly, které těm pravidlům vyhoví, bude podle nich úzké hrdlo celého odvětví. U domácích instalací navíc čekají letos pokles o pět procent, a to kvůli omezené dostupnosti daňového financování a novým povolovacím pravidlům.

Jak velký kus sítě těch 52 GW představuje, ukáže srovnání se špičkou. Když texaská soustava ERCOT překonala letos v červenci rekord odběru a vyšplhala se přes 91 GW, byla to jen jedna z regionálních soustav země. Všechna americká velkoprovozní úložiště dohromady by tu jedinou špičku na papíře pokryla z více než poloviny – jenže jen do chvíle, než se vybijí, a to je údaj, který přehled EIA neobsahuje.

NASA zveřejnila 4. srpna aktualizaci programu Moon Base, tedy základny, kterou chce postavit u jižního pólu Měsíce. Je v ní i odpověď na otázku, co bude s technikou modulu HALO: Northrop Grumman z ní staví tři demonstrační náklady pro lunární povrch, označené Lunar Infrastructure Demo 1 až 3, zkráceně LID-1 až LID-3.

Z obytného modulu zbude napájení a avionika

HALO (Habitation and Logistics Outpost) měl být obytnou a zásobovací částí stanice Gateway. Ta měla obíhat kolem Měsíce a sloužit astronautům jako přestupní stanice cestou na povrch. NASA od stanice ustoupila a těžiště přesunula k povrchovým misím. Z modulu se proto přebírá to, co v něm bylo vyvinuto pro napájení a avioniku, tedy pro řídicí elektroniku; Northrop Grumman k tomu jmenuje ještě datová a mechanická rozhraní.

První demonstrace mají podle NASA ověřit systémy, které přežijí lunární noc, tedy vícedenní období stínu. Vedle toho mají mise vyzkoušet sdílenou energetickou infrastrukturu na povrchu, tedy zdroj, ze kterého by se napájelo víc zařízení najednou.

Ve chvíli, kdy se Amerika pouští do další kapitoly pilotovaného průzkumu vesmíru, pomohou naše demonstrace lunární infrastruktury proměnit Měsíc v místo, kde astronauti můžou zůstat, pracovat a dělat objevy ku prospěchu lidstva.

Řekl to v tiskové zprávě David Schiller, viceprezident Northropu Grummana pro civilní kosmonautiku a vědu; citace je přeložená z angličtiny.

Termín ani cenu neuvedl nikdo

Kdy mise poletí a co přeměna stojí, neuvedla NASA ani Northrop Grumman. Server Spaceflight Now uvádí, že podle doprovodného videa spadají do první fáze programu Moon Base. Ta podle NASA běží od teď do roku 2029 a počítá s víc než dvaceti robotickými přistáními.

Ve stejné aktualizaci NASA popsala i čtyři komerční přistávací moduly, které mají být hotové do roku 2028. Blue Origin má u modulu Blue Moon MK1 pro misi Endurance smontovanou konstrukci, pohon i avioniku a prošel termovakuovou zkouškou v Johnsonově středisku. Firefly staví misi Blue Ghost 2 jako dvojici: lander posazený na orbitální stroj Elytra měří 22 stop, tedy zhruba 6,7 metru, a má být prvním americkým přistáním na odvrácené straně Měsíce. Intuitive Machines skládá třetí lander Nova-C, pojmenovaný Trinity, a k němu první vlastní datovou přenosovou družici Altus-1. Voyager Technologies zkouší modul Griffin-1 v laboratoři JPL a chce startovat na konci roku 2026.

Nulová šance na termín a koroze v konstrukci

Proč NASA od stanice na oběžné dráze ustoupila, je nejlíp vidět z memoranda ML-26-002, které úřad generálního inspektora NASA vydal 24. června 2026. Týká se čtyř zrušených nebo přesměrovaných dílů programu Artemis a HALO je jeden z nich. Souhrnná hodnota jejich smluv vzrostla z necelých 2,8 miliardy dolarů na 5,9 miliardy a dodací termíny se posunuly až o sedm let.

Samotný HALO má v memorandu tuhle dráhu. V červenci 2019 zadala NASA zakázku bez soutěže Northropu Grummanu a později mu přiznala 187 milionů dolarů za předběžný návrh modulu. Roku 2021 se smlouva změnila na pevnou cenu se souhrnnou hodnotou 1,3 miliardy dolarů a dodáním v květnu 2025. V září 2024 přešla na úhradu nákladů s odměnou, hodnota vyrostla na 1,8 miliardy a dodání se posunulo na říjen 2026. V dubnu 2026 poslala NASA Northropu příkaz k zastavení prací; hodnota smlouvy tehdy byla 1,9 miliardy dolarů.

Důvody stojí v memorandu dva vedle sebe. Nezávislá hodnoticí komise programu Gateway došla k tomu, že pravděpodobnost dodržení termínu připravenosti ke startu je nula procent, a to už u termínu posunutého na říjen 2025. Podle komise „nedostatek realismu v harmonogramu může vést k nevhodným technickým rozhodnutím během vývoje“; i tahle citace je přeložená. Druhý důvod je materiálový: v roce 2025 našel subdodavatel, který primární konstrukci vyráběl, rozsáhlou korozi v modulu. Odhad dodání se kvůli tomu posunul o dalšího půl roku na červenec 2028.

Inspektorát z vývoje harmonogramu za předchozí rok a půl odhaduje, že by NASA modul nedostala dřív než v červenci 2031, tedy o šest let později, než měla. Když se k tomu připočte integrace s energetickým a pohonným modulem a zhruba deset měsíců letu na cílovou dráhu, nebyl by podle téhož odhadu Gateway provozuschopný dřív než v roce 2032.

NASA namítá, že projekce stojí na starých předpokladech

Odpověď podepsala 18. června Lori Glazeová, přidružená administrátorka pro vývoj průzkumných systémů. Uznává, že všechny čtyři systémy zdražily a nabraly zpoždění, ale namítá, že odhady inspektorátu vycházejí z výkonu za architektonických předpokladů, které už neplatí. Odvolává se na Ignition Day, veřejné představení přepracovaného programu Artemis z března 2026.

Jedna drobnost se v přetiscích rozchází. Spaceflight Now píše o memorandu z 3. června. To je datum, kdy NASA dostala návrh k připomínkám; samotné memorandum nese datum 24. června a podepsal ho Brian Mullins, zástupce pomocného generálního inspektora pro audity.

Na povrch Měsíce má tedy zamířit technika z modulu, do kterého NASA nalila skoro dvě miliardy dolarů. Memorandum přitom klade rozsáhlou korozi právě do primární konstrukce, kterou ani jedno z obou oznámení mezi přebíranými díly nejmenuje. Co bude s druhým dílem Gateway, energetickým a pohonným modulem, v žádném z těch dokumentů nestojí.

Odpověď, ve které není ani jeden záznam

Bezpečnostní oznámení k chybě CVE-2026-54876 vydal projekt OpenSSL 5. srpna 2026. Sedí v kontrole OCSP odpovědí. OCSP je protokol, kterým se u certifikační autority ověřuje, jestli certifikát mezitím nebyl odvolán; server si takovou odpověď může vyzvednout sám a přiložit ji rovnou k navazování spojení, čemuž se říká stapling.

Podle textu oznámení stačí, aby server poslal odpověď, ve které není ani jeden záznam o certifikátu. Prázdný seznam je v protokolu přípustný a dekodér OpenSSL ho přijme, jenže funkce, která odpověď zpracovává, na tom místě skončila dřív, než se dostala k úklidu. Struktura vytvořená voláním OCSP_response_get1_basic() tak zůstala v paměti.

Velikost úniku si útočník umí sám nastavit: do pole s certifikáty nasype smyšlené certifikáty, ty se rozeberou a uloží do struktury ještě předtím, než kontrola prázdného seznamu funkci ukončí. Jedno navázání spojení tedy nechá v paměti tolik, kolik toho protistrana naskládala, a klient, který běží dlouho a k takovému serveru se opakovaně připojuje, se dá vyčerpat.

Týká se to jen toho, kdo si kontrolu sám zapnul

Kontrola OCSP odpovědí není v OpenSSL ve výchozím stavu zapnutá. Chyba se projeví jedině u aplikací, které při ověřování certifikátu nastaví příznak X509_V_FLAG_OCSP_RESP_CHECK nebo X509_V_FLAG_OCSP_RESP_CHECK_ALL. Postižené jsou větve 4.0 a 3.6 a oprava má přijít až ve verzích 4.0.2 a 3.6.4, takže zranitelné je zatím všechno, co z obou větví vyšlo: nejnovější vydání jsou 4.0.1 a 3.6.3 z 9. června 2026. Řady 3.5, 3.4, 3.0, 1.1.1 a 1.0.2 podle oznámení zranitelné nejsou, protože ten kus funkčnosti v nich vůbec není. Modulů FIPS se chyba netýká, dotčený kód leží mimo jejich hranici.

Nízká závažnost proti 7,5 bodu

OpenSSL dal chybě podle vlastní bezpečnostní politiky stupeň „nízká“ a v záznamu CVE, který jako přidělující autorita sám vyplnil, žádné jiné hodnocení není. Americká databáze NVD u téhož čísla vede navíc známku CVSS 3.1 se skóre 7,5 a slovním stupněm „vysoká“, s vektorem AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H.

Ta známka od OpenSSL nepochází. Záznam ji vede jako druhotnou a u téhož zdroje stojí i posudek SSVC podepsaný rolí „CISA Coordinator“, takže je za ní americká agentura CISA. Týž posudek přitom uvádí, že o zneužívání se neví, že útok jde automatizovat a že technický dopad je jen částečný.

Obě čísla si přitom neodporují tak, jak to vypadá. Základní skóre CVSS popisuje samotnou zranitelnou součást a to, kolik aplikací dotčenou funkci vůbec zapíná, do něj nevstupuje. OpenSSL naopak právě tohle váží: u červnové chyby v téže kontrole napsal rovnou, že oba příznaky jsou ve výchozím stavu vypnuté a „z toho důvodu jsme problému přiřadili nízkou závažnost“ (přeloženo z anglického originálu).

Oprava je v gitu, vydání ne

Záplata existuje ve dvou podobách, commit d8c5104 pro větev 4.0 a commit 155b5fe pro 3.6. Ten druhý přidává dvanáct řádků a dva odebírá, celé v souboru crypto/x509/x509_vfy.c: kontrola počtu záznamů se oddělila od získání struktury a prázdná odpověď se nově pošle na úklidové návěští místo přímého návratu. Autorem opravy je podle oznámení Mounir Idrassi; commit nese autorské datum 29. června 2026 a do větve 3.6 ho 3. srpna začlenil Norbert Pocs.

Nová vydání kvůli tomu nebudou. Oznámení říká, že kvůli nízké závažnosti problému projekt nyní nová vydání OpenSSL nevydává (přeloženo z anglického originálu). Oprava se objeví až v nejbližším řádném vydání obou větví; oznámení mluví o verzích 4.0.2 a 3.6.4 s dovětkem, že se na ně teprve čeká. Kdo chce záplatu dřív, musí si ji vzít z gitu sám.

Třetí nález v jedné poměrně nové funkci

Vícenásobné přikládání OCSP odpovědí pro TLS 1.3 přibylo do OpenSSL 3.6.0, vydané 1. října 2025. Do nástroje s_client s ním přišly přepínače -ocsp_check_leaf a -ocsp_check_all, do s_server přepínač -status_all; podepsaní jsou pod tou změnou Michael Krueger a Martin Rauch. Od té doby má kontrola OCSP odpovědí tři bezpečnostní záznamy a všechny tři se týkají jen větví 3.6 a 4.0.

Dva z nich vyšly v jednom balíku 9. června 2026. CVE-2026-35188 je dvojí uvolnění téže paměti při kontrole přiložené odpovědi a OpenSSL mu dal stupeň „střední“; CVE-2026-42765 je přístup na nulový ukazatel, který nastane při ověřování dílčího řetězce bez vlastnoručně podepsané kotvy důvěry, se stupněm „nízká“. Srpnový únik paměti je třetí v pořadí.

O ohrožení přitom nerozhoduje jen číslo verze. Zjistit, jestli se vás chyba týká, je rychlejší ve vlastním kódu než ve výpisu balíčků: hledá se, jestli aplikace některý z těch dvou ověřovacích příznaků nastavuje. Kdo je nenastavuje, nemá důvod na 3.6.4 čekat.

Zdroje

• OpenSSL Security Advisory, 5. srpna 2026
• Přehled zranitelností OpenSSL
• Záznam CVE-2026-54876 v NVD
• Seznam změn větve OpenSSL 3.6

Balík shadow drží na linuxových systémech soubory /etc/passwd a /etc/shadow a patří k němu příkazy passwd, chage, useradd nebo su. Verze 4.20.0 s přezdívkou Ibores vyšla 29. července 2026 a zajímavá je hlavně tím, co v ní není.

Co ve vydání skončilo

Odstraněné věci byly ohlášené jako zastaralé už ve vydání 4.19 z prosince 2025, některé dřív. Podle poznámek k vydání zmizely:

• příkaz expiry(1), kterým si uživatel mohl nechat zkontrolovat platnost vlastního hesla,
• minimální doba mezi dvěma změnami hesla, a to najednou v pěti podobách: přepínač chage -m včetně interaktivní verze, passwd -n, proměnná PASS_MIN_DAYS v souboru login.defs a pole sp_min v /etc/shadow, které se nově ignoruje a maže,
• nástroj groupmems(8) na správu členství ve skupině, který má nahradit usermod(8),
• démon logoutd(8), který odhlašoval uživatele mimo povolené hodiny,
• překonané způsoby hašování hesel: hodnoty DES a MD5 u proměnné ENCRYPT_METHOD a proměnná MD5_CRYPT_ENAB.

Programy nově skončí chybou, když jim některý z odstraněných přepínačů nebo některou z proměnných podstrčíte. Poznámky k vydání to označují za záměr: má to pomoct najít skripty, které na nich stojí.

Dolní mez odešla proto, že ji nikdo nepředepisuje

Stárnutí hesel míří v projektu k úplnému konci. Návrh, který ho označil za zastaralé, se jmenuje rovnou Remove password aging a jeho autor Alejandro Colomar v něm napsal, že hesla by nikdy neměla vypršet a že je doloženo, jak tím bezpečnost hesel klesá (citace přeložena z angličtiny). Návrh na odstranění zbytku je pořád otevřený a autor si do něj poznamenal, že chce vyčkat asi rok, než se ve světě usadí následky téhle změny.

Proč šla jako první dolní mez, a ne horní, stojí v návrhu na odstranění pole sp_min: minimální doba mezi změnami hesla podle něj nevypadá, že by ji něco regulovalo, takže ji šlo odstranit hned. Poznámky k vydání jsou k ní tvrdší, píše se v nich, že se ta možnost považuje za zranitelnost a náhradu nedostane.

Obě meze přitom dělají něco jiného. Horní hranice, tedy PASS_MAX_DAYS, je ta, která uživatele každých pár měsíců nutí vymýšlet nové heslo. Právě tu americký NIST ve čtvrté revizi doporučení SP 800-63B zakazuje: ověřovatel nesmí po uživateli chtít, aby si heslo měnil pravidelně, a smí ho k tomu donutit jen tehdy, když má doklad o kompromitaci. Dolní mez naopak brání tomu, aby si uživatel po vynucené změně hned nastavil zpátky to staré. O ní se v tom doporučení nepíše.

V samotné verzi 4.20.0 horní mez zůstává, jen se z výchozího souboru login.defs vytratily předvyplněné hodnoty PASS_MAX_DAYS a PASS_WARN_AGE. Spolu s nimi jsou dál označené za zastaralé přepínače chage -M, -W a -I a jejich protějšky v passwd, useradd a usermod.

Výchozím hašováním je SHA512

Druhá velká změna se týká toho, čím se heslo v systému uloží. Podpora SHA256 a SHA512 byla dosud volitelná, ve verzi 4.20.0 je bezpodmínečná, a výchozí hodnota ENCRYPT_METHOD se posunula z DES na SHA512. Projekt k tomu dodává, že si správci mají metodu stejně napsat do konfigurace výslovně, protože jiné programy, které login.defs čtou, můžou pořád vycházet z DES.

Dvě regrese, které tam zůstanou

Poznámky k vydání mají vlastní oddíl na dvě chyby, které vznikly jako vedlejší účinek oprav a se kterými se podle projektu musí uživatelé srovnat. První se týká su(1): pouštět ho jako root je kvůli volání ioctl zvanému TIOCSTI nebezpečné, a když to volání nejde zakázat, su nově skončí chybou. Uživatel, který na to narazil, dostal místo přihlášení hlášku o tom, že shell neumí nastavit procesovou skupinu terminálu, a jeho hlášení z 30. července je pořád otevřené.

Druhá se týká usermod(8): když se mu nepodaří odemknout heslo, protože žádné neexistuje, neudělá teď nic. Dřív to byla jen výstraha a příkaz proběhl. Z balíku navíc vypadla nepoužívaná závislost na knihovně libattr.

Kdy to dorazí k uživatelům

Rychlé distribuce jsou u toho hned. Arch Linux má balík shadow ve verzi 4.20.0 v repozitáři core od 31. července 2026. Debian je jinde: podle jeho vlastního přehledu zdrojových balíků mají 8. srpna 2026 vývojové větve sid i forky verzi 4.19.3, stabilní trixie 4.17.4 a bookworm dokonce 4.13.

Kdo tedy o odstraněné přepínače zakopne, pozná to nejdřív na domácím nebo vývojářském stroji. Návrh na odstranění zbytku stárnutí hesel prosí distribuce, ať trojici PASS_MIN_DAYS, PASS_MAX_DAYS a PASS_WARN_AGE vyházejí ze svých souborů login.defs co nejdřív: až vyjde 4.21, programy s takovou konfigurací skončí chybou.

Pro správce z toho plyne konkrétní úklid. Projít skripty a konfigurační management, jestli někde nevolají chage -m, passwd -n, expiry, groupmems nebo logoutd, a podívat se do login.defs na PASS_MIN_DAYS. Chybová hláška místo tichého ignorování je v tomhle případě dobrá zpráva, protože se ta místa ozvou sama.

Zdroje

• shadow-4.20.0 (Ibores), poznámky k vydání projektu shadow, 29. července 2026
• Remove password aging, otevřený návrh v repozitáři shadow-maint/shadow
• Remove support for shadow(5)'s sp_min, návrh začleněný 11. července 2026
• Deprecate and remove the groupmems utility, hlášení z 25. srpna 2025
• NIST SP 800-63B, Digital Identity Guidelines, čtvrtá revize
• shadow 4.20.0.arch1-1, repozitář core Arch Linuxu
• shadow, přehled verzí zdrojového balíku v Debianu

Kdo od 27. července nastartoval dostatečně vybavené BMW, našel na prostřední obrazovce proužek s upoutávkou na film Spider-Man: Brand New Day. Sám se nespustí. Je to banner, na který se musí klepnout, a teprve pak se přes celý displej rozjede animace s hudbou; u vozů s ambientním osvětlením k ní přibude i světelná show. Kdo ji při startu přeskočí, najde ji potom v nabídce jako další aplikaci.

Kterých vozů se to týká

Rozsah kampaně popsala automobilka sama v tiskové zprávě z 28. července. Animace běží od premiéry filmu 27. července do 10. srpna a je dostupná ve víc než 70 zemích. Dostanou ji vozy s příslušnou výbavou, s datem výroby po červenci 2020 a se systémem BMW Operating System 7, 8, 8.5, 9 nebo BMW Operating System X.

Ten výčet je pro čtenáře podstatnější než film. Nejstarší auta v té skupině opustila továrnu před šesti lety a animaci mají, aniž by o ni jejich majitelé žádali; po 10. srpnu zase zmizí.

Automobilka odmítá, že jde o reklamu

Serveru The Autopian firma potvrdila, že bannery jsou skutečné, a označila je za část širší spolupráce se studiem. „Animace ve voze je součástí mnohem širší značkové spolupráce, jejíž součástí bylo umístění produktu ve filmu a zvláštní edice vozu na červeném koberci losangeleské premiéry. Mělo to být jen zábavné zpestření, které slaví, že se naše vozy v novém filmu objevují,“ stojí ve vyjádření (přeloženo). Firma k tomu dodala, že zavádět do vozů reklamu neplánuje a chce, aby měl zákazník nad děním ve voze kontrolu. Celé vyjádření přetiskl server electrive.

Ten k tomu poznamenává, že v Německu bývá taková propagace u soudů posuzovaná jako reklama, konkrétní rozhodnutí ale neuvádí. Ověřit se to z jeho textu nedá.

V roce 2023 mluvila firma o soukromém prostoru

Kritiku živí starší postoj samotného BMW. V prosinci 2023 řekl Stephan Durach, viceprezident BMW Group pro rozvoj propojených služeb, při diskusi s novináři, že prodej obrazovky na reklamní spot si nedovede představit, protože kabina je soukromý prostor, kde si člověk dělá, co chce. Výrok tehdy zaznamenal server MediaPost a přetiskl ho BMWBLOG.

Mezitím firma zkusila prodávat předplatné na vyhřívání sedadel, která už v autě byla, a po vlně nevole to zrušila. Server Carscoops i diskuse na Redditu spojují obě věci do jedné otázky: co všechno smí výrobce s vozem dělat potom, co ho prodal. Jeden z komentujících napsal, že auta budou brzy potřebovat blokátor reklam.

Co si BMW od spolupráce slibuje

Vedle animace stojí obvyklejší část dohody. Ve filmu, který šel podle tiskové zprávy do kin 31. července, jezdí elektrický BMW iX3 a sedan řady 5, a automobilka je nemá jen v záběru: píše, že jsou zapletené do děje. K tomu vznikl krátký film The Big Screen, natočený v Londýně s kaskadérem Lukem Scottem. Kampaň připravila agentura Jung von Matt Hamburg, na globální části se podílela agentura UEG.

Bernd Körber, viceprezident BMW pro značku a produkt, spojuje v tiskové zprávě start modelové řady Neue Klasse s novou kapitolou Spider-Mana; iX3 je jejím prvním sériovým modelem. Umístění vozu ve filmu je tedy pro firmu především uvedením nové řady.

Kanál pro takový obsah v autech dávno je

Na kampani je technicky nová jenom náplň, ne cesta. Tisková zpráva mluví o „svátečních animacích“ v množném čísle a stejným způsobem posílá BMW do vozů vánoční a novoroční přání; letos se tím slotem propaguje film. Rozdíl mezi pozdravem a upoutávkou je tedy věcí rozhodnutí automobilky, ne technického omezení.

Vedle animace vznikl i jeden kus vozu: BMW iX3 Flow – Spider-Man Brand New Day má vnějšek pokrytý panely E Ink Prism, které umí měnit barvu, a do konce září stojí v mnichovském BMW Welt. Tahle část spolupráce se od reklamy ve vlastním autě liší v jedné věci: dívá se na ni jen ten, kdo za ní přijde.

Zdroje: BMW PressClub, electrive, Carscoops, The Verge, BMWBLOG.

Kdo si pronajme virtuální stroj u poskytovatele cloudu, spoléhá na to, že se ze svého stroje k sousedům nedostane. Chyba Zapscape, zveřejněná 6. srpna 2026, tenhle předpoklad na linuxových hostitelích rušila. Útočníkovi stačilo mít roota ve vlastním virtuálu a mohl spustit kód s právy roota na hostiteli, tedy i nad všemi ostatními virtuály na témže železe. Případně jen shodit jádro hostitele a odstavit je všechny naráz.

Chybu našel a nahlásil korejský výzkumník Hyunwoo Kim, vede se pod číslem CVE-2026-64561. Postižené je KVM, tedy virtualizační vrstva zabudovaná přímo do linuxového jádra, a to na procesorech x86.

Chyba je ve stínových tabulkách stránek, ne v QEMU

KVM překládá adresy hosta na fyzické adresy hostitele hardwarem: na Intelu se tomu říká EPT, na AMD NPT. Jakmile ale host sám spustí další virtuální stroj, jedna hardwarová vrstva na dva překlady za sebou nestačí. Jádro proto tabulky vnořeného hosta vede softwarově, ve stínových stránkách (shadow MMU).

Těch stránek nesmí přibývat donekonečna, takže je KVM při překročení kvóty rekurzivně uklízí. A právě tam chyba je. Úklid dokáže zneplatnit kořenovou stránku, která se pořád používá; KVM pak výpadek stránky dokončí nad kořenem, který už neplatí. Do seznamu aktivních stránek se tím dostane neplatný potomek, tentýž ukazatel skončí ve dvou seznamech naráz a po uvolnění paměti následuje zápis do ní. Tedy use-after-free.

Kim v technickém popisu zdůrazňuje, že chyba je v jádře, ne v QEMU. Emulace se na ni nemá jak dostat, takže se netýká jen běžné dvojice QEMU a KVM, ale i velkých poskytovatelů, kteří si virtualizační vrstvu nad KVM postavili sami.

Na Intelu má útok podmínku, kterou předchozí chyba neměla

Zapscape není v pořadí první. Kim ho sám řadí jako třetí díl trojice po chybách ITScape (CVE-2026-46316) a Januscape (CVE-2026-53359). Ve stínovém MMU je z nich vedle Zapscapu jen Januscape, a i ten má podle Kima jinou příčinu; ITScape vede záznam CVE v kódu KVM pro arm64.

Rozsah se u nich liší. Januscape šlo podle Kima na Intelu spustit, kdykoli byla zapnutá vnořená virtualizace. U Zapscapu musí být hostu vystavena délka průchodu EPT 4 i 5 zároveň; na AMD žádná taková podmínka není. Veřejná ukázka proto cílí na AMD a běží nad jádrem 7.1.3.

Na RHEL nepotřebuje útočník ani virtuální stroj

Druhá cesta k rootovi se obejde bez virtualizace. Na distribucích jako RHEL je zařízení /dev/kvm zapisovatelné pro všechny (práva 0666), takže chybu může jako lokální eskalaci oprávnění použít i obyčejný neprivilegovaný uživatel. Kim k tomu píše, že v téhle podobě je útok dokonce snazší a stabilnější, protože má k dispozici i ioctl volání ze strany hostitele.

Uvnitř virtuálu naopak útočník musí mít práva jádra, tedy roota. Na pronajaté instanci to obvykle není překážka, protože správce vlastního stroje bývá právě zákazník.

Oprava byla v hlavní řadě jádra dva a půl týdne před popisem

Časová osa je v Kimově dokumentu vypsaná do dne. Hlášení šlo 11. července na adresu security@kernel.org, 13. července napsal opravu Sean Christopherson a 21. července ji Paolo Bonzini poslal do konference jádra a zařadil do hlavní řady. K distribucím zamířila informace 1. srpna s pětidenním embargem, 4. srpna přibylo číslo CVE a 6. srpna vyšel text na konferenci oss-security.

Samotná oprava je krátká. Kontrola na zastaralý kořen se přesunula až za volání make_mmu_pages_available(); když úklid kvóty právě používaný kořen zneplatní, výpadek stránky se místo dokončení zopakuje. Do stabilních řad se dostala ve verzích 6.6.148, 6.12.101, 6.18.42 a 7.1.6, v hlavní řadě je od 7.2-rc5.

Záznam CVE k tomu dodává jednu věc, kterou popis útoku nemá. Samotný nedostatek je v kódu už od roku 2008, kdy KVM začalo neplatné kořeny sledovat. Nebezpečným se stal až v roce 2020 s jádrem 5.9, kdy přibylo pravidlo, že neplatné stínové stránky nesmějí být v seznamu aktivních. Zranitelný rozsah proto začíná commitem z 8. července 2020 a končí opravou z 21. července 2026, tedy po šesti letech.

Zveřejněná ukázka není hotová zbraň

Součástí zveřejnění je i ukázkový kód. Kim u něj rovnou píše, že to není útok použitelný v cloudu, ale demonstrace, která chybu reprodukuje nad emulací QEMU TCG. Kdo by ji chtěl nasadit doopravdy, musel by kroky prováděné uvnitř hosta přesunout do jaderného modulu a exploit upravit podle konfigurace jádra hostitele. Že to není nijak těžké, dodává tamtéž. Po úspěšném průchodu ukázka na hostiteli založí soubor /Zapscape, jehož vlastníkem je root.

Na otázku, jestli se v KVM budou takové chyby objevovat dál, odpovídá Kim ve svém textu jediným slovem: ano. Provozovatelům hypervizorů k tomu doporučuje mít na záplatování hostitelů zavedený postup, se kterým se dá počítat dlouhodobě. Čísla CVE té trojice jsou z 9. června, 4. července a 4. srpna 2026, tedy ze dvou měsíců, a dvě z nich míří do téhož kusu kódu.

Zdroje: popis a ukázkový kód Zapscape od Hyunwoo Kima, oznámení v konferenci oss-security, záznam CVE-2026-64561 a zpráva Phoronixu.

Energetický regulační úřad (ERÚ) zveřejnil 4. srpna sdělení, ve kterém upřesnil chystanou změnu tarifů. Aktualizoval koncepční dokument popisující, jak se od 1. ledna 2027 změní placení za užití sítě pro odběratele na vysokém (VN) a velmi vysokém napětí (VVN). Přibyla v něm pasáž o bateriích a přečerpávacích vodních elektrárnách, které se zároveň účastní kapacitního mechanismu.

Úleva se počítá z účinnosti

Nová tarifní struktura počítá s tím, že zařízení pro ukládání elektřiny neplatí za odebraný výkon plnou cenu. Sazba se odvíjí od účinnosti, tedy od poměru mezi elektřinou, kterou úložiště zpětně dodá do soustavy, a tou, kterou z ní odebere. Koncepční dokument uvádí předběžné meze pásma: pro úložiště v přenosové soustavě a na hladině VVN 0,6 a 0,7, na hladině VN 0,6 a 0,75, u přečerpávacích vodních elektráren 0,5 a 0,7. Kdo skončí na spodní mezi nebo pod ní, platí plnou cenu za maximální odebraný výkon. Kdo se dostane na horní mez nebo výš, neplatí za něj nic, a mezi oběma hodnotami se platba krátí lineárně.

Právě tohle krácení podle srpnové revize odpadne všude tam, kde se úložiště nebo přečerpávací elektrárna v daném zúčtovacím období účastní kapacitního mechanismu. Účastí se podle dokumentu rozumí účinná smlouva o zajištění potřebné dostupnosti výkonu mezi provozovatelem přenosové soustavy a provozovatelem zařízení. Cenu za rezervovaný příkon hradí úložiště v obou případech stejně; mění se jen ta druhá složka.

ERÚ v témže dokumentu popisuje, proč od dřívější varianty ustoupil. Úleva měla být původně vázaná na poskytnuté služby výkonové rovnováhy v kladném směru, tedy na výpomoc soustavě navýšením dodávky. U té ale podle úřadu není z tržního principu možné zaručit trvalé využití, takže nová podoba míří na účinnost samotného zařízení.

Rezervovaná kapacita končí

Úprava kolem baterií je detail uvnitř mnohem větší změny. Od ledna 2027 zaniká cena za rezervovanou kapacitu i cena za její překročení a nahradí je dvojice plateb: cena za rezervovaný příkon, což je dlouhodobě sjednaná hodnota vázaná k odběrnému místu, a cena za maximální čtvrthodinový výkon odebraný ze soustavy, který se měří. Odběratelé zároveň přestanou provozovatelům sítí hlásit hodnoty rezervované kapacity na další měsíc nebo rok.

Rozdíl mezi sjednanou a skutečně využitou hodnotou je přitom velký. Podle tabulky v koncepci činil v roce 2024 součet rezervovaných příkonů 21 412 MW, součet rezervovaných kapacit 8 234 MW a součet maximálních odebraných výkonů 10 570 MW. ERÚ čeká, že se rezervovaný příkon díky novým cenám sníží o 3 300 MW, tedy zhruba o patnáct procent celkové kapacity soustav. Kolik flexibility bude česká soustava v příštích letech potřebovat, popsalo červencové hodnocení ČEPS.

Kolik se ušetří, na to jsou dvě čísla

V tiskové zprávě z 25. května mluví předseda ERÚ Jan Šefránek o úspoře dvě až tři miliardy korun ročně a titulek zprávy uvádí až tři miliardy. Stránka s koncepcí na témže webu píše o úspoře až 2,5 miliardy korun ročně, což odpovídá dvěma až třem procentům regulovaných plateb. Obě čísla vydal týž úřad a rozdíl nikde nevysvětluje.

Celkový objem vybraných plateb se změnou nemění. V modelovém propočtu na hypotetických cenách roku 2026 vychází suma u ceny za distribuci před změnou i po ní stejně, zhruba 22,4 miliardy korun. Mění se ale rozdělení: zákazníkům platba klesá o 455 milionů korun (3,1 %), výrobcům elektřiny stoupá o 446 milionů (11,9 %) a provozovatelům lokálních distribučních soustav o 10 milionů (0,3 %). Úspora pro odběratele tedy nevzniká uvnitř tabulky, ale až tím, že se podle úřadu nebudou muset stavět zbytečné posily sítí.

Konec několika výjimek

S rezervovanou kapacitou padnou i výjimky, které se na ni navázaly. Na hladině VN skončí zvláštní režim pro odběratele s akumulačním a přímotopným vytápěním a pro zimní stadiony. Dočasně zůstane jen skupina odběrů pro závlahy, předběžně do roku 2028, protože jednorázové zrušení by jim podle dokumentu platbu za distribuci zvedlo velmi výrazně. Ruší se také kategorizace výrobců elektřiny na první a druhou, a s ní i osvobození od výkonové složky.

Změna se týká zhruba 25 tisíc subjektů na vyšších napěťových hladinách. Domácností a malých podnikatelů na nízkém napětí se zatím netýká vůbec: tam ERÚ plánuje pilotní projekty od roku 2028 a širší, stále dobrovolné nasazení od roku 2030.

Co ještě není hotové

Konkrétní parametry zpoplatnění úložišť a přečerpávacích elektráren mají projít veřejným konzultačním procesem v říjnu 2026, kdy ERÚ zveřejní i návrh cenového výměru pro rok 2027. Další zpřesnění koncepce úřad avizuje na září. Změna v takzvaném managementu jaloviny, tedy v placení za jalový výkon, se z roku 2027 odsouvá na 2028.

Vedle dokumentu zveřejnil ERÚ i kalkulátor, ve kterém si odběratel na VN a VVN spočítá dopad na vlastní odběrné místo. Pro provozovatele baterií z nových pravidel plyne volba: buď účast v kapacitním mechanismu, nebo nižší platba za odebraný výkon podle účinnosti. Obojí naráz nepůjde.

Zdroje: sdělení ERÚ ze 4. srpna 2026, koncepční dokument Efektivní využívání přenosové soustavy a distribučních soustav na hladinách VVN a VN ve znění revize ze srpna 2026, tisková zpráva ERÚ z 25. května 2026 a shrnutí serveru TZB-info z 5. června 2026.

Organizace IETF vydala v červenci 2026 tři dokumenty naráz: RFC 10002, RFC 10003 a RFC 10004. Popisují protokol CMC a ruší platnost RFC 5272, RFC 5273 a RFC 5274 z června 2008 i jejich společného doplňku RFC 6402 z listopadu 2011. Všechny tři jsou v kategorii Standards Track, tedy plnohodnotná norma, ne informativní popis problému.

Čemu CMC slouží

CMC je zkratka za Certificate Management over CMS, tedy správu certifikátů nad syntaxí kryptografických zpráv. Je to protokol, kterým si zařízení vyžádá u certifikační autority certifikát, nechá ho obnovit nebo zneplatnit. Abstrakt RFC 10002 uvádí dvě potřeby, ze kterých protokol vzešel: rozhraní ke službám vydávajícím certifikáty postaveným na CMS a PKCS #10, a zápis klíčů, které umějí jen šifrovat a podepsat samy sebe neumějí.

Rozdělení na tři dokumenty zůstalo stejné jako v roce 2008. RFC 10002 popisuje strukturu zpráv, RFC 10003 způsoby jejich přenosu a RFC 10004 to, co musí implementace umět, aby byla v souladu s normou.

Otisky se posunuly na SHA-256

Nejpodstatnější změnu nese RFC 10004. Jeho vlastní výčet změn proti RFC 5274 a 6402 ji shrnuje třemi odrážkami: SHA-1 nahradil SHA-256, HMAC-SHA-1 nahradil HMAC-SHA-256 a přibyly algoritmy pro AuthEnvelopedData, tedy pro obsah, který je zároveň zašifrovaný a chráněný proti změně.

V podrobnostech to vypadá takhle. Každá strana musí umět ověřit i vytvořit podpis RSA-SHA256, musí podporovat AES jako šifru obsahu a AES-GCM pro obsah šifrovaný s ověřením, a to včetně dvanáctibajtové jednorázové hodnoty i dvanáctibajtového kontrolního součtu. U prvků, kterými žadatel prokazuje totožnost a držení privátního klíče, stojí SHA-256 a HMAC-SHA256 jako povinné.

Kdo provozuje starší implementaci, o spojení nepřijde. RFC 10004 přidalo odstavec o zpětné slučitelnosti: server smí starší algoritmy dál nabízet, ale měl by podle příchozích žádostí zjišťovat, které certifikáty je vhodné převést na bezpečnější.

Přenos vyžaduje aspoň TLS 1.2

RFC 10003 popisuje čtyři cesty, kterými se zprávy CMC dopravují: souborem, elektronickou poštou, přes HTTP a přímo přes TCP. Změny jsou tu drobnější, zato konkrétní. Místo TLS 1.0 se vyžaduje TLS 1.2 nebo novější a implementace se mají řídit doporučeními BCP 195. Při použití TLS 1.3 nebo QUIC je omezené odesílání časných dat (0-RTT), tedy dat poslaných ještě před dokončením ustavení spojení. Omezené je i zřetězení požadavků nad TCP.

Dokument uvádí i registrovaný port: služba se jmenuje pkix-cmc a poslouchá na TCP portu 5318. Novinka roku 2026 to není. Číslo přidělila IANA už kvůli RFC 6402, které ho v roce 2011 popisuje jako registrovaný port; ve výčtu změn RFC 10003 je uvedené proto, že RFC 5273 z roku 2008 ještě žádné přidělené číslo nemělo. Zápis v rejstříku služeb a portů IANA dnes odkazuje na RFC 10003 a nese datum 13. února 2026. Obě RFC ale port zařazují jinam: RFC 6402 mluví o registrovaném rozsahu, RFC 10003 o rozsahu dynamickém a privátním.

Nad tím vším zůstala věta, kterou nové znění přebírá po svém předchůdci: hlavní přepravou pro CMC má i nadále být HTTP.

Klíče, které neumějí podepisovat

Žádost o certifikát musí být podepsaná. Jenže klíč, o jehož certifikát se žádá, podepisovat umět nemusí. Příloha C v RFC 10002 jmenuje Diffieho–Hellmanovu výměnu klíčů, její eliptickou obdobu a mechanismy zapouzdření klíče (KEM) RSA-KEM a ML-KEM. Ten poslední je postkvantový algoritmus, tedy takový, který má odolat i útoku kvantovým počítačem.

Protokol pro ně má náhradní řešení: podpisový algoritmus, který žádný podpis nevytváří (id-alg-noSignature), a k němu dvojici prvků Encrypted POP a Decrypted POP, kterými autorita ověří, že žadatel klíč opravdu drží. Nové vydání k tomu přidalo ukázkovou výměnu zpráv pro certifikát KEM, ve které je odpověď zabalená strukturou KEMRecipientInfo.

Kde SHA-1 v protokolu zůstal

Věta „SHA-1 nahradil SHA-256“ platí pro požadavky na algoritmy, ne pro celý protokol. Starší verze dvou kontrolních prvků mají otisk zadrátovaný: prvek Identity Proof má napevno SHA-1 a HMAC-SHA1, prvek POP Link Witness rovněž. Tabulka souladu v RFC 10004 přitom u POP Link Witness ve staré verzi žádá „MUST“ po registrační i certifikační autoritě, koncovému zařízení ukládá „SHOULD“. Novější POP Link Witness Version 2 se SHA-256 je povinný pro všechny tři role.

Třetí místo je zmíněný podpis, který podpisem není. Hodnota NoSignatureValue obsahuje otisk žádosti spočítaný algoritmem SHA-1 a dokument u ní rovnou píše, že se má ignorovat a že s tímhle typem podpisu není spojená žádná bezpečnost.

Od konceptu k normě to trvalo bezmála dva roky

Obnovu si vzala na starost pracovní skupina LAMPS (Limited Additional Mechanisms for PKIX and SMIME). Podle evidence IETF vyšla nultá revize konceptu draft-ietf-lamps-rfc5272bis 12. září 2024 a poslední, jedenáctá, 26. února 2026. Editory všech tří dokumentů jsou J. Mandel ze společnosti AKAYLA a S. Turner ze sn3rd.

Do nového znění se promítlo i třináct hlášených chyb ve starších dokumentech, které RFC 10002 vypisuje jmenovitě čísly errat.

Pro provoz z toho plyne, že měnit se nemusí nic ze dne na den, protože zpětná slučitelnost zůstala povolená. Kdo ale píše novou implementaci, má od července jednoznačné zadání: SHA-256, AES-GCM a TLS 1.2 nebo novější. A kdo provozuje starou, dostal v RFC 10004 návod, podle čeho přechod načasovat – podle toho, s čím za ním klienti chodí.

Proxmox Virtual Environment spravuje virtuální stroje a linuxové kontejnery a dosud existoval jen pro x86-64. To se 5. srpna změnilo. Vídeňská Proxmox Server Solutions vydala sestavení pro 64bitový Arm, tedy arm64 čili aarch64, a označila ho verzí 9.2 - stejným číslem, jaké nese vydání pro x86-64 z 21. května.

Jedna kódová základna, dvě instrukční sady

Nová varianta není odbočka stranou. Podle oznámení na fóru, které napsal technický ředitel firmy Thomas Lamprecht, sdílí s x86-64 zdrojový kód, balíčkové repozitáře i životní cyklus vydání. Stojí na Debianu 13 „Trixie“, jádru řady 7.0 a týchž verzích klíčových součástí: QEMU 11.0, LXC 7.0 a ZFS 2.4. Úložiště Ceph je ve variantě Tentacle 20.2.3.

V bodovém vydání Debianu se přitom Proxmox sám neshodne. Oznámení na fóru mluví o 13.5, poznámky k vydání na wiki o 13.6. Rozdíl je na provoz bez významu, ale nikde se nevysvětluje.

Nastavení, nástroje i dokumentace jsou podle firmy shodné s x86-64 verzí. „Naším cílem nebylo Proxmox VE na nové architektuře jenom rozběhat, ale dodat plnou paritu funkcí,“ řekl Lamprecht v tiskové zprávě (citace přeložena z angličtiny). Vypočítal v ní KVM, sítě, clustering, ZFS a Ceph.

Plnou podporu mají dvě platformy, obě od Nvidie

Oficiálně podporovaný hardware jsou procesorové platformy Nvidia Grace a Nvidia Vera. Ostatní serverové stroje s UEFI a jádrem ARMv9-A nebo novějším mají podporu „best-effort“, tedy jak se povede; starší ARMv8-A podle Proxmoxu obvykle funguje také, se stejnou výhradou. Hostitel musí startovat přes UEFI a popisovat svůj hardware tabulkami ACPI.

Tím z hry vypadávají jednodeskové počítače, které svůj hardware popisují stromem zařízení (device tree). Raspberry Pi a stroje jemu podobné Proxmox VE nerozběhne a firma to říká rovnou v odpovědích na časté dotazy. Kdo si na levném armovém počítači chtěl postavit domácí virtualizační server, touhle cestou se nedostane.

Čtyři věci, které na Armu chybějí

Rozdílů proti x86-64 je málo a Proxmox je vyjmenoval:

• Virtuální stroje startují vždy přes UEFI, o které se stará armová sestava OVMF zvaná AAVMF. SeaBIOS na arm64 není.
• Šifrování paměti AMD SEV a sdílené virtuální GPU od Intelu (GVT-g) zůstávají vázané na x86.
• Neexistuje balíček s mikrokódem procesoru, tedy obdoba intel-microcode a amd64-microcode.
• Host běží jen na uzlu své vlastní architektury a živá migrace je možná pouze mezi uzly téže architektury.

Míchat x86-64 a arm64 uzly v jednom clusteru technicky nic nebrání, oficiální podporu to ale nemá. Přestěhovat existující virtuální stroj z x86 na Arm znamená přenést jeho data zálohou, offline migrací nebo sdíleným úložištěm a pak ho pro novou architekturu přeinstalovat nebo přenastavit. Samotné zkopírování disku nestačí.

Objednávka přišla z datových center

Port nevznikl ve volném čase. Proxmox uvádí, že šlo o technickou spolupráci s Nvidií a Supermicrem a že jeho inženýři ověřovali platformu přímo na serverech s Grace Hopper Superchip. Software podle tiskové zprávy už běží ve vybraných podnikových produkčních prostředích.

Kde se ta poptávka vzala, ukazuje starší tisková zpráva z 28. července. Proxmox v ní oznámil, že se Proxmox VE stane virtualizační vrstvou pod nástrojem NVIDIA Mission Control, který ve velkých strojovnách pro umělou inteligenci rozvrhuje úlohy a stará se o zotavení po výpadku. Už tehdy stálo v textu, že se platforma upravuje právě pro procesory Grace a Vera.

Server The Register k tomu poznamenal, že technické spolupráce nevznikají samy od sebe a že za portem nejspíš stojí zákazníci Nvidie a Supermicra, kteří chtějí svůj hardware pro umělou inteligenci virtualizovat. Podle nás je to pravděpodobné čtení, ale ani jedna z těch firem to takhle nahlas neřekla.

Předplatné zvlášť, ostatní produkty zatím ne

Podnikový repozitář pve-enterprise pro arm64 existuje a Proxmox ho pro produkci doporučuje stejně jako na x86. Předplatné pro armové uzly je ale oddělené od toho x86 a zatím se prodává jen na vyžádání. Zbylé produkty firmy, tedy třeba Proxmox Backup Server, mají prozatím jen interní zkušební sestavení; pořadí, ve kterém se na ně dostane, si Proxmox nechává určit poptávkou podnikových zákazníků.

Na serverovém Armu přitom Proxmox VE první není. Architekturu umí hypervizory Xen i KVM, ze kterého Proxmox sám vychází, a z komerčních platforem tam podle Registeru už jsou SUSE nebo čínský Sangfor. Otevřený svět se o další instrukční sady rozšiřuje průběžně: první stabilní podporu 64bitového RISC-V nedávno přineslo NetBSD 11.0. Nové je spíš to, kdo přišel: podle vlastních údajů firmy běží Proxmox VE na víc než dvou milionech hostitelů a jeho komunita má přes 225 000 členů. Zároveň platí, že jedinou plně podporovanou branou na Arm je zatím hardware jediného výrobce.

Zdroje

• Proxmox Virtual Environment launches official Arm64 Support, tisková zpráva Proxmox Server Solutions, 5. srpna 2026
• Proxmox Virtual Environment now available for 64-bit ARM (arm64)!, oznámení na fóru Proxmoxu, 5. srpna 2026
• Roadmap, poznámky k vydání Proxmox VE, wiki Proxmoxu
• Proxmox VE delivers high-availability infrastructure management for NVIDIA Mission Control AI factories, tisková zpráva Proxmox Server Solutions, 28. července 2026
• Proxmox ports itself to Arm with help from Nvidia and Supermicro, The Register, 6. srpna 2026

Cloudflare 5. srpna 2026 zveřejnil zdrojový kód platformy Cloudflare OS pod licencí Apache 2.0. Je to prostředí, ve kterém si zaměstnanci firmy nechávají od agenta psát dokumenty a prezentace a stavět malé aplikace nad firemními daty. Kód je ve dvou repozitářích na GitHubu, v jádru a ve vzorovém nasazení.

Název svádí k nedorozumění a projekt to ví. Hned v úvodu popisu repozitáře stojí, že o klasický operační systém pro počítač nejde. Slovo je myšlené jinak: jako systém, ve kterém firma pracuje s umělou inteligencí, a jako správce agentních úloh, obdobně jako běžný systém spravuje ty výpočetní.

Agent začíná bez jediného oprávnění

Uvnitř platformy nemá žádný agent ani žádná aplikace přístup k ničemu. O konkrétní zdroj si agent řekne a člověk mu ho povolí, nebo odmítne. Vygenerovaný kód pak dostane typovanou vazbu; v ukázce z oznámení je to env.PROJECT, tedy oprávnění použít jeden konkrétní zdroj podle jednoho konkrétního pravidla:

const issues = await env.PROJECT.listIssues({
  teamId: "ENG",
  state: "open",
});

Přihlašovací údaj ke službě zůstává mimo agenta i mimo vygenerovaný kód. Serverová část běží v Dynamic Workeru s vypnutou odchozí sítí, klientská v odděleném rámu v prohlížeči. Ven se ani jedna nedostane jinak než přes předané oprávnění.

Mezi platformou a cizí službou stojí Gatekeeper, tedy Worker napsaný pro tu jednu službu. Vyřídí přihlášení přes OAuth, podrží přihlašovací údaj, vynutí pravidlo a zapíše, co se četlo. Místo celého účtu na GitHubu tak agent dostane jediné úložiště, může číst hlášení a nesahat na zdrojový kód, některá pole vidí zamaskovaná a sloučení pull requestu musí schválit člověk.

Schvalování přitom nemusí zastavit práci. Když agent udělá krok, který potřebuje souhlas, Gatekeeper výsledek nasimuluje, agentovi ohlásí hotovo a nechá ho pokračovat; člověk pak dávku schválí nebo zamítne, až se k tomu dostane. Obvykle se na souhlas čeká okamžitě, a proto si lidé z netrpělivosti zapnou automatické schvalování všeho.

Seznam přečteného putuje s výsledkem

Model Context Protocol, tedy rozhraní, kterým agent volá nástroje cizí služby, řekne, které nástroje agent volat smí. Neřekne ale, které řádky, soubory nebo repozitáře opravdu přečetl. Agent tak může spojit data ze dvou systémů, výsledek předat člověku s užšími právy a nezanechat po tom stopu.

Cloudflare na to podle oznámení narazil sám, jakmile si lidé začali sdílet pracovní prostory a výstupy. Platforma proto vede záznam o každém zdroji, který agent viděl, a ten záznam zůstává přilepený na agentovi i na všem, co vyrobil. Když si výsledek otevře druhý člověk, Gatekeepery nejdřív ověří jeho přístup k těm zdrojům.

Příklad z oznámení: agent přečte citlivou tabulku v datovém skladu a udělá z ní živý přehled. Sdílení toho přehledu nesmí být cesta, jak tabulku ukázat někomu, kdo na ni nemá. „Oprávnění musí počítat s tím, kam data můžou putovat dál,“ píšou v oznámení Phillip Jones a Dan Carter (překlad redakce).

Týž záznam řídí i odchozí požadavky. Poté, co agent přečte citlivá data, mu platforma může zakázat zápis do vybraných míst, přizvání dalších lidí, předání práce jinému agentovi i požadavek ven.

Každý soubor může být vlastní aplikace

Místo pevné sady typů souborů, tedy dokumentu, tabulky a prezentace, je v Cloudflare OS každý soubor potenciálně vlastní aplikace. Projekt jim říká gadgety. Taková aplikace má klientský kód pro rozhraní, serverový kód pro stav a chování, vlastní API a trvalá data. Server se načte na vyžádání jako Dynamic Worker a vznikne jako facet Durable Objectu; facet mu dá vlastní databázi SQLite. Dynamic Workers stojí na lehkých izolátech V8, takže každá aplikace má vlastní běhové prostředí, aniž by kvůli ní musel stát vyhrazený server nebo kontejner.

Prohlížeč mluví se serverem přes Cap'n Web, otevřený systém vzdáleného volání procedur od Cloudflare. Klient volá serverovou metodu jako obyčejnou funkci a tutéž metodu může zavolat i agent. Kdo si postaví nástroj pro svou práci, dá ho tím k dispozici i agentovi, který tu práci udělá v jeho nepřítomnosti.

Sdílet jde dvojím způsobem. Sdílená aplikace znamená spolupráci nad týmž stavem; sdílený blueprint je kopie kódu bez dat v SQLite, bez historie rozhovoru, bez přihlašovacích údajů a bez připojených zdrojů. Popis repozitáře z toho vyvozuje, že centralizovaný model softwaru jako služby ztrácí smysl ve chvíli, kdy si chybějící funkci umí doplnit každý uživatel sám.

Proč tomu Cloudflare říká operační systém

Popis repozitáře tvrdí, že označení není jen marketing, a nabízí k tomu tabulku obdob:

• jádru odpovídá balíček workshop-backend,
• ovladačům zařízení Gatekeepery,
• shellu rozhraní v balíčku workshop-frontend,
• procesům gadgety a spustitelným souborům blueprinty,
• seznamům přístupových práv sdílená oprávnění.

Agenti jsou v té tabulce jediná položka, ke které běžný systém protějšek nemá. Argument projektu zní, že agent se nedá brát jako další uživatel: má se zodpovídat konkrétnímu člověku a přitom mít vlastní, užší oprávnění. Proto podle autorů dává smysl přístup přes předávaná oprávnění, ne přes seznamy přístupových práv.

Kde to běží a v jakém je to stavu

Platforma stojí na Cloudflare Workers a hodně používá Durable Objects, Dynamic Workers a Facets. Poslední dvě jmenované podle popisu repozitáře vznikly v běhovém prostředí Workers právě kvůli tomuhle projektu. Vazba jen na Cloudflare to ale podle projektu není: workerd, běhové prostředí Workers, je samo otevřené a celá platforma na něm může běžet na vlastních serverech. Nástroje a dokumentace k takovému nasazení se ovšem teprve dělají, takže kdo do toho chce jít teď, musí si nízkoúrovňové nastavení workerd projít sám.

Model si volí provozovatel a každé volání jde přes Cloudflare AI Gateway. Tam se určuje, které modely jsou k dispozici a který z nich má vzít kterou práci, nastavují se rozpočty a omezení tempa a každý požadavek se připíše člověku, týmu nebo pracovnímu prostoru.

Srpnové vydání označuje sám projekt za rané. Je to druhá verze, kompletní přepis té první, a popis repozitáře u ní mluví o řadě hrubých hran (překlad redakce). Řízená verze, kterou by šlo zapnout přímo z ovládacího panelu Cloudflare, kontejnery pro vývojářské postupy a pracovní prostory uvnitř Slacku teprve mají přijít. Zavádění na míru, i s napojením na vnitřní systémy, mají podle oznámení dělat partneři Presidio a Happy Cog. Jádro je psané v TypeScriptu a k 6. srpnu 2026 mělo podle rozhraní GitHubu 3 847 hvězd a 264 odvozených kopií.

Přenositelná je hlavně ta evidence

Otevřený kód znamená, že postup není vázaný na Workers ani na Cloudflare. Zprostředkovatel, který drží přihlašovací údaj a pouští agenta k jedinému zdroji, i záznam o přečteném, který se veze s výsledkem, jdou popsat a napsat kdekoli. Jestli se to jinam přenese, ukáže až to, jestli podobnou evidenci začnou vést i ostatní agentní platformy. Samotné MCP na to pole nemá, jak Cloudflare v oznámení píše: řekne, co agent volat smí, ne co už viděl.

Zdroje: oznámení na blogu Cloudflare, repozitář cloudflare/cloudflare-os s popisem a licencí, zpráva Phoronixu a rozbor Help Net Security.

Americký úřad pro bezpečnost silničního provozu NHTSA zveřejnil 4. srpna 2026 ve věstníku Federal Register návrh pravidla, který by povinnost splnit nové požadavky na kotevní úchyty dětských sedaček posunul o rok. Není to nový předpis, ale odpověď na žádosti o přezkum toho, který úřad vydal 7. ledna 2025. Připomínky k němu sbírá do 3. září 2026.

Co změnilo pravidlo z ledna 2025

Předpis FMVSS č. 225 popisuje kotevní úchyty dětských zádržných systémů, tedy to, co musí mít samotný vůz. Loňská úprava vznikla na příkaz zákona MAP-21, jehož oddíl 31502 uložil ministerstvu dopravy usnadnit používání spodních úchytů a horního popruhu ve všech zadních sedadlech.

Úřad kvůli tomu zavedl dvě měřitelná čísla. Volný úhel kolem každého spodního úchytu, tedy prostor na manipulaci se sponou, musí být nejméně 54 stupňů. Hloubka uložení úchytu ve spáře mezi sedákem a opěradlem smí být pod 25 mm. Omezení síly potřebné k zacvaknutí spony, které úřad původně navrhoval, do výsledného pravidla nakonec nedal.

Kotva horního popruhu se nesmí schovávat pod sedadlem ani pod jinými díly než pod označeným krytem a má mít podobu tuhé tyče libovolného průřezu. Ohebné provedení, které slouží i jako vodítko popruhu, zůstává povolené jen v autobusech, lehkých nákladních vozech a kabrioletech. Značení úchytů pravidlo sjednotilo.

Celé téhle výbavě se v USA říká LATCH, zkratka pro Lower Anchors and Tethers for Children. Institut IIHS, který ji hodnotí vůz od vozu, sleduje u spodních úchytů přístupnost, volný úhel a sílu nutnou k zacvaknutí.

Kdo o odklad požádal

Žádosti o přezkum podala dvě místa: sdružení výrobců Alliance for Automotive Innovation a americká vývojová odnož Mercedesu, Mercedes-Benz Research & Development North America.

Mercedes chtěl místo tříletého náběhu čtyřletý. V přeloženém znění jeho žádosti stojí, že čtyřletý plán „by zmírnil zátěž výrobců při přepracování skeletu karoserie a struktury sedadla u vozů uprostřed životního cyklu“. Skelet je svařená plechová kostra vozu před lakováním a montáží.

Úřad si předběžně vyhodnotil, že několik modelů by kvůli novým požadavkům muselo projít změnou nosné struktury mimo obvyklý cyklus obměny, včetně nové výplně sedadla a přestavby lisovacích nástrojů. Navrhuje proto tento rozvrh: 20 % vozů vyrobených od 1. září 2028 do 31. srpna 2029, 50 % v dalším roce, 75 % v roce následujícím a 100 % od 1. září 2031. Původní plán měl tři stupně a končil o rok dřív.

Alliance žádala něco jiného: aby se malým výrobcům, tedy těm, kdo v USA prodají méně než 5 000 vozů ročně, náběh zrušil úplně a platila pro ně jediná lhůta. Úřad tomu chce vyhovět s tím, že malý výrobce bude muset splnit vše najednou od 1. září 2031. Poznámka pod čarou v návrhu ale dodává, že pokud se prodloužení náběhu ze tří let na čtyři nakonec nepřijme, zůstane malým výrobcům datum 1. září 2030. Úlevu tedy nedostanou samostatně, ale jen spolu s ní.

Kabriolety mají výjimku od roku 1999

Kabriolety nemusejí mít kotvu horního popruhu vzadu od chvíle, kdy předpis v roce 1999 vznikl. Výjimka je v něm proto, že v připomínkách k návrhu z roku 1997 na to upozornily General Motors a Mitsubishi: sklápěcí střecha, prostor pro její uložení za opěradly a menší místo vzadu montáž kotvy komplikují. Úřad tehdy uznal, že neumí oddělit vozy, kde to jde, od těch, kde ne.

Když se k věci vracel v návrhu z roku 2015, spočítal si vozový park ročníku 2013. Z 35 tehdejších kabrioletů jich mělo spodní úchyty i kotvu popruhu na dvou zadních místech deset, jen spodní úchyty čtrnáct a jedenáct nemělo ani jedno. Pravidlo z ledna 2025 z toho vyvodilo, že výjimka skončí a kabriolety vyrobené po 1. září 2031 už kotvu mít budou muset.

Alliance žádá posunout ten konec o dva roky, na 1. září 2033, s odůvodněním, že kabriolet se navrhuje až po kupé a jeho vývojový cyklus je delší. Úřad chce vyhovět a zároveň o stejnou dobu prodloužit i příbuznou výjimku pro spodní úchyty tam, kde jim v předepsané poloze překáží převodovka nebo díly zavěšení.

Popruh přes stavitelnou opěrku hlavy úřad nepovolí

Pravidlo z ledna 2025 zavedlo u sedadel se stavitelnou nebo odnímatelnou opěrkou hlavy zónu, kam kotva popruhu nesmí. Vymezuje ji koule o poloměru 325 mm se středem v referenčním bodu ramene a vodorovný řez 230 mm pod jejím středem. Smysl je prostý: mezi kotvou a úchytem na sedačce musí zbýt tolik popruhu, aby ho šlo dotáhnout. Sedadla s pevnou opěrkou z toho vypadla, protože přes ni popruh vede a delší dráha problém řeší sama.

Mercedes žádal, aby se vedení popruhu přes stavitelnou nebo odnímatelnou opěrku uznávalo také, když je obtočená dráha od referenčního bodu ke kotvě aspoň 325 mm a postup je popsaný v návodu k vozu. Jinak by podle něj musel kostru karoserie i sedadlo přestavět a kotvu posunout o 75 mm dozadu, tedy do místa, které je dnes vyztužené. Žádost 25. července 2025 společným dopisem podpořily americké pobočky Volkswagenu a Porsche; navíc chtěly řez koule posunout ze 230 na 155 mm pod střed, což by podle nich povolilo kotvy tam, kde je dnešní SUV mají.

Úřad tuhle část předběžně zamítá a opírá se o vlastní zadaný výzkum. Práce Ústavu dopravního výzkumu Michiganské univerzity z roku 2017 (číslo zprávy DOT HS 812 467) podle něj neukázala žádný způsob vedení popruhu, který by vycházel nejlépe co do vysunutí hlavy. Nejmenší vysunutí měly případy s nejkratším kusem popruhu mezi kotvou a sedačkou, pokud šlo popruh pořádně dotáhnout. Jiná studie téhož pracoviště pro NHTSA zase zjistila, že popruh vedený přes opěrku může při šikmém a bočním nárazu sklouznout stranou a vysunutí hlavy tím naopak vzroste. Zamítnutá je i druhá žádost Mercedesu, aby se rozšířila povolená svislá vzdálenost pro umístění značek u spodních úchytů.

Náklady se neruší, jen posouvají

Podle úřadu změna dat žádné nové náklady nepřináší, jen odsouvá ty stávající. Celkovou cenu nových značek a pokynů v návodech odhadl loni na 1,73 milionu dolarů.

Přínos pravidla z ledna 2025 úřad nikdy nevyčíslil. Uvedl jen, že kdyby nová úprava zvýšila podíl správně namontovaných sedaček o 5 % a podíl použitých horních popruhů také o 5 %, zachránila by ročně asi tři životy a zabránila šesti zraněním střední a vyšší závažnosti. V novém dokumentu proto sám píše, že přínos, který by se odkladem posunul, je spekulativní. Návrh je zároveň veden jako deregulační krok podle prezidentského nařízení 14192 a jako nevýznamný podle nařízení 12866, takže ho rozpočtový úřad Bílého domu vůbec neposuzoval.

Dřívější splnění zůstává povolené, takže výrobce, který nové úchyty stihne, čekat nemusí. Nic z toho zatím není rozhodnuté: úřad u všech bodů používá podmíněné formulace a výslovně žádá o připomínky ke všem částem návrhu. Předpisy FMVSS přitom platí pro vozy uváděné na americký trh, takže se evropských zákazníků netýkají přímo; o odklad si řekly americké odnože německých automobilek.

Zdroje: návrh NHTSA z 4. srpna 2026 (spis NHTSA-2025-0051), finální pravidlo ze 7. ledna 2025, návrh z roku 2015 a popis hodnocení LATCH od IIHS.

Jack Huey za skupinu, která na Poloniu pracuje, oznámil 4. srpna, že se do nočních sestavení Rustu zapíná nová podoba borrow checkeru. Příspěvek o tom píše v přítomném čase, samotná úprava se ale do repozitáře dostala až o den později, 5. srpna ve 21:37 světového času. První nightly, které ji nese, je tedy až to ze 6. srpna: jeho manifest uvádí verzi 1.99.0-nightly (7608eb7b0 2026-08-05) a 7608eb7b0 je právě commit, kterým se ta změna slučovala.

Kontrola, která sleduje tok programu

Borrow checker je část překladače, která hlídá půjčené odkazy – že odkaz nepřežije data, na která ukazuje, a že vedle měnitelného odkazu neexistuje druhý. Dnešní stabilní podoba se jmenuje NLL a v Rustu je od roku 2019, kdy nahradila úplně první a hodně omezenou implementaci; její přechodový režim, který zůstal jen kvůli hezčím chybovým hláškám, zmizel v roce 2022.

Polonius Alpha přidává jedinou schopnost, zato podstatnou: vztahy mezi životnostmi posuzuje podle toho, kudy program teče. NLL je v tomhle slepé a dívá se na funkci jako na celek. Nejmenší příklad, na kterém je rozdíl vidět, uvádí oznámení takhle:

fn reborrow(a: &mut u8) -> &mut u8 {
    let b = &mut *a;
    if true { b } else { a }
}

Praktičtější případ je funkce, která z HashMap vrátí měnitelný odkaz na hodnotu a chybějící klíč nejdřív doplní. NLL usoudí, že půjčka vzniklá voláním map.get_mut žije po celou funkci, protože tak vypadá návratový typ – a tvrdí to i o větvi, kde se žádná hodnota nenašla a kde se do mapy vzápětí zapisuje. Právě proto ten zápis odmítne. Polonius Alpha pozná, že v téhle větvi už půjčka živá není, a kód přeloží.

Se starým Poloniem se nepřekrývá úplně

Jméno Polonius nesl už rozbor, který se od prací na NLL odštěpil v roce 2018. Ten prošel celou testovací sadou NLL a přijímal i kód, který NLL nepřijme, jenže byl pomalý – u některých programů natolik, že s ním podle oznámení nešlo počítat. Roky pokusů o rychlejší implementaci téhož zadání k ničemu nevedly. Až v roce 2023 vznikla jiná formulace, která staví na stávající infrastruktuře NLL a vyžaduje jen malou přestavbu; stabilizovat se měla původně už v roce 2024.

Slovo Alpha v názvu má svůj důvod. Některé programy, které starý Polonius přeložil, nová podoba odmítne; oznámení ukazuje cyklus while let, který si uvnitř přepůjčuje odkaz do dalšího prvku spojového seznamu. Platí to i obráceně, takže ani jedno není podmnožinou druhého.

Za přijatý kód se platí časem překladu

Polonius Alpha dělá vždy stejně práce jako NLL, nebo víc; méně nikdy. Návrh změny, který compiler team přijal 25. července, uvádí v měřicí sadě překladače průměrné zpomalení kolem 2 %. Z deseti tisíc nejstahovanějších crate jich 91 překročilo práh 2 % při celé kompilaci i se závislostmi a z pěti tisíc nejstahovanějších jich 61 překročilo práh 1 %, když se měřil jen samotný crate bez závislostí.

Ta dvě čísla se v oznámení na blogu slévají do jednoho: ukazuje jediný graf, mluví u něj o deseti tisících crate i o prahu 1 % a měřený čas u něj popisuje jako čas samotného crate bez závislostí. Návrh takovou dvojici nemá – vzorek pěti tisíc a vzorek deseti tisíc jsou v něm dvě různá měření s různým prahem.

Nejhorší zpomalení uvnitř první desetitisícovky je podle návrhu kolem 20 %. Mimo ni se tým díval hlavně na projekty s velkým počtem půjček a našel i horší případy: sestavovací skript jednoho z nich se překládá dvakrát až třikrát déle. Autoři to považují za přijatelné i v případě, že se to opravit nepodaří, protože jde o vzácné a povětšinou malé zpomalení; část příčin už prošla tříděním a na zmírnění se pracuje. Pro představu, o jaká čísla u rychlosti překladu jde: za předchozích osm měsíců rustc zrychlil o 5,6 %. Obě čísla ale pocházejí z jiných měření, takže se od sebe odečítat nedají.

Zapíná se při stavbě překladače, ne za běhu

Přepínač -Zpolonius v rustc existuje léta. Nové je to, čím se přepnula jeho výchozí hodnota: sestavovací skript nastaví proměnnou CFG_DEFAULT_POLONIUS_NEXT jen tehdy, když se překladač staví v kanálu nightly nebo dev. Beta ani stabilní vydání ji nedostanou a výchozí hodnota tam zůstává vypnutá.

Kdo o novou kontrolu na nightly nestojí, předá překladači -Zpolonius=off, ať už přímo, přes proměnnou RUSTFLAGS, nebo v souboru .cargo/config.toml. Pozor na jednu past: -Zpolonius bez hodnoty znamená legacy, tedy tu starou pomalou implementaci z roku 2018, ne novou. Přijímané hodnoty jsou legacy, off a next, jak stojí ve zdrojovém kódu rustc.

Kdy to bude ve stabilním Rustu

Projekt chce Polonius Alpha nechat na nightly zapnutý až do stabilizace a počítá s ní ještě letos. Do té doby sbírá hlášení o výkonnostních propadech, o nesprávně přijatém kódu a o podivných chybových hláškách; u posledního bodu oznámení dodává, že žádnou změnu proti NLL zatím nezaznamenali. Kdyby se něco vážného ukázalo, na nightly se kontrola zase vypne.

Po stabilizaci má vývoj Polonia utichnout. Optimalizovat a dolaďovat výkon se ještě chvíli bude, ale na další schopnosti – tedy na programy, které nepřeloží ani Alpha, ani NLL – se podle oznámení zatím nikdo nechystá. Projekt to zdůvodňuje tím, že Alpha řeší většinu případů, na které lidé v praxi narážejí, a že jsou přednější jiné věci.

Zdroje: oznámení na blogu Rustu, návrh změny v repozitáři compiler teamu, sloučená úprava rust-lang/rust a manifest kanálu nightly ze 6. srpna 2026.

Voyager 2 letí vesmírem od roku 1977 a jeho zásoba elektřiny se rok co rok ztenčuje. Před koncem roku 2026 měl přijít o jeden ze tří vědeckých přístrojů, které mu ještě zbývaly. Inženýři z Jet Propulsion Laboratory (JPL) tomu předešli zásahem, kterému sami říkají „Big Bang“ – naráz vyměnili skupinu napájených zařízení za úspornější. NASA oznámila 4. srpna, že se to povedlo a že ušetřený příkon udrží všechny tři přístroje v chodu aspoň o rok déle.

Tři zařízení naráz místo jednoho po druhém

Sondu je potřeba držet v teple. Nejde o pohodlí elektroniky, ale o palivové potrubí manévrovacích trysek: kdyby zmrzlo, sonda se přestane natáčet anténou k Zemi. Teplo dodávají ohřívače a odpadní teplo přístrojů, jenže obojí stojí příkon, který sondě chybí jinde.

Co přesně tým vyměnil, popsal mluvčí NASA serveru The Register: šlo o dva ohřívače a o jedno zařízení, které zůstávalo zapnuté jen proto, že jeho odpadní teplo vzniká na správném místě a spotřebuje míň než ohřívač hned vedle. Tuhle trojici nahradila jiná trojice, která zahřeje stejně, ale odebírá méně. Podobné výměny tým dělal i dřív, podle mluvčího ale obvykle jedna za jednu.

Zásah proběhl na dálku, na sondě vzdálené miliardy kilometrů a bez možnosti cokoli vrátit ručně. Přezdívka Big Bang míří právě na to, že se všechno přepnulo v jednom kroku.

Čtyři watty ročně, které nikdo nevrátí

Obě sondy Voyager berou elektřinu z radioizotopových termoelektrických generátorů (RTG). Uvnitř se rozpadá plutonium, teplo z rozpadu se termoelektricky mění na proud – žádné pohyblivé části, žádné palivo k doplnění. Rozpad ale nejde zastavit, takže výkon generátorů klesá: každá sonda přijde zhruba o čtyři watty za rok.

Po bezmála půlstoletí letu je rezerva tenká. Od roku 2024 kvůli ní musela mise vypnout na každé sondě dva vědecké přístroje. Z deseti, se kterými každý Voyager startoval, jich je dnes na Voyageru 2 v chodu jen trojice: detektor kosmického záření, magnetometr a přijímač plazmových vln. Zbytek se odmlčel buď po průletech kolem planet, kde už neměl co měřit, nebo právě kvůli příkonu.

Pořadí vypínání není improvizace. Vědci a inženýři mise se na něm podle NASA dohodli už před lety – dopředu bylo dané, co půjde z provozu jako první a co má zůstat do konce.

Voyager 1 přišel o přístroj letos v dubnu

Že se s příkonem nedá počítat na papíře, ukázala starší sonda. Voyager 1 při běžném plánovaném natočení 27. února nečekaně ztratil napětí. Kdyby kleslo ještě o kus, spustila by se automatika proti podpětí a sonda by si sama vypnula, co uzná za vhodné; návrat z takového stavu je zdlouhavý a sám o sobě riskantní.

Tým proto zasáhl dřív a 17. dubna vypnul přístroj LECP, který téměř bez přestávky měřil nízkoenergetické nabité částice od startu v roce 1977. Jednu jeho část ale nechal běžet: malý motorek, který otáčí čidlem, aby snímalo do všech směrů. Odebírá 0,5 wattu a díky němu zůstává naděje, že se přístroj někdy zapne zpátky. Voyageru 1 tak zbyly dva přístroje, magnetometr a přijímač plazmových vln.

Samotné vypnutí ukazuje, jak se s Voyagery pracuje: Voyager 1 je od Země přes 25 miliard kilometrů, takže povel k ní letí asi 23 hodin a odstavení přístroje pak trvá další tři hodiny a čtvrt.

Na Voyageru 1 přijde Big Bang v nejbližších měsících

Voyager 2 byl pro zkoušku bezpečnější volbou: má o něco větší rezervu v příkonu a je blíž Zemi, takže se na povel čeká kratší dobu. Teď je na řadě Voyager 1 a NASA počítá s tím, že tam tým stejnou výměnu dokončí v nejbližších měsících. Když vyjde, je podle NASA šance, že se dubnový LECP vrátí do provozu.

Rok navíc zní skromně, ale u mise, která byla původně naplánovaná k Jupiteru a Saturnu a dnes letí mimo heliosféru, je to zisk, jaký se jinak koupit nedá. Vyměnit hardware nikdo nepřiletí, přidat palivo taky ne – jediné, co jde, je hospodařit s tím, co plutonium ještě dává.

Zdroje

• NASA Engineers Help Prolong Voyager 2's Science Mission, blog mise Voyager, NASA, 4. srpna 2026
• Voyager 2 cheats the power budget for another year, The Register, 5. srpna 2026
• NASA Shuts Off Instrument on Voyager 1 to Keep Spacecraft Operating, blog mise Voyager, NASA, 17. dubna 2026
• Where are Voyager 1 and Voyager 2 Now?, přehled stavu přístrojů, NASA

Dielektrická konstanta říká, jak ochotně se materiál vnitřně zpolarizuje, když se ocitne v elektrickém poli – a pro elektroniku je to jedno z klíčových čísel, protože na něm stojí kondenzátory i hradla tranzistorů. V učebnicích má každý materiál jednu hodnotu. Jenže čím menší součástky jsou, tím větší část materiálu tvoří povrch a hodnota přestává platit: pár vrstev atomů u povrchu se chová jinak než nitro. Fyzici z tokijské University of Electro-Communications teď vyvinuli způsob, jak rozložení dielektrické konstanty spočítat a zobrazit ve třech rozměrech atom po atomu – a hned první použití přineslo překvapení.

Práci zveřejnil 31. července časopis ACS Omega, univerzita ji oznámila 4. srpna. Tým vedený profesorem Junem Nakamurou metodu vyzkoušel na tenkých vrstvách diamantu a křemíku, jejichž povrch je zakončený vodíkem – atomy vodíku tam uzavírají vazby, které by jinak zůstaly volné.

Křemík podle očekávání, diamant naopak

Výpočty vycházejí z takzvaných prvních principů: berou jen kvantovou mechaniku a polohy atomů, žádné parametry odečtené z měření. U křemíkové vrstvy vyšlo přesně to, co popisují starší studie – dielektrická konstanta u povrchu klesá. Může za to depolarizační pole, které vzniká na rozhraní a vnější pole částečně vyruší. Právě tohle chování komplikuje další zmenšování křemíkových součástek: čím tenčí vrstva, tím menší část si drží vlastnosti, se kterými návrhář počítá.

Diamantová vrstva se zachovala opačně. Dielektrická konstanta u povrchu neklesla, ale vzrostla nad hodnotu, jakou má nitro krystalu. Autoři pro to používají výraz anomální zesílení – mezi běžnými materiály se totiž nic takového nečeká.

Elektrony, které se vznášejí nad povrchem

Příčinu výpočet ukázal také. Vodíkem zakončený povrch diamantu hostí zvláštní elektronový stav, ve kterém se elektrony chovají téměř jako volné – anglicky se mu říká nearly free electron state. Nedrží se u jednotlivých atomů, rozprostírají se do prostoru nad povrchem a podle tiskové zprávy univerzity se chovají, jako by se nad ním vznášely. Právě proto se dají vnějším polem snadno zpolarizovat. U křemíku takový stav na dně vodivostního pásu není, u diamantu ano – a výpočty ukázaly, že tam zůstává bez ohledu na to, jak je vrstva tlustá.

Výsledek zapadá do obecnějšího závěru práce: dielektrickou odezvu u povrchu neřídí materiál jako celek, ale elektronové stavy, které patří jen povrchu samotnému.

Zatím jen na papíře

Celý výsledek stojí na výpočtech, změřený zatím není – experimentální ověření práce neuvádí. Autoři ho nabízejí jako vodítko pro návrh uhlíkové nanoelektroniky: povrch, který polarizuje ochotněji než nitro, by se dal využít tam, kde součástka potřebuje silnou odezvu na malé napětí.

Tisková zpráva jmenuje jako možné využití studené katody – zdroje elektronů, které na rozdíl od žhavených katod ve starých obrazovkách nepotřebují vysokou teplotu ani vysoké napětí. Snadno polarizovatelné elektrony nad povrchem diamantu by z něj šly uvolňovat úsporněji. Na výzkumu se vedle Nakamury podíleli Hayato Kobayashi, Akira Sumiyoshi, Ranferi Cancino Betancourt a Shota Sato z téže univerzity a Sadakazu Wakui z firmy Nichia; financovala ho japonská grantová agentura JSPS.

Zdroje

• Method for Evaluating the Spatial Distribution of Dielectric Constants: Application to Hydrogenated C(111) and Si(111) Surfaces, ACS Omega, 31. července 2026
• Atomic mapping reveals diamond's secret power for future electronics, tisková zpráva University of Electro-Communications, EurekAlert, 4. srpna 2026

Vydavatel sérií EA Sports FC, Battlefield nebo The Sims oznámil v úterý 4. srpna, že jeho převzetí konsorciem saúdského státního fondu PIF a investičních firem Silver Lake a Affinity Partners je uzavřené. Dohodu strany ohlásily 29. září 2025 a akcionáři ji schválili na mimořádné valné hromadě 22. prosince 2025. Schvalováním u regulátorů po světě prošla transakce podle This Week in Videogames bez viditelných potíží. Akcie Electronic Arts se přestaly obchodovat a z burzy NASDAQ budou vyřazeny.

Za akcii 210 dolarů v hotovosti

Akcionáři dostanou za každou akcii 210 dolarů v hotovosti. Původní oznámení tu cenu popsalo jako prémii 25 % proti kurzu 168,32 dolaru z 25. září 2025, tedy z posledního obchodního dne, kterého se zprávy o chystané transakci ještě nedotkly. Celou firmu včetně dluhů ocenilo zhruba na 55 miliard dolarů. Konsorcium skládá přibližně 36 miliard z vlastních prostředků – počítá se do nich i podíl 9,9 %, který PIF v Electronic Arts držel už dřív – a 20 miliard si půjčuje od banky JPMorgan Chase, z toho 18 miliard mělo být podle původního plánu čerpáno hned při uzavření.

Oborový web This Week in Videogames transakci označuje za největší odkup financovaný dluhem (leveraged buyout) v dějinách: kupující zaplatí podstatnou část ceny půjčkami a ty se pak splácejí z hospodaření kupované firmy.

Většina má připadnout saúdskému fondu

Rozdělení podílů mezi tři kupce tisková zpráva k dokončení neuvádí. Podle dřívějších informací, které This Week in Videogames shrnuje, má PIF držet 93,4 %, Silver Lake 5,5 % a Affinity Partners 1,1 %. Saúdský fond potvrdil dokončení i na svém webu; náměstek guvernéra fondu Turqi Alnowaiser připomněl, že fond byl menšinovým akcionářem Electronic Arts přes pět let, a zábavu se sportem označil za strategické oblasti jeho investic; podle This Week in Videogames do firmy před akvizicí vložil 5,2 miliardy dolarů. Affinity Partners založil a vede Jared Kushner, zeť amerického prezidenta Donalda Trumpa; Silver Lake je investiční firma zaměřená na technologie.

Wilson zůstává, plány počítají s umělou inteligencí

Vedení se nemění: generálním ředitelem zůstává Andrew Wilson a firma dál sídlí v kalifornském Redwood City. Wilson v prohlášení napsal, že firma vstupuje do další kapitoly z pozice síly a s partnery, kteří sdílejí její vizi, a slíbil odvážné investice a rychlejší inovace. Šéf Silver Lake Egon Durban v prohlášení uvedl, že konsorcium chce výrazně investovat do růstu firmy včetně toho, co umělá inteligence dokáže udělat pro vývoj her a zážitek hráčů. This Week in Videogames k tomu připomíná starší zprávu deníku Financial Times, podle které investoři počítají s generativní umělou inteligencí i jako s cestou ke snižování nákladů. V měsících mezi ohlášením a dokončením transakce Electronic Arts propouštěla, mimo jiné ve studiích pracujících na sérii Battlefield.

Do herního průmyslu PIF investuje šířeji: drží podíly ve vydavatelích Take-Two a Nexon i v japonských firmách Capcom a Nintendo, vlastní pořadatele esportových soutěží ESL a vydavatele mobilních her Scopely. Nově k tomu přibývá firma, jejíž poslední účetní rok, uzavřený v březnu 2026, skončil tržbami kolem 7,5 miliardy dolarů.

Buňka, do které pronikne bakteriální jed, umí spáchat sebevraždu tak, aby to bylo vidět. Rozpadne se a vypustí ven poplašné signály, které přivolají imunitní systém. Odborně se tomu říká pyroptóza a proti infekci to pomáhá; horší je, když se rozjede příliš a ničí tkáň víc než původní hrozba. Skupina z americké farmaceutické firmy Genentech a z Chemické fakulty Politechniky Wrocławské teď v časopise Nature popsala, jak takovou smrt zastavit i poté, co už začala.

Nůžky, které proděraví membránu

Pyroptózu spouštějí enzymy zvané zánětlivé kaspázy, u člověka kaspáza-1, -4 a -5, u myši navíc kaspáza-11. Fungují jako molekulární nůžky: rozstřihnou bílkovinu gasdermin D a její uvolněné části se v buněčné membráně poskládají do velkých pórů. Těmi ven unikají cytokiny IL-1β a IL-18, buňka nabobtná a praskne.

Proč dosavadní inhibitory neuspěly

Kaspázy se blokovat umějí a zkoušelo se to i na pacientech. Klinické studie s látkami, které snadno procházejí buněčnou membránou, ale nedopadly. Podle tiskové zprávy Politechniky Wrocławské z 5. srpna za to mohla toxicita nebo malá účinnost: inhibitor se dostal i do zdravých buněk, kde kaspázy dělají jinou a potřebnou práci. Jedním z takových snadno pronikajících inhibitorů je emricasan, který autoři použili v buněčných pokusech jako srovnávací látku.

Wrocławský tým proto obrátil obvyklý postup naruby. Místo látky, která projde membránou co nejsnáz, hledal takovou, která jí projde co nejhůř. Nejdřív metodou hybridních kombinatorických substrátových knihoven (HyCoSuL) přečetl, jaké krátké úseky bílkovin zánětlivé kaspázy přednostně stříhají, a podle toho vznikla knihovna asi sta sloučenin.

Sloučenina, která do buňky neměla proniknout

Pozornost si získala látka označená KGR-3. Přes velmi nízkou propustnost neporušenou membránou zastavovala děj, který probíhá uvnitř buňky.

„Nejzajímavější část projektu začala pozorováním, které se zpočátku nehodilo k našim předpokladům. Sloučenina s velmi nízkou propustností přes membrány zdravých buněk dokázala zastavit děj probíhající uvnitř nich. Místo abychom ten výsledek brali jako odchylku, postavili jsme hypotézu, že samotný mechanismus pyroptózy té látce otevírá cestu do buňky,“ řekl v tiskové zprávě Marcin Poręba z Chemické fakulty. Citace je přeložená z polštiny.

Přímo tu cestu nikdo neviděl; plyne ze dvou nepřímých pozorování. KGR-3 zabránil pyroptóze závislé na kaspáze-1, ale nechránil buňky před apoptózou, tedy tichou formou programované smrti, při níž póry gasderminu D nevznikají. A dovnitř buněk zachráněných před pyroptózou se dostala barviva, která přes neporušenou membránu neprojdou. Membrána se tedy na chvíli otevřela, jenže buňka se přesto nerozpadla.

Krátké okno, ve kterém jde smrt zastavit

Podstatné je, že inhibitor smrt buňky neodkládá, ale odvrací. Jakmile se přidá, přestanou vznikat další póry a ty už otevřené podle autorů zvládne uklidit přirozený opravný aparát buňky, komplex bílkovin ESCRT. Část buněk pak přežije a dál se dělí. Ochrana zabírala i několik hodin po spuštění pyroptózy, takže mezi prvními póry a rozpadem buňky je časové okno, ve kterém se dá zasáhnout.

V tom, jak dlouho autoři přeživší buňky sledovali, se prameny liší. Preprint z února 2025 uvádí růst po dobu pěti dnů, tisková zpráva Politechniky k vydané verzi mluví o dvanácti dnech. Vydaný text je za placenou zdí, takže z veřejně dostupných částí ten rozdíl rozhodnout nejde.

Pokus na myších

Od buněčných kultur se tým posunul k látce KGR-53P, upravené tak, aby neměla záporný náboj: póry gasderminu D podle dosavadních poznatků záporně nabité molekuly propouštějí hůř. V myších makrofázích z kostní dřeně tlumila pyroptózu vyvolanou lipopolysacharidem s hodnotou IC₅₀ kolem 4 µM, přestože ve zkoušce propustnosti na zdravých buňkách procházela membránou špatně.

Následoval myší model endotoxinového šoku. Samice myší kmene C57BL/6N dostaly 20 mg/kg lipopolysacharidu z bakterie Escherichia coli a po dvanácti hodinách se jim v krvi měřily IL-1β a IL-18. Zvířatům, která navíc dostala KGR-53P třicet minut před podáním jedu a šest hodin po něm, vyšly obě hodnoty výrazně níž.

Co to zatím není

Poręba to v tiskové zprávě říká rovnou: nevznikl lék proti sepsi ani proti jiným zánětlivým onemocněním. KGR-3 i KGR-53P jsou výzkumné látky, které se musí dál ladit. KGR-53P se podle něj z organismu rychle vylučoval a zvířatům stouply jaterní enzymy; jestli za to může působení látky na jiné cíle, se zatím neví. V preprintu z února 2025 ani jedna z těch dvou výhrad není.

Potenciál autoři vidí ve strategii samotné. Jako nemoci s nadměrnou zánětlivou reakcí, u kterých by mohla pomoct, jmenují sepsi, syndrom akutní dechové tísně a covid-19.

Kde a v jaké podobě to vyšlo

Nature dalo práci ven 3. srpna 2026 v podobě neupraveného rukopisu; redakce u něj sama upozorňuje, že text ještě projde úpravami a že v něm můžou být chyby. Starší verzi zveřejnil tentýž tým jako preprint na bioRxiv už 11. února 2025 a ta je otevřená celá včetně metodiky; většina čísel v tomhle článku pochází z ní. Chemickou a enzymologickou část projektu financovalo polské Narodowe Centrum Nauki z grantu Opus, buněčné pokusy vedla Katarzyna Groborz, která doktorát dělala ve Wrocławi a dnes působí v Genentechu.

Zdroje

• Groborz K. M. a kol.: Gasdermin D-mediated delivery of caspase inhibitors to suppress pyroptosis, Nature, 3. srpna 2026
• Delivery of caspase inhibitors through GSDMD pores to inhibit pyroptosis, preprint na bioRxiv, 11. února 2025
• Jak uratować komórkę, która zaczęła umierać? Publikacja w Nature, Politechnika Wrocławska, 5. srpna 2026

Konsorcium NVM Express oznámilo 4. srpna aktualizaci celé sady jedenácti specifikací NVMe – protokolu, kterým s počítačem mluví prakticky každý dnešní rychlý disk SSD. Vedle drobnějších technických oprav nese balík čtyři větší novinky: virtualizaci lokálně připojených disků se živou migrací, podporu postkvantové kryptografie, omezování výkonu a sledování napětí.

Disk se rozdělí na virtuální subsystémy sám

Nejvýraznější novinka se jmenuje PCIe Exported NVM Subsystem Migration. Virtualizované „exportované“ subsystémy uměl protokol dosud jen po síti, v rámci NVMe over Fabrics; teď stejný princip dostaly i disky zapojené přímo do sběrnice PCI Express. Fyzický disk se navenek tváří jako sada exportovaných řadičů a jmenných prostorů. Hostitelský systém a virtuální stroj v něm vidí jen tuhle virtuální vrstvu, skutečný hardware zůstává skrytý.

Smysl to má při stěhování virtuálního stroje mezi servery: jeho úložiště se musí přestěhovat s ním, aniž si toho běžící aplikace všimnou. „Jednou z klíčových novinek je, že hostitel dostává kontrolu nad exportovanými identifikátory. Během migrace se dají přenést ze zdroje na cíl beze změny. Právě ta stálost je zásadní: i když podkladový hardware používá jiná interní ID, virtuální stroj žádnou změnu nevidí a může pokračovat přesně tam, kde přestal, bez přenastavování úložiště,“ popisuje na blogu konsorcia Mike Allison ze Samsungu, člen správní rady NVM Express (citace přeložena z angličtiny).

Šablony sundávají práci z hypervizoru

Dnes musí hypervizor administrativní příkazy NVMe od virtuálního stroje zachytávat a odpovědi na ně emulovat podle svých pravidel. Nová specifikace k tomu zavádí šablony: popisují, které funkce exportovaný subsystém podporuje, co je pevně dané a co jde měnit za běhu a jak vypadají migrační data. Šablonu vynucuje sám disk, takže virtuální stroj smí posílat administrativní příkazy přímo a hypervizor je nemusí překládat. Stejná šablona na zdrojovém i cílovém serveru pak zaručí, že se exportované subsystémy na obou stranách shodují – a přesun projde.

Šifry pro dobu po kvantových počítačích

Druhá novinka míří na budoucnost šifrování: protokol nově počítá s algoritmy odolnými proti kvantovým počítačům, které schválil americký standardizační institut NIST, a používá je k ochraně dat na cestě mezi hostitelem a diskem. Server The Register k tomu poznamenává, že důležité to začne být teprve tehdy, až kvantové počítače skutečně dokážou lámat dnešní šifry.

Omezení výkonu a dohled nad napětím

Třetí přírůstek, Rate Limiting, přenáší řízení kvality služby přímo do řadiče disku: vynucuje stropy na propustnost a na počet vstupně-výstupních operací za sekundu (IOPS). Konsorcium tím míří hlavně na poskytovatele cloudu, kteří si tak nad jedním diskem nadefinují různé úrovně služby a udrží výkon systému předvídatelný.

Čtvrtou novinkou je sledování napětí, které má odhalit anomálie napájení dřív, než se projeví na výkonu nebo spolehlivosti disku. K tomu přibyla funkce, která vrátí subsystém NVMe do továrního nastavení, což se hodí při řešení potíží. Podle serveru SDxCentral, který cituje prezidentku konsorcia Amber Huffman, padlo oznámení na oborové akci v kalifornské Santa Claře a novinky mají udržet úložiště bezpečná i v postkvantové éře a zjednodušit správu zařízení.

Aktualizace se týká základní specifikace NVMe 2.4, správního rozhraní Management Interface 2.2, zaváděcí specifikace NVMe Boot 1.4, transportních vrstev pro PCIe (1.4), RDMA (1.3) a TCP (1.3) a specifikací příkazových sad. Všechny jsou volně ke stažení na webu konsorcia. Kdy se novinky objeví v prodávaných discích, oznámení neříká – rozhodnou o tom až řadiče a firmware jednotlivých výrobců.

Čínská Ústřední komise pro záležitosti kyberprostoru (Cyberspace Administration of China) zveřejnila 22. července 2026 plán na roky 2026–2030, podle kterého má čínský internet přejít na síť běžící jen s protokolem IPv6, bez zálohy v IPv4. Zprávu popsal server The Register, nezávisle ji potvrdil i server ChinaTechNews.com.

Co plán žádá

Dokument s názvem Implementační plán pro prohloubení technologických inovací a integrovaného využití IPv6 stanovuje, že do roku 2027 má mít Čína 900 milionů aktivních uživatelů IPv6 a protokol má nést 38 % síťového provozu. Do roku 2030 se má počet uživatelů zvýšit na 950 milionů a podíl na provozu na 42 %. Nově připojovaná zařízení mají dostávat adresu IPv6 jako výchozí a síť se má postupně zbavovat překladu mezi IPv4 a IPv6 (NAT) i souběžného provozu obou protokolů, takzvaného dual-stacku, který dnes používá většina zemí včetně Česka. Server ChinaTechNews uvádí, že plán rozepisuje 36 technických úkolů v deseti oblastech.

Rozšíření IPv6+ a SRv6

Plán zároveň žádá další práci na takzvaném IPv6+ – souboru rozšíření, která umí do paketu vložit metadata popisující jeho obsah a navrhnout trasu, kudy má putovat sítí. Jádrem je technologie SRv6 (Segment Routing over IPv6), která má v čínských plánech nahradit starší protokol MPLS a umožnit programovatelné směrování přímo podle záhlaví paketu, tedy bez centrální tabulky tras, kterou dnes drží každý směrovač zvlášť. Podle ChinaTechNews to má hlavně zrychlit a zjednodušit provoz uvnitř průmyslových a finančních sítí.

Proč to znepokojuje analytiky

Server The Register cituje analýzu institutu MERICS (Mercator Institute for China Studies), podle které má IPv6+ „zjevnou přitažlivost pro autoritářské režimy, které chtějí kontrolovat občany“ – protože operátor sítě dokáže metadata v paketu přečíst a podle nich jednat. Zmiňují se dvě možnosti: operátoři by mohli podle typu obsahu účtovat vybraný provoz, třeba video ze služeb jako Netflix nebo YouTube, zvlášť, a čtení metadat by mohlo usnadnit cenzuru – pokud by uživatel musel svůj provoz nějak označit, snáz by se dal dohledat a zablokovat. MERICS podle Registeru upozorňuje, že čínští výrobci telekomunikačního vybavení mají IPv6+ už zabudované ve svých produktech a že se tyto produkty vyvážejí i do dalších zemí.

Dřívější pokus: New IP

Čína se o prosazení vlastní verze internetového protokolu pokusila už dřív. Peking navrhoval Mezinárodní telekomunikační unii (ITU) protokol nazvaný „New IP“, který měl podle kritiků obsahovat obdobné prvky pro sledování provozu. Návrh neuspěl, protože standardy internetového protokolu spravuje organizace IETF, ne ITU. Podle Registeru teď Peking pokračuje v šíření vlastní verze IP jinou cestou – doma legislativně a v zahraničí prodejem síťového vybavení.

Co plán nenavrhuje

Dokument nechce, aby se Čína od běžného IPv6 odtrhla úplně – naopak vyzývá k čínské účasti na vývoji globálních standardů. Zároveň ale plánuje vyvíjet vlastní národní standardy IPv6 a zrychlit jejich vznik v klíčových oblastech, což by teoreticky mohlo časem vést k rozštěpení mezi tím, jak internet funguje v Číně a jinde. Zatím jde ale o plán do roku 2030, ne o hotovou infrastrukturu.

Vývojář Richard Hughes oznámil 4. srpna 2026 na svém blogu, že se NVIDIA stala sponzorem nejvyšší úrovně (Premier) projektu LVFS (Linux Vendor Firmware Service). Firma se tím zařadila vedle Dellu, Lenova a HP a podle Hughese jde už o čtvrtého výrobce, který na tuhle úroveň přispívá – čímž se naplnil cíl financování, který si projekt stanovil před rokem. Zprávu nezávisle potvrdily i servery Phoronix a VideoCardz.

Co LVFS a fwupd dělají

LVFS je katalog firmwaru, do kterého výrobci hardwaru nahrávají aktualizace a popisná metadata. Na straně uživatele je čte démon fwupd, který pozná podporovaný hardware a nabídne mu odpovídající aktualizaci – místo aby si uživatel musel stahovat samostatný nástroj od každého výrobce zvlášť. Většina lidí se s fwupd setká nepřímo přes aplikaci GNOME Software nebo příkaz fwupdmgr. Projekt vede od jeho začátku právě Hughes, dnes zaměstnaný u Red Hatu; hosting dlouhodobě platí Linux Foundation, pod kterou LVFS formálně spadá od roku 2019.

Rok na naplnění cíle

Sponzorská úroveň Premier vznikla podle plánu udržitelnosti, který Hughes zveřejnil 8. srpna 2025: LVFS podle něj rostl rychleji, než stíhaly kapacity jediného hlavního vývojáře, a projekt proto začal žádat největší výrobce, kteří přes něj rozesílají miliony aktualizací, aby přispěli na placenou náhradu a zálohu. Volnou (Associate) úroveň si přitom podle plánu zachovala i drtivá většina ze stovky menších dodavatelů na LVFS, protože jejich měsíční kvóta 50 000 stažení a 50 nahrání zůstala beze změny.

Prvními sponzory na úrovni Premier se 6. května 2026 staly Dell a Lenovo, o dva týdny později přidalo HP. Podle květnového oznámení už v té době LVFS doručil přes 145 milionů aktualizací firmwaru od víc než stovky výrobců. Na stránce seznamu sponzorů jsou Dell, Lenovo, HP a nově NVIDIA jako jediní čtyři označení „Premier Level Sponsor“; nižší úroveň Startup má mimo jiné výrobce notebooků Framework.

NVIDIA a firmware DGX Spark

Hughes svůj srpnový zápis spojil přímo s konkrétním produktem: podle něj NVIDIA přes fwupd distribuuje firmware pro svůj kompaktní počítač DGX Spark a počet stažení podle jeho slov průběžně roste. VideoCardz dodává, že dřívější aktualizace pro DGX Spark přes LVFS přidaly správu spotřeby řadiče ConnectX-7, opravy kompatibility displeje a podporu zvuku přes Bluetooth. Na oficiálním seznamu sponzorů má NVIDIA k dnešnímu dni na starosti 21 souborů s firmwarem, z toho devět nahraných za posledních šest měsíců, a používá aktualizační protokol UEFI Capsule.

Novinářský server Phoronix k tomu připojuje vlastní odhad, ne tvrzení NVIDIE nebo Hughese: doufá, že by firma mohla přes LVFS časem rozesílat firmware i pro servery s čipy Vera Rubin nebo dokonce pro grafické karty. Zatím to ale zůstává jen přáním autora článku – aktuální sponzorství se váže na už fungující distribuci firmwaru pro DGX Spark, ne na přislíbené rozšíření na další produkty.

Co to znamená pro linuxové uživatele

Přímý dopad pro běžného uživatele desktopu je zatím omezený – aktualizace firmwaru grafických karet GeForce přes LVFS/fwupd v tuto chvíli nejdou, NVIDIA je pro desktopové karty dál řeší přes vlastní proprietární nástroje. Sponzorství spíš potvrzuje, že firma bere fwupd vážně jako kanál pro svůj hardware zaměřený na Linux (DGX řada, případně budoucí platformy) a že se podílí na financování infrastruktury, kterou už reálně využívá. Pro projekt samotný to znamená, jak Hughes napsal, naplněný roční cíl a prostředky na placenou zálohu pro jediného dosavadního hlavního vývojáře.

Projekt zlib-rs vydal 3. srpna 2026 verzi 0.6.7. Podle poznámek k vydání přináší hlavně dvě věci: opravu chyby use-after-free ve funkci set_level a sadu optimalizací pro architekturu LoongArch. Nezávisle o vydání informoval i server Phoronix.

Bezpečnější náhrada starého céčkového zlib

Zlib je desítky let stará knihovna pro kompresi dat ve formátu DEFLATE, napsaná v jazyce C. Používá ji obrovské množství software – od archivátorů přes formát PNG až po síťové protokoly. Zlib-rs je její přepis do jazyka Rust se stejným rozhraním, takže jde nasadit jako náhradu beze změny volajícího kódu. Podle vlastního popisu projektu na GitHubu stojí za jeho vznikem organizace Internet Security Research Group (ISRG), tedy nezisková organizace, která provozuje i certifikační autoritu Let's Encrypt, v rámci svého programu Prossimo na přepisování klíčové internetové infrastruktury do paměťově bezpečných jazyků. Vývoj dál financuje Trifecta Tech Foundation. Podle stránky projektu na GitHubu knihovnu používá přes jedenáct tisíc repozitářů, nejsnáz se do rustových projektů dostává přes balíček flate2.

Chyba, která obchází bezpečnost Rustu

Rust hlídá při překladu, že se program nesahá na paměť, která už byla uvolněná – tahle třída chyb (use-after-free) je v jazycích jako C nebo C++ jedním z nejčastějších zdrojů zranitelností. Kontrola ale platí jen pro takzvaně bezpečný Rust; jakmile knihovna uvnitř sáhne po surových ukazatelích (raw pointers) v bloku označeném unsafe, hlídání se vypne a odpovědnost za správnost přebírá autor kódu.

Přesně to se stalo ve funkci compress_uninit: podle popisu chyby, který zveřejnil uživatel kimjy0126, si tahle funkce uloží surové ukazatele na vstupní a výstupní vyrovnávací paměť, aniž by jejich životnost svázala se strukturou Deflate. Když si volající kód pak nechá zaniknout původní buffery a zavolá funkci set_level pro změnu úrovně komprese, sáhne se přes ty už neplatné ukazatele – to je use-after-free. V přiloženém ukázkovém kódu volající program nepoužívá jediné nebezpečné (unsafe) volání a přesto chybu spolehlivě vyvolá, protože nebezpečná část je schovaná uvnitř samotné knihovny.

Bez bezpečnostního dopadu, tvrdí autoři

Nálezce nahlásil chybu nejdřív soukromě přes bezpečnostní kontakt projektu a teprve po domluvě ji zveřejnil jako běžný issue. Hlavní vývojář Folkert de Vries v diskusi napsal, že tým chybu nepovažuje za bezpečnostní riziko: způsob použití, který ji spouští, je podle něj v praxi extrémně vzácný, a program, který by na něj narazil, by beztak fungoval špatně už předtím – chyběla by mu část dat, protože se nestihla zapsat. Opravu přinesla oprava v pull requestu #552, kterou tým zároveň pokryl novým testem a spuštěním pod adresním sanitizérem (AddressSanitizer) v automatických testech, aby se podobná chyba příště odhalila dřív.

Zrychlení pro čínskou architekturu LoongArch

Kromě opravy přidala verze 0.6.7 podle Phoronixu dvě optimalizace pro instrukční sadu LSX (Loongson SIMD eXtension) čínské architektury LoongArch: novou implementaci funkce compare256 s přírůstkem rychlosti kolem 4 % v jednom testu a širší načítání a ukládání dat při dekompresi (inflate), které v tomtéž měření zrychlilo až o 10 %. LoongArch je architektura procesorů čínské firmy Loongson, kterou si vývojáři zlib-rs postupně přidávají do podporovaných cílů vedle x86, ARM a RISC-V.

Zlib-rs není jediný rustový projekt, který se snaží nahradit klíčovou céčkovou infrastrukturu – podobným směrem jde třeba gccrs, rustový frontend pro překladač GCC, který testuje překlad přímo linuxového jádra. Rozdíl je v tom, že zlib-rs už dnešní verzi zlib v produkčním provozu skutečně nahrazuje, zatímco gccrs teprve dohání funkčnost potřebnou ke spuštění jádra.

Otevřený projekt FFmpeg vydal 4. srpna 2026 verzi 9.0 s přezdívkou „Lei“. Podle vlastní stránky projektu vychází nová hlavní verze zhruba jednou za šest měsíců; vývojáři ji oddělili od hlavní vývojové větve 26. června 2026 a dalších šest týdnů jen opravovali chyby a ladili stabilitu. Předchozí hlavní verze, FFmpeg 8.0 „Huffman“, vyšla 22. srpna 2025; mezitím dostala jen bezfunkční opravnou verzi 8.1 „Hoare“ v březnu 2026.

FFmpeg samo o sobě není program s okny, ale sada knihoven a příkazová řádka pro čtení, převod a úpravu zvuku a videa. Většina lidí ho proto nikdy nespustí přímo – je součástí přehrávače VLC a desítek dalších programů na zpracování multimédií, od střihových nástrojů po webové prohlížeče.

Vulkan zabírá další kodeky

Vulkan je otevřené rozhraní pro grafické karty, které vedle vykreslování 3D scén umí zadávat i obecné výpočty a dekódování videa bez ohledu na výrobce karty. FFmpeg 9.0 přes něj nově umí dekódovat formát APV (Advanced Professional Video), otevřený profesionální kodek, který loni představil Samsung a letos ho nasadil i do fotoaparátu telefonu Galaxy S26 Ultra. Přibyl také filtr v360_vulkan pro přepočet 360stupňového videa mezi projekcemi, který teď může běžet přímo na grafické kartě místo na procesoru.

AMD a Apple dostaly víc hardwarového zrychlení

AMD do svých grafických karet vestavuje vlastní sadu nástrojů Advanced Media Framework (AMF) pro kódování a dekódování videa. FFmpeg 9.0 přes ni přidal filtr pro převod snímkové frekvence (vf_frc_amf), filtr na vylepšení kvality obrazu (vf_vqe_amf) a podporu mapování hardwarové paměti; barevný převodník vf_vpp_amf navíc umí víc nastavení HDR. Na straně Apple přibylo hardwarové dekódování formátu ProRes RAW přes rozhraní VideoToolbox, tedy přímo na čipu Apple Silicon místo na procesoru.

Animovaný WebP se konečně dá i přečíst

WebP je obrázkový formát Googlu, který kromě statických snímků umí i animaci – konkurent animovaného GIFu s menší velikostí souboru. FFmpeg uměl animovaný WebP zapisovat už přes deset let, chyběl mu ale opačný směr: dekodér a demuxer, který by takový soubor přečetl zpátky a šel ho třeba převést do jiného formátu nebo přehrát. Tuhle mezeru doplnil až changelog verze 9.0, kde jsou oba nové – dekodér i demuxer animovaného WebP.

Co dalšího přibylo a co zmizelo

Nová verze umí dekódovat i zvukový formát HE-AAC 960, který používá digitální rozhlas DAB+, a přenášet metadata SMPTE 2094-50 – dynamická metadata, na kterých stojí HDR10+. Přibyl také GPU akcelerovaný běh strojových modelů přes ONNX Runtime, tedy nástroj pro filtry založené na umělé inteligenci, například na odšumování nebo zvětšování obrazu. Naopak zmizela podpora dekódování zvukového formátu CELT (na samotný Opus, který CELT používá uvnitř, to vliv nemá) a staré volby pro NVIDIA kodér NVENC vázané na ovladače starší než 11.1 – kdo je má, musí před přechodem na FFmpeg 9.0 aktualizovat i ovladač grafické karty.

Přibyl i bitstreamový filtr, který rozdělí vícevrstvý HDR stream Dolby Vision uložený v HEVC na samostatné vrstvy, a podpora kapesní herní konzole Playdate – FFmpeg jí teď umí zapsat video přímo ve formátu, který zvládne přehrát.

Propojky, tenké vodivé cestičky, které v čipu spojují miliardy tranzistorů, se dnes vyrábějí z mědi kvůli její vysoké vodivosti. S dalším zmenšováním tranzistorů se ale musí zmenšovat i ony – a právě tehdy měď selhává. Tým z Cornellovy univerzity teď popsal materiál, který dělá přesný opak: se zmenšováním se stává vodivějším. Práce vyšla 16. července v časopise Science.

Proč měď v tenkých drátech ztrácí vodivost

Za vodivostí mědi stojí volný pohyb elektronů mezi srážkami s atomy mřížky. Tahle vzdálenost, takzvaná střední volná dráha, je u mědi kolem 40 nanometrů. Jakmile se drát zúží pod tuto hranici, elektrony začnou narážet i na jeho povrch, srážek přibude a vodivost prudce klesne. Inženýři proto zkoušejí i jiné kovy: kobalt má střední volnou dráhu kolem 10 nanometrů, ruthenium kolem 6 nanometrů, takže propojky z nich můžou být tenčí než měděné, než narazí na tentýž problém.

Elektrony, které tečou po povrchu

Cornellský tým vedený profesorkou materiálového inženýrství Judy Chaovou se místo toho posledních sedm let věnuje topologickým materiálům. Jde o látky, jejichž vodivé vlastnosti vyplývají z topologie jejich elektronové struktury – zjednodušeně řečeno mají kromě běžných elektronů uvnitř objemu materiálu i elektrony tekoucí po povrchu, které se hůř rozptylují. „Elektrony, které tečou po povrchu materiálu, se pohybují opravdu rychle a tak snadno se nerozptylují. To je důvod, proč měď trpí, protože měď má elektrony jenom v objemu,“ popsala Chaová v tiskové zprávě Cornell Chronicle. Konkrétní zkoumanou látkou je arsenid niobu, takzvaný Weylův semimetal – materiál vodivý jak v celém objemu, tak na povrchu, kde jeho vodivost nesou kvazičástice odvozené od teoretických Weylových fermionů.

Nanodrátky jako těstoviny

Dosavadní metody výroby nanodrátků – růst z par přes kapku kovu nebo napařování z plynné fáze – podle Chaové neumožňují dost přesně řídit tloušťku a tvar výsledného vlákna. Tým proto použil metodu zvanou termomechanické nanotvarování: materiál se slisuje do objemového polotovaru, ten se za vysoké teploty a tlaku několik hodin protlačuje pórovitou formou z oxidu hlinitého a forma se pak odleptá. „Když v kuchyňském stroji na těstoviny vyměníte přední destičku, uděláte fettuccine nebo vlasové nudle,“ přirovnala Chaová postup pro Cornell Chronicle. „My bereme objemový polotovar jako své těsto a používáme různé formy s různým průměrem pórů.“ Metoda podle ní zvládne řídit průměr drátu až na přibližně 10 nanometrů a je navíc rychlá – dřív skupina zkoumala jeden až dva materiálové systémy ročně, dnes jeden měsíčně.

Sedmdesát procent nižší odpor u čtyřiceti nanometrů

Vědci vyrobili jednokrystalové nanodrátky arsenidu niobu dlouhé 2 až 3 mikrometry a tenké až 40 nanometrů. U 40 nanometrů širokého drátu naměřili při pokojové teplotě odpor asi o 70 % nižší než u objemového monokrystalu téhož materiálu, a podle jejich analýzy za to může právě vodivost na povrchu. Tyhle 40nanometrové dráty už byly vodivější než stejně tlusté dráty z kobaltu nebo ruthenia, na nejmodernější 10nanometrové měděné propojky ale zatím nestačily. Podle výpočtů týmu by je měly předstihnout až dráty arsenidu niobu s průměrem kolem 12 nanometrů – tam by podíl povrchové vodivosti na celkovém vedení proudu měl převážit nad podílem z objemu materiálu. Dráty navíc zůstaly stabilní na vzduchu, snesly vysoký proud bez poškození a měly vysokou tepelnou vodivost, což by propojkám pomohlo se nepřehřívat.

Co brání nasazení v továrně

Chaová sama upozorňuje, že arsenid niobu nejspíš nebude prakticky nahrazovat měď – arsen je toxický. Podle IEEE Spectrum navíc použitá metoda výroby není slučitelná s procesy CMOS ani s běžnou výrobní linkou pro zadní části čipu (tzv. back-end-of-line). Podle Chaové je ale výsledek důkazem principu: topologické semimetaly nejsou jen hračka pro fyziky v laboratoři, ale reálně použitelný materiálový systém. Tým už dřív, v roce 2023, zkoumal příbuznou sloučeninu – monofosfid molybdenu, který byl stabilnější než měď, ale jeho vodivost se s tenčením nezlepšovala. Arsenid niobu je podle autorů první látka, která splňuje obě podmínky najednou. Pozornost průmyslu k tématu potvrzuje i to, že na červnovém sympoziu IEEE/JSAP VLSI v Honolulu představil Samsung výzkum fosfidu molybdenu a IBM výzkum monosilicidu kobaltu – jiných topologických materiálů pro tentýž účel.

Google 28. července 2026 rozšířil Managed Agents v Gemini API o několik novinek najednou: výchozí model Gemini 3.6 Flash, takzvané environment hooky, strop na spotřebu tokenů, naplánované spouštění podle cronu, přístup i na bezplatném tarifu a samostatné API pro správu sandboxů. Popisuje to firemní blog. Podle rozboru serveru The AI Navigator žádná z novinek sama o sobě nevypadá okázale, dohromady ale ukazují, jak má vypadat kontrolní vrstva nad autonomními agenty.

Jeden sandbox na jedno volání API

Managed Agents v Gemini API fungují tak, že jediné volání API vytvoří izolovaný linuxový sandbox v cloudu. Uvnitř něj model uvažuje, spouští kód, instaluje balíčky, pracuje se soubory a prochází web – bez toho, aby vývojář musel řešit vlastní orchestraci. Výchozím modelem se od aktualizace bez nutnosti měnit kód stal Gemini 3.6 Flash; jde ale explicitně zvolit i Gemini 3.5 Flash nebo úspornější Gemini 3.5 Flash-Lite přes pole agent_config.model.

Hooky před a po volání nástroje

Nejvýraznější novinkou jsou environment hooky. Do prostředí agenta stačí přidat soubor .agents/hooks.json a runtime pak spustí přiřazené skripty při událostech pre_tool_execution a post_tool_execution. Pole matcher bere regulární výraz, takže jde zacílit na víc nástrojů najednou nebo hvězdičkou na všechny:

{
  "security-gate": {
    "pre_tool_execution": [{
      "matcher": "code_execution|write_file",
      "hooks": [{"type": "command", "command": "python3 gate.py", "timeout": 10}]
    }]
  }
}

Když skript před spuštěním nástroje vrátí {"decision": "deny", "reason": "..."}, agent volání nástroje neprovede a důvod zamítnutí se dostane rovnou do kontextu modelu, který na to může zareagovat. Hook spuštěný až po volání – třeba na formátování kódu nebo audit – už provedenou akci vrátit nemůže. Podle firmy OffDeal, citované přímo v oznámení Googlu, díky tomu můžou hooky poprvé ověřovat výstupy – v jejich případě loga firem v investičních prezentacích – přímo uvnitř vzdáleného sandboxu, kam dřív jejich vlastní kontrolní kód neměl kam sáhnout.

The AI Navigator ale upozorňuje na meze: hooky zatím nepokrývají volání externích nástrojů přes MCP ani vlastní funkce, a když hook vrátí neplatnou odpověď, výchozí chování je akci povolit, ne zablokovat. Server také píše, že pokud konfigurace hooků leží v zapisovatelném místě uvnitř téhož prostředí, dost schopný agent do ní teoreticky může sám zasáhnout – proti tomu pomáhá jen konfigurace jen pro čtení nebo externí koncový bod mimo dosah sandboxu.

Strop na tokeny a spouštění podle cronu

Protože agent běží ve víckolovém autonomním cyklu, může spotřeba tokenů snadno utéct. Nové pole max_total_tokens v agent_config stanoví strop na celkovou spotřebu (vstupní, výstupní i „přemýšlecí“ tokeny dohromady); po jeho dosažení běh bezpečně pozastaví se stavem incomplete, prostředí sandboxu zůstane zachované a práce jde dokončit předáním previous_interaction_id s novým rozpočtem. Podle dokumentace Googlu, kterou cituje The AI Navigator, se jedna interakce běžně pohybuje mezi 100 000 a 3 miliony tokenů, u složitějších úkolů i mezi 3 a 5 miliony – strop je proto míněný jako hrubá pojistka, ne přesný cenový limit: kešované tokeny se do něj nepočítají a skutečná spotřeba ho může mírně přesáhnout, protože se kontroluje jen mezi jednotlivými kroky agenta.

Naplánované spouštění (scheduled triggers) sváže agenta, jeho prostředí, zadání a cron rozvrh do trvalého zdroje, který se spouští sám a při každém běhu používá tentýž sandbox, takže si soubory mezi jednotlivými spuštěními pamatuje. Nové Environments API navíc dovolí sandboxy vypsat, prohlédnout a smazat ručně, místo aby vývojář čekal na výchozí sedmidenní platnost. Managed Agents jsou od aktualizace dostupné i na bezplatném tarifu bez aktivní fakturace.

Kontrolní vrstva, ne hotová bezpečnostní hranice

Sandboxy mají podle dokumentace Googlu ve výchozím stavu neomezený odchozí přístup k síti, omezit ho jde jen vlastním seznamem povolených adres. The AI Navigator z toho vyvozuje, že hooky, strop na tokeny ani naplánované spouštění samy o sobě nedělají nasazení agenta bezpečným – jde spíš o soubor nástrojů, kterými si tým může sám vynutit, co agent nikdy nesmí udělat bez schválení, a jak poznat, že agent běžící podle rozvrhu pořád ještě někdo sleduje. Server v té souvislosti cituje i zprávu The GenAI Divide konsorcia MIT NANDA z roku 2025, podle které přibližně 95 % zkoumaných firemních nasazení generativní AI nepřineslo měřitelný dopad na hospodářský výsledek – hlavní příčinou podle té zprávy nebyly schopnosti modelů, ale integrace do provozu a chybějící organizační rámec kolem nich.

Nástroj N-central od kanadské firmy N-able spravuje počítače a servery na dálku z jednoho místa – používají ho firmy, které pro zákazníky provozují IT infrastrukturu, i vlastní IT oddělení podniků. Kdo ovládne server s N-central, dostane se nepřímo ke všem strojům, které přes něj někdo spravuje. Přesně to hrozilo začátkem srpna 2026: oprava starší autentizační díry šla obejít jinou cestou a útočník díky tomu na postižených serverech získal plná administrátorská práva.

Nárůst licenčních chyb byl první stopa

Podle vlastního popisu incidentu si N-able 31. července 2026 všiml nárůstu chyb v licencování u zákazníků, kteří provozují N-central na vlastním serveru, ne ve verzi v cloudu firmy. Takové chyby nejsou samy o sobě neobvyklé, jejich objem ale byl vysoký, a proto se do vyšetřování zapojil technický i bezpečnostní tým.

Ráno 2. srpna analýza ukázala, že za tím stojí starší zranitelnost CVE-2026-18556 – obcházení autentizace, které N-able opravil ve verzi 2026.2. Zranitelnost dovolovala obejít přihlášení a dostat se k datům bez oprávnění; podle záznamu postihovala verze do 2026.1 včetně.

Oprava sama nechala jinou cestu otevřenou

Jenže oprava z verze 2026.2 pokrývala jen jednu cestu k témuž cíli. Podle popisu CVE-2026-18577 v Národní databázi zranitelností (NVD) jde o „neúplnou opravu CVE-2026-18556“, která dál umožňuje obejít přihlášení a převzít účet – a to až ve verzích do 2026.3.1 včetně. Kdo starou díru znal, mohl se dostat dovnitř i poté, co ji N-able formálně opravil.

Podle vlastního oznámení firmy vydal vývojářský tým opravu ještě týž den odpoledne – hotfix pro řadu 2026.3 s označením 2026.3.1.7, v poznámkách k vydání vedený jako 2026.3 Hotfix 1. Nová zranitelnost dostala vlastní záznam, CVE-2026-18577.

Útočník ovládl stanice přes vestavěný vzdálený přístup

N-able ve svém popisu incidentu uvádí, že útočník na serverech se starší verzí než 2026.3.1.7 získal vzdáleně administrátorský přístup. Odtud využil funkci Take Control, kterou N-central jinak slouží technikům ke vzdálenému připojení na spravované počítače, a napojil se na stroje uvnitř prostředí zákazníka. Na nich pak zaregistroval novou službu, která vytvořila tunel přes síť Cloudflare – tím si zajistil přístup, i kdyby mu později přístup k samotnému serveru N-central zablokovali.

Podle N-able je incidentem zasažený jen omezený počet zákazníků a jejich podpora je s nimi v přímém kontaktu. Firma zveřejnila šest IP adres spojených s útokem a nástroj pro techniky, který na koncových stanicích s Windows hledá známé stopy průniku – s výhradou, že čistý výsledek kontroly sám o sobě neznamená, že prostředí zasažené nebylo.

CISA dala na záplatu tři dny

Americký Úřad pro kybernetickou a infrastrukturní bezpečnost (CISA) zařadil CVE-2026-18577 3. srpna 2026 do katalogu Known Exploited Vulnerabilities – seznamu zranitelností, u kterých má úřad doloženo, že je někdo v praxi zneužívá. Lhůta na opravu je tři dny, do 6. srpna, což patří k nejkratším termínům v katalogu. Povinnost zalátat do lhůty platí přímo jen pro federální civilní úřady USA, katalog ale běžně slouží i soukromým firmám jako vodítko, které opravy řešit přednostně.

Kdo N-central provozuje na vlastním serveru, by měl podle N-able upgradovat na verzi 2026.3.1.7 nebo novější bez ohledu na to, jestli mu tuhle lhůtu úřad přímo nařizuje.

Firma Thermo Fisher Scientific opravila zranitelnost ve svém softwaru pro genetickou identifikaci, který po celém světě používají kriminalistické laboratoře k vyhodnocení DNA vzorků. Podle vlastního bezpečnostního bulletinu z 31. července 2026 šly výstupní soubory s DNA profily pozměnit tak, že si toho analytický program nevšiml – stačilo obejít laboratorní kontroly přístupu k datům. Podle deníku The Wall Street Journal to výzkumníci demonstrovali s pomocí modelu Claude od Anthropicu; sama Thermo Fisher ale uvedla, že o žádném skutečném zneužití neví.

Co zranitelnost umožňovala

Zranitelnost vedená jako CVE-2026-17583 se týká souborů typu .fsa a .hid, které vytvářejí přístroje řady Applied Biosystems pro lidskou identifikaci – genetické analyzátory, jaké laboratoře běžně používají k vyhodnocení STR profilů při kriminalistickém i příbuzenském testování. Bulletin popisuje riziko jako téměř neodhalitelnou úpravu těchto souborů předtím, než je načte analytický software, pokud někdo obejde kontroly v laboratoři. Thermo Fisher zranitelnost ohodnotila stupněm CVSS v4.0 8,2, tedy jako vysoce závažnou.

Demonstrace s pomocí modelu Claude

Podle Wall Street Journal zranitelnost otestoval Nathan Adams, systémový inženýr firmy Forensic Bioinformatics, na veřejně dostupné datové sadě. První úspěšná úprava souboru s pomocí modelu Claude mu podle listu zabrala zhruba 45 minut. V ukázce, kterou list viděl, jeho kód sloučil skeny ze dvou samostatných DNA profilů do nového souboru, který vypadal, že se od roku 2015 nezměnil – analytický software používaný řadou laboratoří na výsledný soubor neupozornil žádným varováním. Podle výzkumníků ale útočník potřebuje místní nebo vzdálený přístup k serverům laboratoře a znalost toho, jak DNA testování funguje – zvenčí přes veřejný internet zranitelnost sama o sobě nestačí.

Co je opravené, co ne

Aktualizaci s digitálními podpisy, které mají do budoucna ověřit, že data nikdo nezměnil, dostalo pět produktových řad – mimo jiné software pro sběr dat u přístrojů řady 3500/3500xL a 3730/3730xL a program GeneMapper ID-X. Bulletin ale neříká, jestli jde stejným způsobem ověřit i soubory vytvořené před aktualizací. Tři starší řady – 3130 Series, ABI PRISM 3100/3100-Avant a ABI PRISM 310 – aktualizaci nedostanou vůbec, protože jim skončila podpora. Laboratořím, které je pořád provozují, Thermo Fisher doporučuje jen obecná opatření: šifrované úložiště, omezený přístup podle rolí a omezení síťového připojení jen na důvěryhodné zdroje.

Co zůstává nejisté

Podle výzkumníků, které citoval Wall Street Journal, zranitelnost pravděpodobně existovala v souborech z těchto přístrojů už od roku 1995 a dřívější úpravu souboru by dnes nešlo nijak odhalit. Sám bulletin Thermo Fisher tenhle historický rozsah nepotvrzuje. Zranitelnost se navíc týká jen digitálních záznamů z testování, ne samotných fyzických vzorků DNA. Ke 3. srpnu 2026 zranitelnost neměla vlastní záznam v databázích CVE.org ani NVD a nebyla ani v katalogu zneužívaných zranitelností amerického úřadu CISA, který na odhalení zranitelnosti spolupracoval – tedy zatím nic nenasvědčuje tomu, že by ji někdo skutečně zneužil mimo laboratorní podmínky demonstrace.

Linuxové jádro umí od roku 2022 přijímat kód napsaný v Rustu, jeho překlad ale zajišťuje výhradně rustc, oficiální kompilátor založený na LLVM. Projekt gccrs od roku 2020 staví alternativu – rustový frontend přímo pro GCC. Podle shrnutí na LWN.net a vlastních měsíčních zpráv věnoval tým první polovinu roku 2026 právě tomu, aby jím šlo přeložit rustové části jádra, a cestou odhalil a opravil několik zásadních chyb ve zpracování jmen, destruktorů i metadat.

Proč vedle LLVM ještě GCC

Rust v jádře dnes běží výhradně přes rustc s LLVM backendem – experimentální podpora GCC jako backendu přes rust_codegen_gcc existuje, ale samotný frontend zůstává rustc. LLVM ale nepokrývá všechny architektury, které umí GCC, a nedává přístup do jeho pluginového ekosystému. S tím, jak rustová část jádra roste, roste i tlak distribucí na to, aby toolchain nebyl vázaný na jediný kompilátor.

Tři milníky místo verzí GCC

V březnu 2026 tým přeorganizoval plán práce: místo cílení na konkrétní vydání GCC zavedl tři milníky podle schopností. „Embedded Rust compiler“ má zvládnout programy bez standardní knihovny, závislé jen na balíčku core. „Rust-for-Linux compiler“ k tomu přidá balíček alloc a konkrétní balíčky, které používá jádro. „General purpose compiler“ má nakonec zvládnout rustový kód obecně, ne jen jádro.

První milník je podle květnové zprávy skoro hotový. Druhý, klíčový pro jádro, stoupl z 16 procent v únoru na 35 v květnu. Dílčí čísla to rozepisují podrobněji: podpora balíčku compiler_builtins a funkce build_error je hotová na sto procent, balíček ffi na 40, ale makra jádra, rozhraní uapi i hlavní soubory jádra byly v květnu pořád na nule.

Chybějící destruktory

Rust spravuje zdroje modelem RAII: když hodnota vypadne ze scope, kompilátor sám zavolá její destruktor podle traitu Drop. Sledovat, kdy se má proměnná uklidit, je složité, protože stav její inicializace se mění podle průběhu programu – kompilátor proto musí analyzovat řídicí tok a generovat takzvané drop flags, tedy proměnné za běhu, které říkají, jestli je hodnotu ještě potřeba zrušit. Tahle analýza v gccrs podle LWN chyběla úplně, takže se volání Drop::drop() někdy vynechávalo nebo bylo špatně.

V jádru to není kosmetická chyba. Rust-for-Linux vrací při zamčení zámku takzvaný MutexGuard, jehož implementace Drop zámek uvolní. Bez správného volání Drop by zámek zůstal držený i po tom, co strážce vypadl ze scope – to znamená zablokovaný kód nebo deadlock. Na infrastruktuře pro Drop od května pracuje účastnice Google Summer of Code Janet Chien.

Jmenný prostor, který si kompilátor pletl

Testování na standardní knihovně a jádru odhalilo i chybu ve zpracování jmen. Rust rozlišuje čtyři jmenné prostory – pro hodnoty (funkce, statické proměnné), makra, typy a pro životnosti a návěští. Když gccrs hledal definici položky, hledal ji rovnou ve prostoru cílového typu: u funkce tedy ve prostoru hodnot. Jenže moduly a veřejně viditelné importy leží ve prostoru typů, takže bez jejich vyřešení tam kompilátor nedokázal projít cestou k funkci vůbec.

Oprava znamenala přepsat vnitřní datové struktury a část visitor kódu v celém překladači. Do května se tím podařilo správně rozpustit hluboko zanořené importy v balíčku core a chování se přiblížilo rustc.

Atributy pro jádro a chybějící metadata

Podle únorové zprávy přepracoval hlavní vývojář Pierre-Emmanuel Patry i zpracování atributů typu #[cfg()], které řídí podmíněný překlad. Odstraňování položek podle cfg rozdělil do dvou průchodů – bez toho nešlo podporovat nestabilní funkce jádra, které při expanzi maker potřebují atributy nejdřív odstranit a teprve pak validovat. V březnu k tomu přibyl přepínač -frust-crate-attr, obdoba přepínače -Zcrate-attr v rustc, který umí vložit atribut (třeba #![no_core]) při volání kompilátoru bez zásahu do zdrojového kódu.

Propojování rustových balíčků jádra pak odhalilo další chybu: exportovaná metadata v souborech .rlib některým balíčkům chyběla u vnořených modulů, takže se nepodařilo dohledat závislosti. Testy na to nenarazily, protože počítaly s plošší strukturou modulů – objevilo se to až na reálném kódu jádra a vyvolalo přepracování celého zpracování metadat.

Kde to dnes stojí

Gccrs dnes umí přeložit samostatné programy bez závislosti na core (no_core) a zvládá zpracovat kód balíčku core i většinu jádra po syntaktické stránce. Skutečné spuštění jádra je ale pořád daleko – ukazují to nulová procenta u maker, uapi a hlavních souborů jádra ve vlastním přehledu projektu. Letos začali přispívat i dva účastníci Google Summer of Code (Enes Çevik na balíčku alloc, Janet Chien na destruktorech) a stážista Zhi Heng, který se věnuje testům na kódu jádra a průběžné integraci.

Slabinou dlouho bylo prosazování změn do hlavního stromu GCC – rozsáhlé záplaty jako přepis jmenných prostorů narážely na omezenou kapacitu recenzentů. Podle LWN se to zlepšilo poté, co dva vývojáři gccrs dostali status správců GCC a mohou si změny připravovat ve vlastní větvi a slučovat je hromadně. Patry a Arthur Cohen mají letos přednášku „Compiling the Linux kernel with gccrs“ na RustConf v Montrealu a na EuroRust v Barceloně.

Výčet opravených chyb by mohl budit dojem, že má jádro k překladu blízko – čísla z vlastního přehledu gccrs ale ukazují, že klíčové části pro jeho spuštění jsou pořád na nule. Chyby, na které tým narazil (špatný jmenný prostor, chybějící destruktory, děravá metadata), jsou přesně ten druh problémů, který se v malých testech neprojeví a vyleze až na reálném kódu.

Zdroje

• Progress toward compiling Linux with gccrs, LWN.net, 28. července 2026
• May 2026 Monthly report, gccrs (Rust-GCC)
• February 2026 Monthly report, gccrs (Rust-GCC)
• Rust-GCC/gccrs, GitHub

Když se dvě černé díry po dlouhém vzájemném obíhání konečně srazí, vznikne jedna z nejenergetičtějších událostí ve vesmíru. Uvolní se při ní gravitační vlny – vlnění samotného prostoročasu –, které jdou zachytit citlivými přístroji na Zemi i miliardy světelných let od zdroje. Přesně spočítat hmotnost a rotaci výsledné černé díry, takzvaného pozůstatku, ale dosud vyžadovalo superpočítač řešící soustavu Einsteinových rovnic obecné relativity. Tým fyziků vedený Penn State ukázal, že existuje i jednodušší cesta – přes obyčejnou termodynamiku.

Práci Maximum Entropy Conjecture for Black Hole Mergers zveřejnil časopis Physical Review Letters, kde ji redakce označila jako „editor’s suggestion“. Univerzita ji oznámila 7. července 2026.

Entropie jako v pokoji plném věcí

„Výsledná černá díra po srážce ještě chvíli zvoní jako úderem rozhoupaný zvon a vyzařuje gravitační vlny, dokud se neustálí ve stavu, který popisují jen dvě čísla – konečná hmotnost a rotace,“ popsala první autorka práce Monica Rincon-Ramirez, postdoktorandka na Penn State. „Ptali jsme se, jestli se dá ten konečný stav odhadnout z termodynamiky.“

Termodynamika popisuje chování soustav s mnoha částicemi – plynů v motoru, atmosféry i obyčejného vaření – pomocí několika souhrnných veličin jako energie nebo entropie. Entropie je míra neuspořádanosti, přesněji počet způsobů, jak lze prvky soustavy uspořádat. „Neuklizený pokoj má vysokou entropii, protože věci v něm lze rozházet spoustou způsobů. Uklizený pokoj má entropii nízkou, protože za 'uklizené' se počítá jen pár uspořádání,“ vysvětlila spoluautorka Vaishak Prasad, postdoktorandka v oboru astronomie a astrofyziky na Penn State. Příroda podle ní směřuje k vyšší entropii jednoduše proto, že takových stavů je víc.

Sled hypotetických černých děr

Než Stephen Hawking v 70. letech 20. století ukázal, že černé díry mohou vyzařovat energii, patřily mimo dosah termodynamiky úplně. Poté fyzici objevili paralelu mezi vlastnostmi černých děr a plynů – zrodila se takzvaná Bekensteinova–Hawkingova entropie. Ta se ale dosud vztahovala na jednotlivou, ustálenou černou díru, ne na dvě tělesa uprostřed srážky.

Tým spočítal, kolik hmotnosti (energie) a momentu hybnosti soustava během srážky ztrácí vyzářením gravitačních vln, a zbylé hodnoty v každém okamžiku přiřadil hypotetické rotující černé díře podle Kerrova řešení Einsteinových rovnic. Entropie takové hypotetické posloupnosti děr má během vývoje srážky maximum – a to leží nápadně blízko hmotnosti a rotace, kterou pro skutečný pozůstatek předpovídají přesné simulace numerické relativity. Shoda vychází na jednotky procent, ať autoři vycházeli z postnewtonovských výpočtů, nebo přímo z dat numerické relativity.

Zatím jen pro jednodušší srážky

Výpočet zatím platí pro srážky na téměř kruhových drahách, ve kterých ani jedna z obou původních děr sama nerotuje – tedy pro nejjednodušší, ne pro obecný případ. Autoři sami v práci popisují postup jako poněkud ad hoc a mluví o domněnce, ne o odvozeném zákonu: shoda s numerickou relativitou je nápadná, ale proč funguje, se ze samotného výpočtu vyčíst nedá.

„Výsledná černá díra jako by po srážce zapomněla skoro všechno kromě své hmotnosti a rotace,“ shrnul vedoucí týmu B. S. Sathyaprakash, profesor fyziky a astrofyziky na Penn State. „Zjistili jsme, že to, co si přece jen pamatuje, jde nejpřirozeněji popsat termodynamickými pojmy.“ Podle něj práce otevírá otázku, jestli maximalizace entropie nemůže být obecnějším principem, který srážky černých děr řídí.

Kratší cesta k datům z detektorů

Pokud by se domněnka potvrdila i pro obecnější případy – rotující původní díry, výstřednější dráhy –, mohla by fyzikům zjednodušit interpretaci dat z gravitačních detektorů: místo běhu numerické simulace pro každou srážku zvlášť by šlo výsledný stav odhadnout přímo z entropie. Na výzkumu se kromě Rincon-Ramirez, Sathyaprakashe a Prasad podíleli Nathan K. Johnson-McDaniel z University of Mississippi, Eugenio Bianchi z Penn State a Ish Gupta z University of California v Berkeley. Výzkum financovala americká Národní vědecká nadace (NSF).

Zdroje

• Simplifying black hole mergers — the universe’s most violent phenomena, Penn State University, 7. července 2026
• Black hole mergers: Penn State physicists use simple thermodynamics to predict cosmic collisions, Open Access Government, 8. července 2026
• A Maximum Entropy Conjecture for Black Hole Mergers, arXiv:2601.22388

Kolik z původní kapacity baterie ojetému elektromobilu zbylo, se pozná těžko. Číslo na palubní desce si každý výrobce počítá po svém a kupující nemá s čím ho porovnat. Čína na to má od 1. července 2026 národní normu GB/T 46991.1-2025: zavádí jediný ukazatel stárnutí, mez jeho přesnosti a spodní hranice, pod které nemá baterie po pěti, osmi a deseti letech klesnout. Podrobnosti k ní zveřejnila 2. srpna čínská státní televize.

Jeden ukazatel místo procent od výrobce

Ukazatel se jmenuje SOCE. Je to podíl energie, kterou baterie ve voze dokáže vydat, k energii, kterou vydala jako nová; udává se v procentech. Od SOC, tedy stavu nabití, se liší tím, co měří: SOC říká, kolik energie je v baterii právě teď, SOCE kolik z původní zásoby jí za léta zbylo.

Norma žádá, aby výrobce SOCE ukázal zákazníkovi – na přístrojích ve voze nebo v mobilní aplikaci – a hlavně určuje, jak přesné to číslo musí být. Mezi hodnotou na displeji a hodnotou naměřenou smí být rozdíl nejvýš pět procent.

Virtuální kilometry za stání

Druhá část normy míří na energii, která z baterie odteče, aniž se auto hne: dodávka proudu do sítě nebo do spotřebiče, pohon nástavby, klimatizace při stání. Taková spotřeba se přepočte podle spotřeby vozu na „virtuální kilometry“ a připočte se k najetým. Odchylka mezi zobrazenou a naměřenou hodnotou tu smí být nejvýš tři procenta. Účelem je podle výkladu normy to, aby se vozy s takovými funkcemi daly posuzovat stejně jako ostatní.

Kam až smí baterie klesnout

Spodní meze SOCE jsou tři a rozhoduje u nich, co nastane dřív – roky, nebo kilometry:

• po 5 letech nebo 100 000 km nejméně 82 %,
• po 8 letech nebo 160 000 km nejméně 75 %,
• po 10 letech nebo 200 000 km nejméně 70 %.

Plnění se ověřuje na vzorku: úřad odebere určitý počet vozů a mez je splněná, když jí vyhoví devět z deseti.

Ta procenta pocházejí ze zprávy státní televize, kterou přejal server CarNewsChina. Výklad normy na stránkách střediska CATARC, které ji vedlo, čísla neuvádí a od přejatých zpráv se liší i v rozsahu: mluví o mezích zvlášť pro lehká osobní a lehká užitková vozidla, kdežto přejaté zprávy o samotných lehkých osobních.

Přísnější čísla než v Evropě, slabší vymáhání

Evropa má vlastní meze v nařízení (EU) 2024/1257, tedy v Euru 7. Jeho příloha VII žádá u osobních vozů třídy M1 nejméně 80 % do pěti let nebo 100 000 km a 72 % do osmi let nebo 160 000 km; u lehkých užitkových vozů třídy N1 je to 75 % a 67 %. Třetí bod po deseti letech v Euru 7 není. Na nové typy vozů M1 a N1 se to začne vztahovat 29. listopadu 2026, na všechny nově prodávané vozy těch tříd o rok později.

Čínské meze jsou tedy v prvních dvou bodech přísnější a přidávají třetí. CATARC to ve svém výkladu uvádí jako náskok před mezinárodním předpisem; Čína přitom spoluvedla přípravu celosvětového předpisu OSN o životnosti baterií v lehkých vozech, označeného GTR č. 22.

Váha obou dokumentů je ale jiná. Čínská norma je typu GB/T, tedy doporučená, ne závazná jako typ GB. Nemá zveřejněné pokuty, svolávací akce ani jiný postih za překročení odchylky; podle serveru electrive riskuje výrobce, který se doporučení ministerstva průmyslu nedrží, spíš horší postavení u státních dotací a flotilových zakázek. Euro 7 je naopak součástí schvalování typu, bez kterého se vůz v Evropské unii neprodá.

Kdo normu psal

Podle výkladu CATARC normu od roku 2022 připravovala skupina víc než dvaceti domácích i zahraničních výrobců aut, dodavatelů dílů a zkušeben. V záznamu normy jsou mimo jiné BYD, CATL, Geely, Chery, Great Wall, NIO a SAIC-GM-Wuling – a také čínské pobočky Toyoty, Volkswagenu, Mercedesu-Benz a BMW. Skupinu vedl Jü Jang.

Důvod, proč norma vznikla, popisuje výklad CATARC věcně: dosavadní norma GB/T 31484-2015 měří životnost baterie v laboratoři, tedy počtem cyklů, což se s poklesem dojezdu v běžném provozu nekryje, protože baterie stárne i časem. Čínská pravidla pro reklamace přitom po prodejci žádají, aby mez poklesu baterie uvedl, ale neříkají, čím se má měřit.

Pro kupujícího ojetého elektromobilu je podstatné hlavně to, že vznikl údaj, který jde porovnat mezi značkami a ověřit měřením. Jestli se podle něj bude obchodovat, se pozná na výkupních cenách a na tom, kolik výrobců ho do vozů opravdu dá – doporučená norma je k tomu nenutí.

Odběr elektřiny v soustavě, kterou pro většinu Texasu řídí Electric Reliability Council of Texas (ERCOT), překonal 22. července 2026 dosavadní maximum o šest procent. Americký úřad pro energetické informace EIA to oznámil 3. srpna: hodinová špička dosáhla 91,1 GW a přišla v šest hodin odpoledne středního času.

Zajímavější než samotné číslo je to, co je kolem něj. Rekord padl během jediné vlny veder dvakrát, prameny se v jeho výši liší o víc než dvě stě megawattů a soustava ho zvládla bez jediné výzvy k šetření.

V úterý rekord, ve středu znovu

Server Renewable Energy World popsal průběh toho týdne už 23. července. V úterý 21. července zaznamenal ERCOT odběr 87 403 MW, čímž spadlo dosavadní maximum 85 508 MW ze srpna 2023. Vydrželo necelý den: ve středu 22. července šla zátěž na 91 308 MW.

Teploty v Texasu ten týden přesáhly sto stupňů Fahrenheita, tedy zhruba 38 °C. EIA k tomu dodává, že rekord může letos padnout ještě jednou, přijde-li další vedro.

O kolik přesně, na tom se prameny neshodnou

Pro tentýž den kolují tři čísla. EIA uvádí 91,1 GW, texaská televize KXII 91 089 MW a Renewable Energy World spolu s houstonským serverem Chron 91 308 MW.

Mezi krajními hodnotami je rozdíl 219 MW, tedy necelá čtvrtina procenta. Vysvětlení nejspíš vězí v tom, jak se odběr měří. Údaj EIA pochází z hlášení EIA-930, celým jménem Hourly and Daily Balancing Authority Operations Report; provozovatelé soustav v něm posílají odběr po hodinách. Vyšší číslo připisuje Renewable Energy World serveru gridstatus.io a k tomu, z jak dlouhého intervalu vzešlo, se nevyjadřuje.

Obě letošní hodnoty jsou navíc zatím předběžné: ERCOT potvrzuje špičku až podle zúčtovacích dat trhu. Jak to dopadá, ukazuje starší případ. V srpnu 2024 ohlásil ERCOT předběžnou špičku 85 559 MW, letošní zdroje ale shodně píšou, že padl rekord 85 508 MW ze srpna 2023. Proč se číslo z roku 2024 mezi maxima nepočítá, nevysvětluje ani jeden z nich.

Vrchol pokryl plyn se sluncem, večer baterie

Podle dat, která EIA dostala, kryl vrchol ze 48 % zemní plyn a z 32 % slunce. Špička přišla v šest večer, tedy v době, kdy výroba z fotovoltaiky už klesá.

Tomu odpovídají další maxima téhož týdne, která uvádí Renewable Energy World: nejvyšší výroba ze slunce 34 665 MW, nejvyšší čistá zátěž 75 733 MW a nejvyšší současný výdej z baterií 11 980 MW. Čistá zátěž je odběr po odečtení výroby z větru a slunce; právě ona říká, kolik musí pokrýt zdroje, které jde řídit.

Doug Lewin, kterého tentýž server cituje, k tomu připomněl, že při předchozím pětiminutovém rekordu odběru měl Texas v provozu necelé 4 000 MW baterií. Letos to bylo skoro 12 000 MW.

Proč to soustava unesla

ERCOT ještě před sezonou odhadoval, že odběr může v létě přesáhnout 92 GW; důvodem měla být vedra a nové velké odběry, mezi nimi datová centra. V měsících před tím odhadem připojil zhruba 11 GW nových zdrojů.

Zázemí pro to Texas buduje od zimní bouře v roce 2021. Podle sdružení SEIA, které Renewable Energy World cituje, má stát nainstalováno 53 568 MW fotovoltaiky počítaných na stejnosměrné straně panelů a úložiště o kapacitě 29 163 MWh.

Nikdo nemusel šetřit

ERCOT během rekordního týdne nevyhlásil stav nouze ani nepožádal odběratele, aby omezili spotřebu. V létě a na podzim 2023, tedy v sezoně, ve které padl předchozí rekord, k tomu vyzval jedenáctkrát.

Chron staví letošní špičku vedle února 2021, kdy bouře Uri shodila texaskou soustavu a miliony domácností zůstaly bez proudu. Tehdejší odběr vystoupal zhruba na 69 222 MW; letošní špička je proti němu o 32 % vyšší. Srovnávat to jde ale jen tím číslem: v roce 2021 nešlo o rekordní poptávku, ale o výrobu, která v mrazu vypadla.

Rekordy nejsou jen texaské

EIA v téže zprávě uvádí, že odběr v soustavě Southwest Power Pool dosáhl 27. července v pět odpoledne středního času rekordních 57,9 GW. A z toho vyvozuje obecnější závěr: tam, kde roste spotřeba i výroba, budou období vysokého odběru překonávat maxima dál.

Zdroje: EIA, Today in Energy, 3. srpna 2026; Renewable Energy World, 23. července 2026; Chron; KXII; Utility Dive, srpen 2024.

CERN staví nad zemí kus svého budoucího urychlovače nanečisto. Sestava se jmenuje IT String, kopíruje úsek, který má jednou být pod zemí vedle experimentu CMS, a 8. července na ní nové kvadrupólové magnety dostaly jmenovitý provozní proud 16 230 ampérů. Laboratoř to oznámila 21. července 2026. Magnety mají u míst srážek stlačit svazky protonů těsněji než dosud, a tím zvýšit počet srážek; modernizovaný urychlovač HiLumi LHC má podle CERNu začít fungovat v roce 2030.

Otvor se zvětšil víc než dvakrát

Dnešní zaostřovací magnety v LHC mají cívky z niobu a titanu. Nové jsou ze sloučeniny niobu a cínu, Nb₃Sn, a proti současným se liší ve dvou číslech. Otvor pro svazek vzrostl ze 70 na 150 milimetrů a pole, ve kterém magnety pracují, má 11,3 tesla. To je podle CERNu asi o 35 % víc, než zvládá dnešní generace těchhle magnetů. Nové kusy mají přijít po obou stranách experimentů ATLAS a CMS.

Niob s cínem snese vyšší proud, jenže se s ním podle Fermilabu hůř pracuje: supravodivým se stane až po tepelném zpracování za vysoké teploty a po něm je křehký.

Trénink a paměť magnetu

Čerstvě vyrobený supravodivý magnet se nedá zapnout naplno hned. Prochází tréninkem: proud se zvyšuje v několika cyklech po sobě a magnet přitom obvykle několikrát přejde ze supravodivého stavu do normálního. Tomu přechodu se říká quench. První výpadky přicházejí ještě pod jmenovitým proudem a spouštějí je drobné mechanické nestability uvnitř cívky; opakovanými cykly se cívka i její nosná konstrukce srovnají se silami, které na ně působí, a dosažitelný proud roste. Trénuje se na samostatných stolicích, ještě než magnet zamíří do urychlovače.

Nové kvadrupóly došly na jmenovitý proud bez jediného takového výpadku. CERN to čte jako doklad, že si magnety podržely trénink z dřívějších samostatných zkoušek. Té schopnosti se v oboru říká paměť.

„Dobrá paměť je u urychlovačových magnetů klíčový požadavek, protože zkracuje dobu uvádění do provozu, spotřebu chladiva i provozní prodlevy,“ říká Susana Izquierdo Bermudez, která v CERNu vede pracoviště velkých magnetů. (přeloženo)

Zbylých šestnáct okruhů

Kvadrupóly jsou jen část sestavy. IT String má sedmnáct elektrických okruhů a všechny se podle CERNu podařilo napájet na provozní proudy. Oddělovací dipól, který má po srážce rozvést oba svazky od sebe, se na jmenovitý proud dostal až po několika tréninkových výpadcích. Korekční magnety došly na cílové proudy samostatně i při společném provozu; ty jsou z niobu a titanu, tedy ze stejného materiálu jako dnešní magnety LHC.

Energii uloženou v magnetech odvádí při potížích ochranná soustava do lázně helia, které je drží na 1,9 kelvinu, tedy −271 °C. Během zkoušek takhle bezpečně odvedla a rozptýlila až 38 megajoulů.

Kolik je „o polovinu víc“

Údaj o tom, oč jsou nové cívky lepší, vypadá ve dvou pramenech jinak. CERN píše o 35 % proti dnešní generaci zaostřovacích magnetů. Giorgio Apollinari, ředitel amerického projektu HL-LHC Accelerator Upgrade Project, řekl v srpnu 2025 Fermilabu, že niob s titanem zvládne v urychlovači pole do 8 tesla a niob s cínem zhruba o polovinu víc. Obě čísla mohou platit zároveň: jedno srovnává dva hotové magnety, druhé možnosti materiálu.

Ze stejného rozhovoru pochází i tvrzení, že jde o první nasazení niobu s cínem v urychlovači vůbec. Apollinari to říká o technologii jako takové, ne o jednom magnetu.

Čtyři kusy přišly z Ameriky

Ne všechny kvadrupóly v sestavě vznikly v CERNu. Americký projekt AUP, na kterém se podílejí laboratoře Fermilab, Brookhaven a Lawrence Berkeley, jich čtyři vyrobil, odzkoušel a v roce 2025 poslal do CERNu; každý váží 25 tun. Marta Bajko, která zkušební sestavu vede, je tehdy označila za poslední díl skládačky. Na modernizaci se podle únorové tiskové zprávy Fermilabu podílí bezmála padesát institucí z více než dvaceti zemí, převážně evropských.

V září znovu

Napájením všech okruhů skončila fáze, ve které se technika uváděla do provozu. „Kampaň vydala obrovské množství dat, která teď rozebíráme, abychom lépe pochopili, jak spolu všechny soustavy fungují,“ uvedl Samer Yammine, který má provoz IT String na starost (přeloženo). Rozbor se týká magnetů, soustavy chlazeného napájení, měničů, detekce a ochrany proti quenchi, kryogeniky, vakua, řízení i ustavení.

Sestavu čeká ještě série cílených zkoušek, pak se ohřeje na pokojovou teplotu a znovu zchladí. Druhá provozní kampaň má být v září a podle Bajko se zaměří na ověření postupů a nástrojů pro rozbor dat a na to, že se výkon celé sestavy dá zopakovat. Ta sestava je zkušebna nad zemí; má napovědět, jak se bude chovat to, co se do tunelu jednou složí doopravdy.

Zdroje

• HiLumi LHC: new magnets reach full power, CERN, 21. července 2026
• HiLumi LHC: full-scale tests start, Fermilab, únor 2026
• Fermilab technology debuts in supercollider dress rehearsal at CERN, Fermilab, 14. srpna 2025

GCC je sada překladačů projektu GNU; vedle jazyků C a C++ jich zvládá dalších deset, od Fortranu přes Adu a Go po Rust. Jeho řídicí výbor oznámil 29. července 2026, že přijal doporučení pracovní skupiny a projekt má od té chvíle pravidla pro příspěvky, na kterých se podílel jazykový model. Celé znění je na stránce ai-policy.html.

Hranice je v cizím dokumentu, ne v pravidlech samotných

Nosná věta zní, že projekt zatím odmítne každý „právně významný“ příspěvek, který obsahuje výstup jazykového modelu nebo je z takového výstupu odvozený. Co je právně významné, si pravidla nedefinují – přebírají to z pokynů pro správce balíků GNU. Tam stojí, že hranice leží kolem patnácti řádků kódu nebo textu; pod ní podle nadace nevzniká potřeba řešit práva zvlášť.

Týž dokument ale dodává něco, co se v přehledech obvykle ztratí. Nepočítá se jedna záplata, počítá se souhrn všeho, co daný člověk projektu poslal, a nezáleží na tom, kdy jednotlivé kusy poslal. Kdo tedy pošle desetkrát pět řádků od modelu, hranici překročí, i když ji jednotlivou záplatou nepřekročil ani jednou.

Testovací sady jsou výslovná výjimka

Jedinou výjimku dělají pravidla opačným směrem, než by se čekalo: právně významný příspěvek do testovacích sad smí správce přijmout, i když ho model vyrobil celý. Menší příspěvky projít můžou taky, ale musí splnit obvyklé podmínky a být zřetelně označené. Mimo pravidla stojí kód, který GCC jen přebírá odjinud a spravuje ho někdo jiný; jmenován je knihovní balík libsanitizer.

Podepsat se smí jen člověk

Druhá polovina textu je o stopě, kterou to nechá v historii. Zpráva u commitu, který nese obsah od modelu, musí obsahovat značku Assisted-by:. Příspěvek musí poslat člověk, který změně rozumí a umí na dotazy k ní odpovědět, a rozhodnout o jejím přijetí musí zase člověk. Značku Signed-off-by:, tedy potvrzení Developer Certificate of Origin, smí připojit jedině člověk a model nesmí do repozitáře commitovat vůbec.

Má to praktický důvod. GCC nabízí přispěvatelům dvě cesty, jak vyřešit práva k většímu příspěvku: buď je postoupí Nadaci pro svobodný software, nebo se pod něj podepíšou právě tou značkou. Obojí stojí na tom, že se konkrétní člověk zaručí za původ kódu – a u textu, který vypadl z modelu, se za původ zaručit nedá.

Co pravidla nezakazují

V tomhle je text nezvykle konkrétní. Rešerše, rozbor, hledání a hlášení chyb, revize záplat i ladění modelem jsou v pořádku, dokud jeho výstup neskončí v příspěvku. U hlášení chyb je připsaná podmínka, že se výstup neposílá doslova bez rozmyslu, a u revize, že model lidskou revizi doplňuje, ne nahrazuje.

Stranou stojí i osobní nástroje: čtečka obrazovky, převod textu na řeč, překlad, kontrola pravopisu a gramatiky. Jedinou podmínkou je, že si přispěvatel jejich výstup ověří.

Napsané tak, aby to šlo opsat

Pravidla připravila pracovní skupina vedená Jonathanem Wakelym a oznámení jmenuje dalších sedm lidí, kteří v ní byli. Text je označený licencí CC0 1.0, tedy vzdáním se práv – jiný projekt si ho může vzít a použít, aniž by se koho ptal. Výbor zároveň píše, že se pravidla budou vyvíjet; nejzazší termín revize dává na začátek roku 2027.

Slabým místem je vymahatelnost a diskuse pod zprávou o pravidlech na LWN se točila hlavně kolem ní: pravidlo, které se nedá ověřit, podle jedněch trestá poctivé a vyrábí tiché obcházení. Proti tomu tam zaznělo, že řada přispěvatelů ho dodrží prostě proto, že si projektu váží. Pravidla ten spor neřeší a ani se o to nepokoušejí – jejich úplně první oddíl místo toho žádá, aby se s přispěvatelem, který je ještě nezná, jednalo vlídně.

Podobným směrem šly v posledních týdnech i jiné projekty: Codeberg zakázal projekty psané převážně modely a GNOME naopak sepsal pravidla pro rozšíření, která modely generují.

Náš názor: měřitelný dopad bude mít nejspíš značka Assisted-by:. Je to jediná část pravidel, po které v repozitáři zůstane něco, co jde spočítat – u zbytku se projekt spoléhá na to, že mu přispěvatelé řeknou pravdu.

Zdroje

• AI Policy projektu GCC, gcc.gnu.org
• GCC AI Policy Announcement, archiv konference gcc@gcc.gnu.org, 29. července 2026
• Legally Significant Changes, Information for Maintainers of GNU Software
• Contributing to GCC, oddíl Legal Prerequisites
• GCC steering committee announces AI policy, LWN.net, 29. července 2026

Protokol BGP drží internet pohromadě: jednotlivé sítě si jím oznamují, přes koho se dostanou k cizím adresám. Patnáct let se jeho zabezpečení točí kolem jediné otázky – je ten, kdo adresní rozsah ohlašuje, opravdu jeho držitel? Odpovídá na ni RPKI, tedy podepsaná evidence, kdo smí co ohlašovat. Přehledová práce, kterou v časopise IEEE Communications Surveys & Tutorials vydali autoři z římské Sapienzy, z propojovacího uzlu Namex a z italské agentury pro kybernetickou bezpečnost ACN, ukazuje, kolik problému za tou otázkou zůstává.

Vadný atribut, který v květnu 2025 shodil spojení

V úterý 20. května 2025 v 7 hodin UTC se globálním směrováním rozešla jedna zpráva BGP. Nešlo o únos rozsahu ani o únik trasy: byla to obyčejná aktualizace pro jeden blok /16, jenže nesla navíc atribut Prefix-SID podle RFC 8669, který do vnějšího BGP zpravidla nepatří, a k tomu měl celý vnitřek vynulovaný.

Směrovače Cisco IOS-XR a Nokia SR-OS udělaly to, co předepisuje RFC 7606 o snášenlivosti k vadným zprávám: poškozený atribut zahodily a jely dál. JunOS od Juniperu zprávu poslal beze změny dál a zařízení Arista, která ji od něj dostala, na ni odpověděla shozením celého spojení BGP. Protože přenosové sítě jedou z velké části na Juniperu, ztratily zákaznické sítě s Aristou přístup k internetu, podle rozboru Bena Cartwrighta-Coxe nejspíš až na deset minut. Směrovací servery na propojovacích uzlech běží obvykle na démonu BIRD, který atribut Prefix-SID nezná, takže ho nefiltrovaly a rozeslaly dál.

Cartwright-Cox, který incident rozebral z archivu služby bgp.tools, napočítal kolem stovky zasažených sítí; jmenovitě uvádí mimo jiné Starlink, Zscaler, ByteDance a Disney. Jeho sběrač zpráv přijímá běžně 20 000 až 30 000 zpráv za vteřinu, během příhody to bylo v desetivteřinovém průměru přes 150 000 za vteřinu. Přehledová práce totéž číslo uvádí jako víc než 150 000 aktualizací, které během deseti vteřin viděla celá směrovací soustava; to je jiná veličina než tempo na jednom sběrači.

Podstatné je, že po celou dobu nebylo porušeno nic z toho, co RPKI ověřuje. Arista podle přehledové práce chování změnila ve vydání EOS 4.28.11 a novějších.

Osm tříd v jedné tabulce

Z toho místa práce vychází. Rozděluje útoky na směrování do čtyř nadřazených skupin, uvnitř kterých autoři rozlišují osm tříd. Do manipulace s trasou patří únos předpony a úprava cesty AS_PATH. Konzistence směrování pokrývá nestabilitu tabulky a zbytečné drobení předpon. Porušení pravidel obsahuje úniky tras ve čtyřech směrech podle RFC 7908 a ohýbání vlastních pravidel přes Local Preference, MED nebo délku cesty. Poslední skupina je shození relace vadným atributem – přesně to, co se stalo v květnu 2025.

Autoři sami píšou, že nové druhy útoků neobjevili; většina rozdílů už v RFC i v provozní praxi je. Přínosem má být jednotné pojmenování, díky kterému jde ke každé třídě přiřadit obranu.

Kde ochrana opravdu je

Únos předpony je úspěch s výhradami. Pokrytí objekty ROA roste, jenže pokrytí není vynucování: měření, které práce cituje, sáhlo na více než 28 000 autonomních systémů a ukázalo, že 36,2 % z nich neověřuje původ trasy vůbec a jen 12,3 % má plnou ochranu. Benevolentně nastavený parametr maxLength navíc útočnou plochu spíš rozšiřuje, kvůli čemuž vzniklo RFC 9319.

Ověřování celé cesty řeší BGPsec. Existuje, je naprogramované a prakticky nikde nasazené – jediný účastník na trase, který ho neumí, z ohlášení bezpečnostní údaje odstraní, takže částečné nasazení nemá skoro cenu.

Nejvíc se pohnuly úniky tras. Objekty ASPA jdou od prosince 2025 ukládat do repozitářů regionálních registrů a v době psaní práce jich bylo zapsaných 1 314. Podle rozboru, o který se práce opírá, by nasazení u vhodně umístěných sítí srazilo počet zasažených autonomních systémů až o 96 %. Atribut OTC a komunita Down Only, obojí postavené na rolích z RFC 9234, by při výběrovém nasazení u dobře propojených sítí prvního a druhého řádu potlačily přes 98 % víceskokových úniků.

Zbylé čtyři třídy – nestabilita tabulky, drobení předpon, ohýbání pravidel a shození relace atributem – nemají kryptografickou odpověď žádnou. Ne částečně nasazenou: žádnou. Brání se proti nim limitem na počet předpon, filtrem na délku předpony, omezením zátěže řídicí roviny a filtrováním atributů na směrovacích serverech. Všechno to je místní, reaktivní a ten, koho útok postihne, si to nemá jak ověřit. Poctivá odpověď na otázku, jestli je síť chráněná proti záplavě rozdrobených předpon od souseda, podle autorů zní: „máte limit na počet předpon a naději“ (přeloženo z angličtiny).

Proč nepokryté třídy váží víc než dřív

Rizika posunuly dvě věci. První je aritmetika IPv6. Drobení předpon je v IPv4 omezené tím, co útočník opravdu drží; v IPv6 ne. Z jediného bloku /29 lze vytvořit až 524 288 samostatných bloků /48. Globální směrovací tabulka IPv6 měla podle práce kolem 219 000 záznamů, takže jediné přidělení a jediný směrovač ji můžou víc než zdvojnásobit. Obranou je pevně nastavený strop na počet předpon, jenže ten při přísném nastavení zadusí i legitimní růst – proto ho správci nastavují volně.

Druhá věc je posun pozornosti. Čím víc sítí ověřování původu vynucuje, tím menší je výnos z únosu předpony a tím větší z tříd, které nikdo neověřuje.

Nasaditelné poráží dokonalé

Práce z patnácti let vyvozuje, že návrhy S-BGP, soBGP a psBGP nabízely silnější záruky než cokoli dnes používaného a nedostaly se nikam, kdežto RPKI, evidence IRR a nově ASPA se ujaly, protože je lze zavádět po částech. Náklady přitom nese každá síť sama, zatímco užitek je společný; to je klasický problém kolektivního jednání a podle autorů důvod, proč dobře navržené mechanismy uvíznou. Institucionální páky jako směrnice NIS2 nebo návrh Digital Networks Act tu podle nich hrají roli, jejich účinek ale závisí na vymáhání, které je stát od státu jiné.

Nejméně jistí jsou autoři hranicí mezi útokem a nehodou. Skoro každá příhoda z těch čtyř nepokrytých tříd má po ruce nevinné vysvětlení – špatně nastavené přerozdělení tras, skript, který se pustil dvakrát, chyba výrobce. Právě proto se ty třídy zkoumají málo: kolem událostí, které nejdou nikomu připsat, se těžko staví model hrozby. Sami připouštějí, že riziko můžou přeceňovat, a v článku na RIPE Labs vyzvali správce sítí, ať je opraví.

Práce „Survey on Internet Routing Security: Stakeholder Interests, Current, and Future Research Directions“ vyšla otevřeně pod licencí CC BY 4.0 (DOI 10.1109/COMST.2026.3714569). Její shrnutí pro provozovatele sítí vydal jeden ze spoluautorů 21. července na RIPE Labs.

Provozovatel české přenosové soustavy ČEPS zveřejnil 24. července Hodnocení potřeb a potenciálu flexibility elektrizační soustavy České republiky, zkráceně FNA CZ 2026. Je to první dokument svého druhu a odpovídá na jedinou otázku: jestli bude česká soustava schopná pobrat výrobu, kterou do ní přivedou obnovitelné zdroje, a vyrovnat se s tím, jak rychle se ta výroba mění.

Flexibilita v téhle řeči neznamená pružnost obecně. Dokument ji definuje jako schopnost soustavy zvládat proměnlivost a nejistotu poptávky po elektřině, její nabídky i dostupnosti sítí. Zajišťují ji baterie a přečerpávací elektrárny, plynové zdroje, řízená spotřeba i dovoz a vývoz přes hranice.

Povinnost přišla z evropského nařízení

Analýzu si vynutil článek 19e nařízení o vnitřním trhu s elektřinou, který do textu z roku 2019 vložila novela z roku 2024. Ukládá určenému orgánu členského státu přijmout zprávu o odhadovaných potřebách flexibility nejpozději rok poté, co agentura ACER schválí metodiku, a pak každé dva roky. Metodiku ACER schválil 25. července 2025.

Zprávu v Česku přijímá Energetický regulační úřad. Tady se dva prameny drobně rozcházejí: ČEPS ve své tiskové zprávě uvádí, že hodnocení bylo přijato 1. července 2026, zatímco stránka ERÚ je datovaná 23. července s aktualizací o den později. Rozdíl je nejspíš mezi přijetím a zveřejněním, výslovně to ale neříká ani jeden z nich.

Scénář, ze kterého se počítalo

Výpočet nestojí na vlastních odhadech ČEPS, ale na referenčním scénáři evropského hodnocení zdrojové přiměřenosti ERAA 2025, které ACER schválil 24. dubna 2026. Model počítá dva cílové roky, 2030 a 2035, tři klimatické scénáře a patnáct simulací odstávek zdrojů.

Z instalovaných výkonů, se kterými scénář pracuje, je vidět, o jak velký přesun jde. Fotovoltaika roste z 9 999 MW v roce 2030 na 11 065 MW v roce 2035, vítr z 1 485 na 2 475 MW, baterie z 1 723 na 2 031 MW a plyn z 3 396 na 4 754 MW. Uhlí naopak z 932 MW klesá na nulu; model přitom už na rok 2028 indikuje odstavení zhruba 1,76 GW uhelné kapacity. Spotřeba má mezi oběma roky vzrůst z 69 na 74 TWh.

Dvě věci scénář neobsahuje. Dostavba Dukovan je podle dokumentu až za horizontem analýzy, malý modulární reaktor v něm naopak je, a to kolem roku 2035. Řízená spotřeba, tedy odezva na straně poptávky, je započítaná jen ve své přímé podobě, a to skromně: 150 MW v roce 2030 a 190 MW v roce 2035. Přesouvání spotřeby v čase model vynechává úplně kvůli nejistotě dalšího vývoje.

Výsledek: cíl splněn, nedostatek jen v opačném směru

Pokud se scénář naplní, bude Česko v letech 2030 i 2035 plnit požadovaný cíl pro integraci obnovitelných zdrojů. Podle metodiky tedy není nutné navrhovat rozvoj flexibility nad rámec toho, co scénář obsahuje. Dokument k tomu dodává, že další rozšiřování by přesto pomohlo: snížilo by objem výroby, kterou bude nutné omezit, případně by uneslo víc obnovitelných zdrojů, než scénář předpokládá.

Omezování výroby vychází soustředěné do jara a léta, od dubna do začátku října, do poledních a odpoledních hodin a hlavně na víkendy. Nejvíc ho model ukazuje v dubnu, a to kvůli kombinaci velikonočního volna, vyššího osvitu a nízkých teplot, kdy panely pracují s vyšší účinností a přitom se ani netopí, ani neklimatizuje.

Jediný skutečný nedostatek je v záporné obchodní flexibilitě, tedy ve schopnosti přebytek pohltit: zvýšit spotřebu, nabít baterie nebo elektřinu vyvézt. Objevuje se v řádu desítek hodin za rok v obou cílových letech. ČEPS jeho objem popisuje jako nižší desítky gigawatthodin a proti omezované výrobě, která se počítá v desetinách terawatthodiny, ho označuje za zanedbatelný. Nulový ale není a řešit se bude buď zápornými službami výkonové rovnováhy, nebo omezovacím plánem pro obnovitelné zdroje.

Dokument zároveň varuje před spoléháním na zahraničí. Dovoz a vývoz podle něj k flexibilitě přispívají výrazně, jenže právě v exponovaných hodinách nemusí být zahraniční zdroje ani přeshraniční kapacity k dispozici.

Bariéry a termíny, které z nich plynou

Druhá polovina dokumentu je systematický soupis toho, co rozvoj flexibility v Česku brzdí. Bariéry jsou rozdělené do čtyř oblastí, regulatorní, technické, ekonomické a spotřebitelsko-inovační, a ke každému doporučení je uvedený termín i odpovědný úřad.

Do roka má ERÚ dokončit inovaci tarifní struktury pro vysoké a velmi vysoké napětí, ministerstvo průmyslu a obchodu má nechat navrhnout opatření ke kybernetickým rizikům a spolu s ministerstvem pro místní rozvoj posoudit, kde jdou zkrátit procedury při stavbě energetické infrastruktury. Na jeden až tři roky připadá úprava klíče pro sdílení elektřiny, aktualizace vyhlášky o měření elektřiny a plné zprovoznění Elektroenergetického datového centra. Nad tři roky pak zbývá tarifní reforma na nízkém napětí, zavedení trhů s flexibilitou a koncepce, jak čelit obavám spotřebitelů z vysokých cen u tarifů se spotovou cenou, tedy takových, kde se platí podle burzovní ceny v danou hodinu.

Zpráva není konec, ale začátek lhůty

Sousední článek 19f téhož nařízení ukládá členskému státu, aby na základě téhle zprávy vymezil orientační vnitrostátní cíl pro nefosilní flexibilitu, včetně příspěvku řízené spotřeby a akumulace. Lhůta je šest měsíců od předložení zprávy. Od kterého z obou červencových dat se počítá, se z dostupných textů rozhodnout nedá.

„Flexibilita bude v příštích letech jedním z klíčových předpokladů bezpečného a spolehlivého provozu elektrizační soustavy,“ říká v tiskové zprávě Pavel Šolc, člen představenstva ČEPS zodpovědný za úsek Energetický obchod a strategie. Hodnocení se má aktualizovat každé dva roky; z toho vychází příští vydání na rok 2028 – tedy do roku, na který model umísťuje odstavení skoro dvou gigawattů uhlí.

Etoposid je cytostatikum ze seznamu základních léků Světové zdravotnické organizace, kde stojí v oddílu cytostatik. Podává se v první linii u malobuněčného karcinomu plic, příbuzný teniposid u leukémie a některých nádorů mozku. Obě látky se odvozují od podofylotoxinu a ten se dodnes získává z oddenků himálajské rostliny Sinopodophyllum hexandrum.

Tým kolem Capital Medical University v Pekingu a China Academy of Chinese Medical Sciences popsal 30. července v časopise Science postup, který tenhle článek dodavatelského řetězce nahrazuje kvasinkami. Práce vyšla pod DOI 10.1126/science.aef5438, prvním autorem je Siyu Shen.

Rostlina, která potřebuje pět let

Podle studie musí Sinopodophyllum hexandrum růst víc než pět let, než v oddencích nastřádá dost prekurzoru. Odběr autoři označují za ničivý; prekurzor je v oddencích, tedy v podzemní části rostliny. Dodavatelský řetězec proto podle nich zůstává křehký a závislý na klimatu.

Ochranu druhu je vidět i mimo studii. Mezinárodní úmluva o obchodu s ohroženými druhy vede rostlinu v seznamu CITES pod jménem Podophyllum hexandrum v příloze II, tedy mezi druhy, jejichž vývoz je vázaný na povolení. Jako oblast výskytu tam stojí Afghánistán, Bhútán, Čína, Indie, Nepál a Pákistán.

Z rostliny se izoluje podofylotoxin a z něj se lék dodělává chemicky. Autoři tuhle cestu popisují jako přes deset kroků s celkovým výtěžkem pod 20 %. Nejobtížnější je navěsit na molekulu cukr ve správné prostorové poloze – chemie na to podle autorů potřebuje nebezpečná činidla, katalyzátory z drahých kovů a zdlouhavé čištění.

Šedesát zásahů do genomu kvasinky

Skupina proto celou biosyntetickou dráhu přenesla do pekařských kvasinek Saccharomyces cerevisiae. Podle abstraktu k tomu bylo potřeba víc než 60 genetických zásahů a 45 cizích genů. Redakční shrnutí Michaela A. Funka k tomu dodává, že tým zvlášť upravil ve dvou modulech kvasinkový metabolismus aromatických aminokyselin, aby měla buňka dost výchozích látek.

Chybějícím dílem byla právě glykosylace. Autoři popisují glykosyltransferázu označenou UGT709AX1 a další enzymy z rodiny UDP-glukuronosyltransferáz, které chybějící cukerné kroky doplnily; navázání cukru v poloze C-4 se tím podle závěru studie přesunulo z chemické laboratoře do buňky. Výsledná platforma podle nich umí vyrobit dvanáct derivátů podofylotoxinu; tím hlavním je 4′-demethyl-epipodofylotoxin-4-O-glukosid, zkráceně 4′-DMEPI-4-O-Glc.

Poslední krok zůstal chemii

Z té látky vzniká hotový lék jediným mírným chemickým krokem. Výtěžek toho kroku uvádí studie u etoposidu 89 % a u teniposidu 65 %. Celý postup tak podle autorů stlačuje výrobu z víceletého pěstování rostliny do třídenní fermentace.

Slovo „chemoenzymatický“, které autoři používají, znamená přesně tohle rozdělení: obtížnou část s prostorovým uspořádáním obstará enzym v buňce, na chemika zbyde jediná reakce.

Kolik toho kvasinky vyrobí, ve veřejné části nestojí

Ani abstrakt, ani strukturované shrnutí neuvádějí, kolik prekurzoru buňka vyrobí na litr kultury. Plný text je na webu časopisu označený jako nepřístupný, takže tenhle údaj je pro čtenáře bez předplatného mimo dosah. Bez něj se nedá odhadnout, jestli je postup použitelný v provozu, nebo zatím jen v laboratoři – a u přestavěných kvasinek to bývá právě ten rozdíl, který rozhoduje. Studie také nikde netvrdí, že by takto vyrobený lék prošel kontrolou pro klinické použití.

Naše hodnocení: dokud číslo o výtěžnosti nepadne, je to doklad, že cesta existuje, ne že po ní půjde poslat výrobu.

Tabák to uměl už před jedenácti lety

Nápad sám není nový. Warren Lau a Elizabeth S. Sattely popsali v Science 11. září 2015 šest enzymů, které doplnily dráhu k aglykonu etoposidu, a přenesli ji do tabáku. Skončili ale u molekuly bez cukru, tedy před tím krokem, který dělá chemii největší potíže.

Co by muselo přijít dál, je zvětšení nádoby a čísla, která u fermentace rozhodují: gramy na litr, spotřeba cukru, čistota výstupu. Teprve podle nich se pozná, jestli oddenky z Himálaje někdo skutečně přestane vykopávat.

Zdroje

• Shen a kol.: Enabling sustainable supply of the essential cancer medicines etoposide and teniposide in yeast, Science 393 (6810), 30. 7. 2026
• Záznam téže práce v databázi PubMed
• Elektronický seznam základních léků Světové zdravotnické organizace
• Kontrolní seznam druhů CITES
• Lau, Sattely: Six enzymes from mayapple that complete the biosynthetic pathway to the etoposide aglycone, Science 349 (6253), 2015

Popruh, tedy úzká tkaná stuha, drží na palubě kdeco: pomůcky pro pohyb posádky, sítě proti odletu nákladu, ucha u vaků. Běžně se na ně používá nylon nebo meta-aramid. Pro lodě a stanoviště, se kterými NASA počítá u Měsíce a Marsu, tyhle materiály podle bulletinu TB 26-04 z 31. července nestačí. Důvod je v atmosféře, kterou tam mají posádky dýchat.

Proč má být v kabině víc kyslíku než ve vzduchu

Skafandr pro výstup ven má uvnitř mnohem nižší tlak než kabina. Kdo do něj přejde rovnou, riskuje dekompresní nemoc, a tak se před výstupem dýchá čistý kyslík, aby se z těla vyplavil dusík. Čím míň se kabina od skafandru liší, tím kratší to předdýchání je.

Recenzovaná práce v Frontiers in Physiology z roku 2025, která popisuje jedenáctidenní pobyty dobrovolníků v podtlakové komoře, uvádí zamýšlený stav pro program Artemis takto: v lodi nebo obytném modulu 8,2 psi a 34 % kyslíku (parciální tlak kyslíku ve vdechovaném vzduchu 128 mmHg), tedy v přepočtu zhruba 57 kPa. Předdýchání se tím zkrátí na asi dvacet minut. Při simulovaných výstupech v té komoře měl skafandr 4,3 psi, v přepočtu asi 30 kPa.

Kyslík navíc má ale druhou stránku. Bulletin ji shrnuje jednou větou: obohacená kyslíková atmosféra zvyšuje riziko hoření a s ním i nároky na ohnivzdorné materiály. Jak moc to svazuje ruce, je vidět na té komorové studii: třetí z jejích pobytů proběhl celý při 9,6 psi a 28,5 % kyslíku, protože NASA podle autorů chtěla prověřit i variantu pro programy a stroje, které se kvůli hořlavosti nad 30 % kyslíku snadno nedostanou.

Co obnáší zkouška hořlavosti

Popruhy prošly zkouškou číslo 1 podle normy NASA-STD-6001B, která se jmenuje šíření plamene vzhůru a metodicky vychází z normy ISO 14624-1:2003. Jedna zkouška znamená pět shodných vzorků. Materiál obstojí jen tehdy, když ani jeden z nich neshoří na délku větší než 15 cm a když ani z jednoho neodpadne hořící kus, který by zapálil papír položený pod vzorkem. Selhání jediného vzorku znamená selhání materiálu v daném prostředí.

Z toho se odvozuje číslo, které bulletin uvádí u každého popruhu: největší koncentrace kyslíku, při níž pětice vzorků ještě projde. Zkoušelo se ve White Sands Test Facility při tlaku 8,2 psia a v takzvané nestíněné konfiguraci J, kde je zapalovač namířený na plochu popruhu včetně jeho volného bočního okraje, zatímco střižená hrana plameni vystavená není.

Kevlar s polybenzimidazolem, a rozhoduje i barva

Zkoušeným materiálem byl popruh šířky jednoho palce, tedy 2,54 cm, tkaný ze 60 % kevlaru a 40 % polybenzimidazolu, který dodává firma Sturges Manufacturing. Táž tkanina ve dvou provedeních dopadla různě: nebarvená, zlatavá verze prošla až při 37 % kyslíku, černá při 35 %. Právě nebarvená verze proto splnila hodnotu, pro kterou se materiály v tomhle programu posuzují. U ní navíc proběhla i zkouška zplodin, které materiál uvolňuje do vzduchu. Podrobný protokol vede černá verze pod číslem WSTF 26-49145, nebarvená pod WSTF 26-49149.

Popruh se vyrábí v šířkách od čtvrt palce do osmi palců, tedy v přepočtu zhruba od 6 mm do 20 cm. Zkoušel se jen jednopalcový.

Jeden pruh látky ještě není hotový výrobek

Bulletin sám drží výsledek v mezích. Odolnost popruhu po opotřebení se nezkoušela vůbec. Výsledná hořlavost hotového dílu závisí i na ostatních součástech, takže se výrobek musí odzkoušet ve své konečné podobě; výsledek jednotlivé tkaniny za sestavu neručí. A hořlavost může posunout skoro každá odchylka od zkoušeného vzorku, včetně rozměrů, druhu vazby, tloušťky příze, hustoty, povrchových úprav, barvy, poměru vláken, způsobu začištění okraje nebo přišitého suchého zipu.

Dvě čísla, která se nepotkávají

Bulletin píše, že se materiály posuzují pro použití při 37 % kyslíku a tlaku 8,2 psia. Práce ve Frontiers in Physiology popisuje plánovanou atmosféru jako 8,2 psi a 34 % kyslíku. Tlak je stejný, podíl kyslíku ne. Proč se zkouší o tři procentní body výš, než kolik má být v kabině, bulletin neuvádí.

Popsaná práce je podle bulletinu první fází záměru, který má oboru dodat ověřené stavební kameny pro takzvané měkké vybavení, v originále softgoods. Postup vymyslelo středisko NESC, provádí ho kancelář marsovského programu a Johnsonovo vesmírné středisko a začíná se u textilií, které jdou koupit běžně. Co po téhle fázi následuje, v bulletinu nestojí.

Zdroje: technický bulletin NESC TB 26-04 na stránkách NASA (31. 7. 2026), norma NASA-STD-6001B se změnou 3 (standards.nasa.gov) a práce Crucian a kolektiv, Frontiers in Physiology 2025, doi 10.3389/fphys.2025.1637834.

Vláda 27. července schválila návrh novely zákona č. 56/2001 Sb., o podmínkách provozu vozidel na pozemních komunikacích. Materiál předložil ministr dopravy pod číslem jednacím 357/26 a v zápisu z jednání u něj stojí jediné slovo: schváleno. Zákonem se nestane dřív, než ho projedná Parlament.

Převod auta bez cesty na úřad

Jádro návrhu je přesun registračních agend na Portál dopravy. Ministerstvo dopravy v tiskové zprávě uvádí, že koupě a prodej auta byly loni nejčastějším úkonem: 1 223 130 případů. „Převod vozidla je jednou z nejčastějších věcí, kterou lidé s úřady řeší a poslední větší agenda, kterou máme ještě zdigitalizovat,“ říká v ní ministr dopravy Ivan Bednárik.

Osvědčení o registraci vozidla, tedy „malý techničák“, se podle návrhu nebude odevzdávat na úřadě. Nové doklady i tabulky se značkou si má být možné vyzvednout ve výdejním boxu nebo na výdejním místě, cesta na úřad zůstane jako druhá možnost. Staré doklady si pak majitel zlikviduje sám. Tisková zpráva Úřadu vlády k tomu přidává i doručení kurýrem; ve zprávě ministerstva o kurýrovi řeč není.

Část žádostí podaných přes portál se má vyřizovat zcela bez úředníka, konkrétně ty bez příloh. Ministerstvo dává za příklad třetí registrační značku na nosič kol, u níž loni napočítalo 57 715 případů: žádost o ni má jít rovnou do výroby.

Značka, která zůstane majiteli

Přenositelnost registrační značky zákon zná už dnes, ale v úzkém výřezu. Podle § 7c smí dosavadní vlastník nechat značku přidělit jinému svému vozidlu jen tehdy, jde-li o značku na přání podle § 7b, tedy o značku se zvolenou kombinací znaků. Běžná značka zůstává u auta.

Návrh to má rozšířit obecně: při prodeji vozidla, jeho vyřazení z provozu nebo ekologické likvidaci má mít vlastník právo na přidělení dosavadní značky k jinému vozu, který vlastní nebo provozuje. Ministerstvo se odvolává na Rakousko, Slovensko, Belgii a Švýcarsko. Mluví také o kombinaci na značce s rezervací až na šest měsíců od podání žádosti; § 7a dnes rezervaci značky váže na tři měsíce.

Depozit bez odevzdávání tabulek

Kdo dnes odstaví motorku na zimu, odveze na úřad malý techničák i obě tabulky. Ukládá mu to § 12 odst. 2 spolu se žádostí o vyřazení vozidla z provozu a § 12 odst. 8 pak popisuje, jak mu je úřad při zprovoznění vrátí. Z toho chce novela udělat dvě kliknutí, doklady i tabulky mají zůstat u provozovatele. Ministerstvo si od toho slibuje 157 668 ušetřených návštěv úřadu ročně.

Obdobně u zániku vozidla. Zápis se má provést automaticky podle údaje o ekologické likvidaci v informačním systému a doklady se značkami se mají zlikvidovat na vrakovišti spolu s autem; tady ministerstvo počítá se 197 689 ušetřenými návštěvami ročně. Bez žádosti se má obejít i vozidlo vedené jako odcizené nebo pohřešované, které se nově bude považovat za vyřazené z provozu. Obě tyhle automatizace se podle ministerstva můžou ročně dotknout víc než 190 tisíc osob.

Co je v návrhu ještě

Novela řeší i náhradní vyznačení identifikačního čísla vozidla v případech, kdy je VIN nečitelné nebo chybí. A mění rozsah údajů, které registr vydává přes internet: dostupné mají být nově i fotografie vozidel pořízené při jejich prohlídkách. Podle nás je to ta část návrhu, ze které bude mít kupující ojetého auta nejvíc, protože ostatní změny mu jen ušetří cestu na úřad.

Kdy by to mělo platit

Účinnost je rozložená do dvou termínů. Změny u registrace vozidel mají podle ministerstva platit od 1. července 2027, některé části až od 1. července 2028; důvodem je přebudování propojení informačních systémů několika resortů. Projednávání v Parlamentu ministerstvo čeká letos a příští rok. Do hlasování je to návrh, ne pravidlo.

Zdroje: tisková zpráva Ministerstva dopravy z 27. července 2026, výsledky jednání vlády z téhož dne a platné znění zákona č. 56/2001 Sb.

Vývojový tým PHP oznámil 30. července třetí alfu verze 8.6. Alfa je předběžné vydání pro zkoušení, oznámení u ní výslovně varuje, že do ostrého provozu nepatří. Zajímavá je tím, co se do ní dostalo: částečná aplikace funkcí, jejíž menší verzí byl zkrácený zápis odkazu na funkci z PHP 8.1.

Otazník místo argumentu

Částečná aplikace znamená, že se funkce zavolá jen s částí argumentů a zbytek se doplní později. Nový zápis to dělá dvěma značkami: otazník zastupuje právě jeden argument a tři tečky zbytek. Když je PHP ve volání najde, funkci nezavolá, ale vyrobí closure (anonymní funkci), jehož parametry odpovídají tomu, co zůstalo nedoplněné.

function stuff(int $i, string $s, float $f): string {}

// closure, které čeká jen na $s
$c = stuff(1, ?, 3.14);

// closure, které čeká na $s i $f
$d = stuff(1, ...);

Praktický smysl to má u zpětných volání. Návrh RFC to ukazuje na array_map(): místo anonymní funkce, ve které se musí ručně zopakovat všechny parametry i typy, se napíše volání s otazníkem na místě, kam přijde položka pole.

$result = array_map(str_replace('hello', 'hi', ?), $arr);

Co closure podědí z původní funkce

Z původní funkce se do vzniklého closure přenese jméno parametru, jeho typ, volitelnost, výchozí hodnota i to, jestli se předává odkazem. Z atributů ale jen dva: #[NoDiscard] a #[SensitiveParameter]. Návrh to zdůvodňuje tím, že oba mají přímý dopad za běhu, kdežto #[Deprecated] by ohlásil zastaralost dvakrát místo jednou a #[Override] na closure nedává smysl. U vlastních atributů PHP neví, jestli je kopírovat, takže je zahazuje.

Tím se nový zápis liší od zkráceného odkazu na funkci, který přidalo PHP 8.1 pod názvem first-class callable syntax. Ten si atributy nechává všechny, protože mezilehlé closure vůbec nevytváří, jen na funkci odkazuje. Návrh sám ho popisuje jako degenerovaný případ částečné aplikace: foo(...) je zápis, ve kterém se nedoplňuje nic.

V dodatku k návrhu stojí ještě jedna věc, kterou samotný text původně neuváděl. Closure dědí rozsah, ve kterém vzniklo, stejně jako každé jiné. Částečně použít se proto dá i soukromá metoda a výsledek se pak dá předat ven z třídy.

Od hlasování do alfy uplynulo necelých osm měsíců

Návrh nese jméno Partial Function Application (v2), podepsaní jsou pod ním Larry Garfield a Arnaud Le Blanc a je datovaný 3. června 2025. Je to druhý pokus: podle vlastních slov je v podstatě shodný s dřívějším návrhem téhož jména a zkrácený odkaz na funkci z PHP 8.1 z něj tehdy vznikl jako menší první krok.

Ke schválení bylo potřeba dvoutřetinové většiny; konec hlasování měl podle návrhu připadnout na 5. prosince 2025 ve 12 hodin světového času a dnes je uzavřené. Stav návrhu je dnes uvedený jako implementovaný a odkazuje na dva sloučené commity s poznámkou, že jsou v alfě 3. Mezi koncem hlasování a vydáním, ve kterém si zápis může někdo poprvé vyzkoušet, je tedy necelých osm měsíců.

Co dalšího do alfy přibylo

Poznámky k přechodu v souboru UPGRADING vypisují u 8.6 i řadu drobností. Funkce clamp() vrátí hodnotu, pokud je v zadaném rozsahu, a jinak nejbližší mez. Přibyl výčtový typ SortDirection, funkce grapheme_strrev() v rozšíření intl, ReflectionParameter::getDocComment() a mysqli::quote_string(). Větší kusy jsou tři: rozhraní pro polling, tedy dotazování na připravenost vstupu a výstupu (jmenný prostor Io\Poll), obnovení relace TLS u proudů a nové rozhraní pro chyby proudů. Opcache umí nově překlad za běhu i pro vláknově bezpečná sestavení (ZTS) na procesorech Apple Silicon.

Nezávislý přehled novinek na PHP.Watch u verze 8.6 uvádí tutéž alfu 3 a ze zmíněných věcí jmenuje clamp(), SortDirection a grapheme_strrev().

Co se naopak ruší

Za zastaralé je nově označené celé mbregex, tedy regulární výrazy v rozšíření mbstring (funkce mb_ereg a další). Důvod je v samostatném návrhu: knihovna Oniguruma, na které rozšíření stojí, se už neudržuje. Zastarání samo nic nerozbije, program jen začne hlásit varování; je to ale upozornění dopředu pro každého, kdo tyhle funkce v kódu má.

Zastaralé je taky vracení hodnoty z __construct() a __destruct() a jejich psaní jako generátoru. Adresa php://filter s víc než šestnácti filtry hlásí varování, dokud se počet nenastaví výslovně. Ze změn, které nejsou zpětně slučitelné, jsou podstatné dvě: preg_grep() při chybě knihovny PCRE vrátí false místo částečného pole a vlastnosti rozšíření DOM, které byly dosud v dokumentaci označené jen ke čtení, jsou nově deklarované s asymetrickou viditelností, takže zápis zvenčí hlásí jinou chybu než dřív.

Beta 13. srpna, ostrá verze v listopadu

Plán vydání je rozepsaný do 19. listopadu 2026, kdy má vyjít ostrá verze. Do 11. srpna mají být sloučené všechny návrhy mířící na 8.6, 13. srpna přijde beta 1 a s ní měkké zmrazení novinek, u kterého už musí být hlasování uzavřená. Tvrdé zmrazení je na 22. září, první kandidát na vydání o dva dny později. Vydání řídí trojice: Daniel Scherzer jako veterán, Matteo Beccati a Joe Ferguson jako nováčci.

Pro toho, kdo píše knihovny, je alfa první příležitost, jak narazit na problém dřív, než se verze uzavře. Otazník ve volání navíc není povinnost: kdo ho psát nechce, píše anonymní funkce jako dosud a nic se mu nerozbije. Změní se podle nás spíš zvyk – tam, kde se dnes opisuje celá hlavička funkce kvůli jednomu argumentu, bude stačit jeden znak.

Zavaděč je první program, který se po zapnutí počítače dostane ke slovu. U virtuálních strojů, které mají o sobě umět podat důkaz, je zároveň jedním z mála míst, kde se nemá nic měnit. Fedora proto pro verzi 45 přijala změnu, která k běžnému GRUBu přidá druhý, záměrně chudý balíček. Jmenuje se grub2-efi-x64-cc, umí jen UEFI a jeho hlavní práce je najít jeden soubor a spustit ho.

Proč u důvěrných výpočtů vadí aktualizace

Důvěrný virtuální stroj je stroj, do jehož paměti nevidí ani ten, kdo ho provozuje. Aby to zákazník poznal, používá se vzdálené doložení stavu: stroj předloží otisky všeho, co se do něj při startu nahrálo. Otisky drží čip TPM v registrech PCR a stačí do řetězu přidat jediný bajt navíc, aby vyšlo jiné číslo.

Text změny z toho vyvozuje požadavek, který se běžnému software příčí. Protože důvěrné stroje na doložení stojí, mají být hodnoty PCR stabilní a předvídatelné po dlouhou dobu, takže aktualizaci zavaděče je podle návrhu lepší se pokud možno vyhnout. Čím míň modulů má zavaděč zabudovaných, tím menší je jeho útočná plocha a tím řidčeji ho bude potřeba měnit.

Druhá půlka úvahy je o jednotném obrazu jádra, zkráceně UKI. Je to jeden soubor, ve kterém je jádro, počáteční ramdisk i příkazová řádka pohromadě a podepsané vcelku – odpadá tím initramfs, který u klasického startu podepsaný není. Zavaděč u UKI nemá co skládat; jen ho najde a předá mu řízení.

Co ten balíček je

Nový balíček vzniká ze stejného zdroje jako hlavní GRUB, ale sestavuje se zvlášť a obsahuje jen moduly nutné pro virtuální stroje. Umí načíst UKI podle záznamů ve specifikaci zavaděčů (BLS) a běžný GRUB nenahrazuje – kdo si ho nenainstaluje schválně, nepozná, že existuje.

Pro architektury x86_64 a aarch64 je balíček podle textu změny ve vývojové větvi Rawhide a je podepsaný klíčem GRUBu pro Secure Boot. Vlastní podpisový klíč má dostat teprve časem. Návod na vyzkoušení radí přepsat běžný grubx64.efi souborem grubx64-cc.efi z balíčku, restartovat a příkazem tpm2_pcrread ověřit, že se hodnota registru PCR8 mezi starty různých UKI nemění. Vedle toho radí porovnat velikost obou souborů; že je nový menší, návrh tvrdí, o kolik, neuvádí.

Aby se dal takový zavaděč na systémech se spouštěcími kontejnery bezpečně aktualizovat, musí ho umět nástroj bootupd. Hlášení číslo 1080 v jeho repozitáři je otevřené od 2. dubna 2026 a poslední pohyb v něm byl 18. června.

Otázka, které se návrh nevyhnul

Nabízí se, proč se místo osekávání GRUBu nesáhlo po systemd-boot, tedy po zavaděči, který je malý od začátku. Návrh na to má vlastní oddíl. Když ho Leo Sandoval 11. června otevřel k diskusi, stály v něm čtyři důvody: tým systemd prý sd-boot v současné podobě podporovat umí, ale žádné další funkce do něj přidávat nechce; sd-boot není tak prověřený a profuzzovaný jako GRUB; udržovat dlouhodobě dva zavaděče by znamenalo technický dluh; a případné rozšíření na další architektury by si stejně vyžádalo kompatibilní zavaděč.

Odpovědi přišly hned. Michael J Gruber napsal, že proti odlehčené variantě GRUBu nic nemá, ale návrh podle něj rezignuje na myšlenku nového štíhlého zavaděče; GRUB umí příliš mnoho věcí a odsekáváním částí se podle něj k udržitelnému stavu nedojde. Alberto Ruiz připomněl, že Fedora už systemd-boot i ukiboot dodává a že oba zůstanou i proti osekanému GRUBu podstatně menší. Maksym Hazevych označil bod o nepřidávání funkcí za rozporný s tím, že se u GRUBu funkce naopak ubírají.

Nejostřeji se ozval Zbigniew Jędrzejewski-Szmek: část o sd-bootu je podle něj „odtržená od reality“ (přeloženo z angličtiny), protože specifikace UKI se pravidelně rozšiřuje a systemd-boot i systemd-stub pravidelně dostávají nové funkce. Luca Boccassi doplnil, že sd-boot fuzzován je, byť přes oss-fuzz a míň, než by měl být, a že je od několika měsíců výchozím zavaděčem v openSUSE Tumbleweed.

Marta Lewandowska za návrh argumentovala obráceně: dává větší smysl vyjít z něčeho, co v potřebných situacích funguje, a ubírat, než začít od minima a přidávat neprověřený kód. Na dotaz, odkud se vzalo tvrzení o odmítání nových funkcí, odpověděla, že to týmu řekli správci systemd z RHELu a Fedory. Barry A Scott na to namítl, že v e-mailové konferenci devel to lidé od systemd popřeli, a uzavřel to větou „zdá se, že je tu problém v komunikaci“ (přeloženo). Simon de Vlieger dodal, že správce systemd ve Fedoře totéž popřel přímo v tom vlákně.

Věta, která z návrhu zmizela

Sporný bod se ze zadání ztratil. Historie stránky změny ukazuje úpravu z 25. června 2026, ve které účet Kashyapc v oddílu Feedback smazal právě odrážku o tom, že tým systemd další funkce nechce. Zbylé tři důvody zůstaly beze změny a stránka od té doby žádnou zmínku o postoji týmu systemd neobsahuje. Znění z 11. června na diskusním fóru ji má dál.

Schváleno, ale bez nadšení

Řídicí výbor Fedory dostal změnu k projednání 30. června. Simon de Vlieger napsal, že se mu o ní hlasuje těžko: hodnotu balíčku pro důvěrné stroje osobně nevidí, kdežto osekaný GRUB pro běžný hardware podle něj smysl dává, jenže na to zatím připravený není. Timothée Ravier mu odpověděl, že spouštět UKI přímo sice jde, ale uživatel se pak k návratu na starší verzi dostane jen přes rozhraní firmwaru a v řetězu startu chybí shim. Neal Gompa a Kevin Fenzi se přihlásili s týmž odůvodněním a hlasem pro. Michel Lind i Zbigniew Jędrzejewski-Szmek svůj hlas označili sami za slabý. Sedmého července to Jędrzejewski-Szmek uzavřel zápisem, že po týdnu je návrh schválen v poměru pět pro, nula proti, nula zdrželo se. Tiket se zavřel 14. července.

Otevřené věci zůstávají tři. Balíček nemá vlastní podpisový klíč, bootupd ho zatím neumí a Timothée Ravier v diskusi upozornil, že návod na vyzkoušení odpovídá jen zkoušce, ne tomu, jak se se zapečetěnými spouštěcími kontejnery pracuje v projektu bootc, kvůli kterému změna vznikla. Jędrzejewski-Szmek k tomu podotkl, že správný typ záznamu pro UKI je podle specifikace uki, ne efi, jak stojí v návodu.

Čas na doladění ještě je. Podle harmonogramu se větev Fedory 45 odděluje od Rawhide 11. srpna, uzávěrka hotového kódu je 25. srpna a vydání míří na 20. října 2026. Podobně jako u stínového zásobníku platí i tady, že schválená změna není hotová změna.

Zdroje: stránka změny GRUB EFI for Confidential Computing na wiki Fedory a rozdíl mezi jejími verzemi z 25. června, vlákno k návrhu na fóru Fedory, tiket 3626 řídicího výboru, hlášení 1080 v repozitáři bootupd a harmonogram Fedory 45.

Vezměte si přirozené číslo. Je-li sudé, vydělte ho dvěma; je-li liché, vynásobte třemi a přičtěte jedničku. Collatzova domněnka říká, že se z každého kladného čísla takhle po konečně mnoha krocích dostanete k jedničce. Dokázat to nikdo neumí a patří to mezi nejznámější otevřené problémy matematiky.

Repozitář CollatzLean, který se 25. července objevil na GitHubu, přesto tvrdil opak. Vznikl podle de Mourova zápisu s pomocí umělé inteligence. Samotné znění má v souboru Collatz/Definitions.lean, kde je Collatzův krok napsaný přesně tak, jak stojí výš, a závěr v Collatz/Main.lean zní not_conjecture : ¬ Conjecture, tedy domněnka neplatí. Projekt se přeložil systémem Lean 4 a neobsahoval ani jedno sorry, což je značka, kterou Lean zaznamená vynechané místo v důkazu.

Nebyl to důkaz. Byla to chyba v jádře Leanu.

Co jádro nekontrolovalo

Lean má práci rozdělenou na dvě části. Zápis, který píše člověk, zpracuje elaborátor, tedy velký a složitý kus programu, kterému se z principu nevěří. Výsledkem je důkazní term a ten teprve přebírá jádro, malý program, jehož jedinou úlohou je term znovu zkontrolovat. Když projde jádrem, důkaz platí. Celá důvěryhodnost systému tedy stojí na těch pár tisících řádcích jádra.

Kiran Gopinathan původní repozitář rozebral a 28. července z něj vydestiloval krátký příklad, který jádru předloží důkaz nepravdy. Podal ho jako hlášení #14576 s nadpisem, který přeložen říká, že jádro přijímá projekce s nesprávnou strukturou a dovoluje tím bezaxiomový důkaz nepravdy. Příklad nesahá na sorry, na unsafeCast, na vypnutou kontrolu ani na upravené soubory .olean.

Příčinu popsal Leonardo de Moura, hlavní architekt Leanu, ve vlastním zápisu z 1. srpna. Když jádro zpracovává vnořený výskyt pod induktivním typem, jehož parametry se v polích konstruktorů vůbec neobjeví, tyto parametry vypadnou z pomocného typu, který si jádro k té práci vyrábí. A co vypadne, to se nekontroluje. Špatně otypovaný výraz na tom místě pak stačil k tomu, aby jádro přijalo důkaz nepravdy, a z nepravdy plyne cokoliv, tedy i to, že nula se rovná jedné.

Dvě věci k tomu de Moura dodává. Zaprvé, chyba je dosažitelná jen metaprogramováním: deklarace se musí jádru poslat přímo, protože běžnou cestou ji elaborátor zachytí. Zadruhé je to podle něj chyba v implementaci, ne díra v metateorii Leanu.

Nezávislý kontrolor ho pustil taky

Obvyklá pojistka proti chybě v jádře je přepočítat důkaz jinou, nezávisle napsanou implementací. Pro Lean je jí nanoda, kterou v Rustu píše Chris Bailey. Collatzův repozitář prošel i jí, přesněji její týden starou verzí, a to je na celé věci nejzajímavější: nešlo o jednu chybu, ale o dvě, které spolu nesouvisejí. Oficiální jádro neprovádělo kontrolu u vnořených induktivních typů, kdežto nanoda tohle místo kontrolovala, zato neověřovala jméno struktury v uzlu projekce. Podle de Moury byl ten důkaz postavený tak, že výraz, kam se oficiální jádro nepodívá, byl přesně ten, který tehdejší nanoda propustila.

Chybu v nanodě nahlásil Jeremy Chen a opravená byla už týden předtím, než se objevilo hlášení proti Leanu. Ramana Kumar, autor repozitáře, považuje shodu okolností za náhodu, ale podle de Mourova zápisu nevylučuje, že model, se kterým důkaz vznikal, hlášení o nanodě viděl. Joachim Breitner nabídl jiné vysvětlení: shoda plyne z toho, že jsou dnes k dispozici modely, které takovou chybu najdou.

Praktický závěr z toho vychází mírnější, než se na první pohled zdá. Kontrola nezávislým jádrem dál funguje, protože k obejití bylo potřeba obejít dvě různé implementace naráz. Kdo se na ni spoléhá, potřebuje ale aktuální verze obou. Formalizace lean4lean od Maria Carneira, která má o Leanově typové teorii dokázat, že ji jádro implementuje správně, tou chybou zasažená je, protože její zpracování induktivních typů je převzaté z referenční implementace.

Od hlášení k opravenému vydání za den

Hlášení #14576 vzniklo 28. července v 3.28 UTC. Žádost o začlenění #14577 podal de Moura v 5.08 téhož dne a začleněná byla v 13.39. Je v ní 111 přidaných a 3 odebrané řádky ve třech souborech, přičemž vlastní oprava v src/kernel/inductive.cpp dělá 14 přidaných a 3 odebrané řádky; zbytek jsou dva testy, které přesně ten příklad z hlášení zkoušejí znovu. Jádro nově dotyčné argumenty zkontroluje na konci, až má k dispozici právě deklarované induktivní typy.

Opravené vydání v4.32.2 vyšlo týž den. Noční sestavení nightly-2026-07-29 odpovídá přímo tomu commitu s opravou.

Kde se oznámení a repozitář rozcházejí

Do konference oss-security poslal 2. srpna vlastní oznámení Jonathan Brossard. Přidal k němu ukázku v Dockeru, která na verzi 4.31.0 dokáže 0 = 1 bez jediného axiomu, ohodnocení CVSS 3.1 na 7,1 bodu a zařazení pod CWE-843 (záměna typů) a CWE-20. Číslo CVE zatím přiděleno není; Brossard k tomu píše, že projekt Lean nemá soubor SECURITY.md ani zapnuté neveřejné hlášení zranitelností na GitHubu.

Dvě věci v tom oznámení ale nesedí a rozhodne o nich sám repozitář. Zasažené jsou podle něj verze „do 4.31.0 včetně“, jenže Collatzův repozitář má Lean i Mathlib přišpendlené na 4.32.1 a prošel. A hlavně: oznámení tvrdí, že v době jeho vydání neexistuje opravené stabilní vydání. Přitom značka v4.32.2 je ze 28. července a soubor s testem tests/elab/issue_14576.lean v ní je, kdežto ve značce v4.32.1 chybí; totéž platí o samotné kontrole v src/kernel/inductive.cpp. Opravené stabilní vydání tedy bylo venku čtyři dny před tím oznámením.

Co po tom zůstalo

Návazná žádost #14582, která má jádro donutit ověřovat, že se parametry vnořeného výskytu opravdu chovají jako parametry, je zatím otevřená. Daniel Selsam z OpenAI pomohl nadaci Lean FRO modelem zaměřeným na bezpečnost a našel v jádře další chyby v programu; podle de Moury jsou všechny opravené, všechny byly dosažitelné jen metaprogramováním a všechny nanoda zachytila.

Zaznělo taky, že by se metaprogramování mělo omezit, aby se takový útok nedal vůbec zapsat. To de Moura odmítá: elaborátor je nedůvěryhodný záměrně a správnost nesmí stát na tom, že nějaká nedůvěryhodná součást odmítne sestavit špatný term. Kdo chce podstrčit vadný důkaz, může rovnou zapisovat soubory .olean nebo sáhnout do paměti. Jádro musí špatně otypované deklarace odmítnout samo.

Podle nás je na celém případu zajímavější než ta chyba to, co ukázala o pojistkách. Repozitář prošel jádrem i nezávislým kontrolorem, tedy oběma programy, které tohle mají odhalit, a přesto to nebyl důkaz. Poznal to až člověk, který ho rozebral na nejmenší kousek. Strojová kontrola důkazu je tak silná jako program, který ji provádí, a proti chybě v něm pomáhá jedině to, že ji někdo hledá.

Zdroje: zápis Leonarda de Moury z 1. srpna 2026, oznámení v konferenci oss-security z 2. srpna 2026, hlášení #14576 a oprava #14577 v repozitáři Leanu a repozitář CollatzLean. Data vydání a obsah značek v4.32.1 a v4.32.2 ověřeny přes rozhraní GitHubu.

Kdo si k notebooku připojí grafickou kartu v externím boxu, čeká od ní výkon. Na Linuxu ho dosud dostával jen zčásti, a to z důvodu, který s výkonem té karty nemá nic společného: obraz se cestou na monitor dvakrát zbytečně zkopíroval. Vývojář KDE Xaver Hugl popsal 31. července na svém blogu, proč se to dělo a co s tím udělal.

Odkud se ty kopie berou

Na Waylandu si aplikace a kompozitor předávají hotové obrázky protokolem linux-dmabuf. Kompozitor ohlásí, kterou grafiku používá a jaké formáty od ní přijme; aplikace pak na téže grafice alokuje takzvaný dma-buf, tedy oblast paměti přístupnou přímo hardwaru, a pošle na ni odkaz.

Do páté verze protokolu ale kompozitor uměl ohlásit právě jednu grafiku. Když hra běží na jiné, jádro se snaží pomoct: při importu takového bufferu do druhé grafiky ho přesune do systémové paměti, aby se k němu dostaly obě. Systémová paměť je proti té na kartě pomalá a karta k ní chodí přes sběrnici PCIe, takže je z pomoci brzda. Ovladače Vulkanu a OpenGL to řeší po svém – když zjistí, že hra kreslí na jiné grafice, než jakou ohlásil kompozitor, udělají rovnou kopii do systémové paměti a pošlou tu.

Nepříjemné to začne být ve chvíli, kdy je monitor zapojený zpátky do té dedikované grafiky. Konektor HDMI je na spoustě notebooků vyvedený právě z ní, takže je to běžný případ. Obraz pak jde z dedikované grafiky do systémové paměti, odtud do integrované, ta z něj složí plochu – a výsledek se kopíruje zpět na dedikovanou grafiku. U externí karty, kterou spojuje s notebookem jediný kabel USB-C, nemusí pásmo stačit ani na jeden směr; na oba je to podle Hugla konec výkonu.

Šestá verze protokolu

Řešení zní jednoduše: ať ovladač kopie nedělá a předá kompozitoru původní buffer. Přesně kvůli tomu Hugl navrhl šestou verzi linux-dmabuf, ve které kompozitor ohlásí celý seznam grafik a aplikace u každého bufferu řekne, do které se má importovat. Podal ho podle Phoronixu v roce 2023; začleněný byl podle jeho vlastního textu něco přes dva roky nato a k uživatelům se dostal až ve vydání wayland-protocols 1.49 ze 7. června 2026.

Sám na tom nebyl. Victoria Brekenfeld ze System76 doplnila podporu do Mesy a do knihovny Smithay, na které stojí kompozitor Cosmic. V KWinu to znamenalo delší seznam práce: naučit ho, že grafik je víc než jen ty, na které se zobrazuje, zvládnout jejich připojení za běhu, sledovat, na které grafice který buffer leží, a postavit obecnou vrstvu pro kopie mezi nimi – a to tak rychlou, jako je dělá Mesa uvnitř sebe. Kvůli té rychlosti přidal Hugl do KWinu Vulkan; vedlejším produktem je základ, na kterém může jednou stát celý vulkanový vykreslovač.

Co to udělalo s čísly

Měřeno je to na jedné sestavě: notebook Framework 13, karta Radeon RX 5700 XT v externím boxu a monitor 5120 na 1440 bodů při 120 Hz zapojený do té karty. Jednoduchá zkušební aplikace vkcube na celou obrazovku běžela předtím na 55 snímcích za sekundu, potom na 120, což je strop monitoru.

Praktičtější je druhé číslo. Cyberpunk 2077 na nízké předvolbě dal se současnou Mesou 27 snímků za sekundu, s doplněnou podporou šesté verze protokolu 50. Dopočteno je to o 85 procent víc, Hugl sám v textu píše o víc než osmdesáti procentech. Podle něj hru nejspíš brzdí pásmo kabelu USB-C, takže s dalšími úpravami ovladače by rozdíl mohl být ještě větší.

Zprávu o té práci vydal Phoronix, u vkcube ale uvádí posun ze 40 na 120 snímků. V původním blogu stojí 55; odkud se vzalo to nižší číslo, se z textu poznat nedá.

Běžný notebook s dedikovanou grafikou Hugl změřit nemohl – nemá k dispozici ovladač Nvidie s podporou protokolu ani stroj s dedikovanou kartou AMD. Odhaduje, že tam bude zlepšení mírnější, řádově pět až deset procent. Je to jeho odhad, ne měření, a sám to tak píše.

Dvě omezení, která zatím platí

Skládat plochu bude KWin dál na „primární“ grafice, což je na notebooku obvykle ta, ke které byl při startu připojený vestavěný displej. Velký zisk se proto dostaví jen tam, kde hra dostane takzvaný direct scanout, tedy kde jde její obraz na monitor rovnou, bez míchání s ostatními okny. Huglova karta navíc neumí barevné pipeline, takže na ní to platí jen s vypnutým HDR, vypnutým nočním světlem a bez barevného profilu. Žádost o začlenění, která má tohle omezení sundat, má připravenou a slibuje o ní druhý díl.

Větší překážka je jinde: většina her běží pořád přes X11. Zavést protokol užitečným způsobem do Xwaylandu je podle Hugla kvůli předpokladům, se kterými X11 pracuje, nesmírně těžké – a nemá jistotu, jestli je to vůbec proveditelné. Kdo chce zrychlení dnes, musí hru přimět mluvit Waylandem přímo: u nativních titulů často stačí proměnná SDL_VIDEODRIVER=wayland, u windowsových her forky Protonu s ovladačem Wine Wayland.

Stav ostatních kusů skládačky je nestejný. Implementace v KWinu je začleněná, ta v Mese má podle autora přijít brzy a Nvidia ji ve svém ovladači má, ale zatím nevydala. Bez ovladačové poloviny se z toho na cizím počítači nic neprojeví.

Proč to není jen věc KDE

Protokol je společný, ne kdéčkový: podporu do Mesy i do Smithaye psal někdo úplně jiný a Cosmic ji má z téhož zdroje. Zrychlení tedy nemíří na uživatele jednoho prostředí, ale na každého, kdo hraje přes Wayland na jiné grafice, než na které skládá plochu kompozitor.

Podle nás je na celé věci nejzajímavější, jak dlouho to trvalo. Dva roky od návrhu do začlenění protokolu a k tomu práce v jádru KWinu kvůli sledování grafik a chování při resetu – to všechno kvůli tomu, aby se přestala dělat kopie, kterou nikdo nechtěl. Sám autor to zařadil jako první díl; hotovo tedy ještě není.

Zdroje: Fixing Multi-GPU performance, part 1 na blogu Xavera Hugla z 31. července 2026, zpráva Phoronixu z 1. srpna 2026 a oznámení vydání wayland-protocols 1.49.