John,

thanks for taking the time to give some reference and valuable info on
how the UUID did evolve and how to resolve the current situation.

Alex

On Thu, Aug 13, 2009 at 7:17 PM, John M
McIntosh<johnmci at smalltalkconsulting.com> wrote:
> 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
> ===========================================================================
>
>
>
>
>
>