Farid Abdelnour se v příspěvku na blogu rozepsal o novinkám v nejnovější verzi 26.08.0 editoru videa Kdenlive (Wikipedie). Ke stažení také na Flathubu.
Byla vydána nová stabilní verze 8.2 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 152. Přehled novinek i s náhledy v příspěvku na blogu.
Byla vydána nová stabilní verze 4.0 svobodného multiplatformního softwaru pro editování a nahrávání zvukových souborů Audacity (Wikipedie). S rozhraním přepsaným do Qt. Přehled novinek také na YouTube. Ke stažení je oficiální AppImage. Zatím starší verze Audacity lze instalovat také z Flathubu a Snapcraftu.
NVIDIA kupuje Hugging Face za 12,93 miliardy dolarů.
Předobjednat si lze nový jednodeskový počítač Arduino VENTUNO Q s předinstalovaným Ubuntu. S 16 GB LPDDR5 a 64 GB eMMC. Pro lokální LLM, agentní AI, počítačové vidění, robotiku…
Hexpair není nejlepší HEX editor na světě a ani se o to nesnaží. Zato je k dispozici kdykoliv a kdekoliv – všude tam, kde máte svůj Vim. Vznikl jako hobby projekt před pár měsíci a dospěl do stavu, kdy by mohl být užitečný širší komunitě. Přepnout do HEX režimu se dá i uprostřed rozdělané práce: Soubor, který už máte otevřený běžným vim file.md, jedním příkazem přepnete do HEX editoru a dalším příkazem ho můžete vrátit zpět do textu. Kurzor přitom
CERN dlouhodobě používal vlastní sestavení RHEL, ze kterého přešel na CentOS Stream. Federico Vaga a Nikos Tsipinakis ale nyní v přednášce na MiniDebConf Winterthur 2026 popisují plán probíhajícího přechodu na Debian pro řízení akcelerátorů. Důvodem k opuštění CentOS Stream jsou zachování zpětné kompatibility se starším hardwarem, kterou Red Hat narušuje, když tlačí sestavení balíčků pro novější verze architektury (x86-64), a nedostatečné nástroje pro sestavování vlastních balíčků a repozitářů.
UZDoom (Wikipedie), tj. fork GZDoom, byl vydán ve verzi 5.0.0. Videopředstavení na YouTube. Podrobný přehled novinek v Changelogu.
Příručka Linux From Scratch pro sestavení základního linuxového systému byla aktualizována v pravidelném půlročním termínu. Vydání 13.1 shrnuje přes 40 nových verzí balíčků a několik patchů. Navazující příručka Beyond Linux From Scratch s recepty pro sestavení dalších knihoven a aplikací zatím vydána nebyla, ačkoliv vývojová verze stále dostává aktualizace. Lze je číst online nebo stáhnout v HTML či PDF.
Zdravím,
prosím o radu:
na server (jen v příkazové řádce, na sdílení souborů) přidána paměť (původně 1x 512 MB, nyní 2x 2 GB; swap zatím ponechán tak, jak byl = 1 GB). Zkusil jsem pootevírat ze serveru pár fotek, dokumentů - svištělo to jako nikdy (po tomto využitá paměť cca 15 %). Pak ze serveru zkopírován na jiný poč. soubor o vel. 4 GB - volná paměť se snížila na 2 %, něco málo je zabrané (cca 100 MB), zbytek v cache = cca 3,5 GB (free -m). V tomto okamžiku už je rychlost operací stejná jako za stavu RAM = 512 MB.
Jsem na server připojený pomocí Samby - napadá mě, že i když kopírování skončilo, proces smbd běží dál a paměť se tím pádem neuvolní.
- jádro by si toto mělo samo regulovat - a když ne, existuje na uvolnění paměti nějaký nástroj?
- lze nechat swap 1 GB nebo jej zvýšit na 2 GB (někde jsem se dočetl, že víc se nedoporučuje)?
Díky
HonzaS
Nechápu, v čem je problém. To že se všechna nepotřebná paměť automaticky použije jako cache je normální a žádoucí. Pokud ji nějaký proces chce, tak ji dostane.
Tomu rozumim; nechapu ale, proc v okamziku, kdy velka cast pameti byla jeste volna, tak ze stanic pripojenych na server vse fungovalo rychleji. Po presunuti do cache se vse zpomalilo.
Nebudu to ale resit; pokud to ma tak byt. :) Diky za odpoved.
Jeste ke swapu - je treba jej zvetsit, aby byl minimalne stejne velky jako RAM?
Asi myslíš toto video... Nikdy nekričte na svoj harddisk! 
Treba pomoci prikazu:
top
NN
Diky za odpovedi, hlavne jsem potreboval mit jistotu ohledne swapu, zda jej nezvetsit. Po pravde - nevim, cim to je, ale nyni to bezi znovu vyborne, i kdyz jsem server s pametmi testoval jen ja. Uvidim, co bude zitra s plnou zatezi.
Preji pekny zbytek dne.
i když kopírování skončilo, proces smbd běží dál a paměť se tím pádem neuvolníTo se ale týká pouze paměti, kterou alokuje ten proces, nikoliv cache, kterou využil pro kopírování. Proces se neukončuje z dobrého důvodu a tím je právě rychlost, kdyby měl kvůli každému požadavku nabíhat nový proces, tak se zblázníte. Obecně si myslím, že ať budete mít paměť jakkoliv velkou, tak při dostatečném počtu různých souborů budete nakonec stejně omezen rychlostí disku. Zejména pokud děláte na disk zápisy, a používáte žurnálovací FS, nebo RAID. Velká paměť Vám obecně pouze udělá dobro v tom, že často otevírané soubory pro čtení nemusí být pokaždé nataženy z disku.
Díky za tip, dalším krokem tedy bude pořídit rychlejší disky, což ale bude náročnejší prosadit. :) Jsou tam 2 menší SATA disky (RAID 1) na systém + zálohy a 2 velké (320 GB) IDE disky na zakázky (rovněž RAID 1). Zkusím zjistit, jak moc by se vyplatilo koupit něco rychlejšího.
Nemáte tip - je nějaký nástroj, jak spočítat rychlost čtení zápisu dat v závislosti na veškerém HW? Toto je pro mě španělský venkov. Představoval bych si to tak, že spočítám rychlost při stávajícím HW a běžném zatížení serveru a pak zadám do programu jiný HW (místo IDE disků např. SCSI).
Díky
Můžete tam zkusit spustit benchmark "dbench" v několika procesech, a uděláte si jistou představu, jakou má ten disk s filesysémem propustnost. Pokud nebude stačit, nezbyde než rychlejší disky (např. 10k rpms, případně LVM na několika fyzických zařízeních se stripováním).
Pokud má filesystém dostatečnou propustnost, pak je problém jinde (síť, samba).
Tiskni
Sdílej: