V březnu byla oznámena spolupráce GrapheneOS s Motorolou. Nejnovější vlajka Motorola Signature 27 je první Motorola s oficiální podporou GrapheneOS. GrapheneOS (Wikpedie) je varianta Androidu zaměřující se na bezpečnost a soukromí.
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.
Jinak přesně tytéž problémy jsem měl s DRBD i já - problém je v blbě udělaném agentu pro Pacemaker od Linbitu.Není, na těch strojích, kde to blbne, ho nepoužívám - nemám dva uzly se stabilním DRBD úložištěm, ale hodně uzlů, kde se úložiště vytvářejí a propojují dle potřeby. Tj. přišlo mi zbytečné generovat konfiguraci, tak se místo toho prostě postupně volá drbdmeta a drbdsetup, kterými se to DRBD dostane do stavu, v jakém má být. IMO je to bug v kernelu - je to vytuhlé v syscallu a v dmesgu hlášky "task hung for more than 120 seconds". A samozřejmě se to neprojevuje dost deterministicky na to, aby se to dalo dobře ladit.
IMO je to bug v kernelu - je to vytuhlé v syscallu a v dmesgu hlášky "task hung for more than 120 seconds". A samozřejmě se to neprojevuje dost deterministicky na to, aby se to dalo dobře ladit.Tak to nemohu vyloučit. Já měl původně dvě vzájemně nezávislá DRBD pole, v rámci pěti nodového asymetrického clusteru. A binec v tom dělal vždy jen ten agent. V současné době mám jedno DRBD pole (resp. dvě ale jsou v rámci jednoho dvounodového clusteru) a tam musím mít drbd v režimu unamanged, protože jakmile ten resource přepnu do stavu managed, tak mi všechno rozesere. Přitom to DRBD normálně bez problémů běží v režimu Primary/Secondary. Jakmile se resource přepne do stavu managed, udělá mi z toho Slave/Slave a nazdar pipi. Poshazuje to závislé služby, protože ty pochopitelně čekají na Master a konečná. Nepomůže ani svěcená voda. Jinak Sheepdog je ve srovnání s Ceph mnohem subtilnější cca 300MB pro kompilaci versus 20GB. Běží jako jeden výchozí proces, přes který se to i řídí, nepotřebuje extra metadata a funguje opravdu pěkně. Mám ho v kombinaci s GlusterFS. Pacemaker se mi stará jen o nahazování virtuálů. Budu o tom hovořit teď na Installfestu.
Tiskni
Sdílej: