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.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Aktuální předverze je (25. 7. 2007) 2.6.23-rc1, vydaná 22. června. Doba pro začleňování nových věcí do 2.6.23 skončila. Vizte článek níže, kde najdete funkce zařazené od minulého týdne; kompletní přehled získáte z krátkého changelogu - nebo z dlouhého, pokud nevíte co s časem.
Od vydání -rc1 si do hlavního git repozitáře našlo cestu více než 100 dalších patchů. Jde většinou o opravy, ale je mezi nimi i patch odstraňující typedef request_queue_t - o něco později byl obnoven s příznakem "zastaralý" [deprecated].
Aktuální verze -mm stromu je 2.6.23-rc1-mm1. Strom výrazně pohubl, protože se patche přesunuly do hlavní větve; mezi další změny patří aktualizace IDE, autorizace USB zařízení, patch s linuxovými bezpečnostními ne-moduly, nový patch se souborovými kvalifikacemi, nové funkce ext4 a jmenné prostory ID procesů.
Starší jádra: 2.6.16.53-rc1 bylo vydáno 23. června - první aktualizace 2.6.16 po dlouhé době.
2.4.34.6 vyšlo 22. června s několika opravami. 2.4.35-rc1 je také venku - s větši sadou oprav; finální 2.4.35 by se mělo objevit brzy.
Stupidní chyby se při zpětném pohledu zdají roztomilé.
V Linuxu odmítáme _hodně_ kódu, což je jediný způsob, jak dělat kvalitní jádro. Je to trochu jako evoluční výběr: neuvěřitelně marnotraný a úchvatně účinný zároveň.
-- Ingo Molnar
Omluva všem, kteří se těšili na výběr z té série limeriků, která nedávno proběhla přes LKML; máte-li zájem, najdete je skoro všechny v tomto vlákně.
Linus uzavřel 2.6.23 novým patchům, ale ještě předtím jich tam několik proklouzlo:
Změny viditelné vývojáři jádra:
Protože už začleňování skončilo, žádné další funkce by se v tomto vývojovém cyklu neměly do jádra dostat. Možná se však objeví jedna nebo dvě výjimky: několik vývojářů období pro začleňování propáslo a doufají, že se jim podaří protlačit pár změn i po -rc1.
Specifikace Secure Digital Input/Output [bezpečný digitální vstup/výstup] umožňuje vytváření SD karet, které se starají o úkoly i nad rámec běžného ukládání bitů - což je to, na co se karty SD tradičně používaly. SDIO stránka SD asociace ukazuje několik roztomilých obrázků SDIO síťových adaptérů, fotoaparátů, GPS přijímačů, čteček otisků prstů a, kupodivu, i znepokojující obrázek skeneru přilepeného přímo k SD kartě. Protože se do oběhu dostává čím dál více hraček s SD sloty, lze si představit množství různých způsobů využití periferií připojených do těchto slotů. A protože mnohé z těchto hraček běží na Linuxu, bylo by fajn mít řádnou podporu SDIO zařízení přímo v jádře. Bohužel je SDIO, podobně jako většina práce SD asociace, z oblasti proprietárních specifikací a implementací.
To se však asi změní: Pierre Ossman poslal následující zajímavé oznámení:
S radostí oznamuji, že podpora SDIO bude brzy standardní funkcí linuxového jádra. Už žádné další proprietární stacky se všemi problémy (právními a technickými), které přinášejí.
Nový SDIO stack, který napsali Pierre a Nicolas Pitre, je docela kompletní - obsahuje všechny možné druhy podpory na úrovni sběrnice, které už dnes autoři ovladačů očekávají. K dispozici je jeden ovladač (pro GPS rozhraní); brzy se pravděpodobně objeví další. Pokud půjde vše podle plánu, dostane se SDIO Qstack do jádra 2.6.24.
V říjnu 2006 se mluvilo o navrhované metodě fault() pro oblasti virtuální paměti. Tato změna API byla uvedena jako součást opravy obskurního (avšak reálného) souběhu [race condition]. Taková oprava se zdála důležitá, ale stejně trvalo téměř rok, než se fault() dostala do jádra. Když byl teď patch začleněn do 2.6.23, podívejme se na API, které bylo přijato.
Oblast virtuální paměti [virtual memory area (VMA)] v jádře reprezentuje kus virtuálního adresního prostoru procesu. Každá VMA je mapována určitým vlastním způsobem; většina je mapována do souborů na disk, ale existují i anonymní VMA (mapované do swapu), mapování do paměti zařízení a další. Každá VMA musí poskytovat handler [obsluha, zpracovávající funkce] pro situace, kdy specifická stránka z dané VMA není v hlavní paměti; handler musí situaci buď napravit, nebo jádru říci, že to není možné. Ve většině případů se o to stará metoda nopfn() nebo starší (ale více používaná) nopage(). Jsou zavolány s offsetem chybějící stránky v rámci VMA a očekává se od nich, že vrátí ukazatel na její strukturu page. U komplikovanějších případů, zvláště u nelineárních VMA, se volá metoda populate().
Existence tří funkcí pro stejný úkol naznačuje, že se postupem času měnily požadavky, a bylo by na místě kód pročistit. A když žádné ze třech rozhraní nemůže být rozšířeno, aby zabránilo souběhu, tlak na nové řešení sílí ještě více. Nový přístup, který navrhl a napsal Nick Piggin, je metoda fault(), která by nakonec měla nahradit všechny tři ostatní. fault() vypadá takto:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
int (*fault)(struct vm_area_struct *vma, struct vm_fault *vmf);
Většina informací, které nás zajímají, se nachází v nové struktuře vm_fault:
struct vm_fault {
unsigned int flags;
pgoff_t pgoff;
void __user *virtual_address;
struct page *page;
};
Metoda fault() by měla, stejně jako její předchůdci, zařídit, aby chybějící stránka existovala - a vrátit její adresu jádru. Rozhraní je však pružnější.
Offset chybějící stránky se nachází v poli pgoff. Handlery chyb najdou odpovídající adresu v uživatelském prostoru také ve virtual_address. Ale kdokoliv by byl v pokušení to pole použít, by se měl připravit na vysvětlování skeptickému zástupu vývojářů jádra. Většina handlerů by se neměla starat o to, kde v uživatelském prostoru stránka je; a použití virtual_address navíc znemožní podporu nelineárních VMA. Takže je-li to jen trochu možné, měla by být virtual_address ignorována. Pokud váš kód používá pouze pgoff, měl by nastavit příznak VM_CAN_NONLINEAR ve struktuře vm_flags příslušné VMA, aby dal jádru najevo, že hraje podle pravidel.
Pole flags má dva možné příznaky:
Když fault() dokončí svoji práci, měla by uložit ukazatel do pole page ve struktuře page příslušné stránky - ale níže je uvedena výjimka. Návratová hodnota fault() je sada příznaků, které určují několik věcí:
Všechny instance volání VMA operace populate() byly změněny a metoda již neexistuje. Byl vytvořen záznam pro budoucí odstranění nopage(), což značí, že půjde pryč "co nejdříve". Jádro však má i nadále množství implementací nopage(), takže může chvilku trvat, než se jí podaří zbavit. Dlouhodobé plány volají i po odstranění nopfn(), i když pro to ještě nebylo stanoveno datum. Každopádně by veškerý nový kód, který implementuje mmap(), měl být napsán tak, aby výpadky řešil pomocí fault().
Už je to skoro dva roky od chvíle, kdy se na LWN psalo o přednatahování swapu [swap prefetch] od Cona Kolivase. Kód je založen na myšlence, která říká, že když si systém nastrkal uživatelská data do swapu, tak by v době nečinnosti mohl místo poflakování strávit trochu času spekulativním stahováním vyswappovaných dat zpátky do volné paměti. Když pak nějaká aplikace v budoucnu bude data chtít, budou hned k dispozici a vyhneme se časově náročnému načítání z disku.
Klasickým příkladem použití pro tuto funkci je desktopový systém, na kterém v noci běží démony náročné na paměť (řekněme updatedb nebo zálohování). Tyto démony nastrkají do swapu spoustu užitečných dat, kde se budou nudit, dokud nepřijde ráno uživatel s kafem v ruce. Kafe řečeného uživatele však klidně může vystydnout, než se otevřeným aplikacím podaří získat [fault in] dost paměti na to, aby mohly znovu fungovat. Přednatahování swapu je tu proto, aby si uživatelé mohli užívat svých počítačů i horkého kafe najednou.
Existuje hlasitá skupina uživatelů, kteří potvrdí, že díky přednatahování jejich systémy fungují lépe. Přesto však funkce zůstala v -mm skoro celé ty dva roky, aniž by byla cesta do hlavního jádra na dohled. Con to vzdal (patch i vývoj jádra obecně):
Doba pro začleňování do 2.6.23 je teď pryč a tvůj postoj je jasný. Podporoval jsem ten kód v -mm 21 měsíců (od 16. října 2005), ale nebylo o něm pořád rozhodnuto - ať tak nebo tak.
Už nejsem součástí vývoje vašeho jádra; nemohu ten kód tedy dále podporovat. Pokud někdo nepřevezme vývoj, měl bys to považovat za nespravovaný kód a smazat ho.
Je nešťastné, když talentovaného vývojáře s dobrými úmysly vývojový proces jádra otráví natolik, že odejde. Nemůžeme si dovolit takové lidi ztrácet. Stojí tedy za to se pokusit porozumět tomu, kde se stala chyba.
Problém č. 1 je, že se Con rozhodl pracovat na jedné z nejošemetnějších částí jádra. Swap prefetch je patch týkající se správy paměti a takové patche mají do jádra vždycky dlouhou a obtížnou cestu. Nenarazil takto pouze Con; patche s bezzámkovou keší stránek od Nicka Piggina už klepají na dveře stejně dlouho. A LWN článek o přizpůsobivém přednačítání od Wu Fengguanga se objevil přibližně ve stejné době jako článek o přednatahování swapu - a to ještě po té, co na patche Jonathan Corbet týdny zíral a sbíral odvahu o nich něco napsat. Ty patche byly začleněny tento měsíc, ale spousta funkcí se do jádra nedostala. Správa paměti není to správné místo pro programátory, kteří spěchají.
Má to svůj důvod. Ovladače zařízení buď fungují nebo nefungují, ale subsystém virtuální paměti se při každé zátěži chová trošku jinak. Ladění heuristik, které jsou základem správy paměti, je složitý proces; změna, která vylepší výkon u jedné zátěže, může zcela nepředvídatelně zlikvidovat výkon u jiné. A ta "jiná zátěž" se nemusí projevit třeba do chvíle, kdy se nějaká velká bankovní instituce pokusí nasadit novou verzi jádra. Vývojáři nejdůležitějších částí jádra už byli svědky mnoha podobných nepříjemností, takže jsou dost konzervativní, když se mluví o změnách správy paměti. Je těžké dostat do jádra významnou změnu bez přesvědčivých důkazů, že se stav zlepší (nebo alespoň nezhorší) ve všech situacích.
V nedávném rozhovoru Con řekl:
Pak přišlo přednatahování swapu. Strávil jsem hodně času spravováním a vylepšováním kódu. Do -mm to bylo začleněno před 18 měsíci a po celou dobu jsem kód podporoval. Andrew [Morton] si není do dneška jistý, jestli to něčemu pomůže, a jestli to 'možná' nemá na jiném místě negativní dopad. Během posledních 9 měsíců se neobjevila žádná stížnost na výkon nebo hlášení o chybě. Dokonce jsem napsal výkonnostní test, který ukázal, jak to funguje, a vyjádřil to i v číslech!
Potíž je v tom, že, jak ví každý vývojář, "žádné hlášení o chybě" není totéž co "žádné chyby". V takové situaci nejsou potřeba jen komentáře šťastných uživatelů, ale i určité povědomí o tom, že byl patch otestován v nejrůznějších situacích. Relativně úzký profil Conovy testovací komunity (více o tom za chvilku) to dost ztěžuje.
Patch jako přednatahování swapu vyžaduje podporu dalších vývojářů, kteří pracují na správě paměti, než může být začleněn. A tito vývojáři nebyli, jako celek, přednatahováním zrovna nadšeni. Několikrát se objevila námitka, že ten ranní swapovací problém by mohl být znakem většího problému v rámci subsystému virtuální paměti, a že přednatahování problém jen kamufluje. A dokonce ani nekamufluje úplně, protože sice přenáší zpět některé stránky ze swapu, ale neřeší (a ani nemůže) stránky se zálohou v souborech, které byly také vytlačeny. Závěr, ke kterému tato argumentace vede, je, že by bylo lepší objevit a opravit skutečný problém, spíše než ho schovávat za přednatahování.
Tuto otázku lze řešit lepším poznáním zátěží, které vykazují uváděné problémy, aby se dalo něco dělat s počáteční příčinou. Andrew Morton proto říká:
Do druhé otázky bychom se mohli pustit přes hlášení o chybách: systém A se zátěží B dojde k výsledku C. Myslím, že výsledek C je chybný <protože>, a raději bych viděl výsledek D.
A Nick Piggin si proto stěžuje:
Nemluvím o přednatahování samotném, ale kdykoliv jsem někoho požádal, aby zařídil nebo vytvořil zátěž, při které by přednatahování pomohlo, nikdy to neudělali.
Je prima, že přednatahování pomáhá jim, ale zároveň se chci podívat, proč to tak je, a pokusit se v některých těch situacích vylepšit vracení stránek (například standardní noční cron by na 1 nebo 2GB systému snad přednatahování potřebovat neměl).
Objevilo se několik pokusů o charakterizování zátěží, při kterých přednatahování swapu pomáhá, ale popisy jsou většinou obecné a těžko reprodukovatelné. Není snadné pro takovou situaci napsat jednoduchý výkonnostní test (i když se o to Con pokusil), takže demonstrování problému je dost obtížné. Přesto však budou muset proponenti přednatahování vymyslet způsob, jak problémy, které přednatahování řeší, vývojářské komunitě lépe popsat, pokud to se začleněním do hlavního jádra myslí vážně.
Komunikace s komunitou byla občas u Conových patchů problémová. Na rozdíl od téměř všech ostatních vývojářů se Con rozhodl provádět většinu vývoje v rámci své vlastní konference. To vyústilo v komunitu uživatelů, která Conovu práci téměř bezvýhradně podporuje, ale která se většinou vývoje nikterak neúčastní. V konferenci ck-list se patche, které nenapsal Con, objevují jen zřídka. Výsledkem bylo vytvoření skupiny fanoušků, která občas v linux-kernel požadovala začlenění Conových patchů. Tento způsob jednosměrné komunikace nikomu příliš nepomáhal. Nepřesvědčilo to vývojáře, kteří nebyli v ck-list, a nevedlo to ke zlepšení patchů.
Začalo to být přímo škodlivé, když členové ck-list (a Con) pokračovali v nátlaku na začlenění patchů i přesto, že se vyskytly skutečné problémy. Takové chování se projevilo, když Con představil plánovač RSDL. Začalo se díky tomu znovu diskutovat o plánovačích a vedlo to k dobré práci. Jenže když někteří uživatelé hlásili regrese při použití RSDL, bylo jim řečeno, že takové regrese se daly čekat a opravovat se nebudou. Takové chování otrávilo Linuse a připravilo půdu pro CFS od Ingo Molnara. Někteří (ne všichni) lidé jsou přesvědčeni, že Conův plánovač byl navržen lépe, ale odmítání řešit negativní reporty to celé pohřbilo. Některé Conovy nápady se do jádra dostaly, ale jeho kód ne.
U patchů s přednatahováním swapu se žádné zjevné chyby neprojevují; nikdo nehlásí, že by přednatahování zhoršilo výkon. Ale členové konference ck-list (často povzbuzováni Conem) neposkytují informace, které vývojáři jádra potřebují. Přestože nepřevládá názor, že by přednatahování mělo být začleněno, někteří významní vývojáři zařazení do jádra podporují. Patří k nim Ingo Molnar a David Miller, který říká:
Tohle je chvíle, kdy by možná bylo lepší o krok ustoupit a nechat řeku, ať si najde svoji cestu - uvidíme, co se stane. Z počátku je dobré hrát si na "co když", ale po několika měsících už to není produktivní a bezdůvodně to brzdí vývoj.
Pokud bude implementován lepší mechanismus, super! Můžeme v tu chvíli přednatahování swapu snadno vyměnit. Ale do té doby máme přednatahování - už to v -mm sedělo dost dlouho na to, aby bylo možné kód začlenit.
Takže přednatahování swapu se nakonec ještě možná do jádra dostane. A pokud budeme mít opravdu štěstí, tak se Con k vývoji jádra vrátí, protože tam je jeho talentu a zaměření na uživatele velmi potřeba. Začleňování zásadních změn není snadné a to je patrně dobře. Pokud vývojový proces pochybí, mělo by to být kvůli konzervativnosti, i když to občas vyústí v zavržení patchů, které by byly přínosem.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
A tito vývojáři nebyli, jako celek, přednatahováním zrovna nadšeni.Nejsou tam ty čárky navíc? (Já vím, že se opakuju, ale zdá se mi, že s nimi fakt plátváš
)
Vložená věta. Já bych to tam nechal.
6.8.2007 02:44
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
6.8.2007 16:00
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
AC zjevne neni suchar.