On Mon, Feb 8, 2016 at 4:47 PM, Guille Polito <[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]> > <[email protected]> > Reply-To: Pharo Development List <[email protected]> > <[email protected]> > To: Pharo Development List <[email protected]> > <[email protected]> > > > > On Thu, Feb 4, 2016 at 2:59 PM, Sven Van Caekenberghe < <[email protected]> > [email protected]> wrote: > >> >> > On 04 Feb 2016, at 14:02, Henrik Johansen < >> <[email protected]>[email protected]> wrote: >> > >> >> >> >> On 04 Feb 2016, at 12:52 , Sven Van Caekenberghe <[email protected]> wrote: >> >> >> >> >> >>> On 04 Feb 2016, at 11:55, Guille Polito <[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 > > >
