Well if you are running using the Smalltalk code that generates the  
UUID this might be true,
  and I'm not sure that people remove chunks of code from the image just  
for fun,
or isn't there support in the windows vm for the UUID primitive?

Anyway the smalltalk generated code inserts bits of 'random'  by doing

setupRandom
	| seed |
	randomCounter _ 0.
	[seed := (Time millisecondClockValue bitAnd: 16r3FFFFFFF) bitXor: self  
hash.
	seed = 0] whileTrue: ["Try again if ever get a seed = 0"].
	randomGenerator _ Random seed: seed.

which then gets saved  via stuffing an instance of the UUIDGenerator  
into a class variable .  That instance
is used to generate the UUID

I'll note in the croquet image this class variable is nil, thus a UUID  
call creates a new instance and a new instance of Random.

So I'm kinda confused since Random does it not preserve Entropy over  
image saves?

Well unless you fail to save the image, then gee you get the problem,  
because the instance of Random will just restart
from the entropy it remembers from the last save. Thus crashing the  
image without saving will cause a repeat.

Oops didn't look, is this a Unix VM? is the UUID primitives supported  
there?

Seems we need a change set to patch the UUIDGenerator or Random? to  
flip some Entropy on image startup?


Unless of course at the time we in
On Tuesday, November 19, 2002, at 02:56  AM, Andreas.Raab at gmx.de wrote:

> Göran,
>
> This is a problem in the UUIDGenerator. The following will trigger the
> problem reliably:
>
> * take out the primitive from UUID>>primMakeUUID
> * start image
> * evaluate
>      UUID new.
>   (to force generator creation)
> * save image
>
> Whenever you restart the image it will create *exactly* the same UUIDs  
> in
> exactly the same order. The problem is that UUIDGenerator's random  
> number
> generator is based on the millisecond clock value at the point where  
> the generator
> is created. I think there should really be a set of randoms which are
> initialized based on different seeds (including date, time, network  
> address etc)
> and the generator *must* be flushed when the image starts.
>
> Cheers,
>   - Andreas
>
--
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===