other than as a server to let a client connect to, to become the virtual display for a virtual instance of an X server (such as, but not limited to) Xvnc, what uses would a Linux user or Linux system administrator have for running (another) VNC server, either for herself, or for public use?

if you have ever run a VNC server for any reason other than to run a virtual X or to just try it out to learn more about it, what would such a reason be?

I've played with VNC's on my home network to learn about them, but, when it comes usage in the Enterprise, I would say it's to allow someone who has a compelling need to access a remote computer via a GUI interface to do so when that need arises.

The key word there is "compelling."

I remember the first time I used a VNC. At the time I was working tech support for a company that manufactured a very specialized form of security software and hardware. My employer sold through authorized dealers and we in support supported the authorized dealers, usually in trouble-shooting problems at end user sites.

Under the auspices of an authorized dealer rep, an end user set me up with a VNC to the computer that was running our product so I could help diagnose and fix the problem they were having. It was a long time ago and I don't remember precisely what the problem was, but I do remember that, thanks to the VNC connection, the dealer rep and I were able to figure it out and fix it.

This was under Windows, not Linux, but I think it pretty much encapsulates what VNC's are for.

Just my opinion.

using gui with an rpi ? RPi has no display, but I wanted to use some gui apps. But actually I don't understand. Vnc is used as a remote display, what else can it be?

+1. Remote access. I used/use it to access my home server which runs headless. Same now and then with other RPIs. Most times I just SSH into the systems, but sometimes using a GUI tool is easier to use.

As a rule, I access remote systems via SSH. If I want a GUI application such as a file manager then I will add the -Y option when connecting via SSH.
My one use case for VNC is a media server running Kodi. Kodi over a SSH connection is like wading through treacle. Kodi via VNC tunnelled through SSH is acceptable.

VNC serves the same purpose as Windows Terminal Server, but in a different way and shoving off the security question to other application (generally SSH/SSL). Anywhere you need a tool to provide a GUI session into a remote server and network where Terminal Server would do, VNC is another and far more generally compatible (although somewhat less efficient) option.

the summary i make out of this, so far, is the VNC is generally used as a tool to access a system console of some kind, be it software (i think of X Windows and Microsoft Windows both as software) or hardware. i have been thinking of doing something different.

several years ago i was thinking of an application which seemed better to do in VNC due to having parts of the display continuously updated several times a second. today that might be better done as a live video.

a few weeks ago i started thinking about something new. this would be a VNC switcher. it would have one client connect to it and have a custom keyboard sequence to switch among VNC servers. raw byte stream switching would not work with any protocol i can think of. my thought is that VNC is simple enough to do switching with it. i currently switch between many users on my laptop to have many ongoing contexts of work in wider windows. for example, i am typing this in on a nearly full screen web browser in a username dedicated to many forums i access (user "forums"). with a switcher that can connect to other hosts with a different port number for each user, or maybe some kind of session trunking with SCTP. other "server" applications or devices could be used, as well.

would a switch be considered its own application or just a VNC tool?

using a broad meaning for "display" that pretty much covers it all. i once thought of it as a less complicated way to transmit less efficient "video" display content being rapidly calculated by software.

You would need to define your terms very loosely to make that description fit.
CONSOLE has a specific meaning, and neither Terminal Services nor VNC gets you to the system console: they get you to a exported GUI window. In the case of VNC (And Terminal Service in server mode) a window created just for that session.

I see no purpose in a switcher, since when using vnc clients I often have multiple sessions open to multiple servers and switch between them using my normal desktop tools. If that application would have utility for you, then build it. IT might be useful for many others as well.

Why would you care if you called it an application or a VNC tool? That makes no functional or technical difference. It might to those who have more to contribute to community politics than to community code and resources, but that is really not something that should make your decisions for you.

Hi Skaperen,

Running a VNC server on Linux can be useful for remote desktop access, headless server management, accessing GUI applications, and training/support. Personally, I have used it for remote desktop access and headless server management.

Have a nice day.

" If I want a GUI application such as a file manager then I will add the -Y option when connecting via SSH."

May be typo to mean -X?

Took me a while to decide on that too.

what if all those sessions were (nearly) full screen in size? would you minimize all but one, much like switching workspaces does? what if many of the places to make a GUI connection to were on different hosts? at what level would you make the network connections?

That would be the normal case, yes. First, I see no problem in having them all full sized on one behavior on my desktops. screen as long as when I select one that one jumps to the front. That is normal behavior on my desktops. Second, there is nothing wrong with one per workspace, and my machines can support a LOT of workspaces! ALL of my sessions are to different hosts. I am not sure what you mean. Each VNC session makes a unique connection when it is started. If you have two to a single host you can put them all in a single ssh/ssl tunnel, but that is a special case: and in that case the network connection is made when you open that first session and the tunnel gets established.

actually I would not make several connections from the same client to the server, that is not that efficient. But anyway, there can be a case...

i am trying to understand how different LQ users set this up (then how is the reaction to how i would set it up). some means to "switch" has to happen. i see many possible ways.

i currently do it by each session running on a separate X server on my laptop and directing LightDM to switch via "dm-tool switch-to-user $user" where $user is the unique user name for each session. the switch happens via "chvt $n" or the kernel syscall it does. the steps at this point are unknown to me but the currently active X server becomes inactive and the appropriate X server becomes active. the new X server puts its last buffer back on the physical display and sends expose requests to all its X clients.

i want to change this so that each session that runs X (most, usually all) with something like Xvnc. it would run like an X server listening both for X clients and one VNC client. on some machine (i could do this on my laptop as one option) i would run my VNC switcher. if this runs across any unsafe network it will need an encrypted path such as SSH. doing SSH everywhere might be simpler to design. the switcher will listen for incoming VNC clients, authenticate them as appropriate, and pre-connect certain sessions. the user on those VNC clients can then request session connections and disconnections as desired and switch to which session to be active. on my laptop i would run a VNC client (most likely under X or Wayland). it would do the VNC connection to VNC switcher and go from there.

i am thinking to make my switcher require SSH for both incoming (from its one client) and outgoing (to each session). so each session will have to be running some form of an SSH layer, a VNC layer and an application layer (XVNC or WaylandVNC or whatever). this would avoid having to track where there is no SSH by having it always present.

so why would i do this?

as i start to deploy things i am developing out to the cloud, i would have many new sessions to deal with. VNC would make this easier. but i have found many clients that do VNC are awkward as clients and even more so for session switching. nothing integrates any SSH security, yet, so that is even more awkwardness. i could hack some existing client to add all this at the user client level. but i find it to be more awkward to hack around an existing design (it can change in the future and forking has all the same hassle of a new project). i might as well do my own design. i feel a switching server is easier for me and still leaves it possible for others to have their client on Microsoft Windows (they could run the switcher in a cloud instance).