Příspěvky

1

Software / Re:Odstranění duplicit a konsolidace dat

« kdy: 16. 05. 2026, 13:55:24 »

A? Má to niečo spoločné s mojou prvotnou odpoveďou? Vidíte v nej niekde, že by som cez kolónu posielal nejaké veľké dáta?

... pretože v tom nikto žiadne veľké dáta cez kolónu neposiela.

A to je lež.

Lež??? Akože viem, že je to inak a úmyselne vás klamem? Ako si niečo také vôbec môžete dovoliť? Kto si myslíte, že ste???

Pokud jsi jen nevzdělaný, tak se omlouvám. Skutečností je, že v linuxovém světě se kolony běžně používají pro přenos velkých objemů dat, která by se do dočasných objektů ani nemohla vejít.

Budem sa tváriť, že som si nevšimol, že to ospravedlnenie je podmienené a prijímam ho.

Znova sa vás ale musím spýtať: No a? Citujete z mojich odpovedí a argumentujete Linuxom. Je tvrdenie, že "v linuxovém světě se kolony běžně používají pro přenos velkých objemů dat" dôkazom toho, že klamem, keď píšem, že v mojej prvotnej odpovedi v mnou poskytnutom riešení, ktoré sa Linuxu vôbec nijako netýka, "nikto žiadne veľké dáta cez kolónu neposiela"?

Moje odpovede majú jasne definovaný kontext, Linux je úplne mimo neho a jasne som vám už predtým napísal, že to, čo vy robíte na Linuxe ma absolútne vôbec nezaujíma.

Vyjadrujem sa výhradne k PowerShellu a k Windows, pričom Windows majú kolóny implementované úplne rovnako ako Linux, aby bolo (ostatným) jasné, že ten blud, ktorý ste tu šírili o dočasných súboroch je už viac ako 25 rokov jednoducho... nezmysel.

Mimochodom, vy si naozaj myslíte, že neviem ako funguje na Linuxe kolóna a čo sa s ňou dá robiť? A že mi to musíte vysvetľovať? Vy ste fakt dobrý.

Ve Windows se takové objemy nepoužívají a proto si vystačí s objekty uloženými v .NET . Pro spuštění kolony v rámci PowerShellu se tedy využívá tato mezivrstva. Pokud však jedním z členů komunikace je vnější proces, tak tuto službu zprostředkovává přímo jádro operačního systému, kterou si PowerShell obalí tak, že uživatel má pocit, že přenos dat dělá přímo PowerShell bez účasti jádra operačního systému.

V Linuxu však .NET ani PowerShell standardně nejsou, takže meziprocesová komunikace se nejjednoduššeji dělá právě pomocí služeb jádra operačního systému.

Aby nedošlo k omylu, teraz so mnou polemizujete v zmysle, že som zas niečo akože napísal nesprávne alebo je to váš nezávislý pohľad?

Objekty .Net sa týkajú výhradne PowerShellu, nie Windows všeobecne. A v kontexte PowerShellu je prvotné to, či odosielateľ alebo príjemca je alebo nie je z pohľadu PowerShellu externým programom. Objem dát je sekundárny faktor. Napríklad taký git pri väčšine operácii neposiela na štandardný výstup veľký objem dát. Je to ale stále externý program a tak na ten štandardný výstup neposiela objekty, ale text. A s textom, rozloženým na jednotlivé riadky, sa v ďalšom kroku kolóny pracuje. V bloku ForEach-Object je ale možné jednotlivú položku vo forme reťazca zabaliť do objektu PowerShellu, teda urobiť z položky vo forme reťazca vlastnosť vytvoreného objektu a pridať objektu aj ďalšie vlastnosti, ak je to potrebné. Ako výsledok spracovania v danej fáze bude do kolóny poslaná položka ako objekt a s tým sa potom už pracuje v ďalších fázach spracovania.

Vo Windows ako takom sa ale veľké objemy dát kolónou presúvať môžu a dajú. Keď to bude spustené mimo PowerShell, teda v rámci cmd.exe, bude to fungovať úplne rovnako ako na Linuxe. A keď to bude spustené v rámci PowerShellu, pôjde to cez jednu dodatočnú vrstvu, keďže je tam v hre .Net.

Či má používateľ nejaký pocit naozaj neviem. Pokiaľ je to bežný používateľ, tak nevie ako to funguje, jednoducho vlepí riadok z internetu a počká si ako to dopadne. Z okolitého popisu sa zvyčajne dá pochopiť, či to má byť vlepené do PowerShellu alebo do cmd.exe. Pokiaľ je to ale niekto, kto PowerShell pozná, tak vie, že nástroje, ktoré používa počas väčšiny svojej práce ako odosielateľov a príjemcov dát, sú interné a že prenášajú objekty. Veď tie dáta, ktoré po kolóne lietajú, bežne ako objekty používa - filtruje podľa ich pomenovaných vlastností alebo podľa pomenovaných vlastností usporiadáva, zoskupuje alebo si ich necháva zobraziť ako tabuľku, teda v stĺpcoch s možnosťou zobrazovania a skrývania jednotlivých stĺpcov podľa názvu vlastnosti. A keď potrebuje použiť externý program, tak vie, že je to externý program, a že ten, pokiaľ nebol písaný pre PowerShell, čo napríklad vyššie spomenutý git bude asi ťažko, nemôže posielať na výstup objekty PowerShellu, na ktoré je zvyknutý.

Vo Windows ale nikdy nevznikla kultúra zreťazenia činnosti viacerých malých programov. Prevažnú väčšinu používateľov Windows tvorili spotrebitelia zvyknutí na používateľské rozhranie a príkazový riadok im bol cudzí. Až neskôr vznikol PowerShell, ktorý mnohé z činnosti, ktoré v Linuxe riešia malé externé programy, rieši internými  nástrojmi z jeho štandardnej knižnice. Niečo o jeho histórii, motivácii a dôvodoch návrhu je v texte, ktorý som pripojil v predchádzajúcej správe. Mne pripadalo byť veľmi zaujímavé, že niekto chcel vytvoriť nástroj, ktorý by bol zároveň hostiteľom pre príkazový riadok, zároveň pokročilým programovacím jazykom s priamym napojením na behové prostredie alebo aj API operačného systému, a zároveň aj REPL toho programovacieho jazyka.

Nemám už na vás čas, ako som už písal: "do tejto témy zapojil výhradne kvôli tomu, že tu predtým panoval názor, že je nutné kvôli deduplikácii počítať hash z celého objemu dát všetkých súborov, čo teda ani náhodou nie je pravda."

Nad rámec toho si myslím, že som urobiť všetko, čo sa dalo, aby som vám (a ostatným) dostatočne objasnil, že to, čo ste tu písali o Windows je nezmysel.

2

Software / Re:Odstranění duplicit a konsolidace dat

« kdy: 14. 05. 2026, 16:50:50 »

A? Má to niečo spoločné s mojou prvotnou odpoveďou? Vidíte v nej niekde, že by som cez kolónu posielal nejaké veľké dáta?

... pretože v tom nikto žiadne veľké dáta cez kolónu neposiela.

A to je lež.

Lež??? Akože viem, že je to inak a úmyselne vás klamem? Ako si niečo také vôbec môžete dovoliť? Kto si myslíte, že ste???

Už jsem přes kolonu posílal i víc než 1 TB dat, například při kopírování velkého množství souborů mezi disky. Je to rychlejší než příkazem cp a skvěle to funguje i přes ssh.

To pre mňa vôbec nie je relevantné, ja som písal o mojom riešení, teda a o tom ako to má PowerShell.

Kdyby to ve Windows fungovalo stejně jako v Linuxu, tak by to programátoři používali mnohem častěji, protože je to nejrychlejší možná komunikace mezi běžícími procesy. Množství dat není nijak omezeno velikostí volné operační paměti ani volného místa na úložišti. Píšeš, že v PowerShellu se předává jen odkaz na objekt. Jaký objekt, když procesy mají oddělené adresové prostory? Jedině přes operační systém. A přesně tak to dělají kolony.

S takouto mierou nekompetentnosti som sa tu ešte (asi) nestretol. Ale dobre, tak ešte jeden pokus. A pomaly, pre extrémne nechápavých:

Jeden z vašich najväčších problémov, teda okrem toho, že ste troll, je v tom, že si mýlite dojmy s pojmami. Opakovane som vás upozorňoval, že si mýlite operačný systém s programovacím jazykom. Ale nezabralo to.

Moje riešenie používa PowerShell. PowerShell je viac vecí v jednom. Jedna z nich je hostiteľ príkazového riadku. V kontexte môjho riešenia je ale PowerShell použitý ako programovací jazyk.

PowerShell ako taký je normálny používateľský proces a s operačným systémom nemá vôbec nič spoločné. Existujú v ňom kolóny, je to jednoducho abstrakcia postupného spracovania vo viacerých fázach, ale sú implementované na inej úrovni abstrakcie ako kolóny operačného systému.

Nepoužívajú na prenos medzi jednotlivými fázami zápis na štandardný vstup a čítanie zo štandardného vstupu, ale odkaz na objekt. A nie je to žiadny problém, lebo je to všetko v jednom procese. V kontexte PowerShellu totiž používate interné nástroje z jeho štandardnej knižnice, a až keď potrebujete pracovať s externým programom, prenos prechádza cez dáta. Ale aj ten je realizovaný najlepšie ako sa v rámci jeho podkladovej platformy, ktorou je .Net/CLR dá, keby to malo byť pre moje riešenie náhodou dôležité. Zjednodušene povedané.

Všetky vaše poznámky o kolónach vo Windows sú v tomto kontexte teda absolútne mimo. Mnou navrhnuté riešenie nemá s Windows nič spločné. Vy ste doteraz za celé tie roky naozaj nezaregistrovali, že PowerShell funguje aj na Linuxe aj na MacOS?

Čo sa Windows týka, tak tá legenda o dočasných súboroch, ktorú si v komunite asi často opakujete, keď pretrvala štvrtinu storočia po tom ako prestala byť platná, sa týka kolóny v command.com, ten bol naposledy v spotrebiteľskej verzii systému vo Windows 95, možno Windows 98. V podnikovej verzii systému ale už v tej dobe existoval cmd.exe, ktorý bol v podstate prevzaný z OS/2. To bolo asi vo Windows NT 3.1. A cmd.exe používa úplne rovnaký mechanizmus ako Unix.

Minimalistický zdroj, ktorý to potvrdzuje, nájdete tu: https://en.wikipedia.org/wiki/Cmd.exe

Stačí vám to tak? Obávam sa, že nie, tak som špeciálne kvôli vám nechal vygenerovať trochu podrobnejší popis. Samozrejme som to nepísal ja osobne, je to Claude. Požiadal som, aby sa to dalo dobre čítať. Na základe skúsenosti s vami sa zdá, že máte naozaj problémy s chápaním písaného textu.

Na konci máte špeciálny zoznam pre ľudí ako ste vy, teda takých, ktorí keď niekde vidia spomenuté Windows, musia si uľaviť, tak ako pod mojím prvým príspevkom. Celé je to inak celkom zaujímavé čítanie, ktoré by normálnym ľuďom mohlo trochu otvoriť oči o tom aká je história operačných systémov, čo odkiaľ pochádza, čo je odkiaľ prevzaté, atď. Asi si nerobím úplne ilúzie, že by ste to chceli čítať, ale aj tak. Možno si to prečíta niekto iný.

Je to v prílohe ako súbor v markdown.

3

Software / Re:Odstranění duplicit a konsolidace dat

« kdy: 13. 05. 2026, 22:18:05 »

Neviem, čo vám skrachovalo, v podstate ma to ani nezaujíma, neobťažovali ste sa sem vlepiť príkazy, ktoré ste použili, dohadovať sa o tom, čo to bolo a riešiť to je pre mňa strata času, ale z toho popisu, čo ste sem dali si myslím, že je to úplne mimo kontext toho, čo som písal ja, aj mimo mnou navrhnutého riešenia, pretože v tom nikto žiadne veľké dáta cez kolónu neposiela. To nakoniec v PowerShelli v rámci jeho štandardnej knižnice celkovo nerobí nikto, posielaný je odkaz na objekt .Net obsahujúci metadáta týkajúce sa položky súborového systému, ako napríklad cesta, dátumy, veľkosť, vlastnosti, atď., prípadne ďalšie pridané vlastnosti. Dáta zo súboru sú načítavané prúdom .Net po častiach, inkrementálny hash je tiež počítaný objektom z .Net. To všetko je uvedené už v mojom prvom príspevku.

Přes kolonu běžně posílám desítky GB dat. Jednoduchý příkaz:

Kód: [Vybrat]

tar czvf - adresář | gzip > archiv.tgzFunguje to skvěle, rychle a využiji tím 2 jádra procesoru současně.

Pro deduplikaci souborů:

Kód: [Vybrat]

sha256sum . | sort | filtr_mazající_duplicity

A? Má to niečo spoločné s mojou prvotnou odpoveďou? Vidíte v nej niekde, že by som cez kolónu posielal nejaké veľké dáta?

Prípadne, má to niečo spoločné s mojou poslednou odpoveďou? Že neviem, čo konkrétne a kde konkrétne ste písali, keď vám to skolabovalo?

Táto konkrétna vec totiž na Windows funguje principiálne rovnako ano na Linuxe. S prihliadnutím na rozdiely v API a v modeli procesov a vlákien. Asi tak od čias NT 3.1. To bol rok asi tak 1993. Už som vám to niekoľkokrát opakoval. Ale je to márne, je to márne, je to očividne márne.

Záver pre mňa: niekde ste počuli niečo, čo platilo pre Windows 95 a ste schopný opakovať to do nekonečna bez toho aby ste sa obťažovali vyhľadať si ako to v skutočnosti je. Plus si ešte mýlite operačný systém a programovací jazyk. Ale to už som písal.

4

Software / Re:Odstranění duplicit a konsolidace dat

« kdy: 12. 05. 2026, 22:02:34 »

Už som vám naznačoval, že to, čo ste popisovali, je už viac ako 25 rokov vyriešené a teda žiadne súbory tam nie sú. A okrem toho, v PowerShelli idú dáta cez kolónu k spotrebiteľovi cez ešte menšiu časť pamäte ako v Linuxe. Dokumentácia aj zdrojový kód sú tuším otvorené a verejne dostupné.

Dá se to poznat tak, že tou rourou pošlu třeba 200 GB dat, když je jen 100 GB volného místa v úložišti. Pokud mám pravdu, tak to zkolabuje. Pokud nemám pravdu, tak to proběhne během několika málo sekund.

Ve Windows 10 mi to zkolabovalo.

Nehnevajte sa, ale vy naozaj pôsobíte v IT? Nemyslím si, že má pre mňa zmysel pokračovať v debate s niekým, kto očividne nepozná rozdiel medzi programovacím jazykom a operačným systémom, kto sa nenamáha prečítať si navhrnuté riešenie predtým ako sa k nemu vyjadrí a kto sa neobťažuje zistiť si ako veci v skutočnosti fungujú na iných platformách, napriek tomu, že dostane informáciu, že je všetko prístupné a že veci už dávno fungujú inak ako si celé roky myslí.

Neviem, čo vám skrachovalo, v podstate ma to ani nezaujíma, neobťažovali ste sa sem vlepiť príkazy, ktoré ste použili, dohadovať sa o tom, čo to bolo a riešiť to je pre mňa strata času, ale z toho popisu, čo ste sem dali si myslím, že je to úplne mimo kontext toho, čo som písal ja, aj mimo mnou navrhnutého riešenia, pretože v tom nikto žiadne veľké dáta cez kolónu neposiela. To nakoniec v PowerShelli v rámci jeho štandardnej knižnice celkovo nerobí nikto, posielaný je odkaz na objekt .Net obsahujúci metadáta týkajúce sa položky súborového systému, ako napríklad cesta, dátumy, veľkosť, vlastnosti, atď., prípadne ďalšie pridané vlastnosti. Dáta zo súboru sú načítavané prúdom .Net po častiach, inkrementálny hash je tiež počítaný objektom z .Net. To všetko je uvedené už v mojom prvom príspevku.

Správate sa ako troll, ktorý, keď vidí niekde napísané Windows, jednoducho sa potrebuje vyjadriť, že Windows je šmejd, napriek tomu, že daná téma sa Windows vôbec nijako netýka. Okrem toho, že predrečník má vo Windows dáta. Ale má ich aj na Linuxe a PowerShell funguje aj tam. Podobnú skupina tvoria ľudia, ktorí sa správajú rovnako, keď vidia niekde napísané C++. Nebol by som prekvapený, keby ste boli členom oboch skupín.

Ja osobne som do tejto témy zapojil výhradne kvôli tomu, že tu predtým panoval názor, že je nutné kvôli deduplikácii počítať hash z celého objemu dát všetkých súborov, čo teda ani náhodou nie je pravda a aspoň toto si už možno uvedomujete aj vy, takže som rád, že som to mohol objasniť a možno trochu zjednodušiť život aj vám a to napriek tomu, že ste písali, že je to optimalizácia, ktorá nie je potrebná.

Ostatné veci už s dovolením nechávam na vaše samoštúdium.

5

Software / Re:Odstranění duplicit a konsolidace dat

« kdy: 12. 05. 2026, 18:24:42 »

Ve Windows je to tak komplikované? No jo, nemají roury...

PowerShell pochopiteľne "roury" má, a asi vás zmiatlo, že nepíšem o primitíve spájajúcom dve fázy spacovania, čo je menej dôležitý koncept, ale o celom mechanizme kolóny, označenom tak sme sa to kedysi dávno učili.

Pokud vím, tak Windows mají stále parodii na roury přes dočasné soubory. Není to efektivní a proto je uživatelé moc nepoužívají. Zejména při zpracování velkých souborů je to problém.

Je možné, že si mýlite operačný systém a programovací jazyk? To by sa v kombinácii s tým ako autoritatívne sa vyjadrujete k príspevkom ostatných asi nemalo stávať.

Jasne píšem, že je to pre PowerShell a ten predsa beží aj na Linuxe aj na MasOS. Tak prečo do toho montujete Windows, mimochodom vo verzii 95, možno 98? Odvtedy už tie veci, ktoré spomínate fungujú inak a to už je minimálne štvrť storočia. Okrem toho v prvej odpovedi spomínam aj iné programovacie jazyky. Mechanizmus vyraďovania súborov, ktoré nie sú duplikátmi ostane rovnaký.

V Linuxu je podpora pipe službou operačního systému, není tedy součástí aplikace. Vůbec nevyužívá souborový systém, data jdou od producenta ke konzumentovi přes velmi malou část operační paměti. Ve Windows je podpora emulována přes soubory a tím má mizerný výkon. Netuším, zda to v pozdějších verzích napravili, ale nemám to jak zjistit. V desítkách to ještě nebylo a obávám se, že to tam stále není.

Vy si naozaj mýlite operačný systém a programovací jazyk. To že je na jednej platforme niečo implementované nejako neznamená, že to tak nutne musí byť implementované aj na iných platformách.

Už som vám naznačoval, že to, čo ste popisovali, je už viac ako 25 rokov vyriešené a teda žiadne súbory tam nie sú. A okrem toho, v PowerShelli idú dáta cez kolónu k spotrebiteľovi cez ešte menšiu časť pamäte ako v Linuxe. Dokumentácia aj zdrojový kód sú tuším otvorené a verejne dostupné.

6

Software / Re:Odstranění duplicit a konsolidace dat

« kdy: 12. 05. 2026, 15:10:04 »

Sám jsem deduplikaci pomocí hash úspěšně udělal v Bashi na své sbírce filmů. Najde shodu i když mají různé názvy.

Pokud tě zajímají jen přesné duplicity, tak je to v pohodě, i když to na velkém úložišti bude prostě trvat (přečíst celý disk a prohnat ty TB skrz CPU...)

Práveže ak chcete iba nájsť presné duplicity, tak všetky tie TB dát cez CPU prehnať nemusíte, stačia iba tie, ktoré sú bezpodmienečne nutné.

Aha, pardon, asi jsem ještě neměl dost kofeinu v krvi. :-)

To nevadí, nemám problém niečo zopakovať. Je fakt, že tá moja prvá odpoveď bola dosť dlhá.

7

Software / Re:Odstranění duplicit a konsolidace dat

« kdy: 12. 05. 2026, 15:04:04 »

Ve Windows je to tak komplikované? No jo, nemají roury...

PowerShell pochopiteľne "roury" má, a asi vás zmiatlo, že nepíšem o primitíve spájajúcom dve fázy spacovania, čo je menej dôležitý koncept, ale o celom mechanizme kolóny, označenom tak sme sa to kedysi dávno učili.

Pokud vím, tak Windows mají stále parodii na roury přes dočasné soubory. Není to efektivní a proto je uživatelé moc nepoužívají. Zejména při zpracování velkých souborů je to problém.

Je možné, že si mýlite operačný systém a programovací jazyk? To by sa v kombinácii s tým ako autoritatívne sa vyjadrujete k príspevkom ostatných asi nemalo stávať.

Jasne píšem, že je to pre PowerShell a ten predsa beží aj na Linuxe aj na MasOS. Tak prečo do toho montujete Windows, mimochodom vo verzii 95, možno 98? Odvtedy už tie veci, ktoré spomínate fungujú inak a to už je minimálne štvrť storočia. Okrem toho v prvej odpovedi spomínam aj iné programovacie jazyky. Mechanizmus vyraďovania súborov, ktoré nie sú duplikátmi ostane rovnaký.

Takže když v bloku n+1 změním písmenko, tak jsou soubory stále shodné?

- ak je ale kontrolný súčet za prvých n blokov rovnaký, tak ten rozdiel v jednom bajte zistíte v iterácii n+1, do iterácie n sú súbory kandidátmi na duplikáty, ale v iterácii n+1 nimi byť prestanú a tiež ich vyradíte z ďalšieho spracovania

Inak, mohol som asi použiť i na označenie čísla iterácie, ale to už je teraz jedno.

Takže ty soubory stejně musím projít celé, ale už chápu, že jen některé.

Áno, ale iba tie, ktoré sú naozaj duplikátmi, tomu sa nedá zabrániť, ak chceta mať istotu. Veľa z tých, ktoré duplikátmi nie sú vypadne v prvých iteráciách.

8

Software / Re:Odstranění duplicit a konsolidace dat

« kdy: 12. 05. 2026, 11:53:14 »

sam mam zkusenost, ze delat hash jednotlivych souboru a porovnavat je overkill.

.
Postup v skratke pre PowerShell: ...

Ve Windows je to tak komplikované? No jo, nemají roury...

Njn, ešte stále sa stáva, že tu niekto "trollí", ale to že sa nájde niekto, kto má problém s chápaním písaného textu, porovnáva neporovnateľné a vyjadruje sa tak ako vy, ma už v tejto dobe naozaj trochu prekvapuje.

PowerShell pochopiteľne "roury" má, a asi vás zmiatlo, že nepíšem o primitíve spájajúcom dve fázy spacovania, čo je menej dôležitý koncept, ale o celom mechanizme kolóny, označenom tak sme sa to kedysi dávno učili.

To máte ako s vláknom, mne sa tiež slovo vlákno nepáči, ale akceptujem, že ho niekto kedysi dávno z nejakých dôvodov zaviedol.

Tu máte článok, kde je to slovo použité, myslím, že médium, kde je ten článok publikovaný je v odbornej komunite celkom rešpektované:  https://www.root.cz/clanky/terminaly-tajemstvi-zbavene-procesy-a-signaly/

Je k tomu aj celkom výživná diskusia, kde sú uvedené dôvody prečo toto slovo a prečo ho niektorí nechápu.

Pokiaľ ale máte pocit, že som niečo mohol napísať inak a že je chyba na mojej strane, čo sa mohlo stať, písal som to v noci, rád sa dozviem čo, nech sú moje príspevky v budúcnosti jednoduchšie na pochopenie.

Súbory, ktoré majú rovnakú veľkosť a nemajú rovnaký inkrementálny hash z prvých n blokov nie sú duplikátmi a nie je teda pre ne nutné počítať hash od bloku n+1. Vlastne možno ani nemusí byť počítaný inkrementálny hash, ale stačí prostý hash z daného bloku, ale to je v podstate jedno, lebo vypočítať hash je lacné v porovnaní so získaním dát z úložiska.

Takže když v bloku n+1 změním písmenko, tak jsou soubory stále shodné?

V akom prípade? keď je kontrolný súčet za prvých n blokov rovnaký alebo rôzny?

- ak je kontrolný súčet za prvých n blokov rôzny, tak vás blok n+1 nezaujíma, lebo tie súbory na základe prvých n blokov nemôžu na byť duplikátmi a v iterácii n ste ich z vyradili, takže v iterácii n+1 vôbec nie sú, pretože kontrolný súčet z nich nepočítate, lebo nemusíte, keďže viete z predchádzajúcej iterácie, že tie súbory nie sú duplikátmi.

- ak je ale kontrolný súčet za prvých n blokov rovnaký, tak ten rozdiel v jednom bajte zistíte v iterácii n+1, do iterácie n sú súbory kandidátmi na duplikáty, ale v iterácii n+1 nimi byť prestanú a tiež ich vyradíte z ďalšieho spracovania

Inak, mohol som asi použiť i na označenie čísla iterácie, ale to už je teraz jedno.

9

Software / Re:Odstranění duplicit a konsolidace dat

« kdy: 12. 05. 2026, 10:32:11 »

Sám jsem deduplikaci pomocí hash úspěšně udělal v Bashi na své sbírce filmů. Najde shodu i když mají různé názvy.

Pokud tě zajímají jen přesné duplicity, tak je to v pohodě, i když to na velkém úložišti bude prostě trvat (přečíst celý disk a prohnat ty TB skrz CPU...)

Práveže ak chcete iba nájsť presné duplicity, tak všetky tie TB dát cez CPU prehnať nemusíte, stačia iba tie, ktoré sú bezpodmienečne nutné.

Dúfal som, že to bude z mojej odpovede jasné. Súbory, ktoré majú rovnakú veľkosť a nemajú rovnaký inkrementálny hash z prvých n blokov nie sú duplikátmi a nie je teda pre ne nutné počítať hash od bloku n+1. Vlastne možno ani nemusí byť počítaný inkrementálny hash, ale stačí prostý hash z daného bloku, ale to je v podstate jedno, lebo vypočítať hash je lacné v porovnaní so získaním dát z úložiska.

10

Software / Re:Odstranění duplicit a konsolidace dat

« kdy: 11. 05. 2026, 23:08:19 »

sam mam zkusenost, ze delat hash jednotlivych souboru a porovnavat je overkill.

Nie celkom, už som to robil niekoľkokrát v rôznych verziách so stovkami tisíc súborov. Zvlášť keď sa jedná iba o deduplikáciu, ktorá je oveľa menej náročná ako sa zdá. Vidím tam Windows, používam na takéto veci PowerShell je na to ako stvorený, má prístup aj do .Net aj do Windows API, dajú sa v ňom písať aj testy aj tam funguje TDD. A to isté by malo fungovať aj na Linuxe, v rámci .Net Core, tuším. Prípadne python alebo C# alebo čokoľvek.

Postup v skratke pre PowerShell: získať položky súborov v daných zložkách, to sú objekty, asi typ FileInfo alebo niečo také, zoskupiť podľa veľkosti, iba súbory s rovnakou veľkosťou (celkovo alebo veľkosť prúdu audio/video dát, ak ignorujem popisky) môžu byť duplikáty; pre každú skupinu veľkosti (cyklus alebo ForEach-Objekt) ktorá má viac ako jedného člena pridať objektom FileInfo v aktuálnej skupine cez Add-Member ako vlastnosť prúd na čítanie bloku dát, pridať aj objekt .Net na inkrementálný hash, zistiť si vopred z úložiska minimálnu veľkosť bloku, ktorú má zmysel načítať z disku (lebo keď aj zadám iba 1 bajt, OS aj tak načíta napríklad 4kb), pre danú veľkosť vypočítať koľko blokov zistenej veľkosti potrebujem na danú veľkosť súboru. Počet blokov určí počet iterácii inkrementálneho hashovania, pre každú iteráciu poslať položky aktuálnej skupiny veľkosti súborov do ForEach-Objekt, pre každú položku v bloku toho ForEach-Objekt načítať pre danú iteráciu i-ty blok podľa čísla iterácie, z prúdu, ktorý bol pridaný do položky v predchádzajúcich krokoch, pridať načítané dáta do kontrolného súčtu cez objekt z .Net, ktorý bol tiež pridaný do položky a vrátiť položku ako výsledok. Plus mínus niečo na tento spôsob.

Pokiaľ takto spracované položky chcem zhromaždené v jednom poli, tak ich normálne priradím do premennej, ak nie, tak ich zreťazím v kolóne s ďalším krokom, tým ten ForEach-Objekt nie je blokujúci, ale je ako generátorová korutina, ktorá posiela položky ďalej do ďalšieho kroku, takže keď napríklad v prvom kroku kolóny je piata položka, prvá položka je už v piatom kroku kolóny, ak ani jeden z krokov nie je blokujúci. (+-1, nerozmýšľam, nepočítam to...)

Ďalším krokom tu ale je zoskupenie podľa aktuálnej hodnoty inkrementálneho kontrolného súčtu. To sa asi dá urobiť iba blokujúco, lebo sú nutné všetky položky.

Tým vzniknú skupiny podľa aktuálnej hodnoty inkrementálneho kontrolného súčtu, tie ktoré po prvej iterácii majú iba jedného člena nemajú rovnaký prvý blok, nie sú to teda duplikáty, tým treba iba zatvoriť prúd, prípadne odobrať a aj ten objekt .Net, ktorý inkrementálne hashuje a zabudnúť na ne.

Súbory v skupinách, ktoré majú viac ako jedného člena sú kandidáti na duplikáty a tie je treba v ďalšej iterácii poslať opäť do toho ForEach-Objekt, kde sa načíta druhý blok dát, pridá sa do inkrementálneho kontrolného súčtu a výsledok sa zas zoskupí podľa aktuálnej hodnoty kontrolného súčtu z prvých dvoch blokov.

Takto postupne vypadnú súbory, ktoré nie sú duplikáty, veľa z nich hneď v prvých iteráciách, pre veľa z nich sa teda kontrolný súčet počíta iba z blokov na začiatku, dovtedy, kým nevypadnú z hry a úplný kontrolný súčet sa vypočíta iba z tých súborov, ktoré naozaj duplikátmi sú.

Takže pre deduplikáciu nie je nutné počítať celé kontrolné súčty zo všetkých súborov.

ForEach-Objekt má aj paralelnú verziu, ale je to zložitejšie, lebo je nutné obmedziť podľa typu úložiska počet paralelne bežiacich úloh (NVME zvládne viac, SATA SSD menej, rotačný disk ešte menej, možno iba 1, sieťové som neskúšal), pokiaľ máte všetko z NVME, je to jednoduché, ak nie, tak sa to dá zoskupiť podľa druhu úložiska a jednotlivé skupiny podľa druhu hardvéru riešite oddelene s rôznym obmedzením súbežnosti a pred zoskupením podľa výsledku aktuálnej iterácie kontrolného súčtu to zlúčite do jedného poľa. V PowerShelli je to iba jedna ďalšia úroveň cyklu a to zlúčenie je vzhľadom na vlastnosti kolóny automatické.

Potom sú tam ešte také veci ako odkazy na súbory, pevné alebo symbolické, to je nutné vedieť rozlíšiť, získať cieľový súbor odkazu, nechať v sade iba jeden výskyt, nemá zmysel deduplikovať 10 súborov, keď všetky ukazujú na tie isté dáta, to zistíte aj z Windows API, že sú to fyzicky tie isté dáta prístupné pod viacerými názvami a je lepšie prefiltrovať to vopred.

Robil som aj presúvanie súborov v jednej stromovej štruktúre podľa vzoru ich umiestnenia v inej stromovej štruktúre, a podobné veci, to ale vyžaduje buď úplné kontrolné súčty pre všetko, alebo podľa typu dát, napríklad audio/video súbory sa dá tipnúť si, že keď sú dáta v strede rôzne, celý súbor je rôzny, tak stačí kontrolný súčet z kúsku dát.

11

Studium a uplatnění / Re:Kam odejít z IT v době AI?

« kdy: 11. 05. 2026, 14:23:32 »

Jinak komerční produkt to byl +- od dob, kdy se tou hudbou někdo začal živit. Od té chvíle se jakékoliv vyjadřování čehokoliv pohybuje v mezích, kdy je za to dost posluchačů ochotných platit.

Áno. Ale bez možnosti zaznamenať zvuk a pustiť ho bez prítomnosti toho, kto je zaznamenaný, tá komercia v rozsahu v akom je dnes neexistovala.

Jinak komerční produkt to byl +- od dob, kdy se tou hudbou někdo začal živit. Od té chvíle se jakékoliv vyjadřování čehokoliv pohybuje v mevo slyšet. Takže se obvykle omezuju na to, co to dělá se mnou.

To sa predsa dá pomerne dobre zistiť podľa toho, kto to vytvoril. Vyberáte si, čo počúvate, nie? Alebo počúvate čokoľvek vám niekto naservíruje?

Ona ta hranice mezi lidskou a umělou hudbou nebyla úplně ostrá už před AI. Jak moc se AI hudba liší od toho, když si někdo nakliká symfonický orchestr ze samplů a své kokrhání prožene přes autotune?

Rozdiel je zásadný. Skúste si niečo naklikať sám a uvidíte, čo dostanete.

Nemyslím si, že sa musíme dohadovať o tom, že hudba generovaná AI neexistuje. Existuje.

Nemyslím si ani, že sa musíme dohadovať o tom, kto má čo počúvať. Pokiaľ niekomu vyhovujú komerčné rádiostanice a hudba generovaná AI, tak nech to počúva.

Pre mňa osobne je to strata času. Pretože počas toho času by som mohol počúvať niečo, čím niekto chcel niečo vyjadriť. A inokedy, ticho je niekedy náhodou celkom fajn.

12

Studium a uplatnění / Re:Kam odejít z IT v době AI?

« kdy: 11. 05. 2026, 12:19:51 »

... Neumí skládat hudbu a texty písní. ...

Mrknul jste někdy poslední dobou na Youtube a podobně? Protože AI generované hudby jsou tam mraky. Nejsou to sice  mistrovská díla, ale kvalita +- odpovídá standardní masprodukci.

Psal hudbu. O načesaném hluku se nezmiňoval.

Jenže pak do toho načesaného hluku padne i většina toho, co před AI nagenerovali lidi. A rozlišovat to je strašně subjektivní.

Ale subjektívna je predsa celá hudba. Neexistuje objektívny hodnotiaci systém, ktorý by označil nejakú hudbu za skvelú a tú by potom na základe toho počúval každý a mal na ňu rovnaký názor.

Vždy záleží na tom, ako kto danú skladbu vníma a čo mu tá skladba prináša. Môže sa to týkať nejakých emócií alebo iba toho načesaného hluku.

Ja osobne si myslím, že je lepšie, keď sa to týka emócií a v tom prípade je lepšie, keď hudbu vytvoril niekto, kto emócie tiež má a niečo tou hudbou vyjadruje. Nebol by som prekvapený, keby hudba bola prvotne vyjadrením niečoho. A hudbou sa vždy vyjadrovali ľudia. To až oveľa neskôr sa z hudby stal ešte aj komerčný produkt.

To, že existuje hudba vytvorená umelou inteligenciou, že je dostupná a že ju niekto dokonca možno počúva, pre mňa osobne nie je vôbec dôležité. Aj keby mala byť kompozične a technicky skvelá. Iba by mala existovať povinnosť takú produkciu jasne označiť, aby sa jej dalo s minimálnymi nákladmi vyhnúť.

A že je všade? Asi v ničom v súčastnosti nie je taká miera nadprodukcie ako v hudbe. Ešte možno vo videách na YouTube.

13

Studium a uplatnění / Re:Kam odejít z IT v době AI?

« kdy: 10. 05. 2026, 23:10:45 »

Pokud jsem z našeho rozhovoru vyrozuměl dobře, říkal, že největším problémem je zadání. Musí vytvořit tak dobré zadání, aby AI vygenerovala správný kód, a ne něco jiného. Udělat dobré zadání, prý dá hodně práce.

Dá to hodně práce, je to pěkná otrava

Ale pak tím vznikne skvělá dokumentace, což má pro následující rozvoj velkou hodnotu.

To se nevylučuje.

Celkom by ma zaujímal názor ctených účastníkov, čo sa v posledných mesiacoch stalo s tým, že ľudia nevedia, čo chcú. To už teraz neplatí? Nevznikol náhodou agilný proces, keď už musím použiť to škaredé slovo, kvôli tomu, aby sa postupne odstraňovala neurčitosť? Keď sa v tejto dobe do detailu špecifikuje zadanie hneď na začiatku a považuje sa to za správny postup. To už je teraz také rýchle a také lacné, že keď sa zistí, že boli tokeny spálené na niečo, čo je niečo iné ako je v skutočnosti potrebné, tak sa prepíše špecifikácia a nechá sa to vygenerovať zas?

a stejně pak člověk musí celý výsledek podrobně projít a doladit.

Alternativně je možno v zadání vyžadovat vytvoření detailních testů, a pokud ty budou OK tak se dá podrobné procházení a dolaďování vynechat.

Kéž by to bylo vždy tak jednoduché... Nemluvě o tom, že testy pokryjí koncovou funkcionalitu (a ani v tom nejsou dokonalé) ale rozhodně neřeší spravovatelnost, celkový návrh a mikroarchitekturu. Což je zcela typický omyl lidí, kteří nevyvíjí a pro které nic jiného, než koncová funkcionalita neexistuje. (Ostatně není to nic nového, tak to bylo i před AI. Ale AI má skvělou schopnost dát tomu vyloženě destruktivní potenciál.)

Súhlasím.

Navyše, kdesi som čítal alebo počul, že AI nevylepšuje, ale zosilňuje toho, kto s ňou pracuje. Vo všetkom. Aj v chaose.

Inak čo sa týka tých vygenerovaných testov, dáva vám zmysel nechať si vygenerovať testy a nechať si zároveň tým istým generátorom povedať, že tie testy sú v poriadku a že všetky boli úspešné? To nekontrolujete ani tie testy, čo vám to vygeneruje, či dávajú zmysel? A ak mám teda naozaj provokovať, ale fakt bez urážky, viete vôbec písať testy a posúdiť, či sú dobré alebo zlé?

A ešte som si všimol, že je v poslednej dobe veľmi populárne TDD. Teda tá skratka. S obsahom, ako ho chápu AI influenceri. Čo nemá so skutočným TDD príliš spoločného.

PS: Keby to náhodou nebolo jasné, reagujem na viacerých účastníkov diskusie. Viem, že pán Poljak testy rád nepíše, ale tá posledná časť naozaj nie je o ňom.

14

Vývoj / Re:Používáte LLM při vývoji?

« kdy: 31. 03. 2026, 22:17:35 »

Tady je asi ta absurdita videt, v AI je to zatim schovane za tvrzeni "budouci modely budou lepsi (budou? - uz ted se naucily ze vsecho dostupneho)"

Už niekoľkokrát som zaregistroval názor, že modely ako také už svoj potenciál vyčerpali a že aktuálne vnímané zvýšenie užitočnosti je vďaka tomu, čo je naokolo, teda to ako sa modely spúšťajú a čo spúšťajú.

15

Vývoj / Re:Používáte LLM při vývoji?

« kdy: 31. 03. 2026, 22:10:49 »

Ja mam zatim fakt problem ten limit najit. Vzdycky si reknu, ze tohle uz nepujde a vzdycky me to prekvapi...

Asi záleží na tom aké robíte aplikácie. Sú to iba podnikové systémy alebo systémové aplikácie riadené rôznymi druhmi udalostí, s rôznymi druhmi súbežnosti, využitím medzipamäte, atď?

Dokazes mi nadefinovat kde konci trivialni aplikace a kde zacina seriozni business?

Často stačí jedno netriviálne prepojenie medzi dvoma vrstvami, alebo väzba niečoho na životnosť zúčastnených objektov, alebo na určitú potrebnú postupnosť operácií a celé sa to rozsype.

Popisovať takéto scenáre v prirodzenom jazyku je viac práce ako napísať kód.

Keď človek vie, čo robí.

A keď nevie, čo robí, tak to s LLM nevyrieši, lebo sa to bude točiť dookola. Ani s agentami to nevyrieši. Lebo sa to bude točiť dookola a páliť tokeny.

Takže ja to používam na ukážky atď., tam to vnímam ako užitočné.