Názory k článku
Linus Torvalds skládal počítač na youtubovém kanále Linus Tech Tips

Linus a Linus a Linux. ;-)

vůbec nezvládám koukat na videa od toho kluka, je tam něco zajimaveho mimo doporučeni ECC a skladani pc?

tak me ty videa celkem bavi, koukam uz na to nekolik roku a je to fajn.
s timhle dilem me obzvlaste potesil.

Asi tak. Občas mi některý jeho tvrzení přijdou "poněkud" diskutabilní, ale většinou je to racionální a dá se na to koukat nebo to aspoň pustit jako kulisu, protože to umí udělat zábavně.

Nebolo tam nič také, ale celkom milé to bolo, toho tipka nezvláda ani Linus (ozajstný), párkrát ho zotrel.

jsem rád, že ECC pronikají i do osobních počítačů. Jak nám paměť rostě, vše se zmenšuje, vliv je nemalý. Zajímavé ale je kolik lidí je schopno se rvát do krve, že ECC je zbytečná, že jí nemá a nikdy žádné problémy nepozoroval.

Paměť bez ECC neumí ani chyby odhalit, takže je pak těžké vůbec říct, jestli se dějí. Řada chyb v paměti nemusí vůbec nic způsobit nebo to má tak malý vliv, že to nelze zpozorovat. To je argument bez dat.

Zo zvedavosti by som sa chcel opýtať, aký je scénar, keď by mi na osobnom počítači vadilo, že sa mi preklopí bit v pamäti RAM?

Třeba se ti blbě zkopíruje soubor. V lepším případě ti něco crashne, nebo třeba přijdeš o nějakou práci. Tisíce možností, co se může stát.

Zrovna pro kopírování souborů by bylo dobré mít i nějakou kontrolu na aplikační úrovni. To není jen RAMka, ale i řadiče disků, disky a jejich firmware a případně síť, pokud to není v rámci jednoho počítače.

Ale viete že TCP používa kontrolné sumy.

Ty kontroly všude jsou a budou ok. Když se ti v RAM flipne bit, tak ten soubor prostě zapíšeš poškozený, a všechy ty řadiče disků s tím budou souhlasit, protože neví, že ten bit má být jiný.

Ono hodně záleží na tom, kde se to flipne. U nějakého video streamu to třeba jen pokazí pár framů. U něčeho důležitějšího to může ale způsobit, že ty data nenačteš.

Pokud systém na nějakou pozici v paměti zapíše nějaká data, tak očekává že tam následně ta stejná data budou.

jak preklopi? jako blip a to prece nemuze vadit? KOmiku.

tyden mi padal firefox, nic jineho. silel jsem z toho. ztratil furu casu. az mne napadlo run mem test a samozrejme ta horni cast pameti, kam obcas firefox s mnoha taby doputoval, sedel na DImmu plnym chyb.

alespon paritni pameti kdyby zustaly standardem

Tu nehovorím o PEBKAC, ale o reálnej potrebe ECC.

PEBKAC se za mě říkalo uživatelské chybě, když někomu padá program a pak zjistí že je závada v HW, tak to není PEBKAC, a je to dobrá ukázka proč by se hodilo chybu detekovat rychleji, ne?

Já se nejvíc bojím neopravitelné chyby filesystému (bitflip v nějakých zásadních metadatech, kvůli kterému se ztratí přístup k části stromu) nebo databáze (spousta aplikací používá sqlite pro ukládání uživatelského nastavení a dat).

Nepříjemné to může být i pokud děláte nějakou dlouho běžící numerickou simulaci/opti­malizaci a nemůžete věřit výsledkům, podezříváte, že jste do programu zanesli bug atd.

4. 12. 2025, 11:49 editováno autorem komentáře

Muzes pouzivat FS, ktery chrani data opravnymi kody a nebo blokove zarizeni, ktere to dela nezavisle na FS. Pstore a ubifs, ktere cili na potencialne nespolehlive pameti, to delaji by default.

Opravdu to chrání (meta)data před poškozením když se s nimi manipuluje v RAM? Běžné FS s checksumy (btrfs, zfs) chrání data při zápisu na disk (a jinak metadata má checksumované i třeba ext4). Uvedené FS neznám ale co jsem si vygooglil tak pstore je nějaká specialita pro ladění crashů, a ubifs vypadá jako že spočítá právě checksum bloku při zápisu na disk - ono chránit se proti chybě RAM asi ani v principu spolehlivě nejde, když nemůžeš věřit svým vlastním výpočtům.

Tak jestli jedna oblíbená hra spadne do CTD 3x denně kvůli modům, zatímco druhá vydrží týden+, tak to jsou dostatečně průkazná empirická data k podobnému tvrzení.
To samé platí třeba co se týče nutných přeinstalací Win.

Ve vědě se tomu říká upper limit/upper bound, a samozřejmě, že je to relevantní údaj (se kterým je třeba správně pracovat - asi něco jiného je use case serveru, a něco jiného je herní PC, kde případný efekt je prostě zastíněn mnohem výraznějšími efekty, jako nestabilita hry nebo nějakého driveru).

Chyba, ktera nic nezpusobi nebo jeji nasledky jsou tak male, ze nejdou pozorovat, tzn. ze bitflipy pokud se deji, tak jsou casto benigni - takovy argument bych cekal spise od odpurce ECC, ne od zastance :)

Ja rozhodne nejsem militantni odpurce ECC, zejmena v profi nasazeni. Vlastne jsem 6 let pouzival dual Xeon s ECC (behem te doby zadnou chybu neodchytil, reportovani bylo zapnute a memory patrolling take). Ale musim se pridat na hromadku tech, kteri problemy nepozoruji... v 2022 jsem ublognul "Dva roky uptime na PC s Windows aneb příběh jedné sázky" zde

https://www.abclinuxu.cz/blog/Mihovy_sochory/2022/12/dva-roky-uptime-na-pc-s-windows-aneb-pribeh-jedne-sazky

(pokus probihal na PC s 256GB, z nichz je vetsina trvale obsazena) a je tam i kapitola venovana ECC. Pokud bude mezi svatky cas, tak tam dam pokracovani: "Pet let uptime na PC bez ECC". Aj, to bude stavnata diskuze pod clankem ;-)

2. 12. 2025, 10:14 editováno autorem komentáře

Jenže to, že to zrovna tobě vyšlo, statisticky nic neznamená.

Zrovna v tomhle mam dobrou zkusenost z produkcniho nasazeni radove stovek tisic instanci vestaveneho systemu, kde si zakaznik z duvodu uspory rozhodl v dobe produkce prestat pouzivat ECC pameti. Rozdil crashu se lisi az ve 3. radu (0.00..0XXX vs 0.00..0XXY), takze to je to z pohledu nasazeni naprosto zanedbatelne a hlavni problem je, ze pri analyze padu clovek nevi, jestli mohlo dojit k prepnuti bitu a nebo ne. To vyresili tak, ze se analyzuji pady primarne z tech asi 10% systemu, ktere ECC maji.

bitflip se mohl přihodit třeba v paměti, která aktuálně není využívaná nebo v oblasti, která obsahuje nestrukturovaná binární data (třeba video), kde změna nemusí být žádný velký vliv na venek. Ne vždy jsme schopní exaktně tu změnu poznat a detekovat, to jsem myslel.

Je to prostě hra na ruskou ruletu, nikdy nevíš, kdy to může být příčinou jaké nestability nebo problému s chováním.

Je nějaká statistika, jak časté jsou chyby paměti (bitflip)? U nás na TB RAM jsem ECC chybu paměti ještě neviděl.

Ja pouzivam osobne pocitace bez ECC 40 rokov a zatial som mal jednu vadnu RAM.

RAMky nestály za moc v dobách DOS a Windows 9x. Windows NT, pro domácí uživatelé to znamenalo od Windows 2000, shit sestavy padaly kvůli RAMce. Výrobci RAMek zlepšili jejich kvalitu a od té doby je to pro běžné používání většinou bez problému.

EDIT: On jako počítač při bootu RAMky zkontroluje na základní úrovni, což vyřadí většinu RAMek dřív, než byste do nich lil data. Mně třeba odešel slot na RAMku kvůli prachu a zkratu, moduly fungují v ostatních slotech.

2. 12. 2025, 12:38 editováno autorem komentáře

Za 30 let a destiky TB ... sem chyby ram videl reportovat jen jednou, na dellim serveru, a chyba nebyla v ram ale v MB a bylo to false pozitive.

Takze bych to videl tak, ze ECC je sice fajn mit, ale neni to nic zasadniho a na desktopu ... lol.

1-4TB RAM sestavy na levnem hw( dell/hp x86) uz jde nejake ecc chyby vidět zkrz 60 stroju. Je to male DC ( stará ustredna AT&T). Servery jsou ve vrchních patrech coz muze hrát určitou roli. Sever USA.

2. 12. 2025, 13:12 editováno autorem komentáře

My máme aktuálně cca 60TB RAM celkem a ještě nic. Je pravda, že serverové ram jedou na velmi konzervativních frekvencích, na desktopu se to může stát i kvůli velmi rychlému a méně častému refresh, ale na serveru jsem ECC ještě neviděl. To neznamená, že tam nemá být, já jsem příznivec ECC i na desktopu, ale těch chyb obecně není tolik, kolik bych čekal.

(Totéž platí i pro disky, od roku cca 2006 si dělám u všech souborů sha sumy (aktuálně sha3-512) a žádný soubor nikdy nezměnil ani jeden bit.)

Uvědomujete si, že ve spoustě aplikací je jedno, že systém nebo aplikace prostě tu a tam spadne? Nevítězí věci nejlepší a nejfunkčnější. Používá se to, co je dostatečně dobré. A to je veliký rozdíl.

Dostatečně dobre je relativní pojem. Treba neni problem kdyz systém spadne. Ale S JAKYMI daty spadne!!! Jak je invalidujete, jak oddělit dobrá data od špatných atp.

2. 12. 2025, 15:28 editováno autorem komentáře

Pokud by např. spadl před zápisem špatných dat, tak je to ještě hodně v pohodě. prohrabávat se daty a řešit, co je dobře, je masakr :-)

2. 12. 2025, 15:30 editováno autorem komentáře

Herni pocitac, kdyz pada hra vic nez malo: prava krysa -> properties -> Installed Files -> Verify integrity of gaming files"
Těch míst, kde by případný bitflip nebo pád průměrného "Počítač v kuchyni" vadil, je opravdu minimálně, a míst, kde by nehrozilo řádově vyšší nebezpečí (třeba že odejde disk úplně, nebo to ani nemá UPSku...) jen velmi stěží budete hledat problém.
Však "resetni instalaci desítek do defaultu" je dost časté řešení wokeních problémů already ;-)

Z druhé strany u databáze nebo fileserveru samozřejmě není co řešit, u nějakého frontendu, na kterém nejsou data, bych se sice z principu ne-ECC bránil zuby nehty taky ale asi (pokud přes to netečou prachy) by asi nebylo úplně triviální to obhájit, zvlášť když se při jakémkoli problému dá strašně rychle ta instance zrušit a nechat vyprovisionovat dvě jinde.

Jistě:// https://theregister.com/2025/12/01/a320_software_rollback/

Pojdme si pohovorit o tom co znamena slovo "treba". A take si pojdme pohovorit o sirsim kontextu diskuse. Neresime zde specializovane embedded systemy na avioniku ale obycejna pecka.
To co zminuji je uplne nejvic worst case supacky scenar kdy akceptuji ze dany system spadne. A kdy dejme tomu akceptuji i poskozeni dat in transit.
Je avionika/FBW takovy system kde je to akceptovatelne? Kdy si zaparkuju na oblacku a dam si kafe nez se rozhodnu co dal protoze mam dost casu? Neni! Proto jsem pouzil slovo treba.

A pak ti prijde nejaky trdlo a chce si na non-ecc systemu postavit nasku nebo co já vím home bgp core router s kubernetes hostujici cely startup o trech lidech. Od toho snurou na prádlo připojené disky/sitovka přes USB... A ostatní tomu tleskání bububu Trident je srab, ma totiz strach ze ho bit flip baci...
Vzdyt ECC mají uz snad i poslední raspi.

A čo ako. Na 99.999% to bude fungovať. Ak je to dostačujúce v čom je problém? Ja v aute tiež už nemám rezervu, šialené že?

Mate asistencku/od­tahovku nebo lepení ( ktere stejne moc nefunguje). Ze zákona musite mít nějaké z těch reseni. Vyměnila se jen forma ochrany proti nenadále události ale nepřestala se resit uplne.
Navíc u řady aut je kolo porad optional nebo standard ( off roady).

2. 12. 2025, 15:28 editováno autorem komentáře

V drtivý většině případů to bude úplně jedno. Jenže pak jednou přijde monstrózní blb a zapomene se zmínit, že na tom chce pást informační systém lékařský dokumentace nebo řízení etylénovejch pump v rafinérce.

Většinou tyhle kraviny vymysli develove nebo manažeři mimo IT co se lituji do infra. Důkaz je ze 8 let se nic nestalo a tak se nestane nic i v příštích letech a podobné koniny. Bez nejake kalkulace mozne skody. Treba je potencialni skoda tak mala ze pad nějakého keplu nestoji ani MD vyvojare.
Rozumný devel ví kde jsou jeho hranice a mazer jsy se ma zeptat. Já taky neradim našim expertům na routing.
Ideální je papírová valka/SLA/prevzeti odpovednosti a vse si archivovat. Nechcete byt odpovedni za cizi rozhodnutí a pak to resit az treba u soudu.
Tedy za predpokladu ze vam to nereguluji normy daneho odvetvi/securitaci. Tam pak mate lehci praci.

3. 12. 2025, 14:41 editováno autorem komentáře

Moje "NAS" je starý desktop s nízkou spotřebou, kterému se o nějaké ECC může nechat jen zdát. Platí pro něj přesně to, co jsem napsal nahoře. Ale samozřejmě vy víte vždycky nejlíp, co potřebují ostatní, jasné... Jak jsem psal, nakonec je vždy nejúspěšnější to, co je dostatečně dobré, nikliv nejlepší. A pro drtivou většinu SOHO aplikací (včetně valné většiny domácích NAS) je prostě dostatečně dobrá i non-ECC RAM.

Víc v tom fakt nemá smysl hledat.

2. 12. 2025, 17:27 editováno autorem komentáře

pro něj přesně to, co jsem napsal nahoře - sebeklam neni důkaz o vhodnosti.
Řekněte kolik tam hostujete dat a jaké mate toky a co je to za data?Máte tam treba btrfs/zfs? Máte shared volumy? Nějaká file based db? Slozitejsi lockovani souboru?
Dneska každý uz ma dneska aspon desítky TB dat nekde doma.
Na druhou stranu kapesní nas je rada ze ma dobry kontakt na sd kartě a tam ecc typicky neresite- druha hranice problemu.

2. 12. 2025, 23:56 editováno autorem komentáře

"Dneska každý uz ma dneska aspon desítky TB dat nekde doma."

o'rly?

AMD Ryzen Threadripper 9960X
Default TDP 350W

Tak to je pohoda...

Si říkám, jestli to má Torvalds vůbec zapotřebí. Linus (ten z USA) má asi 100 různých kanálů a jen těží monetizaci YT.

Myslel si toho Linusa z Kanady?

Kazdy sa nejak zivi :) pre Torvaldsa to moze byt fun propagacia Linuxu, pre Sebastiana sposob ako ziskat sledovanost. Obaja si spolupracu mozu dovolit.

No jenže je vždy otázka o co kdo může přijít nebo získat. Stavit se jako expert na OS a autor nejrozšířenějšího kernelu na planetě k někomu postavit počítač a tím mu zvýšit prestige, je podle mě trochu mimo Torvaldsovu zónu zájmu. On může dost bodů ztratit. Ale tak já obecně nemám rád kanály vydělávající na banalitách a senzacích.

Sám si myslím, že to všichni, kdo opravdu věci rozumní, berou jako recesi. I když věřím, že si Linus, jak říká, již dlouho počítač sám nestavěl. A nakonec to vyšlo i jako dobrý kompromis udělat reklamu jak AMD (kde Zen je opravdu špička návrhu) tak i pomoci Intelu, kde odvedl na novém GPU mnoho práce, přítom i před tím po desetiletí podporoval open source řešení a obecně alternativa i na LLM je potřeba. Takže za mě to vyšlo v pořádku a Linus Torvalds si videem ostudu neudělal. Nevím, jestli si nechal zaplatit, a spíš by se mi líbilo, kdyby to v tomto případě neudělal. Potřebu pro to tak nemá. Velké peníze od těch, co na jím založeném systému vydělávají, mu ale velmi přeji.

Škoda jen, že neudělali větší reklamu Fedoře a desktopovému Linuxu jako takovému. Jinak docela fajn video.

"...si počítač už dlouho nestavěl..." ???
Vždyť to není dlouho, co šly články jak si POSTAVIL ThreadRippera a značně do hloubky vysvětloval jednotlivý volby komponent.

Jakych banalitach a senzacich? Za tou showmanskou prezentaci je seriozni prace tymu 100+ lidi, kteri testuji, maji dilnu na stavbu custom veci, lab na testovani hluku, chlazeni, zdroju,... Nektera videa povazuju za super zajimava, treba jak si sami staveli a konfigurovali 2PB ZFS nvme storage a mnohe dalsi serverove zamerene. Testy dual Epycu ti moc jinych kanalu neudela. Ze tam do toho zamicha i jak na tom hrajou hry to je zkratka dan, aby se na to podivalo vic, nez 5 lidi ;-) Ale predpokladam, ze jsi se vlastne na nic z jeho tvorby nedival (jinak bys netvrdil, ze je z USA) a jen tak hejtis z hladu ;-)

To není hejt. Já na něj před mnoha lety koukal, ale potom tam začal přidávat více "bombastického" obsahu a tím se stal v podstatě stejným, jako další tisíce YT kanálů. Ničeho zase tak extra zajímavého pro technické lidi jsem si tam nikdy nevšiml. Pokud má někdo rád tu šou, tak ok, ale já tohle nesleduju.

Do stejného bahna jednu dobu spadl i Jeff Gerling, ale potom se docela uklidnil a ještě tam přidal kanál svého táty, který dělá inženýra na vysílačích (velkých), takže je to fajn obsah.

Není z USA, ale z Kanady. Na těch kanálech, kterých je asi 8, se podílí vyšší desítky lidí pod hlavičkou Linus Media Group. Je to business jako každý jiný, který Linus navíc vybudoval z ničeho.

2. 12. 2025, 10:46 editováno autorem komentáře

Tak sám si myslím, že si to Linus Torvalds užil jako roli v divadelním vystoupení, kdy vystoupil ze své běžné polohy, kdy je to spíš takový chlápek v diskutující v davu bez ambicí být dominantní osobou. A podle mě to zahrál dobře a s humorem, který pod tou skořápkou je. Ten druhý Linus má snahu se prodat za každou cenu a daří se mu to. Pokud vím, tak naši studenti ho celkem sledují a je to pro ně zdroj technických informací. Sám, co jsem jimi sdílené a nadšené odkazy na LTT několikrát nakonec shlédl, tak mi připadaly všechna videa plná vaty, nepřesností a s chybějící technickou informací, možná někde nějaká kuriozita, Wow efekt a obecně škoda času. Ale zdá se, že jiným to jako zdroj spíše zábavy občas s drobkem informace vyhovuje. Toto video díky Torvaldsovi stojí za shlédnutí, nakonec je i vtipné jak ten druhý je z toho poblázněný a tak lze ty jeho výstupu v tomto případě nějak tolerovat.

Sám mám raději psaný text a vyhovuje mi styl, kterým píše Jonathan Corbet na https://lwn.net/. Technicky přesný, podložený studiem, porozuměním diskuze vývojářů, někdy dokonce možná i větším, než mají autoři kódu a přitom je mistrem jazyka a dokáže text zpestřit opravdu jemným humorem, který ale často vyžaduje porozumění tématu. Přitom pak z článků vzniká znalostní báze například k jádru https://lwn.net/Kernel/Index/. Jsem přesvědčený, že Jonathan Corbet má na to být špičkovým přispěvatelem jádra, technicky lepším než mnoho jiných, ale nakonec usoudil, že bude užitečnější jako editor dokumentace jádra (zde má tisícovky commitů) a sledovatel technických diskuzí se schopností i jejím účastníkům spojit souvislosti a dokumentovat jí pro další příchozí (ty nesledující na plný úvazek), kdy ta shrnutí postupně tvoří znalostní bázi.

Jinak sám mám rád podobný decentní humor třeba v dílech J.R.R.Tolkiena ("Když nevíš kam se vydat, jdi za nosem"/sleduj kudy v dolu proudí vzduch) nebo jeho, co se děje týče, věrných obdivovatelů.

Ten hysterický Linus se stal prakticky nesnesitelným, ale díl s Alfa Linusem je fajn. Koukám se na to a jsem rád, že ho slyším.

Linus Sebastian byl historicky dost proti Linuxu a neodpustil si kopnutí kdykoli to bylo možné. Někdy bych řekl, že to bylo až účelové. Nicméně jak na PC trhu čím dál víc rezonuje Steam OS a Bazzite, tak chtě nechtě musí otáčet. Tohle video s tím asi trochu souvisí.

Gamers Nexus, LTT konkurence, měl výborné video o Bazzite minulý týden:

https://youtu.be/ovOx4_8ajZ8

Když vidím, jak si herní kanály na YouTube začínají všímat Bazzite a navíc Valve přichází se Steam Machine, tak si dokážu představit, jak musí být teď v XBox divizi Microsoftu horko.

Tak tyto youtube kanály to hlavně dělají kvůli sledovanosti. Jediný komu jsem opravdu věřil, že chce zpropagovat linux byl překvapivě PewDiePie.

https://youtu.be/pVI_smLgTY0?si=ug9Sn-QZb2LWaGGo

Já si myslim, ze jim je horko z ne zcela vydarenych akvizici Activision Blizzard za 75 miliard $ , ZeniMax (Bethesda) 7.5 miliard $, Obsidianu a dalsich do te miry, ze nejaka videa jsou zcela mimo rozlisovaci schopnost ;-)

Těch kotlů tam je víc. On totiž ani GamePass není zrovna zlatý důl.

Nevím zda proti. Neměl s ním dobré zkušenosti na videostřižnu a hraní. A kdo jo? Dnes je situace jiná.

S nastupem pristupu "sifrujeme vsechno" ten jeden flipnuty bit vubec nemusi znamena jeden bit, ale klidne 16 ci 32 bajtu, podle velikosti bloku dane sifry.

Takze za me ano, ECC vsude kde to mozne je. A povinne tam, kde maji data hodnotu.

Kupodivu, pokud by doslo k prehozeni bitu u zasifrovanych dat, tak se to instantne pozna, a dokonce je dost pravdepodobne, ze to pujde opravit.

A pokud k tomu dojde u dat dosud nezasifrovanych, tak je to uplne jedno a sifrovani v tom nehraje vubec zadnou roli.

A jak to poznate? V textaku leda mozna.. uvidite blok zmatenejch znaku, ale v pripade binarky, filmu, archivu.. neni sance poznat rozdil ve zmene bitu vs zmenu bloku. A kontrolni soucty/hashe taky nerozlisuji mezi velikosti zmeny.. jen ze tam zmena byla. Nekde.

Nepoznám. Dokud je ten film koukatelný, tak je mi naprosto šumafuk, jestli je nakopnutý blok nebo bit, když koukatelný není, tak ho někde mám na původním médiu (případně u "odzálohovaných" na BR, kde automaticky mám i sha384)

....

Kdyz zasifruju blok dat, a ten se pak zmeni, tak mam necitelny blok dat. Chovat se to bude presne stejne, jako kdyz zahodim/smazu klic/heslo, potazmo stejne jako BB na disku.

U nezasifrovanych dat se v tom textaku zmeni jedno pismeno. Coz je typicky zcela irelevantni. A totez plati i pro vsechny video i audio soubory, nemluve o takovy drobnosti ze spusta kontejneru obsahuje crc, takze jejich zmena se taky instatne pozna.

Neexistuje zadny zpusob, jak by z toho procesu moh vypadnout soubor ala rozsypany caj. Nic takovyho se stat nemuze.

Tomu moc teda nerozumite a jeste tam pletete chovani BB na disku .. ktere jsou typicky jen informace "nejde to", nikdy to neni "asi tohle, ale neber me za slovo".

Zacnete studiem rezimu pouziti blokovych sifer.

RE: Chovat se to bude presne stejne, jako kdyz zahodim/smazu klic/heslo, potazmo stejne jako BB na disku.

Že je to jinak si můžete bezpečně vyzkoušet.

Vytvoříte si virtuální partition:
dd, parted, losetup, cryptmount, mkfs, mount

Chybu jednoho bajtu můžete nasimulovat vnějším zásahem:
printf '\xFF' | dd of=disk.img bs=1 seek=123456 count=1 conv=notrunc

Zkuste to rozbití použít i na .bmp, .jpg, .mp3, .avi, .zip

V závislosti, kam se zrovna s tou chybou strefíte to bude mít různý efekt na práci s těmi daty.
Ano, některá místa jsou na změny citlivá. Proto má třeba GPT kopii na konci disku, proto má LUKS luksHeaderBackup. Pro učím studenty, zálohovat si MBR nového serveru.

A i když je těch kontrolních a opravných mechanismů v běžném počítači celá řada, tak vhledem k tomu, že každé paměťové/přenosové medium může kdykoliv selhat, a ne jen jeden bajt, tak stále platí: pokud vám na vašich datech záleží, nespoléhejte na jednu kopii na jednom místě.

> Kdyz zasifruju blok dat, a ten se pak zmeni, tak mam necitelny blok dat.

Jak se pozná taková nečitelnost? Budou tam buď 2 bloky šifry (CBC) nebo do konce bloku disku (v případě běžných diskových šifer typicky 512B) náhodná data. Běžné diskové šifry nepoužívají autentizaci obsahu - mj. protože mapují blok na blok, takže nemají autentizační tagy kam strčit.

> Chovat se to bude presne stejne, jako kdyz zahodim/smazu klic/heslo

Smazání hesla se detekuje tak, že nejde otevřít hlavička, ve které je magic a spousta dalších kontrolních dat. Poškození bloku někde uprostřed disku z hlediska šifrovacího programu nijak poznat nelze.

> potazmo stejne jako BB na disku

Bad block na disku se projevuje tak, že při čtení vrátí hardware io error. (nesouvisí se šifrováním)

Technický nitpick:

> ale klidne 16 ci 32 bajtu, podle velikosti bloku dane sifry

U ECB (které není moc bezpečné z jiných důvodů, že) je to jeden blok, u CBC 2 bloky, u dalších módů je to až do konce bloku disku (512/4096B), protože bloky skládají za sebe a různě XORují a chyba se tak propaguje a od chyby dál se dešifrují nesmysly. U CTR by to byl naopak jen ten jeden bit, ale CTR je ještě nebezpečnější (pro tohle i mnoho dalších použití).

https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Error_propagation

4. 12. 2025, 12:32 editováno autorem komentáře

Ten Linus teda starne... Uplne ho chapu jak mluvil o stresu a o pajeni krabicek na kytarove efekty jen tak pro zabavu.