What is the closest approximation to a Solaris door call in FreeBSD?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
: Unfortunately, when you take setuid programs into account, it gets
: far less clear: Reasonable cases could be made for having the owner
: either the real or effective UID.
The case for effective seems quite clear to me, but
I can't see the case for real UID. What is it?
To Unsubscribe: se
Quoth [EMAIL PROTECTED]:
:
: >The problem is that 'fsck -py' ignores the 'p' and will fsck every time,
: >even if it's unneeded. This takes ages for me. I believe I submitted a PR
: >with a 'fix' to fsck.
:
: According to the man page, fsck -y and fsck -p are two distincts commands.
Here's a pa
> vs> I whacked mount and umount into shape for using an option "user" in
>[snip]
> vs> http://www-i2.informatik.rwth-aachen.de/~stolz/mount.diff
> vs> http://www-i2.informatik.rwth-aachen.de/~stolz/umount.diff.
> You can allow non-root users to mount and unmount devices if
> the sysctl varia
> vs> I whacked mount and umount into shape for using an option "user" in
>[snip]
> vs> http://www-i2.informatik.rwth-aachen.de/~stolz/mount.diff
> vs> http://www-i2.informatik.rwth-aachen.de/~stolz/umount.diff.
> You can allow non-root users to mount and unmount devices if
> the sysctl vari
: From: "Daniel C. Sobral"
: Default for FreeBSD is async [meta]data and sync data. Sync and Async
: modes go full sync/async for both metadata and data...
: > Just a btw, you seem to be able to set sync and async on a filesystem
: > at the same time. What gives?
: Beats me.
Logically, then,
: From: "Daniel C. Sobral" <[EMAIL PROTECTED]>
: Default for FreeBSD is async [meta]data and sync data. Sync and Async
: modes go full sync/async for both metadata and data...
: > Just a btw, you seem to be able to set sync and async on a filesystem
: > at the same time. What gives?
: Beats me
: And what happens accross NIS domains?
UID = SSN? Oops -- it's too late for RFC 666. Besides, that's Bill, not Steve.
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
: And what happens accross NIS domains?
UID = SSN? Oops -- it's too late for RFC 666. Besides, that's Bill, not Steve.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
If there were a mechanism whereby one could opt out of the SIGKILL,
most if not all of the complaints would go away. SIGDANGER would
suffice, but even a rude hack would do in a pinch, such as the one
included below (untested). If you mmap real disk instead of sbrk'ing,
and use this procfs contro
If there were a mechanism whereby one could opt out of the SIGKILL,
most if not all of the complaints would go away. SIGDANGER would
suffice, but even a rude hack would do in a pinch, such as the one
included below (untested). If you mmap real disk instead of sbrk'ing,
and use this procfs contr
Lizard has a tetris game built in for those long waits...
Now THAT is cool.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Lizard has a tetris game built in for those long waits...
Now THAT is cool.
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Peanut comment: As long as you get all the reviews done before a snap,
I don't see any reason not to pipeline the process by letting commits
procede before review. They can be backed out/revised, after all. In
commercial projects this is usually considered bad when you have
external dependents,
14 matches
Mail list logo
