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 06:00 | Zajímavý software

Byla vydána verze 0.56 open source platformy Home Assistant (GitHub) pro monitorování a řízení inteligentní domácnosti naprogramované v programovacím jazyce Python verze 3 a bežící také například na Raspberry Pi. Pro vyzkoušení je k dispozici demo [reddit].

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

Byla vydána verze 1.0 klienta F-Droid určeného pro instalaci aplikací do Androidu ze softwarového repozitáře F-Droid (Wikipedie), alternativy k Google Play, nabízející pouze svobodný a otevřený software. Podrobnosti v přehledu změn [Hacker News].

Ladislav Hagara | Komentářů: 5
včera 00:55 | Nová verze

Po téměř 13 měsících vývoje od verze 0.11.0 byla vydána verze 0.12.0 hardwarově nenáročného desktopového prostředí LXQt (Lightweight Qt Desktop Environment, Wikipedie) vzniklého sloučením projektů Razor-qt a LXDE. Přehled novinek v příspěvku na blogu.

Ladislav Hagara | Komentářů: 9
21.10. 12:33 | Zajímavý software

Článek ne Medium představuje nejnovější stabilní verzi 2.0 svobodné decentralizované mikroblogovací platformy a sociální sítě podobné Twitteru Mastodon (Wikipedie). Detailní přehled novinek na GitHubu [Hacker News].

Ladislav Hagara | Komentářů: 0
21.10. 06:00 | Komunita

V Praze na půdě Elektrotechnické fakulty ČVUT dnes probíhá RT-Summit 2017 – setkání vývojářů linuxového jádra a uživatelů jeho real-time verze označované jako preempt-rt. Přednášky lze sledovat online na YouTube.

Ladislav Hagara | Komentářů: 0
20.10. 14:33 | Zajímavý projekt

Blender Animation Studio zveřejnilo první epizodu z připravovaného animovaného seriálu The Daily Dweebs o domácím mazlíčkovi jménem Dixey. Ke zhlédnutí také ve 3D s rozlišením 8K.

Ladislav Hagara | Komentářů: 0
20.10. 12:34 | Komunita

Aktualizovanou počítačovou hru Warhammer 40,000: Dawn of War III v ceně 39,99 eur běžící také na Linuxu lze o víkendu na Steamu hrát zdarma a případně ještě v pondělí koupit s 50% slevou. Do soboty 19:00 lze na Humble Bundle získat zdarma Steam klíč k počítačové hře Sid Meier's Civilization® III v ceně 4,99 eur běžící také ve Wine.

Ladislav Hagara | Komentářů: 0
20.10. 00:22 | Nasazení Linuxu

Společnost Samsung oznámila, že skrze dokovací stanici DeX a aplikaci Linux on Galaxy bude možno na Samsung Galaxy S8 a S8+ a Galaxy Note 8 provozovat Linux. Distribuce nebyly blíže upřesněny.

Phantom Alien | Komentářů: 19
19.10. 23:55 | Komunita

Společnost Purism na svém blogu oznámila, že její notebooky Librem jsou nově dodávány se zrušeným (neutralized and disabled) Intel Management Engine (ME). Aktualizací corebootu na již prodaných noteboocích lze Management Engine také zrušit. Více v podrobném článku.

Ladislav Hagara | Komentářů: 2
19.10. 21:44 | Nová verze

Organizace Apache Software Foundation (ASF) na svém blogu slaví páté výročí kancelářského balíku Apache OpenOffice jako jejího Top-Level projektu. Při této příležitosti byl vydán Apache OpenOffice 4.1.4 (AOO 4.1.4). Podrobnosti v poznámkách k vydání. Dlouhé čekání na novou verzi tak skončilo.

Ladislav Hagara | Komentářů: 8
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (10%)
 (0%)
 (0%)
 (1%)
 (76%)
 (13%)
Celkem 210 hlasů
 Komentářů: 8, poslední včera 23:02
    Rozcestník

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

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

    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: 33 | 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 :)
    Pokecajte si s umelou stupiditou na http://www.kernelultras.org/
    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.