> On Friday 21 August 2020 at 22:23:16, Hendrik Boom wrote:
>
> > Is there a way for process to ask about its own memory usage?
>
> Assuming the process knows its own PD, try the 24th value in /proc/PID/stat
... or just /proc/self/stat
regards
marc
___
> I understand the security advantages of using zoom on a laptop not
> much used for anything else. I suppose the sercurity conern is files
> being accessible to intruders. Someone made the interesting suggestion
> of settin up a new account just for zoom.
The concern about using any gratis com
> The surviving Devuan core team members will take zero or
> more steps to prove Devuan trustworthy and sysadmins will
> each decide for themselves or with their lawyers whether
> they can continue to use Devuan.
Weirdly enough I trust devuan a bit more after this incident:
- I now know that the
> > > > > - Devuan Beowulf will be the next testing, and will follow Ascii
> > > >
> > > > You do realize issues when talking about this on Slashdot, naked and
> > > > petrified?
> > >
> > > I am evidently missing something, but I can't see what.
> >
> > That particular release might be deemed p
> For months, literally, the supervision list
> has been wringing its hands over the very real problem that, for process
> dependency purposes, one must know that process X is not only running,
> but ready to handle its business. Knowing process X is running isn't
> sufficent, because some processe
Hello
> * I then argue that in the current world, autocompletion is not
> reliable, because since it does not stat(), it cannot hide filenames
> the user cannot execute, such as a 0644 file. What your autocompletion
> is currently printing is an approximation of the programs you can run,
> not an
Hello again
> >> 0700 for root-only binaries would hide them from your shell's
> >> autocompletion.
> >
> >Which would be lots of stat() system calls.
>
> If a shell doesn't make them, then it doesn't verify that a file is
> executable either. (I just checked with zsh: it doesn't indeed.)
> Su
Me again
So I am going to quote Laurent a bit out of order, sorry about
that, but it seems the best way to explain things:
> >Now as for other assertions in this thread that the FHS itself is
> >obsolete and violations of it should not be considered a bad thing, just
> >no.
>
> I don't think an
> On 30/04/2015 22:35, Joerg Reisenweber wrote:
> >exactly this PATH issue is what I expect and appreciate here: I do NOT
> >expect
> >command autocompletion of normal user to get confused by command names that
> >are not supposed to even be in user's PATH
>
> 0700 for root-only binaries would h
>
> I used to work for multiple ISPs, and I can tell you a few things for what
> little they are worth. The source and destination IPs are tagged on each
> packet sent over Internet. If you are tracking someone from a browser, which
> is a higher level protocol than DNS, you have no need to cor
10 matches
Mail list logo