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:33 | Zajímavý projekt

    Kevin Lin zkouší využívat chytré brýle Mentra při hraní na piano. Vytváří aplikaci AugmentedChords, pomocí které si do brýlí posílá notový zápis (YouTube). Uvnitř brýlí běží AugmentOS (GitHub), tj. open source operační systém pro chytré brýle.

    Ladislav Hagara | Komentářů: 0
    dnes 12:11 | Pozvánky

    Jarní konference EurOpen.cz 2025 proběhne 26. až 28. května v Brandýse nad Labem. Věnována je programovacím jazykům, vývoji softwaru a programovacím technikám.

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

    Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.

    Ladislav Hagara | Komentářů: 0
    včera 14:22 | IT novinky

    Před 25 lety zaplavil celý svět virus ILOVEYOU. Virus se šířil e-mailem, jenž nesl přílohu s názvem I Love You. Příjemci, zvědavému, kdo se do něj zamiloval, pak program spuštěný otevřením přílohy načetl z adresáře e-mailové adresy a na ně pak „milostný vzkaz“ poslal dál. Škody vznikaly jak zahlcením e-mailových serverů, tak i druhou činností viru, kterou bylo přemazání souborů uložených v napadeném počítači.

    Ladislav Hagara | Komentářů: 22
    3.5. 22:33 | Nová verze

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

    Ladislav Hagara | Komentářů: 2
    2.5. 22:22 | Komunita

    Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za duben (YouTube).

    Ladislav Hagara | Komentářů: 0
    2.5. 19:11 | IT novinky

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

    Ladislav Hagara | Komentářů: 5
    2.5. 11:22 | Zajímavý projekt

    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.

    Ladislav Hagara | Komentářů: 2
    2.5. 09:11 | Bezpečnostní upozornění

    Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.

    Ladislav Hagara | Komentářů: 2
    1.5. 20:00 | Komunita

    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.

    Ladislav Hagara | Komentářů: 3
    Jaký filesystém primárně používáte?
     (58%)
     (1%)
     (8%)
     (21%)
     (4%)
     (2%)
     (2%)
     (0%)
     (1%)
     (3%)
    Celkem 524 hlasů
     Komentářů: 22, poslední dnes 10:06
    Rozcestník

    Jaderné noviny - 1/2008

    22. 1. 2008 | Jirka Bourek | Jaderné noviny | 3782×

    2.6.24-rc4, "trošku pozdě". 2.6.24-rc5, konečná verze do Vánoc nebude. Citát: Vyhýbání se OOM killerovi. Sbírání dat z jaderných oops. Oprášení jádra 0.01. Vydání stabilního jádra 2.4.36. Citát: Proti tomu se postavím. Ospalý Linux. Citát: Výhody TuxOnIce. 2.6.24-rc7, spousta malých změn. Citát: Menšina. Dekódování oops.

    Obsah

    Následující obsah je © KernelTrap.

    2.6.24-rc4, "trošku pozdě"

    link

    4. prosinec, originál

    Mezi jednotlivými vydáními -rc bychom měli mít týdenní interval, ale během Díkůvzdání jsem byl týden pryč (stejně jako mnoho dalších vývojářů jádra), takže tohle je trochu opožděné. Zpoždění začíná být spíše pravidlem než výjimkou, ale slibuji, že se polepším... Linus Torvalds takto začal oznámení o vydání jádra 2.6.24-rc4. Není v něm moc vzrušujících změn, ale děje se v něm o hodně víc změn, než bych doufal ve stádiu, kdy máme -rc4. V diffstatech vynikají Blackfin, MIPS a Power, ale v ARM a x86 došlo také k nějakým aktualizacím.

    Něco se dělo také u ACPI (přiškrcování [throttling] procesoru atd.), společně s tím proběhly různé aktualizace ovladačů: ATA, IDE, infiniband, SCSI, USB a síťové ovladače. U souborových systémů cifs, NFS, ocfs2 a proc. Uf. Je toho příliš.

    Diff od -rc3 má skoro 36000 řádek a to je ten menší pro git, kde se přejmenování ukazují jako přejmenování (není to ten, který nahrávám jako patche na kernel.org, ten je dělán tak, aby ho mohli používat lidé s GNU patch a dalšími starodávnými programy, které používají diffy). Částečně za to může to dvoutýdenní okno, ale i tak je to trochu skličující. Opravdu doufám, že budeme zpomalovat a že -rc5 bude o hodně menší.

    Zkrátka, žádná ze změn není opravdu vzrušující nebo opravdu děsivá. Také jsme opravili spoustu regresí, i když víc jich určitě zbývá.

    2.6.24-rc5, konečná verze do Vánoc nebude

    link

    12. prosinec, originál

    Je to týden, co jsem slíbil, že budu hodný chlapec a budu dodržovat pravidla o vydávání verzí, takže tady je další -rc, psal Linus Torvalds v oznámení jádra 2.6.24-rc5 Dodal k němu:

    Věci se zpomalily, ale lhal bych, kdybych řekl, že máme všechny regrese ošetřené a pod kontrolou. Pracuje se na nich a seznam se zmenšuje, ale můj odhad je, že určitě nebudeme mít finální verzi 2.6.24 hotovou před Vánoci, pokud tedy Santa nezaměstná víc elfů, aby na těch regresích zapracovali. Takže všichni elfové tam venku - prosím, pokračujte v práci.

    Linus dodal, že v tomto nejnovějším release candidate nebyly žádné velké změny, takže nemá cenu posílat diffstat. S ohledem na délku textu je na pohled výrazný revert PA-RISC a aktualizace defconfigu u powerpc. A SPI ovladač pro Blackfin. Zbytek je z velké části náhodný šum v různých subsystémech (ovladače/síť, souborový systém xfs a aktualizace architektur jsou některé z oblastí, kde se objevuje víc změn).

    Citát: Vyhýbání se OOM killerovi

    link

    Kdykoliv začne OOM killer střílet, se systémem je něco špatně a je mnohem produktivnější to řešit, než si přát přesnějšího OOM killera.

    Dan Kegel, zpráva ze 7. prosince na Linux Kernel mailing list.

    Sbírání dat z jaderných oops

    link

    17. prosinec, originál

    Arjan van de Ven oznámil novou webovou stránku: http://www.kerneloops.org sbírá z různých mailových konferencí a bugzill zprávy z jaderných oops a varování. Přiložil shrnutí deseti nejčastějších oops zpráv za posledních 7 dní a poznamenal: Toto je první takové shrnutí, které zasílám. Dejte mi, prosím, vědět, jestli je to užitečné, nebo ne.

    Odezva byla kladná. Andrew Morton poznamenal: To mohla být sranda naprogramovat. Steven Richter vyjádřil obavy, že tento nástroj bude započítávat stejnou zprávu o chybě několikrát, pokud ji najde na několika místech. S tím Arjan souhlasil: To je pravda, nicméně je to... složitá věc. Je opravdu složité rozlišit duplicitní zprávu od dvou zpráv o stejné chybě. Objevila se také další obava, že budou odděleny oops vygenerované jádrem 2.6.X-rcY a 2.6.X.rcY-mmZ. Arjan poznamenal: Zjištění, ze které verze jádra ten oops pochází je... překvapivě složité. A upřímně, chyby proti -mm nás také dost zajímají, protože se přece jenom v budoucnu dostanou do hlavní řady.

    Oprášení jádra 0.01

    link

    2. leden, originál

    Abdel Benamrouche oznámil, že aktualizoval původní jádro verze 0.01 tak, aby šlo přeložit gcc řady 4.x a mohlo tedy běžet v emulátorech jako je QEMU a Bochs.

    Po aplikování sady malých patchů, vysvětluje Abdel, může být jádro 0.01 přeloženo na systému, který běží na linuxovém jádře 2.6.

    Dodal, že úspěšně portoval bash-3.2, část coreutils-6.9, dietlibc-0.31 (místo glibc), bin86-0.16.17, make-3.81, ncurses-2.0.7 a vim-7.1, aby mohly na tomto modifikovaném jádře fungovat.

    Vydání stabilního jádra 2.4.36

    link

    3. leden, originál

    Nový rok, nové jádro: Linux 2.4.36 je konečně hotové a bylo prověřováno dost dlouho na to, abychom ho mohli vydat. Od 2.4.35 byla opravena spousta chyb, chyb při překladu a bezpečnostních problémů, ale všechny tyto opravy byly začleněny do 2.4.35-stable, oznámil správce jádra 2.4 Willy Tarreau.

    Měl bych říct, že jsem docela spokojen s modelem vydávání s dvěma větvemi, který velmi úspěšně odděluje rychlé opravy od změn, které potřebují podrobnější testování. Potom dodal:

    Co se budoucích verzí týče, nezbývá už nic, co by bylo potřeba udělat. Budu pokračovat s 2.4.36.X, až přijdou opravy chyb. 2.4.37 založím jenom v případě, že dostanu něco, co nebudu považovat za vhodné pro zařazení do 2.4.36.X.

    Předchozí stabilní jádro 2.4.35 bylo vydáno v červenci 2007. Změny na úrovni zdrojových kódů lze prohlédnout přes gitweb rozhraní linux-2.4.

    Citát: Proti tomu se postavím

    link

    Proti čemu se budu hodně stavět, je přístup "nevíme, co je špatně, ale necháme to špatně, protože nás přece nikdo nemůže otravovat s tím, abychom to řešili."

    Linus Torvalds, zpráva ze 2. ledna na Linux Kernel mailing list.

    Ospalý Linux

    link

    4. leden, originál

    Současné verze Linuxu umí přejít do režimu uspání do paměti [suspend-to-RAM] docela dobře, ale mohou to udělat jenom na přímý příkaz. Uspávání do paměti je ale důležité, spotřeba energie v porovnání s nezatíženým [idle] systémem je asi 10 %. Ruční uspávání není příliš vhodné, začal Pavel Machek popis svého nápadu, který nazval Ospalý Linux.

    Ruční uspávání nepřichází v úvahu na víceuživatelských strojích a ani na jednouživatelských to není tak jednoduché: 1) Stáhni tenhle velký kus něčeho v Mozille a pak se uspi; 2) Zkompiluj tohle a pak se uspi; 3) Můžeš se uspat hned, ale v 8:30 mě probuď mp3 přehrávačem. Pavel poskytl jednoduchý a ne zcela funkční patch, potom popsal navrhované řešení:

    Dnešní hardware je většinou schopen fungovat lépe: se správně nastaveným probouzením může stroj spát a přitom předstírat, že nespí, tak, že se probudí pokaždé, když se stane něco zajímavého. To je samozřejmě jednodušší na strojích, které nejsou připojeny do sítě, a na noteboocích.

    Citát: Výhody TuxOnIce

    link

    Možná to také pomůže v mé snaze, pokud si na nějakou najdu čas, přesvědčit Andrewa, že TuxOnIce má skutečně významné výhody oproti (u)swsusp a na kexec založené hibernaci.

    Nigel Cunningham, zpráva z 1. ledna na Linux Kernel mailing list.

    2.6.24-rc7, spousta malých změn

    link

    7. leden, originál

    Linus Torvalds oznámil vydání linuxového jádra 2.6.24-rc7: Od -rc6 uplynuly dva týdny, ale přiznejme si, že mezi Vánoci a Novým rokem (a narozeninami) nebylo mnoho pracovních dní, takže rozdílový patch z -rc6 je poloviční oproti tomu z rc5 na rc6. Budu shovívavý a budu tvrdit, že je to díky tomu, že se všechno stabilizuje, ne proto, že jsme všichni během svátků byli zpití do němoty.

    Linus stručně shrnul změny: Zkrácený log (přiložen dole) je krátký a vcelku informativní. Je to prostě jenom spousta malých změn. Diffstat zobrazuje spoustu jedno- a dvouřádkových změn, větší pozornost budí jen pár ovladačů (a platforma Cell.) Více vyniká jenom podpora /proc/slabinfo ve SLUB.

    Citát: Menšina

    link

    Musím říct, že chyby, které skutečně zmizí poté, co uživatel přestane používat nvidia/fglrx/ndiswrapper/atd., tvoří v celkovém počtu menšinu.

    Andrew Morton, zpráva z 9. ledna na Linux Kernel mailing list.

    Dekódování oops

    link

    9. leden, originál

    Tento týden bylo hlášeno celkem 49 oops hlášení a varování, minulý týden to bylo 53, napsal Arjan van de Ven, když posílal seznam nejčastějších 10 kernel oops z tohoto týdne. Al Viro navrhl: Lidé, kteří si stěžují, že s prací v jádře teprv začínají a že pro ně proto není dost práce, by mohli dekódovat tato hlášení na "tohle místo v téhle funkci, funkce byla volána <odtud>, hodnota té a té proměnné byla <taková>" a posílat výsledky.

    Následovalo mnoho požadavků na návod, jak takový oops dekódovat. Linus Torvalds odpověděl: Ve skutečnosti to není vždy tak triviální, zvlášť když nemáte hluboké znalosti o kódu generovaném pro danou architekturu (a i tak jsou některé oops složitější než jiné kvůli inliningu, volání funkce na konci jiné [tail-call], atd.) Pokud oops nastane u kernelu, který jste si přeložili sami, je to většinou jednoduché, zvlášť pokud jste při konfiguraci řekli "y" u "Generovat ladící informace" [Generate debugging info].

    Linus pokračoval detailnějším postupem, jak hledat chybu v oops hlášení, které náhodně vybral v lkml. Obecně musíte disasemblovat šestnáctkovou sekvenci uvedenou v oops hlášení (řádka "Code") a pokusit se ji spojit se zdrojovým kódem tak, abyste zjistili, co se děje. Potom uvedl několik tipů, jak toho dosáhnout nejlépe, a pokračoval příkladem, ve kterém prošel jeden z nahlášených oops. Al Viro se přidal popisem svých vlastních metod, jak dosáhnout stejného výsledku, přičemž prošel jiné hlášení a chybu nalezl.

           

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

    22.1.2008 09:11 Filip Jirsák | skóre: 68 | blog: Fa & Bi
    Rozbalit Rozbalit vše češtinářská koutek
    Nepoužívaly se dříve v JN správné české uvozovky „“?

    Nehodilo by se pro citáty v JN používat sémantický tag <cite> a dám mu stejný styl, jako má třída kt_citace?

    Jinak opět děkuji za další díl Jaderných novin.
    22.1.2008 09:26 Robert Krátký | skóre: 94 | blog: Robertův bloček
    Rozbalit Rozbalit vše Re: češtinářská koutek
    Nepoužívaly se dříve v JN správné české uvozovky „“?
    Spíše ne, ale je pravda, že bych to měl zavést u všech článků.
    Nehodilo by se pro citáty v JN používat sémantický tag <cite> a dám mu stejný styl, jako má třída kt_citace?
    Těch tagů, které by našly uplatnění, je více (q, samp, kbd, ...). Zkusím s nimi začít pracovat.
    22.1.2008 09:18 kavol | skóre: 28
    Rozbalit Rozbalit vše Re: Jaderné noviny - 1/2008
    Kdykoliv začne OOM killer střílet, se systémem je něco špatně a je mnohem produktivnější to řešit, než si přát přesnějšího OOM killera.
    nevím, jestli to není vytržené z kontextu, ale tak jak to stojí, tak bych řekl, že pisatel je s odpuštěním trouba - když je chyba v aplikaci (nebo třeba ani ne chyba, prostě jen zpracovává neobvykle velká data) a ta si naalokuje veškerou dostupnou paměť, takže systém jde do kytek, jak to podle něj mám řešit, to mám tu aplikaci přestat používat a odinstalovat, aby náhodou nedošlo na killer? nebo si mám napsat vlastního démona, který bude hlídat paměť a sestřelí, co jí žere kriticky mnoho, aby náhodou nedošlo na killer (neměla by to snad být jeho práce)?
    22.1.2008 09:35 Filip Jirsák | skóre: 68 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Jaderné noviny - 1/2008
    Kdykoliv začne OOM killer střílet, se systémem je něco špatně a je mnohem produktivnější to řešit, než si přát přesnějšího OOM killera.
    nevím, jestli to není vytržené z kontextu, ale tak jak to stojí, tak bych řekl, že pisatel je s odpuštěním trouba - když je chyba v aplikaci (nebo třeba ani ne chyba, prostě jen zpracovává neobvykle velká data) a ta si naalokuje veškerou dostupnou paměť, takže systém jde do kytek, jak to podle něj mám řešit, to mám tu aplikaci přestat používat a odinstalovat, aby náhodou nedošlo na killer? nebo si mám napsat vlastního démona, který bude hlídat paměť a sestřelí, co jí žere kriticky mnoho, aby náhodou nedošlo na killer (neměla by to snad být jeho práce)?
    Co takhle opravit tu aplikaci? Když jí OOM killer „zastřelí“, tak asi stejně nebude moc použitelná…
    22.1.2008 10:18 Luboš Luňák | skóre: 19 | blog: Seli
    Rozbalit Rozbalit vše Re: Jaderné noviny - 1/2008
    A k cemu potom OOM killer je? Jestli "neni" problem, ze OOM killer by se spis mel jmenovat OOM mass murderer a nahodne postrili i uplne nevinne procesy, tak to uz stejne tak tam muzou dat random() a hotovo. Kazdy se obcas utne a je dost otrava, kdyz se kvuli tomu musi vsechno restartovat (napr. OOM killer se zeleznou pravidelnosti vybere jako prvni k zastreleni jeden z nejdulezitejsich procesu z KDE a vsechno jde do haje, museli jsme na to pridavat workaround).
    22.1.2008 10:49 Filip Jirsák | skóre: 68 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Jaderné noviny - 1/2008
    On snad někdo pravidelně používá programy, které sežerou veškerou dostupnou paměť? Může se to dít ppogramátorům nebo testerům – pak ale není problém v algoritmu OOM killeru, ale v tom, že nemá uživatel šanci říci mu, který přesně proces je ten, který OOM pravděpodobně způsobí. Pak by ale podle mne jediné řešení bylo umožnit uživateli nastavit procesu příznak, že v případě nedostatku paměti má být přednostně odstřelen tento proces.
    22.1.2008 12:06 Michal Kubeček | skóre: 72 | Luštěnice
    Rozbalit Rozbalit vše Re: Jaderné noviny - 1/2008
    Nebo spíš obráceně: označit procesy, které smějí být odstřeleny jen v případě, že není jiného zbytí (třeba sshd).
    22.1.2008 12:20 Filip Jirsák | skóre: 68 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Jaderné noviny - 1/2008
    Ale to přece neodpovídá realitě. V praxi pokud někdo (opakovaně) pouští proces, který zabere veškerou paměť, ví přesně, který proces to je, a jeho představa je taková, že OOM killer zabije právě tenhle jeden proces.

    Pokud někdo spustí nějaký proces „v dobré víře“ a ten proces užírá paměť postupně, je to stav prakticky nepopsatelný, tudíž nealgoritmizovatelný, a asi nemá smysl bádat nad tím, jestli by OOM killer neměl proces k ukončení vybírat nějak lépe. Protože jak posoudí uživatel, že OOM killer vybral pro zabití špatný proces? Jedině tak, že má dopředu představu, který proces měl vybrat místo něj. A jsme zpátky u toho, označit dopředu proces(y), u kterých předpokládám, že by mohly dělat neplechu.
    22.1.2008 13:41 happy barney | skóre: 34 | blog: dont_worry_be_happy
    Rozbalit Rozbalit vše Re: Jaderné noviny - 1/2008
    v praxi to funguje tak, že php zožerie pamäť, ale oom killer odstrelí databázu :-)
    22.1.2008 14:12 cronin | skóre: 49
    Rozbalit Rozbalit vše Re: Jaderné noviny - 1/2008
    To je nie chyba, to je predsa umela inteligencia: OOM Killer odvodil, ze PHP vyzralo pamat len kvoli tomu, ze z databazy natiahlo prilis vela udajov. :-D
    22.1.2008 14:07 Michal Kubeček | skóre: 72 | Luštěnice
    Rozbalit Rozbalit vše Re: Jaderné noviny - 1/2008
    Mně šlo spíš o to, aby když už dojde na nejhorší a OOM něco odstřelí, aby to nebyl zrovna ten jediný proces, který by mi umožnil s tím systémem na dálku něco udělat (i kdyby to měl být jen korektní restart).
    22.1.2008 14:21 happy barney | skóre: 34 | blog: dont_worry_be_happy
    Rozbalit Rozbalit vše Re: Jaderné noviny - 1/2008
    je to dôležité (sshd)? do inittabu s ním :-)
    22.1.2008 14:45 Filip Jirsák | skóre: 68 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Jaderné noviny - 1/2008
    Bral jsem to, že když už mi na nějakém takhle důležitém systému běží nějaká leakující aplikace, je už to stejně skoro jedno, protože nějaký nekorektní restart je ten nejmenší z problémů, který mi to způsobí :-)

    Ale jinak je to pravda – pro běžný provoz by se hodilo, aby nad některými aplikacemi držel OOM ochranou ruku, pro testování je zase lepší, když mu některé hříšníky nabonzuju rovnou předem. A jak napsal někdo níž v diskuzi, obojí je možné. Teď už zbývá jenom doladit startovací skripty, aby při spuštění daemona nastavily procesu tu hodnotu podle nějakého rozšířeného atributu spouštěné binárky automaticky, a máme vystaráno :-)
    22.1.2008 15:02 happy barney | skóre: 34 | blog: dont_worry_be_happy
    Rozbalit Rozbalit vše Re: Jaderné noviny - 1/2008
    oom_adj je tuším dedené, takže v rc skriptoch bude stačiť echo $oom_value > /proc/$$/oom_adj
    22.1.2008 12:17 Luboš Luňák | skóre: 19 | blog: Seli
    Rozbalit Rozbalit vše Re: Jaderné noviny - 1/2008
    Ach jo, tady si to zase nekdo predstavuje jak Hurvinek valku :-/. To mam porad laborovat s nastavovanim nejakeho priznaku na proces, ktery by zrovna mozna nahodou mohl mit problem, jen protoze kernel neni schopny pochopit, ze ma killnout proces, ktery za posledni okamzik nejvic narostl? A ano, vim, ze dokonaly algoritmus pro OOM killer nejde, jenze soucasny k nemu ma asi tak daleko jako trabant k formuli - nakonec taky nejak dojede.

    A hlavni problem soucasneho OOM killeru neni ten, ze by se obcas netrefil. On se napoprve netrefi skoro nikdy.
    22.1.2008 12:24 Filip Jirsák | skóre: 68 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Jaderné noviny - 1/2008
    jen protoze kernel neni schopny pochopit, ze ma killnout proces, ktery za posledni okamzik nejvic narostl
    Nepovede tenhle postup k zabití poslední spuštěné aplikace, nebo k zabití X, pokud oním zlobivým procesem je nějaká GUI aplikace? Případně vybije všechno možné, ale trvale rostoucího bumbrlíčka nechá na pokoji?
    Stanislav Brabec avatar 22.1.2008 13:29 Stanislav Brabec | skóre: 45 | Praha
    Rozbalit Rozbalit vše Re: Jaderné noviny - 1/2008
    Ono je těžké odhadnout, kdo je ten nebezpečný bumbrlíček.

    Představte si proces, který náhodně, zhruba jednou za sekundu, naalokuje pár kilobajtů, a nikdy nic nevrátí. Přestože vypadá nenápadně, časem dokáže zlikvidovat systém.

    Proti němu vypadá proces, který zrovna desetkrát alokoval paměť, aby zobrazil okno „Není dostatek paměti!“ jako hlavní podezřelý. Až postřílí podobně „podezřelé“ dostane to i ten bumbrlíček.

    Je ovšem ještě šance, že ten po první chybě paměť žrát přestane, a jen bude sedět na tom, co už má. Pak už jde použít jedině heuristiku: „Odstřel toho, kdo má nejvíc.“ Je skoro jasné, že podle této heuristiky to jako první dostanou Evolution, Firefox a X.
    22.1.2008 14:40 Filip Jirsák | skóre: 68 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Jaderné noviny - 1/2008
    Právě proto tvrdím, že buď můžu jako uživatel předem označit aplikaci, která je „podezřelá“, nebo holt vybíjení procesů nebude moc daleko od náhodných výstřelů, protože spolehlivě určit viníka nelze. Ostatně která aplikace je viník je vždycky věc názoru člověka, který ty aplikace provozuje – obecně může mít nějaká aplikace dobrý důvod alokovat postupně čím dál víc paměti, stejně jako to může znamenat memory leak. A i aplikace, kde je to memory leak, může takhle leakovat „chtěně“ – např. když se programátor pokouší zjistit, kde je vlastně problém.
    22.1.2008 13:39 petr_p | skóre: 59 | blog: pb
    Rozbalit Rozbalit vše Re: Jaderné noviny - 1/2008
    /proc/PID/oom_adj:

    This file can be used to adjust the score used to select which processes should be killed in an out-of-memory situation. Giving it a high score will increase the likelihood of this process being killed by the oom-killer. Valid values are in the range -16 to +15, plus the special value -17, which disables oom-killing altogether for this process.
    22.1.2008 12:44 Ondrej 'SanTiago' Zajicek
    Rozbalit Rozbalit vše Re: Jaderné noviny - 1/2008
    > to mám tu aplikaci přestat používat a odinstalovat, aby náhodou nedošlo na killer?

    Co poustet takovou aplikaci s vhodne nastavenym ulimitem?
    23.1.2008 13:16 kavol | skóre: 28
    Rozbalit Rozbalit vše Re: Jaderné noviny - 1/2008
    a to "vhodné nastavení" zjistím jak? - nemám křišťálovou kouli, abych v okamžik spuštění nějaké aplikace věděl, jestli druhý den sestřelí systém když bude zabírat 500 MB paměti nebo až když bude zabírat 1,5 GB ...
    22.1.2008 15:18 trekker.dk | skóre: 72
    Rozbalit Rozbalit vše Re: Jaderné noviny - 1/2008
    když je chyba v aplikaci (nebo třeba ani ne chyba, prostě jen zpracovává neobvykle velká data) a ta si naalokuje veškerou dostupnou paměť, takže systém jde do kytek, jak to podle něj mám řešit, to mám tu aplikaci přestat používat a odinstalovat, aby náhodou nedošlo na killer?
    Pokud aplikace zpracovává neobvykle velká data a dojde paměť, tak "je se systémem něco špatně", protože jsi tam nedal dost paměti. Je produktivnější to řešit (přidat paměť), protože jinak se situace pravděpodobně bude opakovat.

    A ne, nemáš ji přestat používat, aby na killera náhodou nedošlo, ale máš potom zjistit, co se stalo a pokusit se tomu nějak předejít. OOM killer je jenom nouzový prostředek, který má napravovat chyby někoho jiného - mnohem efektivnější, než vylepšovat OOM killer, je podle mě věnovat čas na opravu těch chyb.
    Quando omni flunkus moritati
    23.1.2008 13:14 kavol | skóre: 28
    Rozbalit Rozbalit vše Re: Jaderné noviny - 1/2008
    Pokud aplikace zpracovává neobvykle velká data a dojde paměť, tak "je se systémem něco špatně", protože jsi tam nedal dost paměti. Je produktivnější to řešit (přidat paměť), protože jinak se situace pravděpodobně bude opakovat.
    jenomže dopředu to obvykle nevím - ano, až to zjistím, mohu paměť dokoupit, jenomže mezitím jaksi potřebuju něco, aby zasáhlo právě v ten okamžik, kdy problém nastane; můj počítač totiž jaksi nepodporuje hotswap pamětí, nehledě na to, že bych s ním třeba chtěl ještě něco udělat než do toho krámu pro tu paměť poběžím atd.
    A ne, nemáš ji přestat používat, aby na killera náhodou nedošlo, ale máš potom zjistit, co se stalo a pokusit se tomu nějak předejít. OOM killer je jenom nouzový prostředek, který má napravovat chyby někoho jiného - mnohem efektivnější, než vylepšovat OOM killer, je podle mě věnovat čas na opravu těch chyb.
    ta myšlenka nebyla tak úplně dokončená, měl jsem ještě říct, že takhle bych mohl odinstalovat celý systém :-)

    samozřejmě je lepší, aby k chybám nedocházelo, ale občas se holt stane, a říkat, že není vhodné snažit se, aby ten "nouzový prostředek" nebyl co nejefektivnější, je divné ... asi jako kdyby někdo říkal, že nepotřebujeme tolik přispívat na hasiče, aby měli co nejlepší vybavení, protože když někde začne hořet, mám pak zjistit, co se stalo, a pokusit se tomu předejít (nejspíš instalovat tabulku s nápisem "neodhazute nedopalky" a najmout hlídače na vynucení dodržování? ;-))
    23.1.2008 13:18 miso | skóre: 36 | blog: iSCSI_initiator_howto | Praha
    Rozbalit Rozbalit vše Re: Jaderné noviny - 1/2008
    Nikdy nehas benzinem ohniste!

    Ted je to uz jedno, ale pro priste ;-)
    Project Satan infects Calculon with Werecar virus
    13.12.2021 10:48 geebranz
    Rozbalit Rozbalit vše Re: Jaderné noviny - 1/2008

    Založit nové vláknoNahoru

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