Společnost Murena představila (YouTube) novou verzi 4.0 mobilního operačního systému /e/OS (Wikipedie) založeného na Androidu a LineageOS bez aplikací a služeb od Googlu.
V Arch User Repository (AUR) bylo kompromitováno přes 400 opomíjených balíčků (jejich seznam). Útočník do nich začlenil škodlivý npm balíček atomic-lockfile, který krade citlivá data uživatelů. Publikována byla předběžná analýza spouštěného malwaru deps.
Homebrew, správce balíčků nejen pro macOS, byl vydán ve verzi 6.0.0 (seznam změn). Hlavními novinkami jsou bezpečnostní mechanismus tap trust kvůli důvěryhodnosti závislostí, vylepšení sandboxingu na Linuxu, interní JSON API nebo zlepšení výkonu.
Byla nalezena a 9. června opravena kritická zranitelnost ve FreeBSD v Kernel TLS (KTLS). Pojmenována byla Bumsrakete (FreeBSD-SA-26:26.ktls, CVE-2026-45257). Lokální neprivilegovaný uživatel může přepisovat soubory, ke kterým má právo pouze pro čtení. Přepsáním setuid binárky a jejím spuštěním může získat roota. Na všech verzích od verze 13.0 vydané v dubnu 2021.
Vývojáři open source operačního systému ReactOS (Wikipedie), jehož cílem je kompletní binární kompatibilita s aplikacemi a ovladači pro Windows, se na síti 𝕏 pochlubili, že ReactOS zvládne počítačovou hru Half-Life.
Byla vydána nová verze 4.8 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Využíván je Free Pascal Compiler (FPC) 3.2.2.
Apple container dospěl do verze 1.0.0. Jedná se o open source nástroj pro spouštění linuxových kontejnerů na macOS postavený nad containerization. Napsaný je v programovacím jazyce Swift a optimalizovaný pro Apple silicon.
Bylo vydáno Eclipse IDE 2026-06 aneb Eclipse 4.40. Představení novinek tohoto integrovaného vývojového prostředí také na YouTube.
Asterinas (GitHub) je v Rustu napsané jádro operačního systému poskytující s jádrem Linux kompatibilní ABI. Vydána byla verze 0.18.0. První distribucí postavenou nad jádrem Asterinas je Asterinas NixOS. Nejedná se o oficiální projekt NixOS a nemá nic společného s NixOS Foundation.
Podrobně byla rozebrána kritická zranitelnost v nf_tables (CVE-2026-23111). Další lokální eskalace práv na Linuxu. V upstreamu byla zranitelnost již v únoru opravena. Ve zdrojovém kódu stačilo odstranit 1 vykřičník.
ordered mode). Disky mají pro jistotu vypnutou "drive write cache" - zatím to nevadilo a jinak prý hrozí i totální poškození ext3 při výpadku napájení, protože mdraid+lvm neumí správně bariéry (snad opraveno v 2.6.31 ?). Server má 8GB RAM, 4G úplně volné, CPU Intel E2160, zatížení CPU do 10% (až na ten iowait, viz dále).
Momentálně zabírá IOWAIT kolem 10-25% z jednoho CPU, podle zátěže. Procento IOWAIT se zvyšovalo s roustoucím počtem db v postgresu. Pokud postgres běží, iostat ukazuje trvale zápis asi 300 KB/s, tohle číslo v čase roste stejně s tím počtem db a iowaitem.
Jak jsem zjistil nástrojem iotop, způsobuje tohle proces postgres: stats collector process ve spojení s [kjournald]. Při interaktivním sledování vyskočí ve sloupci "IO" každých 5 vteřin tyhle 2 procesy. Výstup iotop - souhrn za 60s:
Total DISK READ: 0.53 K/s | Total DISK WRITE: 1.96 M/s PID USER DISK READ DISK WRITE SWAPIN IO> COMMAND 1983 root 0 B/s 4.26 K/s 0.00 % 18.27 % [kjournald] 23784 postgres 0 B/s 23.45 K/s 0.00 % 8.49 % postgres: stats collector process 1981 root 0 B/s 0.67 K/s 0.00 % 5.28 % [kjournald] 1984 root 0 B/s 0.07 K/s 0.00 % 1.66 % [kjournald] 1027 root 0 B/s 0 B/s 0.00 % 1.35 % [md1_raid1] 1117 root 0 B/s 3.00 K/s 0.00 % 0.77 % [kjournald]Zajímavé je tady číslo "Total DISK WRITE: 1.96 M/s", které se neshoduje s výstupem
iostat.
Pokud na obou discích v RAIDu povolím "drive write cache", tak IOWAIT už CPU neužírá. Bojím se, že s přibývajícími databázemi bude tahle zátěž stoupat i když k tomu není důvod.
Hledal jsem řešení všude možně, ale našel jsem jen zmínku že by to mohlo souviset se souborem pgstat.stat, který se pořád dokola zapisuje na disk, a že ho snad jde v PG 8.4 nějakým parametrem přemístit na ramdisk... U mě má ten soubor 1,4MB.
Setkal se s takovým chováním někdo? Jde tohle nějak omezit laděním nastavení postgresu? Nebo už není třeba se bát zapnout write cache?
Tiskni
Sdílej: