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.
Před 25 lety zaplavil celý svět virus ILOVEYOU. Virus se šířil e-mailem, jenž nesl přílohu s názvem I Love You. Příjemci, zvědavému, kdo se do něj zamiloval, pak program spuštěný otevřením přílohy načetl z adresáře e-mailové adresy a na ně pak „milostný vzkaz“ poslal dál. Škody vznikaly jak zahlcením e-mailových serverů, tak i druhou činností viru, kterou bylo přemazání souborů uložených v napadeném počítači.
Byla vydána nová major verze 5.0.0 svobodného multiplatformního nástroje BleachBit (GitHub, Wikipedie) určeného především k efektivnímu čištění disku od nepotřebných souborů.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za duben (YouTube).
Provozovatel čínské sociální sítě TikTok dostal v Evropské unii pokutu 530 milionů eur (13,2 miliardy Kč) za nedostatky při ochraně osobních údajů. Ve svém oznámení to dnes uvedla irská Komise pro ochranu údajů (DPC), která jedná jménem EU. Zároveň TikToku nařídila, že pokud správu dat neuvede do šesti měsíců do souladu s požadavky, musí přestat posílat data o unijních uživatelích do Číny. TikTok uvedl, že se proti rozhodnutí odvolá.
Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.
Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.
V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).
Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Současné vývojové jádro 2.6 je stále 2.6.29-rc4 vydané 8. února. Obsahuje dlouhý seznam během týdne a půl začleněných oprav chyb. Zkrácený changelog je v oznámení, v kompletním changelogu vizte všechny detaily.
Současné stabilní jádro 2.6 je 2.6.28.4 vydané (společně s 2.6.27.15) 6. února. Obě aktualizace obsahují dlouhý seznam oprav. 2.6.28.5 a 2.6.27.16 - obsahující další dlouhý seznam oprav - jsou revidovány v době psaní tohoto článku; s největší pravděpodobností budou vydány 12. února.
Bylo nebylo, dostat patch do jádra znamenalo poslat ho e-mailem Linusu Torvaldsovi. Vývojář potom s nadějí očekával, až Linus vydá nový jaderný strom, a v něm viděl, jestli byl patch zahrnut, nebo ne. V tom druhém případě vytrvalejší vývojáři patch zaslali znovu. A často museli být opravdu vytrvalí, pokud chtěli, aby byl jejich kód opravdu začleněn. Jinými slovy - systém byl ztrátový; nikdy se už nedozvíme, kolik užitečného kódu bylo zahozeno.
Používání gitu (a předtím BitKeeperu) přineslo konec této éry. Jakmile se změna dostane do něčího stromu, je relativně nepravděpodobné, že by se ztratila. Pro všechny zúčastněné je to mnohem lepší způsob, jak pracovat; důležité opravy se již neztrácejí a vývojáři se místo toho, aby museli hledat své patche a zasílat je znovu, mohou věnovat vytváření nových chyb k opravení.
Krom toho se však věci změnily i tak, že pro většinu vývojářů neznamená dostat patch do jádra zaslat ho Linusovi. Místo toho svou práci předají přes strom subsystému. Tento mechanismus je relativně dobře chápán, ale, alespoň pokud autor tohoto článku ví, nikdo se pořádně nepodíval na to, jak vypadá tok patchů do hlavní řady jádra nyní. Proto se Jon Corbet odhodlal ke komplementárním úkolům (1) zmapovat cesty, kterými se patche ubírají na své cestě k Linusovi, a (2) zjistit, jak funguje Graphviz. Na obou frontách bylo dosaženo určitých úspěchů.
V dobách BitKeeperu se Jon zeptal Larryho McVoye, jestli existuje nějaký způsob, jak sledovat, kterými repozitáři prošla specifická sada změn; tuto informaci bohužel BitKeeper nezachovával. Jak se ukázalo, v tomto ohledu odvádí git mnohem lepší práci - i když záznamy také neuchovává perfektně. Když Linus přetáhne [pull] strom od nějakého jiného vývojáře, git (obvykle) přidá do repozitáře "merge commit", který obsahuje informaci, odkud ten strom přišel. Commit má (minimálně) dva rodičovské commity; jeden je ten, který byl na vrcholu Linusova stromu před začleněním, zatímco druhý ukazuje na vrchol proudu sad změn, který přišel z přetaženého stromu. Lze sloučit několik stromů naráz; v takovém případě budou víc než dva rodičovské commity.
Sledováním odkazů na každý commit k jeho rodiči je možné vysledovat, z kterého stromu přišel který commit. Začleňování jsou také šířena přes operace přetažení, takže je možné sledovat tuto historii zpět k libovolnému počtu stromů. Nástroj gitk hezky zobrazuje, jak se různé cesty sešly v jednom repozitáři; výsledný graf může být relativně složitý. Jon vytvořil statistický pohled na tento proces; tento pohled ztrácí informace o specifických patchích, ale poskytuje místo něj přehled o tom, jak se patche dostávají do hlavní řady.
Část výsledného grafu vidíte vpravo; celý graf je poměrně velký, kliknutím na náhled ho zobrazíte celý. Lze připustit, že obrázek je poněkud zmatený, ale některé zajímavé věci z něj vykukují. První je fakt, že graf je poměrně mělký: ukazuje 107 stromů, z nichž téměř všechny přechází přímo do hlavní řady. Co se vývojového cyklu 2.6.29 týče, pouze pár stromů je přetaženo do odděleného stromu subsystému předtím, než jdou k Linusovi, a jenom jeden strom posílá patche přes dvě úrovně. Z větší části správci subsystémů chodí rovnou za Linusem bez jednání s prostředníky.
975 z 11 260 sad změn šlo do hlavní řady přímo bez existence v jakémkoliv subsystémovém stromu. Některé z nich jsou slučovací sady změn, které vytváří Linus, když stromy přetahuje; mnoho ze zbytku jsou patche, které přichází od Andrewa Mortona. Velmi málo jich napsal Linus sám. Příležitostně je také začleněn patch zaslaný přímo od vývojáře, ale to je relativně vzácný jev.
Když tato čísla interpretujeme, je zde jedna věc, kterou je nutné mít na mysli: ve výchozím nastavení git neukládá začleňovací informace, když začleňuje v režimu "rychle vpřed" [fast forward]. Pokud vývojář stáhne celý současný repozitář hlavní řady, přidá na vrchol nějaké patche a poté přiměje Linuse k tomu, aby tyto patche přetáhl předtím, než se v hlavní řadě cokoliv změní, tyto patche lze přidat přímo do hlavní řady bez potřeby začleňovacího commitu, který by držel věci pohromadě. Začleňování rychle vpřed je v hlavní řadě (pravděpodobně) vcelku vzácné, ale na úrovni subsystémů se může dít častěji. Když tedy tyto informace generujeme z gitového repozitáře, nebudou nikdy 100% kompletní; některá začlenění (a repozitáře, odkud přišla), budou neviditelná.
Co se 2.6.29 týče, dva síťovací stromy spravované Davidem Millerem byly největšími přestupními body pro sady změn (pro 1910 z nich), které mířily do hlavní řady; mnoho z nich přišlo z bezdrátového stromu Johna Linvilla. Na druhém místě je strom "linux-2.6-tip" (strom spravovaný Ingo Molnárem a spol., obsahuje několik subsystémů včetně architektury x86 a plánovače), který v tomto vývojovém cyklu přispěl 1270 sadami změn. Mezi další velké zdroje změn patří strom btrfs (910 sad změn - kompletní vývojová historie btrfs), strom Video4Linux, strom zvuku a strom architektury ARM. Na druhém konci škály bylo dvanáct stromů zdrojem pěti nebo méně změn.
Pro zvědavé jsou statistiky k dispozici v textové podobě společně s celými jmény relevantních gitových repozitářů. Kód, který tyto informace vygeneroval, je k dispozici jako část repozitáře gitdm na git://git.lwn.net/gitdm.git. Zjevným možným místem pro vylepšení je sledovat informace o větvích uvnitř repozitářů; to by zvýšilo rozlišení celého obrazu. To ale přijde až v dalším vývojovém cyklu; nepřepínejte.
Je známo, že vztahy mezi vývojáři embedded systémů a jadernou komunitou jsou přinejlepším napjaté. Vývojáři jádra si stěžují na nekvalitní práci a nedostatek příspěvků ze strany vývojářů pro embedded zařízení; ti si zase, pokud vůbec něco řeknou, stěžují na to, že jaderná komunita nebere v úvahu jejich potřeby. V současnosti probíhající diskuze s vývojáři z projektu Android poskytuje náhled na to, odkud se toto neporozumění bere.
Android je samozřejmě platforma Googlu pro mobilní telefony. Původní Android byl vyvinut za zavřenými dveřmi; kód se dostal ven až poté, co už se vyráběly první série. Vývojáři Androidu udělali spoustu práce na jádře, ale jen velmi málo kódu podniklo cestu do hlavní řady. Kód, když už byl vůbec začleněn, šel všechen do stromu staging bez velké iniciativy na straně Androidu. Nyní se vývojář Androidu Arve Hjønnevåg snaží začlenit část infrastruktury projektu obvyklým procesem. A není to vůbec jednoduché.
Nejkontroverznějším kusem kódu je vlastnost nazvaná jako "probouzecí zámky" [wakelocks]. V jazyku Androidu jsou probouzecí zámky mechanismus, který brání systému přejít do stavu se sníženou spotřebou. Jenom v rychlém pohledu, jádro může nastavit probouzecí zámek nějak takto:
#include <linux/wakelock.h> wake_lock_init(struct wakelock *lock, int type, const char *name);
Hodnota type popisuje, o jaký druh probouzecích zámků se jedná; name mu přiřazuje jméno, které lze vidět v /proc/wakelocks. Pro typ existují dvě možnosti: WAKE_LOCK_SUSPEND brání systému v uspání, WAKE_LOCK_IDLE brání přechodu do stavu snížené spotřeby, který může zvýšit dobu odezvy. API pro získávání a uvolňování zámků je:
void wake_lock(struct wake_lock *lock); void wake_lock_timeout(struct wake_lock *lock, long timeout); void wake_unlock(struct wake_lock *lock);
Také je zde rozhraní pro uživatelský prostor. Zápis jména do /sys/power/wake_lock vytvoří zámek daného jména, které lze následně zapsat do /sys/power/wake_unlock a zámek uvolnit. Současná sada patchů umožňuje převzít zámky pouze z uživatelského prostoru.
Toto zaslání nebylo přijato příliš dobře. Naopak přitáhlo komentáře jako tento od Bena Herrenschmidta:
Nebo tento od Pavla Machka:
Důvody, proč si toto rozhraní neoblíbit, nekončí. Většina z něj duplikuje existující API pm_qos (quality of service, kvalita služby); zdá se, že pm_qos nevyhovuje potřebám Androidu, ale také že nebyla žádná snaha problémy napravit. Zdá se, že schéma je příliš složité, když všechno, co je skutečně potřeba, je příznak "neuspávat" nebo maximálně čítač. Patche vypínají existující rozhraní /sys/power/state, které s probouzecími zámky nefunguje dobře. Neexistuje možnost obnovy, když se proces v uživatelském prostoru ukončí, zatímco drží zámek. Výchozí chování systému je uspávat se, i když běží procesy; udržet systém vzhůru může vyžadovat řetěz probouzecích zámků, které získají různé systémové komponenty. A tak dál.
Konečným výsledkem je, že tento kód se do hlavní řady nedostane. Byl ale dodán ve velkém počtu telefonů G1 a mnohem více se jich chystá. Uživatelé těchto telefonů tedy budou používat kód mimo strom, který nebude začleněn, přinejmenším rozhodně ne v současné podobě. Jakákoliv aplikace, která závisí na sysfs rozhraní probouzecích zámků, přestane fungovat, až se toto rozhraní dostane na standardní úroveň. Je to zmatečné, ale jde o zmatek, který je typický pro vývoj embedded zařízení. Vývojáři těchto zařízení totiž pracují s omezeními, kvůli kterým je dodržování správného postupu vývoje jádra obtížné. Například:
Jedním ze základních pravidel vývoje jádra je "zasílat brzy a často". Kód, který je vyvíjen za zavřenými dveřmi nemá žádnou zpětnou vazbu od komunity vývojářů, takže snadno může jít dlouho slepou uličkou. Prodejci embedded systémů nicméně většinou nechtějí, aby se svět dozvěděl, co se chystá, dokud produkt není připraven k prodeji; doufají, že jejich konkurence bude tápat ve tmě tak dlouho, jak to jen bude možné. Zasílání brzy tedy většinou není přípustné.
Další důležité pravidlo je "nejprve do upstreamu": kód se musí do hlavní řady dostat dřív, než je dodán zákazníkovi. I zde i kdyby prodejce chtěl zaslat kód do hlavní řady, výjimečně tak bude chtít učinit předtím, než se produkt začne dodávat. Jádra v embedded zařízeních jsou tedy dodávána s kódem mimo strom, který má téměř jistě řadu problémů, nepodporovatelné API a další.
Od jaderných vývojářů se očekává, že jejich cílem je vylepšit jádro pro všechny. Vývojáři embedded zařízení na druhou stranu obecně řeší vysoce specifický problém s přísným časovým omezením. Proto nepřemýšlí o tom, že by například rozšířili existující API kvality služby tak, aby splňovalo jejich potřeby; místo toho nabuší něco, co je rychlé, ošklivé a neprochází revizí v upstreamu.
Dalo by se dohadovat, že Google má čas, zdroje a vlastní vědomosti, díky kterým by se všem těmto problémům mohl vyhnout a udělat věci dobře. Místo toho se nám dostalo poměrně klasické ukázky toho, jak se věci mohou pokazit.
Dobrá zpráva je, že vývojáři z Googlu nyní kontaktují komunitu a snaží se dostat svůj kód do hlavní řady. Tento proces může trvat dlouho a vyžadovat hodně změn na straně Androidu. I kdyby návrh probouzecích zámků jako způsobu, kterým zabránit systému uspat se, byl přijat - což není vůbec jisté - rozhraní bude potřebovat značně změnit. S ním spojené API "časného uspání" [early suspend] - což v je v podstatě mechanismus upozorňující na změny stavu systému - bude muset být zobecněno nad specifické potřeby telefonu G1. Snadno to může znamenat spoustu práce.
Když nicméně bude tato práce provedena, jádro bude mnohem lépe vybaveno k tomu řešit potřeby správy napájení přenosných zařízení. Z toho by mohl každý, kdo pracuje na nasazení Linuxu v embedded zařízeních, jenom profitovat. A, což je důležité, pomohlo by to vývojářům Androidu, až budou svůj kód portovat na jiné zařízení s jinými potřebami. Až počet na Androidu založených telefonů vzroste, náklady na údržbu kódu mimo strom, aby podporoval všechna zařízení, budou také růst. Bylo by mnohem lepší tuto podporu zobecnit a dostat do hlavní řady, kde by ji mohla spravovat a vylepšovat komunita.
Zdá se, že většina prodejců embedded systémů nebude chtít tuto práci dělat; mají příliš mnoho práce s tím dát dohromady nový produkt. Tento druh kódu tudíž většinou odumírá mimo hlavní řadu a kvalita embedded Linuxu tím trpí. Tento případ bude možná jiný; Google možná využije své zdroje k tomu, aby svůj specializovaný kód dostal do formy a začlenil ho do hlavní řady. Tato snaha by mohla pomoci získat Androidu pověst pevné, dobře podporované platformy pro mobilní využití, což by mělo být dobré pro obchod. Autor tohoto článku, věčný optimista, doufá, že se věci odehrají takto; byla by to dobrá demonstrace toho, jak komunita vývojářů embedded zařízení může lépe pracovat s lidmi od jádra a obratem získat lepší jádro.
Mimo jádro dlouho existující vlastnost - kterou používá půl tuctu či více antivirových programů - Dazuko nedávno změnila svůj modus operandi ve snaze o začlenění do jádra. Dazuko a nyní DazukoFS jsou mechanismy pro řízení přístupu k souborům, které jsou obecně používány k tomu, aby se viry pro Windows nešířily na linuxové servery. Cíl je v mnoha ohledech podobný fsnotify/fanotify/TALPA, ale DazukoFS je implementován jako skládatelný [stackable] souborový systém se zcela jiným přístupem.
Projekt Dazuko začal téměř přesně před sedmi lety jako snaha umožnit programům v uživatelském prostoru - většinou antivirovým programům ve stylu těch pro Windows - rozhodovat o přístupu k souborům. Jedním důvodem, proč mít vyhledávání virů v uživatelském prostoru - kromě nulové pravděpodobnosti, že by se nějaké dostalo do jádra - je zachovat neutralitu vůči výrobcům nezvýhodňováním žádného konkrétního protivirového enginu. Prostředkem k tomuto cíli se nicméně staly háčky v systémových voláních, což je technika, která se jaderným vývojářům nelíbí. Dazuko ustoupilo k LSM API, ale narazilo na různé problémy, včetně nemožnosti skládat několik bezpečnostních modulů. Nakonec se projekt začal poohlížet po skládatelném souborovém systému jako řešení, které by bylo stravitelné pro přesun do hlavní řady.
Skládatelný souborový systém, který Dazuku poprvé doporučil Christoph Hellwig roku 2004, má nad jinými řešeními mnoho výhod. Jde o samostatné řešení, které nebude vyžadovat žádné změny vnitřních částí jádra [core kernel], pokud si vývojáři antivirů budou přát přidat nové vlastnosti. Také by to znamenalo přidání dalšího skládatelného souborového systému do jádra, což by mohlo pomoci pečovat o obecnější framework skládatelných souborových systémů. Hlavním důvodem je ale to, že projekt tuto cestu vidí jako nejpravděpodobnější pro začlenění. Hlavní vývojář John Ogness vysvětluje:
Aby mohl řešit rozhodnutí o přístupu k souborům, je DazukoFS připojen do již připojeného souborového systému. Například:
mount -t dazukofs /opt /opt
nastaví souborový systém /opt pro kontrolu procesů v uživatelském prostoru, které otevřou speciální soubor v /dev. Veškeré interakce mezi prohledávacími aplikacemi a DazukoFS se odehrávají přes /dev soubory, všechno je zdokumentováno v Documentation/filesystems/dazukofs.txt.
Rozhodování o přístupu k souborům přísluší procesům nebo vláknům, které tvoří "skupinu". Skupina se chová jako fond [pool] dostupných prohledávačů, které umožňují několik paralelních rozhodování o přístupu k souborům. Jakmile je fond zcela zaneprázdněn, přístupy k souborům blokují, dokud některý z prohledávačů nebude k dispozici. Skupiny se registrují zápisem add=NázevSkupiny do /dev/dazukofs.ctrl. Poté je přiřazeno id skupiny, které lze hledat ve výstupu čtení ze souboru dazukofs.ctrl. ID skupiny se používají k přístupu ke správnému zařízení při rozhodování o povolení přístupu.
V závislosti na id skupiny (N) je vytvořen soubor /dev/dazukofs.N. Každý proces ve skupině se registruje tím, že tento soubor zařízení otevře. Pak by měl blokujícím způsobem číst tento soubor a čekat na událost přístupu k uživatelskému souboru. Každá událost obsahuje tři informace, které se načtou: id události, id programu, který ji vyvolal, a číslo otevřeného popisovače souboru, který lze použít pro čtení obsahu daného souboru. Prohledávající proces by poté měl provést všechno, co potřebuje k rozhodnutí o povolení přístupu.
Protože je mu popisovač souboru předán, nepotřebuje prohledávající proces žádná zvláštní oprávnění kromě přístupu k souborům /dev/dazukofs*. Jakmile je rozhodnuto, proces zapíše řetězec určující výsledek zpět do zařízení. Pak je zodpovědný za uzavření popisovače souboru, který prohledával.
Pomocí API pro uživatelský prostor lze udělat několik dalších věcí: mazat skupiny, poskytnout nějakou ochranu proti pádu uvnitř skupin a řešení přístupů k chráněným souborům z DazukoFS, vše je popsáno v souboru v Documentation.
V tomto vydání DazukoFS je také důležitý problém:
Z části se to dělá kvůli tomu, aby nemohlo dojít k souběhu, kdy škodlivý program přepíše obsah souboru mezi jeho prohledáním a skutečným přístupem. To je obecně achillova pata mechanismů prohledávání souborů, ale tiché ignorování zápisů do paměťově mapovaných souborů je poněkud extrémní reakce na tento problém. TALPA, ze kterého se nedávno stalo fanotify, definuje tento problém tak, že není součástí modelu ohrožení, na který reaguje. DazukoFS by možná mohlo udělat něco podobného.
Zdálo by se, že jenom jedno z těchto dvou navržených řešení pro hledání virů z uživatelského prostoru skončí v hlavní řadě. John ve svém zaslání patche fanotify zmiňuje:
Doteď nebylo nijak komentováno zaslání druhé verze patche, ale k prvnímu zaslání v prosinci byly nějaké připomínky. Lidé od jádra jsou obecně dost zaměstnaní, ale v současnosti je navíc revidováno mnoho souborových systémů: btrfs, POHMELFS, DST, FS-Cache a další. Ty pravděpodobně spotřebovávají všechnu dostupnou revidovací sílu. John nedávno oznámil, že končí s podporou Dazuko verze 2.x - založené na háčcích v systémových voláních - aby se mohl zaměřit na DazukoFS. V tomto oznámení upozorňuje na nedostatek revizí:
Z oznámení je jasné, že John má trpělivost potřebnou k tomu, aby provedl DazukoFS procesem začleňování do jádra. Zdá se, že by také mohlo být užitečné věnovat nějaký čas spoluprací s Ericem Parisem a pokusit se najít společné základy jejich dvou řešení.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Diky za preklady, je to vzdy zajimave cteni. Jen bych upozornil, ze pro slovo stackable je vhodnejsi stohovatelny, ve smyslu vrsit jeden na druhy, nez slovo skladatelny, coz spise evokuje skladani vice dilu do jednoho celku. Myslim, ze se tak prekladaji i stohovatelne prepinace, takze je to zavedeny pojem...
Já bych zase jen rád upozornil, že git-merge má parametr --no-ff, který právě vynutí recursive merge místo fast-forward a vytvoří merge commit, tudíž není podmínkou, že se něco v hlavní řadě musí změnit.
Já bych zase jen rád upozornil, že git-merge má parametr --no-ff, který právě vynutí recursive merge místo fast-forward a vytvoří merge commit, tudíž není podmínkou, že se něco v hlavní řadě musí změnit.Já bych řekl, že to je z textu poměrně jasné. Teda ne přesně to, že ten parametr je --no-ff, ale že nějaký takový parametr existuje.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz