Společnost AMD na veletrhu Computex 2024 představila (YouTube) mimo jiné nové série procesorů pro desktopy AMD Ryzen 9000 a notebooky AMD Ryzen AI 300.
OpenCV (Open Source Computer Vision, Wikipedie), tj. open source multiplatformní knihovna pro zpracování obrazu a počítačové vidění, byla vydána ve verzi 4.10.0 . Přehled novinek v ChangeLogu. Vypíchnout lze Wayland backend pro Linux.
Národní superpočítačové centrum IT4Innovations s partnery projektu EVEREST vydalo sadu open source vývojových nástrojů EVEREST SDK pro jednodušší nasazení aplikací na heterogenních vysoce výkonných cloudových infrastrukturách, zejména pro prostředí nabízející akceleraci pomocí FPGA.
Společnost Valve aktualizovala přehled o hardwarovém a softwarovém vybavení uživatelů služby Steam. Podíl uživatelů Linuxu aktuálně činí 2,32 %. Nejčastěji používané linuxové distribuce jsou Arch Linux, Ubuntu, Linux Mint a Manjaro Linux. Při výběru jenom Linuxu vede SteamOS Holo s 45,34 %. Procesor AMD používá 75,04 % hráčů na Linuxu.
Blíží se léto, chladiče topí, tranzistory se přehřívají, novinářům pomalu docházejí témata a nastává klasická okurková sezóna. Je tomu tak i mezi bastlíři? Na to se podíváme na Virtuální Bastlírně! Tentokrát se strahováci podívají na zoubek velmi slibně vypadajícímu open-source EDM projektu - ne, nejde o taneční hudbu, ale o elektroobrábění. Ukáží taky, jak vypadá starší cykloradar zevnitř nebo jak se testuje odolnost iPhonů.
… více »Společnosti Ticketmaster byla odcizena databáze s osobními údaji (jméno, adresa, telefonní číslo a část platebních údajů) 560 miliónů zákazníku. Za odcizením stojí skupina ShinyHunters a za nezveřejnění této databáze požaduje 500 tisíc dolarů [BBC].
Byla vydána nová stabilní verze 24.05 linuxové distribuce NixOS (Wikipedie). Její kódové označení je Uakari. Podrobný přehled novinek v poznámkách k vydání. O balíčky se v NixOS stará správce balíčků Nix.
Byla vydána nová verze 1.48.0 sady nástrojů pro správu síťových připojení NetworkManager. Novinkám se v příspěvku na blogu NetworkManageru věnuje Fernando F. Mancera. Mimo jiné se v nastavení místo mac-address-blacklist nově používá mac-address-denylist.
Před 25 lety, 31. května 1999, započal vývoj grafického editoru Krita (Wikipedie). Tenkrát ještě pod názvem KImageShop a později pod názvem Krayon.
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: