Byla vydána nová verze 4.5 (𝕏, Bluesky, Mastodon) multiplatformního open source herního enginu Godot (Wikipedie, GitHub). Přehled novinek i s náhledy v příspěvku na blogu.
Byla vydána verze 3.0 (Mastodon) nástroje pro záznam a sdílení terminálových sezení asciinema (GitHub). S novou verzí formátu záznamu asciicast v3, podporou live streamingu a především kompletním přepisem z Pythonu do Rustu.
Canonical oznámil, že bude podporovat a distribuovat toolkit NVIDIA CUDA (Wikipedie) v Ubuntu.
Tržní hodnota americké společnosti Alphabet, která je majitelem internetového vyhledávače Google, dnes poprvé překonala hranici tří bilionů dolarů (62,1 bilionu Kč). Alphabet se připojil k malé skupině společností, které tuto hranici pokořily. Jsou mezi nimi zatím americké firmy Nvidia, Microsoft a Apple.
Spojené státy a Čína dosáhly dohody ohledně pokračování populární čínské platformy pro sdílení krátkých videí TikTok v USA. V příspěvku na síti Truth Social to dnes naznačil americký prezident Donald Trump. Dosažení rámcové dohody o TikToku vzápětí oznámil americký ministr financí Scott Bessent, který v Madridu jedná s čínskými představiteli o vzájemných obchodních vztazích mezi USA a Čínou. Bessentova slova později potvrdila také čínská strana.
MKVToolNix, tj. sada nástrojů pro práci s formátem (medialnym kontajnerom) Matroska, byl vydán ve verzi 95.0. Podpora přehrávání formátu Matroska míří do Firefoxu [Bug 1422891, Technický popis]. Přehrávání lze již testovat ve Firefoxu Nightly.
Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 211. sraz, který proběhne v pátek 19. září od 18:00 ve Studentském klubu U Kachničky na Fakultě informačních technologií Vysokého učení technického na adrese Božetěchova 2/1. Na srazu proběhne přednáška Jiřího Eischmanna o nové verzi prostředí GNOME 49. Nemáte-li možnost se zúčastnit osobně, přednáškový blok bude opět streamován živě na server VHSky.cz a následně i zpřístupněn záznam.
Microsoft se vyhnul pokutě od Evropské komise za zneužívání svého dominantního postavení na trhu v souvislosti s aplikací Teams. S komisí se dohodl na závazcích, které slíbil splnit. Unijní exekutivě se nelíbilo, že firma svazuje svůj nástroj pro chatování a videohovory Teams se sadou kancelářských programů Office. Microsoft nyní slíbil jasné oddělení aplikace od kancelářských nástrojů, jako jsou Word, Excel a Outlook. Na Microsoft si
… více »Samba (Wikipedie), svobodná implementace SMB a Active Directory, byla vydána ve verzi 4.23.0. Počínaje verzí Samba 4.23 jsou unixová rozšíření SMB3 ve výchozím nastavení povolena. Přidána byla podpora SMB3 přes QUIC. Nová utilita smb_prometheus_endpoint exportuje metriky ve formátu Prometheus.
Správcovský tým repozitáře F-Droid pro Android sdílí doporučení, jak řešit žádosti o odstranění nelegálního obsahu. Základem je mít nastavené formální procesy, vyhrazenou e-mailovou adresu a být transparentní. Zdůrazňují také důležitost volby jurisdikce (F-Droid je v Nizozemsku).
Řešení dotazu:
Ahoj. Zajímalo by mě, jestli a jak je možné najít v běžícím programu (napsaném např. v C) paměť, na kterou už neukazují žádné ukazatele
Nelze, v C nemas zadny reference counter. Proste si alokujes pamet a je na tobe abys ji uvolnil. Valgrind ti muze vypsat kolikrat se zavolal malloc() a kolikrat se zavolal free(), tim muzes zjistit jestli se vsechno uvolnilo.
Nicméně operační systém ví, kterou paměť má proces alokovanou, takže by to mohlo jít čistě teoreticky zjistit i v běžícím programu, jenže jak?
Obecne to neni pravda. Zalezi na alokatoru.
Funkce typu free() (a podobné, v závislosti na alokátoru) normálně pouze vracejí paměť do heapu procesu, která je z pohledu jádra celá alokovaná tomu procesu.O to mi jde. Zjistit v samotném běžícím programu, jakou všechnu datovou paměť má pro daný proces alokovanou jádro. Pak by čistě teoreticky nebyl problém zjistit, na kterou část paměti už program nemá referenci. Chápu, že je blbost tohle dělat. Zajímá mě to čistě na teoretické úrovni, zda by to šlo naprogramovat.
Hm, dost těžko, adresa v aplikaci není totožná s fyzickou adresou.Hm, dost snadne, adresa v jadre je totozna s adresou v aplikaci
Budete zklamaný. Přiblížím Linux na x86:
Každý proces má vlastní virtuální paměť. Na některá místa jsou mapované různé části kódu procesu (program a knihovny) a na některá samotný Linux. Tohle všechno je v podstatě statická věc jen pro čtení. Ta vás vůbec nezajímá. Pak máte různé bloky se sdílenou pamětí (SHM, I/O), to vás ale také nemusí zajímat (kdyby ano, pak byste se na to tady neptal, protože by to pro vás byla trivialita).
A pak jsou už jen dvě velké oblasti. Halda a zásobník. Haldu si proces voláním brk(2) zvětšuje či zmenšuje, ale nikdy do ní nemůže udělat díry. Vždy se jedná o spojitou oblast. Zásobník roste z druhého konce adresního prostoru proti haldě. Ten ovšem z hlediska jádra je předalokován na konkrétní velikost (ulimit(1)) a z principu x86 ABI taky v něm nemohou být díry a navíc si jeho velikost proces (zjednodušeně vzato) nemůže měnit.
Takže když to shrnu, tak jediný zajímavý údaj je velikost haldy. Tedy jedno číslo. Tedy přesně ten údaj který vidí jádro.
Ten ovšem z hlediska jádra je předalokován na konkrétní velikost (ulimit(1))Zasobnik se zvetsuje dynamicky podle toho, jak je vyuzivan (ulimit pouze omezuje maximalni velikost). Pri startu programu zabira pouze jednu stranku.
Lepší alokátory vůbec nepoužívají haldu a veškeré alokace dělají právě přes mmapy, právě protože je lze snadno vracet.Spíš overengineered než lepší, protože to je optimalizace na situaci, že se podaří současně uvolnit všechny bloky z daného mapování a že aplikace pak nebude zase dlouho potřebovat paměť, kterou by šlo získat recyklováním těchto bloků. Jinak to akorát znamená větší množství syscallů a menší možnost konsolidace volných segmentů. Mluvím o použití haldy typickým způsobem, tj. množství menších až středních alokací ‚náhodných‘ velikosti se slabě korelovanými dobami života.
Tiskni
Sdílej: