Byl publikován aktuální přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie).
V programovacím jazyce Go naprogramovaná webová aplikace pro spolupráci na zdrojových kódech pomocí gitu Forgejo byla vydána ve verzi 12.0 (Mastodon). Forgejo je fork Gitei.
Nová čísla časopisů od nakladatelství Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 155 (pdf) a Hello World 27 (pdf).
Hyprland, tj. kompozitor pro Wayland zaměřený na dláždění okny a zároveň grafické efekty, byl vydán ve verzi 0.50.0. Podrobný přehled novinek na GitHubu.
Patrick Volkerding oznámil před dvaatřiceti lety vydání Slackware Linuxu 1.00. Slackware Linux byl tenkrát k dispozici na 3,5 palcových disketách. Základní systém byl na 13 disketách. Kdo chtěl grafiku, potřeboval dalších 11 disket. Slackware Linux 1.00 byl postaven na Linuxu .99pl11 Alpha, libc 4.4.1, g++ 2.4.5 a XFree86 1.3.
Ministerstvo pro místní rozvoj (MMR) jako první orgán státní správy v Česku spustilo takzvaný „bug bounty“ program pro odhalování bezpečnostních rizik a zranitelných míst ve svých informačních systémech. Za nalezení kritické zranitelnosti nabízí veřejnosti odměnu 1000 eur, v případě vysoké závažnosti je to 500 eur. Program se inspiruje přístupy běžnými v komerčním sektoru nebo ve veřejné sféře v zahraničí.
Vláda dne 16. července 2025 schválila návrh nového jednotného vizuálního stylu státní správy. Vytvořilo jej na základě veřejné soutěže studio Najbrt. Náklady na přípravu návrhu a metodiky činily tři miliony korun. Modernizovaný dvouocasý lev vychází z malého státního znaku. Vizuální styl doprovází originální písmo Czechia Sans.
Vyhledávač DuckDuckGo je podle webu DownDetector od 2:15 SELČ nedostupný. Opět fungovat začal na několik minut zhruba v 15:15. Další služby nesouvisející přímo s vyhledáváním, jako mapy a AI asistent jsou dostupné. Pro některé dotazy během výpadku stále funguje zobrazování například textu z Wikipedie.
Více než 600 aplikací postavených na PHP frameworku Laravel je zranitelných vůči vzdálenému spuštění libovolného kódu. Útočníci mohou zneužít veřejně uniklé konfigurační klíče APP_KEY (např. z GitHubu). Z více než 260 000 APP_KEY získaných z GitHubu bylo ověřeno, že přes 600 aplikací je zranitelných. Zhruba 63 % úniků pochází z .env souborů, které často obsahují i další citlivé údaje (např. přístupové údaje k databázím nebo cloudovým službám).
Open source modální textový editor Helix, inspirovaný editory Vim, Neovim či Kakoune, byl vydán ve verzi 25.07. Přehled novinek se záznamy terminálových sezení v asciinema v oznámení na webu. Detailně v CHANGELOGu na GitHubu.
Co takhle jedno jádro osvobodit a nechat linuxu?To môžem skúsiť.
A 8 je včetně HT?Mno. Tam mi nie je celkom jasno, ale je to asi Dell PowerEdge 1950 a
grep CPU /proc/cpuinfopovie 8x
model name: Intel(R) Xeon(R) CPU E5420 @ 2.50GHzČo sa týka hyper-threading-u:
grep -w ht /proc/cpuinfovypíše
flags ... ht ...Čo je "FP"?
lebo ten procesor má pravdepodobne jedinú FPU.To budem musieť zistiť. Dík za tip. Teraz som si všimol, že /proc/cpuinfo tiež hovorí:
cpu cores : 4 ... fpu : yes
Čo za sakramenský výpočet to je,Z matematického/algoritmického hľadiska sa to nazýva "packing problem" a áno, pracuje so floating point dátami.
že pre každú bežiacu inštanciu je potrebná samostatná inštancia operačného systémuAko to už býva, historicky existuje nejaká implementácia a je do toho zamontovaných mnoho komponentov a nie všetky je možné preportovať na iný OS.
, navyše takého čudného?Sčasti historické dôvody. Sčasti preto, že taký OS je jednoduchý. Na každej ďalšej verzii Windowsov ten OS robí hromadu vecí, ktoré netreba. Keď sa pozriem na zoznam procesov na XP, tak tam nájdem ~10 položiek. Keď sa pozriem na W10, tak ich je tam aj 50 a kvantum úloh, ktoré sa spúšťajú pri nejakej udalosti ...
Skúšali ste vôbec postupný spúšťaním 1, 2, 4 a 8 inštancií, že výpočet skutočne škáluje?To v tomto momente neviem povedať, ale určite sa tým budeme musieť zaoberať.
Vysoká zátěž má určitě vliv na to jak moc často se userspace program (ping) dostane k CPU.To sme sa nerozumeli. Ten ping púšťam na inom stroji než je ten vyťažený neborák. Takže proces ping-u sa k slovu dostane. Ide o to, či ten, kto ten ping paket dostane, odpovie naň ešte v rámci jadra. Reps. ak pingujem ten VM, tak či sa musí dostať k slovu ten VM.
Reps. ak pingujem ten VM, tak či sa musí dostať k slovu ten VM.
Tak moment… celou dobu to vypadalo, že mluvíte o odezvách toho hosta. Tam by to bylo opravdu hodně divné, protože odpověď aby něco takhle zadusilo odpovědi na ICMP echo, muselo by to mít přinejmenším realtime prioritu (a bylo by s podivem, že by vám nezačal nadávat soft lockup detector nebo RCU stall detector.
Jestli se ale bavíme o odezvách těch guestů, tak tam kromě (dvakrát) síťového stacku hosta (Linuxu) hraje roli ještě zpracování ICMP echo guestem, což jsou Windows, takže k tomu nic říct nemůžu.
Ja som to na začiatku nejako explicitne nepovedal. A ani mi to samému nie je 100% jasn0. Len som posunul tak ako som otázku dostal. Skúsim dozistiť podrobnosti, ale nateraz si myslím, že ide o odozvu guest-a. Na druhej strane, nedivil by som sa keby obsluha ping-u bola urobená ak súčasť modulu, ktorý VirtualBox potrebuje v jadre hosta. ... Chcem povedať: neviem ako to presne je vnútri urobené, ale nečudoval by som sa, keby si VirtualBox urobil v host-ovi niečo ako virtuálny adaptér pre každého pusteného guest-a a obsluha pingu by sa mohla odohrať už tam.Reps. ak pingujem ten VM, tak či sa musí dostať k slovu ten VM.Tak moment… celou dobu to vypadalo, že mluvíte o odezvách toho hosta.
host - host (localhost) host - virtuál virtuál - host virtuál - jinej virtuál virtuál - ten samej virtuál (localhost) externí - virtuál externí - host virtuál - externí virtuál - hostPak ještě můžeš zkusit ping flood a skenovat jednotlivé testy nějakým snifferem (například wireshark).
Uz se mi nekolikrat stalo, ze se serveru dostaly do nekonecne smycky procesy s realtime prioritou (Oracle rac lmd procesy) a pak se neslo prihasit, neslo s tim serverem delat nic jineho nez to otocit. Jedine na co ten server reagoval byl sysrq.
To je známý problém, včetně toho, že pachatelem je nejčastěji Oracle. Ten realtime proces sice udusí "jen" jeden procesor, ale čas od času je potřeba provést něco na všech procesorech (např. rcu_sync()
) a taková věc pak čeká, až se příslušný procesor uvolní, čímž blokuje další. Když se to nechá dost dlouho, visí nakonec všechny, pokud ten systém dřív neodstřelí soft lockup detector nebo RCU stall detector.
Na ping ale ten server odpovidal uplne v pohode. Dokonce pri navazani TCP spojeni odpovedel na SYN.
Tohle je trochu složitější. Nemáte-li tam moc velkou zátěž (ve smyslu počtu příchozích paketů), stihne se oboje vyřídit ještě v rámci softirq vyvolaného na konci obsluhy hardwarového přerušení, čemuž nedokáže zabránit ani ten realtime proces okupující daný procesor. Pokud té práce ale bude moc, nechá se to na ksoftirqd a pak máte problém. (Kromě toho ale ten příchozí paket nemusí vůbec připadnout na blokovaný procesor.)
Tiskni
Sdílej: