MALUS je kontroverzní proprietarní nástroj, který svým zákazníkům umožňuje nechat AI, která dle tvrzení provozovatelů nikdy neviděla původní zdrojový kód, analyzovat dokumentaci, API a veřejná rozhraní jakéhokoliv open-source projektu a následně úplně od píky vygenerovat funkčně ekvivalentní software, ovšem pod libovolnou licencí.
Příspěvek na blogu Ubuntu upozorňuje na několik zranitelností v rozšíření Linuxu o mandatorní řízení přístupu AppArmor. Společně jsou označovány jako CrackArmor. Objevila je společnost Qualys (technické detaily). Neprivilegovaný lokální uživatel se může stát rootem. Chyba existuje od roku 2017. Doporučuje se okamžitá aktualizace. Problém se týká Ubuntu, Debianu nebo SUSE. Red Hat nebo Fedora pro mandatorní řízení přístupu používají SELinux.
Byla vydána nová verze 19 integrovaného vývojového prostředí (IDE) Qt Creator. Podrobný přehled novinek v changelogu.
Bitwig Studio (Wikipedie) bylo vydáno ve verzi 6. Jedná se o proprietární multiplatformní (macOS, Windows, Linux) digitální pracovní stanici pro práci s audiem (DAW).
Společnost Igalia představila novou linuxovou distribuci (framework) s názvem Moonforge. Jedná se o distribuci určenou pro vestavěné systémy. Vychází z projektů Yocto a OpenEmbedded.
Google Chrome 146 byl prohlášen za stabilní. Nejnovější stabilní verze 146.0.7680.71 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 29 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
D7VK byl vydán ve verzi 1.5. Jedná se o fork DXVK implementující překlad volání Direct3D 3 (novinka), 5, 6 a 7 na Vulkan. DXVK zvládá Direct3D 8, 9, 10 a 11.
Bylo vydáno Eclipse IDE 2026-03 aneb Eclipse 4.39. Představení novinek tohoto integrovaného vývojového prostředí také na YouTube.
Ze systému Slavia pojišťovny uniklo přibližně 150 gigabajtů citlivých dat. Jedná se například o pojistné dokumenty, lékařské záznamy nebo přímou komunikaci s klienty. Za únik může chyba dodavatelské společnosti.
Sněmovna propustila do dalšího kola projednávání vládní návrh zákona o digitální ekonomice, který má přinést bezpečnější on-line prostředí. Reaguje na evropské nařízení DSA o digitálních službách a upravuje třeba pravidla pro on-line tržiště nebo sociální sítě a má i víc chránit děti.
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: