V Bolzanu probíhá konference SFSCON (South Tyrol Free Software Conference). Jean-Baptiste Kempf, zakladatel a prezident VideoLAN a klíčový vývojář VLC media playeru, byl na ní oceněn cenou European SFS Award 2025 udělovanou Free Software Foundation Europe (FSFE) a Linux User Group Bolzano‑Bozen (LUGBZ).
Open-source minimalistický trackball Ploopy Nano byl po modelech modelech Classic a Thumb Trackball také aktualizován. Nová verze Nano 2 používá optický senzor PAW3222 a k původně beztlačítkovému designu přidává jedno tlačítko, které ve výchozí konfiguraci firmwaru QMK přepíná režim posouvání koulí. Sestavený trackball nyní vyjde na 60 kanadských dolarů (bez dopravy a DPH).
Github publikoval Octoverse 2025 (YouTube), tj. každoroční přehled o stavu open source a veřejných softwarových projektů na GitHubu. Každou sekundu se připojil více než jeden nový vývojář. Nejpoužívanějším programovacím jazykem se stal TypeScript.
Kit je nový maskot webového prohlížeče Firefox.
Mastodon (Wikipedie) - sociální síť, která není na prodej - byl vydán ve verzi 4.5. Přehled novinek s náhledy v oznámení na blogu.
Německo zvažuje, že zaplatí místním telekomunikačním operátorům včetně Deutsche Telekom, aby nahradili zařízení od čínské firmy Huawei. Náklady na výměnu by mohly přesáhnout dvě miliardy eur (bezmála 49 miliard Kč). Jeden scénář počítá s tím, že vláda na tento záměr použije prostředky určené na obranu či infrastrukturu.
Po dvaceti letech skončil leader japonské SUMO (SUpport.MOzilla.org) komunity Marsf. Důvodem bylo nasazení sumobota, který nedodržuje nastavené postupy a hrubě zasahuje do překladů i archivů. Marsf zároveň zakázal použití svých příspěvků a dat k učení sumobota a AI a požádal o vyřazení svých dat ze všech učebních dat.
Úřad pro ochranu hospodářské soutěže zahajuje sektorové šetření v oblasti mobilních telekomunikačních služeb poskytovaných domácnostem v České republice. Z poznatků získaných na základě prvotní analýzy provedené ve spolupráci s Českým telekomunikačním úřadem (ČTÚ) ÚOHS zjistil, že vzájemné vztahy mezi operátory je zapotřebí detailněji prověřit kvůli možné nefunkčnosti některých aspektů konkurence na trzích, na nichž roste tržní podíl klíčových hráčů a naopak klesá význam nezávislých virtuálních operátorů.
Různé audity bezpečnostních systémů pařížského muzea Louvre odhalily závažné problémy v oblasti kybernetické bezpečnosti a tyto problémy přetrvávaly déle než deset let. Jeden z těchto auditů, který v roce 2014 provedla francouzská národní agentura pro kybernetickou bezpečnost, například ukázal, že heslo do kamerového systému muzea bylo „Louvre“. 😀
Z upstreamu GNOME Mutter byl zcela odstraněn backend X11. GNOME 50 tedy poběží už pouze nad Waylandem. Aplikace pro X11 budou využívat XWayland.
Ř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
cat /proc/PID/maps
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:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz