Boudhayan "bbhtt" Bhattcharya v článku Uzavření kapitoly o OpenH264 vysvětluje, proč bylo OpenH264 odstraněno z Freedesktop SDK.
Představeny byly nové verze AI modelů: DeepSeek V3-0324, Google Gemini 2.5 a OpenAI 4o Image Generation.
XZ Utils (Wikipedie) byly vydány ve verzi 5.8.0. Jedná se o první větší vydání od backdooru v XZ v loňském roce.
Byla vydána nová verze 0.40.0 multimediálního přehrávače mpv (Wikipedie) vycházejícího z přehrávačů MPlayer a mplayer2. Přehled novinek, změn a oprav na GitHubu. Požadován je FFmpeg 6.1 nebo novější a také libplacebo 6.338.2 nebo novější.
Byla vydána nová verze 2.20 svobodného video editoru Flowblade (GitHub, Wikipedie). Přehled novinek v poznámkách k vydání. Videoukázky funkcí Flowblade na Vimeu. Instalovat lze také z Flathubu.
LibrePCB, tj. svobodný multiplatformní softwarový nástroj pro návrh desek plošných spojů (PCB), byl vydán ve verzi 1.3.0. Přehled novinek v příspěvku na blogu a v aktualizované dokumentaci. Vypíchnut je interaktivní HTML BOM (Bill of Materials) a počáteční podpora Rustu. Zdrojové kódy LibrePCB jsou k dispozici na GitHubu pod licencí GPLv3.
Minulý měsíc Hector "marcan" Martin skončil jako upstream vývojář linuxového jádra i jako vedoucí projektu Asahi Linux. Vývoj Asahi Linuxu, tj. Linuxu pro Apple Silicon, ale pokračuje dál. Byl publikován březnový přehled dění a novinek z vývoje. Vývojáře lze podpořit na Open Collective.
Ruská firma Operation Zero nabízí až $4 miliony za funkčí exploit komunikační platformy Telegram. Nabídku učinila na platformě X. Firma je známá prodejem exploitů ruské vládě a soukromým společnostem. Další informace na securityweek.com.
Po 9 týdnech vývoje od vydání Linuxu 6.13 oznámil Linus Torvalds vydání Linuxu 6.14. Proč až v pondělí? V neděli prostě zapomněl :-). Přehled novinek a vylepšení na LWN.net: první a druhá polovina začleňovacího okna a Linux Kernel Newbies.
Konference LinuxDays 2025 proběhne o víkendu 4. a 5. října v Praze v areálu ČVUT v Dejvicích na FIT.
Tak mne dnes napadlo položit dotaz k něčemu, co už dlouho přehlížím. Na jedno starší PC s Celeronem a 256 MiB RAM jsem nainstaloval FreeBSD a trochu si hrál. Pootevíral jsem pár aplikací a koukal, že systém má stále stejné odezvy, nijak nezpomalil, tak jsem kouknul, kde je o tolik úspornější ve spotřebě paměti, než Linux. Nijak úspornější nebyl. Vesele swapoval a vůbec to na něm nebylo poznat. Podobně nepoznám, když používají swap Windows.
Doma problém nemám, mám 4 GiB RAM, ale v práci mám jedno 2jádro s 512 MiB RAM, na něm Linux, ale pokud si něco odloží do swapu, systém šíleně zpomalí. Opravdu šíleně. Takže po každé akci, kdy se tak stane, spouštím swapoff -a
a swapon -a
, aby byl ten počítač zase použitelný.
Otázka zní: dá se to nějak pozitivně ovlivnit, nebo je to prostě špatná vlastnost?
Pokud jde o moment, kdy právě v ten okamžik systém swapuje a systém se zpomalí, tak by to šlo asi vyřešit nějakou prioritouTohle mne vůbec netrápí, s tím se musí počítat. Kde nic není, ani smrt nebere…
Pokud jde o zpomalení dlouhodobé, pokud je něco odloženo ve swapuTo je ten problém.
Když má někdo problém, tak v diskuzi píšou lidi že jim to jde v pohodě, i když očividně to jiným nejdeJj, to je výstižné
Ale proč je to pomalé při používání swapuProtože je disk pomalý. Hlavní problém je, proč něco čte ze swapu, když by asi měl mít dost místa v RAM.
proč něco čte ze swapu, když by asi měl mít dost místa v RAMNe "asi", ale určitě. Samozřejmě, že v okamžiku, kdy tam něco odloží, mu to místo chybí. To je v pořádku. Jenže potom ta nenažraná aplikace skončí, místo se uvolní, ale systém zůstane zpomalený, dokud ručně nevyčistím swap. A právě u toho FreeBSD jsem koukal, že mám ve swapu tolik dat, že by se ani do RAM nevešly, a přesto to nebylo na odezvách systému znát - asi dokáže lépe zhodnotit, co do swapu přesunout.
free
, vmstat
, iostat
, slabtop
?
Asi pred rokom az rokom a pol som si vsimol zmenu spravania linuxu pri vytahovani veci zo swapu. Swap sa neuvolni (podla grafu v taskbare). Matne si spominam, ze je to feature a nie bug a to taka, ze v tomto pripade je v swape je kopia toho co v RAM. V pripade, ze sa casom zasu bude musiet odkladat na swap a zase sa vyberu stranky, ktore tam uz raz boli a nezmenili sa medzitym, tak sa len v uvolnia z pamate, v swape zase oznacia za platne a usetrili sme pisanie na disk. V pripade, ze ktorakolvek podmienka nevyhovie, tak sme tam, kde sme boli pred 2 rokmi a normalne sa odswapuje. To je podla mna vysvetlenim, ze vecne zaplneneho a neuvolnovaneho swapu.To by dávalo smysl, pokud by byl zaplněný swap, ale data dostupná z RAM se četla z RAM. Ale v tomto případě se data zřejmě čtou z disku, takže v RAM asi nejsou.
Tvojim cielom nie je mat zapratanu RAMku a prazdny swap, ale co najrychlejsi pocitac. Obavam sa, ze liecis priznaky (a to este blbo) a nie pricinu.No jo, jenže já jsem ty příznaky nezačal "léčit" z dlouhé chvíle, ale právě proto, že systém si udělal velkou diskovou cache, zbývalo mu ještě asi 50 MiB volném RAMky, on si jí ale část odswapoval a zpomalil. Kdyby to nedělal, nikdy bych na swappiness nesahal
Diskova cache nie je zlo.To já vím a opak netvrdím :)
par moznych dovodov:
zmensenie swappines v tomto pripade zice mozno problem trocha oddiali, ale nasledne zhorsi.No, to je možné
Moje tipyDíky za tipy, i když některé z nich bude asi potřeba udělat u každého uživatele samostatně. Pokud by to zde ještě někdo četl a chtěl vědět ty parametry Opery, jsou zde. Místo KDE jim nic jiného dát nemohu. Pro některé je i KDE příliš složité na ovládání. Natož aby hledali připojený flash disk někde jinde
opera -help
. Pre Operu existuju subory /etc/opera6rc a /etc/opera6rc.fixed. Kde prvy su nastavenia predefinovatelne uzivatelmi a ten druhy su veci natvrdo nastavene uzivatelom bez moznosti odmietnutia. Mozno nieco podobne bude existovat aj pre ine programy.
strace opera 2>&1 | grep "open.*/etc"Podobne by sli preklepnut ostatne programy, ci nemaju nejaky utajeny globalny konfigurak.
strace -eopen
. Potom se bude trasovat jenom otevírání, takhle se tracují i systémová volání atd.
No jo, jenže já jsem ty příznaky nezačal "léčit" z dlouhé chvíle, ale právě proto, že systém si udělal velkou diskovou cache, zbývalo mu ještě asi 50 MiB volném RAMky, on si jí ale část odswapoval a zpomalil. Kdyby to nedělal, nikdy bych na swappiness nesahalTo může být ale právě ten problém. Systém nepotřebuje tolik dat v RAM, ale zato potřebuje číst soubory z disku -- normálně by část nepoužívané RAM odswapoval a volnou kapacitu použil pro diskovou cache. Tím by se celý systém zrychlil. Vy mu ale tohle zakážete, a systém pak musí data načítat z disku. Právě proto jsem psal, že zpomalení nemusí být problém tahání dat ze swapu místo z RAM, ale že z nějakého důvodu tahá data z disku. Kdybychom alespoň věděli, o aplikace jakého druhu se jedná, mohli bychom to zkoumat víc -- pokud ten zpomalený systém nemá žádný důvod přistupovat k souborům na disku, ta moje teorie samozřejmě nemá smysl.
Tiskni
Sdílej: