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).
Současné vývojové jádro je 3.0-rc7 vydané 11. července. Myslím, že jsem říkal, že -rc6 by mohlo být poslední. Lhal jsem. Věci byly poměrně klidné, ale je tu dost nových záležitostí, takže jsem chtěl vydat další -rc; stále také máme nějaké problémy se změnami RCU, které působí potíže, když k RCU událostem dojde před kompletní inicializací plánovače. Takže -rc7 je venku. Všechny detaily vizte v kompletním changelogu.
Stabilní aktualizace: stabilní aktualizace 2.6.32.43 a 2.6.33.16 vyšly 13. července; 8. července vyšlo 2.6.39.3. Všechna jádra obsahují obvyklý seznam oprav – v případě 2.6.39.3 je jich poměrně hodně.
Když Linus na konci května oznámil jádro 3.0-rc1, stále se identifikovalo jako „3.0.0“. Očekávalo se, že mnoho skriptů předpokládá, že třetí číslo existuje a Linus je nechtěl rozbít hned zezačátku. I tak ale doufal, že poslední „.0“ zmizí:
Rychle vpřed k 3.0-rc7 a jádro se pořád identifikuje jako 3.0.0. I když jednoznačné informace chybí, zdá se, že je stále mnoho programů a skriptů, které bez posledního čísla přestanou fungovat. V jistém smyslu se schéma s třemi čísly ve verzi stalo během let součástí jaderného ABI. Dalo by se dohadovat, že všechno, co přestane fungovat, bylo napsáno hloupě, ale i tak je cílem vyhnout se rozbíjení programů v uživatelském prostoru. Takže i když není žádná jednoznačná odpověď, zdá se, že vydání z hlavní řady budou ještě nějakou dobu mít tři čísla. Bylo by nicméně velice překvapivé, kdyby první stabilní aktualizace měla jiné číslo než 3.0.1.
Je zde nicméně další otázka: co s programy, které se nedokáží vyrovnat s jiným číslem verze než „2.6.x“? Takové zjevně existují. Prohlásit, že verze jádra budou navždy začínat „2.6“ jde za hranice i té největší snahy dodržet binární kompatibilitu; na něco takového nedojde. Aby zjednodušil život lidem, kteří takové programy mají, implementoval Andi Kleen nový režim [personality], který předstírá, že ke změně na 3.0 nikdy nedošlo. Pokud je program spuštěn v tomto režimu, bude si myslet, že verze jádra je 2.6.40; 3.1 bude vypadat jako 2.6.41 atd.
Andi říká: Vím, že je to poněkud ošklivé, ale lepší workaround jsem nevymyslel a kompatibilita pro existující programy je důležitá. V době psaní tohoto článku se daný patch nicméně ještě nedostal do hlavní řady.
napsal Jonathan Corbet, 12. července 2011
Debata o konceptu jmen disků přívětivých pro uživatele byla tento týden znovu rozdmýchána, když Nao Nishijima zaslal novou verzi patche pro trvalá jména zařízení. Neshody o této vlastnosti trvají; je ale možné bude začleněna i tak. Jádrem diskuze nicméně byl koncept, který jde ještě dál za přidání uživatelem specifikovaných jmen ke specifickým zařízením; je to větší problém, jak dostat z jádra strukturovaná data.
Po všech těch letech je hlavním mechanismem, jak jádro předává informace do uživatelského prostoru, primitivní funkce printk(). Není třeba říkat, že je to užitečná a flexibilní cesta, jak dostat zprávy mimo jádro, ale neklade žádné požadavky na strukturu těchto zpráv. To vše vede k různým výstupům jako (z drivers/net/de620.c):
printk(KERN_WARNING „%s: Thanks, I feel much better now!\n“, dev->name);
nebo slavné zprávy z drivers/char/lp.c:
printk(KERN_INFO „lp%d on fire\n“, minor);
Nelze vinit správce systémů z toho, že nemají tušení, jak na takové zprávy mají reagovat.
Došlo ke změnám, které měly vynutit nějakou strukturu výstupu printk(), počínaje přidáním značky identifikující závažnost každé zprávy. I tak ale není těžké najít volání printk() bez identifikace závažnosti; skutečné vynucení jejich používání se ukázalo jako příliš těžké. Nějakou strukturu přidává dev_printk() (a varianty jako dev_err()), ale používání těchto funkcí rozhodně není všeobecné.
Chybějící struktura znamená, že zprávy nejsou příliš konzistentní; každé dva síťové ovladače téměř určitě vypíšou jinou věc popisující stejnou situaci. Jaderné zprávy se také mohou postupem času změnit; zprávy vypisované pomocí printk() se normálně nepovažují za součást jaderného ABI i přes fakt, že jejich změny mohou rozbít skripty, které se ze systémových logů pokouší vytáhnout užitečné informace. Není překvapivé, že téměř před rokem Andrew Morton řekl:
Různí lidé se situaci na některých místech pokoušeli vylepšit; uživatelsky přívětivá jména disků, která se snaží zařízením přiřadit konzistentní jména, jsou jeden takový pokus. Patch netoops od Google je další; pomáhá Googlu zjistit, které stroje padají bez toho, aby jejich správci museli přehrabovat logy. Tyto změny ale mají daleko k obecnému frameworku pro strukturovaná data od jádra.
Během let došlo k několika pokusům takový framework vytvořit; ani jednomu se nepodařilo do jádra dostat. Není těžké přijít na věrohodné zdůvodnění tohoto selhání. Množství práce, kterou to vyžaduje, je obrovské, obzvláště pokud někdo chce dodat strukturu do větší části zajímavých sdělení od jádra. Vývojáři mají printk() rádi; těžko je okouzlí jiné rozhraní, které k použití vyžaduje práci navíc, jeho výstup je (z principu) méně flexibilní a navíc může existovat společně se stávajícím logováním pomocí printk(). Vymyslet strukturovaný formát, který splní požadavky všech – a který nebude v následujících letech nutné doplnit formátem „verze 2“ – je výzvou samo o sobě.
Také je potřeba říci, že jaderní vývojáři jako celek vidí jenom malou hodnotu ve strukturovaných logovacích informacích. Nepomůže jim to ladit jejich jádra. Fakt, že mnoho uživatelů by takovou vlastnost chtělo, není pro vývojovou komunitu nerelevantní, ale zkušenosti ukazují, že o co vývojáři nemají zájem, je mnohem těžší začlenit – obzvláště když taková změna bude mít široký záběr a bude rušivá.
Pokud tento problém má někdy být vyřešen, zdá se, že je potřeba najít dvě věci: mechanismus, který bude vypadat, že by mohl fungovat, a motivaci pro jaderné vývojáře ho přijmout. Motivaci lze pravděpodobně najít v kombinaci (1) jejich výplatní pásky, protože zákazníci tuto vlastnost stále vyžadují, a (2) vyhlídky na neustávající proud ad hoc patchů, které budou přidávat strukturu do různých koutů jádra bez řešení skutečného problému. To ale stále ponechává otevřený problém, jak najít fungující řešení.
Autor tohoto článku nad touto záležitostí trochu přemýšlel a uvědomil si, že jádro již má hezký mechanismus, jak do uživatelského prostoru předávat strukturovaná data. Téměř na každém současném systému je adresář /dev spravován démonem udev; udev funguje tak, že od jádra přijímá vysoce strukturované zprávy, které popisují příchody a odchody zařízení, změny jejich konfigurace, požadavky na nahrání firmwaru a další. Je to zavedený protokol, který umožňuje sofistikované reakce na události v jádře. Udev a s ním spojený mechanismus „uevent“ si prošel porodními bolestmi, ale kód je nyní stabilní, funkční a používá se téměř univerzálně. Je možná načase, aby převzal další povinnosti.
Uevent rozhraní funguje, protože formát zpráv je jak strukturovaný, tak flexibilní; lze ho rozšířit, když je to potřeba. Generování událostí je téměř zcela zajišťováno automaticky v centrálním kódu pro ovladače; většina autorů ovladačů nemusí udělat vůbec nic, aby se události vygenerovaly a dokonce ani nemusí vědět, že pod kapotou tento mechanismus pracuje. Autoři ovladačů nemusí vytvářet své události; a museli by se hodně snažit, kdyby chtěli v jejich generování zabránit.
Logování jiných typů událostí bude pravděpodobně vyžadovat explicitní podporu v relevantním jaderném kódu; tato část vyžaduje zamyšlení. Vytvořit uevent ručně je poměrně náročná činnost; relevantní kód vypadá nějak takto:
retval = add_uevent_var(env, „ACTION=%s“, action_string); if (retval) goto exit; retval = add_uevent_var(env, „DEVPATH=%s“, devpath); if (retval) goto exit; retval = add_uevent_var(env, „SUBSYSTEM=%s“, subsystem); if (retval) goto exit;
Je zjevné, že jakýkoliv pokus vložit takový kód na každé místo, odkud se něco loguje, nedojde nijak daleko. Co je potřeba, je rozumná sada pomocných funkcí. Tyto funkce, aby byly co nejužitečnější, by pravděpodobně byly poměrně těsně spojeny se subsystémy pod sebou. Ovladače pro úložná zařízení by měly funkce pro hlášení chybných bloků, změn zařízení, změn vícecestné konektivity. Síťové ovladače by potřebovaly hlásit události jako ztrátu nosné, nadměrný počet chyb při počítání kontrolních součtů či duplicitní MAC adresy. Veškerý jaderný kód by mohl benefitovat z pomocných funkcí logujících selhání alokace nebo nesplnění nějakých předpokladů [failed assertions]. V každém případě by pomocná funkce standardizovala formát hlášené informace a zároveň umožnila přidat dodatečné informace specifické pro místo, odkud se volá.
Přidání nové sady logujících funkcí by nutně vyžadovalo změny ovladačů tak, aby se dané funkce začaly používat. Zabralo by tedy čas dosáhnout něčeho, co by se alespoň trochu blížilo všeobecnému pokrytí, a ke 100% pokrytí by nedošlo nikdy. Na druhou stranu nemáme ani 100% pokrytí značkami KERN_* označujícími závažnost hlášení. Pokud toto rozhraní bude užitečné, lze si představit, že kódové cesty, které zajímají zákazníky podnikových distribucí, budou pokryty relativně rychle.
Na druhou stranu tento nápad má pravděpodobně několik aspektů, které jsou naprosto chybné; problém se strukturovaným logováním zůstane pravděpodobně nevyřešen ještě nějakou dobu. Avšak nezmizí; naopak, potřeba rozpoznat a automaticky reagovat na události systému jenom vzroste. Jednoho dne někdo přijde s řešením, které bude fungovat a které bude možné přijmout s minimálními potížemi; do té doby máme jenom printk().
Nástroje: Tisk bez diskuse
Tiskni
Sdílej: