On Mon, Feb 8, 2016 at 4:47 PM, Guille Polito
<[email protected] <mailto:[email protected]>> wrote:
I detach the conversation from the Object>>name issue.
So, to summarize the conversation:
For some reason, the UUIDs generated by my Pharo in my new machine
(Debian Jessie 64bit) are not unique at all. They keep clashing
with UUIDs of existing packages in Smalltalkhub. I mean with this
that it is not an isolated case or a random thing. I can reproduce
it every time I commit. I opened a bug for this [1]. And I marked
it as show stopper, as I believe we cannot release pharo5 with
this bug that prevents people from doing a commit.
Should there be any concern that the CI monkey may have picked up any
wrong slices?
cheers -ben
Then, I tested the NeoUUIDGenerator and it works better in that
sense. Or at least it gives me better guarantees. I propose to
replace the existing UUID generator by NeoUUID generator. The
latter is not only better, but it also includes tests. What do you
think?
Guille
[1] https://pharo.fogbugz.com/f/cases/17544/UUIDs-are-not-so-unique
-------- Forwarded Message --------
Subject: Re: [Pharo-dev] [Need help with Monkey] Removing
Object>>name
Date: Fri, 5 Feb 2016 14:12:10 +0100
From: Henrik Sperre Johansen <[email protected]>
<mailto:[email protected]>
Reply-To: Pharo Development List <[email protected]>
<mailto:[email protected]>
To: Pharo Development List <[email protected]>
<mailto:[email protected]>
On Thu, Feb 4, 2016 at 2:59 PM, Sven Van Caekenberghe
<[email protected] <mailto:[email protected]>> wrote:
> On 04 Feb 2016, at 14:02, Henrik Johansen
<[email protected]
<mailto:[email protected]>> wrote:
>
>>
>> On 04 Feb 2016, at 12:52 , Sven Van Caekenberghe
<[email protected] <mailto:[email protected]>> wrote:
>>
>>
>>> On 04 Feb 2016, at 11:55, Guille Polito
<[email protected] <mailto:[email protected]>>
wrote:
>>>
>>> Good news, so far, installing NeoUUID and replacing UUID
class >> new by:
>>>
>>> UUID class >> new
>>> ^NeoUUIDGenerator new next
>>>
>>> seems to work. At it looks that I can trust again my commits.
>>>
>>> Thanks Sven :)
>>
>> OK.
>>
>> Now, the idea is that one instance of the generator is kept
around, this is way more efficient, but also more correct, as
the random generator should not be created anew each time.
>>
>>> Now I do not know how this should be solved, nor if this
is reproducible in a machine other than mine...
>>
>> I seriously doubt the plugin is better (more random, more
unique) then anything that we can do in Pharo itself. I like
Pharo code way better, because we all see what it does.
>>
>> Anyone else with an opinion ?
>
> More random for certain, at least much faster than we could
do in Pharo, is certainly possible with a plugin.
> More unique... well, depends on whether you can trust the
source RNG (seeded from data with enough entropy, period much
greater than 2^128, etc).
>
> A single next:into:startingAt: primitive filling random data
(obtained using platform primitives and/or RDRAND/RDSEED) into
a buffer would be much nicer/more flexible than the current
UUID primitive though. (the linked UUID library is basically
just a thin wrapper around the platform primitives, plus
setting variant/version bits in the returned UUID bytes)
>
> As a stopgap, one could instead use another, more general
primitive (but with a less flexible api than
next:into:startingAt:) in an otherwise unrelated plugin (but
that is built internal to all Cog VM's, at least):
> rand: aBuffer
> <primitive: 'primitiveGatherEntropy' module:
'CroquetPlugin'>
> ^self primitiveFail
>
> (which, iirc, resolves to the same platform primitives as
UUID lib)
>
> Also, the meaning of different UUID versions are well
defined in the RFC, marking NeoUUID's as being a version 4
UUID seems somewhat ... disingenuous.
Yes, but to 99.99% of developers, a UUID is something
special/magic where some effort was made to generate something
as unique as possible.
If we insist on it being just 128 random bits, then why all
the fuss ? Why do we even need so called standards ?
In my mind, you just answered that :)
The standard provides 4 well-defined ways to implement something
where it's guaranteed that some effort has been made to generate
something as unique as possible.
Why do we need a plugin, an implementation even ? It makes no
sense. Just read 16 bytes from /dev/[u]random, or the
equivalent use of a RNG and be done with it.
But if you tell developers that their database IDs are just
plain random numbers, they will probably feels less good about
them.
But... that's *exactly* what you tell them by marking UUID's as
being of type 4.
To me UUID is a specific concept: << The intent of UUIDs is to
enable distributed systems to uniquely identify information
without significant central coordination. In this context the
word unique should be taken to mean "practically unique"
rather than "guaranteed unique". >>
Not including any 'node' information (identifying process,
image, VM, machine, network endpoint), nor 'counter' does not
feel right.
And I agree Neo-UUID fits that bill nicely, the values it returns
*are* practically unique.
The two things I disagreed with was:
1) The statement that it is possible to implement purely in
Smalltalk UUID's as random as those returned by the plugin (Which,
as you say, is basically reading 16 bytes from /dev/random), at
least as performant, without consulting an external trusted
randomness source.
2) Misrepresenting the way the UUID was generated (a combination
of node identifier + timestamp + random value, similar to type 3,
but with differently sized/ordered fields) by marking it as being
of type 4, which is defined to be UUID consisting of random bytes.
IOW, I think it should be marked as type 0 instead of 4, so for
the 1 person in each country who might be found to assume
something about the implementation based on the type field, won't
later feel he's been duped when checking the generator.
Cheers,
Henry
