> On 05 Feb 2016, at 14:12, Henrik Sperre Johansen > <henrik.s.johan...@veloxit.no> wrote: > > > > On Thu, Feb 4, 2016 at 2:59 PM, Sven Van Caekenberghe <s...@stfx.eu> wrote: > > > On 04 Feb 2016, at 14:02, Henrik Johansen <henrik.s.johan...@veloxit.no> > > wrote: > > > >> > >> On 04 Feb 2016, at 12:52 , Sven Van Caekenberghe <s...@stfx.eu> wrote: > >> > >> > >>> On 04 Feb 2016, at 11:55, Guille Polito <guillermopol...@gmail.com> 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.
Agreed. > 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. OK, I certainly want to change the type. Thing is, I cannot find a reference to type 0 anywhere that I am looking (I mostly used https://en.wikipedia.org/wiki/Universally_unique_identifier). Where did you find a definition of type 0 ? Or would that be a way to say 'no specific type' then ? > Cheers, > Henry
