VNC-Server und Clients: Ein kleiner Überblick

Ich habe mir vor kurzem einen Überblick verschafft, was mir Linux und Debian zum Thema Virtual Network Computing, kurz VNC, bieten können. Insbesondere habe ich mit einem älteren Laptop der Klasse Pentium II, 128 MB und einem Core Duo mit 4 GB RAM experimentiert.
Interessant fand ich auf den ersten Blick directvnc, ein VNC-Client der sich mit dem Framebuffer zufrieden gibt, um den entfernten Desktop anzuzeigen und dabei auf DirectFB zurückgreift. Als erstes habe ich mich mit dem Core Duo verbunden, wo Vino als VNC-Server mit Debian Testing und Gnome 3 lief.
Die erste Hürde über die man stolpern kann sind die Zugriffsrechte, wenn man directvnc als normaler Benutzer startet. Man benötigt auf jeden Fall die Kontrolle über /dev/tty0 und /dev/mouse/ oder /dev/psaux, ansonsten erhält man einen Fehler wie:

Error opening /dev/tty0
--> Permission denied

Die Rechte lassen sich mit chown temporär ändern. Die dauerhafte und "saubere" Methode scheint aber zu sein, udev Regeln zu erstellen, so dass schon beim Systemstart in die Konsole alles funktioniert. Wenn jemand schon öfter mit directvnc gearbeitet hat und eine noch bessere Lösung für das Problem kennt, immer her damit. 😉
Die Performance von directvnc war ausgezeichnet, selbst auf dem Thinkpad von 1998 konnte ich den großen Rechner problemlos kontrollieren. Leider musste ich bei Vino mit der Einschränkung leben, dass ich die Geometrie der Anzeige nicht an meine 1024x768 Pixel Auflösung anpassen konnte.
Wenn man mehr Kontrolle braucht ist x11vnc kein schlechter VNC-Server, da sich hier zahlreiche Optionen direkt über die Kommandozeile steuern lassen und auch die Anzeige des Desktops ist schnell mit dem Attribut -geometry 1024x768 geändert, wonach mein Gnome 3 Desktop im Framebuffer des Thinkpad 600 vollständig dargestellt wurde.
Außerdem habe ich mir noch tightvncserver angesehen, dessen großer Vorteil die effiziente Datenkodierung ist, mit der sich die Performance bei Verbindungen über das Internet und bei schmaler Bandbreite verbessern lässt. Zum Betrieb ist nicht einmal eine laufende Desktopumgebung notwendig, weswegen sich tightvncserver auch mehr für ein kollaboratives Projekt auf einem entfernten Rechner eignet als für ein Hilfsmittel bei Rechnerproblemen. Der Client als Gegenstück heißt xtightvncviewer.
Wer mit aptitude search vnc nach einer groben Idee zum Thema Virtual Network Computing fahndet, findet auch noch vnc4server und xvnc4viewer, dazu auch noch in Java geschriebene Clients und GTK-Widgets, auf die ich aber noch keinen Blick geworfen habe.
Als grafische Oberfläche für einen VNC-Client gefiel mir bisher Remmina sehr gut, weil man hier auch gleich mehrere Protokolle dank verschiedener Plugins zur Auswahl angeboten bekommt und nicht nur mit VNC sich zu einem entfernten Rechner verbinden kann. Die Gnome 3 Lösung Vinagre ist mir hingegen zu spartanisch.
Mein absoluter Favorit war aber linuxvnc, ein kleiner VNC-Server, der Eingaben und Aktionen in TTY-Konsolen übertragen kann. Perfekt geeignet, wenn man jemanden bei der "Arbeit" in der Konsole beobachten oder einfach nur beim Spielen von Dungeon Crawl Stone Soup zusehen möchte. 🙂
Ich schätze man könnte Tage damit verbringen, über die Vor- und Nachteile der einzelnen Varianten zu berichten. Zum Schluss bleibt aber, dass ein VNC-Client oder Server immer noch ein guter Verwendungszweck für einen alten Computer ist.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.