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í
×
včera 21:33 | Nová verze

Byla vydána nová major verze 1.8.0 open source systému pro filtrování nevyžádané pošty Rspamd (GitHub, ChangeLog). Z novinek lze zmínit nový framework selectors, optimalizaci modulu ClickHouse nebo vylepšení webového rozhraní.

Ladislav Hagara | Komentářů: 0
včera 18:44 | Bezpečnostní upozornění

Sabri Haddouche vytvořil stránku Browser Reaper, na které demonstruje zranitelnosti současných verzí webových prohlížečů Chrome, Safari i Firefox. Zveřejněné skripty dokážou zahltit nejen webové prohlížeče, ale v závislosti na nastavení, také celé operační systémy.

Ladislav Hagara | Komentářů: 8
23.9. 19:22 | Nová verze

Byla vydána verze 11.3 open source alternativy GitHubu, tj. softwarového nástroje s webovým rozhraním umožňujícího spolupráci na zdrojových kódech, GitLab (Wikipedie). Představení nových vlastností i s náhledy v příspěvku na blogu.

Ladislav Hagara | Komentářů: 0
22.9. 13:00 | Komunita

Do 30. října se lze přihlásit do dalšího kola programu Outreachy (Wikipedie), jehož cílem je přitáhnout do světa svobodného a otevřeného softwaru lidi ze skupin, jež jsou ve světě svobodného a otevřeného softwaru málo zastoupeny. Za 3 měsíce práce, od 4. prosince 2018 do 4. března 2019, v participujících organizacích lze vydělat 5 500 USD.

Ladislav Hagara | Komentářů: 99
21.9. 22:22 | Komunita

Společnost Purism představila kryptografický token Librem Key. Koupit jej lze za 59 dolarů. Token byl vyvinut ve spolupráci se společností Nitrokey a poskytuje jak OpenPGP čipovou kartu, tak zabezpečení bootování notebooků Librem a také dalších notebooků s open source firmwarem Heads.

Ladislav Hagara | Komentářů: 9
21.9. 20:33 | Nová verze

Společnost NVIDIA oficiálně vydala verzi 10.0 toolkitu CUDA (Wikipedie) umožňujícího vývoj aplikací běžících na jejich grafických kartách. Přehled novinek v poznámkách k vydání.

Ladislav Hagara | Komentářů: 0
21.9. 20:00 | Upozornění

Příspěvek Jak přežít plánovanou údržbu DNS na blogu zaměstnanců CZ.NIC upozorňuje na historicky poprvé podepsání DNS root zóny novým klíčem dne 11. října 2018 v 18:00. Software, který nebude po tomto okamžiku obsahovat nový DNSSEC root klíč, nebude schopen resolvovat žádná data. Druhým důležitým datem je 1. února 2019, kdy významní výrobci DNS softwaru, také historicky poprvé, přestanou podporovat servery, které porušují DNS standard

… více »
Ladislav Hagara | Komentářů: 11
21.9. 15:55 | Pozvánky

Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 156. brněnský sraz, který proběhne v pátek 21. září od 18:00 v restauraci Na Purkyňce na adrese Purkyňova 80.

Ladislav Hagara | Komentářů: 0
21.9. 13:22 | Nová verze

Alan Griffiths z Canonicalu oznámil vydání verze 1.0.0 display serveru Mir (GitHub, Wikipedie). Mir byl představen v březnu 2013 jako náhrada X serveru a alternativa k Waylandu. Dnes Mir běží nad Waylandem a cílen je na internet věcí (IoT).

Ladislav Hagara | Komentářů: 0
20.9. 22:00 | Nasazení Linuxu
Stabilní aktualizace Chrome OS 69 (resp. Chromium OS), konkrétně 69.0.3497.95, přináší mj. podporu linuxových aplikací. Implementována je pomocí virtualizace, a proto je tato funkce také omezena na zařízení s dostatkem paměti a podporou hardwarové akcelerace, tudíž nejsou podporovány chromebooky s 32bitovými architekturami ARM, či Intel Bay Trail (tzn. bez Intel VT-x).
Fluttershy, yay! | Komentářů: 6
Na optické médium (CD, DVD, BD aj.) jsem naposledy vypaloval(a) data před méně než
 (14%)
 (14%)
 (20%)
 (23%)
 (24%)
 (4%)
 (0%)
Celkem 407 hlasů
 Komentářů: 34, poslední včera 12:54
Rozcestník

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

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

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.