abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
    dnes 12:22 | Nová verze

    Multiplatformní emulátor terminálu Ghostty byl vydán ve verzi 1.2 (𝕏, Mastodon). Přehled novinek, vylepšení a nových efektů v poznámkách k vydání.

    Ladislav Hagara | Komentářů: 0
    dnes 00:11 | Nová verze

    Byla vydána nová verze 4.5 (𝕏, Bluesky, Mastodon) multiplatformního open source herního enginu Godot (Wikipedie, GitHub). Přehled novinek i s náhledy v příspěvku na blogu.

    Ladislav Hagara | Komentářů: 0
    včera 21:33 | Nová verze

    Byla vydána verze 3.0 (Mastodon) nástroje pro záznam a sdílení terminálových sezení asciinema (GitHub). S novou verzí formátu záznamu asciicast v3, podporou live streamingu a především kompletním přepisem z Pythonu do Rustu.

    Ladislav Hagara | Komentářů: 0
    včera 21:00 | Komunita

    Canonical oznámil, že bude podporovat a distribuovat toolkit NVIDIA CUDA (Wikipedie) v Ubuntu.

    Ladislav Hagara | Komentářů: 0
    včera 20:44 | IT novinky

    Tržní hodnota americké společnosti Alphabet, která je majitelem internetového vyhledávače Google, dnes poprvé překonala hranici tří bilionů dolarů (62,1 bilionu Kč). Alphabet se připojil k malé skupině společností, které tuto hranici pokořily. Jsou mezi nimi zatím americké firmy Nvidia, Microsoft a Apple.

    Ladislav Hagara | Komentářů: 2
    včera 20:33 | IT novinky

    Spojené státy a Čína dosáhly dohody ohledně pokračování populární čínské platformy pro sdílení krátkých videí TikTok v USA. V příspěvku na síti Truth Social to dnes naznačil americký prezident Donald Trump. Dosažení rámcové dohody o TikToku vzápětí oznámil americký ministr financí Scott Bessent, který v Madridu jedná s čínskými představiteli o vzájemných obchodních vztazích mezi USA a Čínou. Bessentova slova později potvrdila také čínská strana.

    Ladislav Hagara | Komentářů: 0
    včera 16:55 | Komunita

    MKVToolNix, tj. sada nástrojů pro práci s formátem (medialnym kontajnerom) Matroska, byl vydán ve verzi 95.0. Podpora přehrávání formátu Matroska míří do Firefoxu [Bug 1422891, Technický popis]. Přehrávání lze již testovat ve Firefoxu Nightly.

    Ladislav Hagara | Komentářů: 0
    13.9. 17:33 | Pozvánky

    Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 211. sraz, který proběhne v pátek 19. září od 18:00 ve Studentském klubu U Kachničky na Fakultě informačních technologií Vysokého učení technického na adrese Božetěchova 2/1. Na srazu proběhne přednáška Jiřího Eischmanna o nové verzi prostředí GNOME 49. Nemáte-li možnost se zúčastnit osobně, přednáškový blok bude opět streamován živě na server VHSky.cz a následně i zpřístupněn záznam.

    Ladislav Hagara | Komentářů: 0
    13.9. 01:33 | IT novinky

    Microsoft se vyhnul pokutě od Evropské komise za zneužívání svého dominantního postavení na trhu v souvislosti s aplikací Teams. S komisí se dohodl na závazcích, které slíbil splnit. Unijní exekutivě se nelíbilo, že firma svazuje svůj nástroj pro chatování a videohovory Teams se sadou kancelářských programů Office. Microsoft nyní slíbil jasné oddělení aplikace od kancelářských nástrojů, jako jsou Word, Excel a Outlook. Na Microsoft si

    … více »
    Ladislav Hagara | Komentářů: 10
    12.9. 14:00 | Nová verze

    Samba (Wikipedie), svobodná implementace SMB a Active Directory, byla vydána ve verzi 4.23.0. Počínaje verzí Samba 4.23 jsou unixová rozšíření SMB3 ve výchozím nastavení povolena. Přidána byla podpora SMB3 přes QUIC. Nová utilita smb_prometheus_endpoint exportuje metriky ve formátu Prometheus.

    Ladislav Hagara | Komentářů: 0
    Pro otevření více webových stránek ve webovém prohlížečí používám
     (81%)
     (7%)
     (3%)
     (3%)
     (4%)
     (2%)
    Celkem 183 hlasů
     Komentářů: 12, poslední 10.9. 13:00
    Rozcestník

    Jaderné noviny – 14. 7. 2011: Jak vyřešit nepořádek v logu jádra

    26. 7. 2011 | Jirka Bourek | Jaderné noviny | 3362×

    Aktuální verze jádra: 3.0-rc7. Citáty týdne: Andrew Morton, Linus Torvalds. Jak se to jádro bude jmenovat?. Problémy se strukturovanými logy.

    Obsah

    Aktuální verze jádra: 3.0-rc7

    link

    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ě.

    Citáty týdne: Andrew Morton, Linus Torvalds

    link

    Changelog nám zapomněl sdělit, jaké jsou dopady této chyby viditelné pro uživatele. To od něj bylo opravdu špatné. Ošklivý changelog. Nedostaneš kostičku.

    -- Andrew Morton

    Právníci: vypadají jako rozumní a chytří lidé, když na ně koukáte jako na jednotlivce. A stejně se pokusí dohadovat se, jestli si pamatujete specifické datum příspěvku do newsgroup, který jste napsali. Co na tom, že ten příspěvek u sebe má jasně napsané datum a je odpovědí na jiné příspěvky (a je na něj odpovídáno jinými příspěvky), které také mají datum.

    -- Linus Torvalds

    Jak se to jádro bude jmenovat?

    link

    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í:

    Máme před sebou obvyklých 6-7 týdnů zápasu, než ho vydáme a než se skripty pročistí, takže finální verze by měla být jenom „3.0“. Tým pro stabilní jádra může třetí číslo použít pro své verze.

    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.

    Problémy se strukturovanými logy

    link

    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:

    Celý přístup jádra k zasílání zpráv je poměrně nahodilý a neschopný a smutný. Objevilo se několik návrhů, jak ho zlepšit a racionálně rozdělit věci do kategorií tak, aby to bylo pro obsluhu užitečnější, ale zdá se, že se nikdy nic nedostane do hlavní řady.

    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().

           

    Hodnocení: 100 %

            špatnédobré        

    Nástroje: Tisk bez diskuse

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    26.7.2011 07:14 petr_p | skóre: 59 | blog: pb
    Rozbalit Rozbalit vše dmesg
    26.7.2011 23:11 vlastagf | skóre: 11
    Rozbalit Rozbalit vše Re: dmesg
    Ted nechci flamovat, ale obcas se uprimne divim, ze ten moloch porad funguje. Popravde doufam, ze brzy prijde neco lepsiho nez linux.
    Bedňa avatar 27.7.2011 09:05 Bedňa | skóre: 34 | blog: Žumpa | Horňany
    Rozbalit Rozbalit vše Re: dmesg
    Málo čítaš diskusie jadrákov, sú na svoju prácu a svojich kolegov kritické až negatívne odjakživa. Keby týto ľudia vyrábali Ferrari a prečítal si čo o ňom píšu tvorcovia, tak by si ho vživote nekúpil :)
    KERNEL ULTRAS video channel >>>
    13.12.2021 06:52 geebranz
    Rozbalit Rozbalit vše Re: Jaderné noviny – 14. 7. 2011: Jak vyřešit nepořádek v logu jádra
    Flexible ways

    Rely

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.