Na čem aktuálně pracují vývojáři GNOME a KDE? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE.
Před 70 lety, 7. června 1954, ve věku 41 let, zemřel Alan Turing, britský matematik, logik, kryptoanalytik a zakladatel moderní informatiky.
NiceGUI umožňuje používat webový prohlížeč jako frontend pro kód v Pythonu. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána ve verzi 2024.6. Z novinek lze vypíchnout lepší integraci LLM (OpenAI, Google AI, Ollama) nebo podporu Matter 1.3.
IKEA ve Spojeném království hledá zaměstnance do své nové pobočky. Do pobočky v počítačové hře Roblox. Nástupní mzda je 13,15 liber na hodinu.
Alyssa Rosenzweig se v příspěvku na svém blogu Vulkan 1.3 na M1 za 1 měsíc rozepsala o novém Vulkan 1.3 ovladači Honeykrisp pro Apple M1 splňujícím specifikaci Khronosu. Vychází z ovladače NVK pro GPU od Nvidie. V plánu je dále rozchodit DXVK a vkd3d-proton a tím pádem Direct3D, aby na Apple M1 s Asahi Linuxem běžely hry pro Microsoft Windows.
Byla vydána (𝕏) květnová aktualizace aneb nová verze 1.90 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Ve verzi 1.90 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Byla vydána (Mastodon, 𝕏) nová verze 2024.2 linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux (Wikipedie). Přehled novinek se seznamem nových nástrojů v oficiálním oznámení.
Počítačová hra Tetris slaví 40 let. Alexej Pažitnov dokončil první hratelnou verzi 6. června 1984. Mezitím vznikla celá řada variant. Například Peklo nebo Nebe. Loni měl premiéru film Tetris.
MicroPython (Wikipedie), tj. implementace Pythonu 3 optimalizovaná pro jednočipové počítače, byl vydán ve verzi 1.23.0. V přehledu novinek je vypíchnuta podpora dynamických USB zařízení nebo nové moduly openamp, tls a vfs.
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: