15 TeamViewer alternatíva, a legjobb Remote Desktop alkalmazások

Web, mail, IRC, IM, hálózatok

15 Best TeamViewer Alternatives: Best Remote Desktop Software

A DWService nyílt forráskódú szoftver és már majdnem olyan jó mint a Chrome Remote Desktop, ami pedig már le is hagyta a Teamviewert minőségben. 

  • 6814 megtekintés

( uid_16401 | 2022. 02. 06., v – 01:33 )

Ok, és van kérdés? Vagy ez csak egy feljegyzés?

Hiányoltam a jó opensource alternatívákat. Itt van egy jó opensource remotedesktop, DWService. A többi alternatíva között is vannak jó megoldások. Jól összegyűjtötte ez a blog, megosztottam. Ha valaki szerint lenne még mivel bővíteni a listát, írja meg hsz-ban.

Most lehet, hogy én értelmeztem félre, de DWService-hez regisztrálni kell a weblapjukon. Innentől nem látom alternatívának a teamviewerhez vagy anydeskhez képest, amit feldobok (utóbbit telepíteni sem feltétlen kell) és már működik is.

üdv: pomm

A 852-es kídlap telepötúsa sikeresen befejezádétt

Nem kell regisztrálni a DWService-t. https://www.dwservice.net/session.dw# itt be tudsz lépni a server oldalon adott azonosítóval és jelszóval. 

Teamviewer az utóbbi időben nagyon hamar "valószínűsíti a kereskedelmi felhasználást" innentől lényegében használhatatlan ha nem leszel az előfizetőjük. (10 percekre kirak egyébként) 

Nagyon ritkán, de használok még TV-t, van egy regisztrált fiókom és ahhoz tartozó, 5 gépes listám. Soha nem fizetem nekik, és ennyi pénzt, ilyen konstrukcióban soha nem is fogok, de eddig még bármeddig engedtek dolgozni.

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Amint az egyetemi ip címekről kezdtem bejelentkezni az otthoni két pc-mre nagyon hamar jöttek az előfizetést követelő üzenetek és tíz perces tiltások. Talán nagycéges ip tartománynak nézik a magyar egyetemi címeket a teamviewernél, talán csak véletlen egybeesés volt. Akkor váltottam chrome remote desktopra, ami meglepően jól működött, sőt felhasználói élményben már akkor verte a teamviewert. De már akkor szükségét éreztem opensource alternatíva keresésének. 

A Remmina is FOSS, én csak azt ismerem, meg az xfreerdp-t. Plusz Windowsról a Logmein-t meg a Teamviewer-t. Illetve hallottam róla, hogy a Chrome meg valamelyik Electron alapú csevegőapp (Zoom, Teams, Skype vagy melyik, elfelejtettem) tud asztalt megosztani, azokat még nem próbáltam. Ez a Guacamole szimpatikusnak hangzik. Fizetőst én se tennék fel Linuxra meg BSD-re, hiszen azoknak a lényege, hogy minden opensource legyen rajtuk, együtt legyen fejlesztve az ökoszisztémával, haladjon a verziókkal, hozzá legyen fordítva az adott disztróhoz. Zárt forráskóddal csak a baj van, állandóan tartani kell vele visszafelé kompatibilitást, hogy el ne törjön, ez feleslegesen bonyolítja a kódokat, plusz általában valami DRM-et is beletesznek kalózkodást megelőzendő, azt meg extra frusztráció. Nem az a baj, hogy pénzt kellene érte adni, mert pár dollárt itt-ott kibírna az ember, nem arról van szó, de a zárt forráskód emiatt ingyenes programnál is rettenet zavaró.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

( zitev v | 2022. 02. 06., v – 11:05 )

A vnc tud már hangatvitelt?

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

( khiraly | 2022. 02. 06., v – 15:51 )

Enyhen offtopik, de Telegrammal nyomultam multkor. Meg lehet osztani a kepernyot, es sajnos a masik fel kell hozza,

akinek elmondod, hogy mit csinaljon.

De megmarad a hang kontaktus vegig. Nem idealis, de ha van mar telegram telepitve, akkor lehet, hogy jo vegszuksegben.

 

Egyebkent ha technikai segitseget nyujtasz a tuloldalon, akkor *mindig* kell az aktiv jelenlet, az elso drivertelepites, ujrainditas, kijelentkezes-visszajelentkezes, es maris lottek a remote desktop kapcsolatnak.

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Ha már offtopic. Remote desktopre valóban nem túl jó így, de prezentációs meetingekre érdekes alternatíva. Olyat tud a Telegram, hogy mindig a beszélő videóképét maxolja a többieknek automatikusan? A Teams ezt pont nem tudja, de desktopot elég jól oszt meg, bár audiot onnan nem tud, pedig nem ártana. Így a másik kérdés, a Telegram hangot is tud a távolról megosztott asztalról? Azaz ha például távoli asztalon megy egy videó van hangja is? 

Eleg sok esetben valamilyen halozati problema miatt hivnak. Elobb-utobb kell valaki a masik vegere.

 

Az automatikus indulasnal gondolom ugy van, hogy login utan (amit a felhasznalo potyog be) automatan ott van a hatterben. De ha akkor kapcsolod be a gepet, akkor nem indul el magatol, nem?

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Teamviewer-nél biztosan nem igy van, az service-ként települ, nemhogy loginkor, de már azelőtt éled a kapcsolat, a kis türelmet frissitéseket telepit szöveget is látni ilyenkor. Tehát semmilyen user nem kell a túloldalra.

Hálózati problémán meg nem segit semelyik távelérés. (teamviewer annyit segit, hogy dns nélkül is feléled a kapcsolat, mert bepróbálkozik ismert teamviewer ip-ken dns nélkül is)

 

Fő szálhoz:

A chrome remote desktop nem tudom hogy jön ide, mikor utoljára néztem adott google fiókkal kell belépni minden oldalon, az meg nonsense support célra.

VNC, RDP és hasonlók meg szintén noway, hiszen port forwardot vagy vpn-t igényelnek, arra egy egyszeri user képtelen és hülyeség is, csak azért, hogy valaki segitsen egy kicsit.

Ellenben a W10-be integrált Quick assist már értelmesebb dolog, az valóban használható supportra, de az meg nincs is a listán.

"A chrome remote desktop nem tudom hogy jön ide, mikor utoljára néztem adott google fiókkal kell belépni minden oldalon, az meg nonsense support célra."

Chrome remote desktop úgy jön ide, hogy saját erős pc távoli elérésére ideális. Illetve modern kori X-terminal - X-kiszolgáló használatra is jó, erről írtam másik hsz-ban. Egyébként nem kell azonos google fiók a két oldalon. Hasonló módon lehet távoli segítséget kérni vele mint Teamviewerrel. Azaz azonosítószámsor, plusz egyszeri-jelszó. A Google accounthoz kötött belépés akkor jön jól ha senki nem ül ott a másik oldalon de ez általában nem support szituáció. Ilyen esetben jól jön a google accountal együtt járó 2 faktoros azonosítás ha a biztonság is számít. Mindehhez havidíjas google account sem kell. Mivel szolgáltatásként indul frissítés utáni reboot után nem okoz problémát a login képernyő sem a chrome remote dekstopnak mert már ott is működik is elérhető. 

(Egyébként egy szót nem írtam arról, hogy ez support célra kell) 

Saját pc-nél nálam csak rdp jöhet szóba, messze a legjobb sebességben és tudásban, de ismeretlen userek felé az nem jó.

Azt viszont nem tudtam, hogy chrome remote desktop tud egyedi ugrókódot generálni.

Nálam mondjuk több usernél van az, hogy állandó hozzáférésem van a gépükhöz, nem kell kódot diktáljanak, szólnak kettőt kattintok a listában és rajta vagyok, igy a chrome nálam nem opció.

A chrome remote desktop nem tudom hogy jön ide, mikor utoljára néztem adott google fiókkal kell belépni minden oldalon, az meg nonsense support célra.

Egyfelől van benne olyan üzemmód, amikor csak egyszer használatos kódot kérünk, és azzal lépünk be. Ebben az esetben semmilyen megkötés nincs arra, hogy kinek kell bejelentkeznie. ( https://remotedesktop.google.com/support )

A másik lehetőség, hogy a kezelni kívánt gépeken a headless változatot telepítjük. Ilyenkor csak azon a gépen kell bejelentkezni, ahonnan a többi gépet irányítani szeretnénk, a többi gépen csak az egyszeri beállítást kell elvégezni. (egy MSI csomag telepítése, majd egy parancs végrehajtása, és a PIN kód megadása). 
https://remotedesktop.google.com/headless (ez MAC-en nem működik)

Eddigi tapasztalatom alapján elég megbízhatóan működik.

Nagy Péter

Az automatikus indulasnal gondolom ugy van, hogy login utan (amit a felhasznalo potyog be) automatan ott van a hatterben. De ha akkor kapcsolod be a gepet, akkor nem indul el magatol, nem?

UltraViewer-nél ez beállítás kérdése. Ha rendszergazdaként indítva egyszer beállítod, hogy Induljon a windowssal, és a beállítások -> Security lapján az "UltraViewer on Winlogon screen" menüben az Allwayst választod, akkor reboot után is fel tudsz csatlakozni, és be tudsz jelentkezni.

AnyDesket én nem használok, de ismerősömnél tudom, hogy megy ugyanígy a reboot utáni login, valószínűleg maximum valami beállítást kell bejelölni hozzá.

Nagy Péter

Apache Guacamole inkább a viewer kliens funkciókat teszi át böngészőbe ha szerver oldalon telepíted. De a régi távoli asztalos technológiákat, VNC és RDP -t használ. A teamviewerrel hozott újítás lényege röviden:

1. video codec használata a távoli asztal továbbításához

2. audio automatikus kezelése a desktop képpel szinkronban

(3). A távoli egér eltüntetése a user számára, helyette csak a lokális egérmutató mutatása és minden mozdulatának megjegyzésé és továbbítása. Ezért gyengébb internetek kapcsolat mellett is reszponzívabbnak tűnik a távoli asztal pedig nem az. (Régen: húzza a user az egeret és alig követi a távoli asztalon a mutató, neki meg szétrobban a feje. Új megoldásnál: az egér szépen mozog, kattint a user a távoli asztalon valamire de jó sokáig nem történik semmi csak egy idő után. Ez is zavaró de hát "lassú a rendszer" élményt már elfogadta, így türelmesen várja a választ. Egyből jobb a user experience) Nem mindegyik modern remote desktop tudja, a tw-nél emlékeim szerint ez kapcsolható képesség volt. 

A video codec használatát nem értem. Ez inkább hátránynak tűnik, mint előnynek. A xfreerdp meg nagyjából mindent tud, ami RDP-ben elképzelhető.

A hangot sem értem. Minek hang RDP-hez? Elvi jelentősége lehet. De gyakorlatilag a hangot mindenki a saját gépén kezeli és ha mindenképpen hang kell a távoli asztalhoz, ott van az egyébként fóniára használt alkalmazás (Skype, Teams, Zoom, Jitsy stb.) mindenkinek. Ezeket nem váltja ki a teamviewer.

A Guacamole webes felületen viewerként is és RDP célra is megfelel, ingyenes (a teamviewer úgy emlékszem nem az), a sávszélesség igénye kicsit nagyobbnak tűnik (talán a html5 miatt) mint a sima xfreerdp-é de ez nem tűnik jelentős hátránynak (vagy nem tudom megállapítani, hogy hátrány-e mert még sose tapasztaltam vele olyan problémát, mint írsz az egérrel - VNC-vel igen, ott rendszeresen előfordul ilyesmi).

És még egy apróság: a teamviewer egy idegen szerveren keresztül megy, ennél az xfreerdp egy fokkal jobb, mert saját VPN kell hozzá, a Guacamole-hez meg nem kell semmi csak egy böngésző. A teamviewer NOGO.

"A video codec használatát nem értem. Ez inkább hátránynak tűnik, mint előnynek."

Pedig komoly előny. Minőségi váltás ami érezhető is. Ha nem lokális neten van a távoli desktop és nincs gigabit közöttetek akkor egyáltalán nem mindegy, hogy például Chrome remote desktop vagy valami RDP kapcsolatod van. Chrome remote desktopon mintha ott ülnél az előtt a gép előtt. Akár videót is nézhetsz rajta. RDP-nél errről szó sincs. Mire jó az extra? Például nem szeretem a gamer notebookokat de szükségem van erős hardverre. Egy asztali PC az erős hardver amit úgy használhatok mint x-terminálról a "nagy" unix szervert a régi világban. 

"A Guacamole webes felületen viewerként is és RDP célra is megfelel, ingyenes (a teamviewer úgy emlékszem nem az), a sávszélesség igénye kicsit nagyobbnak tűnik (talán a html5 miatt) mint a sima xfreerdp-é"

A html5 kliens miatt szerintem nem lesz nagyobb a sávszélességigénye, talán az hardverigénye valamivel. A képenként átvitt desktop sávszélességigénye már sokkal nagyobb mint a Teamviewer x264 codeces képátvitele. A Chrome remote desktop pedig a teamviewert is veri VP9 codec jobb hatékonysága miatt. 

"És még egy apróság: a teamviewer egy idegen szerveren keresztül megy, ennél az xfreerdp egy fokkal jobb, mert saját VPN kell hozzá, a Guacamole-hez meg nem kell semmi csak egy böngésző."

VPN-nel a teamviewer sem megy át idegen szerveren szerintem. Chrome remote desktop pedig biztosan nem, azt ellenőriztem is. A saját VPN szerver nekem nem probléma, de általános user használatnál azért nem barátságos igény. Régebben a saját SSH porttal sem volt probléma, ma ez egy eléggé támadott kapu. A jól belőtt OpenVPN ma nem jelent nagy biztonsági kockázatot. De általánosságban minél kevesebb port van nyitva kifelé (természetesen szolgáltatással mögötte) annál jobb.

"A teamviewer NOGO."

Ebben maximálisan egyetértek veled. 

Ezek a távoli asztalos alkalmazások adminfeladatokra és segítségnyújtásra valók, nem arra, hogy távoli gépről videózz és audiót hallgass. Arra a streamelés való, akár videó, akár audio, akár egyéb screen/game stream. Bár ha jobban meggondolom, adminfeladatokra is inkább SSH konzol való, így marad a segítségnyújtás laikusoknak, amire ezek igazán kellenek.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Amúgy az xbox game streaming ugyanazt a technológiát használja, mint az RDP. Abban van kép/hang/input, gyorsaságra elég jó. Egyébként ahol tudja, ott használja a GPU video encoding/decoding-et, szóval elég gyors is.

Másik irányban, DX12 játékokkal próbáltam sima win10 gépről sima RDP-n keresztül telefonra streamelni, egészen használható élményt nyújt az is.

Így van. A távoli asztalnak két konkrét értelmes felhasználási területe van. Sok helyen ez a munkakörnyezet, azaz a kommunikáció, levelezés, az ügyviteli szoftver használata, ezekhez általában se videó, se hangátvitel nem szükséges (az ügyviteli programok ritkán adnak ki hangot magukból). Ahol ez a munkakörnyezet, ott ezzel párhuzamosan a gazdagépek között van független kép és hangkapcsolat, ami az RDP-től független (épp az a jó benne, hogy az nem kell központi legyen). Tehát itt a hang és a videó az RDP-hez többnyire fölösleges, attól mindenképp független.

A másik felhasználási terület amikor az admin "segít", erre volt használatos a teamviewer. Van olyan ügyviteli szoftver, amibe pl. a teamviewer a HelpDesk miatt eleve bele van építve (integrálta a fejlesztő). Amióta az RDP ennyire elterjedt (ebben a járvány és a home-office a "bűnös"), azóta szinte minden admin használ valamilyen "segítő" megoldást, pl. ssh+x11vnc. A teamviewer azóta szerintem értelmetlen, annyiféle ingyenes megoldás van, hogy erre (is) fölösleges költeni. 

Elvileg lehet persze olyan, aki az RDP-t vagy a teamviewert videószerkesztésre, zenehallgatásra, mozizásra vagy játékra akarja használni, de miért akarná ezt a saját környezete helyett így? Értelmetlennek tűnik.

Opre órákon hallottam először a kereskedelmi unix szerverekről amelyeknek a korban nagynak számító erőforrásai, ebben az esetben desktopként, ugyanarra a szerverre párhuzamosan csatlakozó x-terminálok között voltak szétosztva. Ugyanezt a képességet a Linux is tudja a mai napig. Furcsa, hogy pont a hup-on ez nem közismert. 

Az X-Window szerver-terminál (egy gépen belül is így megy de ebbe most ne menjünk bele) modell sajnos nem tartja a lépést a kor követelményeivel. Nincs hang, nincs általános megoldás a hardveres 3D-re, MS Windowsról (mint szerver) érdemben nem használható stb. Az X2Go új generáció hivatott orvosolni ezeket a hiányosságokat. Azaz már jóval a Teamviewer előtt létezett ez a felhasználási terület. Ma is van létjogosultsága.

"Elvileg lehet persze olyan, aki az RDP-t vagy a teamviewert videószerkesztésre, zenehallgatásra, mozizásra vagy játékra akarja használni, de miért akarná ezt a saját környezete helyett így? Értelmetlennek tűnik."

ShadowPC ami teljes távoli desktop környezetet ad havidíjért. Csak játékra Stadia, Geforce now, Xbox és PS távoli felhős játékplatformjai. Saját játékstreamelésre Steam Link. Hosszú a lista és egyre bővül. 

Csak kekeckedés végett: wtf kereskedelmi unix?

Az IBM szerveremhez a következő opciók voltak: AIX, RedHat, OpenSuse. Bármelyik ára $768. (2004) Az X-terminálok korában a linux=1 floppy, majd 2, amin már X is volt. (1992) No, nem pont ugyanaz, mint az AIX-en.

Az "MS Windowsról (mint szerver) érdemben nem használható" - pedig egész kiválóan használható szoftver létezett. Egyszer kínomban használtam is (Windows XP), amikor valamilyen elborult AIX programot kellett futtatnom a grafika mentes környezetben. Ugyanaz alkalmas volt vlc szerver (mert ahhoz is fel kellett mindent rakni) megkukkantására egy szekrényben raboskodó, képernyő és klaviatúra nélküli linuxon.

Maga az X-terminál úgy 2000 környékére gyártó híján kihalt. Korábban nagy előnyének számított, hogy több oprendszeren futó alkalmazásokat meg lehetett jeleníteni egy képernyőn. Amikor még menő volt, ugyanakkor céges környezetben az 1 floppys (diskless) Windows is menő volt. De ne feledd, arról a korszakról van szó, amikor még nincs vagy még nem terjedt el az ssh.

Utána pedig nem kérdés, hogy az ssh (amiben van X forwarding is) a platformfüggetlen kapcsolat. Aki képernyőt akar bámulni, annak ott a vnc, amiből a legolcsóbb a TightVNC. Manapság már mindennel IS kompatibilis.

A kereskedelmi Unix tényleg létező fogalom, nem ő találta ki. Pont az, amit írsz, AIX, meg még lehetne sorolni, Ultrix, HP-UX, Irix, Solaris, SCO Unix, Xenix, stb.. Minden ide sorolandó, ami nem eredeti AT&T Unix, és nem ingyenes vagy ingyenes licences unixlike rendszer (Linux, BSD-k, OpenSolaris, Illumnos, stb.).

A terminálok, akár X, akár nem X, kihaltak, de nem gyártó híján, hanem a technológia lett meghaladva, olcsók lettek a desktop gépek, amik nem csak terminálként, hanem egyben szerverként (értsd: komplett OS, és komplett X futtatása) is tudtak működni, így senki nem vett már terminált. Amúgy az utolsó bekezdésben pont azt írod, amit a kolléga is írt. SSH, X forward is bőven megfelelő sok feladatra, ezért felesleges sokszor ez a távoli asztalozás, meg az egész RDP, ami egy Windowshoz kötődő technológia.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Igen, ismerem a kereskedelmi unix fogalmát. Éppen ezért hoztam példának, a második mondatban: A RedHat linux egy nyílt forráskódú, közösség által fejlesztett, ingyenes, de részben nem nyílt forráskódú fizetős kereskedelmi unix. Tehát egy ingyenes kereskedelmi fizetős nem unix unix-linux. Ha valamit kihagytam volna, majd kiegészíted. ;)

Valamint némely vélemények szerint az AT&T UNIX és a BSD az IGAZI UNIX. Így aztán (pl.) a linux és az AIX is egy kalap alá kerül, hiszen (részben) mindegyik alapja a BSD 4.4.

Azaz egyszerűbb lenne megkülönböztetni a linux és egyéb kategóriát. Helyette jön az okosság, miszerint a "kereskedelmi unix" az elavult stb. Mindez olyanok által jól elmagyarázva, akik eddig csak linuxot láttak.

Próbálj megélni a Déli-sarkon teveeledel árusításából! Fél év múlva - mikor arra sétálok a tevémmel - joggal panaszkodok, hogy nincs teveeledel árus arrafelé. Pedig csak éhenhaltál. :-D

Inkább úgy mondanám, hogy csökkent a terminálok iránti érdeklődés, mert mindenkinek a torkán lenyomták a vidózt. Hiszen amiből a legtöbbet adják el, az csak a legjobb lehet! (halk :-D) Jómagam végigvi ttem / láttam olyan átmenetet, hogy Novell munkaállomás -> soros terminál -> OS/2 -> Windows. Ebből majdnem a soros terminál volt a legfejlettebb rendszer. Persze "az olcsó desktop, ami szerver is" téveszme elég ütős, de talán nem mindig a leghatékonyabb megoldás. Legalábbis ilyen rendszert nem igazán láttam még. (akkoriban)

Erre a mondatra írtam: "A RedHat linux egy nyílt forráskódú, közösség által fejlesztett, ingyenes, de részben nem nyílt forráskódú fizetős kereskedelmi unix."

A Red Hat Enterprise Linux teljesen nyílt forráskódú, nincs zárt proprietary  része. Ez a céges filozófiájuk része, amire marketing is épül. Természetesen van számtalan zárt alkalmazás, de azokhoz nincs köze a RedHat-nek, azok nincsenek hozzácsomagolva a RHEL-hoz. Nem véletlenül volt teljes értékű ingyenes RHEL alternatíva a CentOS, illetve most (mivel a centos át lett hangolva) az Oracle Linux, Rocky Linux vagy AlmaLinux.

https://www.openlogic.com/blog/red-hat-enterprise-linux-open-source

"Csak kekeckedés végett: wtf kereskedelmi unix?"

Raynes jól összefoglalta előttem. Annyival egészíteném ki, hogy az Apple máig költ arra, hogy hivatalos Unix minősítést kapjon az aktuális macOS rendszeréhez, így az is ide sorolható de jure, bár kilóg a unix sorból a macOS. Sőt még a Huawei Linux disztribúciója, a EulerOS 2.0 is megszerezte a UNIX certification-t.

De facto a klasszikus kereskedelmi unix rendszereket szokás érteni alatta, AIX-tól, Irix-en át Solaris-ig. Elég nagy részük kihalt mára mint az Irix, vagy vélhetően az utolsó kiadásánál tart mint a Solaris. 

"Az "MS Windowsról (mint szerver) érdemben nem használható" - pedig egész kiválóan használható szoftver létezett. Egyszer kínomban használtam is (Windows XP), amikor valamilyen elborult AIX programot kellett futtatnom a grafika mentes környezetben"

Azaz X-window kliensként használtad a Windows XP-t. Arról írtam, hogy a MS Windows X-Window forrásként, azaz szerverként nem működik. Nem tudod sem a teljes MS Windows desktopot, sem egyes Windows ablakokat X-Window System core protokollal megjeleníteni egy távoli X-windows terminálon. Egyébként grafikára is alkalmas az x-window. 

"Ugyanaz alkalmas volt vlc szerver (mert ahhoz is fel kellett mindent rakni) megkukkantására egy szekrényben raboskodó, képernyő és klaviatúra nélküli linuxon."

Mármint vnc-re gondoltál, igaz? Ha igen, a vnc képességei sok tekintetben elmaradnak a x-window-tól. Például nem tudja a szöveges tartalmat karakterenként átvinni, csak a desktop kép részeként. Nem tud egyes ablakot átvinni csak a teljes desktopot. 

"Amikor még menő volt, ugyanakkor céges környezetben az 1 floppys (diskless) Windows is menő volt."

Létezett ilyen valaha?! Milyen Windows fért rá egy floppy-ra? 

"Utána pedig nem kérdés, hogy az ssh (amiben van X forwarding is) a platformfüggetlen kapcsolat. Aki képernyőt akar bámulni, annak ott a vnc, amiből a legolcsóbb a TightVNC. Manapság már mindennel IS kompatibilis."

Videózásra még mindig elég alkalmatlan a VNC. Van egy desktop géped 64 GB rammal, 8 magos Ryzennel, Geforce rtx 3080-al. Megy egy notebookod 4 magos Intel Core i7-tel és intel grafikával 16 GB ram társaságában. Melyiken szerkesztenél inkább videót? 

Hát, nem vagyunk egy korosztály. ;)

Tudod, amikor még a UNIX embargós volt, akkor 2 emelettel alattam dolgoztak a VT32 fejlesztők. (Igaz, akkor még hardverel foglalkoztam.) Egy onnan kivált sráccal mentünk el egy céghez dolgozni és tőle kezdtem megtanulni a UNIX alapjait. Méghozzá SCO-t, ami akkor került forgalomba nálunk, amikor már nem volt embargós. Folytathatnám, de a "kereskedelmi UNIX" kifejezést csak néhány éve hallottam először.

Utána nem sokkal - egy másik cégnél - valódi, igazi, hamisítatlan IBM X terminálon dolgoztam. Én is konfiguráltam a bootp szervert hozzá AIX alatt. Nyilvánvalóan annyira tökhülye vagyok, hogy keverem a VNC-vel. Szerinted.

A vindózra úgy került az X, hogy egy certet kellett generálnom AIX-en futó X-es programmal. Oda meg nem rakukn X-et, mert se grafikus kártya, se grafikus alkalmazás, és a marha nagy méretű csomagokat utána le kell vakarni. Ezért a DISPLAY -> vindózon, mert ott a képernyő, meg az X szerver is. Azt egy szóval sem állítottam, hogy a MS Windows, mint olyan, megjelenik az X alatt. Csak annyit, hogy van egy szoftver - ha úgy tetszik kettő, amelyek X szerver és X kliens funkciókat látnak el. Ez biztos, mert külön ikon volt a két funkció indításához.

A VNC az adott valódi vagy virtuális gép (valódi vagy virtuális) grafikus csatolója által megjelenített képet másolja a hálózaton keresztül. Egy X-es ablak megjelenítéséhez kell egy window manager, amelyi kezeli az X terminált, de az ablak tartalmát egy-egy másik gépen futó program küldi. Ahonnan az ablak tartalma érkezik, ott nincs sem valódi, sem virtuális megjelenítés, hanem a kliens (X terminál) jeleníti meg a vm segítségével.

Tehát az X terminálhoz tartozik egy boot, vm, font szerver stb., majd indulás után jöhetnek az ablakokba a programok. A felsorolt elemek bármelyike jöhet akár külön-külön gépről és oprendszerről. Ezek a források nem szerverek. Pl. a demo az volt, hogy minden elem az AIX szerverről jött, de meg lehetett jeleníten az órát egy ablakban, amelyet egy VAX -> VMS -> ULTRIX Connection alatti óra program elindításával jelenített meg az AIX alatti vm az X terminálon.

"Milyen Windows fért rá egy floppy-ra?" - Semilyen, csak az user config. A többi a szerverről töltődött, olyan diskless client módon. Gondolom, Win 3.11 lehetett '92-ben. Részleteket nem tudok, mert én csak 8-10 év múlva ültem le Windows elé. Addig elég volt az AIX és a linux, de nem grafikus módban. A Windows csak utána jött, mert azon sok putty ablakot lehet nyitni!

Hasonló megoldást csinált az IBM is: Network Computer. Ez egy könyv méretű gép, ami AIX vagy akár linux szerverről töltődik. Monitor, egér, klaviatúra, villany és hálózat kell hozzá. Mindegyik megoldás előnye az, hogy drasztikusan megnő a menedzselhető gépek száma, hiszen minden a szerveren van. (Az utóbbi a 90-es évek közepe után.)

Biztosan csökevényes az értelmem, de most megjegyzem: A "remote desktop" videó nézésére, sőt vágására (de szigorúan laptopon), az rpi relé csattogtatásra, a mikrokontroller pedig szigorúan ledvillogtatásra való. Majd egyszer ehhez is hozzá fogok szokni, addig minden feladatra az arra legalkalmasabb eszközt fogom használni.

Mi múlt el? Hát nem X hajtja a linux desktopot??

Az már más kérdés, hogy a használói túlnyomó többségének gőze sincs az X-ről.

Amikor egy VAX-os okoskodik a junixon, azon mindig felröhögök. Ez a rasszizmus még abban az időben keletkezett, amikor a 33 MHz-es POWER szerverünket ápgrédeltük 75 MHz-esre. (Itt egy link, ami nem ugyanaz, csak a 7013-as ház a lényeg. A modell 57H volt.)

A linkelt cikkben a 4.77 MHz XT ugyan költői túlzás, ... de nem véletlenül fejlesztettem én sem 8-12 telnetes linux konzolon. Persze ez a 90-es évek eleje-közepe - mert azóta már minden sokkal bonyolultabb lett.

Olyan 8 éve oktattam egy fiatal versenyzőt, aki megállapította: Akkor te ott voltál a ma használatos technológia születésekor! (80-as évek közepe) Mesélj! - Én meg itt ülök egy legalább 600.000x gyorsabb hardver előtt és kb. ugyanazt csinálom...egy kicsit lassabban. Legyen ez a mottó! :-D

Nincs ilyen, csak RDP, vagy VNC, ami a képet viszi csak át.

Hátha angolul jobban érted. ;) "Oh and by the way, the client/server terminology in X seems backwards until you think about it the right way: servers are the things that provide a display service; they display the graphics and take mouse/keyboard input (like your Windows box); clients are the programs (running on Ubuntu in your case) that need the display service." - írta valaki egy hasonló kérdésre a Super User-en.

Vagyis egy Excel a windows erőforrásaival képes képet kiirakni.

Az X esetén két megoldás van, amit megpróbálok roppant primitíven elmagyarázni.

- Írsz egy programot, és a megjelenítéshez hozzá kell fordítani olyan lib(ek)et, ami kifejezetten az xdm alá dolgozik. Tehát van olyan hívás benne, hogy rakjál ki egy bigyót az ablakba. Olyan, mint karakteresen a curses, vagy win alatt a directx.

- Van egy programod, aminek egyszerű kimenetei vannak: stdin, stdout és stderr. Írsz egy olyan programot, ami egyik oldalról kezeli ezeket a csöveket, másik oldalról kezeli az X hívásait. Na, így készül a gdb vagy a GNU Chess frontendje. Az utóbbinál fogod azt a kódot ahol vezér üti b9, és kirakod a sakktáblára, amit megírtál hozzá.

Ennek alapján az Excelnek kezelnie kell a std csatornákat (semmi ilyet nem tesz), vagy a kezedben kellene lennie a forrásának, amelyben lecseréled a megjelenítést a win api hívásokról x hívásokra.

Mindezek ellenére használhtsz olyan szoftvert, ami X szerver - fogadja a klienseket és megjeleníti a képet, vagy klienst - ami pl elküldi az órát egy ablakba a szerverre. Ma már nem kell ilyen, mert ott a cygwin, de talán a win  ubuntu shell is jó. (Az utóbbi sem fogom kipróbálni. ;))

További kérdés - ha jól értem, akkor az X forwarding során a kijelző geometriájának megfelelő a szerver oldalon megjelenő képe az alkalmazásnak. De hogyan lehet a szerveren megjelenített alkalmazás geometriáját megváltoztatni anélkül, hogy az egész kijelző geometriáját változtatnánk? Valahogy úgy, ahogy az xclock --geometry parancsával lehet... úgy tűnik, ezt az opciót az alkalmazások fejlesztése során már átlépték, vagy mindent állítunk a teljes kijelzőn, vagy a megjelenített alkalmazás geometriája egybeesik a szerveren éppen alkalmazott felbontással. Tehát nekem úgy tűnik, hogy ilyesmit vagy tud az alkalmazás, vagy nem, többnyire már nem törődnek ilyesmivel a fejlesztők.

Az X forwarding csak egy cső.

A kérdéseidre néhány lib-ben tanulmányoznod kellene a kérdéseidre választ adó függvényeket. Tőlem biztosan nem fogod megtudni a választ, mert soha nem programoztam grafikát és valószínűleg így is fogok meghalni.

A kollégám programozott ilyeneket. Fogsz néhány mintaprogramot és pillanatokon belül megtalálod az igazak útját. ;)

Egyáltalán nem szándékoztam személyes támadást indítani ellened. Sajnálom ha ekként élted meg a válaszom. Én ugyan utólag tanultam erről, de ettől vagy pont ezért bizonyos tények kérdésében pontosabbak az ismereteim. 

"Folytathatnám, de a "kereskedelmi UNIX" kifejezést csak néhány éve hallottam először."

2005-ben már használta a wikipedia ezt a kifejzést.

". Nyilvánvalóan annyira tökhülye vagyok, hogy keverem a VNC-vel. Szerinted."

Akkor passz! Mire gondoltál "Ugyanaz alkalmas volt vlc szerver (mert ahhoz is fel kellett mindent rakni) megkukkantására egy szekrényben raboskodó, képernyő és klaviatúra nélküli linuxon."-al? 

"Egy X-es ablak megjelenítéséhez kell egy window manager, amelyi kezeli az X terminált, de az ablak tartalmát egy-egy másik gépen futó program küldi."

Ez egészen biztosan nem igaz. Bőven elég az Xorg kliens oldalon a távoli X-es alkalmazás megjelenítéséhez.

Távoli unix/linux szerveren:
tavoli-szerver$ export DISPLAY=linuxpc01.szoba42.local:0

Saját helyi linuxodon virtuális terminálból ha még X sem indult:

linuxpc01$ startx

Ha ~/.xinitrc -ben xterm benne van de nem indul semmilyen ablakkezelő az is elég. Meg fog jelenni a terminál emulátor alakkeret nélkül. Nem tudod áthelyezni, méretezni, nem is túl kényelmes de működik. Onnan:

linuxpc01$ xhost +tavoli-szerver.nagyterem.local

Ezután a távoli szerveren indított X-es programok nálad jelennek meg, akár ablakkezelő nélkül is. Telepített xauth kell de windows manager nem, bár úgy kényelmes használni. Ha a teljes távoli desktopot hozod át akkor egyáltalán nem kell a lokális linux rendszereden ablakkezelőt indítanod, mert a távoli desktopot fogod használni a távoli ablakkezelővel. 

Ehhez ssh sem kell és már az ssh -X user@tavoli-szerver.nagyterem.local előtt is működött. 

"Tehát az X terminálhoz tartozik egy boot, vm, font szerver stb., majd indulás után jöhetnek az ablakokba a programok. A felsorolt elemek bármelyike jöhet akár külön-külön gépről és oprendszerről. Ezek a források nem szerverek."

De a server terminológiát használjuk rá. Hint: Linux Terminal Server Project, itt csak virtuális gépről demonstrálják a vékony klienst a lényeg így is látható. Nagyon ment a görög iskolákban és terjesztették a szomszédaik felé is.

"Hasonló megoldást csinált az IBM is: Network Computer. Ez egy könyv méretű gép, ami AIX vagy akár linux szerverről töltődik."

Nem! A Network Computer nem IBM hanem Oracle találmány. Szövetséget szervezett a koncepció mögé neves risc/unix gyártókból, ezek között ott volt az IBM, de mások is mint SUN Microsystems és többi unixos, sőt még az Apple is. A vékony kliens többféle operációs rendszert használt gyártónként. RISCOS - NCOS néven (Acorn fejlesztés, ma pl RPi-ken lehet használni), SUN persze JavaOS-sel (ami szintén nem unix alapú vékony rendszer volt), IBM valami BSD alapú rendszert használt. 

Nem érzékeltem a támadást. :)

Azt azért megemíteném, hogy a következő konfigurációról beszéltem:

AIX (mwm, boot, firmware) -> fizikai X terminál (ami bootol, firmware-t tölt és megjeleníti a képet)

A képet (ablakokat) az AIX-ről jeleníti meg. Az xclock-ot mondjuk egy egy VAX-ról.

És nincs távoli desktop se.

És igen, akkor még nem volt ssh sem.

És a linuxos xorg kezdemények csak ez után jelentek meg.

Felismered az elemeket?

"Egy X-es ablak megjelenítéséhez kell egy window manager, amelyi kezeli az X terminált, de az ablak tartalmát egy-egy másik gépen futó program küldi."

AIX (mwm), terminál (ablak, mert ugye csak egy konzolod van wm nélkül), program (xclock - másik gép: VAX).

És ez már olyan régen volt, hogy biztosan nem igaz. ;)

A szerver terminológiát tényleg így használjuk: pl. font szerver. A terminológia ellenére ez csak annyit jelent, hogy nem rom-ból vagy helyi diszkről, hanem egy ip címről érkeznek a fontok. A rom nem szerver, tehát ami kiváltja az sem szerver, csak úgy hívják. Így értelmet nyer a "nem szerver" megállapításom is.

Az xclock egy program. Hiába futtatod egy szerveren.

Az AIX szerverben nincs grafikus adapter és ezért monitor se, de odakeveredett egy csak X-et használó program, amit egyszer kellett csak elindítanom. Ekkor felrakok egy minimál X környezetet, és az egyetlen kliensre irányítom a DISPLAY-t, ami a vindózos x client program. Megjelenik az ablak, beírom a kódot és már szedem is le az X-et.

 

Ugyanez a helyzet a VLC felrakásakor, felmennek a grafikus lib-ek is, mert kellenek hozzá. Ekkor a VLC még nem tudja, hogy azon a gépen nem fog képet kirakni és nincs is mire, mert nem úgy fogom használni. Ennek ellenére meg tudom jeleniteni X segítségével a képet, csak máshol. A módszer hasonló, mint az előbb. Utána: linux (vlc) -> video -> vindóz (vlc) -> tévé.

A filmet másik vindóz (firefox) -> http -> linux(vlc) úton választom ki.  Az rpi nem játszik 15 évvel ezelőtt, linux desktop meg nem volt.

"A Network Computer nem IBM hanem Oracle találmány." Nemmindeggy? Attól még az IBM is gyártott ilyet, viszont nem említettem, hogy ki találta fel.

A linkelt "kereskedelmi unix" cikkben nem említik a kereskedelmi unixot. Olvasd csak el!

Említik viszont

  • ... developed over time by AT&T, several other commercial vendors, as well as several non-profit organizations (==fizetős vagy ingyenes)
  • AT&T made UNIX available to universities and commercial firms, as well as the United States government under licenses.
  • AT&T now developed UNIX System III, based on Version 7, as a commercial version and sold the product directly... (ez az AT&T UNIX eladásra szánt verziója)
  • The new commercial UNIX releases (már megint az AT&T UNIX eladásra szánt verzióiról van szó)
  • Other companies began to offer commercial versions of the UNIX System for their own mini-computers and workstations.(még mindig ugyanaz)
  • BSDI was the first company to produce a fully-functional commercial version of BSD UNIX (a BSD is kereskedelmi UNIX, vagy legalábbis van olyan verziója)
  • By 1993 most of the commercial vendors of UNIX had changed their commercial variants... (tehát volt egy kereskedelmi változata ugyanannak az izének. A commercial vendors -> kereskedelmi szállító -> magyarul rövide a szállító (aki a terméket szállítja))

Tehát megállapítom, hogy az AT&T a belső használatra készített UNIX rendszerének egyik verziójából készített eladásra szánt terméket. Tőlem hívhatod akár "kereskedelmi UNIXnak" is. Szerintem ez csak téves tükörfordítás. De kérlek, el ne magyarázd!

( DanielChief | 2022. 02. 09., sze – 15:54 )

Köszi, utánajárok a DWService-nek. Első körben szimpatikus. Eddig én nagyrészt amúgy is az Anydesk-et használtam.

( taarzaan | 2022. 02. 09., sze – 23:14 )

Kicsit azért elvész ez a dwservice így a bejegyzésben... pedig tényleg jó kis cucc. Én két éve találtam rá. Egy laptopot felraktam a galériára egy projektorral és macera lett volna manuálisan böködni. Sokat azóta nem használtam, de tette a dolgát.

Nekem ez nem annyira  szimpatikus: https://www.dwservice.net/hu/contribute-subscriptions.html

Ha valami hangoztatottan ingyenes, akkor ne legyen megkülönböztetés. 

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Ha saját subneten használod akkor ők csak a programkódba fektetett munkájukat adják neked ingyen sourcecode-dal. Ha kívülről használod az ő szervereiken keresztül akkor költséget okozol nekik már a szolgáltatásuk használatával is. Az előfizetés elsősorban támogatásról szól. Az oldal alján tételesen felsorolt "előnyök":

SUBSCRIPTION PROVIDES THE FOLLOWING BENEFITS:

  • Ensure the sustainability and health of the DWService project. - Azaz segíted a projektet.
  • All subscribers will be listed on this page, ordered by subscription class. - Dicsőségtábla, ez is ok.
  • All subscribers have a greater maximum bandwidth than non-subscribed users. - Ez az egyetlen valódi különbség a szolgáltatásban, de ez szerintem rendben van, mert ha fizet valaki megérdemli az extra sávszélességet az ő szervereiken keresztül, ami nekik is havi költséget jelent. Még így is jófejek szerintem, hogy adnak nekik pénzbe kerülő sávszélességet az ingyenes usereiknek.
  • All subscribers will be allowed to use a special version of the DWService logo on their web site, which shows they are supporters of the DWService project. - Dicsőségplecsni, szerintem ez is rendben van.
  • All subscribers will receive technical support, latest bug fixes and updates. - A supportot pénzért régi hagyomány az opensource világban. A kérdőjel itt az, hogy legutóbbi frissítéseket vajon később kapják-e meg a nem fizető ügyfelek. A forráskód itt található: https://github.com/dwservice/agent és úgy látom itt is folyik a fejlesztés, azaz nem csak kirakják githubra néha, időközönként a máshol fejlesztett forráskódot. Szóval legrosszabb esetben is később kapnak frissített binárisokat az ingyenes ügyfelek, és github-ról kell fordítani forráskódból ha mindig naprakész akar lenni egy ingyenes user. De ez is csak feltételezés.

Más nyílt forráskódú modern távoli asztal szoftver hiányában nincs jobb jelenleg, ezek a fentiek pedig nálam beleférnek. Teljesen ingyen nagy sávszélességet a Chrome Remote Desktop ad, de az nem nyílt forráskódú. 

Nálam ilyenkor mindig az kerül mérlegelésre mi a biztonságosabb?

- Csak a szoftver használom de 100% saját kontroll alatt álló infrastruktúrán (nyilván nem minden router kettőnk között, de értsd jól) Ez esetben VPN kapcsolat és onnantól egy subneten vagyunk. Az így kapott sávszélesség természetesen a maximum lesz. Kettőnk közötti sebességen egy közbeiktatott szerver sem tudna gyorsítani. Hátránya, hogy működtetnem kell hozzá egy világ felé nyitott OpenVPN-t, de ma ez nem jelent nagy biztonsági kockázatot az OpenVPN jó biztonsága és minősége miatt.

- Szoftvert és hozzá kapcsolódó szolgáltatás infrastruktúráját is használom. Ilyenkor annyira jó a biztonság amennyire a használt szolgáltatás. Itt az előny az, hogy semmilyen portot nem kell nyitva tartani az internet felé magamnál a fix pc-n. Egy Google elég tőkeerős, hogy ingyenesség mellett is bízni lehessen a szolgáltatása biztonságában. Illetve korábban is jól teljesített biztonság terén. Egy kisebb szereplőnek inkább fizetek, csak álljon minden anyagi forrás a rendelkezésükre, nehogy a biztonságon kelljen spórolniuk. 

Ezzel együtt is kisebb céges háttérnél inkább az első opciót választom. 

Ez tisztasor, egyetértek. Viszont a kereskedelmi szoftverek esetében tudhatók a korlátok, mérlegelhetők az előnyök/hátrányok, egy ingyenesként propagált szoftver esetében viszont kellemetlen az apróbetűs lábjegyzetben arra bukkanni, hogy "igen, ingyenes, de jobb ha fizetsz, különben nem tudjuk garantálni, hogy használható sebességet kapsz!'. Ennyi erővel egy kereskedelmi szoftver free opciójával is jobban járhatsz (az a kapcsolat is átmegy a cég szerverén), viszont ott legalább nincs ez a fajta priorizálás.

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Annyit még az előzőhöz, RDP-nél a BlueKeep elég durva biztonsági hiba volt, sorban törték fel a szolgáltatást futtató windows rendszereket. Ezért sem árt óvatosnak lenni, ez mégiscsak egy közvetlen kapu a gépedre. 

Ebben amit most írtál is nagyrészt egyetértek veled. Számomra ezért a Chrome Remote Desktop teljesen optimális megoldás. Viszont szeretem ha van alternatívája és az lehetőleg opensource alternatíva. 

Anno rdp-t csak ssh-tunnelen keresztül használtam (ma már úgy sem), pedig minőségre talán azzal lenne a leginkább "a gép előtt ülök"-élmény. Kár hogy ennyire korlátoltak a lehetőségei. 

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Chrome remote desktop ugyanolyan "a gép előtt ülök" élmény, sőt annyiban jobb is, hogy szó szerint bármi elindul a távoli asztalon azt látni fogod. UAC sem fog ki rajta.

RDP távoli asztalon a GPU-t használó 3d alkalmazásoknak legalább egy része nem működik, el sem indul úgy.

DWService amióta tesztelem szintén hozza a "a gép előtt ülök" élményt.