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 11:00 | Zajímavý software
Na Good Old Games je v rámci aktuálních zimních slev zdarma k dispozici remasterovaná verze klasické point&click adventury Grim Fandango, a to bez DRM a pro mainstreamové OS včetně GNU/Linuxu. Akce trvá do 14. prosince, 15:00 SEČ.
Fluttershy, yay! | Komentářů: 6
dnes 07:22 | Pozvánky

Konference InstallFest 2018 proběhne o víkendu 3. a 4. března 2018 v Praze na Karlově náměstí 13. Spuštěno bylo CFP. Přihlásit přednášku nebo workshop lze do 18. ledna 2018.

Ladislav Hagara | Komentářů: 0
včera 20:22 | Nová verze

Před měsícem byla vydána Fedora 27 ve dvou edicích: Workstation pro desktopové a Atomic pro cloudové nasazení. Fedora Server byl "vzhledem k náročnosti přechodu na modularitu" vydán pouze v betaverzi. Finální verze byla naplánována na leden 2018. Plán byl zrušen. Fedora 27 Server byl vydán již dnes. Jedná se ale o "klasický" server. Modularita se odkládá.

Ladislav Hagara | Komentářů: 6
včera 10:22 | Zajímavý článek

Lukáš Růžička v článku Kuchařka naší Růži aneb vaříme rychlou polévku z Beameru na MojeFedora.cz ukazuje "jak si rychle vytvořit prezentaci v LaTeXu, aniž bychom se přitom pouštěli do jeho bezedných hlubin".

Ladislav Hagara | Komentářů: 13
včera 07:22 | Komunita

Od 26. do 29. října proběhla v Bochumi European Coreboot Conference 2017 (ECC'17). Na programu této konference vývojářů a uživatelů corebootu, tj. svobodné náhrady proprietárních BIOSů, byla řada zajímavých přednášek. Jejich videozáznamy jsou postupně uvolňovány na YouTube.

Ladislav Hagara | Komentářů: 0
11.12. 19:22 | Nová verze

Ondřej Filip, výkonný ředitel sdružení CZ.NIC, oznámil vydání verze 2.0.0 open source routovacího démona BIRD (Wikipedie). Přehled novinek v diskusním listu a v aktualizované dokumentaci.

Ladislav Hagara | Komentářů: 0
11.12. 09:22 | Pozvánky

V Praze dnes probíhá Konference e-infrastruktury CESNET. Na programu je řada zajímavých přednášek. Sledovat je lze i online na stránce konference.

Ladislav Hagara | Komentářů: 2
9.12. 20:11 | Nová verze

Byl vydán Debian 9.3, tj. třetí opravná verze Debianu 9 s kódovým názvem Stretch a Debian 8.10, tj. desátá opravná verze Debianu 8 s kódovým názvem Jessie. Řešeny jsou především bezpečnostní problémy, ale také několik vážných chyb. Instalační média Debianu 9 a Debianu 8 lze samozřejmě nadále k instalaci používat. Po instalaci stačí systém aktualizovat.

Ladislav Hagara | Komentářů: 11
9.12. 00:44 | Nová verze

Po 6 měsících vývoje od vydání verze 0.13.0 byla vydána verze 0.14.0 správce balíčků GNU Guix a na něm postavené systémové distribuce GuixSD (Guix System Distribution). Na vývoji se podílelo 88 vývojářů. Přibylo 1 211 nových balíčků. Jejich aktuální počet je 6 668. Aktualizována byla také dokumentace.

Ladislav Hagara | Komentářů: 4
8.12. 21:33 | Nová verze

Po půl roce vývoje od vydání verze 5.9 byla vydána nová stabilní verze 5.10 toolkitu Qt. Přehled novinek na wiki stránce. Současně byla vydána nová verze 4.5.0 integrovaného vývojového prostředí (IDE) Qt Creator nebo verze 1.10 nástroje pro překlad a sestavení programů ze zdrojových kódů Qbs.

Ladislav Hagara | Komentářů: 0
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (8%)
 (1%)
 (1%)
 (1%)
 (75%)
 (14%)
Celkem 976 hlasů
 Komentářů: 45, poslední 1.12. 19:00
    Rozcestník

    Jaderné noviny – 24. 4. 2014: Vyšší limity sdílené paměti

    12. 5. 2014 | Luboš Doležel | Jaderné noviny | 2952×

    Aktuální verze jádra: 3.15-rc2. Citáty týdne: netcat, Andrew Morton. Změna výchozích limitů sdílené paměti.

    Obsah

    Aktuální verze jádra: 3.15-rc2

    link

    Aktuální vývojová verze jádra je 3.15-rc2 vydaná 20. dubna. Linus k ní řekl: A sedmého dne rc vydání opět povstalo, jak pravily skripty sepsané na kernel sumitu roku 2004.

    Stabilní aktualizace: verze 3.13.11 vyšla 22. dubna. Greg řekl, že odteď přestane řadu 3.13 udržovat, ale jaderný tým Ubuntu bude v podpoře pokračovat až do dubna 2016.

    Citáty týdne: netcat, Andrew Morton

    link

    Vítáme vás u nejzbytečněji komplikovaného formátu vydání alba od netcatu.

    V tomto repozitáři si můžete zkompilovat vlastní jaderný modul, vytvořit zařízení /dev/netcat a poslat jeho výstup rourou do přehrávače:

    ogg123 – < /dev/netcat 

    Tento repozitář obsahuje data stop z alba ve zdrojových souborech, které (v zájmu složitosti) pocházejí z .ogg souborů, které byly kódovány z .mp3 souborů, které byly kódovány z finálních .wav souborů, které byly generovány z konečných mixážních .wav souborů z ProTools, které byly vytvořeny z 24stopé analogové pásky.

    Brandon Lucia, Andrew Olmstead a David Balatero vydali nové album

    Řekl bych, že první věcí by bylo přidat tam varování a počkat, jestli zjistíme, kolik kódu bude takovou změnou zasaženo. Do printk přidej „prosím pošlete mail Keesovi“ ;-) Jednou jsem to udělal, je tomu mnoho let. Dostal jsem spoustu e-mailu. Znovu jsem to už neudělal.

    -- Andrew Morton

    Změna výchozích limitů sdílené paměti

    link

    Limity sdílené paměti System V v linuxovém jádře jsou od úplného začátku nastaveny na stejnou hodnotu. Ačkoliv uživatelé mohou tento limit navýšit, jelikož objem paměti očekávaný moderními aplikacemi během uplynulých let vzrostl, otázkou nadále zůstává, jestli má smysl výchozí nastavený změnit – je tu i možnost jej zcela odstranit. Jak se už ale často stává, ukázalo se, že se najdou uživatelé, kteří si navykli na to, že se limit sdílené paměti chová určitým způsobem, takže jeho změna by vedla k nečekaným důsledkům. Proto i když asi nikdo není se současným výchozím nastavením spokojen, není jednoduché určit, jak jej opravit.

    Sdílená paměti dle System V (SHM) je běžně užívána jako prostředek ke komunikaci mezi procesy; skupina spolupracujících procesů (například relací databáze) může sdílet segment paměti až do maximální velikosti povolené systémem. Tento limit může být vyjádřen v bajtech na sdílený segment (SHMMAX) a v podobě celkového počtu stránek použitých pro všechny segmenty (SHMALL). Na Linuxu byla výchozí hodnota SHMMAX vždy 32 MB a výchozí hodnota SHMALL je definována jako:

    #define SHMALL (SHMMAX/getpagesize()*(SHMMNI/16))
    

    kde SHMMNI je maximální počet SHM segmentů – standardně 4096 – což zase dává výchozí hodnotu SHMALL 2097152 stránek. I když mají dobře známé výchozí hodnoty, tak hodnoty SHMMAX a SHMALLL je možné měnit pomocí sysctl. Je tu také související parametr nastavující minimální velikost sdíleného segmentu (SHMMIN); na rozdíl od ostatních limitů prostředků je tento nastaven na jeden bajt a není možné jej měnit.

    I když se většina uživatelů shodne, že jeden bajt je rozumnou minimální velikostí segmentu, to samé se nedá říct o SHMMAX; 32 MB není pro dnešní nenažrané procesy mnoho. Pravdou je, že se na produkčních systémech v posledních letech stalo navyšování SHMMAX rutinou a u nejpopulárnějších aplikací používajících SHM je doporučování navýšení běžnou praxí.

    Proto nepřekvapí to, že se v komunitě řešilo, že už je čas tento limit navýšit na nějakou vhodnější hodnotu, a tak 31. března Davidlohr Bueso poslal patch, který zvyšuje SHMMAX na 128 MB. Bueso uznal, že navýšil limit o v zásadě libovolnou hodnotu (jde o čtyřnásobné navýšení), ale v diskuzi, která následovala, řekl, že uživatelé by se asi měli rozhodnout sami a SHMMAX nastavit na určité procento celkové systémové RAM; zvýšení výchozí hodnoty jen představuje lepší výchozí bod pro současný hardware.

    Andrew Morton však namítal, že zvýšení výchozí hodnoty neřeší problém – a to ten, že uživatelé často narážejí na umělé omezení, které není nijak opodstatněné:

    Hele. 32M dělá problémy. Libovolné navýšení libovolných 32M na libovolných 128M nic neřeší – problém tu pořád je. Zkus se nad tím prosím více zamyslet: jak se tohoto problému můžeme navždy zbavit?

    Jedním způsobem, jak se problému navždy zbavit, by bylo se zbavit SHMMAX, ale jak bylo v diskuzi připomenuto, administrátoři pravděpodobně budou mít zájem nastavit alespoň nějaký limit tak, aby nikdo nemohl vytvořit SHM segment, který spotřebuje veškerou paměť v systému. Motohiro Kosaki navrhl nastavit výchozí limit na nulu, což by znamenalo „neomezeně“. Bueso pak tento přístup převzal v druhé verzi svého patche. Jelikož je SHMMIN napevno nastaveno na jedničku, logika velí, že SHMMAX nemůže nikdy být uživateli vnímáno jako platná hodnota – buď jde o výchozí hodnotu („neomezeně“), nebo je to důsledek přetečení.

    Aktualizovaná verze patche navíc nastavuje výchozí hodnotu SHMALL na nulu – což opět znamená „neomezeně“. Odstranění limitu celkového objemu SHM tímto způsobem ale odhalilo druhou chybu na kráse: Manfred Spraul upozornil, že nastavení SHMALL na nulu je způsob, jak administrátoři (poměrně rozumně) úplně zakazují alokace SHM; patch má ten neúmyslný důsledek, že dělá přesný opak toho, co měl tento krok znamenat – povoluje neomezenou alokaci SHM.

    Spraul následně napsal svůj vlastní alternativní patch, který se tomuto problému snaží vyhnout tak, že SHMMAX a SHMALL nastavuje na ULONG_MAX, což znamená nekonečno. Toto řešení s sebou ale také nese rizika; zejména kvůli tomu, že jsou známy případy, kdy se aplikace snaží hodnotu SHMMAX inkrementovat, nikoliv nastavit na určitou hodnotu, což by způsobilo přetečení. Výsledkem by bylo, že by aplikace narazily na nesprávnou hodnotu SHMMAX – pravděpodobně by byla mnohem menší, než kolik potřebují, takže by jejich pokusy o alokaci SHM selhaly.

    I tak ale Buesco souhlasil, že předejít obrácení významu ručního nastavení SHMALL na nulu je správná věc, a odsouhlasil Spraulův přístup. Poslední verze Spraulova patche se snaží přetečení předejít tím, že používá ULONG_MAX – 1L<<24, Spraul ale uznává, že uživatelům nic nebrání v tom přetečení způsobit.

    Poslední obavou zapříčiněnou touto změnou je, že pokud systém nemá žádnou horní mez alokací SHM, pak je možné, aby uživatelé spotřebovali veškerou dostupnou paměť na segmenty SHM. Pokud ale dojde k takové masivní alokaci, OOM killer nebude moci zakročit a tuto paměť uvolnit. Řešením je buď to, aby administrátoři povolili volbu shm_rmid_forced (která vynutí, že každý segment SHM bude vytvořen s příznakem IPC_RMID – což zaručuje, že je přiřazen k alespoň jednomu procesu, což zase zajistí, že jakmile OOM killer zabije zodpovědný proces, tak SHM segment zmizí spolu s ním) nebo aby ručně nastavili limity SHM.

    Protože původním smyslem tohoto úsilí bylo předejít potřebě ručně nastavovat limity SHM, může se zdát, že jsme tam, kde jsme byli. Pro většinu uživatelů je ale odstranění starých limitů vítanou změnou. Zlotřilí uživatelé pokoušející se alokovat veškerou paměť ve sdílených segmentech jsou přinejlepším anomálie (ale určitě něco, na co by si administrátoři měli dávat pozor), zatímco původní výchozí limit 32 MB byl pro řadu uživatelů už dlouhou dobu problémem.

           

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

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