Omarchy (Wikipedie) je linuxová distribuce s dlaždicovým správcem oken Hyprland. Založena je na Arch Linuxu. Vydána byla v nové verzi 4.5.0. Nově také pro Apple Silicon, konkrétně pro M1/M2/M3/Neo MacBooky.
Byla vydána nová stabilní verze 8.3 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 156 s bezpečnostními opravami z Chromia 157. Přehled novinek i s náhledy v příspěvku na blogu.
Multimediální přehrávač mpv byl vydán ve verzi 0.42.0. Jde o větší balík změn po bezmála roce. Mimo jiné se lépe integruje s Waylandem nebo rozšiřuje podporu DVD/Blu-ray, např. umožňuje přehrávat rovnou obrazy médií (soubory iso).
Desktopové prostředí LXQt (Lightweight Qt Desktop Environment, Wikipedie) vzniklé sloučením projektů Razor-qt a LXDE bylo vydáno ve verzi 2.5.0. Přehled novinek v poznámkách k vydání.
Byla vydána (𝕏) nová verze 8.0 LTS open source monitorovacího systému Zabbix (Wikipedie). Přehled novinek v oznámení na webu, v poznámkách k vydání a v aktualizované dokumentaci.
Byla vydána verze R14.1.7 desktopového prostředí Trinity Desktop Environment (TDE, fork KDE 3.5, Wikipedie). Přehled novinek v poznámkách k vydání, podrobnosti v seznamu změn.
Bazzite (Wikipedie), tj. linuxová distribuce vycházející z Fedora Linuxu a optimalizována pro hraní počítačových her, byla vydána ve verzi 45. S Open Gaming Collective (OGC) jádrem a novým Easy Anti-Cheatem pro Linux (EAC Linux v2).
MikroTik zveřejnil vlastní bezpečnostní upozornění potvrzující, že zranitelnost linuxového jádra postihuje také RouterOS 7. Jde o use-after-free při zpracování IPv4 TCP spojení s IP options. Zranitelnost se týká provozu směřujícího na TCP službu samotného routeru, nikoli paketů, které router pouze přeposílá. Opraveno v long-term od 7.24.6, v stable od 7.25.1 a devel od 7.26beta5.
Ve správci balíčků APT, používaném v Debianu a odvozených distribucích, byla nalezena a opravena kritická zranitelnost CVE-2026-109518. Vzdálený útočník může obejít ověření stažených balíčků pomocí přesměrování a dočasných chyb HTTP serveru.
Nazov blogu znie honosne, ale zaujimalo ma, aky dopad na vykon maju rozne scenare pouzitia loggeru.
Na testy som pouzil oracle java 1.7 64bit, slf4j + logback, meranie prebehlo vzdy 3x na nezatazenom kompe. Je to sice primitivne, ale hrat sa s profilerom nemam cas. Vysledky si sem ukladam pre buducu argumentaciu, ale mozu sa takisto hodit niekomu dalsiemu a usetrim mu tak 10 minut prace.
Kod na ktorom som testoval:
private static final Logger logger = LoggerFactory.getLogger(App.class);
private static final boolean loggerInfoEnabled = logger.isInfoEnabled();
public static void main(String[] args) {
long t1 = System.currentTimeMillis();
long x=0;
for(long l = 0; l < 1000000000;l++ ) {
// 1
logger.info("A {}", l);
// 2
if ( logger.isInfoEnabled()) {
logger.info("A {}",l);
}
// 3
if ( loggerInfoEnabled ) {
logger.info("A {}",l);
}
x++;
}
long t2 = System.currentTimeMillis();
System.out.println(t2-t1);
}
Komentarmi 1,2 a 3 su oznacene bloky kodu, ktore som mal za/odkomentovane. Vzdy sa vykonaval len jeden zo scenarov. Scenar 0 je s uplne zakomentovanym kodom loggeru a vykonava sa len x++;
Vysledky:
0 - 2034, 2307, 2306
1 - 20192, 20395, 20625
2 - 8905, 8930, 8941
3 - 2306, 2301, 2309
Vysledok je teda jasny, pokial pracujem v casovo narocnom prostredi, ale chcem mat moznost logovat, pouzijem variantu 3. Nevyhoda je jasna - nebude mi fungovat reloading konfiguracie loggerov za behu aplikacie.
Tiskni
Sdílej:
Vysledok je teda jasny, pokial pracujem v casovo narocnom prostredi, ale chcem mat moznost logovat, pouzijem variantu 3.To mi až tak jasné nepřijde. Protože za 2,0192 ms stihneš zalogovat 100 000 zpráv, to není málo
I při variantě #1 jich zaloguješ 10 000, což je stále dost velká rychlost.
Klíčové je hlavně to, dát tam ten IF (klidně s logger.isInfoEnabled()), pokud do logovacích hlášek dáváme parametry, jejichž získání/vypočtení trvá dlouho.