Nizozemská vláda ve snaze šetřit a zvyšovat efektivitu s využitím umělé inteligence (AI) hodlá zrušit asi 25.000 pracovních míst ve státní správě. Cílem je postupně dosáhnout ročních úspor až 3,5 miliardy eur (85,2 miliardy Kč). Na konci loňského roku ve státní správě pracovalo rekordních 160.000 lidí. „Nemůžeme pokračovat v tom, co jsme dělali dosud,“ uvedl státní tajemník pro efektivní fungování vlády Eric van den Burg. „Proto
… více »Příspěvek na blogu PRUSA 3D představuje fotoaparát CAIM1 (Counter Artificial Intelligence Machine 1). Uměle vytvořený obsah je každým dnem těžší rozeznat od skutečných záběrů či fotografií, což podrývá důvěryhodnost žurnalistiky, archivních materiálů i každodenní tvorby obsahu. Fotoaparát CAIM1 byl vyvinut právě k tomu, aby ověřoval původ fotografií a videí přímo během jejich pořizování. Uvnitř fotoaparátu se nachází hardwarová Web3 peněženka se zabezpečovacím čipem Tropic Square TROPIC01.
Jonathan Thomas oznámil vydání nové verze 4.1 video editoru OpenShot (Wikipedie). Zdrojové kódy OpenShotu jsou k dispozici na GitHubu. Ke stažení je i balíček ve formátu AppImage. Stačí jej stáhnout, nastavit právo na spouštění a spustit.
Při běžné migraci virtuálního stroje mezi hypervizory se jeho MAC adresa přesune na jiný leaf switch. EVPN tuto změnu distribuuje pomocí BGP Type-2 route a MAC mobility sequence number. Problém nastává, pokud útočník podvrhne zdrojovou MAC adresu jiného zařízení. Leaf může změnu interpretovat jako legitimní přesun MAC a rozšířit ji přes BGP do celé fabric. Výsledkem může být přesměrování provozu určeného původnímu zařízení. Autor článku rozebírá možnosti detekce pomocí sledování MAC moves, BGP route reflektorů a kontroly na přístupové vrstvě.
Vývojáři desktopového prostředí Enlightenment (Wikipedie) a souvisejících knihoven Enlightenment Foundation Libraries (EFL) vydali nové verze. Enlightenment byl vydán ve verzi 0.28.0 a Enlightenment Foundation Libraries ve verzi 1.29.
Cloudflare zjistil, že některé odpovědi modelu GLM-5.3 obsahovaly části dat z předchozích požadavků jiných zákazníků. Příčinou byla kombinace chybné konfigurace a chyby v inference enginu SGLang. Model podporoval kontextové okno 1 048 576 tokenů, ale GPU KV cache pool měl kapacitu pouze 681 280 tokenů. Při překročení kapacity docházelo k nesprávnému zpracování odmítnutého požadavku. Decode část systému následně pracovala se starými
… více »Vývojáři Knot Resolver vysvětlují, jak změnili rozhodování o tom, které DNS záznamy ponechat v cache a které odstranit. Článek obsahuje skutečná měření: devět hodin DNS provozu při 2 000 QPS, srovnání cache o velikosti 25 MB a 40 GB a také porovnání s BIND 9, kromě algoritmů obsahuje konkrétní doporučení pro konfiguraci a diagnostiku.
Největší kryptoměnová burza světa Binance se stala terčem útoku, při kterém podvodníci odcizili během několika minut kryptoměny v hodnotě přibližně 6,3 miliardy dolarů. Jedná se o největší kryptoměnovou krádež v historii, přibližně čtyřikrát větší než loňský útok na burzu Bybit. Binance se podařilo ve spolupráci s partnery zmrazit aspoň aktiva v hodnotě zhruba 3 miliard dolarů a slíbila, že veškeré ztráty pokryje z vlastních prostředků.
Zranitelnost CVE-2026-98432 s CVSS 9.8 odhalila AI od společnosti Anthropic. Jedná se o kritickou chybu v implementaci MPTCP (multipath TCP). Debian vydal patche 16.10. a 22.10., ale např. Ubuntu je zatím bez opravy. Více informací na The Hacker News.
Na Slovensku vznikla úplne nová rally hra, ktorá je zadarmo a funguje vo Windowse, Linuxe či na Macu. Greenie Rally má viac ako 50 tratí a vozidiel, šampionáty či turnaje. Má retro feeling a imituje automobilové hry z prelomu tisícročí. Vyskúšate prejsť všetky mapy na Škode 130RS?
fyzický disk -> LUKS > btrfs RaidNicméně tak jsem se s btrfs seznámil, tak btrfs v žádném případě nezjištuje stav fyzického zařízení v jiném smyslu, než že přečte z blokového zařízení data a na příslušném bloku si zkontroluje checksum. V podstatě vždycky
Spoléhá tedy na to, že data, co mu vrací ta mezivrstva jsou ok.Nižší vrstva LUKS v XTS modu a (stejně si myslím že i v jiných) nemá žádnou kontrolu a vezme blok z disku, prožene ho algoritmem a dodá blok do vyšší vrstvy. A můžeme to chápat jako prosté substituční zobrazení blok na blok, kdy samozřejmě zobrazení závisí na číslu bloku. Pokud btrfs pracuje se stejnými bloky jako LUKS, tak podstavná vrstva nesníží nijak obecnost a spolehlivost btrfs, protože ano při malé chybě v HW dodá LUKS sice zcela jiný blok, ale ten by i při malé chybě btrfs označil jako chybný a řešil chybu na úrovni bloku. Pokud nejsou data z LUKSu ok, není to, že problém má LUKS (pokud by nenastalo nějaké kritické prolomení) ale problém má HW, LUKS ten problém přenese na vyšší úroveň a btrfs ho identifikuje. A šifrovat nad btrfs? Netuším jak to provést na blokové úrovni. Možná na úrovni souborů, ale tím jsou názvy souborů a struktura adresářů veřejná, veracrypt kontainer a cokoliv, co nevyužije CoW je nesmysl. Jediná nevýhoda, kterou v mém postupu vidím, že stejná data se pro každý disk šifrují jinak, takže zvýšení zátěže u krypto vrstvy. Jinak vše mi připadá OK a tento zvýšený overhead akceptuji.
Nicméně tak jsem se s btrfs seznámil, tak btrfs v žádném případě nezjištuje stav fyzického zařízení v jiném smyslu, než že přečte z blokového zařízení data a na příslušném bloku si zkontroluje checksum. V podstatě vždyckyTo sice jo, ale z principu, protože jde o COW systém bych řekl že tam dochází k většímu žonglování s daty, protože šifrování produkuje víceméně nedeterministické shluky dat se kterými firmware disku nedokáže efektivně pracovat. Ale nevím. Možná se mýlím.Spoléhá tedy na to, že data, co mu vrací ta mezivrstva jsou ok.
A šifrovat nad btrfs? Netuším jak to provést na blokové úrovni.Samozřejmě že v takovém případě se to nedělá na blokové úrovni. Šifrují se data co tečou mezi FS a userspace. Ale nevím. Nepoužívám to, protože mě k tomu nic nenutí a navíc šifrování dat považuji za zbytečnou obstrukci, protože kdo chce data ukrást, tak si najde jiný, mnohem efektivnější způsob, než je louskání čmajznutého zařízení. Ale pokud ti ten zbytečný overhead nevadí, tvoje věc.
protože šifrování produkuje víceméně nedeterministické shluky dat se kterými firmware disku nedokáže efektivně pracovat.Myslím, že data firmware disku nezajímají. Kompresované video silnými algoritmy je podobně "nedeterministické" (a myslím tím stream a ne obálku) FW vezme blok a uloží jej na pozici, max si zefektivní mechanické pohyby čtecích hlav. A CoW (ale jakýkoliv FS) ať dělá co chce, tak má elementární operaci s blokem dat a pokud je stejná velikost mezi FS vrstvou a diskem tak je to transparentní. (problém jsou když ty velikosti stejné nejsou a někdy ani nemohou být např standardní RAID 5 nad 4 disky má základní velikost
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz3 x strip a to není 2^x pro žádné x)
Netuším, co tím můžeš myslet. Na úrovni FS potřebuješ zašifrovaná data a v paměti potřebuješ pracovat z rozšifrovanými daty. Pokud na disku nepotřebuješ zašifrovaná data a fyzickou bezpečnost máš zajištěnu jinak, nemusíš šifrovat. Stavět zašifrovaný souborový FS jako ecrypt nad btrfs je také pitomé.A šifrovat nad btrfs? Netuším jak to provést na blokové úrovni.Samozřejmě že v takovém případě se to nedělá na blokové úrovni. Šifrují se data co tečou mezi FS a userspace.
[...] šifrování dat považuji za zbytečnou obstrukci, protože kdo chce data ukrást, tak si najde jiný, mnohem efektivnější způsob, než je louskání čmajznutého zařízení [...]pokud nesifrujes tak nemusi nic louskat ani hledat jinej zpusob jak zistat data, kdyz mu je rovnou "das" nesifrovana
19.7.2020 22:24
mount -o degraded ... (nebo si ten "souhlas" dát do fstabu či linux cmdline).
Nikoliv. Tohle je naprosto správná reakce na ztrátu redundance. Je dobře, že se konečně opravdový RAID takhle chová. Názory, že pole, které má garantovat redundanci, by se mělo bez redundance jen tak sestavit a fungovat, jsou hluboce zakořeněná pověra, která ne a ne chcípnout. 
Situace s jedním poškozeným diskem v RAID1 se (zcela správně) považuje za kritickou. Data v takové situaci "bojují o holý život", řečeno patosem. Jediným a prvořadým cílem musí být obnovení redundance, nikoliv "obvyklý" provoz systému.
Kdyby se filesystém namountoval, jako by nic, dovedu si živě představit davy takyadministrátorů bez řádného monitoringu, jak by to napřed pár měsíců nepostřehli, pak by to dalších pár měsíců nechali dál "fungovat", když to do té doby "fungovalo", a nakonec by selhal i druhý / další disk. 
Řekl bych, že Facebook i řada dalších uživatelů Btrfs v business-critical nasazení ví velmi dobře, proč jim zrovna tohle chování vyhovuje.
pokud by pri 4x Disk v RAID1 delalo opravdovej RAID1, tedy mirror pres vsechny disky, nikoliv pouze block vzdy jen na dva, tak by toto degradovani kriticke nebylo...
Aha — takže 4 disky by měly mít v raid1 profilu kapacitu jednoho disku, podle tvého světonázoru?
Mimochodem, ráčil ses obtěžovat přečíst si dokumentaci? Tipuju, že (jako obvykle) ne. Proč číst dokumentaci, když se dá střílet od boku, že jo… Inu, je to takhle:
raid1 — 2 kopie, 1/2 kapacityraid1c3 — 3 kopie, 1/3 kapacityraid1c4 — 4 kopie, 1/4 kapacityTakže, kdyby tazatel opravdu (ale opravdu) chtěl 4 kopie — výměnou za polovinu kapacity ve srovnání s raid1 —, asi by zvolil raid1c4, ne?
Pojďme se ještě bavit o tom, jestli by se degraded pole s jedním chybějícím diskem mělo automaticky namountovat v raid1c4, dejme tomu.
Ne, nemělo.
Proč? Inu, ze stejného důvodu, ze stejného principu: Souborový systém má garantovat odolnost proti selhání kterýchkoliv 3 disků. Je v situaci, kdy tuhle odolnost garantovat nedokáže. Tedy situace je kritická a je na uživateli, aby rozhodl, jak ji řešit. To je stejná situace jako u raid1, jenom jiné N.
Pokud někdo s touto^^^ zásadou nesouhlasí, řešení je jednoduché: přidat do příkazové řádky kernelu rootflags=degraded (a někdy taky přidat degraded do /etc/fstab). Hotovo. Pak se to namountuje stůj co stůj, žádný problém, a řádný monitoring si musí uživatel zajistit po svém. Nebo taky ne; to už je jeho problém.
…i kdyz BTRFS dedela opravdovej RAID1, a kvuli obavam o data pri rebootu nesestavi pole, melo by alespon pripravit emergency consoly s dostupnym SSH, aby kompetentni admin usoudil zda nez se fyzicky dostavi na misto muze server nastartovat, nebo zda ma cekat nenastartovanej...
Huh? Cože? Že by jako Btrfs měl znova vynalézt kolo a vymyslet to, co normálně dělá + má dělat userspace v initramdisku? Jako vtip dobré.
Emergency shell je už asi tak 10+ let normální věc, ve které skončí každé distro, když se nepodaří otevřít a namountovat kořenový souborový systém. Nic nového pod sluncem. Tam se dají taky upravit parametry Btrfs.
Jestli má initramdisk SSH přístup, to už je věcí nastavení — nikoliv úkolem pro Btrfs. Serverový hardware má sériovou konzoli na odděleném ethernetu, takže mít SSH přístup do initramdisku by byl těžký overkill; stačí vzdálený přístup na sériovou konzoli. Hardware jiný než serverový je většinou vedle na stole, takže se bez SSH přístupu do initramdisku obejde.
Proč nemá initramdisk (většinou) lepší podporu pro Btrfs než obecnou konzoli, na to se ptej všech těch distribucí, které mají přes deset let zpoždění v zavádění Btrfs jako implicitního souborového systému. Dokud nebude Btrfs implicitní souborový systém, těžko se dá čekat 100% podpora pro jeho pokročilé funkce v initramdisku. Naštěstí se doba konečně mění a Fedora bude mít konečně (proč to 10 let trvalo???) Btrfs jako implicitní souborový systém. Snad se pak i podpora v initramdisku + dracutu výrazně zlepší.
Btrfs vynalézá jako první kolo, protože předchozí AIDy bez R ho nevynalezly. Nějaké další dotazy k tomu?
Netušíš, která bije. Howgh. A ještě se tím chlubíš. Doprdele šulin čurák piča už.
RAID 1-6 jsou naprosto jasně definované — bezva —, jenže žádná údajná implementace takové definice nesplňovala, dokud nepřišel ZFS a poté Btrfs.
ZFS a Btrfs poprvé implementují skutečnou redundanci. Bez planých slibů, s rozumně definovanými garancemi, atomicitou atd.
Na ZFS nebo Btrfs selhání jednoho disku nikdy neposere všechna data na RAID1, RAID 5 nebo RAID 6. Na nějakém fosilním nesmyslu, který je údajně jasně definovaný, přesně totéž selhání jednoho disku pošle do kytek všechna data. Už se to tady řešilo asi tak stokrát. Už je ten anti-Btrfs FUD fakt únavný.
Nechceš používat rozumný filesystém? Nemáš rád svá data? Dobře! Ale proč si to nenecháš pro sebe? Proč se tím chceš chlubit?
Zatímco Btrfs a ZFS opravdu garantují redundanci, AID bez R (tedy jakýkoliv údajný RAID před ZFS a Btrfs) nikdy nic negarantoval a naivně spoléhal na funkce (modelově dokonalých) disků, které zmizely v době, kdy se kapacita přehoupla přes 100 GB nebo tak. Jinými slovy, de facto negarantoval nic, zatímco de reklamí žvásty garantoval modré z nebe.
Ty jsi ale trouba k pohledání!
Kde přesně RAID1 něco říká?
Kde přesně RAID1 říká, že na všech discích jsou stejná data?
Ale hovno. Nikdy na všech discích nejsou stejná data. Už proto, že tam vždy musí být metadata, ať už jde o AID bez R nebo skutečný RAID, a ta metadata musí obsahovat nějakou unikátní (unikátní — chápeš, co to znamená, jo?) identifikaci každého disku.
Ach jo. Anti-Btrfs FUDisté a jiní mamlasové jsou únavní a otravní. Už to fakt stačí. Nemáme rok 2010.
Tiskni
Sdílej:
