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.

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

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ů.

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.

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.

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.

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.

Kdo v GNOME rozhodne, že se přestane používat jedna knihovna a začne jiná? Příručka projektu na to odpovídá vyhýbavě a návrh, který 27. července otevřela k diskusi Sophie Herold, z ní tu odpověď rovnou cituje: většina rozhodnutí v GNOME padá neformálně, mezi jednotlivci, kteří spolu spolupracují. Týká se to podle příručky i toho, kdo na čem dělá a jaká technická a uživatelská řešení se prosadí. Citace je z anglického originálu přeložená.

Proč to někomu vadí

Text návrhu chce z toho popisu odstranit slova „neformálně“ a „jednotlivci“. Shánění shody je podle něj pro přispěvatele vyčerpávající a ústí buď v malý pokrok, nebo ve vyhoření, nebo v rozhodnutí nízké kvality. Formální a sdílené struktury mají zvýšit odpovědnost a zároveň ji rozložit na víc lidí.

Není to první pokus. Emmanuele Bassi zveřejnil 15. srpna 2025 návrh RFC: Governance, který popisoval celou technickou správu projektu včetně řídicího výboru. Herold píše, že části Bassiho návrhu už dostávají podobu, ale samotný proces RFC se veřejně nepohnul. Její text je proto schválně užší: má zavést jen způsob projednávání a teprve jím pak stavět zbytek.

Jak by to fungovalo

RFC by byl obyčejný soubor v markdownu v repozitáři GNOME/rfcs na GitLabu. Podá ho kterýkoli člen nadace tím, že otevře žádost o začlenění (merge request); číslo RFC se přebírá z čísla té žádosti, takže se na dokument dá jednoduše odkazovat. V popisu žádosti stojí, koho se změna dotýká a kdo smí text upravovat – návrh těm dvěma rolím říká stakeholders a editors.

Nejzajímavější je práce s námitkami. Formální námitku smí vznést kdokoli tím, že komentář začne slovem Concern. Sama o sobě ale neznamená nic: musí ji přijmout někdo ze zúčastněných stran nebo editorů, a to někdo jiný než ten, kdo ji vznesl. Přijatá námitka se do popisu žádosti zapíše jako políčko k odškrtnutí. Návrh k tomu žádá, aby byla praktická, ne myšlenkový pokus, a aby měla zřejmou cestu k řešení.

Odškrtnout ji má ten, kdo ji přijal. Když se do čtrnácti dnů od zmínky neozve, může to udělat kdokoli další ze zúčastněných. Je to pojistka proti tomu, aby celý návrh uvázl na jednom mlčícím člověku.

Konec má podobu závěrečné lhůty na připomínky. Vyhlásí ji kterýkoli editor komentářem, ve kterém uvede, jak to má dopadnout: merge, nebo close. Čtrnáct dní se dají uplatnit poslední námitky, a když nějaká projde, lhůta se ruší a musí začít znovu. Pokud doběhne a všechny námitky jsou vyřešené, žádost se podle vyhlášeného záměru buď začlení, což znamená přijetí, nebo zavře, což znamená zamítnutí. Nad pravomoci, které jednotlivým lidem a skupinám dala nadace, se RFC dostat nesmí.

Spor první: smí se zamítat?

Podle Bassiho by se RFC zamítat neměl. Kdo návrh podává, měl by mít předem sehnané zastánce a rámcovou představu o proveditelnosti; místo zamítnutí navrhuje tři stavy – projednává se, platí, odloženo. Návrh, který nemá šanci projít teď ani později, se podle něj prostě zavře.

Herold s tím nesouhlasí. Zamítnutí má podle ní zůstat možností, protože z diskuse může vyjít, že je nápad slepá ulička; pak dává smysl, aby někdo napsal jiný RFC, ne aby se všechno cpalo do téhož textu. Stav „odloženo“ odmítá rovnou – podle ní zve k tomu nechávat rozhodnutí viset, čehož už projekt zažil dost.

Spor druhý: kde se má diskutovat

Druhá neshoda je o místě. Podle Bassiho nemá GitLab nástroje na moderování: odpověď v něm jde jen smazat nebo uživatele zablokovat, skrýt ji – na rozdíl od GitHubu – nelze. Navrhuje proto vést rozpravu na Discourse a v žádosti nechat jen úřední část, tedy zápis námitek a změny stavu a rolí. Na téže straně stojí i Allan Day.

Herold nejdřív hájila GitLab: účty jsou tam navázané na členství v nadaci, přispěvatelé se můžou přihlásit k odběru štítků jednotlivých týmů a návrh počítá s tím, že se žádost dá zamknout tak, aby psali dál jen členové. Po Bassiho výčtu – dělení vláken do samostatných témat, zpomalený režim, skrývání odpovědí, opatření mířená na uživatele místo plošného zákazu – ale napsala, že jí to i přes nechuť ke dvěma platformám v jednom procesu zní přesvědčivě.

Co návrh sám přiznává

Vlastní oddíl nevýhod jmenuje tři věci. Návrh nemá konečný způsob, jak rozhodnout spor mezi zúčastněnými stranami o přijaté námitce, takže i důležitý RFC může uváznout. Sepsat ho je pro část přispěvatelů technická překážka. A protože text sází na stručnost, nejspíš nepokryje okrajové případy.

Čtvrtou výhradu přidal do diskuse Benjamin Otte. Tři příklady, které Bassi uvedl jako věci, jež měly projít RFC – nový formát symbolických ikon, přechod od knihovny GdkPixbuf ke Glycinu a výměna nástroje na vývojářskou dokumentaci –, byly podle něj předem hotová rozhodnutí: jejich autoři si domluvili těch pár lidí, kterých se to týkalo, a udělali to. Skutečně sporné jsou podle Otteho jiné věci, třeba celoprojektový postoj k umělé inteligenci, jestli se smí základní aplikace psát v Rustu, nebo který terminál má být ten výchozí. Ptá se proto, jestli má pro obojí dávat smysl tentýž postup. Dílčí pravidla pro kód psaný modely přitom v projektu už vznikla – recenzent rozšíření je sepsal na blogu a jsou teď součástí oficiálního průvodce. Matthias Clasen se k tomu přidává z druhé strany: proces musí zůstat lehký, protože žádná z těch tří věcí by podle něj nevznikla, kdyby jí předcházela dlouhá rozprava o všech nepravděpodobných způsobech, jak to může selhat.

Co bude dál

Herold uvedla dva kroky: nejdřív ohlasy na fóru Discourse, a když návrh obstojí, projde vlastním procesem jako RFC-0001. Diskusi si přitom vyhradila pro aktivně přispívající členy nadace. Do 1. srpna se v ní sešlo osmnáct příspěvků od osmi lidí.

Podle nás je nejsilnější místo celého textu právě pravidlo, že námitku musí uznat druhý člověk. Bassi to v diskusi řekl bez obalu: dá se tím pominout komentář někoho, kdo do věci nic nevložil a jen šel kolem. Je to zároveň místo, kde návrh sám přiznává díru – když se neshodnou dva lidé, kteří do věci vložili oba dost, nerozhodne nikdo.

Zdroje: Proposal for an RFC Process na GNOME Discourse, znění návrhu na GitLabu, RFC: Governance z roku 2025, This Week in GNOME #260 a zpráva Phoronixu z 1. srpna 2026.

OBS Studio je otevřený program, kterým se nahrává obrazovka a vysílá živě na Twitch nebo YouTube. Vydání 32.2.0 je z 21. července 2026 a přineslo jednu změnu, které si všimne každý hned po spuštění, a několik dalších, které rozhodnou o tom, jestli má uživatel na aktualizaci vůbec sahat.

Místo nabídky okno s náhledy

Obraz, zvuk i text se do vysílání přidávají jako takzvané zdroje. Doteď se vybíraly z rozbalovací nabídky pod tlačítkem plus, tedy ze seznamu názvů, ze kterého nebylo poznat, co která položka udělá. Verze 32.2 ji nahradila samostatným oknem, ve kterém jsou zdroje dlaždice s náhledem a dá se mezi nimi chodit šipkami na klávesnici.

Náhledy obstarává nová třída ThumbnailManager. Podle popisu ve slučovacím požadavku 12067 drží v paměti náhledy všech viditelných zdrojů v nízkém rozlišení a postupně obnovuje vždy ten nejstarší.

Napoprvé to neprošlo

Změnu poslal vývojář vystupující jako Warchamp7 v dubnu 2025 a projekt ji přijal 14. ledna 2026. O čtrnáct dní později přišel opačný požadavek, který ji z kódu zase odstranil. Jeho zdůvodnění je stručné: zbývaly v ní chyby, na jejichž opravu a kontrolu nebyl před tehdejším vydáním čas, takže se odkládá na příští (přeloženo z anglického popisu požadavku).

Mezitím vyšlo 11. března vydání 32.1.0, ve kterém okno nebylo. Přepracovaná podoba se do kódu vrátila 7. května a k uživatelům se dostala až o dva a půl měsíce později s vydáním 32.2. Od prvního poslání změny do její dostupnosti tak uplynulo přes rok.

Komu aktualizace sebere podporu

OBS v tomhle vydání přešlo na Video Codec SDK 13 od NVIDIE, a tím se posunula spodní hranice ovladače. Kdo kóduje obraz přes NVENC, potřebuje ovladač 570 nebo novější. Sedí to s dokumentací výrobce: popis SDK 13.0 uvádí ovladač 570 a vyšší pro Windows i pro Linux, k tomu CUDA 11.0 nebo novější.

Druhé omezení se týká Applu. Kvůli přechodu na novější Qt už OBS neběží na macOS 12 a poznámky k vydání odkazují ty, kdo na něm zůstávají, na starší verzi 32.1.2. Tahle věta stojí v poznámkách na GitHubu, na stránce projektu s týmiž poznámkami chybí.

Třetí změna se týká starších Maců. Instalace sestavená pro procesory Intel, která běží na stroji s čipem Apple Silicon, se nově sama aktualizuje na verzi pro Apple Silicon. Zásuvné moduly od třetích stran se po takovém přechodu nenačtou, dokud je uživatel nevymění za jejich verze pro nový procesor.

Co se opravilo

Seznam oprav je dlouhý a část z nich míří na kódování obrazu. NVENC používal v režimu CQVBR jiný datový tok, než jaký mu byl zadaný. Kódování AV1 přes VAAPI, tedy cestou pro hardwarové kódování na Linuxu, nefungovalo při vysílání protokolem WHIP. Snímání obrazu přes PipeWire mohlo na kartách NVIDIA selhat.

Vedle toho se opravilo poškozování uloženého stavu přihlášení a rozložení panelů, černý obraz při snímání obrazovky po selhání duplikátoru a několik pádů při zavírání programu. Na Windows přibyla omezení procesu proti vnějším zásahům, změnilo se načítání knihoven DLL a program už nedovolí přepsat vlastní obsluhu pádů.

Přibyl také filtr, který skládá obraz v SDR do HDR, dynamický datový tok pro vysílání ve více stopách (multitrack video) a možnost dát vlastním typům zdrojů vlastní ikony. Funkce obs_properties_add_button je nově označená jako zastaralá.

Za tři dny přišla oprava

Vydání 32.2.1 z 24. července řeší jedinou věc: snímání hry přestalo po aktualizaci OBS fungovat, pokud se ve hře ještě používal zásah (hook) z předchozí verze. Zbytek seznamu změn je totožný s 32.2.0.

Náš názor: kdo vysílá na Windows s kartou NVIDIA a starším ovladačem, má důvod aktualizaci odložit, dokud ovladač nepovýší. Pro ostatní je hlavní změnou jiná práce se zdroji, ne rychlost ani kvalita obrazu.

Zdroje: poznámky k vydání 32.2 na stránkách OBS Studia, vydání 32.2.0 a 32.2.1 na GitHubu, popis NVIDIA Video Codec SDK 13.0.

Cesta k vydání byla podle vlastního výpisu novinek na webu projektu dlouhá. První kandidát vyšel 6. února 2026, sedmý 21. července, hotová jedenáctka o devět dní později. Stránka s poznámkami k vydání ostatně pořád nese nadpis „Announcing NetBSD 11.0 RC7 (July 21, 2026)“, přestože pod ním stojí seznam změn hotové verze.

RISC-V poprvé mimo vývojovou větev

V seznamu novinek stojí na prvním místě port na 64bitovou architekturu RISC-V. Projekt ho označuje za první stabilní vydání, které tuhle architekturu podporuje, a jmenuje k němu desky postavené na čipech StarFive řady JH71XX, tedy VisionFive 2 a PINE64 STAR64. Vedle skutečného hardwaru systém běží v emulátoru QEMU.

Rozsah podpory se mezi čipy dost liší. U StarFive JH7110 uvádějí poznámky k vydání sběrnice PCI a PCIe, generátor náhodných čísel, ovládání vývodů čipu i teplotní čidla. U čipu Allwinner D1, který sedí třeba v desce MangoPi MQ Pro, jde zatím o základ: vývody a sériovou konzoli. V QEMU navíc přibyly hodiny Goldfish RTC a zařízení VirtIO včetně zvuku. Uvnitř jádra funguje na RISC-V i ladicí nástroj crash(8).

Víc linuxových programů se rozběhne bez úprav

Další velká položka seznamu je vrstva compat_linux(8), díky které jdou na NetBSD spouštět programy přeložené pro Linux. Přibylo do ní epoll, postavené nad vlastním mechanismem kqueue, dále fronty zpráv podle POSIX a systémová volání statx, readahead, close_range, waitid, renameat2, clone3, sync_file_range, syncfs a inotify. Výčet v poznámkách začíná slovem „including“, takže úplný není.

Epoll obsluhuje čekání na velké množství otevřených popisovačů najednou, inotify hlídá změny v souborech a adresářích. Samotné NetBSD k tomu dostalo volání memfd_create(2) shodné s linuxovým a jeho procfs umí nově sysvipc a self/limits, opět kvůli kompatibilitě. Na stejné straně stojí i lepší soulad s POSIX.1-2024 a s jazykovou normou C23, včetně nového obalu c17(1), který POSIX.1-2024 vyžaduje.

Jádro MICROVM a slibovaných deset milisekund

Pro x86 přibyla samostatná konfigurace jádra s názvem MICROVM, určená pro virtuální stroje, které mají naskočit co nejrychleji. Staví na zavádění PVH, na VirtIO přes sběrnici MMIO a na několika úpravách jádra. Projekt u ní uvádí, že na procesorech x86 z roku 2020 nabootuje zhruba za 10 ms. To číslo pochází z poznámek k vydání, tedy od samotného projektu; podmínky měření u něj nestojí.

Podobným směrem míří nový port virt68k, který nechává běžet variantu pro procesory Motorola 68000 v QEMU s paravirtualizovanými zařízeními. Tedy stará architektura, ale bez emulace dobových řadičů a karet.

Hardware, který jinde vypadl z podpory

Velká část seznamu změn je o strojích, ke kterým se nikdo jiný nehlásí. Port na Nintendo Wii dostal ovladač DVD mechaniky, bezdrátovou síť bwi(4), sériovou konzoli USB Gecko, hardwarovou jednotku AES a vlastní zavaděč; šifrování disku a Wi-Fi tím na Wii zrychlily. Grafické karty HP Visualize FX a HCRX obsluhují na architektuře hppa nové ovladače summitfb(4) a hyperfb(4). PowerBooky řady 1xx umí nově řídit podsvícení a hlásit stav baterie ovladačem pbbat(4). Textová konzole portu x68k zvládne sekvence Sixel, tedy obrázky přímo v terminálu.

Z novějšího hardwaru přibyla první podpora platformy Qualcomm Snapdragon X Elite včetně jader Oryon, čidel baterie a nabíjení, sběrnice I2C a vývodů GPIO. Michael Larabel na Phoronixu ji ve zprávě o vydání označuje jako Snapdragon X1 Elite; poznámky NetBSD píšou Snapdragon X Elite, bez jedničky.

Co se při aktualizaci rozbije

Nové OpenSSH v tomhle vydání už nepodporuje klíče DSA. Kdo si je někde ručně povolil, může po aktualizaci zjistit, že mu sshd nenastartuje. Rozhraní ctype(3) dostalo hlídací stránky paměti, které odhalí jeho nesprávné použití: kód, který dřív tiše vracel špatné výsledky, teď spadne. Původní chování vrátí proměnná prostředí LIBC_ALLOWCTYPEABUSE. Nastavení frekvence procesoru přes sysctl se na aarch64 udává v MHz místo dosavadních výkonnostních jednotek a ovladač hdaudio(4) přejmenoval a přeskládal ovládací prvky směšovače, takže skripty na hlasitost je potřeba projít.

Drobná změna v síťovém zásobníku: počáteční časovač pro opakované odeslání paketu TCP klesl ze tří sekund na jednu, jak to dovoluje RFC 6298. Firewall npf(7) umí nově filtrovat na druhé vrstvě a podle uživatele a skupiny.

Čím je systém přeložený

V základu vydání jsou binutils 2.42, GCC 12.5.0, GDB 15.1, OpenSSL 3.5.7 a X.Org 21.1.24. Překladač je tedy ze starší řady: GCC 12.5 vyšlo v červenci 2025, ale sama řada 12 začala v květnu 2022 a nejnovější GCC 16.1 je z letošního dubna. Phoronix navíc psal už v srpnu 2025, když se větev pro 11.0 oddělovala, že se do ní nedostaly novější ovladače DRM/KMS ani rozsáhlá obnova ovladačů Wi-Fi.

Na čem NetBSD stojí, ukazuje podle nás seznam podporovaných strojů líp než jakákoli tisková zpráva: v jednom vydání přibude port na architekturu, která se teprve prosazuje, a zároveň ovladač DVD mechaniky do Nintenda Wii. Kam se projekt vydá dál, se bude probírat v září na konferenci EuroBSDcon v Bruselu.

Co je LPM a proč se vypíná

Link Power Management, zkratkou LPM, uspává samotné spojení mezi řadičem a diskem, když se po něm chvíli nic nepřenáší. Nejde o zaparkování hlaviček ani o zastavení ploten, jen o tu linku. Jádro pro ni zná šest pojmenovaných nastavení: max_performance linku neuspí vůbec, min_power spí nejvíc. Michael Larabel na Phoronixu uvádí, že vypnutím LPM přijde uživatel o 0,5 až 1,5 W na disk; odkud to číslo pochází, u něj nestojí a v samotných záplatách není.

Když se ale disk z uspané linky neprobere správně, systém ho ztratí. Přesně to hlásili uživatelé v záznamu 220693 v Bugzille jádra, založeném 22. října 2025 pod názvem, který popisuje příznak a nic víc: sběrnice SATA po chvíli zmizí. Za devět měsíců se pod ním sešlo devětapadesát komentářů.

Tři slepé uličky

První stopa vypadala přesvědčivě. Bisekce jednoho z hlásících ukázala na commit block: Improve read ahead size for rotational devices, který od jádra 6.17 zvětšil dopředné čtení u točivých disků. Damien Le Moal, správce libaty a shodou okolností i autor toho commitu, na to odpověděl, že pokud je spouštěčem opravdu on, chyba nebude v blokové vrstvě, ale v hardwaru, který si neporadí s velkými požadavky.

Druhá stopa přišla od dvou dalších lidí: problém jim zmizel, když vypnuli jednotku IOMMU. Třetí byla velikost přenosů. Niklas Cassel poslal do vlákna skript, který postupně zvyšuje maximální velikost požadavku a hledá, kde disk selže. U jednoho z hlásících skončil test na 4 MiB tak, že se celý stroj zasekl. U dalšího prošly všechny velikosti bez chyby, a přitom disky mizely dál.

Rozuzlení začalo komentářem z 8. prosince 2025. Uživatel v něm napsal, že za jeho výpadky může LPM, konkrétně u disku Seagate ST2000DM008, a že mu od té doby všechno běží s parametrem libata.force=6:nolpm. Cassel totéž o pět měsíců později doporučil majiteli dvou postižených WD. Ten se 24. července ozval, že po zákazu LPM oba disky fungují bez problémů, a zeptal se, co dál. Odpověď přišla za čtyři dny i s odkazem na hotové záplaty.

Které disky to jsou

Commit Disable LPM on some WD drives přidává do tabulky výjimek modely WDC WD100EFGX-68CPLN0 a WDC WD102KFBX-68M95N0. Podle produktových listů výrobce jde o desetiterabajtové disky pro síťová úložiště, první z řady WD Red Plus, druhý z WD Red Pro. Phoronix ten druhý popsal jako Red Plus Pro, což je spojení názvů dvou různých řad.

Druhý commit, Disable LPM on WD Green 2.5 480GB, stojí na samostatném hlášení. Ronald Garcia Vazquez napsal 21. července do konference linux-ide, že se mu SSD v notebooku Dell Latitude 3420 odpojuje po dvou až třech minutách běžné práce. Ve výpisu jádra, který přiložil, jsou tři řádky za sebou: vypršel časový limit příkazu, nepodařilo se vypnout DIPM, nepodařilo se vypnout DEVSLP. Pak už jen zhasla linka a disk se odpojil. S parametrem libata.force=nolpm problém nenastal.

Tabulka, která roste od roku 2013

Výjimky pro konkrétní modely drží libata v jednom poli ve zdrojovém souboru drivers/ata/libata-core.c. K dnešnímu dni má sto čtyřicet záznamů a třiadvacet z nich nese příznak ATA_QUIRK_NOLPM. Jsou mezi nimi SSD Samsungu, Crucialu, Apaceru a PNY, tři disky Seagate i dvě vypalovačky Pioneer.

Western Digital v tom seznamu není poprvé. Sedm starších záznamů dostalo vlastní příznak ATA_QUIRK_WD_BROKEN_LPM a komentář nad nimi odkazuje na hlášení z dubna 2013: některé disky WD s rozhraním SATA-I se po uspání linky roztáčely a zastavovaly nepravidelně. Ten příznak se ale uplatní jen na zařízení, které hlásí podporu první generace SATA a žádné vyšší. Nové disky se tím pádem musely do tabulky přidat zvlášť, což si vývojáři poznamenali i do komentáře v kódu.

Oprava, která ležela v jádře přesně rok

Ve stejné dávce je i jednořádková oprava funkce ata_scsi_lpm_supported(). Ta zjišťuje, jestli port a připojená zařízení úsporný režim zvládají, a podle toho jádro pouští, nebo nepouští uživatele k přenastavení politiky přes sysfs. Vnitřní smyčka v ní procházela pořád dokola zařízení hlavní linky místo té, kterou zrovna probírala. Na sestavách s rozbočovačem portů mohla proto zbytečně odepřít změnu.

Chyba se do jádra dostala s commitem, který ten dotaz zavedl, a ten je datovaný 28. července 2025. Oprava nese datum 28. července 2026, tedy na den přesně o rok později. V poli Reported-by stojí Sashiko s adresou sashiko-bot@kernel.org, tedy strojový hlásič. Cassel opravu poslal se značkou pro stabilní řady, takže se dostane i do starších podporovaných jader.

Co s tím uživatel

Kdo má některý ze tří modelů a nechce čekat na nové jádro, nastartuje s parametrem libata.force=nolpm. Zákaz jde omezit na jediný port číslem před dvojtečkou, takže ostatní disky o úsporu nepřijdou. Vypnutí LPM je taky první věc, kterou má smysl zkusit, když se disk odpojuje bez zjevné příčiny; tenhle záznam v Bugzille ukazuje, jak snadno se místo toho hledá chyba jinde.

Podle nás je na celém případu nejzajímavější, že hardwarová vada se skoro rok schovávala za tři různá softwarová podezření, z nichž každé bylo samo o sobě rozumné. Opravy jsou v 7.2-rc6; stabilní jádro 7.2 má podle Phoronixu vyjít v srpnu. Ve stejné fázi vývoje přišlo do zvukové části jádra 53 záplat, tedy třikrát víc než o vydání dřív.

Zdroje

• SATA bus goes offline after a while, záznam 220693 v Bugzille jádra Linuxu
• Merge tag ata-7.2-rc6 a jednotlivé commity 356d8241, d549df8a a 3fd70e96, strom jádra Linuse Torvaldse
• BUG: libata: WD Green 480GB disconnects unless booted with libata.force=nolpm, archiv konference linux-ide
• Linux 7.2-rc6 Working Around Several Buggy Western Digital SATA Drives, Phoronix

AMD dalo na web referenční příručku k instrukční sadě CDNA5. Dokument je datovaný 27. července 2026, má 823 stran a stáhne se bez registrace. Žádný konkrétní čip v něm nepadne ani jednou. Server Phoronix, který ho 31. července našel, ho spojuje s akcelerátorem Instinct MI455X – a stránka toho akcelerátoru u AMD to potvrzuje, jako architekturu uvádí právě CDNA5.

Vlna se zkrátila na polovinu

Nejnápadnější změna je v tom, po kolika pracovních položkách čip počítá naráz. Vlna je skupina položek, které vykonávají tentýž program v jednom průchodu. Příručka ke CDNA4 z 5. srpna 2025 píše, že procesor sdružuje 64 položek do vlnoplochy. CDNA5 jich sdružuje nejvýš 32 a hned v úvodu varuje, že se v textu může objevit zmínka o wave64, ale zařízení umí jen wave32.

Přejmenoval se i základní stavební blok. CDNA4 mluví o výpočetní jednotce, CDNA5 o procesoru pracovních skupin (WGP), který spojuje dvě výpočetní jednotky a čtyři bloky SIMD32. Není to jen pojem z příručky: technický list MI455X uvádí 256 těchto procesorů, takt 2 400 MHz a 320 miliard tranzistorů.

Zvětšila se sdílená paměť: jedna pracovní skupina si u CDNA5 smí vyhradit až 320 kB, u CDNA4 to bylo 160 kB. Zdvojnásobení kapacity to ale není. WGP spojuje dvě výpočetní jednotky, takže na jednu z nich pořád vychází stejných 160 kB – nová je možnost dát to všechno jedné skupině.

Maticové instrukce mají jiné jméno i jiné registry

CDNA4 počítala matice instrukcemi MFMA; ta zkratka se v textu její příručky objevuje 320krát. V dokumentu ke CDNA5 nepadne ani jednou. Nahradilo ji WMMA, kterého je tam 321 výskytů, zatímco v příručce ke CDNA4 nebyl ani jeden.

Nejde jen o název. CDNA4 měla vedle 256 vektorových registrů (V0–V255) ještě 256 akumulačních (AV0–AV255), vyhrazených maticové jednotce, a instrukce MFMA si polem ACC vybírala, ze kterého pole registrů čte a kam zapisuje. CDNA5 má jediné pole s 1 024 registry (V0–V1023) a akumulační registry v něm nefigurují.

Ani WMMA, ani wave32 přitom nejsou nové pojmy. AMD je používá u herní řady RDNA – vlastní návod na GPUOpen k RDNA 3 WMMA popisuje včetně rozdílu mezi režimy wave32 a wave64. Do výpočetní řady se dostávají teď. Naopak formáty FP8, BF8, FP6, BF6 a FP4 uměla už CDNA4 a v tom se nemění nic.

Přibyly instrukce, které matici při načtení rovnou překlopí. GLOBAL_LOAD_TR16_B128 a jeho osmibitová obdoba načtou dlaždici 16×16 a prohodí u ní pořadí řádků a sloupců, aby se data nemusela do registrů rovnat zvlášť. Příručka u nich uvádí, že fungují jen v režimu wave32.

Mezi mřížkou a skupinou přibyl shluk

Rozvržení práce má nově o patro víc. Shluk je až 16 pracovních skupin naplánovaných na tentýž shader engine, každá na jiném WGP. Umějí se synchronizovat společnou bariérou a sdílet načtená data: vícesměrové načtení přečte data z paměti jednou a rozešle je do sdílené paměti několika procesorů naráz. Hierarchie tak zní mřížka → shluk → pracovní skupina → vlna → pracovní položka.

Shluk o jediné skupině se za shluk nepovažuje a instrukce pro bariéru se v něm chovají jako prázdná operace, takže starý kód se tím nerozbije.

Jednotka na přesun dlaždic

Druhá novinka se jmenuje Tensor Data Mover a je to řadič přímého přístupu do paměti pro maticová data. Přesouvá dlaždice tenzorů až o pěti rozměrech mezi pamětí a sdílenou pamětí WGP; co se má přesunout, popisuje deskriptor uložený ve skalárních registrech. Tenzorové instrukce nepoužívají vektorové registry, ignorují masku aktivních položek a běží souběžně s ostatním kódem – na jejich dokončení se čeká zvláštním čítačem. Data se dají v cílové paměti pravidelně proložit výplní, aby transpozice nenarážela na konflikty pamětových bank.

Co v příručce nenajdete

Popis instrukcí není datový list a výkonová čísla v něm nejsou. Ta dodalo AMD jinde: MI455X má 432 GB paměti HBM4, propustnost 23,3 TB/s a špičkových 40,3 PFLOPS ve formátu MXFP4. Tisková zpráva z 23. července, kterou byl akcelerátor uveden, k němu uvádí až 34krát vyšší průtok tokenů proti MI355X. Je to měření vlastních laboratoří AMD z července 2026 na modelu DeepSeek V4 Flash ve formátu FP4, ne nezávislý test.

Číslo, které se AMD nehodí, je ve dvojité přesnosti: technický list uvádí u MI455X 5 TFLOPS ve FP64, kdežto akcelerátor MI430X pro vědecké výpočty firma v téže tiskové zprávě popisuje až s 288 TFLOPS ve FP64. Kdo počítá fyziku, sáhne v téhle řadě po jiném kusu.

Pro toho, kdo pro Instinct píše, je podle nás podstatnější ta první část. Kód laděný na wave64 a na akumulační registry se na CDNA5 nepřenese beze změny a ruční jádra se budou přepisovat. Ovladač v jádře Linuxu, backend překladače i knihovny ROCm podle Phoronixu MI455X podporují už teď; na stejném ovladači ostatně stojí i nedávná regrese výkonu v Ubuntu. Hostitelskou stranu obstarávají v racích Helios procesory EPYC Venice.

Zdroje

• AMD: „CDNA5“ Instruction Set Architecture Reference Guide (PDF), 27. 7. 2026
• AMD: CDNA4 Instruction Set Architecture Reference Guide (PDF), 5. 8. 2025
• AMD: technický list Instinct MI455X
• AMD: tisková zpráva z konference Advancing AI 2026, 23. 7. 2026
• Phoronix: AMD Publishes CDNA5 ISA Documentation For Instinct MI455X, 31. 7. 2026
• Oak Ridge Leadership Computing Facility: Frontier – složení uzlu superpočítače z fotografie

Porovnání proti CDNA4 v tomhle textu vzniklo nad oběma dokumenty od AMD, ne nad převyprávěním: počty výskytů zkratek MFMA a WMMA i rozsah obou příruček jsou spočítané ze strojového převodu obou souborů PDF do textu.

Moderní grafiku Intelu obsluhuje v Linuxu ovladač xe. U čipů, které ještě neprošly ověřováním, se ale sám od sebe nespustí: v tabulce známých zařízení mají příznak require_force_probe a kdo je chce rozběhat, musí to jádru výslovně nařídit. Desktopová Nova Lake S ten příznak právě ztratila.

Jeden smazaný řádek

Záplatu poslal do konference intel-xe 22. července 2026 vývojář Intelu Gustavo Sousa. Odůvodnění má dvě věty; v překladu z angličtiny: „NVL-S je dost stabilní na to, abychom požadavek force_probe zrušili. Tak to udělejme.“ Rodrigo Vivi, jeden ze správců ovladače, ji tentýž den označil za zkontrolovanou.

Změna se týká souboru drivers/gpu/drm/xe/xe_pci.c a ze struktury nvls_desc, která popisuje vlastnosti platformy, maže jediný řádek:

.require_force_probe = true,

Jeden soubor, jedno smazání, nikde jinde v kódu nic.

Ve čtvrtek 30. července ji Rodrigo Vivi zabalil do žádosti o začlenění větve drm-xe-next pod značkou drm-xe-next-2026-07-30. Píše v ní, že je to poslední dávka směrem k jádru 7.3 a že hlavní změnou je právě zrušení ochrany force_probe pro NVL-S. Vedle toho dávka nese ošetřování neopravitelných chyb a řadu úprav kolem firmwaru GuC.

Na co je force_probe dobrý

Nápověda k volbě CONFIG_DRM_XE_FORCE_PROBE to říká bez obalu. Přepínač je pro grafiku, kterou jádro sice rozpozná, ale řádně nepodporuje, a text rovnou doporučuje přejít na verzi jádra s hotovou podporou, jakmile bude. Zařízení se vypisují po identifikátorech PCI, hvězdička znamená všechna a vykřičník před číslem naopak zablokuje i to, které by ovladač jinak vzal.

Kdo takový čip strčí do počítače s dnešním jádrem, najde v systémovém logu větu, že jeho grafické zařízení není v téhle verzi jádra ovladačem xe oficiálně podporováno, a k tomu návod: přidat xe.force_probe=<ID> a zároveň i915.force_probe=!<ID>, aby si zařízení nevzal starší ovladač. Bez toho se ovladač k zařízení odmítne navázat a o obraz se musí postarat něco jiného.

Kdo na seznamu zůstává

Ve vydávaných jádrech omezení dál platí. Ve zdrojích hlavní větve, ze které vzniká jádro 7.2, nese příznak require_force_probe dvanáct popisů platforem včetně Nova Lake S. Do 7.2 se změna nedostala a čeká na okno pro slučování další verze.

Zbylých jedenáct se dělí na dvě skupiny. V té první jsou čipy, které ověřování zatím neprošly: Nova Lake P, druhá varianta téže generace, a Crescent Island, samostatný čip bez výstupu na obrazovku. Ve druhé jsou starší platformy, jmenovitě Tiger Lake, Rocket Lake, tři varianty Alder Lake, DG1, ATS-M, DG2 a Meteor Lake, pod jehož popis spadá i Arrow Lake.

U té druhé skupiny přitom nejde o nedodělanou podporu. Ovladač xe je podle vlastního popisu v souboru Kconfig určený pro řadu Xe2 a novější, kdežto podpora starších čipů je v něm označená za pokusnou; výchozím ovladačem pro ně zůstává starší i915. Odtud ta dvojice parametrů v hlášce: jeden ovladač u daného zařízení zapnout, druhý zároveň vypnout.

Bez příznaku už jsou naopak Lunar Lake, Battlemage a Panther Lake.

Co z toho má uživatel

Zatím nic. Procesory Nova Lake S nejsou v prodeji a Intel k nim datum neoznámil; server VideoCardz čeká jejich příchod kolem začátku roku 2027. Jádro 7.3 se navíc teprve otevře, protože 7.2 je zatím ve fázi kandidátů na vydání.

Význam je jinde. Až se procesor objeví v obchodech, bude 7.3 nejnižší verzí jádra, na které jeho grafika naběhne sama od sebe. Distribuce, které si ovladač nezáplatují po svém, tím dostávají laťku: pod ní instalační obraz na takovém počítači nabídne obraz bez akcelerace, nebo bude chtít ruční parametr.

Nova Lake P na seznamu zůstává. Jestli o ní platí totéž, co Sousa napsal o desktopové verzi, se pozná stejně: dalším smazaným řádkem.

Zdroje

• Gustavo Sousa: drm/xe/nvls: Drop force_probe requirement, konference intel-xe, 22. července 2026
• Rodrigo Vivi: žádost o začlenění drm-xe-next, 30. července 2026
• Zdrojové soubory xe_pci.c a Kconfig ovladače xe v hlavní větvi jádra
• VideoCardz: Linux 7.3 will enable Intel Nova Lake-S integrated graphics by default, 31. července 2026

Raspberry Pi má od 22. července 2026 v prodeji desetipalcovou verzi dotykového displeje Touch Display 2. Katalogová cena je 80 dolarů a proti dosavadním pěti a sedmi palcům nejde jen o větší kus skla: panel má vyšší rozlišení, jiný poměr stran a jako jediný z rodiny se nezapojí do starších počítačů téže značky.

Pro srovnání, o kolik se posunula laťka: původní Raspberry Pi Touch Display, který je pořád v dokumentaci, má sedm palců a 800 × 480 bodů.

Sedmipalcový Touch Display 2 přišel v roce 2024 jako jeho náhrada s tenčím tělem a vyšším rozlišením, pětipalcová varianta ho následovala. Desetipalcová je tedy třetí velikost téže řady a výrobce ji míří na panely chytré domácnosti, kiosky, rozhraní robotů, digitální cedule a ovládání dílenských či laboratorních přístrojů.

Co stojí v katalogovém listu

Katalogový list uvádí úhlopříčku 10,1 palce, aktivní plochu 135,4 × 216,6 mm a vnější rozměr 161,8 × 247,3 mm. Rozlišení je 1 200 × 1 920 bodů ve 24bitové barevné hloubce, nativně na výšku. Zobrazovací vrstva je IPS TFT s antireflexní úpravou, dotyková zvládne deset prstů naráz a odezva dotyku je nejvýš 35 ms.

Provozní teplota sahá od −20 do +70 °C. Výroba má podle téhož listu běžet nejméně do ledna 2030 – u dílu, který se zabuduje do stroje a má se za pár let dát dokoupit, je to údaj podstatnější než jas.

Proč se čtyřka nezapojí

Starší displeje značky si vystačily se dvěma linkami sběrnice DSI, kterou se vede obraz i dotyk. To sedělo na konektor Raspberry Pi 1, 2, 3 i 4. Desetipalcový panel potřebuje kvůli vyššímu rozlišení linky čtyři, a s nimi i užší, zato rychlejší plochý kabel a novější konektor. Ten je podle oznámení výrobce jen na Raspberry Pi 5 a na deskách pro výpočetní moduly.

Displej tedy nespolupracuje s Raspberry Pi 4 ani se staršími deskami a řadou Zero. Pro ně zůstávají v nabídce pětipalcová a sedmipalcová varianta. Jinak je zapojení stejné jako dřív: napájení jde přímo z hostitelského počítače, v balení jsou kabely, konektory i montážní materiál a ovladače má Raspberry Pi OS v sobě – stačí aktualizovat systém a zavaděč v paměti EEPROM.

Kde se nový panel od menších liší

Pětipalcová i sedmipalcová varianta mají shodně 720 × 1 280 bodů, tedy poměr stran 9:16. Desetipalcová má 1 200 × 1 920, což je 5:8 – je o kousek širší. Hustota bodů vychází z aktivní plochy a rozlišení na zhruba 225 bodů na palec proti 210 u sedmipalcové a 295 u pětipalcové; tahle tři čísla v katalogu nestojí, jsou dopočítaná.

Ne každý údaj jde nahoru. Podsvícení má nový panel 400 cd/m², kdežto katalogový list menších variant uvádí 500 cd/m². Oznámení také mluví o štědřejším pozorovacím úhlu 85 stupňů; sedmipalcový displej má ovšem v katalogu tentýž údaj a osmdesát stupňů má jen ten pětipalcový. Deset dotykových bodů místo pěti a technologie IPS jsou naopak novinky, které menší panely nemají.

O kousek se zlepšila i odezva dotyku. U desetipalcového panelu udává katalog nejvýš 35 ms, u menších variant typicky 35 a nejvýš 40 ms. Jsou to jednotky milisekund, ale ukazuje to, že se s velikostí nevyměnil jen panel, nýbrž i řadič dotykové vrstvy.

Cena a dostupnost

Ceník výrobce zní 40 dolarů za pětipalcový displej, 60 za sedmipalcový a 80 za desetipalcový, vždy bez daně a dopravy. Prodej jde přes síť autorizovaných prodejců; britský The Pi Hut ho vede za 76,80 libry včetně DPH. Cenu i podmínku čtyř linek DSI potvrzuje nezávisle na výrobci i server Linuxiac.

Touch Display 2 tím přestal být příslušenstvím pro celou rodinu. Kdo staví ovládací panel do skříně a počítá s tím, že v ní časem vymění jen počítač, si u desetipalcové verze vybral i generaci: menší displeje se dají přendat na starší i novější desku, tenhle ne. Podle nás je to za to rozlišení přijatelná daň, ale je lepší o ní vědět před objednávkou než po ní.

Co v té dávce je

Padesát tři commitů od 29 autorů, 42 souborů, 444 přidaných a 171 odebraných řádků. Většinu podle Iwaie tvoří výjimky pro konkrétní zařízení a úpravy kodeků. Výjimce se v jádře říká quirk: ovladač jí obchází chování jednoho kusu hardwaru, který se nedrží normy. Sesbírané modely dávají docela slušný přehled o tom, kde zvuk v Linuxu skřípe:

• USB zvuk: C-Media CM6206, Corsair Virtuoso, Razer Barracuda X 2.4, zařízení JKY Technology Q2A a blíže neurčená USB sluchátka
• HD Audio, tedy kodeky zapájené na deskách notebooků: HP Victus 16, HP Dragonfly Folio G3, Lenovo Legion 7, HP Laptop 14s, Acer Nitro 5, TongFang X6SP45xU, Infinix INBOOK X3 a HP Pavilion All-in-One
• Zvukové řadiče AMD: Lenovo Legion 7, Acer Aspire AG14-22P, MSI Crosshair A16 a Asus ExpertBook

Zbytek míří do společného kódu. Dělení nulou při zapínání časovače v sekvenceru MIDI, závod v jádru časovače ALSA, probuzení čekajících vláken při rozpojení propojených streamů a dvojí uvolnění paměti při chybě v rozhraní UMP. K tomu několik zápisů mimo vyhrazenou paměť v ovladačích USB.

Osmnáct proti třiapadesáti

Žádosti o začlenění chodí na veřejnou konferenci, takže se dají srovnat kus po kuse. Tohle jsou týdenní dávky oprav vývojového cyklu 7.2 tak, jak je popisují samotné žádosti:

Týden před rc3 zvuk žádnou dávku nemá. Počty commitů v tabulce jsou součtem toho, co si žádost sama vypisuje po autorech; řádky a soubory hlásí přiložený diffstat.

Zajímavější je srovnání s předchozím vydáním ve stejné fázi. Pro 7.1-rc6 poslal Iwai 29. května 18 commitů v deseti souborech, o týden později pro 7.1-rc7 devět commitů v osmi souborech a napsal k nim, že se to uklidňuje. Letos v téže fázi cyklu je to 53 a Iwai slibuje brzdit. U dávky pro rc5 použil obrat, který se pak chytil: množství je podle něj pořád „new normal“, nový normál, ale samé drobné opravy.

Značka Assisted-by

Dokumentace jádra má stránku AI Coding Assistants. Zakazuje agentům přidávat pod záplatu Signed-off-by: Developer Certificate of Origin, tedy prohlášení o původu kódu, může podepsat jen člověk, který text přečetl a bere za něj odpovědnost. Pro přiznání strojové pomoci zavádí jinou značku:

Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]

Za dvojtečkou má stát konkrétní verze modelu, v hranatých závorkách nepovinně nástroje statické analýzy jako coccinelle nebo sparse. Běžné vybavení – git, gcc, editor – se do ní nepíše.

Ve stromu Linuse Torvaldse nese tuhle značku v adresáři sound/ devětačtyřicet commitů, nejstarší z 23. března 2026. V praxi vypadá třeba takhle: Assisted-by: Jetski:Gemini-3.6-Flash, Assisted-by: Claude:claude-opus-5 nebo Assisted-by: VeroCoder:claude-sonnet-4-5.

Příčinu žádost neuvádí

V žádné z pěti letošních žádostí o zvukové opravy slovo o jazykových modelech nepadne. Iwai píše o objemu, ne o tom, odkud se bere. Souvislost s modely dělá server Phoronix, který si růstu všiml v květnu a opírá ji právě o značky Assisted-by na konferenci zvukových vývojářů.

Spočítat to jde přesně. Šest z 53 commitů poslední dávky značku má: tři od Norberta Szeteie (dělení nulou v sekvenceru a dvě opravy časovače), dva od Sonali Pradhanové z Googlu a jeden quirk pro Acer Aspire od Jorna Baayena. Zbylých sedmačtyřicet ji nemá. Že by za nárůstem z osmnácti na třiapadesát stála jedna šestice commitů, z toho podle nás neplyne – doložený je zatím ten růst, ne jeho příčina. Jinde v otevřeném softwaru ostatně vychází měření opačně: SQLite v poznámkách k verzi 3.53.4 uvádí, že hlášení chyb pořízených s pomocí AI ubývá.

Obě záplaty Sonali Pradhanové míří do počítání velikostí v ovladači USB zvuku. Jedna opravuje zápis za konec vyrovnávací paměti pro přímý přístup k paměti, když si ovladač vyžádá plné pakety a přepočítá jednu hodnotu, ale druhou ne. Druhá zastropuje počet snímků odvozený ze synchronizačního paketu, aby zařízení přehnaným údajem nedostalo přehrávací frontu za mez, kterou koncový bod zvládne. Obě mají v hlavičce Cc: stable, takže půjdou i do starších udržovaných řad jádra. Finální 7.2 se čeká v srpnu.

Zdroje

• Žádost o začlenění zvukových oprav pro 7.2-rc6 a starší dávky rc5, rc4, rc2, rc1 a pro předchozí vydání 7.1-rc6 a 7.1-rc7, archiv MARC
• Commity se značkou Assisted-by v adresáři sound/, strom jádra Linuse Torvaldse
• Sound Fixes For Linux 7.2-rc6: „Far Larger Than Wished“ a Linux Sound Subsystem Also Seeing Many Fixes Driven By AI/LLMs, Phoronix

Nouveau, otevřený ovladač grafických karet NVIDIA v jádře Linuxu, umí atomické nastavování obrazového režimu od roku 2016. Kdo ho chce, musí ovladač zavést s parametrem nouveau.atomic=1; jinak zůstane vypnutý. Sérii pěti patchů, které tohle výchozí nastavení obracejí, poslala Lyude Paul z Red Hatu do konference dri-devel; poslední verze odešla 30. července.

Co se v kódu mění

Vlastní změna je drobná. Poslední patch série přepíše výchozí hodnotu proměnné nouveau_atomic z nuly na minus jedničku a popis parametru z „default: disabled“ na „default: auto“. Podmínka, která ovladači přidává příznak DRIVER_ATOMIC, se z if (nouveau_atomic) mění na if (nouveau_atomic != 0). Celá série sahá na dva soubory, přidává 22 řádků a 19 jich ubírá.

Přepínač zůstává. „Modulový parametr zatím ponecháme, protože jeho vypnutí může pomoct, kdybychom narazili na regrese,“ píše Paul v patchi (přeloženo). Kdo tedy na atomickém nastavování narazí a bude mu vadit, zavede ovladač s nouveau.atomic=0 a je zpátky na starém chování.

Proč to zůstalo vypnuté

Atomické rozhraní do Nouveau přinesl commit Bena Skeggse ze 4. listopadu 2016, který se do jádra dostal ve verzi 4.10. Týž commit zavedl i parametr atomic s výchozí nulou a Skeggs v popisu napsal proč: „Atomické ioctl tímhle zatím ve výchozím stavu nezpřístupňujeme, protože testování proběhlo jen omezeně“ (přeloženo). Pak uplynulo devět let a skoro devět měsíců a výchozí hodnota zůstala nulová.

Paul to v úvodní zprávě série vysvětluje tím, že v době, kdy Skeggs kód psal, nebylo moc na čem atomické nastavování zkoušet. Dnes je to podle ní norma, kdežto podpora neatomických ovladačů v uživatelském prostoru začíná chátrat a nese si vlastní chyby; řada z nich podle ní zmizí právě zapnutím atomického režimu. Sama ho na svých strojích běžně používá; jedinou potíž, kterou uvádí, je blikání obrazovky na jejím stolním počítači, u kterého si ale není jistá, že s atomickým režimem vůbec souvisí.

Co atomické nastavování dělá

Nastavování obrazového režimu v jádře znamená, že rozlišení, obnovovací frekvenci a rozvržení obrazových vrstev nastavuje jádro, ne grafický server nad ním. Starší cesta k tomu používá řadu samostatných volání: zvlášť se nastaví režim, zvlášť se přehodí obrazová vrstva, zvlášť kurzor.

Atomické rozhraní posílá celé nastavení jako jednu transakci, takže buď projde všechno, nebo nic. Kompozitor si navíc může kombinaci nechat nejdřív jen ověřit, aniž by ji provedl. Do jádra se dostalo ve verzi 4.0 jako schopnost DRM_CLIENT_CAP_ATOMIC a od verze 4.2 ji podle dokumentace jádra podporují všechny ovladače, které atomické nastavování zvládají. Praktický dopad, který Phoronix zmiňuje, je méně blikání při přepínání a spolehlivější chování na moderním linuxovém desktopu.

Kterých karet se to týká

Změna platí pro rodinu NV50 a novější. Podle seznamu kódových jmen projektu Nouveau je to architektura Tesla, tedy GeForce 8, 9, 100, 200 a 300, plus všechno novější. Čipy pod hranicí NV50 zůstávají beze změny; atomické nastavování pro ně nikdy nikdo nenapsal.

Právě kvůli nim je v sérii čtvrtý patch. Dosud si ovladač na příkaz nouveau.atomic=1 nastavil příznak DRIVER_ATOMIC i na hardwaru, který atomický režim neumí. Nově se to na starých čipech zakáže a ovladač místo toho vypíše varování, že je potřeba NV50 nebo novější. Druhý patch série přidává hodnotu parametru nouveau.atomic do ladicího výpisu ovladače, takže z hlášení jádra bude poznat, v jakém režimu ovladač jede.

Pět verzí za jeden den

První verze série odešla večer 29. července a měla čtyři patche v jediném souboru. Za necelý den ji vystřídaly další čtyři: přibyla oprava chyby v uklízení po neúspěšném zavedení ovladače, druhý patch se přepracoval na zacházení se strukturou drm_driver a kontrola generace čipu se přesunula z konkrétního modelu na rodinu. Celý sled i s reakcemi vydá hledání v archivu konference dri-devel.

Kdy se změna dostane do vydaného jádra, jisté není. Phoronix soudí, že vzhledem k načasování na cyklus jádra 7.3 nejspíš nedosáhne, a doufá, že přistane krátce po něm.

Zdroje

• Lyude Paul: [PATCH v5 0/5] Enable atomic modesetting by default, dri-devel, 30. července 2026
• Lyude Paul: [PATCH v5 5/5] drm/nouveau/kms/nv50-: Enable atomic modesetting by default, dri-devel, 30. července 2026
• Ben Skeggs: drm/nouveau/kms/nv50: transition to atomic interfaces internally, jádro Linuxu, 4. listopadu 2016
• Dokumentace jádra Linuxu: Userland interfaces (DRM_CLIENT_CAP_ATOMIC)
• Nouveau: CodeNames (přiřazení NV50 ke generacím GeForce)
• Phoronix: Nouveau Preparing To Finally Enable Atomic Mode-Setting By Default, 31. července 2026

Předstírat cizí procesor už nejde

Od roku 2009 uměl Xen hostovi namluvit, že běží na procesoru druhého výrobce. Nebyla to kuriozita. Byla to podmínka živé migrace, tedy přesunu běžícího virtuálního stroje z jednoho serveru na druhý bez vypnutí. Když se v racku míchaly stroje s Intelem a s AMD, dala se sestavit sada vlastností procesoru, kterou zvládaly obě strany, a host se pak dal přestěhovat tam i zpátky.

Verze 4.22 to ruší. Host smí být nastavený jen na téhož výrobce, jakého má hostitelský procesor. Projekt to v souboru CHANGELOG.md odůvodňuje takhle (přeloženo): „Když se to v roce 2009 přidávalo, šlo procesory Intelu a AMD s dostatkem triků donutit, aby byly dost kompatibilní na živou migraci hosta. Výrobci se ale od té doby rozcházejí způsobem, který Xen nedokáže vyrovnat, a s příchodem bezpečnostních problémů se spekulativním prováděním se možnost, že by to bylo použitelné, uzavřela.“

Tiskovou zprávu k vydání rozeslala Linux Foundation, pod kterou Xen spadá. Tuhle položku neuvádí; je jen v seznamu změn od projektu.

Kvóty na Xenstore

Xenstore je malá stromová databáze, kterou si hypervizor, správcovská doména a jednotliví hosté předávají konfiguraci a oznámení o změnách. Host do ní může zapisovat a může si hlídat, kdy se něco změní.

Xen 4.22 na to nasazuje strop: kvótu na doménu a takzvanou hloubku sledování, tedy mez pro to, jak hluboko se dá zanořit hlídání změn. Podle tiskové zprávy je to obrana proti hostovi, který si bere víc zdrojů, než mu patří. Kvóty dávají smysl tam, kde na jednom stroji běží zákazníci, kteří o sobě navzájem nevědí. Takového provozu přibývá: v letošním průzkumu Uptime Institute mají cizí datová centra poprvé největší podíl firemní zátěže.

Co je v seznamu změn a co jen v tiskové zprávě

Z novinek pro procesory je v seznamu podpora funkce Bus Lock Threshold na čipech AMD Zen 5 a novějších. Když host zneužívá pomalé atomické instrukce, které zamykají celou sběrnici, Xen mu je nově omezí tempem, aby tím netrpěl celý stroj. Přibylo také načítání mikrokódu z archivu CPIO v samostatných modulech zavaděče a příkaz get-core-temp v nástroji xenpm, který na platformách Intelu vypíše teploty jader.

Tisková zpráva ale na prvním místě uvádí něco jiného: podporu FRED (Flexible Return and Event Delivery), tedy nového způsobu, jakým procesory x86 obsluhují přerušení, výjimky a systémová volání. Odvolává se na ni i citovaný zástupce Citrixu. V materiálech samotného projektu FRED nenajdete ani jednou, ať už v poznámkách k vydání, v přehledu funkcí nebo v souboru CHANGELOG.md.

Kód pro něj ve verzi 4.22 je. Soubor entry-fred.S, který obsluhuje vstupní body FREDu, ve značce RELEASE-4.22.0 leží; ve značce RELEASE-4.21.0 chybí. Autor ho napsal v prosinci 2024, do stromu se ale dostal až letos v březnu, tedy v cyklu 4.22. Rozpor mezi oběma zdroji nerozhodneme, jen ho zaznamenáváme: podle nás je pravděpodobnější, že tiskovou zprávu psal někdo štědřeji než správci seznamu změn, než že by šlo o omyl v datu.

Arm a RISC-V

Na Armu umí hosté nově uspat se do paměti a zase se probudit, a to standardní cestou přes rozhraní PSCI. Platí to jen pro obyčejné hosty, ne pro doménu, která má přímý přístup k hardwaru. Pokračuje také podpora profilu Armv8-R s jednotkou MPU, kterou používají systémy s nároky na funkční bezpečnost, a rozhraní FF-A se posunulo na verzi 1.2. Naopak podpora instrukční sady ThumbEE z Xenu zmizela.

U RISC-V je vidět, že je celá věc rozdělaná. Rozšíření SSTC pro časovače umí zatím jen sám Xen, hosté ne. Přibyly pomocné funkce pro sestavení domény z popisu hardwaru (device tree), což je podle projektu základ pro budoucí spouštění hostů. Kdo si chce Xen pro RISC-V přeložit, potřebuje překladač gcc aspoň ve verzi 12.2, kdežto pro x86 a Arm stačí 5.1.

Kdo do Xenu mluví

Na seznamu členů projektu jsou vedle AMD, Armu a AWS také Ford, Honda, Renesas, EPAM a Vates. Právě odtud jsou skoro všechny citace v tiskové zprávě. Kazuo Tsubouchi z Hondy v ní mluví o softwarově definovaných vozidlech a o tom, že různé úlohy s různými nároky mají běžet na společné výpočetní platformě; Aish Dubey z Renesasu o mixed-criticality systémech, tedy o strojích, kde vedle sebe běží úloha, na které závisí bezpečnost, a úloha, na které nezávisí nic.

Artem Mygaiev z EPAM popisuje práci skupiny pro funkční bezpečnost: nové nástroje postavené na QEMU umožňují opakovaně vstřikovat do systému poruchy a měřit, jak se zachová, k tomu přibylo měření pokrytí kódu testy až po úroveň modifikovaného pokrytí podmínek a rozhodnutí (MC/DC) a strukturované fuzzování. Ford uvádí, že do projektu poslal prvního mentorovaného vývojáře. Vates si podle svého vyjádření vzal na starost hlavně rozjezd RISC-V.

Co se vyhodilo

Kromě cizích výrobců procesoru zmizely z Xenu volby cpuid_mask_*, označené za zastaralé už ve verzi 4.7, a rozhraní SYSCTL_get_cpu_levelling_caps, o kterém projekt píše, že ho nejspíš nepoužívala žádná nadstavba. Skončila podpora Xenoprofile: nástroj oprofile sám přestal Xen podporovat v roce 2014 a od té doby se na tom v Xenu nic nedělalo. Nástroj xenpm se přestal stavět mimo x86, protože tam stejně nic užitečného neuměl.

Změna, o kterou zakopnou správci nadstaveb: volání pro vytvoření domény teď chce hodnotu DOMID_ANY, když má číslo přidělit systém sám. Dřívější zástupné hodnoty už nic takového neznamenají.

Zdroje: tisková zpráva Linux Foundation, poznámky k vydání a přehled funkcí na wiki projektu, CHANGELOG.md ve značce RELEASE-4.22.0 a zpráva o vydání na Phoronixu. Značku RELEASE-4.22.0 podepsal Andrew Cooper 29. července ve 20:06 UTC, tedy den před oznámením.

Čtyřicet šest ku čtyřiačtyřiceti

Uptime se firemních respondentů každý rok ptá, jaký podíl svých zátěží provozují ve vlastní režii a jaký v cizím zařízení. Letos vyšlo 46 procent na datová centra třetích stran a 44 procent na vlastní dedikované haly. Zbylých 10 procent běží v serverovnách a rozvaděčích, tedy v prostorách, které firmy provozují samy, jen to nejsou plnohodnotná datová centra. Do roku 2028 podle odhadu analytiků Uptime zůstane podíl vlastních hal stejný a cizí vzroste na 48 procent, a to právě na úkor těch improvizovaných serveroven.

Ta čísla stojí za pozorné čtení. Server The Register, který shrnutí zprávy četl, dal svému článku titulek The majority of corporate IT is now off premises for the first time, tedy že většina firemního IT je poprvé mimo vlastní prostory. Jeho vlastními čísly to ale podložené není. Většina znamená víc než polovinu a 46 procent víc než polovina není. Zbylých 10 procent popisuje Uptime jako serverovny a rozvaděče namísto vyhrazeného zařízení, tedy jako prostory u firmy, ne u poskytovatele; pokud je to tak, běží ve vlastní režii 54 procent zátěží. Přesné je proto „největší jednotlivý podíl“, ne „většina“.

Průměrný stojan přes 11 kW, typický 7,8

Druhé číslo, které se dá snadno přečíst špatně, je hustota výkonu. Průměr nejčastějších hodnot letos poprvé překročil 11 kW na stojan. Zvedla ho ale hrstka nových hal se stojany nad 30 kW; bez nich průměr sedí na 7,8 kW proti 7,5 kW v roce 2025. Titulky o 120 kW na stojan patří k infrastruktuře pro umělou inteligenci, ne k tomu, co stojí v běžném sále.

Stojan nad 30 kW nemá pořád většina zařízení. Aspoň jeden takový hlásí 24 procent dotázaných proti 19 procentům loni a přírůstek je hlavně v pásmu nad 50 kW. Patří do něj i provozovatelé, kteří dávají servery s grafickými akcelerátory do stojanů zapojených nad 100 kW.

Výpadků ubývá, účet za ně roste

Podíl respondentů, kteří za poslední tři roky zažili výpadek, klesl šestý rok v řadě, letos o tři procentní body. Uptime k tomu hned dodává, čeho naopak přibývá: omezené a nestabilní dodávky elektřiny, horší spolehlivost místních sítí, potíže v dodavatelském řetězci a extrémní počasí.

Co roste, je cena. Nejhorší výpadek stál aspoň sto tisíc dolarů 71 procent dotázaných, loni to bylo 57 procent. Vysvětlení, které zpráva nabízí, je prosté: firmy jsou na digitální infrastruktuře závislejší než dřív, takže tatáž hodina výpadku bolí víc. Jeden z deseti výpadků je podle tiskové zprávy pořád vážný nebo závažný.

Elektrikáře shání víc než polovina provozovatelů

Největší mezery v dovednostech hlásí provozovatelé u elektro profesí (38 procent) a u juniorních provozních rolí (rovněž 38 procent), dál u řízení provozu (35 procent) a u strojních profesí (34 procent). Vhodné uchazeče na volná místa hledá obtížně 53 procent provozovatelů proti 46 procentům loni. Tisková zpráva k tomu doplňuje, že lidi odvádějí hlavně konkurenční provozovatelé datových center.

Co průzkum umí a co ne

Uptime sesbíral odpovědi od více než 800 majitelů a provozovatelů datových center, přes internet a e-mailem. Necelá čtvrtina respondentů pracuje pro poskytovatele služeb třetích stran, tedy pro kolokaci, velkoobchodní pronájem nebo cloud. Přes polovinu, 52 procent, sídlí v Severní Americe a Evropě. Sama zpráva upozorňuje, že počet odpovědí se u jednotlivých otázek liší, protože respondenti nemusí odpovědět na všechno.

Vzorek tedy nevznikl náhodným výběrem; odpověděl ten, kdo chtěl. Meziroční srovnání ukazuje, jak se mění odpovědi, ne nutně jak se mění celý obor. Veřejně dostupné je třináctistránkové shrnutí, a i to až po vyplnění formuláře; plná zpráva má 32 stran a je pro zákazníky Uptime.

Zajímavější než jednotlivé číslo je, co v tiskové zprávě chybí. Přesun zátěží mimo vlastní haly v ní nepadne ani jednou a stejně tak v ní nejsou hodnoty 11 kW, 7,8 kW ani 71 procent. Uptime do ní dal hustotu stojanů, výpadky, nábor lidí a udržitelnost. Kdo chce ta čísla, musí do shrnutí.

Průzkum sám žádné doporučení nedává. Podle nás je z něj ale vidět jedna praktická věc: o tom, kde firemní IT poběží, rozhoduje čím dál víc dostupnost elektřiny a lidí, ne cena serverů. Podobným směrem šel americký úřad NOAA, který na konci července oznámil přesun provozních superpočítačů pro předpověď počasí do komerčního cloudu.

Zdroje: stránka zprávy Global Data Center Survey Results 2026 na webu Uptime Institute, tisková zpráva Uptime Institute z 28. července 2026 v plném znění tak, jak ji rozeslala agentura Business Wire, a článek Dana Robinsona v The Registeru z 30. července 2026, ze kterého pocházejí čísla ze shrnutí zprávy.

Jde o rozšíření ovladače HSMP (Host System Management Port). Ten v jádře je, ale dosud sloužil jen serverovým procesorům Epyc. Patche ho otevírají chystaným čipům řady Zen 6 – a v popisu jsou vyjmenované modely, které tím vznikají:

• Models 80h–87h: Medusa1, mobilní APU
• Models 88h–8Fh: Olympic Ridge, desktopové procesory
• Models E0h–E3h: Medusa2

HSMP je rozhraní, kterým se operační systém baví s řídicí jednotkou uvnitř procesoru. Na serverech se přes něj čtou teploty a spotřeba a nastavují se limity příkonu – správce datového sálu tak může procesoru přikázat, kolik smí brát. Dosud znal jen serverovou stranu.

Klientský čip mluví jinou řečí než serverový

Není to jen doplnění seznamu. Autor patchů Muralidhara M K v popisu píše, že klientské části používají jinou schránku (mailbox) než serverové rozhraní HSMP a že mluví sadou zpráv Ryzen Master SMC, ne serverovými identifikátory. Ovladač proto musí od sebe obě sady rozeznat a pro každou platformu sáhnout do jiné tabulky.

Řeší to tak, že se platforma popíše jednou a ovladač se pak ptá popisu, ne pokaždé znovu čipu: jedna struktura drží adresy schránky, tabulku zpráv i její velikost. Popis pro server v ní zůstává jako výchozí hodnota, aby se ovladač nemohl dostat k prázdnému ukazateli ani při volání, se kterým autoři nepočítali.

Druhý rozdíl je nepříjemnější: klientské čipy podle popisu neohlašují adresu té schránky nijak, takže ji ovladač nemůže najít. Musí ji mít napevno zapsanou ve zdrojovém kódu.

Co se tím otevírá

Server Phoronix, který si patchů všiml, vypisuje, co klientské zprávy umějí: čtení senzorů a metrik, nastavení teplotního stropu TjMax, zapnutí a vypnutí přetaktování, nastavení frekvence pro všechna jádra, napětí (OC VID) a změnu frekvence sběrnice FCLK za běhu.

Tedy zhruba to, co na Windows dělá Ryzen Master.

Jenže tím to končí

Patche přidávají jen ovladač v jádře. Žádný program, kterým by to šlo ovládat, AMD neohlásilo – a Phoronix k tomu podotýká, že u grafických karet Radeon firma na Linuxu vlastní ovládací panel taky nenabízí a nechává to na otevřených projektech. Jestli Ryzen Master na Linux přijde, nebo jestli se rozhraní chopí někdo jiný, se z patchů vyčíst nedá.

Zájem se ale ozval hned. V konferenci na patche reagoval vývojář Armin Wolf, který upozornil na příbuzné rozhraní ve firmwaru a napsal doslova: „Vlastním několik zařízení s takovým rozhraním a rád bych pro ně podporu přidal.“ (přeloženo)

Sérii prošel patch po patchi vývojář Mario Limonciello; k několika z nich se hned druhý den vyjádřil i jejich autor. Připomínkové kolo tedy běží a podoba, ve které kód nakonec do jádra půjde, se ještě může změnit.

Kdy to bude

Zatím nijak brzy. Patche jsou v prvním kole připomínek, vývojáři je připomínkují a čipy, kterých se týkají, se ještě neprodávají. Do jádra se dostanou nejdřív poté, co je správci přijmou; teprve pak přijde na řadu otázka, čím to bude ovládat běžný uživatel.

Za pozornost to stojí z jiného důvodu: dosud platilo, že HSMP je serverová věc. Tohle je poprvé, co se otevírá i domácím strojům.

Zdroje

• Konference jádra Linuxu: PATCH 1/7 platform/x86/amd/hsmp – Add HSMP client support (29.–30. 7. 2026)
• Phoronix: AMD Zen 6 Client HSMP Patches Point To „Ryzen Master“ Functionality On Linux (30. 7. 2026)

Rychlost přinesla vrstva pod normou

Verzi 5.0 vydal JEDEC v únoru 2026 pod označením JESD220H a nahradil jí JESD220G z prosince 2024, kterou trh zná jako UFS 4.1. Sama norma ale žádný signál nepřenáší. To dělá dvojice specifikací od sdružení MIPI a právě odtud rychlost pochází. Kioxia se na ně ve své zprávě výslovně odvolává.

MIPI vydalo M-PHY v6.0 a UniPro v3.0 24. února. M-PHY 6.0 přidalo nový vysokorychlostní stupeň HS-G6, který místo dvou napěťových úrovní používá čtyři, tedy modulaci PAM4. Jedna linka tím zvládne nejvýš 46,694 Gb/s, dvojnásobek předchozího stupně. Druhá změna je nenápadnější a užitečná stejně: nové kódování linky 1b1b srazilo režii fyzické vrstvy pod deset procent, takže z hrubé rychlosti zbude na data víc než dřív. Úložiště telefonu jede po dvou linkách, dohromady tedy zhruba 10,8 GB/s užitečné propustnosti.

Čísla Kioxie a Samsungu

Kioxia udává sekvenční čtení až 10 GB/s a zápis až 9,0 GB/s. Čip staví na vlastním řadiči a na paměti BiCS FLASH osmé generace, kapacity jsou dvě, 512 GB a 1 TB. Údaj o čtení firma vztahuje k oběma modelům, údaj o zápisu jen k terabajtovému.

Kioxia v téže zprávě sama uvádí, že rozhraní teoreticky zvládne asi 10,8 GB/s. Její čip tedy slibuje o 0,8 GB/s míň, než kolik dovoluje sběrnice pod ním.

Samsung ohlásil vlastní paměť UFS 5.0 už 23. června a udává čísla o kousek vyšší: čtení až 10,8 GB/s a zápis až 9,5 GB/s. Označuje se přitom za prvního výrobce, který takovou paměť vyvinul, a za držitele nejvyšší propustnosti v oboru. Pouzdro má rozměry 7,5 × 13 × 0,9 mm, což je podle firmy o 16,7 % méně než u předchozí generace. Vůči čemu se to procento počítá, zpráva neuvádí. Sériová výroba má začít ve čtvrtém čtvrtletí letošního roku.

Kde jsou obě zprávy mlhavé

Spotřebu vyčíslil jen Samsung: udává o víc než 40 % lepší energetickou účinnost proti své vlastní paměti UFS 4.1 a jmenuje i důvody, hradlování hodin a práci s několika napájecími napětími. Kioxia píše jen o lepší energetické účinnosti a žádné číslo neuvádí.

Obě firmy se navíc srovnávají samy se sebou, ne s konkurencí. Kioxia v poznámkách jmenuje konkrétní starší typy THGJFRT2G48BATV a THGJFRT3G88BATW, Samsung se odvolává na svou vlastní paměť UFS 4.1. Přímé srovnání obou nových pamětí za stejných podmínek tak zatím neexistuje.

Hlavně ale ani jedna firma nejmenuje přístroj. Kioxia své čipy popisuje jako obchodní vzorky a sériovou výrobu čeká do konce roku, Samsung míří na čtvrté čtvrtletí. Telefon s pamětí UFS 5.0 podle nás dřív než v příštím roce nekoupíte, ale je to odhad z termínů výroby, ne údaj od výrobce.

Vedle telefonu i datové centrum

O den později, 30. července, přidala Kioxia oznámení z opačného konce trhu: řadu podnikových disků CM10. Je to podle firmy její první podnikové SSD s rozhraním PCIe 6.0, postavené na paměti BiCS FLASH desáté generace s 332 vrstvami. Kapacity sahají od 1,60 TB do 61,44 TB. Chladit kapalinou přes studenou desku jde podle zprávy u provedení E3.S a E1.S 9,5 mm, ostatní jedou na vzduchu.

Tisková zpráva absolutní rychlosti neuvádí, jen přírůstky proti předchozí řadě CM9: asi o 92 % rychlejší sekvenční čtení a asi o 85 % rychlejší náhodné čtení. Konkrétní čísla, 28,4 GB/s a 6,29 milionu náhodných čtení za sekundu, uvedl server The Register. Pozor na jeden detail schovaný v poznámce pod zprávou: dvouapůlpalcové provedení je pořád PCIe 5.0 a osmá generace paměti, takže „první PCIe 6.0“ neplatí pro celou řadu.

I disky CM10 jsou zatím jen vzorky pro vybrané zákazníky a Kioxia u nich výslovně píše, že slouží k ověření funkce a že se jejich parametry můžou od sériové výroby lišit. Obojí, paměti i disky, chce firma ukázat na veletrhu FMS: the Future of Memory and Storage, který se koná od 4. do 6. srpna v kalifornské Santa Claře.

Zdroje

• Kioxia: New UFS 5.0 Embedded Flash Memory Devices from Kioxia Enable On-Device AI (29. července 2026)
• Kioxia: Introduces First PCIe 6.0 Enterprise SSDs Utilizing Newest BiCS FLASH Generation 10 Flash Memory (30. července 2026)
• Samsung: Samsung Unveils Industry's Fastest UFS 5.0 Solution for Next-Gen On-Device AI Applications (23. června 2026)
• MIPI Alliance: M-PHY, přehled změn ve verzi 6.0
• JEDEC: Universal Flash Storage (UFS) Version 5.0, JESD220H (únor 2026)
• The Register: Kioxia launches KV caching SSD and AI-focussed fingernail drive (30. července 2026)

Microsoft mění v klasickém Outlooku místo, odkud se spouští Copilot. Tlačítko se přesune vedle pásu karet, kde už ho mají Word, Excel a PowerPoint, a zapne se samo – ale jen tomu, kdo má licenci Microsoft 365 Copilot. Rozesílat se začne koncem srpna.

Co se mění

Změna je vedená v roadmapě Microsoftu pod číslem 567007 a je v ní zapsaná od 22. července 2026. Stav má „In development“, tedy ve vývoji.

Popis v roadmapě je psaný firemním jazykem, ale jedna věta z něj říká, o co jde: nové rozhraní podle Microsoftu „ukotvuje Copilota jako jeden propojený systém napříč Microsoftem 365 a nabízí relevantní akce, které pomáhají zůstat v proudu“ (přeloženo). Prakticky to znamená, že Copilot přestane být rozesetý po různých místech rozhraní a dostane v každé aplikaci totéž stálé místo – vedle pásu karet, ne v něm.

Klasický Outlook je poslední na řadě. Roadmapa uvádí, že v ostatních podobách Outlooku i ve Wordu, Excelu a PowerPointu už tenhle vstupní bod je.

Kdy a komu se objeví

Podrobnosti Microsoft rozeslal správcům 29. července do centra zpráv v administraci pod označením MC1441784. Rozvržení je odstupňované podle prostředí:

• běžné organizace – od konce srpna, hotovo do konce září 2026;
• GCC a GCC High (americká státní správa) – od konce srpna do začátku října;
• DoD (ministerstvo obrany) – od konce srpna do poloviny října.

Roadmapa přitom u dostupnosti uvádí jen „srpen 2026“. Ta dvě čísla si neodporují, jen popisují jinou věc: roadmapa začátek, zpráva správcům celé rozvržení včetně dojezdu.

Týká se to uživatelů klasického Outlooku pro Windows, kteří mají licenci Microsoft 365 Copilot. Kdo ji nemá, žádné nové tlačítko neuvidí.

Co zůstává, jak bylo

Microsoft ve zprávě výslovně uvádí, že se nemění licenční požadavky ani nastavení pro správce. Boční panel Copilotu zůstává tam, kde je; nové tlačítko je jen další způsob, jak ho otevřít.

Akce podle Microsoftu není potřeba žádná. Doporučuje jen upozornit uživatele, přepsat interní návody, které odkazují na staré umístění, a dát vědět podpoře.

Proč se u tlačítek Copilotu čeká na potíže

Umístění Copilotu v Office má za sebou jeden ústup. Když Microsoft nasadil ve Wordu, Excelu a PowerPointu plovoucí tlačítko, které se vznášelo nad dokumentem, podle The Register narazil na takovou nevoli, že uživatelům dovolil odsunout ho do oblasti pásu karet.

V Outlooku k tomuhle sporu dojít nemá: tlačítko bude u pásu karet, ne nad zprávami. Zdroje se tu rozcházejí ve slovech: Microsoft ve zprávě správcům píše „next to the ribbon“, tedy vedle pásu karet, kdežto The Register „above the ribbon“, tedy nad ním. Držíme se znění Microsoftu. Server také uvádí, že klasický Outlook má podporu nejméně do roku 2029 a že se lhůta pro odmítnutí přechodu na nový Outlook posunula na rok 2027 – obojí je údaj The Register, primární dokument Microsoftu k tomu nemáme.

Naše hodnocení

Podle nás je to drobnost, která se ale dotkne velkého počtu lidí naráz a bez jejich přičinění. Sjednocení rozhraní napříč aplikacemi dává smysl a boční panel zůstává, takže nikdo o nic nepřijde. Sporné je, že se to zapne ve výchozím stavu a zpráva správcům žádnou možnost, jak to vypnout, neuvádí – jediné, co Microsoft doporučuje, je informovat lidi předem.

Zdroje

• Microsoft 365 Roadmap, položka 567007 – titulek, popis, stav a data
• Znění zprávy MC1441784 z centra zpráv Microsoftu (29. 7. 2026)
• The Register: Microsoft makes Copilot harder to miss in Classic Outlook (30. 7. 2026)

Základní desku pro moderní procesor obsluhuje firmware, který dodává výrobce desky a jehož zdrojový kód nikdo zvenčí nevidí. Projekt coreboot to dlouhodobě mění, jenže u novějších platforem naráží na to, že výrobci čipů nezveřejňují kód pro rozběh vlastního křemíku. Firma 3mdeb teď oznámila vydání Dasharo v0.9.0 pro desku MSI PRO B850-P WIFI. Podle ní jde o první otevřený firmware pro moderní desktopovou platformu AMD.

Coreboot, openSIL a jeden konkrétní kus železa

Dasharo je sestava firmwaru, kterou 3mdeb staví z corebootu a z EDK II, tedy z referenční implementace rozhraní UEFI. Verze pro desku MSI stojí na corebootu 25.12. Chybějící část, totiž inicializaci procesoru a paměti, doplňuje AMD openSIL – knihovny, které AMD vydává jako zdrojový kód a které se do firmwaru přilinkují.

Právě openSIL určuje, s jakým procesorem deska nastartuje, a tady je hlavní omezení celého vydání. Použitá větev pokrývá jádra Phoenix (Zen 4), tedy procesory Ryzen 8300, 8400, 8500, 8600 a 8700. Deska přitom sama o sobě zvládne i běžné Ryzeny 7000 a 9000; s Dasharem se ale nerozběhnou. Ryzen 9000 je Zen 5 s označením Granite Ridge a odpovídající větev openSIL zatím nevznikla – repozitář projektu jich má tři, pro rodiny Genoa, Phoenix a Turin. Nefungují ani modely s přidanou vyrovnávací pamětí X3D, protože v rodině Phoenix žádný takový není.

Nejvýkonnější podporovaný procesor je tedy Ryzen 7 8700G s osmi jádry a šestnácti vlákny. 3mdeb ale přiznává, že vydání otestovala jen na slabším Ryzenu 5 8600G.

Kód, který AMD samo označuje za nehotový

Větev, ze které firmware vychází, se jmenuje phoenix_poc a zkratka na konci není náhodná. Hned v úvodu jejího souboru README stojí, že jde o proof of concept, který není určený pro produkční firmware, a že se na něj proto nevztahuje ani odměnový program AMD pro hlášení chyb. Vlastní plán projektu má čtyři fáze: první tři jsou označené jako hotové a všechny tři jsou výslovně jen k vyzkoušení. Produkční fáze je v dokumentu vedená jako očekávaná v roce 2026.

Podle nás je to ta nejdůležitější věta celé zprávy. Firmware existuje a startuje, ale opora, na které stojí, je z pohledu jeho dodavatele pořád pokus.

Co v něm funguje

Seznam funkcí není krátký. Dasharo v0.9.0 umí UEFI Secure Boot, heslo do nastavení firmwaru, vypnutí USB nebo síťové části zásobníku, hesla pro disky přes TCG OPAL i SATA a přesměrování konzole na sériový port. Zápis do BIOSu hlídá režim SMM spolu s AMD ROM Armor 3.

Samostatný čip TPM deska nepotřebuje. Firmware zapíná fTPM, tedy implementaci TPM 2.0 běžící uvnitř bezpečnostního koprocesoru AMD PSP; podle 3mdeb zvládne měřený start, BitLocker i Windows Hello. Druhý start bývá rychlejší, protože si firmware uloží kontext paměti a při dalším zapnutí ho jen obnoví. Diagnostické LED na desce hlásí postup – ale jen ty pro paměť a procesor, kontrolky pro grafiku a zavádění systému zatím zůstávají nevyužité. Firmware také hlásí teplotu procesoru přes ACPI a nese soupis binárních částí, které v něm zbyly.

Otestované systémy jsou dva: Ubuntu 26.04 LTS a Windows 11 25H2.

Kolik uzavřeného kódu zbylo

Dasharo u každé podporované desky počítá skóre otevřenosti, tedy poměr otevřeného kódu k binárním blobům. Proti firmwaru výrobce, konkrétně proti obrazu E7E56AMSI.2A92, uvádí 3mdeb o 79,1 % méně uzavřeného kódu a o 377,3 % víc volného místa v obrazu. Třetí položka téže tabulky, rozdíl v objemu dat, vyšla v absurdních stovkách milionů procent; 3mdeb sama vysvětluje, že nástroj v BIOSu výrobce žádná data nenašel a aby nedělil nulou, dosadil jedničku.

Co ze zavřeného kódu zbývá, je hlavně firmware PSP – bloby, bez kterých se procesor nerozběhne a které AMD jako zdrojový kód nevydává. Podobný podíl vyšel podle 3mdeb i na serverové desce Gigabyte MZ33-AR1, pro kterou firma vydala Dasharo ve stejné verzi letos v květnu.

Čtyři chyby, ke kterým se vydání hlásí

Aktualizace firmwaru přes kapsli UEFI funguje jen okamžitá; ta odložená restart nepřežije, protože se u moderních platforem AMD data v paměti ztratí. Nefunguje obnovení stavu napájení do vypnutého stavu, spolehlivě jdou nastavit jen možnosti „vždy zapnuto“ a „vždy vypnuto“. Ubuntu 26.04 se zapnutou sériovou konzolí občas zamrzne při startu; obejde se to jejím vypnutím v nastavení. A poslední: Wi-Fi karta se občas neobjeví na seznamu zařízení PCI a je pryč i pro systém. Vrátí ji reset paměti CMOS a 3mdeb dodává, že totéž se děje i s firmwarem od výrobce desky.

Nastavovat se toho moc nedá

Víc voleb než firmware od výrobce nový firmware nenabídne. Většina nastavení u platforem AMD nesedí ve firmwaru, ale v datové struktuře APCB, kterou coreboot neumí měnit a jejíž formát není veřejně popsaný. Přetaktování navíc obsluhuje ještě jiný koprocesor, SMU. „Komunita, která od platforem AMD čeká funkce, laditelné volby a přetaktování, bude muset trochu zchladnout, protože nic z toho v dohledné době nebude,“ píše 3mdeb v překladu. Šifrování paměti TSME zůstává u Ryzenů rodiny Phoenix bez označení PRO zakázané na úrovni PSP a firma to sama komentuje tak, že je to rozhodnutí AMD.

Chybí i payload Heads, který se v okruhu otevřeného firmwaru používá pro ověřený start; podle 3mdeb není ani v nejbližších plánech.

Co má přijít dál

Nejbližší kroky, které firma jmenuje, jsou dva. Dostat kód pro Phoenix i pro samotnou desku do hlavní větve corebootu a poslat úpravy zpět do openSIL. A pak opravy: kapsle, stav napájení, zamrzání Ubuntu a mizející Wi-Fi. K tomu má přibýt ochrana proti přímému přístupu do paměti ještě před startem systému, nastavením jednotky IOMMU během POST – vede se k ní otevřený tiket #1880.

Deska sama je běžné zboží. Michael Larabel z Phoronixu, který o vydání psal den po oznámení, uvádí, že ji na začátku roku koupil asi za 179 dolarů a že se dnes u velkých prodejců prodává kolem 300 dolarů. Otevřený firmware tak běží na desce, kterou si může koupit kdokoli – procesor do ní ale musí být z jedné konkrétní řady.

Zdroje: oznámení vydání na blogu 3mdeb, větev phoenix_poc v repozitáři openSIL, zpráva na Phoronixu.

Co ty čtyři záplaty dělají

ALLM je zkratka pro Auto Low-Latency Mode. Počítač jím řekne televizi nebo monitoru, ať si zapne svůj herní režim, tedy ať vypne dodatečné zpracování obrazu, které přidává prodlevu. Ovladač amdgpu ten příznak dosud neposílal vůbec. „amdgpu nikdy nenastavoval ALLM_Mode v HF-VSIF, takže se ALLM přijímači nikdy neohlásilo,“ stojí v popisu záplaty (přeloženo; HF-VSIF je informační rámec, kterým zdroj obrazu posílá displeji doplňkové údaje). Nově se příznak zapne ve dvou případech: když si program nastaví typ obsahu na hru, nebo když zrovna běží proměnlivá frekvence.

Druhá polovina série řeší právě tu proměnlivou frekvenci. Ovladač si dosud schopnost FreeSync četl jen z toho kusu EDID, který do popisu displeje zapisuje AMD. EDID je sada údajů, kterými se monitor počítači představí. Přijímače, které ohlašují jen variantu podle HDMI Fóra – třeba EDID používané při zkouškách shody –, tak vycházely jako zařízení bez podpory VRR. Nová záplata v takovém případě sáhne po rozsahu z bloku HF-VSDB, který do EDID zapisuje výrobce podle specifikace HDMI. Rozsah se přitom nebere jakýkoli: podle HDMI 2.1 platí za podporovaný jen tehdy, když spodní mez leží mezi 1 a 48 a horní je buď nula, což znamená „až do základní obnovovací frekvence“, nebo aspoň 100.

Čtení těch údajů z EDID nenapsalo AMD. Záplata, která je do společné části jádra přidává, má jako autora Tomasze Pakułu, který v ní vystupuje s vlastní, ne firemní adresou; podepsaný je pod ní i Zuo a otestoval ji Bernhard Berger.

Proč se čekalo od roku 2020

Hlášení, ze kterého celá věc vyrostla, je na bugtrackeru freedesktop.org otevřené od 28. prosince 2020 a jmenuje se prostě 4k@120hz unavailable via HDMI 2.1. Rozlišení 4K při 120 snímcích za vteřinu potřebuje FRL, tedy přenosový režim HDMI 2.1 s vyšší propustností. A ten se v otevřeném ovladači implementovat nesměl.

Překážka nebyla technická. „HDMI Forum v tuto chvíli neumožňuje otevřenou implementaci HDMI 2.1,“ napsal do hlášení už 13. září 2021 inženýr AMD Alex Deucher (přeloženo). V únoru 2023 tam přibylo, že firma s právníky řeší, co může dodat, aniž poruší závazky vůči konsorciu. Konec přišel 28. února 2024: „HDMI Forum náš návrh bohužel zamítlo. V tuto chvíli není otevřená implementace HDMI 2.1 možná, aniž by narazila na požadavky HDMI Fóra,“ shrnul Deucher (přeloženo). Phoronix tehdy uzavřel, že linuxovým uživatelům zbývá DisplayPort.

Co se změnilo, AMD neřeklo

1. května 2026 se to zlomilo. Harry Wentland z AMD poslal na konferenci sérii jednadvaceti záplat, které FRL do ovladače přidávají. Devět z nich napsal Rodrigo Siqueira, který v AMD už nepracuje. „Dík Siqueirovi, který tuhle práci připravil před pár lety a bohužel ji nestihl poslat, dokud byl ještě v AMD,“ píše Wentland v průvodním dopise (přeloženo). Podle téhož dopisu série prošla reprezentativním výběrem zkoušek shody HDMI a plný běh byl v době odeslání teprve rozdělaný.

Co se mezi únorem 2024 a květnem 2026 změnilo, ale AMD veřejně nevysvětlilo. Přímo pod oznámením se na to jeden z diskutujících zeptal a odpověď nepřišla; poslední příspěvek někoho z firmy v tom hlášení je právě Deucherův odkaz na záplaty. Co k tomu píšou ostatní, jsou dohady, ne doklad.

Kdy to bude v jádře

Záplaty FRL byly zapsány 3. června 2026 a do hlavní větve jádra se dostaly hromadným sloučením větve drm-next 17. června. Jsou tedy součástí Linuxu 7.2. Ten zatím vyšel jen jako pátý kandidát na vydání, a to 26. července 2026. Ve verzi 7.1 ze 14. června FRL ještě nebyl; pozná se to strojově, protože commit „drm/amd/display: Tie FRL programming together in HWSS“ je předkem značky v7.2-rc1, ale ne značky v7.1.

Nové záplaty na ALLM a proměnlivou frekvenci míří do Linuxu 7.3. Podle Phoronixu je ale uzávěrka větve drm-next těsná, takže se může stát, že si počkají až na 7.4.

Pro majitele Radeonu s televizí nebo monitorem s HDMI 2.1 to znamená, že vyšší rozlišení a snímkovou frekvenci přes FRL přinese jádro 7.2, proměnlivou frekvenci přes HDMI zatím ne. Přes DisplayPort ji ovladač umí dlouho. Podle nás je na celé věci nejzajímavější to, že překážka nikdy nebyla v kódu, ale v tom, kdo ho směl vidět. Spor o to, co v otevřeném ovladači smí zůstat zavřené, se přitom vede dál – tento týden se Huawei ptal projektu Mesa na ovladač s uzavřenou částí kompilátoru.

Zdroje: série čtyř záplat na konferenci amd-gfx (30. července 2026), průvodní dopis série HDMI FRL (1. května 2026), hlášení drm/amd#1417 na freedesktop.org, porovnání commitu se značkou v7.2-rc1 přes API GitHubu a zprávy Phoronixu z 28. února 2024 a 30. července 2026.

Problém není kubit, ale kabel

Kubitů v křemíku přibývá rychleji než způsobů, jak k nim dostat signál. Autoři to popisují jako volbu ze tří možností: nechat řídicí hardware v pokojové teplotě a vést dolů stovky analogových linek, posadit ho rovnou ke kubitům do milikelvinů, kde by ho nikdo neuchladil, nebo hledat mezistupeň. HRL zvolila třetí cestu. Čtyři kelviny se chladit dají, jenže tím se problém jen posune: signály musí sjet ještě o dva řády níž a nesmějí s sebou vzít teplo.

Kubit ze tří elektronů

Čip nese 54 kvantových teček ve třech řadách. Jeden kubit tvoří společný spinový stav tří elektronů ve třech tečkách, takže se z pole dá poskládat až osmnáct kubitů v mřížce 3 × 6. Elektrony drží v kvantové jámě z křemíku a slitiny křemíku s germaniem, obojí izotopicky obohacené, aby ubylo magnetického šumu. Hradla nad jámou vznikla ve slévárenském procesu na dvousetmilimetrových destičkách; jeho podrobnosti si HRL nechává pro sebe.

Volba typu kubitu souvisí přímo s tím, co se od řadiče chce. Kubity řízené výhradně výměnnou interakcí potřebují jen napěťové pulzy v základním pásmu a na jejich tvaru nezáleží. Od obyčejného digitálního signálu se to neliší tak, aby na to nestačil úsporný CMOS.

Páska, která vede signál, ale ne teplo

Mezi řadičem a čipem vede plochý kabel z niobu na polyimidu. V jedné vrstvě široké zhruba centimetr je 296 koaxiálních linek a přeslech mezi nimi zůstává pod minus 80 dB až do 10 GHz. Kabel přenáší 150 časově proměnných řídicích signálů a 35 statických předpětí a ze čtyřkelvinového stupně do směšovací komory přitom pustí méně než 10 μW tepla. Cesta signálu tam a zpět trvá asi 3 ns.

Co má řadič uvnitř

Řadič je smíšený systém na čipu, vyrobený komerčním procesem RF CMOS se strukturami 130 nm. Má kolem 70 milionů tranzistorů a v běžném provozu spotřebuje nejvýš 3,5 W. Uvnitř je 78 téměř shodných analogových bloků se 156 výstupními kanály, 366 převodníky a 78 generátory pulzů. Pulz trvá typicky od 400 ps do 6 ns a jeho náběžná hrana kolem 150 ps. Digitální část běží až na 250 MHz, má vlastní instrukční sadu a 6 144 slov programové paměti.

Čísla

Průměrná chyba jednokubitového hradla vyšla 1,7 na deset tisíc, u hradla CNOT tři a půl tisíciny. Nejnižší opakovaně dosažená chyba CNOT byla devět desetitisícin. Proti dosavadním výsledkům s tímto typem kubitu je to podle autorů posun o řád.

U opravy chyb předvedla sestava dvě věci. Opakovací kód vzdálenosti pět běžel na sedmi kubitech s logickou chybovostí kolem pěti tisícin a proti průměru trojkových podmnožin z týchž dat vyšel poměr 4,7. Kvantový kód [[4,2,2]], který odhalí libovolnou chybu na jednom kubitu, běžel na šesti fyzických kubitech. Po třech kolech měření syndromu vyšla věrnost dvojice logických kubitů 0,95; kdyby se výsledky detekce ignorovaly, bylo by to 0,59. Výběr přijatelných běhů ale zahodí zhruba 77 % z deseti tisíc opakování.

Kde se tisková zpráva a článek rozcházejí

Tisková zpráva HRL uvádí, že oprava chyb proběhla poprvé celá na kryogenním řadiči, bez zásahu elektroniky v pokojové teplotě. V odborném článku takový nárok na prvenství není. Schéma sestavy navíc ukazuje, že z pokojové teploty pořád přichází digitální komunikace i statická předpětí a že se tam dál digitalizuje čtení stavu kubitů; autoři píšou, že tuhle funkci čekají uvnitř kryostatu teprve u dalších systémů.

Druhý rozdíl je v rychlosti. Zpráva mluví o operaci kratší než mikrosekunda. Článek u hradla CNOT uvádí 37 pulzů ve 45 časových krocích a takt mezi 12 a 28 ns, z čehož vychází zhruba 0,5 až 1,3 μs. Ten přepočet je náš, v článku ani ve zprávě nestojí.

Co zbývá a komu to bude patřit

Autoři sami vypisují, co chybí: vyrobitelné propojení a vyvedení signálů z čipu, řadiče s nižší spotřebou na kubit, vyrovnanější součástky, aby se tolik nezdržovalo laděním, a architektura, která počítá s tím, jak jsou zrovna tyhle kubity pospojované. Osmnáct kubitů je prototyp architektury, ne stroj na počítání.

Vlastník se přitom mění. IBM oznámilo 23. července 2026, že podepsalo závaznou dohodu o koupi HRL od Boeingu a General Motors. Cenu firmy nezveřejnily, obchod podléhá schválení úřadů a má se uzavřít do konce třetího čtvrtletí 2026. IBM staví na supravodivých kubitech a spinové kubity z HRL popisuje jako druhou schůdnou cestu ke škálování; zmiňuje i možnost napojit je na Anderon, samostatnou firmu ohlášenou v květnu 2026 jako slévárnu destiček pro kvantové čipy.

Jestli tahle sestava někam vede, se pozná až na čipu s řádově víc kubity. Zatím platí to, co autoři napsali sami: kvalitu výsledku neurčuje žádná jednotlivá součástka, ale to, jak dobře do sebe zapadají.

Zdroje

• A digitally controlled silicon quantum processing unit – odborný článek v Nature 655, 1154–1159, vydaný 29. července 2026 v otevřeném přístupu
• HRL demonstrates a silicon quantum processor that runs itself – tisková zpráva HRL z 29. července 2026
• IBM to Acquire HRL Laboratories to Power the Future of Quantum – tisková zpráva IBM z 23. července 2026

Co se stěhuje a co zůstává na místě

Oznámení se týká systému WCOSS, tedy provozních strojů, na kterých běží americké předpovědní modely. Jsou dva a jmenují se Dogwood a Cactus; první stojí v Manassasu ve Virginii, druhý v Phoenixu v Arizoně. NOAA je uvedla do provozu v červnu 2022, kdy měl každý z nich výkon 12,1 petaflopu, a v srpnu 2023 jim kapacitu zvedla o 20 procent na 14,5 petaflopu. Podle tehdejší zprávy zpracuje předpovědní systém dohromady 29 biliard operací za sekundu.

Výzkumné stroje NOAA v Západní Virginii, Tennessee, Mississippi a Coloradu, které měly v roce 2023 dohromady 20 petaflopů, se v oznámení nezmiňují vůbec. Řeč je o provozu, ne o vývoji.

Termíny uvádí zpráva dva. Přesun provozu včetně modelů Global Forecast System a Global Ensemble Forecast System, tedy globálního modelu a jeho souboru variant, má běžet do začátku roku 2027. Celý přechod má být dokončený v prosinci 2027. Rozdělený je na dvě fáze: v první se výpočetní kapacita v cloudu postaví, ve druhé se do ní jednotlivé modely přestěhují.

Železo: virtuální stroje H4D a procesory AMD

Google ve svém oznámení uvádí, že základem výkonu budou virtuální stroje H4D s procesory AMD Epyc pátého pokolení. Vedle výpočetního výkonu vyzdvihuje nízké zpoždění sítě mezi nimi, které je podle něj potřeba pro rozsáhlé propojené simulace. Totéž popisuje i server Data Center Dynamics.

U předpovědi počasí je to podstatné rozlišení. Model si zemskou atmosféru rozdělí do mřížky rozprostřené mezi tisíce jader a po každém časovém kroku si sousední uzly musí vyměnit hodnoty na svých hranicích. Když jedna výměna trvá o zlomek sekundy delší, prodlouží se celý výpočet. Proto se pro takové úlohy v cloudu nabízejí oddělené řady strojů s rychlým propojením, ne běžné virtuální servery.

Umělou inteligenci tam NOAA nasadila už v prosinci

Červencová zpráva zmiňuje i Google DeepMind jako základ nové sady modelů AIGFS, kterou označuje za první předpovědní modely NOAA poháněné strojovým učením. Sluší se dodat, že to není plán do budoucna: tuhle sadu NOAA oznámila 17. prosince 2025 a už tehdy ji označila za provozní.

Čísla z prosincové zprávy jsou zajímavější než ta cloudová. AIGFS spočítá jednu šestnáctidenní předpověď za asi 40 minut a spotřebuje na ni 0,3 procenta výpočetních prostředků, které by na totéž potřeboval klasický GFS. Soubor variant AIGEFS má 31 členů a vystačí si s devíti procenty prostředků klasického GEFS, přičemž jeho přesnost je podle NOAA srovnatelná a první výsledky ukazují použitelnou předpověď o 18 až 24 hodin dál. Nejzajímavější je HGEFS: dvaašedesátičlenný soubor slepený z 31 členů fyzikálního modelu a 31 členů toho neuronového, který podle NOAA ve většině hlavních ověřovacích ukazatelů překonává oba zdroje, ze kterých vznikl. NOAA k tomu uvádí, že pokud ví, je první organizací na světě, která takový hybridní soubor zavedla do provozu.

Modely nevznikly na zelené louce. Tým vyšel z modelu GraphCast od Google DeepMind a doladil ho na vlastních analýzách z Global Data Assimilation System, tedy na datech, se kterými NOAA pracuje sama.

Ke slabému místu se úřad hlásí v téže zprávě: verze 1.0 modelu AIGFS zhoršuje předpověď intenzity tropických cyklón, i když trasu předpovídá lépe než dosavadní GFS. Oprava má přijít v dalších verzích.

Za jednou větou červencové zprávy se přitom vyplatí zastavit. Stojí v ní, že nástroje příští generace, na kterých NOAA s Googlem pracuje, zkrátí dobu potřebnou k vytvoření globální předpovědi z hodin na pouhé sekundy. Je to budoucí čas a mluví o něčem, co ještě neběží. Model, který běží dnes, potřebuje podle NOAA na jednu předpověď těch 40 minut.

Co ve zprávě nestojí

Cena. Ani tisková zpráva NOAA, ani oznámení Googlu, ani odborné servery, které jsme prošli, neuvádějí, kolik bude cloudový provoz stát nebo na jak dlouho je dohoda sjednaná. U federálního úřadu je to údaj, který se obvykle dohledat dá; tady zatím nikde není.

Osud Dogwoodu a Cactusu. Zpráva neříká, jestli se stroje vypnou, prodají, nebo si je NOAA nechá jako záložní cestu. Podle The Registeru měl kontrakt na jejich stavbu a podporu cenu nejméně 150 milionů dolarů a za osm let mohl dosáhnout 505 milionů; NOAA v žádné ze svých zpráv o superpočítačích tuhle sumu neuvádí.

A ještě jedna formulace. NOAA o sobě píše, že bude jedním z prvních provozních center numerické předpovědi na světě, které přejde na komerční cloud. Ne prvním. Kdo z toho udělá titulek se slovem „poprvé“, tvrdí víc než úřad sám.

Nejsilnější z uvedených důvodů je podle nás ten, který se s pevným počtem skříní udělat nedá: přidat výkon zrovna v hurikánové sezoně, kdy je ho potřeba, a po ní ho zase pustit. To je vlastnost, kterou dvojice strojů v Manassasu a Phoenixu nemá a mít nemůže.

A co se stane mezi oběma termíny. Přesun modelů má běžet do začátku roku 2027, celý přechod skončit až v prosinci téhož roku; co v té skoro roční mezeře zbývá dodělat, zpráva nepíše.

Ověřit se to dá jednoduše. Buď na konci roku 2027 poběží GFS a GEFS v cloudu, nebo ne.

Zdroje: tiskové zprávy NOAA o přechodu do cloudu (27. července 2026), o modelech se strojovým učením (17. prosince 2025) a o rozšíření kapacity WCOSS (10. srpna 2023), dále oznámení Google Cloudu, zpráva na Data Center Dynamics a článek The Registeru o uvedení strojů Dogwood a Cactus.

Nový operační systém se dnes ohlašuje skoro každý měsíc a většina z nich skončí u README souboru. LiberSystem je jiný aspoň v jednom ohledu: kódu je tam hodně a přibývá rychle. Na druhou stranu je repozitář starý šest týdnů, hvězdiček má čtrnáct a stáhnout si hotový obraz nejde. Podívali jsme se, co za tím je.

Jádro jako malý rozhodčí

LiberSystem není distribuce Linuxu ani unixový klon. Je to samostatný systém psaný od nuly v jazyce Rust a postavený na mikrojádru. To znamená, že v privilegovaném režimu běží jen nezbytné minimum: správa paměti, plánování, meziprocesová komunikace a hlídání přístupu k hardwaru. Ovladače, souborové systémy i síť jsou obyčejné služby v uživatelském prostoru. Když ovladač spadne, správce zařízení mu odebere oprávnění a restartuje ho, místo aby padl celý stroj. Linux to má obráceně, většina ovladačů žije uvnitř monolitického jádra.

Druhý pilíř je kapabilitní model. Kapabilita je nepadělatelný odkaz na objekt jádra spolu se seznamem práv, jako je čtení, zápis nebo mapování paměti. Proces nemá žádná okolní oprávnění, dostane jen to, co mu někdo výslovně předá. Účet root, který smí všechno, v tomhle návrhu neexistuje vůbec. Dokumentace to shrnuje tak, že komponenta smí pojmenovat věc, na kterou nedosáhne, protože pravomoc žije jen v kapabilitě, ne ve jméně.

Třetí odlišnost se týká disků. Místo jednoho globálního stromu s přípojnými body pracuje LiberSystem s explicitními svazky. Cesta patří vždy právě jednomu svazku, který se identifikuje podle UUID, a je to typovaný objekt, ne řetězec znaků. Jednotlivé části cesty jsou položky seznamu, takže klasický útok přes dvě tečky a lomítko nemá kde vzniknout. Když svazek není dostupný, operace selže. Nikdy potichu nezapíše na jiný disk.

Aplikace: nativní rozhraní a nad ním WebAssembly

Základní smlouva pro aplikace je nativní typované rozhraní přes kapability, stejné, jaké používá jádro a systémové služby. Nad ním má běžet hostitel pro WebAssembly, konkrétně Component Model a rozhraní WASI. Kalkul je jednoduchý: jeden balíček aplikace poběží na architektuře x86-64, ARM64 i RISC-V a je izolovaný už z principu.

Autoři si přitom nechali zadní vrátka. V návrhovém dokumentu stojí, že WASI je jen jeden z hostitelů nad stabilním nativním kontraktem, ne definice systému. Pokud se ta poměrně mladá specifikace změní, přepíše se jedna vrstva a ne celé jádro. Kompatibilita s POSIX, tedy schopnost spouštět běžný unixový software, je v plánu jako volitelná překladová vrstva v uživatelském prostoru. Zatím není.

Co už opravdu běží

Snímky obrazovky na webu projektu ukazují víc než obvyklý „ahoj světe“ z jádra. Systém nabootuje pod emulátorem QEMU, rozjede všechna procesorová jádra (na snímku 52 z 52), spustí ovladače virtio pro disk, síť, konzoli, vstup, grafiku a zvuk, k tomu ovladač USB řadiče xHCI, přihlásí jedenáct zařízení a nastaví síť přes DHCP. Pak naskočí textový shell s výzvou ve tvaru vol://.

Na dalším snímku je vidět výpis přerušení, překlad doménového jména a příkaz ping, který umí vypsat výsledek jako JSON. To je praktická ukázka principu, na kterém systém stojí: existuje jedno typované rozhraní a binární podoba, JSON, CBOR i čitelný text jsou jen jeho reprezentace. Banner v konzoli hlásí verzi 0.0.1.

Sestavit se to dá zatím jen na Linuxu s noční verzí Rustu. Skript stáhne toolchain, příkaz just build přeloží jádro i uživatelskou část a just run ji spustí v emulátoru. Bootovatelný obraz pro reálný počítač s UEFI vyrobit jde, starý BIOS projekt nepodporuje. Jestli někdo LiberSystem skutečně nabootoval na fyzickém železe, se mi ověřit nepodařilo. Všechny doložené snímky pocházejí z emulátoru a i dokumentace mluví o testech v QEMU.

Kdo za tím stojí a jak je to staré

Za projektem je organizace LiberSoft, která na GitHubu vede i decentralizované sdílení souborů LiberShare a starší komunikační projekt Yellow. Všechno pod licencí Unlicense, tedy uvolněné do veřejného vlastnictví. Kontaktní adresa uvedená na webu vede do Liberlandu, což je mikrostát na sporném území u Dunaje. Web i návrhové dokumenty existují v české verzi a analytiku měří česká služba, takže čeští autoři jsou pravděpodobní. Konkrétní jména ale nikde uvedená nejsou a nepodařilo se mi je ověřit.

Repozitář vznikl 17. června 2026. Za šest týdnů do něj přibylo přes sedm set commitů, tempo se drží mezi osmdesáti a stošedesáti commity týdně a poslední změna je z dneška. Přispěvatel je ale jediný účet, forků nula, otevřených issues nula. Návrhový dokument má přes osmdesát kilobajtů textu a existuje v angličtině i češtině, k tomu je popsaný model hrozeb, vlastní jazyk pro definici rozhraní a formát nativního souborového systému. Na projekt starý šest týdnů je to nezvykle důkladná dokumentace.

Co chybí a kde je riziko

Vydání zatím žádné. Tlačítko „Stáhnout“ na webu vede na stránku vydání na GitHubu, která je prázdná, a projekt to sám přiznává větou, že vydání se publikují, jakmile budou k dispozici. Kdo si chce systém zkusit, musí ho přeložit ze zdrojových kódů.

Model hrozeb otevřeně vyjmenovává, co ještě řešené není: ověřený start systému a podepsaný obraz, postranní kanály typu Spectre, fyzické útoky na hardware, šifrované svazky ani formální verifikace jádra. Jádro je tedy důvěryhodné, ale nedokázané. To není podvod, je to poctivé přiznání stavu, ale mění to význam slova „bezpečný“ v marketingovém popisu.

Plán vývoje má sedm fází. Grafické rozhraní a desktop jsou až v páté, kompatibilita s POSIX a podpora reálných počítačů ve čtvrté. Aktuální prioritou je fáze pro takzvané appliance, tedy jednoúčelová síťová zařízení. Cesta k systému, na kterém by šlo pracovat, je pořád dlouhá.

Riziko číslo jedna je podle mého názoru jediný přispěvatel. Kód, dokumentace i web stojí na jednom účtu, a pokud ten přestane, nemá projekt kdo převzít. Slabinou je i licence Unlicense: dává maximální volnost, ale patenty neřeší nijak, což velké firmy u systémového softwaru sledují.

Pozornost zvenčí je zatím minimální. Odkaz na Hacker News z 8. července získal jediný bod a jediný komentář, ve kterém se čtenář ptá, čím se LiberSystem liší od existujících mikrojader v Rustu, jako je Redox, Tock nebo Xous. Odpověď tam nepřišla. Vlákno na fóru jazyka Rust má pár reakcí. České weby, které o projektu psaly, převzaly texty z jeho vlastních stránek a nic neověřovaly.

Pro koho to dnes je

Nasadit LiberSystem na cokoliv, na čem záleží, dnes nejde a autoři to netvrdí. Pokud hledáte bezpečnější počítač na práci, tohle není odpověď a nebude jí ani příští rok. Zajímavý je jinak: jako čitelně napsaný a rychle rostoucí příklad toho, jak by vypadal systém postavený od začátku na kapabilitách a typovaných objektech. Kdo se učí psát jádra nebo ho zajímá návrh operačních systémů, dostane osmdesát kilobajtů promyšleného textu zdarma a k tomu kód, který nabootuje.

Zdroje: web projektu LiberSystem, repozitář na GitHubu včetně návrhového dokumentu a modelu hrozeb, a diskuse na Hacker News. Údaje o stáří repozitáře, počtu commitů a přispěvatelů pocházejí z veřejného rozhraní GitHubu ke dni 27. července 2026.

Když si na displeji s vysokou hustotou bodů nastavíte zvětšení 150 procent, musí okenní systém spočítat, kde přesně okno začíná. Při zvětšení 100 nebo 200 procent vyjdou celá čísla. Při 150 procentech ne – a právě tam začíná potíž, kterou řeší nová verze kompozitoru Wayfire. Autoři ji popsali 24. července, vydání na GitHubu nese datum 27. července.

Celá čísla tam, kde celá čísla nestačí

Autoři to v oznámení popisují bez okolků: „Wayfire dosud většinu logické geometrie reprezentoval celočíselnými souřadnicemi“ (přeloženo). A hned dodávají, proč to přestalo stačit: „Funguje to dobře při celočíselném škálování výstupu, ale zlomková měřítka nevyhnutelně vytvářejí subpixelové souřadnice“ (přeloženo).

Jinými slovy: okno začínající na logickém bodě 100 při zvětšení 1,5 padne na fyzický pixel 150, což je v pořádku. Okno na bodě 101 ale padne na 151,5 – a takový pixel na displeji není. Někam se zaokrouhlit musí, a pokud každá vrstva zaokrouhluje sama za sebe, výsledky se rozejdou.

Nová verze proto přesouvá práci s geometrií „téměř celou na desetinná čísla“ a zaokrouhluje se až úplně na konci: „V poslední fázi vykreslování se tato čísla pečlivě převedou na celočíselné souřadnice a zarovnají s mřížkou framebufferu“ (přeloženo). Zaokrouhlení tedy nezmizelo – jen se děje jednou a na jednom místě.

Xwayland a ostrý text

Druhá změna míří na starší aplikace. Programy běžící přes Xwayland neumějí waylandové škálování, takže je kompozitor dosud vykreslil v menším rozlišení a výsledek zvětšil – odtud rozmazané okraje písma, které uživatelé HiDPI displejů znají.

Wayfire teď umí nechat Xwayland vykreslit každé okno rovnou v jeho nativním, tedy fyzickém rozlišení. Text pak může být ostřejší, ale podle autorů si to může vyžádat úpravu nastavení DPI v X11 i nastavení písma nebo škálování v jednotlivých aplikacích. Není to tedy přepínač, po kterém se všechno samo srovná.

Barvy a HDR s výhradou

Vydání dál přináší ICC profily pro jednotlivé výstupy, správu barev pro jednotlivé plochy a vykreslování v HDR. U HDR autoři sami připojují omezení: vyžaduje podporu ze strany vykreslovacího jádra, ovladače grafiky, konektoru i displeje – a úplná barevně spravovaná cesta zatím funguje jen s vykreslováním přes Vulkan.

Tohle je poctivější formulace, než na jakou je u vydání zvyk. HDR se dá odškrtnout v seznamu novinek, ale prakticky ho zprovozní jen ten, komu vyjde celý řetězec.

Sandbox dostal zámek na privilegovaná rozhraní

Z bezpečnostních novinek je nejzajímavější plugin pro protokol security-context-v1. Ten umí skrýt privilegovaná globální rozhraní před klienty běžícími v pískovišti; které protokoly se filtrují, se nastavuje volbou security-context-v1/privileged_protocols.

Zdroj u toho nevysvětluje, proti čemu přesně to má chránit. Sama možnost skrýt vybraná privilegovaná rozhraní ale dává smysl: protokoly na snímání obrazovky nebo čtení schránky jsou mocné a samotný Wayland je od běžných nerozlišuje.

Seznam nových protokolů je delší: přibyly ext-copy-capture, ext-foreign-toplevel-list, ext-data-control-v1 a cursor-shape-v1.

Co si z toho odnést

Změna geometrie je zajímavá i mimo Wayfire: ukazuje, že zlomkové škálování není otázka jednoho přepínače, ale toho, v jakém typu čísel počítá celý řetězec od okna k framebufferu.

Podle vývojářů jde o krok k verzi 1.0. Kdy vyjde, oznámení neuvádí.

Zdroje: oznámení na wayfire.org, poznámky k vydání na GitHubu (27. července 2026) a LWN.net.

Paměť pro velké výpočetní akcelerátory se dnes nepřipojuje drátky ani po desce. Stohy čipů HBM sedí těsně vedle procesoru na společné destičce z křemíku, takzvaném interposeru, protože jinak by se dva tisíce vodičů mezi paměť a čip nevešly. Vyrábí se podobnými postupy jako čip sám, takže je nákladná a montáž s ní vyžaduje zvláštní linku.

Sdružení JEDEC, které normuje polovodičové paměti, vydalo 13. července 2026 normu JESD330-4 s označením SPHBM4 (Standard Package High Bandwidth Memory). Její smysl je jednoduchý: dostat stejnou propustnost jako u HBM4, ale po čtvrtině signálů a na obyčejném organickém substrátu, tedy na tomtéž typu podložky, na jakém sedí běžné čipy.

Dva tisíce vodičů versus pět set

Norma HBM4, kterou JEDEC vydal v dubnu 2025, staví na sběrnici široké 2048 bitů s rychlostí až 8 Gb/s na vývod. Podle shrnutí normy to odpovídá propustnosti až 2 TB/s.

SPHBM4 používá 512 datových signálů a chybějící šířku dohání serializací 4:1 – jeden vývod odbaví za stejný čas to, co u HBM4 zvládly čtyři. Celková propustnost proto podle JEDEC zůstává stejná. Konkrétní rychlost na vývod oznámení sdružení neuvádí; ze samotné serializace plyne jen to, že musí být čtyřnásobná proti HBM4. Přetisky uvádějí různá čísla a v oznámení JEDEC pro ně opora není.

Nemění se ani kapacita. SPHBM4 používá tytéž paměťové čipy DRAM jako HBM4, mění se jen spodní logická vrstva, která stoh obsluhuje. Kolik dat se do jednoho stohu vejde, tedy zůstává stejné.

Proč záleží na roztečích

Křemíkový interposer se nepoužívá z rozmaru. Vodičů mezi pamětí a čipem je tolik, že jejich vývody musí být hodně nahusto – u HBM se propojují mikrokuličkami v roztečích, které běžná organická podložka neuveze. Křemík takovou hustotu zvládne, organická podložka ne – a právě odtud se bere celý ten mezikrok.

Když signálů ubude na čtvrtinu, může se rozteč povolit natolik, že stačí organický substrát. Server Blocks & Files k předběžnému oznámení normy z prosince 2025 upozornil na dvě věci naráz: uvolněná rozteč je právě to, co připojení na organickou podložku vyžaduje, a spodní logická vrstva stohu se kvůli tomu musí navrhnout znovu.

Delší cesta jako výhoda

Organické propojení má ještě jeden důsledek, který je na první pohled nečekaný. Spoj mezi procesorem a pamětí smí být delší než na interposeru. Podle JEDEC to znamená, že návrhář akcelerátoru může kolem procesoru rozmístit víc stohů paměti – a zvětšit tak celkovou kapacitu, aniž by musel čekat na hustší stohování.

Právě tohle je podle Blocks & Files hlavní motiv celé normy: víc paměti na jeden akcelerátor a levnější výroba.

Norma není výrobek

Stojí za to rozlišit, co se stalo, od toho, co se zatím jen dá čekat. JEDEC zveřejnil dokument; JESD330-4 se dá stáhnout z jeho webu. Oznámení neuvádí žádný hotový výrobek ani termín. Mezi normou a čipem na skladě stojí nový návrh spodní logické vrstvy, ověření a rozběh výroby.

Předseda představenstva JEDEC Mian Quddus to komentoval obecně: „Členové JEDEC aktivně utvářejí normy, které určí příští generaci modulů pro datová centra s umělou inteligencí.“ (přeloženo z angličtiny) O konkrétních výrobcích ani datech oznámení nemluví.

Co z toho plyne

Hodnocení: pokud se SPHBM4 ujme, nebude to znát na výkonu – propustnost je z definice stejná jako u HBM4. Znát to má být na tom, kolik akcelerátorů se dá vůbec vyrobit a za kolik – každý čip, který se bez pokročilé montáže obejde, uvolní její kapacitu ostatním.

Zároveň je to připomínka, že u pamětí pro umělou inteligenci se poslední roky nebojuje jen o rychlost. Sběrnice široká 2048 bitů si vynutila zvláštní typ pouzdra a ten pak určuje, kdo si takový čip může dovolit vyrobit. SPHBM4 je pokus tuhle vazbu rozpojit, aniž by se sáhlo na propustnost.

Zdroje: tisková zpráva JEDEC k vydání SPHBM4, rozbor Electronics Weekly a zpráva Blocks & Files k předběžnému oznámení. Parametry HBM4 podle shrnutí normy JESD270-4.

Co firma oznámila

Tržby za čtvrtletí byly 3,629 miliardy dolarů, za celý fiskální rok 12,195 miliardy. Hrubá marže podle účetních pravidel GAAP dosáhla ve čtvrtletí 52,3 %, po očištění o mimořádné položky 52,7 %. Zředěný zisk na akcii vyšel na 5,58 dolaru podle GAAP a 5,71 dolaru po očištění. Volné peněžní toky byly 1,1 miliardy dolarů za čtvrtletí a 3,1 miliardy za celý rok, dividenda zůstala na 0,74 dolaru na akcii.

Na první čtvrtletí nového fiskálního roku firma čeká tržby 4,1 miliardy dolarů s odchylkou 100 milionů a očištěný zisk 7,30 dolaru na akcii s odchylkou dvaceti centů.

Roční růst o 34 % z 9,1 miliardy dolarů uvádí The Register a totéž číslo zaznělo i ve vyjádření generálního ředitele Davea Mosleyho k výsledkům. U samotného čtvrtletí se ale zdroje rozcházejí: The Register mluví o padesátiprocentním meziročním růstu, přepis hovoru s analytiky o osmačtyřiceti procentech.

Přibyly plotny, ne disky

Nejzajímavější číslo z hovoru s analytiky neříká, kolik se prodalo, ale co se změnilo uvnitř. Finanční ředitel Gianluca Romano popsal, že za poslední rok vzrostl počet ploten a hlav uvnitř jedné krabice zhruba o patnáct až dvacet procent, kdežto počet prodaných kusů zůstal podle jeho slov úplně stejný.

Plotna je kotouč, na který se zapisuje; hlava je součástka, která nad ním čte a píše. Když se jich do téhož šasi vejde víc, kapacita disku roste, aniž by z výrobní linky sjela jediná krabice navíc. Seagate tedy neprodává víc disků, prodává tlustší.

Souvisí s tím i výše investic. Ty loni spolkly 4,7 % tržeb a Romano potvrdil, že se firma i letos chce vejít do svého obvyklého rozmezí 4 až 6 %. Peníze podle Mosleyho míří hlavně do nástrojů na výrobu hlav a médií, ne do rozšiřování počtu linek.

Kapacita je rozebraná do roku 2028

Poptávku táhnou datová centra. Ta podle Mosleyho odebírají zhruba 90 % všech exabajtů, které Seagate dodá. Řeč je o discích kategorie nearline, tedy o kapacitních discích pro data, ke kterým se sahá řidčeji než k těm na rychlém úložišti, ale musí být pořád po ruce.

Mosley na hovoru uvedl, že na základě dnes platných dlouhodobých dodavatelských smluv je naprostá většina nearline exabajtů alokovaná do kalendářního roku 2028 a že řada zákazníků se aktivně snaží protáhnout plánování do roku 2029 a dál. Dodal, že u zákazníků nevidí žádné zkracování plánovacích horizontů. Smlouvy podle něj určují konfiguraci i cenu na celý kalendářní rok 2027, a firma je uzavírá dřív, než výrobu vůbec spustí.

Že to není situace posledních týdnů, je vidět z dřívějších rozborů trhu. Analytická firma TrendForce psala už v září 2025, že dodací lhůty nearline disků narostly z několika týdnů na víc než 52 týdnů, protože výrobci roky nerozšiřovali kapacitu a nedokázali pak zareagovat na nárůst poptávky. Datová centra přitom tlačí na víc míst řetězce najednou; letos v červenci vydalo sdružení JEDEC normu SPHBM4 pro rychlé paměti.

HAMR: ze čtyřiceti procent na sedmdesát

Technologie, na které to celé stojí, se jmenuje HAMR – tepelně asistovaný magnetický zápis. Zjednodušeně: laser na okamžik nahřeje místo na plotně, takže tam jde zapsat menší bit, než by šlo za studena. Menší bit znamená víc dat na tutéž plochu.

Na konci fiskálního roku připadalo podle Mosleyho zhruba 40 % dodávaných nearline exabajtů na produkty s HAMR. Do června 2027 chce firma dojít na 70 %. Platforma Mozaic 4 podporuje disky s kapacitou až 44 TB a náběh výroby míří k velkým poskytovatelům cloudu. Nástupce Mozaic 5 má jít na kvalifikační dodávky koncem roku 2027 a slibuje přes 5 TB na jednu plotnu.

Na dotaz analytika, jestli samotný růst plošné hustoty pokryje poptávku v letech 2028 a 2029, Mosley odpověděl, že si nemyslí, že by přechody na vyšší hustotu stačily; považuje je za silné, ale ne za dostačující.

Kde má ta zpráva slabinu

Seagate má zájem, aby trh s pevnými disky vypadal dobře. The Register to říká natvrdo: podnikání firmy se SSD označil někdo za naprosto okrajové, takže Seagate stojí a padá s prodejem nearline disků hyperskalerům a velkým firmám. Bílá kniha o vrstveném úložišti, na kterou se Mosley odvolával, vznikla společně se SK hynix – jsou to tedy dva dodavatelé, ne nezávislé měření.

Druhá věc, kterou ta zpráva pro odběratele znamená, je cena. Analytik Morgan Stanley Erik Woodring na hovoru shrnul, že cena za exabajt vzrostla v červnovém čtvrtletí meziročně o 10 % a zářijový výhled implikuje růst kolem dvaceti procent nebo i víc. Romano to nerozporoval a řekl, že mezera mezi nabídkou a poptávkou je teď o něco větší než před několika čtvrtletími a že firma tu zvýšenou produkci umí prodat za velmi dobrou cenu.

Pro provozovatele datového centra je to jednoduchá bilance: kapacitu dostane, ale dráž. Kam se v téhle situaci posunou ceny běžných disků v obchodě, ze zveřejněných čísel vyčíst nejde – Seagate je nerozepisuje a odhadovat to za něj nebudeme. Jisté z nich je jen tolik, že se výroba nerozšiřuje a že smlouvy na většinu kapacity jsou podepsané roky dopředu.

Zdroje: tisková zpráva Seagate k výsledkům, The Register, přepis hovoru s analytiky a rozbor TrendForce.

Firma ChangXin Memory Technologies, zkratkou CXMT, začala v pondělí 27. července obchodovat na šanghajském trhu STAR. Upisovací cena byla 8,66 juanu za akcii, závěrečná cena prvního dne 49 juanů. Rozdíl dělá 465,82 %, jak spočítal deník China Daily; agenturní zprávy i Fortune uvádějí zaokrouhlené 466 %.

Analytická firma TrendForce píše o 471,6 %. To číslo není v rozporu s předchozími – počítá se z denního maxima 49,50 juanu, ne ze závěrečné ceny.

Osm a půl miliardy dolarů z úpisu

Úpis vynesl 57,9 miliardy juanů, tedy zhruba 8,6 miliardy dolarů. Pokud upisovatelé uplatní opci na dalších 15 % akcií, částka podle TrendForce stoupne na 66,6 miliardy juanů. Podle deníku The Washington Times je to druhý největší vstup na burzu v pevninské Číně vůbec – první zůstává Agricultural Bank of China z roku 2010 s 22,1 miliardy dolarů.

Tržní hodnota CXMT vyšplhala na přibližně 3,3 bilionu juanů. Přepočet na dolary se ve zdrojích liší: Fortune i americké přetisky uvádějí přes 487 miliard, China Daily počítá 443 miliard. Objem obchodů prvního dne byl podle China Daily rekordních 140 miliard juanů.

Firma stará deset let

CXMT vznikla v roce 2016 v Che-fej na východě Číny a vyrábí paměti DRAM – tedy operační paměť, kterou používá počítač, telefon i server pro data, se kterými zrovna pracuje. Za první tři měsíce roku 2026 utržila 50,8 miliardy juanů (7,5 miliardy dolarů), meziroční růst tržeb tak přesáhl 700 %.

V podílu na trhu se zdroje rozcházejí. Fortune uvádí za rok 2025 pořadí Samsung 36 %, SK Hynix 29 %, Micron zhruba 24 % a CXMT okolo 8 %, přičemž v prvním čtvrtletí 2026 měla čínská firma asi 9 % světových dodávek. TrendForce jí za totéž čtvrtletí přisuzuje 7,6 % a první tři výrobce dohromady počítá na 89,7 %. Obě čísla se shodují v jednom: CXMT je čtvrtá a od trojice vpředu ji dělí velký kus.

Technologicky firma podle TrendForce postupně přechází na svůj proces G4 a přesouvá těžiště od pamětí pro mobily k pamětem pro servery.

Proč zrovna teď

Načasování není náhoda. Paměti zdražují už od roku 2025, protože Samsung, SK Hynix a Micron přesouvají výrobní kapacitu k pamětem HBM pro akcelerátory umělé inteligence. Network World psal loni v listopadu s odvoláním na Counterpoint Research, že ceny DRAM od začátku roku 2025 vzrostly zhruba o 50 % a Samsung zvedl cenu modulů DDR5 o kapacitě 32 GB ze 149 na 239 dolarů. SK Hynix měl tehdy podle téhož textu kapacitu HBM, DRAM i NAND vyprodanou do konce roku 2026.

Do téhle mezery míří CXMT. Wu Hao z fondu Founder Fubon Fund pro China Daily řekl, že úpis CXMT „doplňuje nejdůležitější dílek skládačky“ v čínském paměťovém odvětví (přeloženo z angličtiny). Firma je zároveň součástí čínské snahy o vlastní řetězec pro umělou inteligenci, do které patří i otevřené váhy modelů, jaké nedávno zveřejnil Moonshot.

Kde je strop

Peníze z úpisu problém CXMT neřeší celý. „Obchodní omezení na výrobní zařízení zůstávají klíčovou výzvou,“ řekl agentuře MS Hwang z Counterpoint Research (přeloženo z angličtiny). Pokročilé stroje na výrobu čipů se do Číny dovážejí jen s povolením, které americká administrativa vydávat nemusí.

Tlak navíc sílí. Server The Register 17. července upozornil na dopis, ve kterém kongresmani John Moolenaar a George Whitesides žádají ministra obchodu Howarda Lutnicka, aby americkým subjektům zakázal nakupovat paměti od CXMT a od výrobce pamětí NAND YMTC. Argumentují tím, že takové nákupy podrážejí západní výrobce.

Co se bude sledovat

Odhady dalšího růstu se rozcházejí víc než dnešní čísla. Podle podkladů, ze kterých vychází Fortune, by se CXMT do roku 2028 dostala zhruba na 11 % trhu, přičemž pro dlouhodobou konkurenceschopnost by potřebovala aspoň 15 %. Analytik Donnie Teng z Nomury pro China Daily naopak odhaduje růst z 10 % na 18 % do konce roku 2028. Rozdíl mezi oběma odhady je větší než celý dnešní podíl firmy.

Není to jen burzovní zpráva. The Register letos v červenci psal, že vysoké ceny pamětí se podle očekávání udrží nejméně do roku 2028 – a právě do téhle situace přichází čtvrtý výrobce s osmi a půl miliardami dolarů v kapse a s dovozním stropem na stroje, které by za ně chtěl koupit.

AMD na své konferenci Advancing AI, která proběhla 22. a 23. července v San Franciscu, představilo šestou generaci serverových procesorů EPYC. Řada nese označení 9006 a kódové jméno Venice, staví na jádrech Zen 6 a nejsilnější kus zvládne 256 jader a 512 vláken v jedné patici. Do prodeje se ale dostane až ve čtvrtém čtvrtletí.

Co je uvnitř

Nejvyšší model má 256 jader a se zapnutým SMT, tedy dvěma vlákny na jádro, obslouží 512 souběžných vláken. Pátá generace EPYC s kódovým jménem Turin se zastavila na 192 jádrech, takže přírůstek je zhruba třetinový.

Paměťový řadič obsluhuje šestnáct kanálů na patici. AMD u nich uvádí podporu modulů MRDIMM druhé generace s přenosem 12,8 GT/s a vedle toho běžných DDR5-8000. Šestnáct kanálů po 12,8 GT/s vychází při osmibajtové šířce sběrnice zhruba na 1,6 TB/s – a právě paměťová propustnost, ne počet jader, bývá u serverů s mnoha vlákny tím, co drží stroj zpátky.

Vstupně-výstupní část přešla na PCI Express šesté generace, ve dvoupaticové sestavě je linek až 160. Prakticky to znamená, kolik akcelerátorů a síťových karet lze na jeden stroj pověsit, aniž by si navzájem ukrajovaly propustnost.

Dvě různá jádra pod jedním jménem

Číslo 256 platí pro hustotní jádra Zen 6c, tedy variantu navrženou tak, aby se jich na křemík vešlo co nejvíc. Kdo potřebuje vyšší takty, sáhne po jiné části nabídky, která končí níž: model s 96 jádry se v boostu dostane na 5 GHz. Rozdíl není kosmetický. Stroj na obsluhu tisíců drobných požadavků a databázový server potřebují každý něco jiného a samotný počet jader je nerozliší.

Nabídka se navíc dělí dál. Vedle patice SP7 bude i levnější SP8, verze Venice-X s trojrozměrně skládanou vyrovnávací pamětí se čeká v roce 2027 a ve druhé polovině téhož roku ještě varianta Verano s pamětí LPDDR.

První velký čip na dvounanometrovém procesu

Venice se vyrábí u TSMC na uzlu N2. Zahájení sériové výroby AMD oznámilo už letos v květnu a označilo Venice za první procesorovou řadu pro náročné výpočty, která se na tomto uzlu vyrábí ve velkém.

Označení „2 nm“ je obchodní jméno uzlu, ne rozměr čehokoliv na čipu – tranzistory jsou fyzicky výrazně větší. Podstatná je změna jejich typu: místo dosavadních FinFETů nastupují tranzistory s hradlem obepínajícím kanál ze všech stran. Slibují menší svodové proudy a lepší chování při nízkém napětí, což u čipu se stovkami jader rozhoduje o tom, kolik z nich může běžet naplno současně.

Čísla od výrobce, ne z nezávislých testů

Proti generaci Turin slibuje AMD až o 70 procent vyšší výkon. Zhruba pětinu z toho má obstarat samotné jádro, zbytek dělá jejich počet. U jedné konkrétní zátěže, obsluhy zabezpečených požadavků v serveru Nginx, firma ukázala nárůst 1,2násobku. Proti serverům s procesory Vera od Nvidie uvádí 2,08násobek počtu jader na rack.

Všechna ta čísla pocházejí od AMD a týkají se úloh, které si samo vybralo. Nezávislá měření zatím nejsou, protože stroje se neprodávají. Rozdíl mezi sedmdesáti procenty v tiskové zprávě a 1,2násobkem v jedné ukázce je dobré vodítko k tomu, jak moc u těchto čipů záleží na konkrétní úloze.

Helios a akcelerátory

Vedle procesorů AMD ukázalo akcelerátory řady Instinct MI400 a hotovou rackovou sestavu Helios: 72 akcelerátorů MI455X a 18 procesorů EPYC v jedné skříni. Model MI430X míří na vědecké výpočty a AMD u něj uvádí 288 bilionů operací za sekundu v dvojité přesnosti. U Heliosu slibuje AMD proti sestavě Vera Rubin NVL72 od Nvidie až o 30 procent víc vygenerovaných tokenů na dolar. Opět vlastní číslo bez nezávislého ověření.

Odběratelé jsou domluvení. OpenAI podle AMD spustí první Helios ve čtvrtém čtvrtletí, Anthropic má odebrat akcelerátory MI455X s celkovým příkonem až dva gigawatty. Tady se zdroje rozcházejí v termínu: dřívější materiály k Heliosu mluvily o třetím čtvrtletí, tisková zpráva z konference už o čtvrtém. Samotná sestava je prý ve výrobě.

Co bude dál

AMD zároveň odkrylo plán na roky dopředu. Jádra Zen 7 pod jmény Florence, Ferrara a Fidenza mají přijít v roce 2028, Zen 8 s označením Ravenna až v roce 2030. Akcelerátory MI500 se čekají v roce 2027, MI600 o rok později.

Přes velkou show jde zatím spíš o oznámení než o uvedení na trh. Zajímavé bude, co ukážou nezávislá měření na podzim a jestli TSMC udrží dodávky z nového uzlu ve chvíli, kdy o stejnou výrobní kapacitu stojí i další zákazníci. Podklady: tisková zpráva AMD z 23. července, rozbor na Phoronixu a materiály serveru ServeTheHome.

Když se do jádra Linuxu dostane chyba, obvykle se o tom uživatelé dozvědí až od někoho, komu přestalo fungovat. Tady to bylo naopak: kernelový tým Ubuntu vydal 16. července varování dřív, než chybné jádro doputovalo ke všem.

Co se stalo

Jádro 7.0.0-28.28 pro Ubuntu 26.04 a pro takzvaný HWE stack Ubuntu 24.04 LTS obsahuje chybu v ovladači amdgpu. Projeví se u výpočtů, které používají ROCm – což je obdoba CUDA od NVIDIE, tedy vrstva, přes kterou běží na grafických kartách AMD strojové učení a další výpočetní úlohy.

Čísla z hlášení jsou nezvyklá. Úloha, která zabrala 9 sekund, trvala 388 sekund. To je zhruba dvaačtyřicetinásobek. Jako příklad tým uvádí generování obrázků modelem Stable Diffusion XL přes rozhraní ComfyUI.

Podstatné je, že nejde o zamrznutí ani pád. Systém běží dál, jen výrazně pomaleji – přesně ten druh chyby, kterého si člověk nemusí všimnout, dokud nezačne měřit.

Co je HWE stack a proč se to týká i LTS

Že chyba dopadá i na Ubuntu 24.04 LTS, může překvapit – vydání s dlouhou podporou mají pověst konzervativních. Jenže LTS vydání nabízí volbu: buď zůstat na jádře, se kterým vyšlo, nebo přejít na takzvaný HWE stack, tedy novější jádro a grafické ovladače přebrané z pozdějších vydání.

Smysl je hlavně v novém hardwaru: čerstvě koupený počítač často se čtyři roky starým jádrem pořádně nefunguje. Daň je právě tohle – spolu s podporou nových karet přicházejí i jejich čerstvé chyby. Kdo na 24.04 zůstal u původního jádra, tuhle regresi nepotká.

Jak zjistit, na čem jedu

Verzi běžícího jádra vypíše jediný příkaz:

uname -r

Když ve výpisu je 7.0.0-28 a počítač se používá k výpočtům na kartě AMD, je to ten dotčený případ. Kdo tam má cokoliv jiného, se aktualizací může chvíli počkat a rovnou přeskočit na opravené vydání.

Koho se to netýká

Hráčů ani běžných uživatelů. Chyba sedí v části ovladače, která obsluhuje heterogenní správu paměti, tedy sdílení paměti mezi procesorem a grafickou kartou při výpočtech. Vykreslování obrazu jde jinou cestou.

Zasažení jsou tedy hlavně ti, kdo mají Radeon jako výpočetní kartu – domácí generování obrázků, trénování modelů, vědecké výpočty. Tedy nasazení, kde je AMD dlouhodobě v roli vyzyvatele NVIDIE a kde se každý takový zádrhel počítá.

Co s tím

Rada od kernelového týmu je prostá: zůstat na dosavadním jádře. Kdo už 7.0.0-28 nainstalovaný má a naráží na zpomalení, může při startu počítače v nabídce GRUB vybrat předchozí verzi jádra a nabootovat z ní.

Oprava existuje. Do jádra Linuxu se dostala ve verzi 7.0.13, konkrétním commitem, který upravuje opakovací smyčku v dotčené části ovladače. Ubuntu ji zabalilo do jádra 7.0.0-29.29, které bylo 22. července zpřístupněno v testovacím repozitáři, a řádné vydání je naplánované na týden od 2. srpna.

Proč to stojí za zaznamenání

Ne kvůli samotné chybě – regrese ve výkonu se v jádře objevují pravidelně a tahle bude za pár dní zalátaná.

Zajímavý je způsob, jakým se to řešilo. Chyba nevznikla v Ubuntu, ale výš, v opravné verzi jádra 7.0.12, odkud ji distribuce převzala. Distribuce, které bezpečnostní a opravné verze přebírají rychleji, tak dostaly problém dřív – a rychleji i opravu. Ubuntu, které je přebírá s odstupem, mělo naopak čas problém pojmenovat dřív, než na něj lidé narazí.

Veřejné varování ve stylu „tohle vám příští týden zpomalí výpočty, počkejte s aktualizací“ je u distribucí spíš výjimka. Přitom je to přesně to, co uživatel potřebuje: ne dodatečné vysvětlení, ale varování včas.

Zdroje: oznámení kernelového týmu Ubuntu a zpravodajství Phoronixu.

Grafické čipy NVIDIE se na Windows s procesorem Arm doteď obešly bez oficiální podpory. Kdo chtěl na takovém stroji spustit cokoli postavené na CUDA – tedy na rozhraní, kterým NVIDIA pouští výpočty na grafické kartě – měl smůlu. Šestnáctého července to firma změnila: na svém vývojářském fóru vydala CUDA Toolkit 13.4 jako Developer Preview a spolu s ním ovladač pro Windows 11 na Arm64.

Co je v balíku

Preview má tři části: vývojářský ovladač pro chystanou platformu RTX Spark, samotný toolkit ve verzi 13.4 a dokumentaci. Instalační soubor ovladače se jmenuje 616.00_DeveloperPreview_win11_arm64_International.exe. Vedle něj NVIDIA nabízí i verzi pro x64, aby šlo programy pro Arm křížově překládat na běžném počítači.

Podstatné je, že k začátku není potřeba nic kupovat. „Nepotřebujete hardware RTX Spark, abyste mohli začít – použít se dá existující vývojový systém s Windows na Armu,“ píše NVIDIA v oznámení (přeloženo z angličtiny). Programátoři si tak mohou aplikaci přeložit, najít v ní závislosti, které pro Arm neexistují, a připravit první sestavení dřív, než se čip vůbec objeví v prodeji. Ověření na skutečném RTX Sparku má podle stejného textu přijít, „až bude podporovaný hardware a software k dispozici“ (rovněž přeloženo).

Instalační soubor prozradil, co má chystaný čip uvnitř

Zajímavější než ovladač sám je jeho instalační předpis. Web Windows Latest si 18. července všiml, že soubor nv_surface_woa.inf vyjmenovává dvě zařízení: „NVIDIA RTX Spark N1X (6144-core Blackwell RTX GPU)“ a „NVIDIA RTX Spark N1X (5120-core Blackwell RTX GPU)“. Chystaný čip tedy nepřijde v jediné podobě, ale nejméně ve dvou, a liší se počtem jader grafické části.

Vyšší z nich odpovídá tomu, co Microsoft uvedl na začátku června při ohlášení notebooku Surface Laptop Ultra: dvacetijádrové procesorové pole složené z deseti jader Cortex-X925 a deseti Cortex-A725, grafika se 6 144 jádry architektury Blackwell a až 128 GB paměti sdílené mezi procesorem a grafikou. Server PCWorld k tomu dodává, že stejný počet grafických jader má stolní karta GeForce RTX 5070.

Co N1X umí ve výpočtech, zatím nikdo nezměřil. Microsoft u svého notebooku mluví o výkonu „až petaflop“ v úlohách umělé inteligence, což je údaj výrobce, ne výsledek nezávislého testu.

Co zatím nefunguje

Omezení vypisuje NVIDIA v oznámení sama. Nástroj Nsight Copilot je na Windows ARM64 v tomto preview vypnutý a nedostupný. U knihovny PyTorch firma varuje, že spuštění jejích testovacích úloh v režimu CI/CD může vyvolat vypršení časového limitu grafiky. Balík není finální vydání a NVIDIA ho tak ani neoznačuje – v názvu souboru i v titulku oznámení stojí Developer Preview.

Ovladač 616.00 navíc obsluhuje pouze hardware RTX Spark. Na žádnou jinou grafickou kartu NVIDIE se nevztahuje, což u vývojářského balíku mířícího na jediné zařízení dává smysl.

Proč na tom pro Arm záleží

Windows na Armu naráží dlouhodobě na tentýž problém: software napsaný pro x86 na něm buď neběží, nebo běží v emulaci a pomaleji. U výpočtů na grafické kartě byla situace horší, protože chyběla samotná knihovna – a bez CUDA se neobejde většina nástrojů kolem strojového učení. Vydáním pro Arm64 se ta mezera zavírá. Zatím ovšem jen ve vývojářské podobě a pro jedinou chystanou platformu; to je hodnocení redakce, ne tvrzení výrobce.

Kdy se hardware objeví, NVIDIA v oznámení neuvádí. Podle Windows Latest se první stroje s RTX Sparkem čekají na podzim a kromě Surface Laptopu Ultra se mluví o Lenovu Yoga Pro 9n. Microsoft u svého notebooku uvedl podzim 2026 rovněž, cenu ale zatím neřekl.

Vydání ovladače tedy není zpráva o výkonu, ale o načasování. NVIDIA dala vývojářům zhruba dva měsíce náskok, aby jejich programy fungovaly hned první den prodeje – a mimoděk jim přitom v obyčejném textovém souboru prozradila, kolik variant čipu chystá.

Rust 1.97 vyšel 9. července a na první pohled je to nezajímavé vydání: pár nových metod na celých číslech, drobnost v Cargu. Jenže obsahuje jednu změnu, kterou pozná každý, kdo někdy ladil pád aplikace v uvolněném sestavení. Kompilátor od této verze používá jako výchozí kódování symbolů schéma v0.

Co je kódování symbolů a proč na něm záleží

Když překladač vyrobí binárku, musí každou funkci pojmenovat jedním řetězcem v tabulce symbolů. To jméno smí obsahovat jen omezenou sadu znaků, takže se cesta k funkci i její typové parametry zakódují do jednoho slova. Tomu se říká mangling, tedy zkomolení jména.

Podle tohoto jména se pak orientuje ladicí program, profiler i výpis zásobníku po pádu. Když je kódování špatné, ladicí nástroje zobrazí místo funkce jen shluk znaků a vývojář hádá.

Rust do teď používal starší schéma, které si s obecným kódem neporadilo. Pokud jste měli funkci s typovým parametrem a zavolali ji pro deset různých typů, vzniklo deset různých funkcí, jenže jejich konkrétní typy se do jména nedostaly. Nahradil je hash. Ve výpisu jste tedy viděli, že spadla nějaká varianta obecné funkce, ale ne která.

Co dělá v0 jinak

Schéma v0 vzniklo podle návrhu RFC 2603 a jeho hlavní vlastnost je obousměrnost. Kódování je navržené tak, aby z výsledného jména šlo zpětně přečíst, co v něm bylo, včetně typových parametrů. Oznámení k vydání to shrnuje jednou větou: dosazení obecných parametrů si zachovává své hodnoty, místo aby bylo sledované jen za hashem.

Kromě typů umí v0 zakódovat i životnosti, konstantní generické parametry, meze s vyšším řádem, uzávěry a další konstrukce, na které starší schéma nemyslelo. Jména používají jen znaky A–Z, a–z, 0–9 a podtržítko, takže projdou beze změny každým linkerem. Aby přitom nebyla nekonečně dlouhá, používá formát zpětné odkazy na už zakódované části.

Ukázkový symbol ve formátu v0 vypadá takto:

_RNvMsr_NtCs3ssYzQotkvD_3std4pathNtB5_7PathBuf3newCs15kBYyAo9fc_7mycrate

Po rozkódování je z něj čitelné <std::path::PathBuf>::new.

Samotné schéma není novinka. Zapnout se dalo ručně přepínačem od verze 1.59, tedy od února 2022. Novinkou je, že se čtyři a půl roku poté stalo výchozím.

Na co si dát pozor

Dokumentace kompilátoru na dvou místech mírní očekávání. Zaprvé: v0 není stabilní binární rozhraní Rustu. Je definované natolik, aby z něj šlo vyrobit čitelný tvar, ne aby se na jeho podobu daly vázat cizí nástroje.

Zadruhé: neexistuje jediný předepsaný způsob, jak symbol zobrazit. Dokumentace doporučuje oddělovat cesty dvojtečkami, psát implementace vlastností jako <Typ as Vlastnost> a uzávěry jako {closure#N}, ale je to doporučení, ne norma. Dva profilery tedy mohou tentýž symbol vypsat jinak.

Nástroje, které rozkódování zvládají, mají podle dokumentace při setkání s neznámou značkou raději vypsat původní zkomolené jméno než spadnout. Kdo používá starší verzi ladicího programu nebo vlastní nástroj nad tabulkou symbolů, měl by po přechodu na 1.97 zkontrolovat, že to skutečně dělá.

Zbytek vydání

Druhá praktická změna se týká linkeru. Jeho hlášky se dosud zahazovaly; nově se zobrazují jako varování pod kontrolou lintu linker_messages. Potíže s linkováním se tak nebudou projevovat až záhadným chováním výsledné binárky.

Cargo umí nově řídit chování varování přes proměnnou prostředí CARGO_BUILD_WARNINGS s hodnotami allow, warn a deny. Podstatné je, že změna této hodnoty neshodí vyrovnávací paměť sestavení, takže přepnutí na deny v průběžné integraci nestojí celý překlad znovu.

Ze standardní knihovny přibyly metody pro práci s bity celých čísel: isolate_highest_one, isolate_lowest_one, highest_one, lowest_one a u typů bez znaménka bit_width. Stejná sada je i na typech NonZero. Metoda char::is_control je nově použitelná v konstantním kontextu.

O týden později, 16. července, vyšla opravná verze 1.97.1.

Zdroje: oznámení vydání na blogu projektu Rust a kapitola o kódování v0 v příručce kompilátoru.