In message [EMAIL PROTECTED] Brian
Beattie writes:
: I have an older 486 system, running 3.4R that has a cmos clock that seems
: to be unwilling to accept years out side the range 94-99. The bios seems
: willing to set dates between 1994-2099, but after reboot any year not
: between 94-99 is
struct seminfo seminfo = {
SEMMAP, /* # of entries in semaphore map */
SEMMNI, /* # of semaphore identifiers */
SEMMNS, /* # of semaphores in system */
SEMMNU, /* # of undo structures in system */
SEMMNI is the number of semaphore ids, i.e., the number of times you
can call 'semget()' without deleting any semaphores. SEMMNS is the
actual number of semaphores in the system, which should be = SEMMNI.
Of course, you can ask 'semget()' to give you up to SEMMSL semaphores
on each call, so
On Sun, 13 Feb 2000, Warner Losh wrote:
In message [EMAIL PROTECTED] Brian
Beattie writes:
: I have an older 486 system, running 3.4R that has a cmos clock that seems
: to be unwilling to accept years out side the range 94-99. The bios seems
: willing to set dates between 1994-2099, but
Is there a sysctl for FreeBSD which prevents execution in
the stack segment? (ie. to prevent attacks from getting root)
I'm using 3.4R.
--
Dru Nelson Director of Network Operations
http://www.egroups.com/ Voice: 415-546-2740
To Unsubscribe: send
On Sun, Feb 13, 2000 at 01:29:46PM -0800, Dru Nelson wrote:
Is there a sysctl for FreeBSD which prevents execution in
the stack segment? (ie. to prevent attacks from getting root)
I'm using 3.4R.
Atsuo Ohki sent a mail to -hackers on Feb 05 with a kernel-patch
doing exactly this.
The
Greetings !
I have a question, I need to write a small program that sets the default
gw. It is written in C and I have looked at several way to do it. One
way is using ioctl but that way seems a little "old" and not very well
documented. Here is a simple snippet of my code, now when I run it I
On Fri, Feb 11, 2000 at 03:59:49PM -0500, Jim Mercer wrote:
i hear that there are some patches which might fix some serious packet loss
problems with the de driver in 100mbps fullduplex.
i am running 3.4 (synced to stable via cvsup).
with the mailing list archives down, i can't do my
Hi,
I was thinking (I know, I know, I shouldn't do that, it's bad for me
;)...
Since we now have 3000+ ports, what are the chances of getting a special
"FreeBSD Ports Distfiles" CD-ROM subscription set, which would just
contain the distfiles? Since this set would be fairly low maintainance
It's something we've been considering. :)
Hi,
I was thinking (I know, I know, I shouldn't do that, it's bad for me
;)...
Since we now have 3000+ ports, what are the chances of getting a special
"FreeBSD Ports Distfiles" CD-ROM subscription set, which would just
contain the distfiles?
On Sun, Feb 13, 2000 at 06:05:55PM -0500, Crist J. Clark wrote:
with the mailing list archives down, i can't do my own search, but i was
hoping someone on these lists could give me some pointers.
Try www.deja.com and search the muc.lists.freebsd.* hierarchy.
i'll poke about there.
Just
Jim Mercer wrote:
On Sun, Feb 13, 2000 at 06:05:55PM -0500, Crist J. Clark wrote:
Just one question I always ask people trying to get things working at
full-duplex, is the card plugged into a hub at the other end?
actually, we started with cross over cables, and then suspecting them,
Hello,
I have a problem with shared libraries that need a
shared library by themselves (FreeBSD-3.4-STABLE):
imagine a shared library `libfoo.so'. This library depends
on the X11 lib and therefore has a `libX11.so.6' NEEDED entry.
On this system `libX11.so.6' was installed into '/vol/X11/lib',
howdy!
i was wondering if FreeBSD had a kind of like DLL capability?
i'd like to be able to do something as follows:
// ... construct char *fileName
moduleHandle = loadCodeModule(fileName);
(char *)(*fn char *) myfn; // ii'm pretty sure i screwed that
14 matches
Mail list logo
