THis is repeatable for me at will.
5.0-current, supped as of 2/1.
4 80GIG maxtors on 2 promise IDE ultra 66 cards, exported via NFS.
newfs'd an 80G FS on each drive, created one big file filled with
zero's from /dev/zero on each drive. (Softupdates/UFS1)
login to my other box, which has the
On Fri, 31 Jan 2003 13:24:49 +0100,
Michael Nottebrock <[EMAIL PROTECTED]> wrote:
> I'm sorry to have to bother you further, but this patch does not solve the
> problem completely. Amd works partially now, but I still get 'mountd rpc
> failed: RPC: Unable to receive' errors when I try to access
On Thu, Jan 30, 2003 at 07:37:04PM -, Patrick Stinson wrote:
> has anyone every had problems with appending existing files on volumes
> mounted by smbfs or shlight?
>
> $ echo "sdsad" >> hey
> $ echo "sdsad" >> hey
> cannot create hey: Permission denied
Please try this patch and let me know
³¬Ò»Á÷ÍøÂçÊÓƵ»áÒé¡¢Ãâ·Ñµç»°¡¢Ô¶³Ì½Ìѧר¼Ò»áÕïϵͳ
±¾¹«Ë¾×îвúÆ·:ÍøÂçÊÓƵ»áÒéÊÓƵ·þÎñÆ÷---¹ã·ºÓÃÓÚ¸ßÇåÎú¶È¾ÖÓò»ò¹ãÓòÊÓƵ»áÒé¡¢ÍøÂç¼à¿Ø¡¢Ó׶ùÔ°¾´ÀÏÔººÍÒ½Ôº²¡·¿¼ÒÈËÒìµØÔ¶³Ì¼à»¤¡¢×¨¼ÒÔ¶³ÌÒ½ÁÆ»áÕïºÍ½Ìѧ¡¢ÍøÂçÔ¶³Ì½ÌÊÒÒÔ¼°ÎÞ»°·Ñ¿ÉÊÓ»¯¿Í»§·þÎñϵͳ,ÍøÉÏ·ç¾°Çø,¾ÆµêʵʱÊÓƵչʾ¡¢µçÊÓ½ÚÄ¿ÍøÉÏʵʱת²¥¡¢´
Steve Kargl wrote:
> On Sun, Feb 02, 2003 at 04:37:07PM -0800, Terry Lambert wrote:
> > I can fire up my HP/UX and SunOS 4.1.3-U1 boxes too, if you need
> > those, but I'm pretty sure the reason you got a different answer
> > for newer Solaris was because it uses the SVR4 code, instead.
>
> That's
Edward Brocklesby wrote:
> On Monday 03 February 2003 12:20 am, Terry Lambert wrote:
> > Edward Brocklesby wrote:
> > > Where was it indicated that random() wouldn't change?
> >
> > Right there in the boot message, and again when you logged in,
> > where the system indicated to you that it was a BS
Don wrote:
> > > It isn't a question of the API. It's a question of expected function
> > > output.
> >
> > Then it's applicable not only to binary packages as Terry states, but any
> > source that uses rand().
>
> I think Terry mentioned binary packages simply because it is harder to fix
> them t
On Monday 03 February 2003 12:41 am, Don wrote:
> I think Terry mentioned binary packages simply because it is harder to fix
> them than something available as source but I could be mistaken.
Possibly -- if we're looking at this from the point of view of the user of
said binary package, rather th
Terry Lambert wrote:
> > Last 10 digits.
> >
> > FreeBSD Redhat SunOS
> 386BSD 0.1+
> patchkitTRU64
Crap.
Ignore these numbers. I replaced the libc implementation on both
these machines, and forgot I had done it. When I put the code
back to what it was, they give the Solar
On Sun, Feb 02, 2003 at 04:37:07PM -0800, Terry Lambert wrote:
>
> I can fire up my HP/UX and SunOS 4.1.3-U1 boxes too, if you need
> those, but I'm pretty sure the reason you got a different answer
> for newer Solaris was because it uses the SVR4 code, instead.
>
That's the whole point! You sh
Mark Murray wrote:
> > That's why randomness tests + mathematician to interpretate their results
> > are needed to compare what we have now in random(3) with RC4. Easy and
> > understandable code not always mean better results. We can't switch
> > algorithms blindly, i.e. when their comparative qua
On Monday 03 February 2003 12:20 am, Terry Lambert wrote:
> Edward Brocklesby wrote:
> > Where was it indicated that random() wouldn't change?
>
> Right there in the boot message, and again when you logged in,
> where the system indicated to you that it was a BSD system;
Sorry, I can't quite work
> > It isn't a question of the API. It's a question of expected function
> > output.
>
> Then it's applicable not only to binary packages as Terry states, but any
> source that uses rand().
I think Terry mentioned binary packages simply because it is harder to fix
them than something available as s
Steve Kargl wrote:
> I was going to stay out of this, but
>
> #include
> #include
> int main(void) {
> int i;
> long x;
> x = 100L;
> srandom(x);
> for (i = 0; i < 1010; i++) {
> x = random();
> printf("%ld\n", x);
> }
> return 0;
> }
>
> Last 10 digits.
>
> FreeBSD
Thus spake Andrey A. Chernov <[EMAIL PROTECTED]>:
> 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
>
On Monday 03 February 2003 12:18 am, Don wrote:
> It isn't a question of the API. It's a question of expected function
> output.
Then it's applicable not only to binary packages as Terry states, but any
source that uses rand().
> I run FreeBSD and not Linux because of the stability and predict
Doug Barton <[EMAIL PROTECTED]> wrote:
>
>I can think of one significant benefit... I had noticed that my perl
>script to pick random windowmaker themes (which uses rand()) seemed to be
>picking the same themes over and over again.
That's a bug in perl's compile-time configuration. It can be told
Doug Barton wrote:
> I can think of one significant benefit... I had noticed that my perl
> script to pick random windowmaker themes (which uses rand()) seemed to be
> picking the same themes over and over again. Now I know why. :) I had to
> create a "last seen" list to artificially increase the "
Edward Brocklesby wrote:
> 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'
> > Binary packages from third party software vendors.
>
> What about them? They either,
> a) link to a static libc, and use its rand() always; or
> b) link to a shared libc, and use its rand(), as the binary API hasn't
> changed; or
It isn't a question of the API. It's a question of expected funct
> Interesting The SunOS output exactly matches random(3)
> behavior from 4.3BSD! In fact random() remained the same for
> 4.3BSD-Reno, -Tahoe, 4.4BSD-Alpha and Net2.
>
> 4.2BSD random() behavior is different from all of the above.
> There was real bug-fix between 4.2BSD and 4.3BSD.
>
> I do
Mark Murray wrote:
> 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)
On Sun, Feb 02, 2003 at 04:02:27PM -0800, Juli Mallett wrote:
> * De: David Malone <[EMAIL PROTECTED]> [ Data: 2003-02-02 ]
> [ Subjecte: Re: rand() is broken ]
> > On Sun, Feb 02, 2003 at 02:37:25PM -0800, Steve Kargl wrote:
> > > FreeBSD Redhat SunOS
> > > 6607877546607877
On Sunday 02 February 2003 11:59 pm, Terry Lambert wrote:
> Edward Brocklesby 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
Mark Murray <[EMAIL PROTECTED]> wrote:
>
>3) int random(void) which returns a number statistically
> random in all bits.
>
>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
* De: David Malone <[EMAIL PROTECTED]> [ Data: 2003-02-02 ]
[ Subjecte: Re: rand() is broken ]
> On Sun, Feb 02, 2003 at 02:37:25PM -0800, Steve Kargl wrote:
> > FreeBSD Redhat SunOS
> > 660787754660787754645318364
>
> FWIW - AIX aggrees with Solaris.
Endiannes, or a
Edward Brocklesby wrote:
> 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
"M. Warner Losh" wrote:
> 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 st
--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
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.
I tried that, and it didn't repeat the sequence I got when I
previously used "rand()"... 8-) 8-).
-- Terry
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 detail. Callers
> > expect good, cheap, non-
[From address modified because I don't want every message in this
thread to end up in my personal mailbox. I'll read them in the
list, thank you very much.]
On Sun, Feb 02, 2003 at 09:23:43PM +, Mark Murray wrote:
> Bakul Shah writes:
> > > Since you keep talking about random(), I must conclu
> Last 10 digits.
>
> FreeBSD Redhat SunOS
> 660787754660787754645318364
> 3275486913275486911583150371
> 2009993994 2009993994 715222008
> 1653966416 1653966416 1349166998
> 1074113008 1074113008 566227131
> 2142626740 2142626740 1382825076
> 15177758
On Sun, Feb 02, 2003 at 02:37:25PM -0800, Steve Kargl wrote:
> FreeBSD Redhat SunOS
> 660787754660787754645318364
FWIW - AIX aggrees with Solaris.
David.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
"Andrey A. Chernov" writes:
> On Sun, Feb 02, 2003 at 22:35:54 +, Mark Murray wrote:
> >
> > I stand (somewhat) corrected. The random() code is _nasty_ complexity-wise.
> > Its not obvious how it works.
> >
> > RC4 is 10-20 lines and clean with no magic numbers.
>
> That's why randomness tes
Thus spake Bakul Shah <[EMAIL PROTECTED]>:
> > 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
On Sun, Feb 02, 2003 at 22:35:54 +, Mark Murray wrote:
>
> I stand (somewhat) corrected. The random() code is _nasty_ complexity-wise.
> Its not obvious how it works.
>
> RC4 is 10-20 lines and clean with no magic numbers.
That's why randomness tests + mathematician to interpretate their res
I'm getting double-faults on my laptop, and I have managed to capture
them in DDB because I roughly know when to expect them.
But It seems that the panic and DDB offers absolutely no helpful
information about a double-fault ?
How does one debug problems like this ?
--
Poul-Henning Kamp
"Andrey A. Chernov" writes:
> On Sun, Feb 02, 2003 at 22:19:33 +, Mark Murray wrote:
>
> > > 1) Implementing random(3) with RC4 is not needed, its algorithm is
> > > already equal or better.
> >
> > Rubbish. :-) RC4's internal state is 256 bytes. In theory, its
> > cycle-of-repetition is 2^(
On Sun, Feb 02, 2003 at 01:59:25PM -0800, Bakul Shah wrote:
>
> AFAIK all random(3) implementations in various versions of
> Unix come from Earl's original 4.2BSD implementation so in my
> view the _expected_ behavior is to see the _exact_ same
> sequence starting from a given seed. This function
On Sun, Feb 02, 2003 at 22:19:33 +, Mark Murray wrote:
> > 1) Implementing random(3) with RC4 is not needed, its algorithm is
> > already equal or better.
>
> Rubbish. :-) RC4's internal state is 256 bytes. In theory, its
> cycle-of-repetition is 2^(8*256) bits.
This is comparable with rand
On Sun, Feb 02, 2003 at 14:21:02 -0800, Kris Kennaway wrote:
>
> If I understand correctly, this still doesn't solve the problem,
> because any PRNG sequence that hits the "magic" value will still get
> stuck there forever.
It was true for the first patch I post which just move problem to another
"Andrey A. Chernov" writes:
> On Sun, Feb 02, 2003 at 21:23:43 +, Mark Murray wrote:
> >
> > That was random(9). KERNEL random().
>
> KERNEL random() can be easily implemented (better - replaced) with
> arc4random(), there is no objections. But...
>
> 1) Implementing random(3) with RC4 is no
On Mon, Feb 03, 2003 at 12:55:40AM +0300, Andrey A. Chernov wrote:
> On Sun, Feb 02, 2003 at 13:06:08 -0800, Kris Kennaway wrote:
> > 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 objectio
Bakul Shah writes:
> > No. Evil interface change. #ifdef hell while programs try to
> > figure out OS differences.
>
> How so? This or a similar change is upward compatible in
> that the existing behavior is left unchanged and it gives you
> a way to replace the algorithm.
It requies that progra
In message <[EMAIL PROTECTED]>, Darryl Okahata writes
:
>[EMAIL PROTECTED] wrote:
>
>> Say, do you actually have the GEOM_BDE option in your kernel ?
>
> Sigh, no. I missed it in gbde(4).
>
> You might want to further idiot-proof gbde(8) with code like:
>
>err(1, "ioctl(GEOMCONFIGGEOM) (is
On Sun, Feb 02, 2003 at 21:23:43 +, Mark Murray wrote:
>
> That was random(9). KERNEL random().
KERNEL random() can be easily implemented (better - replaced) with
arc4random(), there is no objections. But...
1) Implementing random(3) with RC4 is not needed, its algorithm is
already equal or
[EMAIL PROTECTED] wrote:
> Say, do you actually have the GEOM_BDE option in your kernel ?
Sigh, no. I missed it in gbde(4).
You might want to further idiot-proof gbde(8) with code like:
err(1, "ioctl(GEOMCONFIGGEOM) (is \"options GEOM_BDE\" in the kernel?)");
Thanks for the hel
> > another suggestion: why not fold your algorithm change in
> > that function? For example,
> >
> > initstate(seed, "RC4", 3);
> >
> > changes the algorithm to RC4. Yes, this is a change in the
> > interface but one I am sure most people can live with.
>
> No. Evil interface change. #ifd
On Sun, Feb 02, 2003 at 13:06:08 -0800, Kris Kennaway wrote:
> 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 ha
On Sun, Feb 02, 2003 at 13:12:55 -0800, Doug Barton wrote:
>
> If I had to guess, I'd say that you're eager to fix the mistake you made,
> and I suppose that's commendable. However, it's been broken for two years,
> it can wait another couple days for a more thorough fix.
If you talk about 0 prob
In message <[EMAIL PROTECTED]>, Darryl Okahata writes
:
>[EMAIL PROTECTED] wrote:
>
>> Can you please try this:
>>
>> mdconfig -a -t malloc -s 4m -u 75
>> gbde init /dev/md75
>> gbde attach md75
>
> Nope, exact same error.
That is weird, it works like a charm here.
syv
[EMAIL PROTECTED] wrote:
> Can you please try this:
>
> mdconfig -a -t malloc -s 4m -u 75
> gbde init /dev/md75
> gbde attach md75
Nope, exact same error.
--
Darryl Okahata
[EMAIL PROTECTED]
DISCLAIMER: this message is the author's personal opinion and d
In message <[EMAIL PROTECTED]>, Darryl Okahata writes
:
>[EMAIL PROTECTED] wrote:
>
>> >su-2.05b# gbde init /dev/md0 -L /tmp/foo.lock
>>
>> Don't use the -L and -l arguments unless you have to.
>
> Thanks, but that was what I originally tried, and I still got the
>"gbde: ioctl(GEOMCONFIGGEOM):
Sorry, I'm being forgetful: I'm getting these errors under
5.0-RELEASE.
--
Darryl Okahata
[EMAIL PROTECTED]
DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion, or policy of Agilent Technologies, or
of the little green men t
[EMAIL PROTECTED] wrote:
> >su-2.05b# gbde init /dev/md0 -L /tmp/foo.lock
>
> Don't use the -L and -l arguments unless you have to.
Thanks, but that was what I originally tried, and I still got the
"gbde: ioctl(GEOMCONFIGGEOM): Invalid argument" error. In other words,
I get the same error
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
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
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 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
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
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
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
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
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
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
> 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
$ 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
> 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
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
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 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
> 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
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,
>
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
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
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
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
> 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
> > 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
> 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
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.
>
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
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
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
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
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:
> > 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
> 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
[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
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
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
[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
"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
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.
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
> 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
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
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
"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
1 - 100 of 156 matches
Mail list logo
