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.
Řešení dotazu:
Kupodivu tohle cislo je zajimavejsi nez zatizeni CPU v procentech. %CPU je jen pro manazery :) . Blby je, ze tohle cislo neni absolutni a zavisi na poctu CPU. Podle me "5" na single CPU systemu znamena docela zatizenej system, "20" -> system vubec nestiha. Nejvice jsem videl asi 560 ale to bylo na AIXu. Kazdej admin ma asi zazity jiny konstanty. Dalsi zajimavy cislo je IO Wait protoze tvuj system klidne muze bejt pretizenej a pritom se CPU muze flakat.
Load average konkretne byva klouzavy prumer delky runqueue (zalezi na systemu), neboli tedy zjednodusene kolik procesu by se rado dostalo k lizu na CPU v dane casove jednotce. Neni zavisle na poctu CPU, na tom zavisi threshold, kdy vam velikost runqueue zacne vadit. Spolecne s %CPU a context switches je to dobry ukazatel zamestnanosti vasich CPU. Jednotlive jsou ty hodnoty nejasne a samy o sobe vam o systemu reknou asi tolik, jako pohled pres zavrene okno o tom, jak se obleci (ano, v zime muze take svitit slunicko na krajinu bez snehu, vypada to na triko a je pritom pod nulou, ale to zjistite jen teplomerem nebo otevrenim okna).
Cili -
%CPU (idealne pro jednotliva jadra) vam reknou kolik procent casu se stravilo skutecnou praci. Pokud je to dlouhodobe nad 90%, kouknete na dalsi dve hodnoty a zvazte upgrade/prikoupeni CPU
load vam rekne, kolik bylo pracechtivych. Do 1x pocet_zpracovavajicich_jednotek je to puste flakani CPU. Do 2x PZJ je to na soucasnych procesorech celkem v pohode. 3xPZJ a vice uz je na povazenou a pokud se to casteji opakuje, prohlednete si zbyle dve hodnoty a zvazte prikoupeni/upgrade CPU
context switche (sloupec cs, pripadne csx ve vmstat, napriklad) - ukazuje pocet prepnuti uloh/threadu v danem casovem rozmezi. Prepnuti kontextu s sebou nese nejakou rezii, napriklad ulozeni stavu predchozi ulohy, casto i nutnost vylit cache CPU a nalit do ni data a kod noveho kontextu, a po tu dobu vam CPU nedela nic uzitecneho a nepocita se to do %CPU. Muze tedy dojit i na situaci, kdy mate obrovsky load, ale %CPU treba na 40%, zadne swapovani ani velke IO, a pritom je system jak slimak. V tom pripade se podivejte na cs, bude to asi v tisicich ci desetitisicich a to vam pak ani Power6 nepomuze, protoze bude proste vetsinu casu jen velmi rychle cekat na data z pameti.
PZJ - to je zavisle na architekture. U starych procesoru je to proste procesor. Dnes to ale je slozitejsi, protoze mame vicejardova CPU a jeste muze kazde jadro nabizet vicero vice ci mene paralelnich procesnich jednotek. Napriklad na intelech muzete mit quad-core a kazdy core s HT, takze mate 1 cip, 4 jadra, ale 8 zpracovavajicich jednotek. Pak hodne zalezi na velikosti sdilene cache a na tom, jestli server zpracovava jedny binarky dokola nebo mnoho zcela ruznych. Pak mate SUNovske T2 apod, kde mate 8 jader, kazde s dvema paralelnima pipeline a kazda pipeline ma ctyri sady registru (HW thready), ktere toci dle potreby (nizka rezie prepnuti mezi dvema HW tasky). Tam je tedy PZJ 64, ale musite se pak peclive divat a srovnavat load, csx a %CPU pro jednotlive HW thready, abyste urcil, jestli potrebujete vic CPU nebo jinou architekturu. Kvuli temto vecem vam uz davno nestaci koukat jen na load nebo jen na %CPU.
Zakladni scenare jsou tyto:
Vysoke %CPU a vysoky load - asi chcete vic a rychlejsich CPU. Nezapomente na primerene navyseni pameti, at nezacnete tuhnout na ni nebo na discich.
Vysoke %CPU a nizky load - asi chcete rychlejsi CPU, asi mate malo paralelni nebo vubec neparalelni aplikaci. Holt smula, pripravte si penezenku, asi skoncite u IBM P6. Ostatne s tou chybu neudelate ve vetsine scenaru, pokud tedy na to mate. Mozna vas ale vyjde lepe poohlednout se po softwaru, co dela totez, ale paralelne.
Nizke %CPU a vysoky load - mate asi paralelni provoz, pricemz kazdy thread vyrizuje jen kratke pozadavky nebo ma vysoke IO, takze casto odchazi dobrovolne z CPU. Chcete vic zpracovavajicich jednotek (asi vic CPU, nebo vymenu za vicejadrove), ale pokud mate navic vysoke IO, tak bych asi zkusil nejdrive vice pameti a rychlejsi disky/sit. Kvuli tomuhle delali SUNove svoje T procesory. Tohle byva typicky stav webovych a aplikacnich serveru.
Tolik asi obecna voditka. Jedno slovo nakonec - neverte prosim moc udajum o %Wait. IO Wait uz na mnoha novejsich systemech bud neni nebo je nesmyslny a je to casto i explicitne uvedeno v manualech. Nekde mate dokonce tohle policko proste nastavene natvrdo na 0 a existuje jen kvuli kompatibilite. Kdysi to byvala doba, kterou se cekalo na IO, jenze mame DMA, cache, silne paralelni provozy atd, a to vsechno vec zkresluje natolik, ze je ta postaru merena a pocitana hodnota proste k nicemu, krome tech nejjednodussich pripadu (single-core desktop, mozna 
Ceho je to vystup, program, command?
NN
top.
/proc/loadavg
proc(5):
První tři položky v tomto souboru jsou hodnoty průměrné zátěže (load average) udávající počet úkolů (jobs) čekajících ve frontě na spuštění (stav R) nebo čekajících na čtení/zápis disku (stav D), zprůměrované po 1, 5 a 15 minutách. Jsou to stejné hodnoty, jako poskytuje uptime(1) a další programy. Čtvrté pole se skládá ze dvou čísel oddělených lomítkem (/). První představuje počet současně vykonávaných entit plánovače jádra (procesů, vláken); bude menší nebo rovno počtu CPU. Hodnota za lomítkem je počet entit plánovače jádra, aktuálně přítomných v systému. Páté pole je PID systémem naposledy vytvořeného procesu.
uptime
Ja jsem si udelal vytah z top a posilam to do grafu http://93.91.157.25/2hodiny.html
Tiskni
Sdílej: