Řada vestavěných počítačových desek a vývojových platforem NVIDIA Jetson se rozrostla o NVIDIA Jetson Thor. Ve srovnání se svým předchůdcem NVIDIA Jetson Orin nabízí 7,5krát vyšší výpočetní výkon umělé inteligence a 3,5krát vyšší energetickou účinnost. Softwarový stack NVIDIA JetPack 7 je založen na Ubuntu 24.04 LTS.
Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) spolu s NSA a dalšími americkými úřady upozorňuje (en) na čínského aktéra Salt Typhoon, který kompromituje sítě po celém světě.
Společnost Framework Computer představila (YouTube) nový výkonnější Framework Laptop 16. Rozhodnou se lze například pro procesor Ryzen AI 9 HX 370 a grafickou kartu NVIDIA GeForce RTX 5070.
Google oznamuje, že na „certifikovaných“ zařízeních s Androidem omezí instalaci aplikací (včetně „sideloadingu“) tak, že bude vyžadovat, aby aplikace byly podepsány centrálně registrovanými vývojáři s ověřenou identitou. Tato politika bude implementována během roku 2026 ve vybraných zemích (jihovýchodní Asie, Brazílie) a od roku 2027 celosvětově.
Byla vydána nová verze 21.1.0, tj. první stabilní verze z nové řady 21.1.x, překladačové infrastruktury LLVM (Wikipedie). Přehled novinek v poznámkách k vydání: LLVM, Clang, LLD, Extra Clang Tools a Libc++.
Alyssa Anne Rosenzweig v příspěvku na svém blogu oznámila, že opustila Asahi Linux a nastoupila do Intelu. Místo Apple M1 a M2 se bude věnovat architektuře Intel Xe-HPG.
EU chce (pořád) skenovat soukromé zprávy a fotografie. Návrh "Chat Control" by nařídil skenování všech soukromých digitálních komunikací, včetně šifrovaných zpráv a fotografií.
Byly publikovány fotografie a všechny videozáznamy z Python konference PyCon US 2025 proběhlé v květnu.
Společnost xAI a sociální síť X amerického miliardáře Elona Muska zažalovaly firmy Apple a OpenAI. Viní je z nezákonné konspirace s cílem potlačit konkurenci v oblasti umělé inteligence (AI).
Byla vydána nová verze 9.16 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání.
ž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: