Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
Před 25 lety zaplavil celý svět virus ILOVEYOU. Virus se šířil e-mailem, jenž nesl přílohu s názvem I Love You. Příjemci, zvědavému, kdo se do něj zamiloval, pak program spuštěný otevřením přílohy načetl z adresáře e-mailové adresy a na ně pak „milostný vzkaz“ poslal dál. Škody vznikaly jak zahlcením e-mailových serverů, tak i druhou činností viru, kterou bylo přemazání souborů uložených v napadeném počítači.
Byla vydána nová major verze 5.0.0 svobodného multiplatformního nástroje BleachBit (GitHub, Wikipedie) určeného především k efektivnímu čištění disku od nepotřebných souborů.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za duben (YouTube).
Provozovatel čínské sociální sítě TikTok dostal v Evropské unii pokutu 530 milionů eur (13,2 miliardy Kč) za nedostatky při ochraně osobních údajů. Ve svém oznámení to dnes uvedla irská Komise pro ochranu údajů (DPC), která jedná jménem EU. Zároveň TikToku nařídila, že pokud správu dat neuvede do šesti měsíců do souladu s požadavky, musí přestat posílat data o unijních uživatelích do Číny. TikTok uvedl, že se proti rozhodnutí odvolá.
Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.
Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.
V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).
Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
On někdo nabízí skutečné obecné master master řešení?Např. Oracle RAC přesně toto umožňuje. Minimálně dřívější verze vyžadovaly shared storage (s cluster filesystémem, nebo s přímým přístupem na blockdevice), jak je to v posledních nevím. Pokud je tlak na výkon synchronizace u konkurečních zápisů, pomůže nějaký low-latency interconnect - infiniband, případně platformy s globálně sdílenou pamětí jako je SGI Altix.
Ale já s replikacemi db příliš zkušeností nemám. Pracuju ve sféře, kde je lepší mít nedostupnost než mít vadná data. Nenašel jsem spolehlivé funkční řešení, které by nepřinášelo víc problémů než užitku.Ono je to vždy o poměru nákladů na takové řešení - jak pořízení tak provoz/správa - vs. ten užitek. Od určité úrovně je spolehlivé funkční řešení dostupné za nákladů, které už ten užitek navíc v např. podobě "lehce" vyšší dostupnosti nevyváží.
Takové to klasické na master se zapisuje a na replikách běží selecty je použitelné pouze v místech, kde nevadí lag mezi masterem a replikou (a tedy nevadí že jeden server vrátí jiné informace než druhý). A nebo na místech, kde o tomto problému ani neví a vesele vrací vadná data.Synchronní replika i u toho postgresu řeší právě tohle - commit write transakce čeká na potvrzení od všech replik, takže replika nikdy nevrátí data před tímto commitem.
Ohledně RAC tedy nejlépe společný block deviceJestli je ten společný blok device na jednom železe pro ty dva Oracle servery, tak mi není jasné, v čem je potom přínos master master replikace. Stejně to běží z jednoho disku (pole). Resp. problém se přesouvá na storage vrstvu, jak storage vrstva zajistí master master replikaci těch block device přes více železa?
V této sféře se samozřejmě počítá s nějakou SAN infrastrukturouJistě, ale ta infrastruktura bude u master master řešit úplně stejné problémy, jaké by (měl) řešil ten db server. Tím, že se to jen posune o vrstvu níž se problém nevyřešil (spíš mi přijde že právě naopak zkomplikoval, protože teď se ještě musí řešit paralelní zápis ze dvou míst do jednoho bloku - resp zabránění. Takže zámky. + k tomu ještě problémy zamykání těch transakcí v db). To už je lepší nějaká replikační proxy (Slony a spol.), který ten master master nějak zařídí (i pro PostgreSQL). DRBD split brain jsem viděl a řešil tolikrát, že to za spolehlivé řešení ničeho nepovažuji (to jen poznámka mimo téma).
Minimálně dřívější verze vyžadovaly shared storage (s cluster filesystémem, nebo s přímým přístupem na blockdevice), jak je to v posledních nevím.No, takže se problém posouvá na storage vrstvu. To mi tedy jako řešení nepřipadá.
Synchronní replika i u toho postgresu řeší právě tohle - commit write transakce čeká na potvrzení od všech replik, takže replika nikdy nevrátí data před tímto commitem.To jo, ale zase je to pomalé (pomalejší než klasické master - multislave pro selecty). Takže to řeší maximálně možnost přepnutí na vedlejší db server v případě havárie masteru.
Ono je to vždy o poměru nákladů na takové řešení - jak pořízení tak provoz/správa - vs. ten užitek. Od určité úrovně je spolehlivé funkční řešení dostupné za nákladů, které už ten užitek navíc v např. podobě "lehce" vyšší dostupnosti nevyváží.Přesně tak. Prošel jsem mnoho řešení, nakonec se v praxi ukazuje jako nejlepší řešení single db server, který výkon zvládá (to není žádný problém), spolehlivé zálohy a údržba hw a záložní hw k disposici. V praxi ten hw zase tak často nepadá (rozhodně méně častěji, než různá replikační řešení) a i kdyby, tak se ten několikahodinový výpadek jednou za 10 let snese. Stejně i v tom DC vypínají elektriku častěji.
To jo, ale zase je to pomalé (pomalejší než klasické master - multislave pro selecty). Takže to řeší maximálně možnost přepnutí na vedlejší db server v případě havárie masteru.Pomalejší než asychronní replika to přirozeně je. Pokud je ale významná část zátěže v SELECT operacích, tak je to relevantní řešení. Zápisy se proti single serveru o něco zpomalí (na dnešním HW a 10Gb nebo infiniband síti to není tak hrozné), ale mám možnost rozložit zátěž způsobenou složitými SELECT dotazy na několik dalších uzlů. Není to pro všechny případy, ale pro řadu aplikací to může být dobré řešení.
V praxi ten hw zase tak často nepadá (rozhodně méně častěji, než různá replikační řešení) a i kdyby, tak se ten několikahodinový výpadek jednou za 10 let snese. Stejně i v tom DC vypínají elektriku častěji.S padáním replikačních řešení by se tedy dalo polemizovat. Já ke spokojenosti používám DRBD - v případě selhání HW není výpadek několikahodinový (s případnou ztrátou dat od poslední zálohy), ale v minutách. Jinde u postgresu používám alespoň asychronní replikaci a uchovávání WAL jako formu kontinuální zálohy. To vypínání elektriky z velké části řeší právě tak replikace, alespoň přes různé sály v DC. U komerčních replikovaných SAN lze slýchat různé story o nespolehlivosti, ale při objektivním pohledu to za předpokladu kvalifikované správy prostě funguje.
Já ke spokojenosti používám DRBD - v případě selhání HW není výpadek několikahodinový (s případnou ztrátou dat od poslední zálohy), ale v minutách.Já už viděl tolik splitbrainů (v režimu primary / secondary), že DRBD neberu.
Jinde u postgresu používám alespoň asychronní replikaci a uchovávání WAL jako formu kontinuální zálohy.JJ, tam kde to jde, tak online backup, jinde snapshoty těch db serverů. To je jasný.
U komerčních replikovaných SAN lze slýchat různé story o nespolehlivosti, ale při objektivním pohledu to za předpokladu kvalifikované správy prostě funguje.U jednoho nejmenovaného produktu jedné významné firmy prostě suše oznámili, že jejich zálohovací řešení prostě nefunguje, protože u produktu jiné významné firmy nefunguje oznamování změněných bloků. Takže všechny inkrementy jsou v ... Kdyby se za ty peníze, co stál ten nefunkční soft koupilo další železo, a rozhodila by se tam záloha třeba z toho online backupu, tak se pro bezpečí dat udělá lépe. Jenže to nemá dostatečně cool rozhraní s barevnými grafy.
Já už viděl tolik splitbrainů (v režimu primary / secondary), že DRBD neberu.V režimu primary / secondary by splitbrain měl vzniknout jen velmi těžko vzhledem k tomu, že na secondary se až do failover okamžiku přímo nezapisuje. Až dojde na failover, secondary zajistí shození původního primary a přepne se. Zpět to řeším ručně. Pokud se dobře nakonfiguruje cluster manager, tak by podobné situace z principu neměly vznikat. Nevím o jaké šlo verze, já to používám poslední asi 3 roky, kdy už je jaderná část DRBD v upstreamu. U primary / primary je to horší, při určitém pořadí spadnutí a spuštění uzlů k split-brain může dojít i když není přerušená komunikace mezi nimi, proto ho nakonec raději nepoužívám.
Ale nemůžu si pomoct, spolehlivě funguje OSS dostatečně prověřené verze, komerční soft v naší cenové kategorii (tzn 100tis za licenci) prostě nefunguje. Možná funguje nějaké superdrahé řešení za miliony, ale jsem si jist, že kdyby se tytéž peníze vrazily do HW a řešení se postavilo na OSS prověřených softech, tak se pro bezpečnost dat udělá víc.Ano, řada "entry-level" komerčního SW a hlavně HW funguje mizerně, a OSS řešení může v takovém segmentu dopadnout lépe. Relace 100tis za licenci nebo nižší stovky tisíc za HW jsou entry-level. U řešení "za miliony" ale často OSS nic se srovnatelnými parametry nenabízí; nebo to nikdo nenabízí jako prověřené řešení se supportem, což ve větším měřítku prostě je riziko. U velkých storage má dobře nakročeno CEPH, jeho nasazení pod OpenStack, a tam bych tipoval že dost velkou roli sehrála dostupnost komerčního suportu od Inktank (pohlcen RedHat-em). Nicméně koupit NetApp MetroCluster je pořád "jistota".
Nevím o jaké šlo verze, já to používám poslední asi 3 roky
Tohle je tak 5 let staré. Bohužel to nemá adekvátní servis a zavolají jen když je průser.
U řešení "za miliony" ale často OSS nic se srovnatelnými parametry nenabízí
Tak ono je otázka, zda je to potřeba. Nechci za každou cenu odporovat, ale my provozujeme několik řešení na úrovni ČR, kde jeden produkt má share tak 30%, druhý skoro 50% a třetí někde mezi tím.
Na toto nasazení pro ČR bohatě stačí OSS a (pro vás) levné servery se vyloženě nudí. Toto hw řešení suma sumárum asi tak za 3M by jakš takš stačilo pro 100% ČR (kdyby se to optimalizovalo, tak i pro SR).
(Chápu, že v české diskusi má kde kdo servery pro stovky miliard uživatelů, ale mě ČR bohatě stačí.)
U velkých storage má dobře nakročeno CEPH
Mám to v todo, zatím nebyl dostatek času.
... (Chápu, že v české diskusi má kde kdo servery pro stovky miliard uživatelů, ale mě ČR bohatě stačí.)Já souhlasím, že často se v korporátní i státní sféře používají předimenzovaná a zbytečně drahá HW řešení. Ale tohle přece není primárně o počtu uživatelů nebo geografickém zaměření. Rozhodující je typ aplikace - objem dat a povaha operací nad nimi, zejména nakolik je možné (a účelné) náročné operace přesunout mimo databázi. Pokud mám systém, se kterým pracují ve špičce současně tisíce až desítky tisíc přihlášených uživatelů a databáze musí řešit náročné transakční a analytické úlohy, tak může skutečně vyjít, že OSS a komoditní HW neposkytuje řešení. Navrch takové aplikace obvykle nevznikají z roku na rok, ale mají poměrně dlouhou historii sahající do doby, kdy třeba ten Postgres nebyl zdaleka v takovém stavu jako teď, a tím je dána vazba třeba na Oracle. Některé vaše úvahy sdílím, ale představa, že celý segment enterprise HW je kult do kterého všichni sypou takové peníze ze zvyku, když by se to snadno dalo dělat levněji a lépe, je imho mimo realitu.
Jako příklad si vezmu do huby KapicuAleš má výhodu v hromadě času a tento čas vrací ostatním v podobě poznámek v blozích a na své wiki. Nevidím do jeho provozu, ale tipuju, že určitě není nutné nasazovat takto složité systémy a že to dělá spíš proto, že ho to baví a navíc si tím zjednodušuje práci. Proč ne a jsem za jeho činnost moc rád.
Osobně jsem zkusil naladit FreeNAS a narazil jsem na několik problémů : stará verze NFS, úplně idiocké default hodnoty + to má stejně nepěkné bugy. Teď už bych do toho nešel a naladil bych čisté FreeBSD.No otázkou je, zda to byl dobrý krok. Některé moje produkční storage jsou obyč linuxy exportující NFS a tím to hasne. Normální ext3/4 (podle stáří), exportfs a konec. Potom se to připojí do vmware a běží na tom produkce. Proč vymýšlet složitosti? Když se to pokazí, tak nastavit druhej linux s NFS je otázka chvilky, nahrnou se tam image ze záloh (resp. my to mámě udělané přes replikace). Jinde mám pro ulehčení btrfs, na tom valím kontejnery (pro testy). Opravdu nevidím důvod pro nasazení FreeNAS (teď nemyslím proto, že je to BSD, ale proto, že je to zase nějaká vrstva navíc - i kdyby existovalo FreeBTRFS, tak nevidím důvod pro to to instalovat).
Kdybychom jeli jen linuch, tak asi ok, ale když jedeme i Oracle, Exchange, windows, MSSQL, Citrix, tak fakt ne. Člověk by řekl, že nasadí Proxmox, ale pak čte lidi v diskusi, co tvrdí, že windows na tom občas zlobí (třeba jsou extrémně líný) a na ofiku forku si na to stěžují.Jasně, tak máš tam větší mix věcí a je to složitější, ale proboha proč zase proxmox? Nainstaluju linux, kvm už tam je, přidám qemu a věci kolem, nastavím síť a skončil jsem. Když si chci trochu ulehčit život, tak přidám libvirt. Nemusím řešit další vrstvy v ovirtu, proxmoxu apod. kravinách. (Čtvrt roku mě volá jeden člověk, kterému v proxmoxu něco neběží a ptá se mě, na co má kliknout. Já nevím, já to nikdy neviděl. Ale na cli by to měl během jednoho dne. Stejně je to jen virtálka, někde je image disku a někde jsou definice vmka. Jestli to má v bash skriptu a pouští qemu-kvm, tak je to přece jedno.)
Ale to jsem se už hodně odklonil od tématu. Já tím chtěl jen říci, že někdy OSS není úplně tak rentabilní, nebo neexistuje vhodná OSS alternativa :-/.Tak to si musí každý spočítat sám. Já se pohybuju v OSS světě a komerční svět vnímám tak jak jsem popsal. Řekl bych, že jsme přesně v té oblasti, kdy je ten software sice relativně drahý na pořízení, ale současně příliš levný na to, aby něco uměl. Takže to přináší vlastně jen nevýhody. Jestli si někdo spočítá, že se mu software vyplatí, tak ať. Mě to zatím přináší jen problémy a ty peníze za ten soft bych raději viděl jinde.
ale převážné výkonové faily jsou v samotných selectechAno. U nás někdy bohužel převládne názor "tak nakoupíme ssdčka" místo toho, aby se to napsalo lépe. Naštěstí, ty chyby mají mocninnou nebo lépe exponenciální složitost, takže ani ssd neudrží krok moc dlouho a stejně se to musí nakonec optimalizovat. To potom časy běhu dotazů spadnou klidně 1000x (resp. složitost spadne na log, nebo rovnou konstantní). Ne, že bych měl něco proti ssd, ale vadí mi, když makají zbytečně na něčem hrůzném.
dej tam minimalne 32 GB pameti a rychle harddisky
Tiskni
Sdílej: