Byli vyhlášeni vítězové ocenění Steam Awards 2025. Hrou roku a současně nejlepší hrou, která vám nejde, je Hollow Knight: Silksong.
Byla vydána nová verze 26.0 linuxové distribuce Manjaro (Wikipedie). Její kódové jméno je Anh-Linh. Ke stažení je v edicích GNOME, KDE PLASMA a XFCE.
Jednotný seznam blokovaných internetových stránek vedený Českým telekomunikační úřadem obsahoval také Český telekomunikační úřad.
Byl představen webový prohlížeč Brow6el, běžící v terminálu. Pro prohlížení webu je využit Chromium Embedded Framework, vyrendrovaná webová stránka je následně zobrazena v terminálu převodem na sixely pomocí knihovny libsixel. Brow6el se ovládá modálním klávesnicovým rozhraním, inspirovaném populárním textovým editorem Vim. Demonstrační video s ukázkou používání.
Společnost Pebble představila (YouTube) chytré hodinky Pebble Round 2. S kulatým e-paper displejem, s open source PebbleOS a vydrží baterie přibližně dva týdny. Předobjednat je lze za 199 dolarů s plánovaným dodáním v květnu.
Na novoroční inauguraci starosty New Yorku Zohrana Mamdaniho bylo zakázáno si s sebou přinést Raspberry Pi anebo Flipper Zero. Raspberry Pi i Flipper Zero jsou explicitně uvedeny v seznamu zakázaných věcí jak na na veřejné pozvánce, tak i na oficiálních stránkách města.
OpenTTD (Wikipedie), tj. open source klon počítačové hry Transport Tycoon Deluxe, byl vydán v nové stabilní verzi 15.0. Přehled novinek v seznamu změn a také na YouTube. OpenTTD lze instalovat také ze Steamu.
Správce oken IceWM byl vydán ve verzi 4.0.0, která např. vylepšuje navigaci v přepínání velkého množství otevřených oken.
Od 1. ledna 2026 jsou všechny publikace ACM (Association for Computing Machinery) a související materiály přístupné v její digitální knihovně. V rámci této změny je nyní digitální knihovna ACM nabízena ve dvou verzích: v základní verzi zdarma, která poskytuje otevřený přístup ke všem publikovaným výzkumům ACM, a v prémiové zpoplatněné verzi, která nabízí další služby a nástroje 'určené pro hlubší analýzu, objevování a organizační využití'.
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: