Vývoj linuxové distribuce Clear Linux (Wikipedie) vyvíjené společností Intel a optimalizováné pro jejich procesory byl oficiálně ukončen.
Byl publikován aktuální přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie).
V programovacím jazyce Go naprogramovaná webová aplikace pro spolupráci na zdrojových kódech pomocí gitu Forgejo byla vydána ve verzi 12.0 (Mastodon). Forgejo je fork Gitei.
Nová čísla časopisů od nakladatelství Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 155 (pdf) a Hello World 27 (pdf).
Hyprland, tj. kompozitor pro Wayland zaměřený na dláždění okny a zároveň grafické efekty, byl vydán ve verzi 0.50.0. Podrobný přehled novinek na GitHubu.
Patrick Volkerding oznámil před dvaatřiceti lety vydání Slackware Linuxu 1.00. Slackware Linux byl tenkrát k dispozici na 3,5 palcových disketách. Základní systém byl na 13 disketách. Kdo chtěl grafiku, potřeboval dalších 11 disket. Slackware Linux 1.00 byl postaven na Linuxu .99pl11 Alpha, libc 4.4.1, g++ 2.4.5 a XFree86 1.3.
Ministerstvo pro místní rozvoj (MMR) jako první orgán státní správy v Česku spustilo takzvaný „bug bounty“ program pro odhalování bezpečnostních rizik a zranitelných míst ve svých informačních systémech. Za nalezení kritické zranitelnosti nabízí veřejnosti odměnu 1000 eur, v případě vysoké závažnosti je to 500 eur. Program se inspiruje přístupy běžnými v komerčním sektoru nebo ve veřejné sféře v zahraničí.
Vláda dne 16. července 2025 schválila návrh nového jednotného vizuálního stylu státní správy. Vytvořilo jej na základě veřejné soutěže studio Najbrt. Náklady na přípravu návrhu a metodiky činily tři miliony korun. Modernizovaný dvouocasý lev vychází z malého státního znaku. Vizuální styl doprovází originální písmo Czechia Sans.
Vyhledávač DuckDuckGo je podle webu DownDetector od 2:15 SELČ nedostupný. Opět fungovat začal na několik minut zhruba v 15:15. Další služby nesouvisející přímo s vyhledáváním, jako mapy a AI asistent jsou dostupné. Pro některé dotazy během výpadku stále funguje zobrazování například textu z Wikipedie.
Více než 600 aplikací postavených na PHP frameworku Laravel je zranitelných vůči vzdálenému spuštění libovolného kódu. Útočníci mohou zneužít veřejně uniklé konfigurační klíče APP_KEY (např. z GitHubu). Z více než 260 000 APP_KEY získaných z GitHubu bylo ověřeno, že přes 600 aplikací je zranitelných. Zhruba 63 % úniků pochází z .env souborů, které často obsahují i další citlivé údaje (např. přístupové údaje k databázím nebo cloudovým službám).
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: