Společnost Meta na dvoudenní konferenci Meta Connect 2025 představuje své novinky. První den byly představeny nové AI brýle: Ray-Ban Meta (Gen 2), sportovní Oakley Meta Vanguard a především Meta Ray-Ban Display s integrovaným displejem a EMG náramkem pro ovládání.
Po půl roce vývoje od vydání verze 48 bylo vydáno GNOME 49 s kódovým názvem Brescia (Mastodon). S přehrávačem videí Showtime místo Totemu a prohlížečem dokumentů Papers místo Evince. Podrobný přehled novinek i s náhledy v poznámkách k vydání a v novinkách pro vývojáře.
Open source softwarový stack ROCm (Wikipedie) pro vývoj AI a HPC na GPU od AMD byl vydán ve verzi 7.0.0. Přidána byla podpora AMD Instinct MI355X a MI350X.
Byla vydána nová verze 258 správce systému a služeb systemd (GitHub).
Byla vydána Java 25 / JDK 25. Nových vlastností (JEP - JDK Enhancement Proposal) je 18. Jedná se o LTS verzi.
Věra Pohlová před 26 lety: „Tyhle aféry každého jenom otravují. Já bych všechny ty internety a počítače zakázala“. Jde o odpověď na anketní otázku deníku Metro vydaného 17. září 1999 na téma zneužití údajů o sporožirových účtech klientů České spořitelny.
Byla publikována Výroční zpráva Blender Foundation za rok 2024 (pdf).
Byl vydán Mozilla Firefox 143.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Nově se Firefox při ukončování anonymního režimu zeptá, zda chcete smazat stažené soubory. Dialog pro povolení přístupu ke kameře zobrazuje náhled. Obzvláště užitečné při přepínání mezi více kamerami. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 143 bude brzy k dispozici také na Flathubu a Snapcraftu.
Byla vydána betaverze Fedora Linuxu 43 (ChangeSet), tj. poslední zastávka před vydáním finální verze, která je naplánována na úterý 21. října.
Multiplatformní emulátor terminálu Ghostty byl vydán ve verzi 1.2 (𝕏, Mastodon). Přehled novinek, vylepšení a nových efektů v poznámkách k vydání.
Osobně jsem podobný incident zažil poprvé,Chápu, ono to chce dlouhodobější statistiky. U mě je to jednoznačné, většina výpadků byla způsobena protivýpadkovým systémem. V racku máme dvě napájecí větve. Kolega si prosadil JEDNU UPSku pro zálohování jedné větve. Druhá byla napojená přímo na DC. A hádej, se kterou větví byl největší problém? USP se rozhodla zkontrolovat aku, aku chcíplo a ta zálohovaná větev spadla. Byla tam většina síťových prvků. Ve výsledku je lepší se na USP v racku vyprdnout, nebo mít dvě fakt dobré a fakt pravidelně udržované (měnit aku po x letech a nečekat, až se jejich parametry zhorší - stojí to pochopitelně dost peněz). Obecně čím méně prvků, tím lépe. O napájení se stará DC, nemusím to řešit. A mám další historky, jak "redundantní" věc způsobila více problémů, než kdyby to prostě bylo single. Selektivita jističů je vždy komplikovaná věc. Impedance sítě je pod 1ohm (často třeba 0,2ohm), takže při zkratu tečou stovky ampér. Jistič neomezuje proud, pouze vypíná. A když máš za sebou 6A, 10A, 16A, 25A, tak při zkratu vypadnou všechny. Proto se často používají pojistky, protože než se ten drátek přepálí, chvilku to trvá. Jistič je mnohem rychlejší (při zkratu). Takže vhodně navrženými pojistkami selektivitu dosáhnout lze. (Ale musí to navrhnout zkušený projektant, řešilo se to roky na elektrika.cz.) Co se týče síťování, tak díky za info, nejsem sítař, psal jsem info z roku 2010. VRRP jsem testoval pro použití s GlusterFS. Fungovalo to, ale pro produkční nasazení jsme nakonec použili něco jiného (zcela jiný storage).
Já osobně mám 10Gbit switche ve stacku, všechny servery připojený přes 4x10Gbit (2x10Gbit pro storage a 2x10Gbit pro app/hypervisory/zálohování/user access).Jo, tohle je rozumné řešení. Na tohle jsme přecházeli někdy kolem 2016. S tím, že pouze dva kabely z jednoho serveru a rozdělení na jednotlivé role se řešilo až pomocí VLAN. Tohle tehdy někomu přišlo jako lepší řešení a ušetřilo se za Xkrát 10GbE síťovky. Fungovalo to spolehlivě. Výměna switche je hlavně o fyzické práci. Konfigurace se nalije ze zálohy a potom jen přepojit porty do správných vlan skupin.
Zaprvé se vždy tradovalo, že se cesta ke storage nemá trunkovat, jelikož to přidává nějaké latence.Storage bylo připojeno primárně přes sas kabel redundantně přímo do diskového pole. iSCSI byla záložní varianta. A opět, přepnutí ze sas komunikace na iSCSI naprosto bez výpadku. Takto upgradovali firmware v těch řadičích a rebootovali je. Za běhu. Jinak máš pravdu, ten sas byl rychlejší než běh po iscsi. To tam bylo opravdu jen jako záložní varianta připojení storage. A ono, když už máš v serveru 2x10GbE síťovky + 2xsas řadič, tak tam dávat ještě další 2x 10GbE pro storage už je trochu moc. V našem případě se volilo trunkování a VLAN pro storage, management a produkční přístup na vmka. Funkční řešení a i ten storage přes to šlapal.
Ne, já jsem to nikdy neměl na starosti a nikomu jsem to na hlavu nehodilTvrdíte teď, tvrdil jste něco jiného.
Zkoušeli jsme to na blokové vrstvě RBDAha, takže vaše tvrzení "shodili jsme Ceph [cluster]" ve skutečnosti znamená shodili jsme konkrétního Ceph klienta. Že mě to nepřekvapuje.
Prostě to nefungovalo.Budiž, tohle beru. Rozhodli jste se použít klienta, který nefungoval, takže nefungovalo řešení, které jste se pokoušeli nasadit. Vy to ovšem od té doby používáte jako zkratku k "Ceph je špatný" a vymýšlíte si metriky tak, aby vám toto tvrzení podkládaly.
RBD byl nepoužitelnýRBD byl nepoužitelný pro vás. To je zase taková vaše lež-nelež (v angličtině je na to pěkný výraz lie by omission), kdy vynecháte nějaký malý detail, aby to vypadalo, že něco, co se vám nelíbí, je horší, než tomu ve skutečnosti je.
A vůbec si netroufám zpochybňovat, že tento výkon někomu jinému může pro jeho služby stačit.To odpovídá na otázku, kam zajdete ve své absurdnosti. Zásadní ovšem je, že přestože vy jste kvůli svému způsobu nasazení nedokázali Ceph použít, neznamená to, že Ceph je špatný, ani to, že jste ho dokázali na počkání shodit, jak tady trvale lžete.
Pricemz sem si 100% jisty, ze hodiny straveny konfiguraci cehokoli, vygeneruji nasledne nejmin tisicinasobek hodin stravenych udrzbou.Ano. Moje zkušenost z praxe je taková, že když nějaká věc jde jen s obtížemi nainstalovat (nebo prostě jen návod na instalalaci obsahuje 200kroků), tak její provoz bude už jenom horší. Fakt nevím, odkud pramení bezbřehý optimismus mnoha kolegů, že stačí projít instalací a všechno bude fajn. Kdy naposledy se tohle stalo?
Predvadecku citrixu sem s kolegackem sejmul behem prvnich 5 minut a bylo po predvadecceMno... raději nic. Já už rozbil takových "nezničitelných" věcí...
krátka mnohem sympatičtější než někdo, kdo soustavě překrucuje všechno co řeknu, hledá ve všem naprosto nepodstatné a vůbec nic neřešící detaily a na těch se snaží vozitNikdo takový se tady sice neobjevil, ale chápu, že když se omezíte jen na tato vybraná kritéria - jak je vaším zvykem - tak vám takový závěr skutečně může vyjít.
Každopádně někteří místní by ti řekli, že řešit failover pomocí RSTP je out of date, protože dnes existují řešení, které splní jak failover, tak mají oproti RSTP možnost využívat všechny trasy (LACP, IRF apod.) U routerů se dost často pro ten základ používá VRRP.Akorát se tím u těch switchů dostáváte asi tak na desetinásobek ceny, protože je potřebujete stackovat, což switche za ~30k umí, ale až switche za ~200k to umí dobře. (A to se bavím jen o gbit switchích)
A jako bonus, pri tom vypadku switche ve skutecnosti dojde k vypadku konektivity, se kterou by si sice kazdy zarizeni melo poradit, ale realne casto neporadi.Je potřeba to vyzkoušet. Při přechodu na 10GbE někdy v tom roce 2016 jsme na to měli síťaře, vše nastaveno, vše odzkoušeno, vše funguje, můžeš si vesele vytahovat kablíky ze switchů a ono to stále komunikuje. Jak je to přesně nastaveno - ty protokoly, o kterých píše Max, já nevím. Ale síťaři to umí. A by bylo fajn, kdyby o tom někdo napsal článek jen pro info, co všechno je možné nastavit a kde jsou limity.
ale ta UPSkaPřesně tak, viz komentář výše.
Tiskni
Sdílej: