> On 6 Feb 2017, at 14:51, Peter Uhnak <i.uh...@gmail.com> wrote: > > I had issues with Pharo not being random during the first startup: > http://forum.world.st/Random-is-not-random-at-startup-td4895905.html > > Even though the seed is different during startup, the mask trims the > randomness away.
The Random generator is what it is, it can certainly be improved, but that is tricky too. In 64 bits we could probably do with less masking/trimming. > Looking at NeoUUID, it actually makes it worse on Linux (and presumably > Unix/Mac too), because it uses Pharo's broken seeding and not pooling > /dev/urandom. > > (I can test it on linux machine later today just to be sure.) Why would it be worse ? Of course it is not. Reading from /dev/random is not portable to Windows and tricky too (because it sometimes hangs until there is enough entropy). >> Still, UUIDs are not 100% guaranteed to be unique, they are a (very good) >> best effort. > > For all intents and purposes they are considered 100% to be unique. > If you generate two identical V4 UUIDs then either PRNG or seeding is broken > (seeding in Pharo's case). > > Peter According to https://en.wikipedia.org/wiki/Universally_unique_identifier << When generated according to the standard methods, UUIDs are for practical purposes unique, without depending for their uniqueness on a central registration authority or coordination between the parties generating them, unlike most other numbering schemes. While the probability that a UUID will be duplicated is not zero, it is so close to zero as to be negligible. >> Read the last sentence. So IMO it is certainly not 'broken'. Note also that NeoUUID uses different elements, the random part is only one of them. > On Mon, Feb 06, 2017 at 02:35:37PM +0100, Sven Van Caekenberghe wrote: >> >>> On 6 Feb 2017, at 14:17, Yuriy Tymchuk <yuriy.tymc...@me.com> wrote: >>> >>> Hi everyone, >>> >>> I’m using the session id (Smalltalk session id) for my data recording, so I >>> can distinguish if the recorded events came from the same session. The idea >>> is that each time an image is started a new session is created and assigned >>> a new UUID. Now when I started to look on the data I noticed that I have >>> some cases where I have same session IDs with different session creation >>> times (yes a new session is initialized with a current timestamp). The time >>> difference for the sessions with the same UUID and a different timestamp is >>> within 2 hours. Then another thing that I did is to group the data by the >>> timestamp and there are no cases where I have a different ID for the same >>> timestamp, which shows that the timestamp is a more reliable ID. Now I will >>> deal with my data just fine, but maybe we need to look in the >>> implementation why do we get sessions with the same IDs? >>> >>> Cheers. >>> Uko >> >> I would be very surprised it would happen with NeoUUIDGenerator >> (NeoUUIDGenerator next). The idea was to replace UUIDGenerator and the VM >> plugin by it. That got stalled when there was unforeseen interaction with >> WorkingSession. I believe that should be solved by now. >> >> Still, UUIDs are not 100% guaranteed to be unique, they are a (very good) >> best effort. >> >> But I agree that if they repeat in such a short time frame, that should be >> considered a bug. >> >> Sven >> >> >> >> >> >
