PixiEditor byl vydán ve verzi 2.0. Jedná se o multiplatformní univerzální all-in-one 2D grafický editor. Zvládne rastrovou i vektorovou grafiku, pixel art, k tomu animace a efekty pomocí uzlového grafu. Zdrojové kódy jsou k dispozici na GitHubu pod licencí GNU LGPL 3.0.
Byly představeny novinky v Raspberry Pi Connect for Organisations. Vylepšen byl protokol auditu pro lepší zabezpečení. Raspberry Pi Connect je oficiální služba Raspberry Pi pro vzdálený přístup k jednodeskovým počítačům Raspberry Pi z webového prohlížeče. Verze pro organizace je placená. Cena je 0,50 dolaru za zařízení za měsíc.
CISA (Cybersecurity and Infrastructure Security Agency) oznámila veřejnou dostupnost škálovatelné a distribuované platformy Thorium pro automatizovanou analýzu malwaru. Zdrojové kódy jsou k dispozici na GitHubu.
Ubuntu nově pro testování nových verzí vydává měsíční snapshoty. Dnes vyšel 3. snapshot Ubuntu 25.10 (Questing Quokka).
Společnost Proton AG stojící za Proton Mailem a dalšími službami přidala do svého portfolia Proton Authenticator. S otevřeným zdrojovým kódem a k dispozici na všech zařízeních. Snadno a bezpečně synchronizujte a zálohujte své 2FA kódy. K používání nepotřebujete Proton Account.
Argentinec, který byl náhodně zachycen Google Street View kamerou, jak se zcela nahý prochází po svém dvorku, vysoudil od internetového giganta odškodné. Soud uznal, že jeho soukromí bylo opravdu porušeno – Google mu má vyplatit v přepočtu asi 12 500 dolarů.
Eben Upton, CEO Raspberry Pi Holdings, informuje o RP2350 A4, RP2354 a nové hackerské výzvě. Nový mikrokontrolér RP2350 A4 řeší chyby, i bezpečnostní, předchozího RP2350 A2. RP2354 je varianta RP2350 s 2 MB paměti. Vyhlášena byla nová hackerská výzva. Vyhrát lze 20 000 dolarů.
Představen byl notebook TUXEDO InfinityBook Pro 15 Gen10 s procesorem AMD Ryzen AI 300, integrovanou grafikou AMD Radeon 800M, 15,3 palcovým displejem s rozlišením 2560x1600 pixelů. V konfiguraci si lze vybrat až 128 GB RAM. Koupit jej lze s nainstalovaným TUXEDO OS nebo Ubuntu 24.04 LTS.
Po půl roce od vydání verze 2.41 byla vydána nová verze 2.42 knihovny glibc (GNU C Library). Přehled novinek v poznámkách k vydání a v souboru NEWS. Vypíchnout lze například podporu SFrame. Opraveny jsou zranitelnosti CVE-2025-0395, CVE-2025-5702, CVE-2025-5745 a CVE-2025-8058.
Byla vydána nová verze 9.15 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání.
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: