Přímý přenos (YouTube) z konference LinuxDays 2026, jež probíhá tento víkend v Praze v prostorách FIT ČVUT. Na programu je spousta zajímavých přednášek.
Byla vydána nová verze 0.17.0 programovacího jazyka Zig (Codeberg, Wikipedie). Přispělo 206 vývojářů. Přehled novinek v poznámkách k vydání.
Open-source projekt OpenDLSS-NR je 'bitově přesná reimplementace' neuronové rendrovací sítě DLSS 5 od společnosti NVIDIA, jenže pro grafické API Vulkan (DLSS slouží k vylepšování klasickým způsobem vyrendrovaných snímků pomocí lokálních modelů umělé inteligence, a to v reálném čase). Projekt není nijak spojen se společností NVIDIA, je pouze pro OS Windows a natrénované váhy modelu si uživatelé musí obstarat sami. Zdrojový kód je k dispozici na GitHubu, pod licencí MIT s výjimkou pro komponenty třetích stran.
Společnost Cloudflare představila Clef a Clef-Flash, open-source rozhodovací modely určené pro rychlou a konzistentní klasifikaci vstupů. Na rozdíl od klasických LLM vracejí tyto modely deterministické striktně typované strukturované odpovědi s exaktními pravděpodobnostmi, tedy odpovědi ve stylu přelomového modelu Jev.
… více »Byla vydána beta verze Ubuntu 26.10 s kódovým názvem Stonking Stingray. Přehled novinek v poznámkách k vydání. Dle plánu by Ubuntu 26.10 mělo vyjít 15. října 2026.
Byla vydána verze 1.99.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.
Od 13. do 15. října proběhne v Praze OpenSSL Conference 2026. Na YouTube lze zhlédnout videozáznamy přednášek z loňského roku.
Eben Upton oznámil další zdražení jednodeskových počítačů Raspberry Pi. Tentokrát 2 GB varianty o 12,50 dolarů. Nově 2 GB Raspberry Pi 4 stojí 67,50 dolarů a 2 GB Raspberry Pi 5 stojí 77,50 dolarů.
OpenMandriva ROME, tj. průběžně aktualizovaná (rolling) edice linuxové distribuce OpenMandriva, byla vydána ve verzi 26.09. Vedle Flatpaku také s podporou Snapu.
Edison Design Group po více než 30 letech zveřejnil zdrojový kód svého EDG C/C++ front-endu. Ten proslul širokou podporou standardů C++ a kompatibilitou s dialekty kompilátorů od Microsoftu, GNU, Clangu, Sunu a dokonce i s prehistorickým cfrontem. EDG byl použit například v kompilátoru Intel C++ Classic, kompilátoru NVCC od firmy NVIDIA pro platformu CUDA nebo v našeptávači kódu IntelliSense v produktech společnosti Microsoft. Projekt nyní spravuje organizace The C++ Alliance a kód je dostupný pod licencí Apache 2.0, doplněnou o výjimky projektu LLVM.
Současný vývojový kernel nese označení 4.5-rc2. Vydán byl 31. ledna a podle Linuse se práce na vydání zrychlily: „Ještě v pátek jsem měl v plánu zmínit, jak prima je nový trend malých rc2 vydání, protože až do pátku nebylo příliš mnoho žádostí o zařazení. Jenomže se ukázalo, že všechny žádosti se objevily až o víkendu a 4.5-rc2 nakonec až tak malým vydáním nebude. Za víkend se prakticky zdvojnásobila.“
Stabilní aktualizace: 3.14.60 a 3.10.96 byly vydány 29. ledna a o dva dny později je následovaly 4.4.1, 4.3.5 a 4.1.17.
*Nejhorší* chyby jsou ty, kde kód dává smysl a na lokální úrovni funguje bez problému, ale kombinace dvou nebo tří částí kódu, které jsou jednotlivě srozumitelné, z jakýchsi podivných důvodů nefunguje – kvůli absenci tranzitivity. S tím je opravdu těžké se vypořádat.
Vskutku, paměťový model definovaný výhradně testy lakmusovými papírky by se dal kvalifikovat jako exotická forma mučení.
Bylo nebylo, blokové I/O plánovače, zodpovědné za optimalizování proudu I/O požadavků k úložným zařízením, byly oblastí intenzivního vývoje. Charakteristika rotujících disků znamenala, že výkon I/O se hodně různil podle toho, v jakém pořadí byly požadavky vyřizovány. Změny v hardwaru (hlavně přechod k SSD) způsobily úpadek motivace na práci v této oblasti. To nejlepší, čeho může u moderních disků I/O plánovač dosáhnout je, že zůstane stranou. I přesto přetrvává aspoň nějaký zájem na vylepšování I/O plánovačů a dokládá to zejména návrat plánovače BFQ (budget fair queuing).
Plánovač BFQ vyvinuli Paolo Valente a Arianna Avanzini a naposledy se o něm psalo v červnu 2014. Je odvozen od plánovače CFQ I/O, který je obsažen v současných jádrech. Na většině systémů se jedná o výchozí plánovač, ačkoliv někteří uživatelé s rychlejšími disky jej nahrazují některým z jednodušších plánovačů. Nicméně, BFQ se od svých kořenů v CFQ za tu dobu hodně odchýlil.
Pro podrobnosti o tom, jak BFQ funguje, viz zmíněný článek z roku 2014. Následuje jen velmi zkrácené shrnutí. Pro jakékoli blokové zařízení BFQ vytvoří frontu požadavků pro každý proces v systému. Každá fronta získá rozpočet, který představuje množství I/O provozu, které může vyslat k diskové jednotce v daném plánovacím cyklu. Rozpočet je stanoven plánovačem podle priority I/O a pozorováním I/O chování procesu. Odesílaný kód (pod názvem B-WF2Q+) obsluhuje každou frontu zvlášť; v jednotlivých krocích je uvolněno určité množství I/O až do výše přidruženého rozpočtu. Správným nastavením rozpočtů se BFQ snaží zajistit, aby každý z procesů dostal spravedlivé množství dostupného I/O pásma, a to v celkem malých mezích latence.
Hlavní myšlenka je jednoduchá, ale reálný svět je o něco složitější, a tak BFQ, stejně jako předtím CFQ, nashromáždil velké množství heuristik, jejichž cílem je zlepšení výkonu v konkrétních oblastech. Dochází ke sloučení front spolupracujících procesů ve stejné oblasti disku, což umožňuje větší konsolidaci požadavků. Pokud proces vykonávající požadavek na čtení vyprázdní svou frontu před vyčerpáním rozpočtu, bude zařízení na krátkou dobu označeno jako nečinné, aby tak proces získal šanci vytvořit další požadavek. Procesy, identifikované jako soft realtime (ty s mírnými požadavky na šířku pásma a pravidelně přerušovaným cyklem žádostí) získají vyšší prioritu, stejně jako právě začínající procesy atd.
Podle všeho se BFQ od června 2014 příliš nezměnilo. Popisované heuristiky jsou více méně stejné. Jistě došlo k odstranění chyb a zlepšení výkonu na základě zkušeností z využívání plánovače v ostrém provozu – plánovač se dodával v několika méně rozšířených distribucích a zřejmě byl využíván v některých telefonech. Původní patche pocházely od Paola z univerzity v Modeně a Reggio Emilia, ale ty současné chodí z adresy v Linaru, což by mohlo naznačovat nějaký komerční zájem.
Plánovači BFQ se dostalo v roce 2014 dobrého přijetí – na rozdíl od navrženého postupu zavedení do jádra. V té době byl BFQ přidán jako nový I/O plánovač spolu s ostatními do kernelu, bohužel komunita kolem jádra neměla vůbec chuť na další plánovač, natož takový, který by se tolik podobal plánovači CFQ. Vzhledem k tomu, že BFQ je hlavně vylepšením CFQ, bylo Paolovi doporučeno zapracovat na sérii patchů vyvíjejících CFQ požadovaným směrem. To se snadněji řekne než udělá, přestože BFQ původně z CFQ pochází. Tyto dva plánovače se během vývoje BFQ značně vzdálily. V důsledku tohoto požadavku zmizel BFQ plánovač z e-mailové konference na více než rok.
Jeho návrat naznačuje, jak mají BFQ vývojáři v plánu uspokojit požadavek, který jim byl zadán. Nový patchset se skládá z 22 změn, rozdělených do tří kroků:
V době psaní tohoto článku nebyl ještě nový patch nikým komentován, takže se teprve ukáže, zda komunita patch přijme či nikoli. Dá se říct, že jaderní vývojáři mají rádi kód, který se vyvíjí po menších krocích. Velký kus nového kódu v jediném patchi je složitý na kontrolu a je velké riziko problémů s výkonem či regresemi. CFQ se hojně využívá, jeho destabilizace po několik vydání není nejlepší nápad. Je tedy možné, že tento příspěvek nebude o moc úspěšnější než ten předešlý.
Na druhou stranu, možná v současné době neexistuje lepší způsob, jak BFQ do kernelu dostat. Pokud by nadšení pro BFQ bylo nízké, znamenalo by to, že bude odsouzen k životu mimo hlavní strom i nadále. Jenže BFQ se zdá být prokazatelně lepší než CFQ a jeho heuristiky jsou srozumitelnější, takže motivace pro zavedení do jádra by tu byla. Lze si představit, že vybudovat kvalitní kód bude nějaký čas trvat, takže bychom se BFQ mohli dočkat třeba ve vývojovém cyklu 4.6. Tou dobou by vývojová komunita mohla přijít na způsob, jak tento kód začlenit a jak ho učinit dostupným celé uživatelské komunitě.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej: