On Sat, Feb 01, 2003 at 23:06:50 -0800, Kris Kennaway wrote:
> FreeBSD's rand() implementation has been broken for the past 23
> months, since the following commit:
> i.e. the first value returned from rand() is correlated with the seed
> given to srand(). This is a big problem unless your seed i
On Sat, Feb 01, 2003 at 06:30:45PM +0100, [EMAIL PROTECTED] wrote:
> In message <[EMAIL PROTECTED]>, Christoph Kuk
> ulies writes:
> >
> >I bought new hardware for a server today, an ASUS P4S8X with
> >an 1.8 GHZ P4 CPU, nothing fancy I would say, which has an
> >onboard RAID controller (Promise) b
On Sun, Feb 02, 2003 at 12:04:22PM +0300, Andrey A. Chernov wrote:
> Yes, first value correlation is there, but old formulae have even worse
> effect "The random sequences do not vary much with the seed", as source
> file comments and whole discussion about old RNG bad effects shown. I.e.
> for
After reading src/UPDATING and attempting to follow the directions to
upgrade from 4.7-RELEASE to -CURRENT, I'm having some difficulty, after
successfully building world and building and installing the kernel, I
attempted to make install in src/sys/boot. I'm getting the following error:
((inap
On Sun, Feb 02, 2003 at 01:11:06 -0800, Kris Kennaway wrote:
>
> Another problem (noticed by tjr) is that once the sequence hits '0' it
> jumps to INT_MAX and stays there forever. For example, seeding with
> srand(0) produces nothing but INT_MAX from rand().
>
> It looks like a lot more validati
In message <[EMAIL PROTECTED]>, "Andrey A. Chernov" writes:
>
>--SUOF0GtieIMvvwua
>Content-Type: text/plain; charset=us-ascii
>Content-Disposition: inline
>Content-Transfer-Encoding: quoted-printable
>
>On Sun, Feb 02, 2003 at 01:11:06 -0800, Kris Kennaway wrote:
>>=20
>> Another problem (noticed b
[EMAIL PROTECTED] writes:
> >BTW, note that new formulae also used in the kernel (by BSD developers)
> >and taken from there - libkern/random.c - so all you say is true there
> >too.
>
> It should be nuked from the kernel, and arc4random() used instead.
I agree. If no-one objects, I'll do this?
On Sun, Feb 02, 2003 at 01:11:06 -0800, Kris Kennaway wrote:
>
> Another problem (noticed by tjr) is that once the sequence hits '0' it
> jumps to INT_MAX and stays there forever. For example, seeding with
> srand(0) produces nothing but INT_MAX from rand().
>
> It looks like a lot more validati
On Thu, 30 Jan 2003 14:41:59 +0900, Hidetoshi Shimokawa wrote
> Do you get timeout only for sbp0:0:0?
> Is the other drive still working?
>
> I have no problem with concurrent accesses with `iozone -s 102400m -r
> 1024k`.
...
> try some of the following:
>
> - fwcontorl -g 20
> - sysctl
Thus spake Andrey A. Chernov <[EMAIL PROTECTED]>:
> Yes, first value correlation is there, but old formulae have even worse
> effect "The random sequences do not vary much with the seed", as source
> file comments and whole discussion about old RNG bad effects shown. I.e.
> for different time+PID
--- Begin Message ---
This is _only_ about the driver for the DiskOnChip devices from
M-Systems. This does not affect any other device. If you have
never seen a /dev/fla0 mounted on your system, you don't need to
read the rest.
I realize that there are users of the DiskOnChip hardware out there
--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
At Sun, 2 Feb 2003 13:28:33 +0200,
mike wrote:
> > try some of the following:
> >
> > - fwcontorl -g 20
> > - sysctl hw.firewire.sbp.max_speed=0
> > - change SBP_QUEUE_LEN in sbp.c to 1 and rebuld module.
> > - sysctl machdep.cpu_idle_hlt=0
> > - sysctl debug.sbp_debug=1 and send me a dmesg.
On Sun, Feb 02, 2003 at 03:48:17 -0800, David Schultz wrote:
> Specifically, rand() isn't very interesting in the lower-order
> bits, and it spectacularly fails nearly all of Marsaglia's
It seems that you speak about old formulae, we use new one (which
intended to fix low-ordered bits), see our
On Sun, Feb 02, 2003 at 13:26:21 +0300, Andrey A. Chernov wrote:
> Workaround I find so far is something like that
>
> #define MASK 123459876
I found nothing better. Here is fix for 0 problem I plan to commit:
--- stdlib/rand.c.old Sat Jan 4 20:39:19 2003
+++ stdlib/rand.c Sun Feb 2 1
On Sun, 2 Feb 2003, Andrey A. Chernov wrote:
> On Sun, Feb 02, 2003 at 13:26:21 +0300, Andrey A. Chernov wrote:
>
> > Workaround I find so far is something like that
> >
> > #define MASK 123459876
>
> I found nothing better. Here is fix for 0 problem I plan to commit:
I think it's worthwhile to w
On Sun, Feb 02, 2003 at 04:38:53 -0800, Doug Barton wrote:
>
> I think it's worthwhile to wait till we get a chance to try arc4random().
This is libc's rand/random, it can't be fixed with arc4random() as
designed.
> Also, have you run the code you're proposing through the tests in the post
> th
On Sun, Feb 02, 2003 at 03:30:35PM +0300, Andrey A. Chernov wrote:
> On Sun, Feb 02, 2003 at 13:26:21 +0300, Andrey A. Chernov wrote:
>
> > Workaround I find so far is something like that
> >
> > #define MASK 123459876
>
> I found nothing better. Here is fix for 0 problem I plan to commit:
>
>
On Mon, Feb 03, 2003 at 00:17:35 +1100, Tim Robbins wrote:
>
> I believe that this change just moves the "bad" seed to 123459876; after
> calling srand() with that seed, each call to rand() returns 0.
Yes. Nothing better is possible for this formulae and this is documented
in algorithm, some valu
In message: <[EMAIL PROTECTED]>
Oliver Brandmueller <[EMAIL PROTECTED]> writes:
: Hi,
:
: I'm currently experimenting with 5-CURRENT on my Notebook an have a
: question regarding the concept of devd.
:
: With 4-STABLE I had pccardd running. Whenever a pccard was inserted I
: had pccar
In message: <[EMAIL PROTECTED]>
"Kevin Oberman" <[EMAIL PROTECTED]> writes:
: > Date: Sat, 1 Feb 2003 19:20:12 +0100
: > From: Oliver Brandmueller <[EMAIL PROTECTED]>
: > Sender: [EMAIL PROTECTED]
: >
: > Hi,
: >
: > I'm currently experimenting with 5-CURRENT on my Notebook an have a
On Sun, Feb 02, 2003 at 16:42:25 +0300, Andrey A. Chernov wrote:
> On Mon, Feb 03, 2003 at 00:17:35 +1100, Tim Robbins wrote:
> >
> > I believe that this change just moves the "bad" seed to 123459876; after
> > calling srand() with that seed, each call to rand() returns 0.
>
> Yes. Nothing better
On Sun, Feb 02, 2003 at 17:02:23 +0300, Andrey A. Chernov wrote:
>
> I'll produce and send it a bit later.
Here it is.
--- stdlib/rand.c.old Sat Jan 4 20:39:19 2003
+++ stdlib/rand.c Sun Feb 2 17:06:08 2003
@@ -72,10 +72,13 @@
*/
long hi, lo, x;
+ /* Can't be initiali
Hi Warner.
On Sun, Feb 02, 2003 at 06:47:07AM -0700, M. Warner Losh wrote:
> devd works for me when I have devices in my machine at boot. It does
> run the start script for me. I just confirmed this on my machine. I
> put my wi card in, booted and it picked up a dhcp address.
>
> What script a
So far, this is final variant for 0 problem fixing ready for committing.
Any objections?
--- stdlib/rand.c.old Sat Jan 4 20:39:19 2003
+++ stdlib/rand.c Sun Feb 2 17:34:34 2003
@@ -72,10 +72,13 @@
*/
long hi, lo, x;
+ /* Can't be initialized with 0, so use another valu
David Schultz <[EMAIL PROTECTED]> writes:
> [2] http://stat.fsu.edu/~geo/diehard.html (you need ports/lang/f2c)
There's a native C version on Marsaglia's random number CD:
http://stat.fsu.edu/pub/diehard/cdrom/die.c/
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [
I'm not sure if this is a result of the recent sched_ule import, but
buildkernel is dying on a bunch of undefined symbols (that from what
I can see, are definitely present in both sched_(4bsd|ule)). I fol-
llowed a discussion on -arch about being able to nominate the prefe-
rre
"Jeroen C. van Gelderen" writes:
> Wouldn't it be a good idea to change the name at the same time? Or
> should it be retained for compatibility reasons with other BSDs?
>
> Currently the name needlessly exposes implementation detail. Callers
> expect good, cheap, non-blocking randomness but don'
On Sun, Feb 02, 2003 at 15:32:32 +, Mark Murray wrote:
> "Jeroen C. van Gelderen" writes:
> > Wouldn't it be a good idea to change the name at the same time? Or
> > should it be retained for compatibility reasons with other BSDs?
> >
> > Currently the name needlessly exposes implementation de
On Sun, Feb 02, 2003 at 03:35:00PM +, Trent Nelson wrote:
> I'm not sure if this is a result of the recent sched_ule import, but
> buildkernel is dying on a bunch of undefined symbols (that from what
> I can see, are definitely present in both sched_(4bsd|ule)). I fol-
> llowed
Hi,
You _must_ add SCHED_4BSD (old scheduler) or SCHED_ULE (new scheduler) to your
config file.
-- Aurelien
On Sun, Feb 02, 2003 at 03:35:00PM +, Trent Nelson wrote:
> I'm not sure if this is a result of the recent sched_ule import, but
> buildkernel is dying on a bunch of undefined
Okay, so it seems either 'options SCHED_4BSD/SCHED_ULE' needs to be
added to your kernel config file. Considering that this is a comp-
letely new line, would it not be wise to update UPDATING? I'm not
sure if /sbin/config has been modified to complain if one of either
isn't p
On 02-Feb-2003 Taylor Dondich wrote:
> After reading src/UPDATING and attempting to follow the directions to
> upgrade from 4.7-RELEASE to -CURRENT, I'm having some difficulty, after
> successfully building world and building and installing the kernel, I
> attempted to make install in src/sys/b
On Fri, 31 Jan 2003, Pascal Giannakakis wrote:
> Nicolao Renè schrieb:
> > Hi I've just upgraded to FreeBSD-Stable, the UPDATING file says that
> > many debugging options are enabled. But how do I remove them? thanks.
>
> One way would be to compile your own kernel:
> http://www.freebsd.org/doc/e
Hi.
Sorry for answering my own mail now.
On Sun, Feb 02, 2003 at 03:19:24PM +0100, Oliver Brandmueller wrote:
> action "/usr/local/etc/netconf/bin/netconf $device-name start";
David Wolfskill gave a good pointer, that devd starts before all
non-root disks are mounted. I'm just trying to
On Sun, Feb 02, 2003 at 03:54:08PM +, Trent Nelson wrote:
>
> Okay, so it seems either 'options SCHED_4BSD/SCHED_ULE' needs to be
> added to your kernel config file. Considering that this is a comp-
> letely new line, would it not be wise to update UPDATING? I'm not
Have you loo
HI,
I had the same unresolved symbols and it baffled me for a while. After
cvsupping several times to an avail, I deleted the new kernel build.
i.e. I deleted my kernel file and its directory (the one created when
you do config ), copied generic to a new kernel file, added my
own configs, and did
Hi,
One other step I did before that is buildworld, and then I did
buildkernel KERNCONF=ykernel
HTH
On Sun, 2003-02-02 at 17:03, Redjupiter wrote:
> HI,
>
> I had the same unresolved symbols and it baffled me for a while. After
> cvsupping several times to an avail, I deleted the new kernel build
On Sun, 2 Feb 2003, Oliver Brandmueller wrote:
> Sorry for answering my own mail now.
>
> On Sun, Feb 02, 2003 at 03:19:24PM +0100, Oliver Brandmueller wrote:
> > action "/usr/local/etc/netconf/bin/netconf $device-name start";
>
> David Wolfskill gave a good pointer, that devd starts bef
Hi.
On Sun, Feb 02, 2003 at 12:19:26PM -0500, Robert Watson wrote:
> > I'll keep you informed 'bout my findings.
>
> I ran into a similar problem, actually -- programs like dhclient rely on
> being able to write to lease and pid files. It's almost as though we'd
> like an additional set of even
"Andrey A. Chernov" writes:
> On Sun, Feb 02, 2003 at 04:38:53 -0800, Doug Barton wrote:
> >
> > I think it's worthwhile to wait till we get a chance to try arc4random().
>
> This is libc's rand/random, it can't be fixed with arc4random() as
> designed.
Why not? Arc4 is a) deterministic and b)
"Andrey A. Chernov" writes:
> On Mon, Feb 03, 2003 at 00:17:35 +1100, Tim Robbins wrote:
> >
> > I believe that this change just moves the "bad" seed to 123459876; after
> > calling srand() with that seed, each call to rand() returns 0.
>
> Yes. Nothing better is possible for this formulae and th
"Andrey A. Chernov" writes:
> > Objections?
>
> We can't, simple because sequence must be repeated for the same seed
> across the calls.
RC4 is repeatable.
M
--
Mark Murray
iumop ap!sdn w,I idlaH
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of t
We had a system running 4.3-RELEASE that I used the sysinstall upgrade
mechanism to upgrade to 5.0-RELEASE. I installed "compat4x" to use our
existing 4.x binaries.
Immediately after rebooting, I noticed most old 4.x binaries were
complaining about "_stdoutp" being an undefined symbol. However
On Sun, Feb 02, 2003 at 11:41:32AM -0600, Kevin Day wrote:
> lrwxr-xr-x 1 root wheel 9 Feb 1 00:18 libc.so -> libc.so.5
> lrwxr-xr-x 1 root wheel 16 Jul 5 2002 libc.so.3 -> /usr/lib/libc.so
^
This is seriously messed up. See below
Hi,
With a fresh -CURRENT tree, I got:
cc -fno-merge-constants -mcpu=pentiumpro -Werror -Wall -Wno-format-y2k -Wno-unin
itialized -c /usr/src/lib/libdisk/rules.c -o rules.o
cc1: warnings being treated as errors
/usr/src/lib/libdisk/rules.c: In function `Check_Chunk':
/usr/src/lib/libdisk/rules.c
At 11:42 AM 2/2/2003, Jacques A. Vidrine wrote:
On Sun, Feb 02, 2003 at 11:41:32AM -0600, Kevin Day wrote:
> lrwxr-xr-x 1 root wheel 9 Feb 1 00:18 libc.so -> libc.so.5
> lrwxr-xr-x 1 root wheel 16 Jul 5 2002 libc.so.3 -> /usr/lib/libc.so
On Sun, Feb 02, 2003 at 11:53:22AM -0600, Kevin Day wrote:
> Ok, I admit, no matter how it happened, an application using the wrong libc
> is a bad thing.
>
> But, how are things supposed to work?
Apps that need the old libc.so.4 will find it in
/usr/lib/compat/libc.so.4 (or /usr/lib/libc.so.4
On Sun, Feb 02, 2003 at 11:41:32AM -0600, Kevin Day wrote:
>
>
> lrwxr-xr-x 1 root wheel 9 Feb 1 00:18 libc.so -> libc.so.5
> lrwxr-xr-x 1 root wheel 16 Jul 5 2002 libc.so.3 -> /usr/lib/libc.so
Delete this.
> -r--r--r-- 1 root wheel 571480 Aug 5 13:45 libc.so.4
Delete this.
> -r--r--r-- 1 roo
At 11:54 AM 2/2/2003, Jacques A. Vidrine wrote:
> Ok, I admit, no matter how it happened, an application using the wrong
libc
> is a bad thing.
>
> But, how are things supposed to work?
Apps that need the old libc.so.4 will find it in
/usr/lib/compat/libc.so.4 (or /usr/lib/libc.so.4 if you didn'
On Sun, Feb 02, 2003 at 17:30:48 +, Mark Murray wrote:
>
> Why not? Arc4 is a) deterministic and b) good for all bits.
If you mean arc4random() function - not, because it use true randomness,
if you mean RC4 algorithm, probably yes, but we should compare its
distribution with our current vari
On Sun, Feb 02, 2003 at 17:34:19 +, Mark Murray wrote:
> "Andrey A. Chernov" writes:
> > > Objections?
> >
> > We can't, simple because sequence must be repeated for the same seed
> > across the calls.
>
> RC4 is repeatable.
It seems we mean different things saying arc4random(), see my answ
On Sun, Feb 02, 2003 at 21:20:09 +0300, Andrey A. Chernov wrote:
> On Sun, Feb 02, 2003 at 17:30:48 +, Mark Murray wrote:
> >
> > Why not? Arc4 is a) deterministic and b) good for all bits.
>
> If you mean arc4random() function - not, because it use true randomness,
> if you mean RC4 algorith
In message: <[EMAIL PROTECTED]>
Robert Watson <[EMAIL PROTECTED]> writes:
: I ran into a similar problem, actually -- programs like dhclient rely on
: being able to write to lease and pid files. It's almost as though we'd
: like an additional set of events when the system is "more boot
In message <[EMAIL PROTECTED]>, "Andrey A. Chernov" writes:
>On Sun, Feb 02, 2003 at 17:30:48 +, Mark Murray wrote:
>>
>> Why not? Arc4 is a) deterministic and b) good for all bits.
>
>If you mean arc4random() function - not, because it use true randomness,
>if you mean RC4 algorithm, probably
On Sun, Feb 02, 2003 at 19:32:50 +0100, [EMAIL PROTECTED] wrote:
>
> Anyway, last time we discussed this, I think we stuck with the rand()
> we had because we feared that people were using it's repeatable well
> documented sequence of random numbers in regression testing.
As documented, it must b
"Andrey A. Chernov" writes:
> On Sun, Feb 02, 2003 at 17:30:48 +, Mark Murray wrote:
> >
> > Why not? Arc4 is a) deterministic and b) good for all bits.
>
> If you mean arc4random() function - not, because it use true randomness,
> if you mean RC4 algorithm, probably yes, but we should compar
In message <[EMAIL PROTECTED]>, "Andrey A. Chernov" writes:
>On Sun, Feb 02, 2003 at 19:32:50 +0100, [EMAIL PROTECTED] wrote:
>>
>> Anyway, last time we discussed this, I think we stuck with the rand()
>> we had because we feared that people were using it's repeatable well
>> documented sequence o
In message <[EMAIL PROTECTED]>, Mark Murray wr
ites:
>We have most of this, and RC4 can deliver. RC4's "licence" is
>fine. Call it "ArCFour" and there is no problem. The code is
>small, fast and repeatable, and meets conditions 1-4 above.
There are some concerns about RC4's strength and predictab
> Good point. We can re-implement random() internally with arc4rand().
>
> Objections?
Guys, please realize that random() is also used in generating
simulation inputs (or timing or whatever). If you go change
the underlying algorithm or its parameters one can't generate
the same sequence from th
On Sun, Feb 02, 2003 at 19:43:44 +0100, [EMAIL PROTECTED] wrote:
>
> Please surf the mail-archives to find the discussion, it contained
> a lot of good arguments from both sides, arguments which should
> be thought about before changing rand().
I remember well that we decide to allow it be change
On Sun, Feb 02, 2003 at 18:36:02 +, Mark Murray wrote:
> I think we need four things.
>
> 1) void srandom(int arg) which uses the argument to seed.
> 2) void srandomdev(void) which uses system entropy to seed.
> 3) int random(void) which returns a number statistically
>random in all bits.
"Andrey A. Chernov" writes:
> On Sun, Feb 02, 2003 at 19:32:50 +0100, [EMAIL PROTECTED] wrote:
>
> > Anyway, last time we discussed this, I think we stuck with the
> > rand() we had because we feared that people were using it's
> > repeatable well documented sequence of random numbers in regression
[EMAIL PROTECTED] writes:
> RC4 can be implemented in about 4 lines of C.
Yah. If you like writing obfuscated C!
> Anyway, last time we discussed this, I think we stuck with the rand()
> we had because we feared that people were using it's repeatable well
> documented sequence of random numbers i
On Sun, Feb 02, 2003 at 19:47:12 +0100, [EMAIL PROTECTED] wrote:
> In message <[EMAIL PROTECTED]>, Mark Murray wr
> ites:
>
> >We have most of this, and RC4 can deliver. RC4's "licence" is
> >fine. Call it "ArCFour" and there is no problem. The code is
> >small, fast and repeatable, and meets cond
After doing a make in /usr/src/sys/boot/, I get this error and compile ends:
In file included from /usr/src/sys/boot/ficl/loader.c:40:
/usr/src/sys/boot/ficl/../common/bootstrap.h:254: syntax error before
'struct'
/usr/src/sys/boot/ficl/../common/bootstrap.h:254: warning: data
definition has no
[EMAIL PROTECTED] writes:
> In message <[EMAIL PROTECTED]>, Mark Murray
> wr
> ites:
>
> >We have most of this, and RC4 can deliver. RC4's "licence" is
> >fine. Call it "ArCFour" and there is no problem. The code is
> >small, fast and repeatable, and meets conditions 1-4 above.
>
> There are som
> As I said, I don't know how big a concern this is. But last time
> it was enough of a concern to make us keep rand() as it was.
[I know you are talking about rand() but Mark Murray's
earlier email about wanting to re-implement random() really
concerned me so I want to make sure my point gets ac
Bakul Shah writes:
> > Good point. We can re-implement random() internally with arc4rand().
> >
> > Objections?
>
> Guys, please realize that random() is also used in generating
> simulation inputs (or timing or whatever). If you go change
> the underlying algorithm or its parameters one can't g
Consider the following patch. Since you have custom configuration, it
might rely on other parts of the system being active before they will
work. This patch moves devd from starting 'first' to starting before
we have to mount the 'critical' remote disks. If you require critical
remote disks to d
Bakul Shah writes:
> Not changing random() was of real concern to me when I was
> doing chip simulations. ASIC design verification folks won't
> be happy if the rug is pulled out from under them. In
> general crypto and simulation needs are different and I don't
> trust the crypto guys to look ou
In message: <[EMAIL PROTECTED]>
Oliver Brandmueller <[EMAIL PROTECTED]> writes:
: fine. Any ideas?
Thanks for the info! I've sent in a different message that I think
will fix this problem. The problem is that /usr/local isn't mounted
when devd starts, so /usr/local/etc/netconf/bin/ne
On Sun, Feb 02, 2003 at 07:08:47PM +, Mark Murray wrote:
> RC4 is _utterly_ repeatable, given a particular seed/key.
I presume it also produces reasonably uniform output for most
seeds too.
> > The old 16 bit rand() was broken enough that it didn't matter
> > much (read: _I_ don't care) if it
On Sunday 02 February 2003 6:48 pm, Bakul Shah wrote:
> Guys, please realize that random() is also used in generating
> simulation inputs (or timing or whatever). If you go change
> the underlying algorithm or its parameters one can't generate
> the same sequence from the same seed when repeating
David Malone writes:
> On Sun, Feb 02, 2003 at 07:08:47PM +, Mark Murray wrote:
> > RC4 is _utterly_ repeatable, given a particular seed/key.
>
> I presume it also produces reasonably uniform output for most
> seeds too.
Yes. Modulo the requirement to "burn" a bit of output after a
reseed.
>
> RC4 is _utterly_ repeatable, given a particular seed/key.
May be but it is not the same as the current random(). Also,
I know you will want to change it the next time some one
points out a problem with RC4.
> Yes. And it breaks, and we have a complainant.
So create a new function! Or use a d
> > I presume it also produces reasonably uniform output for most
> > seeds too.
> Yes. Modulo the requirement to "burn" a bit of output after a
> reseed.
I guess the crypto guys would have junked it otherwise ;-)
> > I thought the complaint was about rand, not random?
> Erm, yes. Similar diffe
> Maybe I missed something, but why cannot you just rip random() from libc,
> rename it to bakul_shah_random() and use that in your testing code? Then you
> are safe from any changes to random(), and indeed have a portable RNG if your
> host OS changes.
Yes, *I* can do it but I don't work at eve
On Sunday 02 February 2003 8:06 pm, Bakul Shah wrote:
> > Maybe I missed something, but why cannot you just rip random() from libc,
> > rename it to bakul_shah_random() and use that in your testing code? Then
> > you are safe from any changes to random(), and indeed have a portable RNG
> > if your
Bakul Shah writes:
> > RC4 is _utterly_ repeatable, given a particular seed/key.
>
> May be but it is not the same as the current random(). Also,
> I know you will want to change it the next time some one
> points out a problem with RC4.
Yes. This is called "fixing bugs". We (OS maintainers) res
Bakul Shah writes:
> Yes, *I* can do it but I don't work at every place they do
> simulation! If in the extreme you are suggesting that a
> portable application shouldn't rely on any OS features, you
> are of course right but that kind of makes mockery of any
> claims of compatibility. The point
On Sun, Feb 02, 2003 at 20:05:29 +, David Malone wrote:
> > > I presume it also produces reasonably uniform output for most
> > > seeds too.
>
> > Yes. Modulo the requirement to "burn" a bit of output after a
> > reseed.
>
> I guess the crypto guys would have junked it otherwise ;-)
Notice t
Taylor,
May I ask why you're running this command? Are you trying to upgrade
4.X to 5.0-R/C? If so, make sure that you've followed all the steps listed
in /usr/src/UPDATING.
If your problems persist, try doing a fresh cvsup, clear out /usr/obj/ and
retry the steps listed in UPDATING.
Regards,
>
> a restriction on the OS. If FreeBSD makes random2() using RC4 to avoid
> changing rand() or random(), will people then start relying on random2()'s
> behaviour, and when someone finds a problem in RC4, then the next will be
> random3()?
What I am suggesting is to leave random() as it is and
On Sun, Feb 02, 2003 at 12:39:50 -0800, Bakul Shah wrote:
>
> Note that it is rand() that is broken, not random() as can be
> seen by modifying Kris Kennaways' test so I don't see why
> Mark Murray was talking about changing it in the first place.
About correlation bug: it is srand() which is bro
On Sun, Feb 02, 2003 at 12:06:56PM -0800, Bakul Shah wrote:
> > Maybe I missed something, but why cannot you just rip random() from libc,
> > rename it to bakul_shah_random() and use that in your testing code? Then you
> > are safe from any changes to random(), and indeed have a portable RNG if y
On Sun, Feb 02, 2003 at 11:55:25AM -0800, Bakul Shah wrote:
> > RC4 is _utterly_ repeatable, given a particular seed/key.
>
> May be but it is not the same as the current random(). Also,
> I know you will want to change it the next time some one
> points out a problem with RC4.
Since you keep ta
> Would you prefer that we defined random() as
>
> int
> random(void)
> {
> static int retval = 0;
>
> return retval++;
> }
No because that would be a change from the exisiting random()
behavior :-)
As I indicated in my earlier email random() is not broken,
srand() is (as corrected
$ pciconf -l
chip0@pci0:0:0: class=0x06 card=0x chip=0x07351039 rev=0x01 hdr=0x00
pcib2@pci0:1:0: class=0x060400 card=0x chip=0x00011039 rev=0x00 hdr=0x01
isab0@pci0:2:0: class=0x060100 card=0x chip=0x00081039 rev=0x00 hdr=0x00
ohci0@pci0:2:2: class=0x0c0310 card=0x0a141
> Since you keep talking about random(), I must conclude you're
> knee-jerking, since we're not discussing that function. Please stay
> on-topic :-)
Read through the thread. In particular see Mark's message
<[EMAIL PROTECTED]> where he
says
Good point. We can re-implement random() internall
Bakul Shah writes:
> Note that it is rand() that is broken, not random() as can be
> seen by modifying Kris Kennaways' test so I don't see why
> Mark Murray was talking about changing it in the first place.
rand(3) says:
STANDARDS
The rand() and srand() functions conform to ISO/IEC 9899:1990
On Sun, Feb 02, 2003 at 12:57:45PM -0800, Bakul Shah wrote:
> > Since you keep talking about random(), I must conclude you're
> > knee-jerking, since we're not discussing that function. Please stay
> > on-topic :-)
>
> Read through the thread. In particular see Mark's message
> <[EMAIL PROTECTED
On Sun, Feb 02, 2003 at 06:10:49PM +0300, Andrey A. Chernov wrote:
> So far, this is final variant for 0 problem fixing ready for committing.
> Any objections?
What tests have you run on this code to ensure it doesn't still have
strange problems?
Kris
msg51583/pgp0.pgp
Description: PGP si
Has anyone gotten gbde working with vnode md devices (file-based)?
I'm trying to create a gbde-managed device from a file, and I keep on
getting various ioctl() failures. See attached log file.
Thanks,
--
Darryl Okahata
[EMAIL PROTECTED]
DISCLAIMER: this message is th
Bakul Shah writes:
> random(3) also provides an initstate() call which presumably
> allows you to change the amount of randomnes. So here is
> another suggestion: why not fold your algorithm change in
> that function? For example,
>
> initstate(seed, "RC4", 3);
>
> changes the algorithm to
On Sun, 2 Feb 2003, Andrey A. Chernov wrote:
> So far, this is final variant for 0 problem fixing ready for committing.
> Any objections?
Several people, including myself have asked for A) Enough discussion to
reach a consensus, and B) Thorough testing of the agreed upon solution.
You have allowe
On Sunday 02 February 2003 8:39 pm, Bakul Shah wrote:
> What I am suggesting is to leave random() as it is and
> guarantee its behavior won't change and add cryto_random() or
> whatever, and indicate it *may* change.
Where was it indicated that random() wouldn't change?
> Note that it is rand() t
In message <[EMAIL PROTECTED]>, Darryl Okahata writes
:
>su-2.05b# gbde init /dev/md0 -L /tmp/foo.lock
Don't use the -L and -l arguments unless you have to.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD sinc
On Sun, 2 Feb 2003, Bakul Shah wrote:
> Yes, *I* can do it but I don't work at every place they do
> simulation!
Well the code is still going to be available in cvs. It's not like we're
going to magically make it disappear. :)
> If in the extreme you are suggesting that a
> portable application
Bakul Shah writes:
> > Since you keep talking about random(), I must conclude you're
> > knee-jerking, since we're not discussing that function. Please stay
> > on-topic :-)
>
> Read through the thread. In particular see Mark's message
> <[EMAIL PROTECTED]> where he
> says
>
> Good point. W
1 - 100 of 156 matches
Mail list logo
