Byla vydána nová verze 2026.3.0 "Carousels & Killer Whales" svobodného softwaru ScummVM (Wikipedie) umožňujícího bezproblémový běh mnoha klasických adventur na zařízeních, pro které nebyly nikdy určeny. Přehled novinek v poznámkách k vydání a na GitHubu.
Tento týden (24. a 27. června) vyprší platnost Microsoft certifikátu v UEFI vydaných v roce 2011. Nové certifikáty byly vydány v roce 2023. Kdo na počítačích, i virtuálních, používá zabezpečené spouštění (Secure Boot), měl by si ověřit, že má certifikáty aktualizovány, viz např. články na Red Hat nebo Fedora. Pro stávající systémy se nic nemění. Nadále se budou normálně spouštět. Zavaděče podepsané pouze klíčem z 2023 se ale na počítačích s pouze certifikátem 2011 nespustí. Ve Fedoře je zavaděč shim ve verzi 16.1-6 podepsán klíči 2011 i 2023.
Uživatelé mobilních telefonů s Linuxem si nyní mohou nainstalovat aplikaci Mobilní Datovka. Díky tomu je přístup k datovým schránkám dostupný i na zařízeních s mobilními linuxovými distribucemi, jako jsou například Mobian, NixOS Mobile, pmOS atd. Aplikace je dostupná na Flathubu.
Software Freedom Conservancy v novém dokumentu shrnuje doporučení, jak přistupovat ke generativní AI založené na LLM při přispívání do svobodného a open-source softwaru. Mimo jiné vyzývá k obezřetnosti, transparentnosti a revizi generovaného kódu člověkem.
Byla vydána nová verze 5.6.0 programu na úpravu digitálních fotografií darktable (Wikipedie).
Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma. V Týdnu v GNOME je zmíněn flatpak balíček pro GIMP 0.54.1 z roku 1996. Jedná se o poslední verzi GIMPu postavenou nad toolkitem Motif.
Home Assistant Operating System, tj. linuxová distribuce optimalizována pro hostování Home Assistanta a jeho aplikací, byl vydán v nové major verzi 18.0.
Po šestiletém úsilí byla z jádra Linux odstraněna funkce strncpy(). Všechna předchozí volání této funkce byla převedena na bezpečnější alternativy.
Byla vydána nová verze 261 správce systému a služeb systemd (Wikipedie, GitHub). Z novinek lze vypíchnout nový subsystém IMDS (Cloud "Instance Metadata Service"), nový příkaz storagectl nebo novou komponentu systemd-sysinstall.
Vývojové prostředí Qt Creator bylo vydáno ve verzi 20 (seznam změn). Novinky zahrnují hlavně rozšíření pro integraci LLM agentů nebo minimalistický editační režim uživatelského rozhraní („zen mode“).
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: