On 12-Aug-09, at 11:02 PM, Alexander Lazarević wrote:

> Thanks to all of you who have replied and suggested to remove the
> UUIDPlugin. This did the trick. Why not use the UUIDGenerator all the
> time? What's the advantage of using libuuid? Are the benefits that
> high that it is worth having a crashing vm on many unbuntu systems?
> Just wondering. :S
>
> Regards,
> Alex


Ok as the author of the UUID logic let me reply.


back in Sept 2001 I got a note from Andreas:

> * UUIDs/GUIDs on Macs:
> This is more a strategic inquiry - is there a way of getting UUIDs/ 
> GUIDs
> directly from MacOS?! We could make use of them for various purposes  
> and it
> would be nice if there'd be a simple way of getting them.
>
> Note that the above list is ordered by priority - I really don't  
> care as
> much about UUIDs as I do care about figuring out proxy settings.


This resulted in some paid work from Viewpoints Research Institute to  
implement on the Mac.

The basis of the work was taken from

http://ftp.ics.uci.edu/pub/ietf/webdav/uuid-guid/draft-leach-uuids-guids-01.txt

Although there was some code on the internet that calculated a UUID  
version 1 it was quite rough
and difficult to compile on os-9 as we were in the transition period  
from os-9 to os-x.  Fortunately
OS-X provided an operating system api to get a UUID.

My fall back choice then was to create a UUID version 4  in smalltalk  
code.
"For UUID version 4, it is a randomly or pseudo-randomly generated 60  
bit value."

Now there are two issues with this,  the first bug reported was a  
problem with MC on unix if I remember correctly.
I was using the random number generator that David N Smith wrote based  
on  an adaptation of the Park-Miller RNG.
This provides a good random number distribution but it does repeat and  
requires a seed number.
The first issue was reuse of the seed number which would then generate  
the same sequence of UUIDs after restarting a image, over the years  
figuring out the seed start value was an issue, some people used sound  
input (zero bytes when no mic on machine), millisecond clock, zero on  
some platform at VM startup, seconds (well that didn't work very  
well), to finally setting on using the /dev/urandom to get the four  
bytes.
Of course since the macintosh, windows, iPhone and Unix/Linux now  
provide UUID via the plugin the fallback for UUID version 4 isn't used  
much. In fact the code is such now it assume that the unix platform  
*IS* the only candidate and is hard coded with that in mind.
My concern is that the UUIDGenerator>>generateOneOrZero will generate  
a UUID that has been used in the past because the algorithm will at  
some point repeat the squence of randomness
I note the check for 100000 which resets the generator is hand waving  
to "maybe" reduce the probability.

So what can be done?
Well can the unix platform check to see if the libuuid version is a  
version that is acceptable? Either warn at startup time, or fall back  
to UUID version 4?
Or consider using bytes from /dev/random (not /dev/urandom) to build  
the UUID, really you could pull just the 60 bits needed as a sequence  
8 bytes of data.
--
= 
= 
= 
========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com>   Twitter:   
squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
= 
= 
= 
========================================================================