1 PC, Zugriff von mehreren Arbeitsplätzen. Wie?

Du suchst nach KVM Switch.

Wenn es über LAN gehen soll dann der Suche LAN hizufügen.

Hier gibt es sowas zum beispiel.

https://kvm-switch.de/de/

Tastatur/Maus/Monitor ist vergleichsweise einfach (Microsofts Remote 
Desktop, VNC, ...). USB wird schon deutlich interessanter, Audio 
wahrscheinlich auch.

Wenn du auf diesem Weg nicht zum Experten werden willst, dann nimm ein 
Notebook und klemm es ggf unter den Arm.

markus schrieb:
> Gibt es solche Geräte wo man in jedem Raum die Periphärie anschliesst
> und dann übers Netzwerk die Daten übertragen werden?

Solche Geräte sind i.d.R. teurer als jeweils ein kompletter PC pro 
"Arbeitsplatz".

A. K. schrieb:
> dann nimm ein Notebook

PS: ... mit jeweils einer Docking-Station an den Plätzen. Ist einfacher.

DS216


aktuelles Modell DS218

https://www.e-tec.at/frame1/details.php?art=253826&gclid=EAIaIQobChMIroHNmNaH3AIVGYfVCh1UrQgxEAQYASABEgIHrPD_BwE

Alles wichtige an eigenen Daten drauf was vorher auf diversen PC, Läppis 
usw.
rumflog. An den internen Router damit, über WLAN und LAN können alle 
Geräte(MAC iPAD Windows- und Linuxrechner) im Haus drauf zugreifen, 
sogar vom Internet, wenn ich will. Auf den Geräten läuft nur mehr 
gerätespezifische SW.

Weiterer Vorteil die Platten in der DS sind gespiegelt. Zusätzlich ziehe 
ich halbjährlich Backups. Seither keine Daten verloren. ;)

Namaste

mit Teamviewer kannst du komfortabel das gewünschte einrichten.

Wegstaben V. schrieb:
> mit Teamviewer kannst du komfortabel das gewünschte einrichten.

Das wär was für Fans der Cloud, mit gutem Internet-Anschluss. Denen es 
nichts ausmacht, dass der Kram über Server im Internet läuft, nicht 
lokal. ;-)

markus schrieb:
> @ Antoschka
> dies ist leider keine Option, der Hauptrechner steht bereits und die
> HW-Konfiguration lässt sich nicht soeinfach in ein mobiles Gerät
> integrieren (spezielle PCI-Karten / Audio-Interface). Trotzdem danke.

was stört dich am kostenlosen realVNC?

braucht keine extra Hardware, läuft sogar auf einem Raspi (OK lahm) aber 
das Tempo macht ja der "Fernbediente" mit seiner Hardware, auf den 
Clienten will oder muss man vielleicht nicht TV sehen mit 60 FPS

A. K. schrieb:
> Wegstaben V. schrieb:
>> mit Teamviewer kannst du komfortabel das gewünschte einrichten.
>
> Das wär was für Fans der Cloud, mit gutem Internet-Anschluss. Denen es
> nichts ausmacht, dass der Kram über Server im Internet läuft, nicht
> lokal. ;-)

https://community.teamviewer.com/t5/Knowledge-Base/Can-TeamViewer-be-used-within-a-local-network-LAN-only/ta-p/4618

markus schrieb:
> Joachim B. schrieb:
>> markus schrieb:
>> was stört dich am kostenlosen realVNC?
>
> bis jetzt noch nichts, da ich noch nicht mal weiss was dies ist ^^ werde
> mich mal schlau machen darüber.

oder tightVNC oder ultraVNC

Wenn das verwendete Windows 10 nicht die kastrierte Heim-Version ist, 
kann statt VNC auch das windowseigene RDP ("remote desktop") verwendet 
werden. Das ist schneller, insbesondere seit den 
Protokoll-Optimierungen, die mit Windows 8 eingeführt wurden.

Allerdings braucht man natürlich wiederum irgendein Gerät, auf dem man 
den entsprechenden Client laufen lässt (Windows selbst liefert ihn mit, 
mstsc.exe, aber es gibt auch RDP-Clients für Linux).

