[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Child killing UI (was Re: Reliability of RPC services)
From: |
Pierre THIERRY |
Subject: |
Re: Child killing UI (was Re: Reliability of RPC services) |
Date: |
Fri, 28 Apr 2006 14:24:42 +0200 |
User-agent: |
Mutt/1.5.11+cvs20060403 |
Scribit Bas Wijnen dies 28/04/2006 hora 11:34:
> > Yeah, but as I said, in some systems that encapsulation is obviously
> > broken.
> So you are suggesting we should build a broken system, because others
> have done so as well? I don't think I like that approach. ;-)
I said I'm not so sure we break encapsulation here. If you consider that
spawning a process is clearly an action you ask the outside world (like
it is in POSIX), then it's not breaking encapsulation.
In Coyotos and HurdNG, where spawning a process could be no more than
giving some of your own resources ot something you start yourself, then
it would break encapsulation.
It's a matter of paradigm and semantic.
> For example, I think it is likely that a user's session manager will
> not allow listing of its processes (at least not to anyone except the
> user). That means that others (including the system administrator)
> cannot see what programs the user is running. And that's a good thing,
> privacy-wise.
I agree. I don't want my mom, connected with SSH to her account on my
system, know I'm executing 'xine ~/Porn/hotbabes.mpg' or a friend of
mine, connected as I am on a GNU's or Debian's infrastructure's system,
know I'm executing 'gvim software-patents-directive-take2.tex'. ;-)
That has always bothered me, when I'm doing some distant administration
work on someone else's system, to see what he is doing when I do some
top or ps.
Privately,
Nowhere man
--
address@hidden
OpenPGP 0xD9D50D8A
signature.asc
Description: Digital signature
- Escaping it's parents (was Re: Process Management (was: Re: Reliability of RPC services)), (continued)
- Child killing UI (was Re: Reliability of RPC services), Pierre THIERRY, 2006/04/27
- Re: Child killing UI (was Re: Reliability of RPC services), Marcus Brinkmann, 2006/04/27
- Re: Child killing UI (was Re: Reliability of RPC services), Pierre THIERRY, 2006/04/27
- Re: Child killing UI (was Re: Reliability of RPC services), Marcus Brinkmann, 2006/04/27
- Re: Child killing UI (was Re: Reliability of RPC services), Pierre THIERRY, 2006/04/28
- Re: Child killing UI (was Re: Reliability of RPC services), Bas Wijnen, 2006/04/28
- Re: Child killing UI (was Re: Reliability of RPC services), Marcus Brinkmann, 2006/04/28
- Re: Child killing UI (was Re: Reliability of RPC services), Bas Wijnen, 2006/04/28
- Re: Child killing UI (was Re: Reliability of RPC services),
Pierre THIERRY <=
- Re: Child killing UI (was Re: Reliability of RPC services), Jonathan S. Shapiro, 2006/04/28
- Re: Reliability of RPC services, Bas Wijnen, 2006/04/25
- Re: Reliability of RPC services, Bas Wijnen, 2006/04/25
- Re: Reliability of RPC services, Jonathan S. Shapiro, 2006/04/25
- Re: Reliability of RPC services, Bas Wijnen, 2006/04/25
- Re: Reliability of RPC services, Tom Bachmann, 2006/04/25
- Re: Reliability of RPC services, Jonathan S. Shapiro, 2006/04/25
- Re: Reliability of RPC services, Bas Wijnen, 2006/04/25
- Re: Reliability of RPC services, Bas Wijnen, 2006/04/25
- Re: Reliability of RPC services, Marcus Brinkmann, 2006/04/25