Po více než roce vývoje od vydání verze 5.40 byla vydána nová stabilní verze 5.42 programovacího jazyka Perl (Wikipedie). Do vývoje se zapojilo 64 vývojářů. Změněno bylo přibližně 280 tisíc řádků v 1 500 souborech. Přehled novinek a změn v podrobném seznamu.
Byla vydána nová stabilní verze 7.5 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 138. Přehled novinek i s náhledy v příspěvku na blogu.
Sniffnet je multiplatformní aplikace pro sledování internetového provozu. Ke stažení pro Windows, macOS i Linux. Jedná se o open source software. Zdrojové kódy v programovacím jazyce Rust jsou k dispozici na GitHubu. Vývoj je finančně podporován NLnet Foundation.
Byl vydán Debian Installer Trixie RC 2, tj. druhá RC verze instalátoru Debianu 13 s kódovým názvem Trixie.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za červen (YouTube).
Libreboot (Wikipedie) – svobodný firmware nahrazující proprietární BIOSy, distribuce Corebootu s pravidly pro proprietární bloby – byl vydán ve verzi 25.06 "Luminous Lemon". Přidána byla podpora desek Acer Q45T-AM a Dell Precision T1700 SFF a MT. Současně byl ve verzi 25.06 "Onerous Olive" vydán také Canoeboot, tj. fork Librebootu s ještě přísnějšími pravidly.
Licence GNU GPLv3 o víkendu oslavila 18 let. Oficiálně vyšla 29. června 2007. Při té příležitosti Richard E. Fontana a Bradley M. Kuhn restartovali, oživili a znovu spustili projekt Copyleft-Next s cílem prodiskutovat a navrhnout novou licenci.
Svobodný nemocniční informační systém GNU Health Hospital Information System (HIS) (Wikipedie) byl vydán ve verzi 5.0 (Mastodon).
Open source mapová a navigační aplikace OsmAnd (OpenStreetMap Automated Navigation Directions, Wikipedie, GitHub) oslavila 15 let.
Vývojář Spytihněv, autor počítačové hry Hrot (Wikipedie, ProtonDB), pracuje na nové hře Brno Transit. Jedná se o příběhový psychologický horor o strojvedoucím v zácviku, uvězněném v nejzatuchlejším metru východně od všeho, na čem záleží. Vydání je plánováno na čtvrté čtvrtletí letošního roku.
Občas není od věci vyslovit něco, za co se upaluje nebo ukamenovává. Nic není totiž tak jednoduché, aby byla pravda vždy jediná a na první pohled zřejmá.
Je příjemné alokovat si více paměti, než je k dispozici. Na druhou stranu, má to dost nepříjemná úskalí. Mnohokrát jsem o tom přemýšlel, ptal jsem se řady lidí na jejich názor, ale jisté zůstává jenom jedno - je to záležitost vysoce kontroverzní.
Pravděpodobně všichni vědí, o co jde - ale raději to aspoň ve stručnosti nastíním:
Pokud se alokuje paměť (např. funkcí malloc()
v jazyce C), paměť k dispozici buďto je (a v tom případě volání skončí úspěchem, paměť se alokovala), anebo není (a volání skončí neúspěchem). Protože programy obvykle alokují více paměti, než jí pak skutečně využijí (je to z různých důvodů, někdy je skutečné využití velmi malé, např. u málo vytížených serverových aplikací), používá se technika zvaná overcommitting (česky bych řekl třeba "přealokace", ale není to přesné). Z pohledu aplikace to vypadá tak, že alokace skončí vždycky úspěšně, i když dané množství k dispozici není. Většinou to není problém, systém úspěšně funguje.
Problém nastane, když je alokováno víc paměti, než může systém dát k dispozici (když selžou veškeré pokusy o uvolnění paměti). Pak nastupuje hrubé násilí - v Linuxu reprezentované procesem oom-killer
. Ten se spustí ještě dřív, než k dané situaci dojde (spouští se při poklesu volné paměti pod určitý práh) a vytipuje vhodné kandidáty na odstřelení. Pokud už skutečně není volná paměť, oom-killer
zlikviduje proces, který byl nejžhavějším kandidátem. A tak pokračuje tak dlouho, dokud nejsou požadavky uspokojeny.
Otázka je, zda je použití overcommittingu vůbec výhrou. Jednoznačná odpověď není, čím dál víc jsem ale přesvědčen, že minimálně v prostředí, kde požadujeme stabilitu, své místo nemá (jen pro úplnost - overcommitting lze snadno vypnout). Poměrně snadno lze totiž takový systém destabilizovat.
Před časem jsem si tu stěžoval na problémy s X.org v souvislosti se zběsilou alokací paměti. Tato alokace souvisela s prohlížečem Opera, nicméně paměť alokoval X server. A nejen že alokoval, ale také nějak používal (podrobnosti neznám), takže brzy (za několik sekund) došlo k tomu, že se vyčerpala veškerá paměť včetně swapu a došlo na nejhorší. To co se dělo dál, nešlo předem předvídat - oom-killer
(aspoň ten v jádře 2.6.10) je špatný střelec a svůj cíl si často vybere nevhodně. Takže i když by měl být sestřelen původce (tj. X server; správněji spíš Opera, ale takovou inteligenci od "ničitele" chtít nemůžeme), odnesl to často jiný, zcela nevinný proces.
Jaké nebezpečí z toho plyne, je zřejmé. Jakýkoli program, který v systému běží, ho snadno může zásadním způsobem poškodit, aniž by dělal nějakou složitou činnost. Stačí pouze alokovat paměť. Bez overcommittingu by jeho alokace byla prostě najednou neúspěšná, a i když by se mu podařilo vyčerpat volnou paměť, přímé následky by nebyly. Kdežto takto by mu mohlo za oběť padnout i několik procesů, než by byl sám sestřelen.
Nechávám celou věc otevřenou, jednoznačný názor jsem si neudělal. Jen si říkám, zda cena, která se platí za možnost "kouzelného nafouknutí" paměti, není příliš vysoká.
Tiskni
Sdílej:
V případě, že jseš přihlášený, tak toho žrouta paměti taky nezabiješ, protože program kill nedostane žádnou paměť.Proto je taky kill zabudovany prikaz shellu (prinejmensim bash a zsh).
kill -9
nemá fatální následky, dopadne (aspoň u mě) úplně stejně, jako kdybych stiskl Ctrl-Alt-BkSp.
echo 2 > /proc/sys/vm/overcommit_memoryNejhorší zkušenosti s nedostatkem přealokované paměti mám taky pod Xkama, pravým původcem je pro změnu Mozilla/FireFox (je jedno, co je to za verzi). Poprvé jsem si toho všiml na své celkem nevinně vyhlížející stránce s naskenovanými skripty. Na novějších počítačích s větší pamětí (>= 512 MB), nebo i na starších s Konquerorem (nebo s Mozillou/IE pod Windows) nehrozí žádné nebezpečí, pod Linuxem s Mozillou/FireFoxem a 256 MB RAM+128 MB swapem to ale končí špatně... P.S.: Ta stránka obsahuje jen 96 PNG obrázků s celkovou velikostí cca 2,5 MB.
/sbin/sysctl -p
. Takže se tím neřeší nic... Nebylo by od věci si ten overcommit zakázat rovnou ve zdrojácích jádra :cat /etc/init.d/procps.sh | grep sysctl # /etc/init.d/procps: Set kernel variables from /etc/sysctl.conf [ -x /sbin/sysctl ] || exit 0 if [ ! -r /etc/sysctl.conf ] eval "/sbin/sysctl $n -q -p $redir"