Coppwr, tj. GUI nástroj pro nízkoúrovňové ovládání PipeWire, byl vydán v nové verzi 1.6.0. Zdrojové kódy jsou k dispozici na GitHubu. Instalovat lze také z Flathubu.
Byla vydána dubnová aktualizace aneb nová verze 1.89 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Vypíchnout lze, že v terminálu lze nově povolit vkládání kopírovaného textu stisknutím středního tlačítka myši. Ve verzi 1.89 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Proton, tj. fork Wine integrovaný v Steam Play a umožňující v Linuxu přímo ze Steamu hrát hry určené pouze pro Windows, byl vydán ve verzi 9.0-1 (𝕏). Přehled novinek se seznamem nově podporovaných her na GitHubu. Aktuální přehled her pro Windows běžících díky Protonu také na Linuxu na stránkách ProtonDB.
Byla vydána verze 1.78.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání na GitHubu. Vyzkoušet Rust lze například na stránce Rust by Example.
Služba Dropbox Sign (původně HelloSign) pro elektronické podepisování smluv byla hacknuta.
Byla vydána nová major verze 8.0 textového editoru GNU nano (Wikipedie). Podrobný přehled novinek a oprav v oznámení v diskusním listu info-nano nebo v souboru ChangeLog na Savannah. Volbou --modernbindings (-/) lze povolit "moderní" klávesové zkratky: ^C kopírování, ^V vložení, ^Z vrácení zpět, … Tato volba je aktivována také pokud binárka s nano nebo link na ni začíná písmenem "e".
Před 60 lety, 1. května 1964, byl představen programovací jazyk BASIC (Beginners' All-purpose Symbolic Instruction Code).
Byla vydána nová verze 12.0 minimalistické linuxové distribuce (JeOS, Just enough Operating System) pro Kodi (dříve XBMC) a multimediálního centra LibreELEC (Libre Embedded Linux Entertainment Center). Jedná se o fork linuxové distribuce OpenELEC (Open Embedded Linux Entertainment Center). LibreELEC 12.0 přichází s Kodi 21.0 "Omega".
Microsoft vydal novou velkou aktualizaci 2404.23 v září 2019 pod licencí SIL Open Font License (OFL) zveřejněné rodiny písma Cascadia Code pro zobrazování textu v emulátorech terminálu a vývojových prostředích.
OpenTofu, tj. svobodný a otevřený fork Terraformu vzniknuvší jako reakce na přelicencování Terraformu z MPL na BSL (Business Source License) společností HashiCorp, bylo vydáno ve verzi 1.7.0. Přehled novinek v aktualizované dokumentaci. Vypíchnout lze State encryption.
Současné vývojové jádro je 4.12-rc3, vydané 28. května. Abychom citovali Linuse: „Hele, pořád to vypadá dobře a rc3 ani není moc velké. Doufám, že nás nečeká žádné překvapení, ale zatím to vypadá na příjemně klidný vývojový cyklus, velikosti začleňovacího okna navzdory.“
Stabilní aktualizace: 4.11.3, 4.9.30, 4.4.70 a 3.18.55 byly vydány 25. května.
Nedávný článek Kontejnery jako jaderné objekty se věnoval pokusu o přidání formálního konceptu „kontejner“ do jádra, částečně jako způsob, jak zajistit běh jaderných upcallů (volání z jádra do programu v uživatelském prostoru) ve správných jmenných prostorech. Nyní je David Howells zpět s jiným přístupem: způsobem, jak by mohl proces démona zachytávat a spravovat upcally s určitým klíčem.
Konkrétně systémové volání keyctl() je vylepšeno o příkaz KEYCTL_SERVICE_CREATE, který vrací speciální popisovač souboru. Následující volání mohou přidávat „filtry“ popisující upcally, které mají být zachyceny. Ty jsou popsány jménem a skupinou příznaků označujících množinu relevantních jmenných prostorů. Pokud se jmenné prostory volajícího programu shodují s těmi procesu, který upcall vytváří, bude programu povoleno zpracovat dané volání. Podrobnější popis toho, jak to funguje, najdete v příspěvku s patchem.
Být jedinečná sněhová vločka ve velké komunitě, jakou ta okolo jádra je, je občas nezbytné, protože když dělají všichni totéž, celá komunita se nic nového nenaučí.
V praxi jsou whitelisty sestavovány tak, že na začátku je na nich všechno a postupně se odmazávají položky, dokud věci nepřestanou pracovat, potom jsou příslušné položky vráceny zpět. Whitelisty jsou teoreticky skvělé, ale je těžké je sestavit a v reálném světě také udržovat.
Souhlasím s tím, že se jedná o zvláštní scénář. Ovšem programátoři uživatelského prostoru přečíslují jaderné vývojáře 10 000 ku 1 a časem přijdou na všechny možné způsoby, jak API kreativně využít, pokud se jim „bude hodit.“
—Michael Kerrisk (díky Dimitriji Safonovi)
Linuxová vrstva asynchronního I/O (AIO) mívá hodně kritiků a málo zastánců, ale většina lidí alespoň očekává, že bude skutečně asynchronní. Ve skutečnosti může být operace AIO blokující v jádře z vícero důvodů, což vede k tomu, že je AIO obtížné použít v situacích, kdy si volající vlákno skutečně nemůže dovolit blokovat. Přetrvávající sada patchů, která by měla situaci zlepšit, se blíží svému dokončení, ale jde spíše o krok správným směrem než o skutečně řešení problému.
K provedení AIO musí program nastavit kontext I/O pomocí io_setup(), vyplnit jednu nebo více struktur iocb popisujících operace, které se mají provést, potom tyto struktury odeslat pomocí io_submit(). Volání io_getevents() se dá použít ke zjištění stavu nevyřízených I/O operacích – a volitelně také počkání na ně. Všechna tato systémová volání, s výjimkou posledního, by měla být neblokující. Ve skutečnosti je to složitější. Přidělení paměti nebo zabrání zámku může způsobit blokování libovolnou operací AIO, a to dříve než dojde k zahájení přenosu dat. Dokonce i v nejlepším případě (I/O přímo do/z souboru) může samotná operace blokovat na více místech.
Sada patchů nečekajícího AIO Goldwyna Rodriguese se snaží tuto situaci vylepšit hned několika způsoby. Nečiní AIO asynchronnějším, ale vede k selhání AIO operací s chybami EAGAIN namísto blokování v řadě situací. Pokud je program na podobné chyby připravený, může se aktivně pokusit předložit I/O v hlavním vlákně. Pak se bude muset pouze uchýlit do samostatného zadávacího vlákna v případech, kdy by operace blokovala.
Pokud je program navržen, aby používal nečekající AIO, musí to dát najevo nastavením nového příznaku IOCB_RW_FLAG_NOWAIT ve struktuře iocb. Tato struktura má pole (aio_flags), která má obsahovat pouze tyto typy příznaků, ale je v tom háček: jádro aktuálně v tomto poli nekontroluje neznámé příznaky. To znemožňuje přidání nového příznaku, protože volající program nemůže nikdy vědět, zda jádro, na kterém běží, tento příznak podporuje či nikoli. Naštěstí tato struktura obsahuje několik rezervovaných polí, která v současných jádrech jsou kontrolována. Pole dříve známé jako aio_reserved1 je v této sadě patchů změněno na aio_rw_flags a používáno pro nový příznak.
Jedním z míst, kde může I/O požadavek blokovat, je operace, která spustí operaci zpětného zápisu. V takovém případě bude požadavek zdržen až do dokončení zpětného zápisu. Toto čekání se projeví na začátku procesu podání požadavku, konkrétně k němu může dojít před dokončením io_submit() a jeho vrácením. Nastavení příznaku IOCB_RW_FLAG_NOWAIT způsobí, že podání požadavku v tomto případě selže s EAGAIN.
Dalším běžným místem blokování je zadání I/O požadavku na blokové úrovni: ten může být pozastaven, protože příslušné blokové zařízení je zaneprázdněné. Možnost, jak se tomu vyhnout, zahrnuje vytvoření nového příznaku REQ_NOWAIT, který je možné nastavit ve struktuře BIO, která se používá k popisu požadavků na blokové I/O. Pokud je tento příznak přítomen, I/O požadavek opět místo blokování čekáním na blokové zařízení selže s chybou EAGAIN.
Podpora je nutná také na úrovni souborového systému, každý souborový systém má svá vlastní místa, kde může vykonání blokovat cestu k zadání požadavku. Sada patchů obsahuje podporu Btrfs, ext4 a XFS. V každém případě situace, jako je neschopnost získat zámek na příslušném inode, způsobí selhání požadavku.
Všechny tyto práce mohou AIO vylepšit, ale pouze pro omezený počet případů užití. Zlepšuje například pouze přímé I/O. I/O s vyrovnávací pamětí (buffered I/O), které bylo vždy ve vrstvě AIO spíše občanem druhé kategorie, se nemění – je příliš mnoho míst, kde může dojít k blokování, a není síla vyřešit je všechna. Obdobně neexistuje podpora síťových souborových systémů nebo souborových systémů na MD a LVM oddílech — ačkoliv Rodrigues plánuje někdy v budoucnu některá z těchto míst časem zaplnit.
Jinými slovy se zdá, že AIO zůstane užitečným jen pro těch několik aplikací, které provádějí I/O přímo nad soubory. V minulosti došlo k řadě pokusů o zlepšení situace, včetně fibrilů, threadletů, sysletů, acall a reimplementace AIO založené na jaderných vláknech, provedené původním autorem AIO. Ani jeden z těchto pokusů ovšem nikdy nedosáhl stavu, kdy by bylo zvažováno jeho začlenění do hlavního repozitáře. Existuje příliš mnoho choulostivých detailů, které je třeba vyřešit, než bude možné implementovat kompletní řešení, a zatím nikdo neshledal tento úkol natolik důležitým, aby ospravedlnil značnou práci, kterou je třeba vynaložit na řešení tohoto problému. Takže jádro se asi bude i nadále plazit kupředu s inkrementálními vylepšeními AIO.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz