On Sat, Dec 27, 2008 at 12:21:49PM -0800, Roman Shaposhnik wrote:
True. But why that should be a problem in practice? If the process
belongs to a user X that means user X has control over it. Thus the
behavior of accidental consumption of an fd that was meant to be consumed
by some other
Knowing *who* made the change is often even more useful than the change comment.
uriel
On Tue, Dec 30, 2008 at 2:48 AM, Charles Forsyth fors...@terzarima.net wrote:
i've rarely found per-change histories to be any more useful than
most other comments, i'm afraid.
And that meant that math
Knowing *who* made the change is often even more useful than the change
comment.
yes. i use ls -lm on our trees, but that might not work on less direct things
like sources.
On Tue, Dec 30, 2008 at 2:22 AM, Nathaniel W Filardo n...@cs.jhu.edu wrote:
If #s can be virtualized -- ala srv^2 or devcapsrv or something else -- then
the system is one step closer to supporting the above. There is some
machinery for sealing off #p that I do not recall in full detail but
If one buys this argument, then namespaces are not valid security constructs
they are not security constructs at all. though ftpd and a few friends
use rfork(2) to create a pgrp that doesn't allow attaches. very simple
and effictive, but probablly not strong security.
either, and Plan 9
On Tue, Dec 30, 2008 at 4:06 PM, C H Forsyth fors...@vitanuova.com wrote:
Knowing *who* made the change is often even more useful than the change
comment.
yes. i use ls -lm on our trees, but that might not work on less direct things
like sources.
It would work if the development trees were
http://code.google.com/hosting/createProject
On Tue, Dec 30, 2008 at 12:31 PM, Uriel urie...@gmail.com wrote:
On Tue, Dec 30, 2008 at 4:06 PM, C H Forsyth fors...@vitanuova.com wrote:
Knowing *who* made the change is often even more useful than the change
comment.
yes. i use ls -lm on our
