V Redisu byla nalezena a v upstreamu již opravena kritická zranitelnost CVE-2025-49844 s CVSS 10.0 (RCE, vzdálené spouštění kódu).
Ministr a vicepremiér pro digitalizaci Marian Jurečka dnes oznámil, že přijme rezignaci ředitele Digitální a informační agentury Martina Mesršmída, a to k 23. říjnu 2025. Mesršmíd nabídl svou funkci během minulého víkendu, kdy se DIA potýkala s problémy eDokladů, které některým občanům znepříjemnily využití možnosti prokázat se digitální občankou u volebních komisí při volbách do Poslanecké sněmovny.
Společnost Meta představila OpenZL. Jedná se o open source framework pro kompresi dat s ohledem na jejich formát. Zdrojové kódy jsou k dispozici na GitHubu.
Google postupně zpřístupňuje českým uživatelům Režim AI (AI Mode), tj. nový režim vyhledávání založený na umělé inteligenci. Režim AI nabízí pokročilé uvažování, multimodalitu a možnost prozkoumat jakékoliv téma do hloubky pomocí dodatečných dotazů a užitečných odkazů na weby.
Programovací jazyk Python byl vydán v nové major verzi 3.14.0. Podrobný přehled novinek v aktualizované dokumentaci.
Bylo oznámeno, že Qualcomm kupuje Arduino. Současně byla představena nová deska Arduino UNO Q se dvěma čipy: MPU Qualcomm Dragonwing QRB2210, na kterém může běžet Linux, a MCU STM32U585 a vývojové prostředí Arduino App Lab.
Multiplatformní open source voxelový herní engine Luanti byl vydán ve verzi 5.14.0. Podrobný přehled novinek v changelogu. Původně se jedná o Minecraftem inspirovaný Minetest v říjnu loňského roku přejmenovaný na Luanti.
Byla vydána nová stabilní verze 6.10 (YouTube) multiplatformního frameworku a GUI toolkitu Qt. Podrobný přehled novinek v poznámkách k vydání.
Netwide Assembler (NASM) byl vydán v nové major verzi 3.00. Přehled novinek v poznámkách k vydání v aktualizované dokumentaci.
Jsem zakladatelem tohoto portálu. Linux jsem používal spousty let, nějaký čas jsem se aktivně podílel na jeho propagaci v Česku (CZLUG, časopisy ComputerWorld, Network Magazine atd). Se současným Abíčkem už nemám nic společného.
Zatím jen sen, těch výpadků jsme ale už zažili tolik, že Stickfish plánuje nasadit Abíčko do clusteru. No a já trochu chladím jejich nadšení soupisem možných problémů. Rád bych slyšel vaše názory a postřehy, jak byste je řešili vy.
Poslední výpadek byl způsoben hard diskem, který se poroučel do věčných lovišť. RAID nám sice zachránil kůži (už poněkolikráté), ale nemůžeme se spoléhat na jeden server. V nárazech nemusí stíhat požadavkům, ale hlavně jeho výpadek znamená desítky minut či hodiny nefunkčnosti Abíčka. A to si prostě nemůžeme dovolit. Takže se koupila další našlapaná mašina, na kterou se přesunou všechny servery (webové) a z původního stroje vznikne druhý uzel pidi clusteru. Na obou strojích by měly být nainstalovány stejné webové aplikace i databáze, která se bude mezi nimi replikovat. Požadavky bude na uzly rozhazovat buď specializovaná mašina nebo nějaká síťová komponenta (nejspíše round robin algoritmus, nic sofistikovaného).
Život mě naučil jisté skepse a tak dopředu hledám rizika, ať se na ně mohu připravit. Za prvé databáze. Abíčko teď jede na MySQL 4.1, která clusterování neumí. Přechod na pětku snad nebude tak bolet, jako na 4.1 (důsledkem jsou duplicitní loginy, které tento víkend budeme fixovat). Jaké máte zkušenosti? Je možné rozjet MySQL na dvou počítačích tak, aby databáze byly v obou okamžicích rovnocenné a vzájemně zastupitelné? Aby měly stejné data a když jeden uzel spadne, druhý jede v pohodě dál a po obnovení spojení ten první uzel jen načetl změny? (Nechci mít dedikovaný databázový server, stejně bychom jej museli dát do clusteru.)
Dalším rizikem je souborový systém. Abíčko má spoustu souborů na disku, uživatelé nahrávají screenshoty či obrázky. Jak efektivně ale zajistit, ať oba uzly mají stejná data při požadavku na co nejmenší riziko zatuhnutí? Připojit disk ze třetího stroje (třeba NFS) nepovažuji za dobrý nápad, jeho výpadek by zasáhl oba uzly. Takže spíše nějakým skriptem neustále synchronizovat adresáře na obou strojích. Ale to bude asi dost náročné na výkon počítače.
Další problém vidím v Abíčku jako aplikaci. Abíčko je nesmírně optimalizovaná aplikace (kvůli jedné hloupé chybě - vypnutí JIT - jsem dělal divy), jenže všechny ty cache jsou stavěny na tom, že Abíčko běží na jediném stroji. Kdyby běželo na dvou strojích, rychle by byly cache nesynchronizovány a data by se mohly poškodit či přepsat, různě ztrácet atd. Například uzly A a B načtou softwarový záznam. Uzel A jej pak upraví, změní třeba licenci a uloží jej. Nicméně uzel B o tom nic neví a má v cache původní hodnotu, takže když má změnit třeba popisek, uloží do databáze řádek se starou licencí a novým popiskem. Což se ale nedozví uzel A a tak bude všem čtenářům ukazovat starý popisek a novou licenci, zatímco uzel B bude ukazovat starou licenci a nový popisek. Schíza, že?
Co teď? Jak toto vyřešit? Udělat komunikaci mezi cachemi, aby se vzájemně informovaly, když je třeba něco načíst z databáze? Nebo zahodit současnou cache a najít nějakou distribuovanou cache? Máte v této oblasti zkušenosti? Co byste doporučili?
Tiskni
Sdílej: