![OpenSSH logo](https://i.iinfo.cz/images/root/426/openssh-logo.jpg)
Microsoft slíbil v roce 2015 podporu SSH. Před rokem dostaly OpenSSH Windows 10. A nyní dostává OpenSSH oficiálně i Windows Server 2019. Ve Windows Server 1709 sice OpenSSH také bylo, ale jen jako pre-release feature.
(zdroj: slashdot)
Microsoft slíbil v roce 2015 podporu SSH. Před rokem dostaly OpenSSH Windows 10. A nyní dostává OpenSSH oficiálně i Windows Server 2019. Ve Windows Server 1709 sice OpenSSH také bylo, ale jen jako pre-release feature.
(zdroj: slashdot)
Ve Windows má OpenSSH pramalý význam. Windows má svoji sadu instrumentace - tj. jak vzdáleně ovládat jiný stroj běžící s Windows. To fungovalo docela dobře už před 20 lety, pak k tomu ještě přidali PowerShell a s Windows se stal systém, který se dá vzdáleně, a hlavně i hromadně ovládat. To sice moc nezajímá jednotlivce, nebo správce pár kusů serverů, ale ve velkém je to nedostižné. Tyto technologie naopak na Linuxu a Unixech docela chybí, dohánějí se více či méně nedokonalými nástroji na vzdálený deploy - což není to samé, jako vzdálená instrumentace u Windows.
Oba systémy fungují prostě úplně jinak, ale vysmívat se, že Windows neměly SSH je docela vedle.
> Tyto technologie naopak na Linuxu a Unixech docela chybí
S Ansible nebo Puppet jste se setkal?
Asi nerozumím tomu, jak se liší přímá a skriptovatelná správa Win od použití SSH na Linuxu, případně deploy pomocí Ansible a podobných.
On je problém v tom, že stejně jako na Windows nepotřebuješ SSH, tak v Linuxu nepotřebuješ věci pro Windows. Takže tvrdit, že Win mají něco, co na Linuxu chybí, je stejné jako tvrdit, že jízdní kolo nemá motor a motorka zase šlapátka (motokola znám, ale je to nanic v obou směrech -- podstatně těžší jak kolo, takže hůře přenosné a do motorky to má taky daleko). Každé má své limity použití a naopak své výhody.
Asi nerozumím tomu, jak se liší přímá a skriptovatelná správa Win od použití SSH na Linuxu, případně deploy pomocí Ansible a podobných.
Je to pojaté úplně jinak. Na windows se nepřipojujete ke vzdálenému shellu. Přímo ovládáte jednotlivé služby, jejich nastavení. Takže z jednoho scriptu, <b>který běží u Vás</b> ovládáte zdálené stroje.
SSH oproti tomu spouští příkazy vzdáleně, i script běží vzdáleně.
V praxi je rozdíl v tom, že na windows dostáváte daleko jednodušeji a přímo do svého místního scriptu zpětnou vazbu. Jste jedním příkazem schopný poslat konfigurační pokyn pro pět serverů naráz a vyhodnotit, že byla provedena.
Deploy proti tomu má tu nevýhodu, že se vzdáleně pošle script, který se provede, ten tam něco udělá, a pak pošle zpět výsledek.
Nemyslím to jízlivě, ale podle mě by kritikové Windows měli tyto věci znát, jak fungují, protože jinak nemohou hodnotit ani vzdáleně objektivně.
> Deploy proti tomu má tu nevýhodu, že se vzdáleně pošle script, který se provede, ten tam něco udělá, a pak pošle zpět výsledek.
No a co myslíte, že dělá to slavné Windowsí RPC? Ano, pošle na vzdálený server příkaz (volání), který se provede, něco tam udělá a pak pošle zpět výsledek...
Vzdálené volání procedur (RPC) považujete za stejnou technologii jako terminálový přístup?
Podle mě terminál (SSH) je něco naprosto jiného, než RPC / WMI. Obojí se dá použít k témuž (správa vzdáleného stroje) ale obojí umí navíc každý něco jiného.
SSH je ve světě Windows poměrně nepotřebné. Někdy se hodit může, ale je to spíš okrajová záležitost.
Ale tak jak to popisuješ není rozdíl mezi Win RPC a SSH. U Win RPC přes definované API ovládáš vzdálený server pomocí definovaného síťového protokolu. Na vzdálené straně musí běžet nějaká aplikace, která přijímá, dekóduje, a vykonává povely a vrací jejich výsledek. SSH je vlastně pouze wrapper, který šifruje komunikaci mezi definovaným API (shell), které přijímá, dekóduje a vykonává povely a vrací jejich výsledek. Vzdálená strana umí ovládat jen to, k čemu má instalované moduly (například modul pro správu disků známý jako fdisk, modul pro interaktivní úpravu textových souborů VIM/emacs/nano/joe/mcedit... a mnoho dalších). V Linuxu máš navíc výhodu, že pokud Ti defaultní API nevyhovuje, můžeš použít jiné. Pokud Ti nevyhovuje daný modul, můžeš si vybrat alternativu. Navíc dané API máš dostupné nejen po síti, ale i lokálně.
Ale to pořád nemění nic na tom, že Win RPC v Linuxu neužiješ a SSH ve Win asi taky ne-e.
Na prvním místě Unixy mají trochu problém v tom, že neexistuje standardní API pro správu systému. Zkuste si například zjistit jaké máte na stroji služby (daemony), a u konkrétní služby zjistit jestli běží, nebo ji spustit, založit apod. Na konkrétním Unixu (v případě Linuxu na konkrétním distru) může initd, systemd, upstart, runit, OpenRC, Service Management Facility (Solaris), launchd (MacOS), System Resource Controller (AIX), nebo ještě něco úplně jiného. Z těch jmenovaných nejspíš jenom systemd, SMF, launchd a SRC mají vůbec nějaké API, ovšem každý jiné. Podobné je to když chcete třeba změnit IP adresu, založit uživatele nebo ho přidat do skupiny, vytvořit FS apod.
Ve Windows je primárním prostředím GUI, tzn. naprostá většina věcí musí jít z GUI nastavit. Vyjma toho se vyžaduje i možnost nastavení z command line. To znamená že Windows mají API pro správu systému, které jsou pak používány GUI nástroji (včetně modulární MMC), command line nástroji, a případně i aplikacemi třetích stran. To API bývá dostupné i vzdáleně, takže uživatel může na stanici otevřít GUI nástroj, a z něj se připojit k serveru, který chce spravovat. Správa systému ve Windows prostě není omezená jen na příkazový řádek.
Pokud vám nejde o správu nastavení systému pomocí API, samozřejmě se i ve Windows můžete připojit ke vzdálenému systému pomocí terminálu. Máte na výběr RDP (graficky - nic tak dobrého na Unixech dodnes není), telnet (s dodatečnou autentizací podle RFC2941; kupodivu dodnes podporováno jako optional feature), WinRM (to podporuje mimo jiné PowerShell), a nově i SSH.
BTW nesnažte se prosím utility vydávat za API.
No... Popravdě řečeno, nemám pocit, že by zrovna u Windows platilo, že co nějak funguje v jedné verzi, se v jiné bude chovat stejně. A to se bavíme o produktu jedné firmy a ať nežeru, vezměme to od XP k novějším (a ekvivalentní serverové edice).
Tebou zmiňované unixy jsou z poloviny v současnosti okrajové a často mrtvé věci, které byly exotické už v době vzniku před třiceti lety. Takže srovnej třeba aktuální verzi FreeDOS-u (jakožto pokračovatele MS DOS) s Win 10. Je tam trochu rozdíl? Pro různé unixy hodně aplikací stačí pouze překompilovat.
Druhá polovina má sice aktuální vývoj, ale buďto s unixem nemá vlastně mnoho společného (MacOS X), nebo je dostatečně podobně ovladatelná, že se zkušený uživatel v jednom či druhém zorientuje (Linux vs *BSD). Ale zde se stále bavíme o různých produktech, které pouze vychází ze stejné filozofie, avšak na vzájemnou kompatibilitu si nikdo ani nesnaží hrát. (Narozdíl od produktu jedné firmy v čase)
Ad RDP -- na unixu není potřeba a ve Windows je obecně považován za nejslabší prvek v zabezpečení stroje. Na unixu mám vzdálený šifrovaný shell, aplikaci pro X11 můžu pouštět vzdáleně bez celého zbytku prostředí a VNC funguje dobře. To nepočítám ty další alternativy využívající SSH tunely... Telnet -- jak je libo, já raději něco bezpečného.
A utility... Spousta utilit je pouze API pro příkazovou řádku pro volání funkcí nějaké knihovny (tak jako můžu v programu napsat #include "libopenssl.h" a využívat funkce této knihovny, tak můžu použít v jiném jazyce napsat /usr/bin/openssl ... a opět využívat nabízené f-ce té stejné knihovny).
Ale ano, *nix je taková katastrofa, že Linux je pouze druhý nejrozšířenější oprační systém (hned po Minixu) a pokud potřebuješ centrálně spravovat tisíce uzlů tak Windows jsou jediná správná volba s jejich WinRM a PowerShell (jako třeba stroje v Top 500).
Ve Windows je API velmi stabilní. Na Windows 10 můžete spustit aplikace psané pro Windows 95; na 32-bitových Win10 i aplikace psané pro Win3.1. Na Linuxu se vydávají balíčky pro každé distro zvlášť, a ještě pro každou verzi distra zvlášť.
Pokud jde o Unix jako platformu, tak ta se snaží hrát si na kompatibilitu. Od toho existuje POSIX, který popisuje požadovaná API a utility. Bohužel se celá platforma fragmentovala do té míry, že POSIX je prakticky jediné, co jednotlivé deriváty spojuje. Bohužel POSIX popisuje jenom naprosté základy (například ne X11, ne Wayland, ne API ke správě systému atd.), a Linux nedodržuje ani ty. Ano, nedodržování standardů - ta věc, kterou linuxová komunita tak ráda vyčítá třeba Microsoftu :)
A bohužel v rámci Linuxu ta fragmentace není o nic lepší. Pěkná byla snaha o sjednocení dister ve formě Linux Standard Base, dokonce z LSB stal ISO standard (ISO/IEC 23360). Bohužel počet LSB-certified dister postupně klesl na nulu, a LSB verze 5.0 "rafinovaně" bourá zpětnou kompatibilitu. Takže Unixy si sice na kompatibilitu hrají, ale ve skutečnosti je velmi omezená. To že se zkušený uživatel v jiném Unixu za použití dotazů na Googlu ;) nakonec nějak zorientuje je sice pěkné, ale celkem nedostatečné.
Na Linuxu nepotřebujete vzdálený přístup v grafice? To myslíte vážně? :) X11 je, jak jsem už psal, naprostá technická i bezpečnostní katastrofa, která má navíc jako jednu z "features" je to že když odpojíte session, tak se k ní nelze znovu připojit. Na vzdálenou správu zcela nevhodné. VNC je pustý screen grabber, který prostě posílá bitmapy na druhou stranu. Ve srovnání s RDP, které přenáší informace o tom, jak obraz sestavit na druhém konci drátu (obdélník s výplní, v něm text), je to nesmírně primitivní a neefektivní technologie. No a pak je tu Wayland, který vzdálený přístup neřeší pro jistotu vůbec. Ale prý je to v principu možné řešit, a výsledek bude nepříjemně podobný tomu VNC :/
Mimochodem u RDP vás nikdo nenutí pouštět si celé prostředí, klidně si můžete pustit jen vybranou aplikaci.
Vážně jste napsal "API pro příkazovou řádku"? :) API je určené pro vývoj aplikací, jak plyne i z názvu (application programming interface). Příkazová řádka je primárně textový uživatelský interface, a utility jsou prostředky, kterými uživatel tu interakci vede. Sekundární použití utilit je ve skriptech, což je v podstatě soupis příkazů, které by uživatel provedl interaktivně na příkazovém řádku. Zkusme tedy nezaměňovat dvě dost odlišné věci.
Linux je zdarma, a pochopitelně se hodně používá v prostředí, kde na ceně velmi záleží. To je například internetová infrastruktura, nebo tisíce hloupých nodů, které musí umět akorát stáhnout si job, spustit proces, a pak uploadovat výsledek jobu. V korporátním světě je ale situace poněkud odlišná.
"V korporátním světě je ale situace poněkud odlišná."
Povídejte, přehánějte :) Já jsem nedávno viděl čísla Gartneru z trhu placených serverových OS a Linux byl celkově na nějakých 50 %, Windows Server na 45 % a zbytek byly Unixy. A trend byl docela jasný: Linux dál roste, teď už ne na úkor Unixů, ale Windows.
Přijde mi, že dnes se Windows Server drží hlavně v segmentu malých a středních podniků kvůli zavedeným podnikovým aplikacím a protože tam prostě mají historicky Windows adminy. Už jsem ale dlouho od někoho neslyšel: "Rozjíždíme novou firmu nebo začínáme projekt na zelené louce a stavíme to na Windows Server".
Tady zopakuji co jsem už psal. Predikce budoucnosti jsou ošidné.
https://www.linux.com/news/global-it-firm-predicts-linux-will-have-20-desktop-market-share-2008
https://www.root.cz/zpravicky/analyza-gartner-windows-se-pomalu-hrouti/
Kdo dneska rozjíždí novou firmu, většinou použije cloudovou infrastrukturu, a k tomu desktopy na Windows. Úplně se nabízí cloudový OneDrive, Office Web Apps, Exchange, SharePoint atd., doplněný desktopy s Windows a MS Office. Osobně bych do takového řešení nešel z důvodu důvěrnosti dat. Ale malé firmě to umožňuje pořídit infrastrukturu na pár kliknutí, a k tomu si na dalších pár kliknutí přikoupit CRM, HR management, ERP, nebo v podstatě cokoliv dalšího. Bez nutnosti investice do vlastních serverů, a bez nutnosti najímat hromady geeků s dredy, aby všechna ta tamagochi opečovávali.
Navíc mi - snad vyjma ceny a případně unixové kultury v nějaké firmě - uniká jediný důvod, proč by někdo stavěl prostředí na Linuxu. Vždyť je to technologicky krok o pár desítek let zpátky, a vývoj i deployment aplikací pro Linux je z mnoha hledisek noční můrou.
Ale já se tady nebavím o desktopu, ale u serverovém segmentu. Samozřejmě souhlas, že pro menší firmu nemá dneska moc smysl si provozovat vlastní infrastrukturu a je lepší využít cloud, ale na čem ty cloudové služby dneska běží? Počítám, že Microsoft má své cloudové služby i nadále na Windows, ale co ten zbytek? Google, Amazon, Dropbox, SalesForce atd. atd. jedou prakticky výhradně na Linuxu. Stejně tak opravdu nenarážím na case studies internetových startupů, které s nějakou takovou službou začínají a staví ji na Windows Server. Nakonec i na tom Azure je dnes víc linuxových instancí než těch s Windows a ty nůžky se rozevírají, protože podíl Windows tam drží tradiční zákazníci Microsoftu, kteří tam přesouvají věci z vlastní infrastruktury a to má logicky omezený potenciál růstu.
Ano, řeč je o serverech. Desktopy jsem zmiňoval v tom kontextu, že pomáhají prodávat cloud. To bude zřejmě jeden z důvodů, proč Azure roste nejrychleji.
Cloudové služby běží na všem možném. Na Windows běží své hosty nejen Microsoft, ale také řada jeho partnerů. Předpokládám že znáte třeba německý TelekomCLOUD, který jede na technologiích MS Azure. Takových je veliká spousta. AWS, Google a někteří další předpokládám jedou hosty na Linuxu. Další věc je na čem jedou guesti. V Azure je cca půlka strojů na Windows, půlka na Linuxu. U AWS nevím, ale loni podle IDC běželo 57% z instancí Windows ve veřejných cloudech na AWS, takže tam jistě mají velké zastoupení Windows.
Jenže to pořád mluvíme v podstatě o internetu. Velká část IT je za firewallem ve firemních serverovnách. A tam najdete Linuxu výrazně méně.
Mimochodem to nejsou predikce budoucnosti, ale trend posledních let. Je to pár let nazpátek, kdy měly Windows Server na trhu přes 60 % a Linux pod 30 %. Jen abyste s nimi časem nedopadl jako fanoušci komerčních Unixů, já si taky pamatuji, jak se před 10-15 lety na fórech chlubili, jak má třeba takový Solaris pokročilé technologie oproti Linuxu. A do určité míry to byla pravda. Ale trh rozhodl jinak a kde je dnes Solaris...
Mohl bych požádat o zdroj těch čísel? Rád se kouknu na trendy.
Souhlas že Solaris je - nebo alespoň před pár lety byl - technicky daleko vyspělejší než Linux.
Ale když jsme u toho. Co je podle vás motivem pro použití Linuxu? Vyjma ceny (pak z toho ovšem vy jako Red Hat nic nemáte) a unixové tradice mě nic nenapadá. To že je systém koncepčně někdy ze začátku sedmdesátých let, jeho vývoj prakticky ustal koncem osmdesátých let (například X11 je z roku 1983), a vývoj aplikací musí být noční můrou i pro masochisty, je podle mě spíš motivace se Linuxu vyhnout.
Jsou to data z neveřejných zpráv Gartneru, které máme ve firmě k dispozici a jak se dívám, tak Gartner je dává k dispozici jen za částky v tisícovkách dolarů. Odkaz vám tedy poskytnout nemůžu, takže mi můžete, ale nemusíte věřit.
Jinak proč je Linux atraktivní pro zákazníky, je zase na delší vyprávění a na to teď bohužel nemám čas. Díky za docela konstruktivní diskusi.
Opět porovnáváte neporovnatelné co se týče přístupu systémů. Jak to, že tedy stále existují a poůžívají se v Linuxu i 20 let staré aplikace? A dokonce nyní běží jako 64bit?
Pouštění grafických aplikací používám celkem často a to používám výhradně Linux. Zatím mi nikdo neukradl z počítačů nic a to to tak provozuji již cca 20 let. Veškerý provoz totiž balím do SSH tunelu. (Zde dlužno podotknout, že se to v poslední době dost omezuje na webový prohlížeč na hranici jinak nepřístupné sítě pro přístup přímo do ní. To se dá často obejít použitím SSH tunelu a proxy, ale občas jsem příliš pohodlný.) Asi jsem v tomto dost specifický případ, ale grafické prostředí mám kvůli webu (pro složitost a komplexnost již nelze efektivně využívat textové browsery) a částečně kvůli multimédiím. Jinak si vystačím s terminálem a jsem spokojený. Asi jsem jeden z mála, kdo stále používá textové konzole, ne grafické emulátory terminálu. Takže ano, na Linuxu se obejdu bez vzdáleného přístupu ke grafice. Navíc jsem nepsal, že se bez toho obejdu, jen jsem psal, že cesty jsou jiné. Ty jsi napsal, že X11 je katastrofa, tudíž nic není a grafický vzdálený přístup nepotřebuji. Jo, a kromě VNC tu je ještě SPICE.
A ano, napsal jsem API pro příkazovou řádku. Napsal jsem to tak schválně. V příkazové řádce pouštíte co? Shell. Co je shell? Programovací jazyk. Jake má vlastnosti? Je to intepretovaný jazyk, co umožňuje interaktivní zpracování kódu. Když si takhle pustím python v příkazové řádce a pustím funkci z openssl knihovny, tak už nepoužiji API pro openssl knihovnu? Primárně mi tu šlo o jistou abstrakci v myšlení. Shell je pouze nějaký interpret jazyka, který se snadno používá v interaktivním režimu. To je vše. Pokud v něm píši aplikaci, tak používám doporučované struktury pro napojení na existující knihovny. To může bý správně oparametrizovaná binárka. Pokud v tom nevidíš analogii, tak nevím...
Ony se na Linux dají reálně provozovat 20 let staré aplikace? A nějakým zázrakem se překlopily z 32-bitových na 64-bitové? O tom se rád dozvím více. Pokud mi tedy nechcete říct, že se ty aplikace průběžně udržují, rekompilují a balí pro každou verzi každého distra, nebo že jsou staticky kompilované.
Chápu že jste ze staré školy, a vystačíte převážně s textovým prostředím. Osobně používám primárně GUI, ale celkem často i command line (cmd.exe a PowerShell). Bez GUI se jistě dá pracovat, ale je to v řadě případů daleko méně efektivní, plus je to daleko náročnější na učení. Vezměte kolik úsilí jste musel na začátku strávit tím že jste se učil vi/vim, oproti tomu kolik úsilí stojí naučit se s textovým editorem v GUI.
Jistě, chápu jakou paralelu se snažíte naznačit. Jenže shell je prostředí, interface - nikoliv programovací jazyk. Jednou z funkcí textového shellu může (a nemusí) být vyjma zpracování interaktivně zapsaný příkazů také zpracování příkazů zapsaných ve skriptu. Hodinky a holínky mají společné to že se oboje natahuje, ale přesto se jedná o dvě výrazně odlišné věci :)
Ano, takže místo toho, aby byla služba jednoduchá a napsatelná v libovolném skriptovacím jazyku, tak musí implementovat speciální rozhraní pro služby atd....
Ve výsledku to nevede k snáze spravovatelnému serveru, ale daleko hůře spravovatelnému serveru, protože můžete ovládat jen to, k čemu někdo napsal ovládací rozhraní, což je ve výsledku minimum věcí.
Zatímco v linuxu - kde máte přístup přes univerzální shell - uděláte vzdáleně cokoli.
Pokud chci od serveru přes ssh zpětnou vazbu, není to problém dopsat. Pokud chci od WS univerzální shell..... musím implementovat ssh :-) A to se vyplatí.
Myslite RPC? Pred par lety (v dobach Win7) jsme to zkusili na ovladani stoje, ktery slouzil na automaticke testy od instalace az po API naseho SW. Nasledovalo asi pulrocni hledani proc to nekdy funguje a nekdy nefunguje a nakonec se ukazalo, ze to zpusobuje prave nespolehlive RPC (stroj prestal bez zjevne priciny na RPC reagovat, pokazde jindy a jinak). Nakonec jsme skoncili u OpenSSH
Ten nas RPC problem nemel zadnou souvislost s dobou od rebootu. Ten testovaci stroj, na kterem se to spoustelo byl stale stejny virtual, na ktery se pomoci scriptu postupne naistaloval SW stejnym instalatorem jako to dela uzivatel/spravce a pak se testovalo vse od API az po klikani a jine uzivatelske vstupy. Cele to trvalo asi 3-4 hodiny. A to ukolem vzdaleneho volani nebylo delat samotne testy, ale pouze spustit test a vytahnout vysledny report. Desitky volani celkem.
Windows používají pro vzdálenou správu většinou RPC, ale ne nutně.
Chápu že jste u vás měli nějaký problém s aplikací založenou na RPC. Ono Win32 API pro RPC je poměrně rozsáhlé, má skoro 200 funkcí, a je určené pro C/C++. Psát cokoliv za pomoci RPC je poměrně náročná záležitost, a kdo s tím nemá zkušenosti, ten udělá lépe když použije nějaký wrapper, nebo rovnou jinou formu IPC.
Není mi ale jasné, co to má společného s diskutovanou tématikou. Je to jako kdybyste to diskuse o TCP psal "jako po ethernetu? to moc nefunguje, měl jsem problém na své televizi přehrávat soubory z počítače přes ethernet, náhodně to přestávalo fungovat, tak jsem nakonec skončil u HDMI kabelu". Jako pěkné, jistě to mohlo mít spoustu zajímavých příčin, ale co to má s společného s tématem?
Zkousel jsi nekdy na windows neco tak obycejneho a jednoducheho jako naklonovat git repo (a tim nemyslim pres https)? Takze ano, je trefne se vysmivat widlim, ze nemeli neco tak zakladniho jako je ssh, aby z nich clovek mohl normalne spolupracovat s beznymi servery. To jak vidim nektere "spravce" na win jak patlaji veci pres rdp a klikani... hanba systemu ktery to umoznuje.
On je snad problém si během minuty táhnout SSH klienta?
Windows mají jako primární interface GUI, takže je RDP celkem praktická záležitost. Rozdíl je v tom, že ve Windows můžete vzdálený stroj spravovat pomocí lokální GUI aplikace, pomocí vzdáleného UI (RDP), i pomocí command line. Na Unixech vám nezbývá než použít tu command line (ssh), protože nic jiného není k dispozici.
Unixy totiž mohou takové RDP leda závidět. Mají X11, což je naprostá technická i bezpečnostní katastrofa, která má navíc jako jednu z "features" je to že když odpojíte session, tak se k ní nelze znovu připojit. Myslím že je to zbytečně konfrontační, ale že jste to vy, vypůjčím si váš slovník: hanba systému, který takovou příšernost používá.
Cockpit je neco jako jina varianta MobaXtermu s nekteryma odlisnymi funkcemi. Navic, jde vubec s ssh neco takoveho, jako jen navazani spojeni, delani nejakych operaci mimo to spojeni a pak po tom spojeni poslat nejaka data? Podobne, jako se chova napr. skript webove aplikace, kde se generuje zdrojak a kdyz je potreba, tak se poslou data do db spojeni, cili kvuli kazdemu poslani dat neni treba navazovat nove spojeni.
No, nevím, jestli to je něco jako jiná varianta MobaXtermu. Nepotřebuje ke svému běhu ani X ani ssh (to je tam jenom od toho, aby si do správy daného serveru mohl přidat další). Je to prostě webové UI postavené na již existujícími API systémových služeb, ke kterému se člověk vzdáleně připojuje přes https.
Jaké "existující API systémových služeb" máte na mysli? Shell out? To snad ne :/
Pokud jsem si správně všimnul, tak Cockpit je webová aplikace, která nabízí nějaké GUI pro správu systému, a na pozadí spouští shell a provádí v něm příkazy. Navíc to není nic univerzálně unixového. Je to specifický kus SW pro Linux, a ještě s hacky pro každé podporované distro (a jednotlivé verze těch dister). Je to v názorná ukázka, jak je API pro správu systému na Unixech neřešené, a musí se obcházet pro každý konkrétní Unix, v případě Linuxu pro každé distro a jeho verzi, pomocí spouštění shellu a utilit.
Pro ilustraci: když ve Windows potřebujete přidat uživatelský účet, zavoláte API NetUserAdd. Pokud chcete uživateli změnit heslo, zavoláte API NetUserChangePassword. Když chcete spravovat síťová rozhraní, použijete IP Helper API. Atd., atd. Na Unixech zakládáte uživatele tak, že spustíte shell (bash nebo jiný) a necháte mu provést nějaký skript (useradd, adduser nebo něco jiného - POSIX totiž ani tohle nepředepisuje). Změna hesla je stejný příběh (passwd, chpasswd, pwdadm apod.). A správa síťových rozhraní se realizuje tak že spustíte nějakou utilitu a nakrmíte jí nějakým vstupem, podle toho na jakém Unixu zrovna jste; případně editací konfiguráků, které se opět na různých Unixech liší.
Připadá vám ta situace na Unixech konzistentní a dobrá?
Já jsem rozporoval tvrzení, že není k dispozici žádné GUI, vy to zase stáčíte na něco jiného. Jinak mi popravdě nepřijde příliš fér porovnávat konzitenci v rámci široké rodiny systémů (Unixy a Unix-like) a jednoho konkrétního systému Windows. I kdyby ta přítomnost a konzistence API byla u Windows nakrásně lepší, tak to zjevně nemá takový půvab, když Linux (o Unixech už to dneska moc není) čím dál víc dominuje většinu segmentů serverového trhu.
"I kdyby ta přítomnost a konzistence API byla u Windows nakrásně lepší, tak to zjevně nemá takový půvab, když Linux (o Unixech už to dneska moc není) čím dál víc dominuje většinu segmentů serverového trhu."
Takovy roztomily osli mustek... To uz se Linuxaci na nic jineho opravdu nezmuzou?
Ona ta odpověď relevantní je. Lael přišel s pseudoproblémem a ještě si vmýšlí. Ke spuštění jiného procesu není třeba pouštět shell a volání příkazové řádky v principu není o nic horší než volání API funkce z DLL. Linuxové servery tím pádem nemají problém, o kterém píše Lael a widlí řešení, ač v něčem možná elegantní, ten zbytek ekosystému skoro nikomu neprodá.
Ke spuštění jiného executable není nutně potřeba spouštět shell, pokud ten executable není shell script. A například init skripty jsou... skripty.
Volání příkazové řádky je v principu mnohem horší, než volání API funkce z DLL. Dochází vám, že volání funkce API znamená naplnění registrů a provedení jednoho callu, kdežto při volání příkazové řádky musíte serializovat parametry, vytvořit nový proces, nechat ho provést inicializaci, deserializovat parametry, zavolat tu funkci API, serializovat výsledek, ukončit proces a uvolnit zdroje, a pak volající pak musí deserializovat výsledek? Jestli vám to nepřijde o nic horší, tak to doveďte do důsledku. Jak by to asi vypadalo, kdybyste spouštěl příkaz pro vykreslení každého jednoho písmene na obrazovce? :)
To nemluvě o tom, že klasická unixová sekvence fork/exec je mimořádně drsná. Když máte DB server, který má alokováno 100GB RAM, a provede fork/exec aby zavolal utilitu, tak na to potřebuje dalších 100GB RAM. Tohle naštěstí po pár desítkách let začal řešit posix_spawn(), pokud ho tedy aplikace použije.
Linuxové systémy mají problémy, o kterých jsem psal. Akorát jste na ty problémy zvyklí. Navíc adminy nemusí zrovna dvakrát trápit jestli existuje nějaké API, protože s ním stejně nikdy nepřijdou do styku.
Otázkou zůstává, co je větší oslí můstek. Zda nejednotnost Unix/Linux API pro správu, nebo to, že Windows postupně hází ručník do ringu a zakrývám to argumentací jednoduché správy.
V uzavřeném světě je jednoduché být konzistentní, když se omezím na jedinou distribuci, taky si ji budu jednoduše spravovat. A to zmiňované WIndows API jako ukázka přehlednosti? Stovky volání, na tu samou věc pokaždé minimálně ve třech variantách, většinou pak ještě v extended verzi. U 90 % z toho nikdo pořádně neví, jak nyní funguje a jaké má vedlejší efekty, bugy se staly součástí dokumentace jako feature. Většina služeb velmi špatně škáluje, takže když přerostou nízké desítky, tak začínají problémy. Děkuji, nechci.
Není mi jasné, co myslíte tím "Windows postupně hází ručník do ringu a zakrývám to argumentací jednoduché správy". Mohl byste to trochu rozvést?
Co podle vás technicky brání tomu, aby se Unix jako platforma rozšířil o API pro správu systému, zobrazování, multimédia atd.? Technicky nic. Politicky tomu brání to, že se vývoj Unixů prakticky zastavil někdy koncem 80. let minulého století. Přišly nějaké novoty z různých stran, a celkem dost z strany Linuxu. Jenže Linux je bazaar, a kde jsou dva autoři open source kódu, tam jsou i minimálně tři podobné, ale dostatečně různé řešení každého problému :/. Qt vs GTK vs wxWidgets vs Tk, a spousta dalších. Open Sound System vs Advanced Linux Sound Architecture vs PulseAudio. Initd vs systemd vs upstart vs runit vs OpenRC. A pokusy se na něčem dohodnout alespoň na úrovni Linuxu? Linux Sandard Base vyšla i jako ISO standard, ale počet certifikovaných dister postupně klesl na nulu.
Windows API není dokonalé, ale je velmi široké. Ano, některé funkce mají více verzí, protože se postupně přidávají funkce. To pak můžete mít třeba GetDiskFreeSpace() a GetDiskFreeSpaceEx(), CopyFile() a CopyFile2() apod. Díky tomu mohou staré aplikace dál fungovat beze změny, takže ve Windows 10 fungují (správně napsané) aplikace psané pro Windows 95.
Pokud jsme u toho jak API funguje, tak Windows mají dokumentaci. A to dost možná nejlepší v dokumentaci v oboru. Pokud něco v dokumentaci není popsané, tak na to autor aplikace nemůže a nesmí spoléhat, protože spoléhat na nedokumentované chování je prasárna, která se dříve či později vymstí.
Co máte na mysli tím "většina služeb velmi špatně škáluje, takže když přerostou nízké desítky, tak začínají problémy"? Jakých služeb, desítky čeho?
Ta konzistence je jednoznačnou výhodou. Snaží se o ni jak POSIX, jenže toho většinu nepopisuje. Snaží se o ní Linux Standard Base, ze které se stal i ISO standard, ale bohužel počet certifikovaných dister časem klesl na nulu.
Technicky není problém mít definované daleko širší sdílené API než to co nabízí POSIX. Problém je to finančně a politicky.
Chápu že jako zaměstnanec Red Hatu máte nějaký názor na budoucnost Linuxu. Rád bych tedy připomněl jen dvě předpovědi. Z toho by snad mělo být jasné, že s budoucností to není tak jednoduché :)
https://www.linux.com/news/global-it-firm-predicts-linux-will-have-20-desktop-market-share-2008
https://www.root.cz/zpravicky/analyza-gartner-windows-se-pomalu-hrouti/
bába povídala, že microsoft už nebaví ty widle řešit (klesají jim z nich zisky, ale podpora je čím dál náročnější), troufám si tvrdit, že jednoho dne se probudíme, a microsoft oznámí, že stejně jako u prohlížeče edge se jim vyplatilo zahodit své řešení a použít opensource, tak zahodí svůj kernel a postaví vlastní linuxovou distribuci...android jim vydělává skrz výpalné na "patentech", což je taky jen linux + bordel nad tím a dokážu si představit že si to své ošklivé win10 naskinují na linuxu - bude to vypadat stejně, bude to mít nainstalované nesmysly a šmíráky, ale podvozek bude opensource - vývoj tomu nasvědčuje