Příspěvky

3706

Odkladiště / Re:Jak správně zálohovat data okolo 20 GiB

« kdy: 16. 10. 2017, 13:31:53 »

Pane Šilhavý, já si myslím, že to nikdo nezpochybňoval.

V tom případě jste asi přehlédl všechny příspěvky Milfause.

3707

Software / Re:Hledám prohlížeč který podporuje Java aplety

« kdy: 16. 10. 2017, 13:12:00 »

Omyl, pisi o portalech, ktere vznikly v poslednich dvou trech letech.

To jste ovšem zapomněl napsat. Reagoval jste na komentář o daňovém portálu.

A ackoliv ukonceni podpory npapi se vedelo minimalne rok dopredu

Což je ovšem problém Oraclu. Že se Oracle hodí Java applety přes palubu se dopředu nevědělo.

3708

Odkladiště / Re:Jak správně zálohovat data okolo 20 GiB

« kdy: 16. 10. 2017, 11:59:30 »

Pokud není vadný, tak ne!

To je opravdu výborná informace. Vy to víte dopředu, že ten disk je vadný? Kupujete disky „dejte mi pět bezvadných a tři vadné“? Asi těžko. Ve skutečnosti máte disky, u kterých nevíte, zda jsou vadné nebo bezvadné. Dokonce i dříve bezvadný disk se může změnit ve vadný. A to, že je disk vadný, se dozvíte buď tak, že rovnou začne hlásit tvrdé chyby a data vůbec nepřečte, a nebo právě tak, že vám vrátí špatná data, což zjistíte právě z kontrolního součtu. Ano, většina vadných disků se projeví tak, že budou rovnou vracet tvrdé chyby, ale to neznamená, že k vrácení chybných dat nemůže dojít.

Nechci se Milhause zastávat, ale opravdu tu někteří tvrdí, že disk vrací data podle nálady, což není pravda.

Já jsme nikoho takového nezaznamenal. Naopak jsem si všiml, že Milhaus pořád předpokládá, že vadné disky nemohou existovat.

3709

Software / Re:Hledám prohlížeč který podporuje Java aplety

« kdy: 16. 10. 2017, 08:40:54 »

A takhle funguje cela statni sprava, zavadi reseni, ktera jsou zbytecna pomoci technologii, ktere jsou zastarale :-D Ve statni sprave se pouziva hromada portalu, jejichz existence je primo umerna EU dotacim:-) A pro elektronicke podepisovani se bohuzel bezne pouziva java applet nebo silverlight, asi ty vyvojarske firmy ziji v jinem vesmiru nez bezni smrtelnici.

Pláčete sice hezky, ale na základě špatných informací. Daňový portál je mnohem starší, než ukončení podpory NPAPI v prohlížečích. Takže psát o „zavádění řešení“ je úplně mimo – zavedení Javy pro elektronický podpis na daňovém portálu před mnoha lety znamenalo nahrazení ActiveX komponenty, byl to tedy jednoznačně krok vpřed. To, že se pro elektronické podepisování běžně používá Java Applet nebo Silverlight, je dané tím, že to byly jediné dvě reálné možnosti. Pak už zbývala jen možnost proprietárních aplikací svázaných s konkrétním prohlížečem a platformou, např. ActiveX. Dnes je akorát potřeba Java Applety (a případně Silverlight, pokud se někde ještě používá) upravit na Java WebStart aplikace. Vývojářské firmy nežijí v jiném vesmíru, právě naopak, vývojářské firmy mohou použít jenom technologie, které jsou k dispozici.

3710

Odkladiště / Re:Jak správně zálohovat data okolo 20 GiB

« kdy: 16. 10. 2017, 06:56:11 »

nemocný disk vrací nemocná data.

To bych řekl, že nikdo nezpochybňuje.

O čem tedy celou dobu píšete? Na začátku bylo tvrzení, že je vhodné mít u souboru kontrolní součet, aby bylo možné rozpoznat, že disk je nemocný a vrátil špatná data. Vy to celou dobu zpochybňujete a tvrdíte, že disk nikdy za žádných okolností špatná data vrátit nemůže.

Já se přiznám, že už se ani nenamáhám to číst.

To je váš problém, že chcete setrvávat v bludu. Tak ty bludy aspoň dál nešiřte.

3711

Odkladiště / Re:Jak správně zálohovat data okolo 20 GiB

« kdy: 15. 10. 2017, 21:19:49 »

Jirsák nerozumí psanému textu, že?
Chyba 12bitů se rozumí na CELÝ BLOK!
Pokud má SSD interně 640b bloky (spíš by se slušelo říct stránky), tak se bavíme o to, že se dá opravit chyba až 12 bitů KDEKOLIV v tom bloku a rozpoznat chyba až 18b!!!

Pěkně prosím, kde v tom vašem textu bylo napsané, že je to 12 bitů na blok? Aby mohl někdo rozumět psanému textu, musí nejprve existovat ten psaný text. A také bývá vhodné, když ten text je psaný v nějakém všeobecně uznávaném jazyce, což lze jen stěží říct o shluku slov „Chyba dvanáctibitů se rozumí na celý blok!“ „Rozpoznat chyba až osmnáctibitový“ je také zajímavá češtin. Jestli on spíš nebude problém v tom, že Milfaus neumí psát.

Ten váš SSD s 80bajtovými stránkami taky musí být zajímavý kousek. Zaměňovat bloky a stránky taky není to pravé, protože je to každé něco jiného – bloky SSD disků se skládají ze stránek (které mají obvykle 4 KiB, ale mohou mít třeba i 8, 16 nebo jen 2 KiB).

Přiznej se, že ty to děláš schválně 

Ano, ty vaše nesmysly opravuju schválně. Zajímavé spíš je, proč vy ty nesmysly píšete.

3712

Odkladiště / Re:Jak správně zálohovat data okolo 20 GiB

« kdy: 15. 10. 2017, 15:51:48 »

například u SSD se používá 12-ti bitová ochrana, jinými slovy, pokud dojde k selhání 12-ti bitů, pořád to jde opravit

Zkuste se zamyslet nad tím, co jste napsal. Když načtete jeden bajt, tedy 8 bitů, může tam být 12 bitů chybných? 12 z 8? Nebo je to 12 bitů na celý disk? Takže když máte 512 GB SSD disk, může na něm být chybných 12 bitů, a pořád je možné obsah celého disku obnovit? To by ale znamenalo, že byste při každém čtení musel přečíst úplně celý disk, abyste mohl spočítat kontrolní kód a detekovat chyby, případně je opravit. Už vám je jasné, jaký jste napsal nesmysl? Už víte, že chybovost je nutné vždy uvádět jako podíl, tedy například že řadič ECC dokáže detekovat a opravit jednobitovou chybu v 64bitovém slově, případně dvoubitovou chybu v 64bitovém slově dokáže detekovat?

Ale jinak je fajn, že jste konečně uznal, že úložiště může selhat a vrátit chybná data, takže ukládat kontrolní součet dat není až tak bláhový nápad, jak jste ze začátku tvrdil.

3713

Odkladiště / Re:Jak správně zálohovat data okolo 20 GiB

« kdy: 15. 10. 2017, 14:26:06 »

Data na discich se meni, neco jako 100% spolehlivost neni.

Jenze milfaus ma pravdu a ty si zkontroluj disky a ovladac radice!

Kdyby měl Milfaus pravdu, tak by přece kontrola disků a řadičů byla zbytečná. Pokud by nemohla nastat chyba disku nebo řadiče, která by znamenala přečtení špatných dat, co byste na tom chtěl kontrolovat? Takže sám potvrzujete, že není možné se spolehnout na to, že disk 100% vždy vrátí správná data. Ano, pokud disk vrátí špatná data, je to ve většině případů způsobené závadou na disku nebo na řadiči. Ale proto se ty kontrolní součty používají, aby se takové závady odhalily.

3714

Odkladiště / Re:Jak správně zálohovat data okolo 20 GiB

« kdy: 15. 10. 2017, 14:17:35 »

Vyvedu tě z omylu, ne každá databáze ukládá data v plaintextu

Proč by měla databáze ukládat data v plaintextu? Já jsem uváděl konkrétní příklad s celým číslem uloženým normálně ve dvojkové soustavě – obě dvě ta čísla jsou platné hodnoty, takže jenom z těch samotných hodnota databáze samozřejmě nepozná, že je něco špatně.

databáze jsou na změnu jednoho bitu poměrně dost citlivé!

To už jste jednou psal, a já jsem vám to vyvracel, že většina dat uložených databází jsou uživatelská data, a pokud by došlo k překlopení bitu v nich, databázi to nijak vadit nebude.

Ono se to zvládne vesměs opravit

Aha, takže ty chyby, ke kterým podle vás nedochází, se vlastně vyskytují, ale magicky se to samo opravuje.

ale jak databáze zjistí nekonzistenci, musí se provést oprava.

Opět, jaká nekonzistence, když k tomu podle vás nedochází?

Nebo že by nevadilo, kdyby docházelo k chybám a měnil by se datový kontejner virtuálního počítače?
Takové kontejnery mají běžně 60 GB obsazeného místa!

To, že vy jste se s nějakou chybou nesetkal, neznamená, že vůbec neexistují. Zřejmě taky nezálohujete, protože vám nikdy žádný disk neodešel a budete tvrdit, že k selhání disků nedochází. Víte, jiní lidé se ale neřídí jen svou vlastní zkušeností, takže když mají informace o tom, že disk může selhat, zálohují data, i když jim disk zatím neselhal.

Data na disku se nemění!

Stopy na disku jsou dnes tak blízko u sebe, že zápis do jedné stopy ovlivňuje i vedlejší stopy. Dnešní disky fungují spíš tak, že čtecí hlava přečte nějaký spíš šum než data, a na základě samoopravných kódů se z toho zrekonstruuje, co tam asi mělo být uloženo. Ta data se nemění v tom smyslu, jak si to představujete vy, že by na tom disku někde byla vyražená jednička a sama se změnila na nulu. Ne, ta data se mohou změnit tak, že tam toho šumu může být už příliš mnoho, víc, než kolik zvládnou opravit dané samoopravné kódy.

Může to hlídat i souborový systém.

Aha, takže souborový systém hlídá chyby, které nemohou nikdy nastat. Proč pak to asi dělá?

A dobrý archivační program ti zajistí jak integritu tak se dokáže sám opravit!

A dokonce i dobrý archivační program hlídá chyby, které nemohou nikdy nastat. Zdá se, že v oblasti ukládání dat panuje obsese v ukládání zbytečných kontrolních součtů. Tak proč se k tomu nepřidat a neuložit si je taky?

Mimochodem, bavili jsme se tu o 7zipu a raru, což nejsou archivační programy, ale komprimační. A dobrý komprimační program rozhodně data nebude opravovat, protože pro možnost opravy dat potřebujete jejich redundanci, nebo-li by se tím velikost komprimovaného souboru zvětšovala. Přičemž komprimační soubory se používají proto, aby byl zkomprimovaný soubor co nejmenší, ne proto, aby byl ještě větší, než originál. Podobné je to i s těmi kontrolními součty, i ty zabírají místo navíc.

3715

Odkladiště / Re:Jak správně zálohovat data okolo 20 GiB

« kdy: 15. 10. 2017, 08:26:47 »

Databáze jsou o řád citlivější na poškozené soubory a nikdy se jejich obsah nemění samovolně!!!

Popisujete, co se děje, ale já jsem vám k tomu vysvětloval i to, proč se to děje. Ty databázové soubory máte uložené na nějakém RAIDu, RAID má uložené kontrolní součty bloků a při čtení je ověřuje. Pokud mu nějaký kontrolní součet nesedí, přečte data z jiného disku, kde jsou také uložená, a ten původní disk, který vrátil chybná data, označí za chybný a správce jej vymění.

Mimochodem, na skrytou změnu bitů nejsou databáze citlivější. spíš právě naopak. Většina toho, co máte v databázi uložené, jsou uživatelská data. Pokud by se v databázi změnila hodnota 55 731 na 53 683, nebo se „Praha“ změní na „PrAha“, databázi by to opravdu nijak nesložilo, protože ty hodnoty tam klidně mohl zadat i uživatel.

3716

Odkladiště / Re:Jak správně zálohovat data okolo 20 GiB

« kdy: 15. 10. 2017, 00:14:45 »

Disk vrací data opravená. To, jestli jsou ta data taky správná, si zjišťují vyšší úrovně systému – např. souborové systémy pomocí svých kontrolních součtů, aplikace zase pomocí svých kontrolních součtů (které jsou třeba ještě nad těmi kontrolními součty souborových systémů). Podle vás jsou ti autoři souborových systémů a aplikací používajících kontrolní součty blázni, kteří dělají zcela zbytečné věci. Dotyční autoři se ovšem řídí heslem „důvěřuj ale prověřuj“, protože vědí, že existují nejen bezvadné disky, ale také vadné disky. A vědí, že k takovým chybám sice nedochází tak často, aby se s nimi Milfaus už potkal, ale zase na druhou stranu nejsou tak výjimečné, aby se nad nimi dalo mávnout rukou.

A mimochodem, u dnešních disků se ty kontrolní součty nepoužívají proto, aby se opravily případné chyby, ale proto, aby se z toho šumu, který se z disku přečte, podařilo zrekonstruovat původní data s nějakou aspoň trochu slušnou pravděpodobností.

3717

Odkladiště / Re:Jak správně zálohovat data okolo 20 GiB

« kdy: 14. 10. 2017, 22:31:01 »

Osobně bych použil více hashovacích algoritmů, pravděpodobnost, že všechny v kombinaci budou mít stejnou chybu (kolizi) je prakticky nulová.

Prakticky nulová je pravděpodobnost kolize i u jediného hashovacího algoritmu, pokud se použije nějaký rozumný (třeba SHA-2 nebo SHA-3). Použití dvou hashovacích algoritmů by bylo dobré akorát tak pro dobrý pocit a pro to, že je pořád extrémně jednoduché to použít (zejména v porovnání se zjišťováním, jestli a jaké používá 7zip kontrolní součty).

Užít k hashování 7z je taky možnost

Pak tedy asi víte, jaký hashovací algoritmus 7zip používá, co hashuje a jakým způsobem hashe ověřuje. Mohl byste to nám ostatním prozradit, ať to nemusíme hledat?

3718

Software / Re:Hledám prohlížeč který podporuje Java aplety

« kdy: 14. 10. 2017, 20:10:28 »

Jenda? Ať se dívám jak se dívám radu od Jendy fakt nevidím?

Je to hned první komentář… 

3719

Odkladiště / Re:Jak správně zálohovat data okolo 20 GiB

« kdy: 14. 10. 2017, 18:10:14 »

Z těch obyčejných RAR umí BLAKE2, stačí mu to říct parametrem.

Jenže aby to k něčemu bylo, je potřeba si ověřit, že konkrétní program, který se použije pro rozbalování, ten kontrolní součet opravdu ověřuje. Zejména když použijete nějaký opensource klon, který někdo napsal hlavně pro to, aby dokázal běžné archivy vůbec rozbalit, nemáte vůbec jistotu, že nějaké ověřování kontrolních součtů bude dělat. Vždyť to pro rozbalení není potřeba, a když se ten kontrolní součet neověří, nikdo to nepozná.

Pro pomaleji chápající – použití komprimačního programu v tomto případě nepřinese vůbec žádné výhody, za to má několik nevýhod:

• Je potřeba ověřit, že použitý kontrolní součet je dostatečně silný pro uvedenou potřebu, a je potřeba zajistit, aby se do archivu opravdu vkládal.
• Je potřeba ověřit, že se při dekompresi kontrolní součet ověřuje, a jakým způsobem bude program signalizovat, že kontrolní součet nesedí.
• Komprese a dekomprese je zbytečně náročná na zdroje, bude to trvat déle.
• Výsledný komprimovaný soubor bude pravděpodobně větší, než originál, protože se komprimují takřka náhodná data.

Nemusíte stále dokazovat, že použít tímhle způsobem archiv je možné – to tu nikdo nerozporuje. Důležité je to, že to nedává žádný smysl, protože je to komplikovanější a riskantnější.

3720

Odkladiště / Re:Jak správně zálohovat data okolo 20 GiB

« kdy: 14. 10. 2017, 16:48:47 »

Řada archivátorů (snad skoro každý) přidává do souboru kontrolní i opravné součty.
Proto Vám ZIP řekne, že je archiv porušený, protože detekoval chybu, to je sice hodně primitivní kontrola někde úrovni MD5, ale dostatečně odolná, aby se zjistilo poškození byť jen jediného bitu.

Problém je právě v tom „někde na úrovni“. Kdyby byla někde na úrovni MD5, je to fajn, protože by to změnu v jediném bitu opravdu zaznamenalo. Ale co když je ta kontrola někde na úrovni CRC32? To už by bylo velmi nedostatečné, vzhledem k tomu, o jak důležitá data má jít. Takže byste musel zjistit, jaký kontrolní součet se v kterém archivačním formátu používá (a vůbec bych se nedivil, kdyby jich pro některé formáty bylo víc a záleželo na tom, který program použijete pro kompresi). Dále byste musel zjistit, že program, který použijete na dekompresi, opravdu provádí tu validaci kontrolních součtů.

Proč to celé, proč takové komplikace, proč používat program k něčemu, na co není určen, když tu máme programy, které jsou na výpočet kontrolních součtů určené, dělají to správně a spolehlivě a jejich použití je mnohem jednodušší, než ta anabáze s kompresí?

Mimo to, jak CD/DVD/BD, Pásky i HardDisky disky používají vlastní kontrolní součty!
Každý formát má svoje opravné mechanismy, aby se bity neztrácely!
Takže další kontrolní součty na úrovni souborového systému!!!

To všichni vědí. Jenže tohle všechno je určené pro běžný provoz, ne k nějakému super jištění. Vzhledem k tomu, že tazatel chce uložit data asi na pět nebo kolik míst, určitě chce mít svou vlastní možnost ověřit si, že data v jednotlivé kopii nejsou poškozená. Ono je to jednodušší, než stahovat všech pět kopií k sobě a pak porovnávat, které z nich jsou stejné a které se liší (což by se dělalo opět přes hashe…).

Mimochodem, třeba při použití Amazon Glacier je použití hashe při uploadu povinné, protože i Amazon chce být chráněný a zkontrolovat si, že k němu po síti doputovalo skutečně to, co klient odeslal. A při downloadu vám (v závislosti na podmínkách) opět pošlou hash stahovaných dat. A to mají TCP segmenty také své kontrolní součty, a linkové protokoly obvykle také.