106
Studium a uplatnění / Re:Inteligence programátora vs. nadšení
« kdy: 03. 02. 2015, 14:24:28 »protože tam budu řešit už nějaké opravdové problémy
Počujte, Kefalín. A čo si vy predstavujete pod takým opravdovým problémom?
Zobrazit příspěvky
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
Počujte, Kefalín. A čo si vy predstavujete pod takým opravdovým problémom?
107
Software / Re:Odstranění obsahu zpravodajských serverů
« kdy: 02. 02. 2015, 14:15:55 »
Doporučuju se nejdřív podívat, zda ten web má rozdělené RSS na blogy / názory / články (některé to mají). Tím by byl celý problém převeden na hledání vyhovující rss čtečky. Já jsem titulku některých webů neviděl několik let, jdu rovnou na článek.
108
Software / Re:Program pro stažení celého webu
« kdy: 02. 02. 2015, 09:43:33 »Tomáš
Co vlastně používáš, nějaké zpracování textu, vyhledávání, hledání kopií ?
Ne, ke každé stažené stránce mám jen čas stažení, URL a Title. Samotné stažené .html nijak dále nezpracovávám. Já to mám opravdu jen pro případ, kdy ten web zmizí, v ideálním případě to vlastně vůbec nepoužiji. Případně jen (v případě třeba EnglishRussia.com) vytáhnu ven obrázky do galerie.
109
Software / Re:Program pro stažení celého webu
« kdy: 28. 01. 2015, 19:05:26 »Tomáš, OMG
Ještě jsem zapomněl zmínit program ImgBurn
Neduhy to také má. Možná je jen pro Widle, takže spouštět pod wine.
Mno, opravdu není nutné spouštět cokoliv pod wine, když je hromada nativním programů. Např. growisofs.
Jinak místo 7zip nebo ISO bych spíše doporučil squashfs. Je to souborový systém přímo navržený na kompresi a silnou deduplikaci (po blocích), dá se připojit (read only) a dá se k němu připisovat další data (append, nikoliv re/write). Používají jej např. různá live distra. Není problém jít do stovek GB.
-nd znamená všechny soubory v jednom adresáři, takže se jesště situace toho co viím jako problém zhorší. -m znamená -r -l inf(nekonečno) -N(stejná timstamp jako na serveru). Ale při příkazu -m nejde použít -nc (vynechá již stažené soubory).
Ano, já to také psal jako příklad pro stažení jedné URL (chci to mít v ploché struktuře bez podadresářů, stejně to jde do taru a do db), pro mirror potom používám jiné parametry wgetu (-E -H -k -K -p -r -l0).
110
Software / Re:Program pro stažení celého webu
« kdy: 28. 01. 2015, 13:14:30 »...Tomasi, jak to ukladas? Mas nejakou repository? Nebo proste mas ve svem home 100gb archivu? Zajima me velikost a typ dat.
se článek změnil, mám pouze jednu verzi tak, jak vypadal těsně po uveřejnění v rss feedu a aktální stav). Rozhodně nemám zájem dělat druhý archiv.org.
Proženu to tarem, gzipem a jako bytea to vrazím do Postgresu. Aktuálně něco přes 200 GB. Pochopitelně, takto se tam ukládá hromadu duplicitních souborů (v každém archivu je logo webu, csska apod.), takže se chystám na deduplikaci. Potom by to byl každý soubor jako bytea zvlášť, nekomprimovaný (TOAST se v PG stejně komprimuje přes lza). Vlastně taková jednoduchá implementace fs v sql. (S deduplikací a transparentní kompresí.)
111
Software / Re:Program pro stažení celého webu
« kdy: 28. 01. 2015, 11:39:54 »Tomáš Crhonek: Ciste pro zajimavost, pouzivas porovnavani ruznych verzi clanku profesionalne (tj. jako zpravodajska agentura nebo monitoring zpravodajstvi aj. - neco ve stylu http://www.newtonmedia.cz/) nebo jenom jako duvod pro nasledny trolling v diskuzi a nadavani na redakci?
Ani jedno. ;-)
Jen si tak udělám obrázek o práci redakce, který nikomu nevnucuji. Většinou je to důvod proč daný web přestat sledovat.
Původní účel pro který toto vzniklo byla archivace mého vlastního webu v čase. Ono to člověku nepřijde, protože ten svůj web má pořád před očima a dělá jen malé změny. Potom jsem se mrknul na různé webarchivy jak vypadal před 10 lety a zjistil jsem, že už si to ani nepamatuju.
Tak jsem si napsal bastlskript, který ne/pravidelně dělá mirror. No a potom jsem ho rozšířil o ttrss na offline ukládání webů mého zájmu (tady se ale článek stáhne pouze jednou, takže pokud mám podezření, že se článek změnil, mám pouze jednu verzi tak, jak vypadal těsně po uveřejnění v rss feedu a aktální stav). Rozhodně nemám zájem dělat druhý archiv.org.
112
Software / Re:Program pro stažení celého webu
« kdy: 28. 01. 2015, 11:08:12 »
Zajímavé téma, osobně používám wget s parametry -E -H -k -p -nd --no-check-certificate --content-on-error. Vždy na jednu konkrétní URL. Na stažení celého webu (mirror) je potřeba si pohrát s parametrem -m (případně -r -l). Někdy je také vhodné získat seznam URL ze xmlsitemapy (pokud ji web má, tak je to lepší jak mirror přes parsing jednotlivých html stránek).
Nedělám si iluze o tom že po tomto způsobu uložení všechny stránky půjdou pohodlně přečíst. Ale min text se z toho vytáhne vždy. A to je to nejdůležitější.
Ještě vysvětlení PROČ pro lidi jako Jozin. Není to vůbec o tom, že připojení k netu dneska může mít člověk za pár korun. Je to o tom, že informace z webu prostě mizí. Zajímavé stránky, které dnes existují, zítra už mohou zmizet. A webové archivy také nezachytí všechno. Nevím, zda ještě někdo používáte bookmarky v prohlížečích, já ne, protože po roce už polovina odkazů stejně nefunguje. Místo bookmarků si tu stránku raději rovnou stáhnu offline.
Dál, mám to napojené na TTRSS, takže se mi automaticky stahují články z RSS zdrojů. Důvod není ani tak to, že bych chtěl mít všechno z RSS uložené, důvod je to, že se velmi často obsah článku změní v čase (a redakce se ještě tváří, že takto vypadal článek od počátku).
Nedělám si iluze o tom že po tomto způsobu uložení všechny stránky půjdou pohodlně přečíst. Ale min text se z toho vytáhne vždy. A to je to nejdůležitější.
Ještě vysvětlení PROČ pro lidi jako Jozin. Není to vůbec o tom, že připojení k netu dneska může mít člověk za pár korun. Je to o tom, že informace z webu prostě mizí. Zajímavé stránky, které dnes existují, zítra už mohou zmizet. A webové archivy také nezachytí všechno. Nevím, zda ještě někdo používáte bookmarky v prohlížečích, já ne, protože po roce už polovina odkazů stejně nefunguje. Místo bookmarků si tu stránku raději rovnou stáhnu offline.
Dál, mám to napojené na TTRSS, takže se mi automaticky stahují články z RSS zdrojů. Důvod není ani tak to, že bych chtěl mít všechno z RSS uložené, důvod je to, že se velmi často obsah článku změní v čase (a redakce se ještě tváří, že takto vypadal článek od počátku).
113
Software / Re:RAID5 silent data corruption/detection
« kdy: 22. 01. 2015, 14:42:30 »Ále, taková zatrpklost a trolling. Asi bych s tím mohl přestat
To znám.
Tak v disku se to už řeší. Ale ještě tam máš ten SATA kabel, RAM/cache disku a řadiče (opravdu to má ECC? stačí jednoduché ECC typu parita, tj. nemůže se stát, že když už dojde k poruše, překlopí se hned 2 bity?) a PCIe, která nevím, jak na tom je s konzistencí. Zase když dojdeš takhle hluboko, tak si nemůžeš být jistý, že ti procesor správně počítá
Přenos po SATA kabelu je ošetřen přes nějaké CRC, stejně tak PCIE apod. Paměti mohou být ECC také. Cache v CPU ECC mají (min. u AMD).
Já se přiznám, že jsem silent data corruption ještě neviděl. Disk vždycky hodil chybu. Nemám žádné petabajty, ale jak se psalo, že dojde k chybě každých 12 TB, tak to můžu jednoznačně vyloučit.
U disků také ne. Měl jsem podezření, že se mi kazí zejména multimediální soubory (co šlo před lety přehrát to už dneska nejde), tak mám sha512 sumy všech souborů na disku, které nepravidelně kontroluji a za x let ani jedna vada. Nakonec jsem přišel na to, že se u přehrávačů snižuje schopnost přehrávat poškozené soubory, takže zatímco přehrávač před 8 lety s daným videem neměl nejmenší problém, tak letos už nelze přehrát (musel jsem to prohrat přes ffmpeg nebo mencoder a opravit kontejner). Stejně tak poškozené mp3 (o kterých jsem věděl, že jsou poškozené) se dřív přehrávaly v pohodě (výpadek frame sice byl slyšet, ale přehrávač se ho snažil zamaskovat), tak dneska přehrávače vydávají pazvuky.
Opět, kdyby přehrávače i před těmi 8 lety upozornily na vadný soubor, řešil bych to hned a nehledal bych problém tam kde není (ale co, kontrola sha512sum ničemu neuškodí).
114
Software / Re:RAID5 silent data corruption/detection
« kdy: 22. 01. 2015, 12:01:25 »Možná moderní disky se takto chovají. Ale na úrovni firmware disku. Jak jinak by probíhala detekce chyb a realokace sektorů.
Někde jsem našel že každý block má CRC ale je to informace z nějakého fóra.
Pokud by to tak bylo je samozřejmě zbytečné to řešit na úrovni raidu.
Ano, každý blok uložený (fyzicky) na disku má na konci ECC, který kontroluje přímo samotný disk. ECC dovoluje malé chyby opravit a větší detekovat.
CRC má dále i samotné rozhraní mezi diskem a řadičem (SATA, SAS), kde se ověřuje přenos dat mezi diskem a řadičem. Každá sběrnice má nějakou vlastní formu CRC nebo i samoopravného kódu, přímo na úrovni HW.
Otázkou tak zůstává, kolik chyb může reálně projít až do OS.
Jak jinak tedy vzniká rád se poučím. Díky.
Tak samozřejmě různě. Asi nejhorší poškození dat, na které jsem v praxi narazil, způsobila jistá nejmenovaná takydatabáze, která se tvářila, že umí transkace (a spousta lidí tomu dodnes věří), ale příkaz rollback částečně nebo úplně ignorovala. Takže aplikace v nestandardní situaci správně zavolala rollback, každá normální db by data vrátila do původního stavu před transakcí, ale zrovna tahle se rozhodla jen pro částečný úklid.
Než si tohoto všimla obsluha aplikace (za normálních okolností to bylo neviditelné, což bylo dané návrhem aplikace, která zobrazovala relativně správná data*), tak byla chyba zpropagována na všechna záložní media (a ostatně data stará několik let by byla stejně k ničemu).
*) Což je poučení i pro návrh aplikace, chyby v datech by se měli co nejvíce amplifikovat a nikoliv potlačovat. Kdyby v tomto případě aplikace na vadných datech selhala, objevilo by se to v řádu minut.
Sice to není příklad klasického data silent cor. kdy zařízení vrátí jiná data než se tam uložila, ale výsledek je stejný. Formálně jsou data v pořádku, ale ve skutečnosti jsou vadná (nelze rozhodnout, které záznamy jsou správné a které měli být rollbacknuté).
115
Software / Re:RAID5 silent data corruption/detection
« kdy: 22. 01. 2015, 11:04:43 »Na linuxovém MD-RAIDu vůbec nijak. V rozumném operačním systému by na konci každého bloku nebo stripu bylo CRC nebo dokonce samoopravný kód. Na Linuxu to ale nikdo nedělá. Můžeš použít souborový RAID ZFS, které alespoň počítá CRC bloků souboru.
Jak tak čtu tvoje komentáře z poslední doby, tobě musel Linux udělat něco opravdu hodně ošklivého.
Tohle je o (filozofickém) pohledu na stavbu systému. Je otázkou, zda si tohle nemá řešit HW sám. Tedy HW (v tomto případě disk) vrátí buď data (vždy správná) nebo data nevrátí a ohlásí chybu. Mě (z hlediska oddělení rolí) nepřipadá úplně správné na straně SW řešit HW problémy. Kontrolovat ano, opravovat ne.
Jinak RAID5 (žádný) nepozná, který stripe je vadný už přímo z definice R5.
Existují systémy souborů, které implementují různé stupně redundance a také ukládají a kontrolují kontrolní součty. Takové FS (BTRFS, ZFS), potom poznají, že blok, který načetly z disku, je špatný (resp. že neodpovídá kontrolnímu součtu, může být špatný ten součet).
Jinak silent data corruption vznikají především úplně jinak než tím, že disk vrátí jiný blok. Tohle totiž lze ještě docela dobře detekovat (takže to není tak úplně silent).
116
Odkladiště / Re:Buducnost informatiky za 5-10 rokov
« kdy: 05. 01. 2015, 14:54:24 »
Tyhle úvahy a diskuse o tom, jak se IT každých 10 let mění, se mi hrozně líbí. Je to takové odlehčené scifi povídání. Dobře se to čte. Ale to je tak celé.
Realita je taková, že když se přenesete o 40 let zpět, tak IT vypadalo vlastně úplně stejně jako dnes. U jazyků se časem jen mění syntax, paradigmata se ovšem nemění. Datové struktury jsou 40 let pořád tytéž. Jen s kosmetickými obměnami, které jsou dané více méně jen možnostmi HW a efektivním způsobem uložení. Operační systémy furt na stejných principech. Virtualizace, kontejnery, všechno existuje x desítek let.
Jediné co se mění jsou velikosti úložišť a rychlost zpracování, ale společně s tím velikost zpracovávaných dat . Skoro se mi chce říct, že relativně to vychází pořád nastejno (je jedno, zda máte 1MB dat a zpracujete je za hodinu, nebo 10GB dat a zpracujete je za hodinu). Lidé jsou ochotni čekat pouze určitou dobu a tomu se podřizuje to co se zpracovává. Dále se mění dostupnost HW. Před 30 lety měl počítač s trochou přeháněním 1 člověk ze sta, dneska má člověk počítačů víc (i když se tomu třeba neříká počítač, ale třeba tablet, mobil, foťák apod).
Lidé, kteří mají pocit, že se neustále všechno mění hrozně rády nasedají na hype vlny (jak to správně popsal Mirek Prýmek), a taky je sami vytvářejí. Takže data neustále přelévají tuhle na key-value, tuhle do dokumentů, tuhle do grafových db, tuhle do sloupců a o každé předchozí technologii prohlašují (po pár měsících) jak je neskonale zastaralá. Když z jakékoliv supermoderní IT technologie utřete ten hype výcak, tak zjistíte, že je to jen reinkarnace toho, co už tu bylo hodně dávno.
Takže budoucnost IT za 5-10 let závisí na tom, zda má člověk nasazené hype brýle. Pokud ano, tak za 10 let se IT kompletně změní. Pokud je člověk ale nohama na zemi, tak IT za 10 let bude vypadat úplně stejně jako vypadá dnes a úplně stejně, jako před x desítkami let. Jen se možná změní jméno nejoblíbenějšího jazyka, jen se změní název služby pro ukládání dat, jen se zvýší velikosti úložišť a společně s tím velikost dat. A pořád budou existovat lidé, kteří budou vytvářet hype technologické bubliny a účelově na nich vydělávat.
Realita je taková, že když se přenesete o 40 let zpět, tak IT vypadalo vlastně úplně stejně jako dnes. U jazyků se časem jen mění syntax, paradigmata se ovšem nemění. Datové struktury jsou 40 let pořád tytéž. Jen s kosmetickými obměnami, které jsou dané více méně jen možnostmi HW a efektivním způsobem uložení. Operační systémy furt na stejných principech. Virtualizace, kontejnery, všechno existuje x desítek let.
Jediné co se mění jsou velikosti úložišť a rychlost zpracování, ale společně s tím velikost zpracovávaných dat . Skoro se mi chce říct, že relativně to vychází pořád nastejno (je jedno, zda máte 1MB dat a zpracujete je za hodinu, nebo 10GB dat a zpracujete je za hodinu). Lidé jsou ochotni čekat pouze určitou dobu a tomu se podřizuje to co se zpracovává. Dále se mění dostupnost HW. Před 30 lety měl počítač s trochou přeháněním 1 člověk ze sta, dneska má člověk počítačů víc (i když se tomu třeba neříká počítač, ale třeba tablet, mobil, foťák apod).
Lidé, kteří mají pocit, že se neustále všechno mění hrozně rády nasedají na hype vlny (jak to správně popsal Mirek Prýmek), a taky je sami vytvářejí. Takže data neustále přelévají tuhle na key-value, tuhle do dokumentů, tuhle do grafových db, tuhle do sloupců a o každé předchozí technologii prohlašují (po pár měsících) jak je neskonale zastaralá. Když z jakékoliv supermoderní IT technologie utřete ten hype výcak, tak zjistíte, že je to jen reinkarnace toho, co už tu bylo hodně dávno.
Takže budoucnost IT za 5-10 let závisí na tom, zda má člověk nasazené hype brýle. Pokud ano, tak za 10 let se IT kompletně změní. Pokud je člověk ale nohama na zemi, tak IT za 10 let bude vypadat úplně stejně jako vypadá dnes a úplně stejně, jako před x desítkami let. Jen se možná změní jméno nejoblíbenějšího jazyka, jen se změní název služby pro ukládání dat, jen se zvýší velikosti úložišť a společně s tím velikost dat. A pořád budou existovat lidé, kteří budou vytvářet hype technologické bubliny a účelově na nich vydělávat.
117
Server / Re:Web aplikace - provozní kniha serveru?
« kdy: 19. 11. 2014, 13:26:38 »
Používáme MediaWiki (postačí jakákoliv Wiki), tam je kompletní historie každého článku (všechny editace) a u každé je uvedeno, kdo editoval. Dohledat to lze.
Jinak vám doporučuju nedokumentovat to, co se dá velice snadno zjistit přímo z těch serverů. Je to zbytečné a je to jen další údaj, který se v čase v realitě změní a v dokumentaci nikoliv.
Tedy cokoliv, co lze zjistit pomocí
for server in $server_list ; do ssh $server "zjisti info o os a zakladnich parametrech" ; done
prostě nedokumentovat.
Co naopak dokumentovat, protože to ani na samotném serveru nenajdete je slovní popis proč tam daná věc je. Třeba jen "tento databázový server slouží pro tyto weby a také se k němu připojuje proces pro sběr dat jednou za půl roku". Tohle případnému novému adminovi pomůže mnohem víc, než typické: je tam databaze ve verzi 1.2.3. To si snadno zjistí.
Jinak vám doporučuju nedokumentovat to, co se dá velice snadno zjistit přímo z těch serverů. Je to zbytečné a je to jen další údaj, který se v čase v realitě změní a v dokumentaci nikoliv.
Tedy cokoliv, co lze zjistit pomocí
for server in $server_list ; do ssh $server "zjisti info o os a zakladnich parametrech" ; done
prostě nedokumentovat.
Co naopak dokumentovat, protože to ani na samotném serveru nenajdete je slovní popis proč tam daná věc je. Třeba jen "tento databázový server slouží pro tyto weby a také se k němu připojuje proces pro sběr dat jednou za půl roku". Tohle případnému novému adminovi pomůže mnohem víc, než typické: je tam databaze ve verzi 1.2.3. To si snadno zjistí.
118
Hardware / Re:Sluchátka pro klid na práci
« kdy: 07. 11. 2014, 14:01:23 »
Existují audio sluchátka se zatlumením 18dB, což už je docela slušné.
Potom existují sluchátka, která totéž řeší elektronicky tím, že snímají okolní zvuk a "generují" signál s opačnou fází. Tím se ty dva zvuky vyruší. Tohle bych nebral.
Oboje sluchátka mají výhodu, že se na nich dá poslouchat také normální hudba. I když na těch s elektronickým potlačením asi jen něco na kvalitativní úrovni popu.
Potom samozřejmě špunty do uší za pár korun. Ale pozor na dlouhodobé používání, ucho musí dýchat.
Potom existují sluchátka, která totéž řeší elektronicky tím, že snímají okolní zvuk a "generují" signál s opačnou fází. Tím se ty dva zvuky vyruší. Tohle bych nebral.
Oboje sluchátka mají výhodu, že se na nich dá poslouchat také normální hudba. I když na těch s elektronickým potlačením asi jen něco na kvalitativní úrovni popu.
Potom samozřejmě špunty do uší za pár korun. Ale pozor na dlouhodobé používání, ucho musí dýchat.
119
Server / Re:Zálohování po pomalé lince
« kdy: 06. 11. 2014, 20:19:58 »Myslim, ze si trochu nerozumieme. Skusim vysvetlit este raz a vy zase mozete skusit jednat trochu normalnejsie. Ak sa neda, tak nevadi, pochopim, kazdy ma nieco, co je nad jeho schopnosti. Ak v dalsej odpovedi dokazete zformulovat aj nieco konstruktivne, tak pokojne aj v takomto jazyku.
Samozrejme mi ani nenapadlo porovnavat obsahy suborov. Ak ale porovnavam len datumy zmien, tak sa takisto musi rsync opytat na kazdy jeden subor druhej strany a musi to urobit cez siet. Teda urobi velmi vela dotazov, ktore su uplne zbytocne, pretoze v konecnom dosledku zisti, ze na lokalnej strane (na strane odkial uploadujem) sa zmenili len 3 subory. Ak by som mal nejaky lokalny katalog, tak by som vykonal vsetky testy na zmeny bez jedineho requestu po sieti a posieti by som riesil len upload zmenenych suborov alebo nebodaj len casti suborov.
Nerozumím, čemu říkáte "rsync udělá mnoho dotazů". Rsync žádné dotazy nedělá. Při spuštěný rsync udělá na obou stranách seznam souborů, vzdálená strana pošle svůj seznam souborů na iniciační stranu a tam se porovaní. Pro 1000 souborů se třemi změnami tohle nemůže být překážkou. Potom se přes síť pošle jen ona malá změněná část těch vašich 3 souborů.
Rsync žádné binární porovnávání obsahu všech souborů nedělá. (Neurčíte-li jinak. Porovnávání dělá pouze u zdroje a cíle na lokálním stroji (Opět, pokud neurčíte jinak.).)
120
Odkladiště / Re:SEZNAM.CZ jak přijít o data
« kdy: 05. 11. 2014, 13:43:21 »Sakra, tedy doufam, ze za prihlaseni k uctu" povazuji stazeni mailu pres POP.
Ne. Jen na web.
