Vlákno názorů k článku
LinkedIn přešel z CentOS na Azure Linux
od mad - " neb Azure Linux nemá grafické rozhraní" .......
-
" neb Azure Linux nemá grafické rozhraní" .... tak je to snad server, ne ?
Nedovedu si nejak predstavit, ze by se naslo pako, ktery by na serveru ve virtualizaci provozovalo "graficke rozhranni". Sice jsem to 2x zazil, ale nikdy nepochopil. Debian minimal (ssh only) z netinst nebo analogicky jine distro, a pak uz jen ty baliky, ktere opravdu potrebuju pro beh sluzby.
-
Server (ani s Windows) samozřejmě nemusí mít GUI. Ale připadá mi to jako návrat do devadesátek, kdy GUI na unixovém serveru bylo něco jako u auta dveře otevírající se ve stylu křídel: neobvyklé a nepraktické. Proč needitovat konfigurační soubory v normálním editoru? Proč nespouštět admin tools v GUI? Koukněte se třeba na Oracle DB. Instalátor má GUI (Oracle Database Setup Wizard), admin tools také (ifsca), ačkoliv Oracle Enterprise Manager už je web-based. Jistě, spousta věcí se dá udělat bez GUI, ale je to zbytečně přes ruku.
Rozumím tomu, že kdo je odkojený shellem, ten mu asi dává přednost před GUI. Nakonec proto má člověk většinou obě možnosti. -
No vidíte, pro mě je návrat do devadesátek spíš to GUI na serveru a to pracuju v desktop týmu. Přijde mi to nepraktické a neefektivní. Jak říkáte, zbytečně přes ruku. Když vidím, jakou zažívá příkazová řádka renesanci i na těch Windows a Macu, tak v tom asi nebudu sám.
BTW soubory můžu samozřejmě editovat v normálním editoru i přes ssh. Akorát na lokální mašině, která je k tomu uzpůsobená, nemusí mi ten editor běžet na vzdáleném serveru, který na to nemusí mít vůbec vhodné parametry.
29. 8. 2024, 15:30 editováno autorem komentáře
-
Jak jsem psal, každému co jeho jest. Je mi tedy není úplně jasné, jak by server mohl nemít vhodné parametry pro běh GUI. Pokud je tím serverem něco co má výkon alespoň Raspberry Pi 2.
Jistě, editor nakonec můžete běžet ve Windows, a editovaný soubor na Linuxu. Jen je to poněkud přes ruku. Mimochodem překvapivě velká spousta GUI admin nástrojů pro Windows se umí připojit ke vzdálenému stroji. Dokonce i Regedit.
-
Ano, Windowsové nástroje jsou dělané tak, aby doménoví admini mohli všechno naklikat vzdáleně... Na tom není nic nového ani překvapivého.
Linuxové nástroje jsou dělané tak, aby admini mohli všechno naskriptovat a spustit vzdáleně přes ssh.
Když se jedná o jeden stroj, tak se rozdíl moc nepozná.
Když je těch strojůale víc, tak se efektivita linuxáka hned projeví
-
Když potřebujete něco na více strojích, tak použijete třeba Group Policy. Stroje si GPO samy stáhnou a akci provedou. Spouštět něco vzdáleně je dost špatný nápad třeba u desktopů. Některé jsou zrovna vypnuté, s mnoha notebooky jsou uživatelé zrovna někde v terénu... Jinak vzdálené spouštění čehokoliv je ve Windows možné přes WMI, WinRs, PsExec, PowerShell atd.
-
Pokud to je lehká GUI administrace jako třeba Cockpit, tak je to v pohodě. Pokud se bavíme o plnohodnotném desktopu, který konkrétně po nás nemálo zákazníků na serveru chce, tak ten footprint už je celkem citelný.
Já se přes ssh připojuji na zařízení, vedle kterých je Raspberry nabušený počítač. V tom je univerzálnost ssh, že je to způsob, který funguje i na nějakém zatraceně slabém embedded zařízení a na špatném připojení. Ale ono se to hodí i v cloudu, kde platíte za použité zdroje. Když systémy spravujete jako pets a ne cattle, tak se hodí, když to můžete spravovat přes jednu nenáročnou službu a ušetříte stovky MB na desktopových komponentách. O tom, že to má menší attack surface ani nemluvě.
Bavím se ale o vzdálené obrazovce a desktopu běžícímu na serveru. Pokud má člověk nějaký administrační nástroj lokálně a ten ovládá vzdálený stroj přes nějaký úsporný protokol, je to jiný písnička.
Jinak já si na to nestěžuju. Je to práce pro náš tým. Sice pak musíme řešit desktop i na mainframech, ale okruh zákazníků, kteří používají naše komponenty je podstatně širší. Takže ať žije desktop na serverech!
-
Existuje spousta různých scénářů. Když potřebuji něco udělat řekněme na hodinkách, tak se tam připojím přes nějaký tool (dneska typicky adb.exe), a nebudu na nich pouštět desktop :). Ve firemním i domácím prostředí ten desktop ale bývá praktičtější. Za mě je to prostě náhled do systému, kde můžu mít otevřená různá okna a rozjeté různé aplikace, takže na serveru můžu dělat poměrně komplexní akce. S terminálem si připadám, jako když se dívám skrz klíčovou dírku do tmavé místnosti. Naprosto rozumím, že jiní lidé to mohou mít jinak.
Jinak stovky MB jsou dneska dost o ničem i pokud se bavíme o zařízeních, které jedou z MicroSD karty. Ohledně attack surface máte samozřejmě pravdu, ale i to se dá řešit. Shodneme se ohledně GUI nástrojů pro vzdálenou administraci. -
Tak to GUI na Windows serveru podle mne bylo proto, že to z konzole nešlo tenkrát vůbec ovládat. Měl sem na Windows serveru pár věcí. Pak vedle toho Debian. Administrovat Windows server byla bolest. Myslím že od té doby co tam je ten minimal server a slušný PowerShell, tak to je nebe a dudy. Nebo se mýlím?
Jinak mne GUI na serveru taky neuráží, v pohodě, ale když to je jediná možnost jak to dělat, tak to je blbý. -
Spousta věcí v NT šla ovládat z command line od začátku. Technicky vzato když se dá něco udělat z GUI, tak to musí jít nějak udělat i z command line. Vždyť to GUI nakonec zavolá nějaké API, udělá změnu v Registry nebo na FS, nebo použije nějakou formu IPC. Jedinou otázkou je, jestli existuje vhodný command line tool přímo ve Windows, nebo od třetí strany, nebo jestli si ho chcete udělat sám.
Jinak souhlas v tom, že PowerShell nabízí více funkcionality, než cmd.exe. On ten cmd.exe není tak hloupý, jak si někdy uživatelé unixů myslí, ale žádná velká sláva to není. PowerShell se mi líbí v tom, že umí dělat přímo s objekty. Můžu si řekněme nechat vrátit seznam běžících services, zastavit ty které začínají na T, a nastavit automatický start všem které začínají na U a jsou disabled. Přitom nejde o parsování textu. Get-Service dodá rovnou objekty, a na nich zavolám metodu. Za mě je to v podstatě jediný reálný pokrok mezi (reálně rozšířenými) shelly za posledních pár desítek let.
ČLÁNKY DO MAILU