Es gibt auch sogenannte "Thin-Clients", das sind kleine stromsparende 
PCs ohne Festplatte o.ä., auf denen eine korrespondierende Software 
läuft. So etwas könnte gebraucht recht günstig zu bekommen sein; als 
Neugerät ist ein Selbstbau z.B. auf Basis eines Intel NUC oder Gigabyte 
Brix aber günstiger.

Rufus Τ. F. schrieb:
> RDP ("remote desktop") verwendet
> werden. Das ist schneller, insbesondere seit den
> Protokoll-Optimierungen, die mit Windows 8 eingeführt wurden.

RDP war auch im Jahr 1998 schon ungefähr 42 mal schneller als das 
schnellste VNC. sogar über eine einzelne ISDN-Leitung.

Nun, auch VNC wurde weiterentwickelt und ist zwischenzeitlich benutzbar 
geworden. Apple verwendet das für seine "Remote Desktop"-Lösung.

georg schrieb:
> Joachim B. schrieb:
>> was stört dich am kostenlosen realVNC?
>>
>> braucht keine extra Hardware
>
> LOL, nur einen kompletten PC.

och bei mir tun es einige PI unter 50,-€

> Ausserdem musst du dem TO erst mal
> erklären, wie du mit RealVNC oder etwas ähnlichem eine USB-Schnittstelle
> so durchreichst, dass er an jedem Platz einen Stick oder sonstwas
> einstecken kann.

war das das Ziel, dann erkläre wo du das liest!
USB Anschlüsse kann auch heissen Maus und Tastatur
ansonsten ist es kein Problem vom VNC Server aufs NAS zu speichern und 
am Client wieder abzuholen

> KVM über VNC ist auch nicht geeigent, auch dafür braucht man einen
> Client-PC. Mir ist jedenfalls keine KVM-Over-Ethernet bekannt, bei der
> Tastatur usw. direkt ans Ethernet angeschlossen werden können.

es gibt auch virtual USB für den PI damit kann ein abgesetzter PI übers 
Netzwerk USB Schnittstellen durchreichen als USB Server, sowas mache ich 
mit Sharkoon LANport um abgestzt über Netzwerk den ISP Prommer zu 
steuern.

> Natürlich sind die Vorstellungen des TO ziemlich unsinnig, aber so sind
> sie nun mal, und das ist eben die Frage, wie macht man das. Mir fällt da
> auch nichts ein ausser einem Server und Client-PCs an jedem Arbeitsplatz
> (natürlich furchtbar konventionell, sprich rückständig), daher melde ich
> mich auch zu dem Thema nicht mehr, das wird eh ohne Lösung versanden.
>
> Georg

besser so?

VNC hat den Charme gegenüber RDP XRDP das alles was auf dem ServerPC 
passiert auf dem Monitor sichtbar ist

Schalte ich die Webcam vom abgesetztem Client ein dann sehe ich das Bild 
auf dem Client und auf dem Server Monitor, oder eben ein Quellprogramm 
in der IDE kann beim Zimmerwechsel sofort weiterprogrammieren.

Bei RDP und XRDP wird hinterrücks ein weiteres Fenster geöffnet welches 
auf dem Server nicht sichtbar ist, kann gut sein zur Zimmerüberwachung, 
nervt aber wer nach Zimmerwechsel weiterarbeiten will.

georg schrieb:
> Du kannst mich auch ruhig noch weiter anpöbeln

ich will dich überhaupt nicht anpöbeln, ich lese den Wunsch des TO nur 
anders
er schrieb eindeutig die ganze nötige Hardware hängt am Server Rechner.

Das nun USB am Client was anderes tun soll als Tastatur und Maus 
aufnehmen soll habe ich ncht interpretiert, offensichtlich du.

Aber darum muss es doch keinen Streit geben oder (ausgenommen du willst 
streiten, ich aber nicht)

Manfred schrieb:
> TV über RDP geht bei mir generell garnicht.

da ich nur VNC nutze geht das sogar, reicht um den PI mit OSMC zu 
bedienen, nicht zum gucken wegen 5-10 FPS, auch die WEBcam wird 
übertragen zwar auch langsam aber mir genügt es.

Joachim B. schrieb:
> nervt aber wer nach Zimmerwechsel weiterarbeiten will.

Auch bei RDP (genau wie beim Linux-Äquivalent X2go) kannst Du eine 
Sitzung trennen und von einem beliebigen anderen Ort wieder aufnehmen 
und weiter arbeiten.

Wenn Du natürlich wie mit deinem Webcam-Beispiel ein Programm lokal auf 
dem Client startest ist es natürlich nur auf dem Client. Auch bei VNC. 
Das ist ja auch logisch.

Bernd K. schrieb:
> Wenn Du natürlich wie mit deinem Webcam-Beispiel ein Programm lokal auf
> dem Client startest ist es natürlich nur auf dem Client. Auch bei VNC.

ich hatte die Aufgabenstellung so verstanden und ich wünschte mir das 
auch.
Aber Server!

Denn der Server soll ja die angeschlossene Hardware nutzen!

vielleicht verstehen wir uns auch miß,

bei Synergy ist
Server der PC der Maus und Tastatur besitzt
Client der es nutzt

Deswegen ist Server der PC für mich mit der angeschlossenen Hardware
Server der PC der diese Hardware besitzt
Client der es nutzt

markus schrieb:
> dies ist leider keine Option, der Hauptrechner steht bereits und die
> HW-Konfiguration lässt sich nicht soeinfach in ein mobiles Gerät
> integrieren (spezielle PCI-Karten / Audio-Interface). Trotzdem danke.

ergo ist der Server derjenige mit der Hardware

steht bei mir auch im Wohnzimmer und wird mit Client PC/PI anderorts 
genutzt, deswegen verstehe ich deinen Satz nicht!

Bernd K. schrieb:
> Wenn Du natürlich wie mit deinem Webcam-Beispiel ein Programm lokal auf
> dem Client startest ist es natürlich nur auf dem Client.

meine Clients haben keine Webcam, wozu auch wenn ich in Woohnzimmer 
schauen will?

Auch wenn es ein paar Nachteile hat..

Eine Möglichkeit wäre auch ein paar Steam-Links anzuschaffen.
(gab es im Sale für 3€)

Joachim B. schrieb:

> meine Clients haben keine Webcam, wozu auch wenn ich in Woohnzimmer
> schauen will?

Vielleicht versuchst Du vor dem Schreiben erstmal Deine Gedanken zu 
ordnen und nach dem Schreiben nochmal korrekturzulesen denn in dem 
Posting auf das ich mich bezog schriebst Du daß Du es auf dem Client 
startest und das Fenster deshalb nicht auf dem Server erscheint.

Und das ist natürlich logisch. Diesbezüglich gibt es auch keine 
Unterschiede zwischen VNC und RDP: Was Du auf dem Server startest läuft 
auf dem Server und Du kannst es von jedem Client aus sehen und benutzen, 
was Du auf dem Client startest bleibt nur auf dem einen Client.

Wenn Du darauf antworten willst dann versuch Dich bitte mal verständlich 
auszudrücken sonst geht das noch ewig so hin und her.

c-hater schrieb:
> Es ist immer noch vielfach langsamer als RDP.

Habe ich nirgends bestritten; und wenn Du genau gelesen hättest, hättest 
Du auch gesehen, daß ich RDP vorgeschlagen habe.

c-hater schrieb:
> Ziemlich schwachsinnige Auffassung, finde ich.

Bei X ist es so, da ist das, was man auch "Terminal" nennen könnte, also 
das Ding, das den Monitor ansteuert, vor dem jemand sitzt, der Maus und 
Tastatur nutzt, der "Server", währenddem der PC, auf dem das Programm 
läuft, das dem "Terminal" mitteilt, was es wo darzustellen hat, als 
"Client" bezeichnet wird.

Die andere Sichtweise, das "Terminal" als "Client" zu bezeichnen, hat 
sich recht überwiegend durchgesetzt. Da nennt man solche Geräte auch 
"ThinClient" ...

Mittlerer Datentechniker schrieb:
> Es ist konsequent das gleiche wie bei Datenbanken:

So, und nun stellst Du Dir mal einen dicken fetten PC vor, auf dem 
mehrere Programme mehrerer unterschiedlicher Benutzer gleichzeitig 
laufen. Die Bildschirmausgaben und Tastatureingaben der Benutzer 
erfolgen an minimalistischen kleinen PCs (oder sogar seriellen 
Terminals).

Der X11-Definition zufolge sind das je ein Server pro Benutzer, und der 
dicke fette PC ist dann mehrere Clients gleichzeitig.

Also ist auch ein serielles Terminal ein Server (daß das statt bunter 
Graphik nur etwas Text darstellt, dürfte für die grundlegende 
Betrachtung ziemlich irrelevant sein).

Ja. Das klingt logisch. Irgendwie.

Bernd K. schrieb:
> Vielleicht versuchst Du vor dem Schreiben erstmal Deine Gedanken zu
> ordnen

meine Gedanken sind geordnet und beziehen sich auf die Benennung der 
Programme,
wenn man den Thread weiter folgt merkt man das es verschiedenste 
Definitionen für Server und Client gibt so das JEDER auch du versteht 
was er verstehen will,

c-hater schrieb:
> Wobei ich zugeben muss,
> dass die Rollenzuordnung bei Anwendungen vom Typ "RemoteDesktop"
> wirklich nicht so ganz einfach ist. Da scheitern die klassischen
> Definitionen nämlich schlicht und ergeben: beide Seiten sind beides...

genau!

wer aber andere Sichtweisen NICHT zulässt kann nicht mitdiskutieren.

Auf einem Clienten eine Webcam zu starten welche am Server hängt zeugt 
nun mal von Unverständnis.

Bernd K. schrieb:
> was Du auf dem Client startest bleibt nur auf dem einen Client.

auf dem Client eine WEBcam starten die an Sever hängt?
ziemlich verworren auch deine Rede :)

georg schrieb:
> Was der TO als USB-Anschluss haben möchte weiss
> hier keiner.

eben!

RDP und XRDP fand ich brauchbar aber nicht für mich weswegen ich nur 
noch VNC und x11vnc nutze

Mittlerer Datentechniker schrieb:
>> Die andere Sichtweise, das "Terminal" als "Client" zu bezeichnen...
> ...ist Marketinggequatsche ;-) leider Eingebürgertes.

Nein. Wenn auf irgendwelchen dabei beteiligten Protokollschichten 
zufällig der Client den Part des Servers übernimmt ändert das noch lange 
nichts an der grundsätzlichen Topologie: Zuerst baust Du als Client eine 
Verbindung zum Server auf, zum Beispiel per SSH. Alles was danach in dem 
Tunnel passiert sind Implementierungsdetails die den Anwender nicht 
interessieren müssen.

Keiner nutzt in der Praxis nackte X11-verbindungen so daß er sich über 
solche Details Gedanken machen müsste, die werden immer über irgend 
etwas getunnelt und das ist es was der Endanwender zu sehen bekommt und 
wie es sich nach außen darstellt: Er startet zum Beispiel den X2go 
Client und verbindet sich mit einem X2go Server. Welche Richtungen dann 
dabei irgendwelche der zwei dutzend eingebetteten dreifach 
verschachtelten Low-Level Unterprotokolle haben die im Rahmen dieser 
Verbindung automatisch abgewickelt werden oder auch nicht interessiert 
ihn nicht die Bohne und soll es auch gar nicht.

Der Client (Auftraggeber, Kunde) ist der der die Musik bestellt hat und 
der Server ist der der sie pflichtgemäß spielt. Wenn er dazu Rückfragen 
an den Auftraggeber hat die der Auftraggeber (oder einer seiner 
Untergebenen) beantworten muss damit das Geschäft abgewickelt werden 
kann werden dadurch mitnichten plötzlich die Rollen vertauscht in Bezug 
auf wer arbeitet für wen und in wessen Auftrag. Es mag sein daß der 
Dienstbote des Lieferanten (X11-client) den Dienstboten des Kunden 
(X11-server) im Zuge dieser einen Transaktion mal kurzfristig 
herumkommandieren darf und es mag auch sein daß der eine immer die 
Oberhand hat wenn sich x11client und x11server mal zufällig alleine auf 
dem Datenhighway treffen und keiner ihrer Herrn dabei ist aber das sind 
Implementierungsdetails die nicht nach oben dringen und die Herrschaften 
Kunden nicht interessieren. Am Ende wird im Rahmen des übergeordneten 
Protokolls geliefert was bestellt wurde und nur dadurch wird definiert 
wer hier Kunde und wer hier Lieferant ist.

c-hater schrieb:
> Joachim B. schrieb:
>
>> bei Synergy ist
>> Server der PC der Maus und Tastatur besitzt
>> Client der es nutzt
>
> Ziemlich schwachsinnige Auffassung, finde ich.

Das liegt nur daran, dass viele im Hinterkopf haben, dass der Server 
immer das ist, was weit weg vom Benutzer ist. Aber eigentlich ist er 
das, was einen Dienst anbietet. Der Client ist das, was den Dienst 
benutzt. Und das ist ganz unabhängig davon, vor welchem von den beiden 
der Benutzer hockt.

c-hater schrieb:
> Die Grundidee ist einfach: wer will was von wem?

Genau, und in diesem Fall ist der angebotene Dienst der Zugriff auf 
Tastatur und Maus. Der Client will wissen, was der Benutzer eingibt, der 
Server stellt diese Information zur Verfügung.

Wenn es nicht Enterprise Grade sein muss schau dir mal SteamLink an 
(wobei die Hardware wohl momentan durch eine Android App ersetzt wird, 
also evtl brauchst du jeweils eine Android Box + gratis App). Sollte 
eine weitaus bessere Performance abliefern als VNC da ausgelegt auf 
geringe Verzögerung und hohe Auflösungen.

Rolf M. schrieb:
> Genau, und in diesem Fall ist der angebotene Dienst der Zugriff auf
> Tastatur und Maus. Der Client will wissen, was der Benutzer eingibt, der
> Server stellt diese Information zur Verfügung.

Diese Sichtweise lässt sich ebenso gut umdrehen und das passiert auch. 
Tatsächlich ist das schlicht eine Frage, wer mit wem Verbindung 
aufnimmt.

Das X11 Netzprotokoll definiert das Terminal als Server, denn das 
Terminal stellt einen Port zur Verfügung und der zentrale Rechner nimmt 
damit Verbindung auf.

Bei RDP und VNC ist das andersrum, d.h. der zentrale Rechner stellt den 
Port zur Verfügung, und der PC mit dem User davor nimmt damit Verbindung 
auf. Bei RDP nennt sich der zentrale Rechner auch Terminal-Server, weil 
er für potentiell mehrere Terminals den Server spielt.

Rolf M. schrieb:
> Genau, und in diesem Fall ist der angebotene Dienst der Zugriff auf
> Tastatur und Maus. Der Client will wissen, was der Benutzer eingibt, der
> Server stellt diese Information zur Verfügung.

dann stimmt doch alles wieder

Ein Gerät ist Server
mein PI mit Webcam, alle anderen die es nutzen sind Clients (VNC)
mein USBlanport 400 Sharkoon, alle anderen die abgesetzt USB nutzen sind 
Clients (eigener USB Treiber)
mein PC mit Maus und Tastatur, alle anderen die es nutzen sind Clients 
(Synergy)

ich weiss nicht mal warum das angezweifelt wurde!

und beim TO ist es doch genauso, er möchte abgesetzt vom Server dessen 
Hardware nutzen, also alles was an Hardware am Compi hängt also stellt 
dieser den Server dar, die abgesetzten Nutzniesser sind Clients.

Rolf M. schrieb:
> Genau, und in diesem Fall ist der angebotene Dienst der Zugriff auf
> Tastatur und Maus. Der Client will wissen, was der Benutzer eingibt, der
> Server stellt diese Information zur Verfügung.

Nein, im Fall Terminalserver oder X2co oder VNC oder RDP ist der 
angebotene Dienst das Bereitstellen von Rechenzeit auf dem Server in 
Form einer Desktop-Sitzung mit Bildschirm, Tastatur und Maus! Wer der 
Server ist sieht man klar daran wer diesen Dienst anbietet.

Wenn auf irgendeiner unteren Protokollschicht im Detail und ganz für 
sich allein betrachtet zufällig die Anfragen immer von der anderen Seite 
kommen und somit für diese abgegrenzte Unteraufgabe die Rollen 
Client/Server zufällig vertauscht sind stellt das noch lange nicht die 
Rollen von Client und Server im Gesamtzusammenhang dieses Dienstes und 
dieser Verbindung in Frage.

Bernd K. schrieb:
> stellt das noch lange nicht die
> Rollen von Client und Server im Gesamtzusammenhang dieses Dienstes und
> dieser Verbindung in Frage.

M.a.W: Was auf Netzwerkebene ein Server ist, kann auf Anwendungsebene 
ein Client sein, und umgekehrt. Und auf Anwendungsebene ist dann eben 
ein X-Server ein Client.

A. K. schrieb:
> M.a.W: Was auf Netzwerkebene ein Server ist, kann auf Anwendungsebene
> ein Client sein, und umgekehrt. Und auf Anwendungsebene ist dann eben
> ein X-Server ein Client.

Im Falle von Terminalserver ist sowohl aus Anwendungsebene als auch auf 
Netzwerkebene der Fall daß der Anwendungsserver auch der Netzwerkserver 
ist. Zum Beispiel ist es auf Netzwerkebene meist SSH über welches das 
abgewickelt wird, bei Windows ist es RDP und auch da ist der 
Anwendungsserver der Netzwerkserver. Auch die Namensgebung der 
beteiligten Softwarekomponenten lassen keinen Zweifel daran.

Implementierungsdetails der untergeordneten getunnelten Hilfsprotokolle 
dringen in keinster Weise nach außen in Erscheinung und müssen also 
weder dem Anwender noch dem Admin bekannt sein um zu verstehen wie es 
benutzt wird und wie er sein Netzwerk konfigurieren muss.

Bernd K. schrieb:
> Implementierungsdetails der untergeordneten getunnelten Hilfsprotokolle
> dringen in keinster Weise nach außen in Erscheinung und müssen also
> weder dem Anwender noch dem Admin bekannt sein um zu verstehen wie es
> benutzt wird und wie er sein Netzwerk konfigurieren muss.

Yep. Beim X11 wechseln Server und Client die Rollen, sobald man sie 
nicht mehr nativ über Netz betreibt, sondern über SSH. ;-)

A. K. schrieb:
> Beim X11 wechseln Server und Client die Rollen, sobald man sie
> nicht mehr nativ über Netz betreibt

Nein. Sobald man sie tunnelt ist es für das äußere Erscheinungsbild des 
Tunnels nicht mehr relevant was die im Innern desselben treiben.

Bernd K. schrieb:
>> Beim X11 wechseln Server und Client die Rollen, sobald man sie
>> nicht mehr nativ über Netz betreibt
>
> Nein. Sobald man sie tunnelt ist es für das äußere Erscheinungsbild des
> Tunnels nicht mehr relevant was die im Innern desselben treiben.

Ohne Tunnel (nativ) verbindet sich die X-Anwendung direkt mit dem 
Terminal. Hier ist also das Terminal der Server. Deshalb wird ein 
solches Terminal traditionell auch als X-Server bezeichnet. Diese 
Bezeichnung ist fixiert, es sei denn man schreibt die Geschichte der 
letzten Jahrzehnte um.

Mit Tunnel verbindet sich das Terminal mit dem Rechner, auf dem die 
Anwendung läuft. Das Terminal verbindet sich also mit einem SSH-Server. 
Die Anwendung verbindet sich per X-Protokoll dann mit dem Ende des 
SSH-Tunnels auf dem gleichen Rechner, auf dem die Anwendung läuft.

Die Frage, wer da nun Client und Server ist, abhängig davon wo genau man 
nun hinsieht, führt also direkt ins Absurde. Oder wie gut klingt es, 
wenn ein X-Server sich mit einem SSH-Server verbindet, damit der 
X-Client (die Anwendung) auf dem Server mit dem Client (dem Terminal) 
kommunizieren kann? ;-)

A. K. schrieb:
> Die Frage, wer da nun Client und Server ist, abhängig davon wo genau man
> nun hinsieht, führt also direkt ins Absurde.

Ein speziell ausgezeichneter Ort von all den Orten wo man hinsehen 
könnte wäre "das Gesamtgebilde von außen betrachtet"

Mittlerer Datentechniker schrieb:
> A. K. schrieb:
>> Bernd K. schrieb:
>>> Implementierungsdetails der untergeordneten getunnelten Hilfsprotokolle
>>> dringen in keinster Weise nach außen in Erscheinung und müssen also
>>> weder dem Anwender noch dem Admin bekannt sein um zu verstehen wie es
>>> benutzt wird und wie er sein Netzwerk konfigurieren muss.
>>
>> Yep. Beim X11 wechseln Server und Client die Rollen, sobald man sie
>> nicht mehr nativ über Netz betreibt, sondern über SSH. ;-)
>
> Zur weiteren Bespaßung:
> $ man xnest

Ich gehe mit und erhöhe um:
$ man nxproxy

Bernd K. schrieb:
> Rolf M. schrieb:
>> Genau, und in diesem Fall ist der angebotene Dienst der Zugriff auf
>> Tastatur und Maus. Der Client will wissen, was der Benutzer eingibt, der
>> Server stellt diese Information zur Verfügung.
>
> Nein, im Fall Terminalserver oder X2co oder VNC oder RDP

Sehr kreativ, wie du den Fall, auf den ich mich bezogen habe, aus dem 
Zitat gestrichen und einfach durch andere, zu denen meine Aussage nicht 
mehr passt, ersetzt hast.
Hier nochmal das Orignal:

c-hater schrieb:
> Joachim B. schrieb:
>
>> bei Synergy ist Server der PC der Maus und Tastatur besitzt
>> Client der es nutzt
>
> Ziemlich schwachsinnige Auffassung, finde ich.

Und darauf habe ich geantwortet.


Bernd K. schrieb:
> ... ist der angebotene Dienst das Bereitstellen von Rechenzeit auf dem
> Server in Form einer Desktop-Sitzung mit Bildschirm, Tastatur und Maus!

Ist er das? Würdest du die Aufgabe von VNC in der Bereitstellung von 
Rechenzeit sehen?

A. K. schrieb:
> Bernd K. schrieb:
>> stellt das noch lange nicht die
>> Rollen von Client und Server im Gesamtzusammenhang dieses Dienstes und
>> dieser Verbindung in Frage.
>
> M.a.W: Was auf Netzwerkebene ein Server ist, kann auf Anwendungsebene
> ein Client sein, und umgekehrt. Und auf Anwendungsebene ist dann eben
> ein X-Server ein Client.

Nein. Die Anwendung gibt dem X-Server Befehle zur Darstellung von 
graphischen Elementen, die dieser ausführt. Und sie gibt ihm Befehle, um 
Events abzuholen, die z.B. von Tastatur und Maus angekommen sind.

Was Client ist und was Server, bezieht sich übrigens für mich nicht 
unbedingt darauf, wer die Verbindung aufbaut, sondern darauf, wer die 
Befehle gibt (Client=Kunde) und wer sie ausführt (Server=Diener). Meist 
baut der Client die Verbindung auf, aber muss er nicht zwangsweise.

Bernd K. schrieb:
>> Zur weiteren Bespaßung:
>> $ man xnest
>
> Ich gehe mit und erhöhe um:
> $ man nxproxy

$ man xpra

Rolf M. schrieb:
> Bernd K. schrieb:
>> ... ist der angebotene Dienst das Bereitstellen von Rechenzeit auf dem
>> Server in Form einer Desktop-Sitzung mit Bildschirm, Tastatur und Maus!
>
> Ist er das? Würdest du die Aufgabe von VNC in der Bereitstellung von
> Rechenzeit sehen?

In letzter Konsequenz ja. Und um Deine Frage die Du dennoch gestellt 
hast vorweg zu nehmen fügte ich ja in weiser Voraussicht noch "in Form 
einer Desktop Sitzung" hinzu. Es stellt also die Möglichkeit der 
Benutzung einer entfernt ausgeführten Software bzw. Desktopumgebung zur 
Verfügung, also mit anderen Worten die Benutzung von an entferntem Ort 
befindlicher Rechenzeit zu ermöglichen. Genau das tut es.

Bernd K. schrieb:
> Rolf M. schrieb:
>> Bernd K. schrieb:
>>> ... ist der angebotene Dienst das Bereitstellen von Rechenzeit auf dem
>>> Server in Form einer Desktop-Sitzung mit Bildschirm, Tastatur und Maus!
>>
>> Ist er das? Würdest du die Aufgabe von VNC in der Bereitstellung von
>> Rechenzeit sehen?
>
> In letzter Konsequenz ja. Und um Deine Frage die Du dennoch gestellt
> hast vorweg zu nehmen fügte ich ja in weiser Voraussicht noch "in Form
> einer Desktop Sitzung" hinzu. Es stellt also die Möglichkeit der
> Benutzung einer entfernt ausgeführten Software bzw. Desktopumgebung zur
> Verfügung, also mit anderen Worten die Benutzung von an entferntem Ort
> befindlicher Rechenzeit zu ermöglichen. Genau das tut es.

Naja, für mich ist Client/Server eine Art der Kommunikation. Ich sehe 
den Zweck der Kommunikation bei VNC darin, Bildschirminhalte und 
Tastatur- und Mauseingaben zu übertragen und nicht in der Bereitstellung 
von Rechenzeit. Das macht das Betriebssystem des Rechners, nicht VNC.

Rolf M. schrieb:
> Ich sehe
> den Zweck der Kommunikation bei VNC darin, Bildschirminhalte und
> Tastatur- und Mauseingaben zu übertragen

Das selbe also wie RDP und X2Go: Die Möglichkeit mit lokaler Tastatur, 
Maus und Bildschirm über Programme auf einem entfernten Rechner zu 
verfügen. Das ist genau das was ich gesagt habe, nur mit anderen Worten.

Vielleicht liegt es daran wie man seine eigene Rolle vor dem Bildschirm 
begreift: Ich empfinde mich als aktiv Handelnden, der Computer reagiert 
auf meine Eingaben. Somit reagiert auch der entfernte Computer auf meine 
Eingaben und ich verfüge über ihn. Andere mögen es eher so empfinden daß 
sie vorwiegend konsumieren und auf Eingabeaufforderungen des Computers 
oder des entfernten Computers reagieren. Die einen benutzen den 
Computer, die anderen lassen sich von ihm benutzen, so mutieren sie vom 
Master zum Slave.

„... Ich empfinde mich als aktiv Handelnden, der Computer reagiert auf 
meine Eingaben. Somit reagiert auch der entfernte Computer auf meine 
Eingaben und ich verfüge über ihn. Andere mögen es eher so empfinden daß 
sie vorwiegend konsumieren und auf Eingabeaufforderungen des Computers 
oder des entfernten Computers reagieren. Die einen benutzen den 
Computer, die anderen lassen sich von ihm benutzen, so mutieren sie vom 
Master zum Slave.“

Nachdem nun die Gefühlswelt geklärt ist , würde ich den nächsten Schritt 
machen und überlegen ob dann auf dem entfernten und Deinen „aktiven“ 
Befehlen wartenden Computer - ein Betriebssystem wie Windows Deinen 
Ansprüchen wirklich genügt ;-)

Walter K. schrieb:
> Windows

Na endlich! hab schon gewartet wann der erste endlich den 
obligatorischen und immerwährenden W... vs L... Streit vom Zaun bricht. 
Hat ja lange genug gedauert!

Bernd K. schrieb:
> Walter K. schrieb:
> Windows
>
> Na endlich! hab schon gewartet wann der erste endlich den
> obligatorischen und immerwährenden W... vs L... Streit vom Zaun bricht.
> Hat ja lange genug gedauert!

Wieso L... ?

Ich empfehle MacOS oder FreeBSD oder openBSD - also unixoide 
Betriebssysteme!
Linux gehört da nicht wirklich dazu ;/)

Walter K. schrieb:
> Wieso L... ?

Mit ist das schon öfters aufgefallen., Es gibt inzwischen einige Leute, 
die so empfindlich auf Linux-vs-Windows-Threads reagieren, dass sie gar 
nicht merken, dass sie die ersten sind, die das erwähnen und das damit 
selbst erst zum Thema machen.