Quoting Eygene Ryabinkin <[EMAIL PROTECTED]>:
> *) New function OPENSSL_cleanse(), which is used to cleanse a section of
>memory from it's contents. This is done with a counter that will
>place alternating values in each byte. This can be used to solve
>two issues: 1) the removal of
Quoting Kris Kennaway <[EMAIL PROTECTED]>:
> Yes, there is no possibility of ULE 2.0 being merged to 6.x. Use it in
> 6.x if you dare, just don't complain to us if it breaks your system :-)
All right, I won't :-)
> i.e. if at any point you start experiencing problems, do not report them
> until
Quoting Xin LI <[EMAIL PROTECTED]>:
> Do NOT use ULE on 6.x. ULE has been revamped heavily on 7.0 and the
> version on 6.x is old, and is known to contain some bugs.
Is it particular to 6.x *SMP* systems ?
I've been using 6.3-R with ULE for about a fortnight without any trouble (on a
pentium4-m
Quoting Julian Elischer <[EMAIL PROTECTED]>:
> but be warned that th at book was written part way through the SMP
> rewrite so a lot has changed... Dr McKusick said the words "Next
> edition" the other day but I think it's still just a glimmer in his eye.
I for one am _really_ looking forward to
Quoting Fernando Apesteguía <[EMAIL PROTECTED]>:
> Maybe a mix of both could be good: use the linxprocfs when it is
> almost straightforward (in fact I could run the app, just changing few
> lines) and sysctl when the linprocfs doesn't provide the information
> that I need.
And I just made a fool
Quoting Fernando Apesteguía <[EMAIL PROTECTED]>:
> Maybe a mix of both could be good: use the linxprocfs when it is
> almost straightforward (in fact I could run the app, just changing few
> lines) and sysctl when the linprocfs doesn't provide the information
> that I need.
Wouldn't the opposite
Quoting Ivan Voras <[EMAIL PROTECTED]>:
> For general information on the FreeBSD kernel see the book "Design and
> implementation of the FreeBSD operating system",
Will this edition be updated, or is it still relevant with the coming of 7.0 ?
It was written with 5.0 in mind, and considerable prog
Quoting Stefan Sperling <[EMAIL PROTECTED]>:
>flags=
> mtu 1500
>
> Would that be better?
IMHO, too much info packed in here, making reading difficult.
> Has anyone got better ideas?
What if there was a single line added, right after status for instance:
wol: (magic) unicast link multicast
Hello,
Quoting Robert Watson <[EMAIL PROTECTED]>:
> No problem -- just to be clear: in 7, users can still choose between
> libpthread (m:n) and libthr (1:1), but the default is now libthr rather than
> libpthread, as libthr seemed to perform better in most if not all workloads
> of
> interest.
I
9 matches
Mail list logo
