Na crowdsourcingové platformě Crowd Supply byla spuštěna kampaň na podporu open source biometrického monitoru ve tvaru hodinek HealthyPi Move. Cena je 249 dolarů a plánovaný termín dodání listopad letošního roku.
Firma Murena představila /e/OS verze 2.0. Jde o alternativní sestavení Androidu bez aplikací Google. Mezi novinkami je podrobnější nastavení ochrany soukromí před sledováním aplikacemi. Murena prodává několik smartphonů s předinstalovaným /e/OS (Fairphone, repasovaný Google Pixel 5).
Do 30. května lze v rámci akce Warhammer Skulls 2024 získat na Steamu zdarma hru Warhammer 40,000: Gladius - Relics of War.
HelenOS (Wikipedie), tj. svobodný operační systém českého původu založený na architektuře mikrojádra, byl vydán ve verzi 0.14.1. Přehled novinek v poznámkách k vydání. Vypíchnou lze nabídku Start. Videopředstavení na YouTube.
BreadboardOS je firmware pro Raspberry Pi Pico (RP2040) umožňující s tímto MCU komunikovat pomocí řádkového rozhraní (CLI). Využívá FreeRTOS a Microshell.
Vývojáři KDE oznámili vydání balíku aplikací KDE Gear 24.05. Přehled novinek i s náhledy a videi v oficiálním oznámení. Do balíku se dostalo 5 nových aplikací: Audex, Accessibility Inspector, Francis, Kalm a Skladnik.
Byla vydána (𝕏) nová verze 18.0.0 open source webového aplikačního frameworku Angular (Wikipedie). Přehled novinek v příspěvku na blogu.
V neděli 26. května lze navštívit Maker Faire Rychnov nad Kněžnou, festival plný workshopů, interaktivních činností a především nadšených a zvídavých lidí.
Byla vydána nová stabilní verze 3.20.0, tj. první z nové řady 3.20, minimalistické linuxové distribuce zaměřené na bezpečnost Alpine Linux (Wikipedie) postavené na standardní knihovně jazyka C musl libc a BusyBoxu. Z novinek lze vypíchnou počáteční podporu 64bitové architektury RISC-V.
že ty jako budeš mit dualboot?? ;D
V poslední době jsem se bavil s několika linuxáky i windowsáky o memory managementu a zjistil jsem, že obě strany se docela dobře vyznají, jak to funguje v „jejich“ systémuNa něco podobného jsem narazil taky. Známej, co tvoří programy snad ve Visual Basicu (jsem ani nevěděl, že to dneska ještě existuje), takže dalo by se říct takovej power user, a pokecali jsme a téma padlo i na memory management a celkem mě překvapil. Diskuse kolem overcommit a ballooning ve vm (v jeho podání hyper-v) apod. Chytal se. Jinak je nějaký důvod, proč je to ve widlích navrženo takto složitě? Tohle je poněkolikáté, co se setkávám s tím, že ve widlích je něco takto komplexního (příkladem budiž třeba NTFS, které už v době NT 4.0 umělo hardlinky i linky na adresář, ale začalo se používat snad až ve W7). Nevím, jestli Windows pořád návrhově míří na nějaké ultrasuperpočítače, ale pořád jsou zaseklí na desktopech, kde je to vlastně kontraproduktivní.
LRUJsem to jen já, nebo i ostatním tyhle simple přístupy vyhovují nejvíc? Ve widlích io cache (pro můj workflow) nefunguje. Nebo nefunguje vůbec. I před chvílí čtený soubor se čte opět. Všímám si toho i ve hrách, kdy i přes dostatek volné ram, kam by se vešly všechny datové soubory hry, se neustále čte z disku. V linuxu, i přes jednoduchost lru, se na disk po určitém čase chodí jen pro zápisy. (Tentýž problém v bledě modrém i ARC na ZFS na FreeBSD. Je to tak adaptive, že to vyhodí stránky zrovna těsně před tím, než je opět potřebuju.)
Je to tak adaptive, že to vyhodí stránky zrovna těsně před tím, než je opět potřebuju.
Tomu říkám "problém screensaveru". Ideální screensaver by neměl o zhasínání obrazovky rozhodovat podle doby od posledního stisku klávesy nebo pohybu myši, ale podle doby do příštího. :-)
Mě spíše fascinuje, že už jsou tu 2 příspěvky, které hodnotí algoritmy Windows podle her.To má poměrně jednoduché vysvětlení, dual boot mám už jen pro hry. Posledního pracovního programu na win jsem se zbavil před několika měsíci. Navíc je jedno, jaký typ appky si daný soubor otevře. IO cache by měla zafungoval stejně.
Co jsem se kdy setkal, tak každá počítačová hra je napsaná jako největší prasárna.I kdyby to snad byla pravda, tak to nic nemění na stavu io cache. Pokud si 32b hra vezme svých max 3GB, její datové soubory mají 16GB a stroj má volné paměti několikrát tolik, tak je podivné, že se datové soubory pokaždé čtou z disku a nikoliv už z OS io cache. (A ano, existují flagy, aby se daný soubor necachoval, ale nevěřím tomu, že se toto používá tak často. U těch, podle vás "prasáren", bych spíše očekával, že vývojáři takové detaily nebudou řešit vůbec.)
cat soubor > /dev/null
ten soubor bude v io cache. Občas toho využívám jako "prefetch". Bohužel tuhle jistotu už vůbec nemám třeba na FreeBSD s ZFS ARC, kde ani opakované (klidně i 15x) čtení nepřinutí ARC si to zapamatovat. A na widlích si už ani netipuju (ale tam nemám potřebu dělat systémové prográmky nebo skripty, takže mě to až tak netankuje).
Na linuxu mám, na systému s dostatkem volné paměti, jistotu, že po cat soubor > /dev/null
ten soubor bude v io cache.
To není s dostatečně novými jádry tak úplně pravda. Před časem jsem to tu psal; pokud už je page cache "plná", typicky až třetí čtení souboru jde z cache, druhé je ještě pomalé.
fd = open(argv[1], O_RDONLY); addr = mmap(NULL, length + offset - pa_offset, PROT_READ, MAP_PRIVATE, fd, pa_offset); s = write(STDOUT_FILENO, addr + offset - pa_offset, length); munmap(addr, length + offset - pa_offset); close(fd);Při použití
mmtest soubor 0 | pv > /dev/null
to nacachovalo soubor. Důvod, proč jsem tam zařadil pv
je ten, že při obyčejném přesměrování mmtest ... > /dev/null
to nic neudělalo (hádám, že to poznalo, že výstup je null; což se mi opět nelíbí). Následné čtení souboru i jinými metodami potvrdilo, že soubor je skutečně v cache. (zpool iostat
, rychlost překračující možnou rychlosti disku)
při obyčejném přesměrování mmtest ... > /dev/null
to nic neudělalo (hádám, že to poznalo, že výstup je null; což se mi opět nelíbí)
Nechce se mi to dohledávat, abych se ujistil, ale IMHO by bylo docela logické, že se v takovém případě ze souboru nebude vůbec číst. Nammapovaný soubor je pro systém prostě jen kus (virtuální) paměti a teprve když se z příslušných stránek něco zkusí přečíst, vyvolá se pagefault, handler zjistí, že je to mmap a potřebná data načte z filesystému. V tomhle případě ale write()
v důsledku povede na odpovídající metodu blokového zařízení /dev/null
, která velmi pravděpodobně ten blok, který dostane, vůbec číst nebude (proč taky) a jenom vrátí příslušnou délku, čímž oznámí, že se data úspěšně zapsala. Takže se žádný pagefault nekoná a vůbec se nepozná, že to byl kus mmapovaného souboru a ne obyčejný kus paměti.
Windows mají i serverové variantyTo samozřejmě vím.
a tam se ten "složitý návrh" může hoditOčekával bych nějaký příklad. Neříkám, že se hodit nemůže, ale co potkávám windowsáky vývojáře, tak u nich mnohem víc platí (i když už to přestává být tak silné jako dřív) "umlátíme to větším železem". A navíc jim hw za pár mega nepřijde nic přehnaného, protože za licence zaplatí mnohem víc. A když k nim přijdu s tím, že to celé by mohlo běžet na hw o čtvrtinovém výkonu a licence 0Kč, tak se na mě dívají, jak kdybych spadl z Marsu. Standard je MSSQL, pokud ne rovnou Oracle, k tomu superrychlé pole a pár mega za licence. Nějak mi nepřijde, že by se někde používal ten sofistikovanější návrh Windows.
Pokusů udělat OOM killer (nebo page reclaim) chytřejším byla spousta a soudě podle občasného nadávání kolegy sedícího ob dva stoly se stále objevují další, které v lepším případě sice zlepší chování v tom specifickém use case, kterým jsou motivovány, ale obvykle za cenu zhoršení jinde.
Pokud se někomu overcommit nelíbí, může ho vypnout. Otázkou ale je, nakolik je to rozumné po tolika letech, kdy se userspace aplikace píší s vědomím, že overcommit tu prostě je, takže není důvod si hned po startu nenamapovat hromadu paměti, co kdyby se někdy hodila. Zkusil jsem se trochu porozhlédnout po systému, u kterého zrovna sedím (destktop, uptime 2.5 dne):
Všechny ty procesy běží celou dobu a kromě firefoxu není pravděpodobné, že by jejich skutečné nároky na fyzickou paměť nějak zásadně narostly.
Pokud je nějaký proces pro systém důležitý (podle okolností to může být třeba sshd nebo X server), lze ho před OOM celkem spolehlivě ochránit nastavením /proc/*/oom_{,score_}adj
Hezké srovnání.
V článku i diskuzi mě zaujaly narážky na "debilní programátory", který nedokážou využít volnou paměť. A celkem by mě zajímalo, jak si tedy představujete, že by aplikace měla postupovat, když běžná metoda vyhradit pro cache nějakou "rozumnou", fixně omezenou velikost je zcela špatně? Má se zjistit velikost fyzické paměti a podle ní nastavit ten limit? Nebo velikost aktuálně volné paměti? Stroj sice může mít 32GB, ale co když uživatel bude chtít mít s mojí aplikací spuštěné zároveň dvě další aplikace v elektronu? Nebo obráceně, co když měl tyto dvě elektronové aplikace spuštěné v době mé alokace, ale poté je zavře? Nemluvě o tom, že první "expert", co uvidí, že mu ta aplikace "žere" 30GB paměti jí udělá takovou "reklamu", že i Horst Fuchs (Ví Gréta, kdo je (byl - žije ještě vůbec?) Horst Fuchs?) bude blednout závistí?!
Tak Horst, zdá se, žije, ale "Die WS Teleshop International Handels-GmbH aus Wiener Neudorf ist pleite." (2007). Prej za to může internet.
Byl bych se ochotný hádat, že to v článku bylo (vlevo dole), ale teď to tam nemůžu najít. Takže je to asi jenom v diskuzi. Ale pointa zůstává.
Tiskni Sdílej: