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.
Poslední příspěvky