[buug] hello

[Ian Zimmerman]

Karen> So paraphrasing Wiki, a daemon is a process whose parent has
Karen> terminated (possibly by its own hand) and so is adopted by init,
Karen> which is PID 1, and generally runs in background. Is that right?

Not quite.  A nondaemon process can very well be orphaned.  The real
essence of being daemon is what I said in the other subthread: not
having a "controlling" terminal.  That being a terminal whose
disconnection (in some fashion, physical or logical) causes the process
to die, and from which it can (if it is in the foreground) receive INT
and QUIT signals.

That last clause also touches on the foreground/background divide.
Technically, only processes with a controlling terminal can be either of
these.  Daemons are in a separate category even farther on the way to
netherworld.

Karen> When I log in as karenh rather than root, I see that "login [pam]
Karen> (login)" is PID 1115 under root, and then -sh is PID 1116 under
Karen> karenh, so I guess that login made me a shell.

Hmm.  You should do a "ps w" in that situation to see who is the shell's
parent.  It is not necessarily the process with the immediately
preceding ID.  I suspect the login process is just waiting for a
password to be typed on another virtual terminal.

Classically, login just *exec*s the shell, it doesn't fork a new
process.  Do you understand the difference?

It is possible that FreeBSD now does things differently.  I'm very much
a Linux guy so I wouldn't know.

Karen> Now I remember what I wanted to ask about the history of X
Karen> Window. From a little bit of reading, it seemed like the concept
Karen> of server and client were reversed from how we think of client
Karen> and server software now. If I understand, there are three kinds
Karen> of X pieces.  X Server, X Window Manager, X clients.  Imagine we
Karen> have three computers. One is in Boston, Mass, and two are in
Karen> Berkeley, CA, It was originally envisioned that the X Server
Karen> would run in Berkeley and the X Window Manager would run in
Karen> Boston?

The window manager is just another client, although one that does things
clients normally don't.  So, if you were working on a machine in Boston
and running client programs on it, the WM would probably be there too.
And yes, this was very much anticipated by the design (although this
particular scenario would be both slow and insecure, unless you go
through a tunnel).

-- 
Ian Zimmerman <itz at buug.org>
gpg public key: 1024D/C6FF61AD 
fingerprint: 66DC D68F 5C1B 4D71 2EE5  BD03 8A00 786C C6FF 61AD
Ham is for reading, not for eating.