Headless YellowDog

[yellowdog-general at lists.terrasoftsolutions.com]

> I remember on Suns a long time ago that you could get cards 
> that had a video 
> and keyboard plug on them to do just what I was describing.  
> Tehn you coul 
> dhave two local people usin gthe box at once.

The beginnings of extreme programming? All the dweebs huddled around their
Sun, praying to its mighty CPU. That would be kind of cool, actually.
 
> > In your above example, you said "'display' and 'screen' can 
> be omitted" but
> > I think you meant system and screen. You have to have at 
> least display,
> > i.e., :1 or :0, the others will be inferred (localhost:0.0).
> 
> You are right, that should have been "system and screen"

Now if I can just get my wife to utter those words....(take notice,
Norberto).
 
> > Not exactly, because you have to make sure you are talking 
> about the right
> > scenario. In all cases, the client always connects to a VNC server
> > component. In the case of stand-alone vncserver, it has 
> already forked its
> > own X session, so it mediates between the X session and the 
> client. In the
> > case of an X session on the console using the VNC module, 
> the VNC module is
> > run under control of the X session, not the other way 
> around. This has
> > importance because of the way the screen is handled.
> 
> I find that a bit confusing.  How about this?
> 
> - The VNC viewer does connect to the VNC server (but not that 
> same way a X 
> client would connect to it).

Right, it connects using the VNC protocol.

> - The VNC server is Xvnc (vncserver is just a wrapper to make 
> it easier to 
> start).

Right.

> - The viewer talks directly with the virtual X server in the 
> stand alone case

No. The client *never* connects to the remote X session because the client
uses the VNC protocol to get its display information. It *has* to go through
mediation by some VNC component which has access to the X client information
(and the X server information in the case of the X server module). That's
the translator between X client/server conversations and VNC client/server
network sessions.

> - The viewer talks directly with the vnc X module (which is 
> part of the 
> non-virtual X server) when using that feature, but this looks 
> the same to the 
> viewer.

Yes.

> - The viewer (assuming it is an X application) makes another 
> connection to the 
> X server it will use for a display.

Yes.

> > On Linux, the typical VNC client is an X client. That is 
> not the case on
> > other platforms. You don't need to run *another* X server to use the
> > client, though. You can just run it in the existing X session.
> 
> True, but not relevant to the original question asking about 
> displaying the 
> VNC viewer in another virtual console.  For that you need 
> another X server 
> for the VNC viewer's display.

I think I understand (with regards to how these answers came about). This
was in the context of him trying to get his second session running.

But on a given session, I can run five vncviewers if I want. I can control
five different machines with five different viewers all running in one X
session. Certainly, far off in network land, there must be five VNC servers
somewhere for me to control. They do not all necessarily need to be X
servers.

vncviewer eenie &
vncviewer meenie &
vncviewer miney &
vncviewer moe &

and I'll get four viewers all running on my desktop asking me for passwords.
Then they'll open and I can just minimize and switch around as I need them.
We're just talking about running the client here, right?

I agree, for ease of use, that would be a cool way to use them, but for
beginners, I think this is way to confusing.