Byl vydán Mozilla Firefox 152.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 152 bude brzy k dispozici také na Flathubu a Snapcraftu.
Desktopové prostředí KDE Plasma bylo vydáno ve verzi 6.7 (Mastodon). Přehled novinek i s videi a se snímky obrazovek v oficiálním oznámení. Podrobný přehled v seznamu změn.
Hříčka xsnow, která na ploše spustí sněžení, je protestware. Pokud jste v Rusku (LANG=ru), zobrazuje ukrajinské vlajky.
UBports, nadace a komunita kolem Ubuntu pro telefony a tablety Ubuntu Touch, vydala beta verzi Ubuntu Touch 24.04-2.0. Nová verze již počítá s výřezy pro fotoaparát (notch) a zaoblenými rohy displeje. Webový prohlížeče Morph přešel z Chromia 87 na Chromium 134. Do shellu Lomiri byl přidán editor snímků obrazovky.
V Praze probíhá Flock 2026, tj. konference pro přispěvatele a příznivce Fedory. Přednášky lze sledovat také na YouTube.
Node-RED (Wikipedie, GitHub), webová aplikace postavená na Node.js pro vizuální programování a propojování hardwarových zařízení, API a online služeb, byl vydán ve verzi 5.0. Přehled novinek v příspěvku na blogu.
Byla vydána nová verze 3.27.0 FreeRDP, tj. svobodné implementace protokolu RDP (Remote Desktop Protocol). Opraveno bylo 5 zranitelností.
Řídící výbor GCC schválil záměr do GCC začlenit backend WebAssembly.
Po 9 týdnech vývoje od vydání Linuxu 7.0 oznámil Linus Torvalds vydání Linuxu 7.1. Přehled novinek a vylepšení na LWN.net: první a druhá polovina začleňovacího okna a časem také na Linux Kernel Newbies.
Cheat Engine (Wikipedie) je s verzí 7.7 k dispozici už také pro Linux. Jedná se o proprietární skener/debugger paměti používaný především k cheatování v počítačových hrách.
Musím se předem přiznat, že s monitorováním RAM a disku moc zkušeností nemám, ale o zatížení CPU něco vím. Takže se ve své odpovědi omezím na CPU a snad objasním aspoň z malé části, jak se to dá monitorovat.
Jednoduchá odpověď je „v /proc/[pid]/stat“, ale zkusím to trochu rozvést. Tady je jednoduchý load monitor, který se dá rovnou spustit a vyzkoušet:
(
# Vyrobíme nějaký proces k monitorování.
(for ((;;)); do stress -c 1 -t 1; sleep 1; done >/dev/null;) &
# Poznamenáme si, který proces to byl a že ho máme zabít.
trap 'kill "$PID"' EXIT
PID="$!"
# Naprogramujeme výpočet vytížení procesoru v awk.
AWK_SCRIPT='
BEGIN {
getconf = "getconf CLK_TCK"
getconf | getline TCK
close(getconf)
}
{
uspace = $14
kernel = $15
kids_uspace = $16
kids_kernel = $17
kvm_uspace = $43
kvm_kernel = $44
total_ticks = uspace + kernel + kids_uspace + kids_kernel
kvm_ticks = kvm_uspace + kvm_kernel
}
NR > 1 {
print (100 * (total_ticks - last_total_ticks) / TCK) "% total,",
(100 * (kvm_ticks - last_kvm_ticks) / TCK) "% in KVM"
}
{
last_total_ticks = total_ticks
last_kvm_ticks = kvm_ticks
}'
# Každou sekundu načteme statistiky vytížení procesoru do awk.
for ((i = 0; i < 20; ++i)); do
cat "/proc/${PID}/stat"
sleep 1
done | awk "$AWK_SCRIPT"
)
Co tohle dělá, v kostce:
stressuje jeden procesor na 100%. Poznamená si to PID toho subshellu (nikoliv však PID stressu ani PID jednoho dalšího potomka, kterého stress zplodí).awk čte informace o tom, kolik tiků příslušný proces spotřeboval od minulého čtení (před sekundou) a na základě toho ukazuje vytížení procesoru v procentech. Protože stress nic nevirtualizuje, bude druhá vypisovaná hodnota v tomto případě vždycky nula. Protože děti toho shellu, jehož PID sledujeme, vždy jednu sekundu stressují a jednu sekundu spí, právě tomu bude odpovídat první vypisovaná hodnota. Co znamenají které hodnoty v daném /proc/[pid]/stat souboru nebo v globálním /proc/stat souboru, se dá snadno nalézt v man 5 proc.stress -c 3, bude chvílemi ukazovat například vytížení 300%. To je zcela normální a očekávaný jev. Aby člověk získal hodnotu od 0 do 100%, musí to normalizovat třeba počtem virtuálních procesorů toho KVM.Ke KVM musím dodat, že se mi teď zrovna nechce logovat na některý z mých KVM serverů a tudíž jsem hodnoty typu kvm_ticks ani náznakem neotestoval. Takže tam můžu mít celkem značnou spoustu chyb jak ve sloupcích, které dané hodnoty obsahují, tak i v jejich interpretaci.
To už si musíš dořešit. Každopádně manuálová stránka říká, že hodnoty pro virtualizaci, tedy kvm_uspace a kvm_kernel, jsou už zahrnuté v hodnotách pro děti daného procesu (kids_uspace a kids_kernel), takže není radno všech šest políček sečíst. První dvě plně stačí pro procesy bez dětí, druhá dvě je třeba přičíst, když je to (jako v tomto případě) nějaký shell nebo stress s potomky a ta poslední dvě jsou asi tou slibovanou třetinou odpovědi na tvou otázku — udávají, kolik se strávilo virtualizací. Ovšem pokud někomu počítáš vytížení jeho KVM stroje, podle mě bys měl počítat všechny userspace + kernel + kvm_uspace + kvm_kernel tiky daného KVM procesu, protože to, co proces virtuálního stroje dělá mimo virtuální stroj (údržbu kdovíčeho, mapování paměti, přístupy k disku a k virtuálním zařízením všeho druhu atd. atp.), by se rozhodně mělo taky „účtovat“ tomu klientovi. Děje se to přece kvůli podpoře běhu toho příslušného virtuálního stroje a že při tom procesor není zrovna ve virtualizačním režimu a nevykonává přímo instrukce toho KVM, to není až tak rozhodující.
Tiskni
Sdílej: