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í
×
18.8. 22:22 | Nová verze

Po roce vývoje od vydání verze 1.20 byla vydána verze 1.21 knihoven EFL (Enlightenment Foundation Libraries). Do vývoje EFL se zapojilo 96 vývojářů. Provedeno bylo téměř 5 000 commitů.

Ladislav Hagara | Komentářů: 0
16.8. 19:00 | Nová verze

Byla vydána verze 18.08.0 KDE Aplikací (KDE Applications). Přehled novinek v kompletním seznamu změn a na stránce s dalšími informacemi.

Ladislav Hagara | Komentářů: 0
16.8. 18:44 | Pozvánky

Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 155. brněnský sraz, který proběhne v pátek 17. srpna od 18:00 na zahrádce restaurace Tanganika (Horova 35). V případě nepřízně počasí uvnitř. Tentokrát bude sraz pojat tématicky. Vzhledem k blížícímu se 50. výročí invaze vojsk Varšavské smlouvy do Československa proběhne malá výstava. Kromě literatury budou k vidění též originály novin z 21. srpna 1968, dosud nikde nezveřejněné fotky okupovaného Brna a původní letáky rozdávané v ulicích.

Ladislav Hagara | Komentářů: 0
16.8. 01:00 | Komunita

Měsíc po Slackware slaví 25 let také Debian. Přesně před pětadvaceti lety, 16. srpna 1993, oznámil Ian Murdock vydání "Debian Linux Release".

Ladislav Hagara | Komentářů: 10
15.8. 06:00 | Nová verze

Byla vydána nová verze 1.26 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Představení novinek také na YouTube.

Ladislav Hagara | Komentářů: 28
15.8. 03:00 | Nová verze

Po více než 3 měsících vývoje od vydání verze 2.12.0 byla vydána nová verze 3.0.0 otevřeného emulátoru procesorů a virtualizačního nástroje QEMU (Wikipedie). Přispělo 169 vývojářů. Provedeno bylo více než 2 300 commitů. Přehled úprav a nových vlastností v seznamu změn. Proč verze 3.0.0 a ne 2.13.0? Není to kvůli triskaidekafobii. QEMU letos v březnu slavilo 15 let od oznámení verze 0.1 a to je dle vývojářů dobrý důvod pro novou major verzi. Vývojáři mají v plánu zvyšovat major verzi jednou ročně, vždy s prvním vydáním v daném roce.

Ladislav Hagara | Komentářů: 3
14.8. 22:11 | Bezpečnostní upozornění

Intel potvrdil (INTEL-SA-00161) další bezpečnostní problém ve svých procesorech. Problém byl pojmenován L1 Terminal Fault aneb L1TF. Popis problému přímo od Intelu na YouTube. Jedná se o CVE-2018-3615 (SGX), CVE-2018-3620 (OS/SMM) a CVE-2018-3646 (VMM). Další informace na stránce Foreshadow nebo přímo v dnešním commitu do Linuxu.

Ladislav Hagara | Komentářů: 19
14.8. 12:33 | IT novinky

Po více než 4 letech bylo vydáno RFC 8446 popisující verzi 1.3 protokolu TLS (Transport Layer Security). Popis novinek i historie TLS například v příspěvku na blogu Cloudflare.

Ladislav Hagara | Komentářů: 0
14.8. 11:11 | Zajímavý software

V roce 1998 uvedla společnost Tiger Electronics na trh elektronickou hračku, malého chlupatého tvora s velkýma ušima, Furby. Furby patřil k nejžádanějším hračkám. Během tří let se jich prodalo více než 40 milionů. Furby již tenkrát reagoval na světlo, zvuk, polohu, doteky a přítomnost dalších Furby. Sám mluvil a pohyboval se. Firmware uvnitř simuloval postupný vývoj a učení. Zdrojový kód tohoto firmwaru byl zveřejněn na Internet Archive [Hacker News].

Ladislav Hagara | Komentářů: 21
14.8. 02:00 | Nová verze

Australská společnost Blackmagic Design oznámila vydání verze 15 svého proprietárního softwaru pro editování videa a korekci barev DaVinci Resolve běžícího také na Linuxu. Představení nových vlastností na YouTube. Základní verze DaVinci Resolve je k dispozici zdarma. Plnou verzi DaVinci Resolve Studio lze koupit za 299 dolarů. Před rokem to bylo 995 dolarů.

Ladislav Hagara | Komentářů: 0
Používáte zařízení („chromebook“, „chromebox“ či tablet) s ChromeOS?
 (7%)
 (3%)
 (15%)
 (76%)
Celkem 213 hlasů
 Komentářů: 10, poslední 18.8. 11:25
    Rozcestník

    Jaderné noviny – 6. 6. 2013: Vlastní OOM killer

    24. 6. 2013 | Luboš Doležel | Jaderné noviny | 3639×

    Aktuální verze jádra: 3.10-rc4. Citáty týdne: Arnd Bergmann, Luc Verhaegen. Na cestě ke spolehlivému rešení OOM v užvatelském prostoru.

    Obsah

    Aktuální verze jádra: 3.10-rc4

    link

    Aktuální vývojová verze jádra je 3.10-rc4 vydaná 2. června. rc4 je nicméně menší než rc3 (bomba!). Ale i tak by mohlo být ještě menší (fuuuj!). Je tam obvyklá hromada oprav v ovladačích (drm, pinctrl, scsi target, fbdev, xen), ale i v systémech souborů (cifs, xfs, drobné opravy v reiserfs a nfs)

    Stabilní aktualizace: verze 3.2.46 vyšla 31. května.

    Citáty týdne: Arnd Bergmann, Luc Verhaegen

    link

    Náš proces revidování kódu jednoznačně není dokonalý, jestliže musíme čekat, než se věci v linux-next porouchají, aby si lidé konečně všimli problémů.

    -- Arnd Bergmann

    Nedávno jsem se ze spolehlivého zdroje dozvěděl, že se managementu v ARM opravdu hodně nelíbí projekt ovladače Lima. Slušně se to dá říct tak, že nevidí na open source ovladači pro Mali žádné výhody a myslí si, že ovladač Lima už teď odhaluje příliš mnoho z vnitřností hardwaru Mali. Navíc je jejich postoj takový, že kdyby opravdu chtěli open source ovladač, tak by prostě jen zveřejnili svůj vlastní kód a bylo by.

    Opravdu?

    -- Luc Verhaegen

    Na cestě ke spolehlivému rešení OOM v užvatelském prostoru

    link

    Návštěva od jaderného zabijáka při nedostatku paměti (OOM killer) je asi tak vítaná jako nečekná návštěva z berňáku. OOM killer je zavolán, jakmile systému dochází paměť a nemůže pokračovat dál bez zabití někerých procesů; jde o sadu často se měnících heuristik, které popisují, jaké procesy se mají zabít s co největším dopadem na uvolnění paměti a co nejmenším dopadem na systém jako celek. Člověk by řekl, že něco takového nelze dělat v uživatelském prostoru, ale jsou i uživatelé, kteří se snaží dosáhnout právě tohoto a dokonce se jim to i daří. Tak či tak není řešení OOM v uživatelském prostoru tak bezpečné, jako by někteří chtěli, ale není ani moc shoda na tom, jak to zlepšit.

    Řešení OOM v uživatelském prostoru

    link

    Řešení OOM v uživatelském prostoru nejčastěji používá asi Google. Kvůli snaze vytlačit z hardwaru co nejvíce je u nich obvyklé toho na servery co nejvíce namačkat. Paměťové řídící skupiny (memcg) se tam používají k tomu, aby si uživatelé nepřekáželi. Stejně jako systém jako celek se i memcg může dostat do situace OOM (nedostatku paměti) a jádro reaguje stejným způsobem: probudí se OOM killer a začne zabíjet procesy v dané skupině. Ale protože situace OOM v řídící skupině neohrožuje stabilitu systému jako celku, tak má jádro v řešení této situace volnější ruku. OOM killer na úrovni řídící skupiny je možné úplně zakázat a navíc je to mechanismus, jak si proces může zažádat o notifikace pro případ, kdy ve skupině dojde paměť.

    Zmiňovaný notifikační mechanismus je navržen podle potřeb globálního, pravděpodobně privilegovaného procesu, který spravuje několik skupin v systému; proces může reagovat zvýšením paměťového stropu, přesunem mezi skupinami nebo selektivím zabitím procesů. Ale v případě Googlu to funguje trochu jinak: každý interní uživatel u Google má možnost (a zodpovědnost) řešit situace OOM v rámci své skupiny. Tento přístup může fungovat, ale jsou tu nástrahy, kvůli kterým je to méně spolehlivé, než by někdo mohl doufat.

    Jedním z důvodů je to, že jelikož si uživatelé řeší OOM sami, pak i OOM handler je omezen stejným paměťovým stropem. Takže pokud obsluha OOM bude potřebovat paměť navíc, bude blokována a jako ostatní procesy bude čekat na vyřešení situace; to je v podstatě deadlock celé skupiny. Dá se tomu vyhnout uzamčením stránek a tak podobně, ale i tak je docela obtížné napsat program, kde je záruka, že nedojde k alokacím paměti v jádře. K deadlocku může vést třeba i přečtení souboru v /proc (vyvolající alokaci paměti).

    Dalším problémem je to, že proces, jehož alokace vyvolala situaci OOM, může být zrovna hluboko v jádře a držet určité množství zámků. Semafor mmap_sem se zdá být obzvláště problematický, protože je často zamknutý v situacích, kdy je paměť alokována – např. při obsluze výpadků stránek. Pokud obsluha OOM potřebuje udělat něco, co by mohlo potřebovat ty samé zámky, tak se bude čekat na nesprávný proces a opět dojde k deadlocku.

    Výsledkem je tedy to, že OOM killing v uživatelském prostoru není 100% spolehlivý a snad ani nikdy nebude. Co se týče Google, pak lehce nespolehlivé očetřování OOM je přijatelné, ale deadlocky nikoliv. Proto v roce 2011 David Rientjes zaslal patch zavádějící nastavitelnou prodlevu OOM killeru. Při jejím nastavení má obsluha OOM v uživatelském prostoru určitý čas na vyřešení situace, jinak nastoupí jádro.

    Davidův patch nebyl tehdy začleněn; ostatní z něj měli pocit, že je to jen obezlička pro chyby v uživatelském prostoru, které by bylo lepší opravit u zdroje. Tehdy David řekl, že Google bude patch v případě potřeby udržovat interně, ale domníval se, že v případě rozšíření memcg by i ostatní měli zájem o stejnou funkčnost. Teď se po dvou letech snaží znovu, ale reakce nejsou o moc jiné.

    Alternativa k prodlevám

    link

    Někteří vývojáři reagovali, že mít obsluhu OOM uvnitř skupiny, kterou má řídit, je případem typu „tak takhle tedy ne“, ale jakmile David vysvětlil, že si uživatelé dělají vlastní obsluhu OOM, tak trochu ustoupili. I tak se ale drží názor, že by obsluha OOM měla být uzamčena v paměti a měla by se vyvarovat alokaci paměti. Zejména je pak pozdě číst soubory v /proc za účelem zjištění, co za procesy v systému běží, když paměť už došla. Alternativou je ale sledovat vytváření procesů v každé memcg, což s sebou nese vlastní (výkonnostní) problémy.

    Johannes Weiner přišel s konstruktivními nápady, jak stávající situaci zlepšit. Jedním z nich byl patch, jenž měl vyřešit problém procesů čekajících na vyřešení OOM a držících zámky. Tento patch dělá dvě úpravy, první z nich se týká situací, kdy je alokace paměti přímým následkem systémového volání. V tomto případě alokující proces nebude vůbec umístěn do čekací fronty OOM; místo toho volání selže s chybou ENOMEM. To řeší většinu problému, ale část zůstává: systémová volání, která předtím fungovala, mohou najednou vracet neočekávaný chybový kód. To může vést k podivnému chování a jelikož je nedostatek paměti málo častý, pak by takové chování bylo obtížné odhalit při testování.

    Druhá část patche mění cestu pro výpadek stránky. V tomto případě není možné skončit s chybou ENOMEM; to by vedlo ke smrti procesu s výpadkem. Kód je změněn tak, aby si tuto skutečnost zaznamenal a vrátil se; jakmile je call stack odrolován a všechny zámky jsou uvolněné, pak bude proces čekat na vyřešení problému OOM. S těmito změnami by většina (nebo veškeré) problémy s deadlocky měly snad zmizet.

    To ale neřeší jiný problém: pokud se obsluha OOM pokusí sama alokovat paměť, dostane se do fronty čekajících procesů a opět dojde k deadlocku. Johannes navrhl, že obsluha OOM v uživatelském prostoru by mohla formálně sdělit svou roli jádru. Pak, jakmile by proces narazil na problém OOM, by jádro mohlo ověřit, jestli to je proces pro obsluhu; pokud ano, situace by byla předána k řešení jadernému OOM killeru. Výsledek by byl stejný jako s prodlevou, jen by k tomu došlo hned, bez čekání.

    Michal Hocko má Johannesovy změny raději, ale měl dodatečný návrh: implementovat globální watchdog proces. Tento proces by obdržel upozornění na situace OOM současně jako obsluha uživatele; spustil by časovač a čekal by na vyřešení situace. Pokud by čas vypršel, pak by watchdog zabil uživatelovu obsluhu a povolil jaderné řešení OOM v dotčené memcg. Jeho názor je ten, že problém je možné řešit v uživatelském prostoru, a proto by i tam měl být vyřešen.

    Při zvolení kombinace těchto úprav je možné, že deadlocky obsluhy OOM v uživatelském prostoru budou vyřešeny. V takovém případě už snad nebude mechanismus s prodlevou od Googlu potřeba. Ani to ale zajisté nebude konec debat o obsluze OOM; tato debata je asi nekonečná.

           

    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ář

    24.6.2013 09:10 Honz
    Rozbalit Rozbalit vše Re: Jaderné noviny – 6. 6. 2013: Vlastní OOM killer
    Takže oni chtějí bránit vytvoření svobodného ovladače, místo aby do toho přispěli...?
    Petr Tomášek avatar 24.6.2013 11:40 Petr Tomášek | skóre: 37 | blog: Vejšplechty
    Rozbalit Rozbalit vše Re: Jaderné noviny – 6. 6. 2013: Vlastní OOM killer
    No a co byste čekal od takovéto korporace?
    multicult.fm | monokultura je zlo | welcome refugees!
    Bedňa avatar 24.6.2013 23:20 Bedňa | skóre: 34 | blog: Žumpa | Horňany
    Rozbalit Rozbalit vše Re: Jaderné noviny – 6. 6. 2013: Vlastní OOM killer
    Práve projektu Lima fandím a toto beriem ako úplnú arogonciu od ARMákov. Teda možno ich naštvala nedávna iniciatíva Lima & Co voči ARM aby pomohli s vydávaním slobodných ovládačov.
    KERNEL ULTRAS video channel >>>
    Bedňa avatar 24.6.2013 23:23 Bedňa | skóre: 34 | blog: Žumpa | Horňany
    Rozbalit Rozbalit vše Re: Jaderné noviny – 6. 6. 2013: Vlastní OOM killer
    Dík za patche do Reisera, teda ext4 už chodí dosť slušne pred týždňom som ale robil inštaláciu na starší komp a tam na Reisera, ešte stále nič nemá, ext sa proste vleče.
    KERNEL ULTRAS video channel >>>

    Založit nové vláknoNahoru

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