Názory k článku Microsoft otevírá PowerShell a vydává ho pro Linux
-
Tak si to uzij a napis pak na blog. Jsem opravdu zvedavy, jak ti to bude fungovat. Tedy napriklad kolik externich prikazu bude chybet. Krome toho, prakticke pouziti bych si dokazal predstavit napriklad v pripade, ze MS na Linux naportuje i ty strasne utility z MS Resource Kit, ale to se asi nechysta.
-
Adam KaliszStříbrný podporovatelPowerShell na Windows je určitě krok správným směrem. Nějaké věci jsou sice dost neintuitivní a některá použití nejsou úplně elegantní při nízkých nárocích na administrátora/ programátora, ale i tak usnadňuje poměrně výrazně práci. Jestli to tak bude i na "Linuxu" je těžko říct. Na druhou stranu ale bude jednodušší prostě používat "Linux" jako hlavní operační systém a otravné úkoly okolo Windows Serverů realizovat např. pomocí nyní lépe podporovaného WinRM a PowerShellu. Viděl bych tedy tyto snahy poměrně pozitivně pod tím úhlem, že snižuji závislost na Windows.
-
Stepan (neregistrovaný)
Powershell je fajn nástroj, nejčastěji se setkáte se skripty pro lokální konfiguraci služeb, networkingu atd. Zde ale jeho možnosti nekončí, v praxi používám Powershell na vzdálenou správu přes WinRM. Z toho správcovsky-uživatelského hlediska mi vážně sedí. Zde vidím možné využití např. pro správce, kteří si do infrastruktury přibrali nějaké služby běžící na MS Windows. Otázka, co všechno bude umět. Pokud by dosahoval stejné funkcionality, jak ten na MS Windows ...
http://www.howtogeek.com/117192/how-to-run-powershell-commands-on-remote-computers/
-
JA (neregistrovaný)
Jako windowsak jsem stale nejak powershellu nepropadl. Ani jsem se vlastne nikdy nesnazil to ani naucit. Uprimne, tyhle skriptovaci jazyky je vhodne vyhodit od deseti radku kodu. A do deseti radku bohate postaci i clasicky command.com.
Nicmene co se tyce bashe, ktery ma stale jeste vyzadovanu exaktni syntaxi ala pascal 1.0, ale ve vyrazove logice jej i ten pascal o pul stoleti predbiha a za poslednich 40 let se ten fosil nikam nepohl, je zhovadilost to pouzivat i na byt jednoradkove skripty. Takze tam kde je bash, tak powershell nema moc velkou konkurenci a jak rika klasik - i T602ka je lepsi skriptovaci jazyk nez bash:) -
Ondra Satai NekolaZlatý podporovatelDovolim si jako interektivni shell doporucit fish, je to dalsi krok v podobnem smeru, jako byl zsh od bashe.
-
Adam KaliszStříbrný podporovatel
PowerShell bych viděl spíše někde na úrovni Pythonu. Nejsem nějaký znalec, ale v PowerShellu se dá docela produktivně pracovat, když nemusíte obcházet nějaká omezení Windows jako krátké cesty, poměrně slabý remoting pomocí WinRM (tedy ve srovnání s OpenSSH), vše je UTF-16 pokud se tomu aktivně nevyhýbáte (třeba protože potom mají logy v UTF-8 poloviční velikost) a připojování vzdálených souborových systému také není z mého pohledu žádné terno z pohledu předvídatelnosti a případně debuggovatelnosti.
Problém PowerShellu je, že autoři prostě nepochopili UNIXovou filozofii i když se snažili poučit se ze zkušeností při užití UNIXových nástrojů a mj. částečně i SQL. Je to tedy monolitický miš-maš, kdy sice můžete dodat Vaše cmdlety podobně jako můžete do nějaké cesty v PATH na *NIXu nakopírovat/ nalinkovat nějaké binárky. Zlepšuje se to, ale v praxi prostě máte na nějaké mašině PS 2.0 a někde PS 4.0 a nemůžete se na funkcionalitu spolehnout, nemůžete v produkci jen tak upgradovat (protože reboot, protože Windows) atd.
Pokud omezení Windows nepřetečou do PowerShellu pro Linux a pokud bude super jednoduché nějak napojit textové nástroje na jinak objektově orientovaný PowerShell, tak by to mohl být opravdový pokrok z hlediska systematičnosti. Jednou by třeba v nějaké obskurní distribuci mohl nahradit bash/ dash a spol. -
Adam KaliszStříbrný podporovatel
Jinak po zběžné zkoušce PowerShell pod Debian 9 Stretch (testing) vypadá poměrně dobře. Less a podobné nástroje úplně v pohodě s cmdlety komunikují a mohly by tedy jisté nedostatky PowerShellu prozatím při vhodném nasazení kompenzovat.
-
Registry jsou, tak to už u Microsoftu často bývá, docela dobrý nápad se strašně zmršenou implementací. Pro uživatelské aplikace už máme dconf, který, ač není bez chyby, má většinu výhod registrů bez většiny jejich problémů. Kdyby systemd zavedl, tedy ano, v podstatě vnutil, trochu koherence a pořádku do té odporné slátaniny zvané /etc, tak co by ne.
-
Ted je otazka, jestli registry lze udelat jinak, nez tak, ze je konfigurace jedne veci rozptylena po tisici ruznych klicich a ruznych mistech registry, bez komentaru, bez moznosti zjistit, ktere klice uz nicemu nepatri a dalsimi lahudkami. Dekuji, ale davam prednost te odporne slatanine v /etc a doufam, ze ani Poettering nedostane napad vylepsit Linux o registry.
-
To je právě jeden z důvodů, proč tvrdím, že implementace registrů ve Windows je katastrofa, což ovšem neznamená, že je nutně špatná i samotná idea.
Představme si, že místo desítek souborů v /etc, bez ladu a skladu a každý samozřejmě s jinou, čistě arbitrární syntaxí, by důsledně platilo pravidlo, že každá položka obsahuje právě jednu jedinou informaci. Prostě tak, jako máme /etc/hostname, by bylo i např. /etc/passwd/honza/uid, obsahující jedinou hodnotu typu integer.
Adresář /etc by byl namontován na speciálním FS typu klíč-hodnota, který by vynucoval správné typování a zároveň by zaručil, že jakékoliv změny proběhnou atomicky. Jednotlivé "registry" by pak mohly podléhat normálním přístupovým právům, čímž by odpadla nutnost mít setuid a sudo. Výborný princip, že "všechno je soubor" by se tak posílil, aplikace i admin nástroje by byly mnohem jednodušší a spolehlivější a jakékoli nastavení čehokoliv by se dalo snadno provádět programově.
Kdyby tohle někdo prosadil, tak mu bude patřit všechna čest.
-
mhi (neregistrovaný)
Problem registru je zejmena v tom, ze spousta aplikaci vyzaduje ulozit specificka konfiguracni data a to se potom nejak roubuje na registry, vznikaji "foreign klice" (treba GUID), ruzne se to matla, etc. Nevidim taky zadny prakticky duvod k centralnimu ulozisti konfigurace (samozrejme, jednotlive konfiguracni soubory by mely byt nekde smysluplne ulozene, treba v tom /etc ). Rychlost take neni argumentem, jednotlive soubory se bud' daji cachovat nebo staci nepsat prasacke aplikace.
Daleko lepsi zpusob se mi jevi Applovsky .plist, ten se alespon da snadno rucne editovat a zadnymi velkymi nevyhodami netrpi (opet-je to ale vynuceni urciteho formatu, kteremu se podrizuji aplikace). Kdyby se doplnil o nejake vazby mezi soubory, tak to ma i moznost automatizovane s tim pracovat.
-
Prostě tak, jako máme /etc/hostname, by bylo i např. /etc/passwd/honza/uid, obsahující jedinou hodnotu typu integer.
Uzasne. Takze /etc by primo editovat neslo, protoze by se z toho clovek posral. Byl by tam milion adresaru, podadresaru a klicu. Pristup by se zpomalil, protoze by bylo nutne prohledavat slozitu adresarovou strukturu.
Adresář /etc by byl namontován na speciálním FS typu klíč-hodnota, který by vynucoval správné typování a zároveň by zaručil, že jakékoliv změny proběhnou atomicky.
Takze namisto parsovani souboru aplikaci ziskame parsovani milionu malych souboru pomoci virtualniho FS. To bude urcite rychlejsi. Dalsi hezka vec je, ze na kazde a=5 se spotrebuje jeden alokacni blok, takze budeme mit "registry" jeste vetsi, nez ma MS registry.
Otazka je, co tim ziskame. V Linuxu parsuje konfigurak typicky jenom aplikace, ktere patri a to typicky jen pri startu, obcas nektera kdyz dostane SIGUSR (ve Widlich tomu tak neni, tam Widle i aplikace porad dokola ctou a casto i zapisuji klice - oni to asi pouzivaji misto /tmp).
Tak kvuli tomu se takova harafika urcite vyplati. Zejmena, kdyz tim ziskame dalsi uroven nekompatibility s ruznymi *NIXy. Tedy uz nejen systemd bude komplikovat portaci softu, ale i "registry". Ne, dekuji, ale o napodobeniny MS techologii opravdu nestojim.
-
Jenda (neregistrovaný)
> Dalsi hezka vec je, ze na kazde a=5 se spotrebuje jeden alokacni blok
To není pravda, psal, že se použije speciální FS. Můžeš si to představit jako kdyby někdo napsal FUSE nad sqlite. Tam se taky pro každou hodnotu nespotřebuje celý blok.
Stejně si ale myslím, že tím nic nezískáme. A navíc tím rozbiješ třeba možnost mít /etc v gitu.
-
@Jenda: Precti si jeste jednou, co napsal: Představme si, že místo desítek souborů v /etc, bez ladu a skladu a každý samozřejmě s jinou, čistě arbitrární syntaxí, by důsledně platilo pravidlo, že každá položka obsahuje právě jednu jedinou informaci. Prostě tak, jako máme /etc/hostname, by bylo i např. /etc/passwd/honza/uid, obsahující jedinou hodnotu typu integer.
Co s tim pak udela nejaky virtualni system, ktery nad tim pobezi, je totalne nezajimave.
-
@Jenda: A ten specialni FS, potvora, bude take mit alokacni jednotku. Pricemz ten specialni FS bude pouzit jen tehdy, pokud se uzivateli bude chtit pri instalaci opruzovat s tvorbou extra oddilu se specialnim FS jen kvuli par desitkam KB v /etc. Take by ten specialni FS mohl byt vytvoen v souboru, prislusne naformatvanem a namotovanem na /etc. Takze budeme mit vlastne jede velky konfigurak, ktery bude skoro jako registry. Bravo, v Redmondu by z vas meli radost.
-
Uzasne. Takze /etc by primo editovat neslo, protoze by se z toho clovek posral. Byl by tam milion adresaru, podadresaru a klicu. Pristup by se zpomalil, protoze by bylo nutne prohledavat slozitu adresarovou strukturu.
Proč by nešlo?
echo "true" > /etc/network/enp1s0/ipv6/slaac/auto
S klávesou TAB by to bylo mnohem jednodušší, než editovat nějaký dlouhý román a hledat v něm, kdeže to vlastně je. A nevím, proč by to mělo být pomalejší, než např. přístup do /usr/local/lib/python2.7/site-packages. Jestli je v Linuxu něco vyřešené opravdu dobře, tak je to directory traversal.Takze namisto parsovani souboru aplikaci ziskame parsovani milionu malych souboru pomoci virtualniho FS. To bude urcite rychlejsi. Dalsi hezka vec je, ze na kazde a=5 se spotrebuje jeden alokacni blok, takze budeme mit "registry" jeste vetsi, nez ma MS registry.
Zaprvé by se nespotřeboval, pokud FS umí tail packing. Zadruhé spousta jiných věcí žere alokační bloky jak zjednané a nikomu to nevadí. Podívej se například na alokační algoritmus v ZFS a garantuju ti, že ne nebudeš stačit divit. Zatřetí jsem říkal, že by na to měl být zvláštní FS kvůli typové kontrole a atomičnosti, takže nic nebrání tomu, aby jako úložiště používal nějaký kompaktní formát. No a začtvrté je to v době mnohoterabytových disků úplně jedno.
Otazka je, co tim ziskame. V Linuxu parsuje konfigurak typicky jenom aplikace, ktere patri a to typicky jen pri startu,Získáme tím to, že aplikace nebude muset "parsovat" vůbec, pouhý read() poskytne okamžitě hledanou hodnotu. Dneska ano, každá aplikace musí obsahovat parser, v 50% případů je to moloch vyblitý yaccem, v dalších 49% zprasený ručně s obligátními buffer overflow a memory leak a to všechno běží jak jinak, než pod rootem.
A pochopitelně jenom při startu, protože za běhu... už jenom, co by se stalo, když by se při dynamické rekonfiguraci objevil parse error, he?
Tak kvuli tomu se takova harafika urcite vyplati.
Asi vyplatí, protože přesně takovou harafiku používáme každý den už léta: /sys. Celá konfigurace kernelu už dávno funguje výhradně na tomhle principu a neslyšel jsem, že by si na to někdo stěžoval. Jediný rozdíl je v tom, že zatímco /sys je čistě virtuální FS bez perzistence, pro systémové služby a nastavení by perzistence byla nutná, takže nějaký diskový back-end by byl potřeba. Toť vše.
Zejmena, kdyz tim ziskame dalsi uroven nekompatibility s ruznymi *NIXy. Tedy uz nejen systemd bude komplikovat portaci softu, ale i "registry". Ne, dekuji, ale o napodobeniny MS techologii opravdu nestojim.
Neboli učebnicový příklad Baby Duck syndromu ;-)
Předpokládám, že logicky nestojíš takové napodobeniny MS technologií, jako je podpora ACPI nebo power management?
-
Proč by nešlo?
echo "true" > /etc/network/enp1s0/ipv6/slaac/auto
Fantasticky napad. Takze zatimco dnes si otevru jeden soubor, kde mam vsechna nastaveni prehledne i s komentari, v buoucnu budu editovat bordel, kde bude jedna polozka na soubor a bez komntare (ten bude eventuelne v dalsim souboru a cely konfigurak neuvidim nikde. A az budu hledat, co mam blbe, ze to nechodi, tak si to budu soubor po souboru vypisovat na kus papiru a v manu hledat, co je co.
Získáme tím to, že aplikace nebude muset "parsovat" vůbec, pouhý read() poskytne okamžitě hledanou hodnotu. Dneska ano, každá aplikace musí obsahovat parser, v 50% případů je to moloch vyblitý yaccem, v dalších 49% zprasený ručně s obligátními buffer overflow a memory leak a to všechno běží jak jinak, než pod rootem.
Tak nevim, proc by parser mel jet pod rootem, kdyz je to jen na cteni. A jinak brani neco tomu, aby spise byl sjedncen frmat konfiguraku a parser byl obsazen primo v systemu, k dispozici vsem aplikacim? Dokud totiz konfiguraci dela rucne clovek, je textovy konfigurak lepsi. Nebo budeme mit povinne v kazdem systemu GUI a ke kazde aplikaci klikatko?
Asi vyplatí, protože přesně takovou harafiku používáme každý den už léta: /sys.
/sys je zalezitost jadra, ne aplikaci. Existence ci absence /sys nebrani portaci aplikaci. Byly doby, kdy na Linuxu zadny /sys nebyl.
Předpokládám, že logicky nestojíš takové napodobeniny MS technologií, jako je podpora ACPI nebo power management?
Jak na APM, tak na ACPI se MS pouze podilel. Na ACPI se asi podilel hodne, je to videt na tom, jaky je to bordel a jak to a spouste stroju nefunguje. Ke vzniku veci, jako ACPI, MS vubec neni potreba. Ucast MS je naopak nezadouci, protoze tim vznikaji veci, jako Secure Boot v UEFI, ktery na ARMu dokonce ani nesmi jit vypnout.
-
ebik (neregistrovaný)
Hmm, a ted treba konfiguraci apache, vcetne virtualnich serveru, rewritu, atd...
A propos, zrovna ta sitova konfigurace - kdyz si tam clovek nepusti networkmanager (coz jde posledni dobou docela spatne), tak to maji distribuce vytvorene docela pekne. Ja na debianu pouzivam /etc/network/interfaces (nebo /etc/network/interfaces.d/*), a musim rict, ze se v tom vyznam vyrazne lepe, a funguje to 100%. Network manager je notoricky znamy problemy s 802.11X na wired interfacech. Kdyz nejaky problem vyresi tak o par verzi dal zavedou jiny.
Vetsina radku (tedy hodnot v tom vasem konfiguracnim FS) je stejne textovych, ale presto do nich nemuzete napsat cokoli. Takze vase syntakticka kontrola je zde na nic. Konfigurace se musi vzdy otestovat a rozumne programy na to maji rezim, kterym konfiguraci otestuji, a reknou jestli je formalne v poradku. (Napriklad pokud pouzivate volby pro nejaky modul, tak ze ten modul mate uvedeny v seznamu modulu, ktere se maji pouzit.)
Nejlepsim prikladem flexibility textovych souboru je pak konfigurace varnishe. Tomu date v podstate "program" v jazyce vcl (to je jeho vlastni jazyk), ktery se pri nacteni zkompiluje. Ostatne i muj windowmanager se konfiguruje programovacim jazykem (Lua), a mnohokrat jsem to jiz ocenil (mohl jsem si napsat kratky kousek kodu, ktery napravil chovani spatne aplikace, windowmanager mi ho pak spusti na definovane udalosti).
-
Sto let to funguje, vsichni jsou na to zvykli a hlavne to umeji, pak prijde nekdo s genialnim napadem, presvedci particku lidi ve vedeni a pak maji vsichni uzivatele polofunkcni vec, a nikdo to navic neumi, procez se musi ucit nejlepe novy jazyk.
Nejak by me neudivilo, kdyby lidi ve vedeni distribuci mely na notesech windowsy, vlastne by to mnohe vysvetlovalo.... -
Proboha ne! Už to tu sice pár lidí uvedlo, ale aby to nezapadlo v Jardově absurdním šumu:
Problém je v tom "FS typu klíč-hodnota"!!
Tento kocept totiž sám od sebe naprosto nedostačuje!
Opravdu jednoduché aplikace si s tím ještě vystačí, ale už tam dost vadí absence komentářů.
Cokoliv složitějšího už požaduje nějaké složitější datové struktury (hlavně hierarchické) a to se do KEY-VALUE už pasuje hodně, hodně špatně - viz právě ten bordel ve Windows Registry.A to ani nemluvě o případech kdy "konfigurák" je přímo v nějakém programovacím jazyku (např. ten varnish, jak tu někdo uváděl).
-
To je taky pravda. Ale hlavně je tu skutečnost, že každé iracionální číslo obsahuje libovolnou sekvenci, a tedy jakékoli dílo podléhající autorským právům. OSA má logicky nárok na tučné poplatky za každý kruh (operovat s číslem pi znamená nepovoleně kopírovat všechno, co kdy bylo a bude vytvořeno), za každý čtverec (odmocnina z 2!) a za každý výpočet mocniny - z nich se odvozují logaritmy a tudíž i ilegální konstanta e, která ničí hudební průmysl a kvůli které ubozí tzv. "umělci" hladoví stejně jako kvůli pi a sqrt(2).
-
Matematikum, ekonomum a inzenyrum budiz omluvou, ze zadna kalkulacka nepocita s neomezeou presnosti a utrpeni umelcu tak je omezeno typicky na nejakych 8 az 11 desetinych mist.
Nebyt tomu tak, bylo by nutne kazdy projekt studovat i z hlediska numerologie, aby se nahodou nestalo, ze napriklad ve vypoctech ekologicke stavby v blizkosti prirodni rezervace by se vyskytla budovatelska pisen "Traktory vyjely do poli" a podobne ulety. A k tomu by mohlo snadno dojit jiz pri vypoctech s presnosti na nekolik milionu desetinnych mist.
-
Ondra Satai NekolaZlatý podporovatel
(Mas pravdu, ciste pro nahlednuti dodam:
0.1001110000111110000001111110000000011111111... urcite neobsahuje sekvenci 1234 ani sekvenci 11011 a pritom je ocividne iracionalni.) -
Ondra Satai NekolaZlatý podporovatel
To je snad videt, ne?
(Sporem: at ma periodu delky n, uvnitr je sekvence nul delky alespon n+1 a sekvence jednicek delky alespon n+1...) -
Ondra Satai NekolaZlatý podporovatel
@klokan Ted nejak nechapu, na co reagujes? Pokud to bylo na tu konstukci cisla, tak sis asi vsimnul, ze periodu nema?
-
ebik (neregistrovaný)
Tady uz hodne zalezi na definicich! Pokud to zuzime napriklad tak, ze neexistuje sekvence se zacatkem a koncem na _konecne_ pozici, tak mate pravdu. Jinak tezko rict, protoze ani neni zrejme kolik ruznych binarnich rozvoju odpovida jednomu iracionalnimu cislu (i presto, ze libovolne dlouhy konecny prefix maji tyto binarni rozvoje spolecny.)
-
Ujo (neregistrovaný)
Muzika se sice (někdy někdo možná ještě) píše na papír, ale OSA se stará o poplatky za hudební produkci, nikoliv za rozmnoženiny notových záznamů...
Jen aby nedošlo k nedorozumění, s prací OSA výrazně nesouhlasím. Stejně tak s Dilia a Integram.
Narážím na to, že i ajtak by měl mít všeobecný přehled a nekomentoval to v čem si není jistý... -
Mozna, ze OSA jde u HD o tohle: https://www.youtube.com/watch?v=G081hD0nwWE
-
Ondra Satai NekolaZlatý podporovatel
Windows users with bash.
Linux users with PowerShell.
FreeBSD users with WiFi.
It's been a crazy year.https://twitter.com/SwiftOnSecurity/status/767088302780473344
