• (cs) in reply to Remy Porter
    Remy Porter:
    Or, y'know, you could just accept the slim risk that you'll duplicate a GUID sometime before the heat death of the universe. Searching the list of pre-generated GUIDs is going to rapidly turn into a performance bottleneck.

    So? Performance is a hardware problem. Just get a bigger server (these days: buy more cloud) and everything will be well.

    (At least, that's how our vendors solve performance problems.)

  • PRMan (unregistered) in reply to Some Jerk
    Some Jerk:
    PRMan:
    spike:
    TRWTF is that this code was written in the first place, it stinks of premature protection. I highly doubt there was an issue that prompted this code to be written.

    The perpetrator of this code obviously doesn't understand GUIDs, they have a temporal component (time created), a spatial component (MAC address or similar unique number), a algorithm ID and a random component. (IIRC there may also be a small sequential component intended for GUIDS created at the same time, so even in the unlikely occurrence of a random numbers collision there is still a difference!)

    Actually, not anymore. Now they are almost completely random.

    I worked at a company where we actually got a duplicate that couldn't be explained any other way except that it was a generated duplicate. This is when I learned that the generation method had changed.

    Not this shit again...

    Believe it or don't. I don't really care. We had a duplicate that was generated. I thought it was absolutely impossible because the time/date was involved. But when I learned that they are essentially long pseudorandom numbers with a couple "version 4" codes.

    V4 GUIDs use the later algorithm, which is a pseudo-random number. These have a "4" in the same position, for example {38a52be4-9352-453e-af97-5c3b448652f0}. More specifically, the 'data3' bit pattern would be 0001xxxxxxxxxxxx in the first case, and 0100xxxxxxxxxxxx in the second. Cryptanalysis of the WinAPI GUID generator shows that, since the sequence of V4 GUIDs is pseudo-random, given full knowledge of the internal state, it is possible to predict previous and subsequent values.[4]

    Let me ask you this: Do you really think that Microsoft's pseudorandom generator algorithm is so good that it could never give a duplicate?

    I mean, there's a reason that Google gives 624,000 results when searching for "Duplicate GUID". They can't all have done it wrong...

  • (cs) in reply to Coyne
    Coyne:
    Remy Porter:
    Or, y'know, you could just accept the slim risk that you'll duplicate a GUID sometime before the heat death of the universe. Searching the list of pre-generated GUIDs is going to rapidly turn into a performance bottleneck.

    So? Performance is a hardware problem. Just get a bigger server (these days: buy more cloud) and everything will be well.

    (At least, that's how our vendors solve performance problems.)

    I find it remarkable how much support that mindset is gaining as technology improves. Truthfully, I despise the strategy. For example... Entity Framework generating 200 lines of code for every 1 line that actually needs to be there.

    I can host 10 web apps on my workstation while playing City of Heroes and downloading animes at 2MB/sec without suffering slow response times. Yes... my system definately has the hardware for it... but it would not work if I was silly enough to think (just do whatever and add hardware if it needs it).

  • Harrow (unregistered) in reply to GettinSadda
    GettinSadda:
    spike:
    The perpetrator of this code obviously doesn't understand GUIDs, they have a temporal component (time created), a spatial component (MAC address or similar unique number), a algorithm ID and a random component. (IIRC there may also be a small sequential component intended for GUIDS created at the same time, so even in the unlikely occurrence of a random numbers collision there is still a difference!)
    That used to be the case, but according to Microsoft (and the same seems to apply to *nix systems too)
    Microsoft:
    For security reasons, it is often desirable to keep ethernet addresses on networks from becoming available outside a company or organization. The UuidCreate function generates a UUID that cannot be traced to the ethernet address of the computer on which it was generated. It also cannot be associated with other UUIDs created on the same computer.
    Any halfway competent security analyst can tell you that a security scheme that depends on my MAC address remaining secret is doomed. For starters, if my MAC address is compromised I cannot change it.

    This is typical Microsoft crap on a stick. The only thing that distinguishes UuidCreate from a bog standard PRNG is the the temporal and spatial components -- so let's break them.

    When I first saw UuidCreate I didn't trust it. Not because I think it can't work, not because UUIDs are long and ugly, not because there are better methods, but because it's implemented by Microsoft.

    The value of a UUID scheme is the mathematical rigor of its specification. At Microsoft, a developer who admits he can even spell "mathematical rigor" goes immediately to the bottom of the stack.

    -Harrow.

  • neminem (unregistered) in reply to Cbuttius
    Cbuttius:
    Mijzelf:
    And how big is the chance to be frist?

    I've achieved that aim several times, now I wish to get a comment with a blue background and appearing with the article.

    Hey, I actually (sort of) got one; I asked a question and the answer got blue'd up.

    This is even kinda relevant to this article, as the question asked was "can I still steal^Hacquire a t-shirt even if I have no desire, nor in fact any particular ability to test out New Relic's software on any real applications?", and the official answer here seemed to be "yes", so I did. Interestingly enough, New Relic's official answer, according to their faq, would seem to be "no", but I wanted a t-shirt, so I did it anyway. Presumably New Relic wasn't actually reading the comments on their advertisement's thread. :p

  • (cs) in reply to Some Jerk
    Some Jerk <- imposter:
    He should use a dictionary to increase performance over the .Any() call.
    hmmm. I didn't see anyone else posting as me when I was unregistered. Glad that I registered... I would hate for anybody to think this came from me.
  • Larry (unregistered) in reply to GettinSadda
    GettinSadda:
    the universe is about 4.6 * 10^17 seconds old, so if a device started calculating 11 billion billion GUIDs a second at the big bang, it would be running out soon.
    Kids throwing around cosmology stuff as if they know what they're talking about are TRWTF.

    First of all, an awful lot of events happened in the first second after the BB. Hell, forget the first second, let's just focus on the first thousandth of a second...

    Anyway, the point is, the Universe was so small that with the speed of light and all that you could get a hell of a lot done in a very short time. In other words, it was as if time proceeded a lot slower than it does now.

    Which means most of those GUIDs would have been calculated before the formation of the first atoms.

  • ORly? (unregistered) in reply to spike
    spike:
    TRWTF is that this code was written in the first place, it stinks of premature protection.
    Premature protection? Is that what you call it now? Is that your lofty-sounding excuse for not testing anything until it breaks in production?
  • Andrew Stein (unregistered) in reply to Andrew Stein

    250k duplicate GUIDs in a set of 3 million, we sure need this DiffeerentGuid method..

  • (cs) in reply to Andrew Stein
    Andrew Stein:
    250k duplicate GUIDs in a set of 3 million, we sure need this DiffeerentGuid method..

    one problem is that the guid generator still depends on random numbers, which are generated by system clock. based on your count, 1 of 6 guids were duplicated. Thread.sleep for 100ms and try it again. I suspect that 10 MS would do it... but just to be sure.

  • n_slash_a (unregistered) in reply to QJo
    QJo:
    GettinSadda:
    The number of random GUIDs (using version 4 which is most common now) there are 2^122 or about 5.3 * 10^36 values.

    To put this into perspective the universe is about 4.6 * 10^17 seconds old, so if a device started calculating 11 billion billion GUIDs a second at the big bang, it would be running out soon.

    I could calculate the chance of a collision, but I have better things to do :-)

    Running out already? Goodness! We need to sort this one out! Quick, where are my developers? All leave cancelled till you sort this out! GettinSadda has just told me the GUIDs are running out!

    Open IE (because anyone that "smart" uses IE) to your company's home page and press F5 as fast as possible to signal your developers to return.

  • Andrew Stein (unregistered) in reply to Some Jerk

    Hi Some Jerk :-)

    My comments were in reference to the generation of GUIDs in parallel in Oracle. See http://sqlfascination.com/2012/01/22/oracle-duplicate-guid-values-being-returned-from-sys_guid-when-run-in-parallel/

    Sleeping would defeat the purpose.

  • Andrew Stein (unregistered) in reply to Some Jerk
    Some Jerk:
    Andrew Stein:
    250k duplicate GUIDs in a set of 3 million, we sure need this DiffeerentGuid method..

    one problem is that the guid generator still depends on random numbers, which are generated by system clock. based on your count, 1 of 6 guids were duplicated. Thread.sleep for 100ms and try it again. I suspect that 10 MS would do it... but just to be sure.

    Hi Some Jerk :-)

    My comments were in reference to the generation of GUIDs in parallel in Oracle. See http://sqlfascination.com/2012/01/22/oracle-duplicate-guid-values-being-returned-from-sys_guid-when-run-in-parallel/

    Sleeping would defeat the purpose.

  • Barf 4eva (unregistered)

    When Guid isn't Guid enough, use DifferentGuid.

  • (cs) in reply to Andrew Stein

    Ahh. I am surprised that Oracle has that problem. I made a blanket comment earlier that ORDBMS servers would be an ideal place to maintain uniqueness among such fields, as it is inherrent in the architecture to deny duplicates (with constraints). It seems that this might be more challenging for Oracle to handle than MS Sql Server. Can you force the insert to retry if it fails? Just curious.

  • Some Jerk (unregistered) in reply to Some Jerk
    Some Jerk:
    Some Jerk <- imposter:
    He should use a dictionary to increase performance over the .Any() call.
    hmmm. I didn't see anyone else posting as me when I was unregistered. Glad that I registered... I would hate for anybody to think this came from me.
    Afraid of having your good name besmirched, matterhorn?
  • Some Jerk (unregistered) in reply to Larry
    Larry:
    GettinSadda:
    the universe is about 4.6 * 10^17 seconds old, so if a device started calculating 11 billion billion GUIDs a second at the big bang, it would be running out soon.
    Kids throwing around cosmology stuff as if they know what they're talking about are TRWTF.

    First of all, an awful lot of events happened in the first second after the BB. Hell, forget the first second, let's just focus on the first thousandth of a second...

    Anyway, the point is, the Universe was so small that with the speed of light and all that you could get a hell of a lot done in a very short time. In other words, it was as if time proceeded a lot slower than it does now.

    Which means most of those GUIDs would have been calculated before the formation of the first atoms.

    Who are you trying to fool? I'm no Einstein, but isn't time constant?

  • (cs) in reply to Some Jerk
    Some Jerk:
    Some Jerk:
    Some Jerk <- imposter:
    He should use a dictionary to increase performance over the .Any() call.
    hmmm. I didn't see anyone else posting as me when I was unregistered. Glad that I registered... I would hate for anybody to think this came from me.
    Afraid of having your good name besmirched, matterhorn?

    Not really... it was just a subtle suggestion that certain people could maybe produce their own ideas as opposed to using those of others durring the name selection process. I attempted to word it as politely as possible.

  • (cs) in reply to Some Jerk
    Some Jerk <-- Imposter:
    Who are you trying to fool? I'm no Einstein, but isn't time constant?

    Though I must admit... using my handle exclusively to spout nonsense really is unkind. I suspect (however) that most can tell the difference. You should try to be more subtle... and actually say something intelligent once in a while... and it might pass for me.

  • Some Jerk (unregistered) in reply to Some Jerk
    Some Jerk:
    Some Jerk <-- Imposter:
    Who are you trying to fool? I'm no Einstein, but isn't time constant?

    Though I must admit... using my handle exclusively to spout nonsense really is unkind. I suspect (however) that most can tell the difference. You should try to be more subtle... and actually say something intelligent once in a while... and it might pass for me.

    The fact that you think anyone else cares speaks volumes on your intelligence.

  • (cs) in reply to Some Jerk
    Some Jerk:
    Some Jerk:
    Some Jerk <-- Imposter:
    Who are you trying to fool? I'm no Einstein, but isn't time constant?

    Though I must admit... using my handle exclusively to spout nonsense really is unkind. I suspect (however) that most can tell the difference. You should try to be more subtle... and actually say something intelligent once in a while... and it might pass for me.

    The fact that you think anyone else cares speaks volumes on your intelligence.
    Does anyone else have a weird sense of deja vu here?

  • (cs) in reply to PedanticCurmudgeon

    :p

    see? Someone does care. Now grow an imagination... or failing that, feel free to post as "Some Jerk is a dickhead" or something... if you suddenly found that the most interesting thing to do with your life is to harrass me on a message board.

    Anyway... I never said that I thought "SOMEONE" cared... only said that "I" cared.

  • (cs) in reply to Harrow
    Harrow:
    For starters, if my MAC address is compromised I cannot change it.
    Ahem.
  • Recursive Reclusive (unregistered) in reply to Some Jerk
    Some Jerk:
    Recursive Reclusive:
    Esse:
    I'm having some problem understanding the code.

    What if guid3 accidentally gets the same GUID as guid2. The loop first checks if guid3 is the same as guid1. It isn't. Then, it checks if guid3 is the same as guid2. Because it's the same, guid3 gets a new GUID, and the loop ends. But what if the second GUID that's assigned to guid3 is the same as guid1?

    I believe there are two loops in there. An inner loop, "guids.Any(g => g == result)", that goes through all GUIDs and return true or false. And an other loop, "while", that continues until the inner loop return false.

    In reality, the inner loop will always return false, so the while-loop is only executed once.

    Not so... :p

    guids.Any will return true only if the newly created Guid is already in the ParamArray, and if so, creates a new one. It's basically like replicating SQL In Operator -- if @intVal in (1, 2, 3) -- yielding true where @intVal is either 1, 2 or 3...

    You say that as if it in any way contradicts what I wrote.

  • (cs) in reply to PedanticCurmudgeon
    PedanticCurmudgeon:
    Some Jerk:
    Some Jerk:
    Some Jerk <-- Imposter:
    Who are you trying to fool? I'm no Einstein, but isn't time constant?

    Though I must admit... using my handle exclusively to spout nonsense really is unkind. I suspect (however) that most can tell the difference. You should try to be more subtle... and actually say something intelligent once in a while... and it might pass for me.

    The fact that you think anyone else cares speaks volumes on your intelligence.
    Does anyone else have a weird sense of deja vu here?
    Yep.

  • The Joker (unregistered)

    You shouldn't leave these things to chance.

  • (cs)

    What are the "fancy html comments" I keep reading about? I don't think I've ever seen them. :S And I read the first page of comments on nearly every article.

  • David F. Skoll (unregistered)

    I wonder what the test coverage of the body of the

    while
    loop is like?

  • David F. Skoll (unregistered) in reply to Coyne

    Ah, but if you get a bigger server, you hasten the heat death of the universe, so you are defeated once again!

  • I dunno if I should reply but I'll do it anyways. (unregistered) in reply to Some Jerk
    Some Jerk:
    I'm no Einstein, but isn't time constant?
    No, you're definitely no Einstein.
  • Raphael (unregistered) in reply to Harrow
    Harrow:
    Any halfway competent security analyst can tell you that a security scheme that depends on my MAC address remaining secret is doomed. For starters, if my MAC address is compromised I cannot change it.

    This is typical Microsoft crap on a stick. The only thing that distinguishes UuidCreate from a bog standard PRNG is the the temporal and spatial components -- so let's break them.

    When I first saw UuidCreate I didn't trust it. Not because I think it can't work, not because UUIDs are long and ugly, not because there are better methods, but because it's implemented by Microsoft.

    The value of a UUID scheme is the mathematical rigor of its specification. At Microsoft, a developer who admits he can even spell "mathematical rigor" goes immediately to the bottom of the stack.

    -Harrow.

    Who uses UUIDs for security purposes? Aren't they just for differentiating two things? Like COM interfaces, or partitions.
  • Hi No Einstein, I'm Tom (unregistered) in reply to Some Jerk
    Some Jerk:
    I'm no Einstein, but isn't time constant?
    Time is a function of the speed of light, so as light slows down due to the expansion of the Universe, time does too, so that we perceive the speed of light as a constant.
  • Evoex (unregistered) in reply to PRMan
    PRMan:
    I mean, there's a reason that Google gives 624,000 results when searching for "Duplicate GUID". They can't all have done it wrong...

    There's a reason that Google gives 12,600,000 results when searching for "void main". It can't be wrong then, right?

  • (cs) in reply to Evoex
    Evoex:
    PRMan:
    I mean, there's a reason that Google gives 624,000 results when searching for "Duplicate GUID". They can't all have done it wrong...

    There's a reason that Google gives 12,600,000 results when searching for "void main". It can't be wrong then, right?

    Let's get this straight: He counted "velociraptors that are running loose" and you counted "all occurrences of 'WTF' on the web"...and you're using your count as an explanation for why his count doesn't indicate any concern?

    All I can say is: +1

  • (cs) in reply to Raphael
    Raphael:
    Harrow:
    The value of a UUID scheme is the mathematical rigor of its specification. At Microsoft, a developer who admits he can even spell "mathematical rigor" goes immediately to the bottom of the stack.

    -Harrow.

    Who uses UUIDs for security purposes? Aren't they just for differentiating two things? Like COM interfaces, or partitions.

    Even if GUIDs aren't used for security themselves, they reveal details about their origin that might be considered secure.

    Ignoring the fact that wireless is often sensitive to MAC for example, think about assigning a GUID to an election ballot: The GUID reveals the election machine and the time of creation, which means that the individual that cast the ballot can be identified--a violation of secret ballot.

    Of course, UUID is probably equally unusable, really, since I suspect MS carefully buried all that information in the ID anyway. Like NSA, they can't stand it if they don't know exactly where and when the UUID was created, so they probably just used some kind of lame hardcoded encryption to hide the details. I won't be surprised if we hear about someone breaking the UUID protection scheme at some point, so that MAC and time can be extracted.

  • Luiz Felipe (unregistered) in reply to Remy Porter
    Remy Porter:
    Or, y'know, you could just accept the slim risk that you'll duplicate a GUID sometime before the heat death of the universe. Searching the list of pre-generated GUIDs is going to rapidly turn into a performance bottleneck.

    Perhaps the guid generator dont generate new guids every time, perhaps it increments stored generated guid and time from time update. Then you have a multthreaded program, th collision can happen once or twice a month.

  • Luiz Felipe (unregistered) in reply to Sten
    Sten:
    I see the problem is that GUIDs are only globally unique. This programmer obviously thought of poor Martians and other extraterrestrials forced to place interplanetary calls to have this fixed (the prices are just insane). On the other hand, he could simply use univerally unique UUIDs :-)
    But what if in multiverse we have duplicated values, this can be a serous problem for multi-space-time research lab.
  • Michelle (unregistered)
    article:
    Sure, you're more likely to be struck by a meteor and lighting while winning the lottery on the last Tuesday before Lent while driving your Ferrari to the diner for pancakes, but it can happen!
    FTFY
  • fheiwo (unregistered) in reply to Coyne
    Coyne:
    Remy Porter:
    Or, y'know, you could just accept the slim risk that you'll duplicate a GUID sometime before the heat death of the universe. Searching the list of pre-generated GUIDs is going to rapidly turn into a performance bottleneck.

    So? Performance is a hardware problem. Just get a bigger server (these days: buy more cloud) and everything will be well.

    (At least, that's how our vendors solve performance problems.)

    Big Blue? I guess it could be any of the others too....

  • Jugiga (unregistered) in reply to n_slash_a
    n_slash_a:
    QJo:
    GettinSadda:
    The number of random GUIDs (using version 4 which is most common now) there are 2^122 or about 5.3 * 10^36 values.

    To put this into perspective the universe is about 4.6 * 10^17 seconds old, so if a device started calculating 11 billion billion GUIDs a second at the big bang, it would be running out soon.

    I could calculate the chance of a collision, but I have better things to do :-)

    Running out already? Goodness! We need to sort this one out! Quick, where are my developers? All leave cancelled till you sort this out! GettinSadda has just told me the GUIDs are running out!

    Open IE (because anyone that "smart" uses IE) to your company's home page and press F5 as fast as possible to signal your developers to return.
    What's Open IE? Firefox?

    Captcha: combover

  • I wanna go too (unregistered) in reply to Some Jerk
    Some Jerk:
    Some Jerk:
    Some Jerk:
    Some Jerk <- imposter:
    He should use a dictionary to increase performance over the .Any() call.
    hmmm. I didn't see anyone else posting as me when I was unregistered. Glad that I registered... I would hate for anybody to think this came from me.
    Afraid of having your good name besmirched, matterhorn?

    Not really... it was just a subtle suggestion that certain people could maybe produce their own ideas as opposed to using those of others durring the name selection process. I attempted to word it as politely as possible.

    But he's "Some Jerk (unregistered)" which appears totally different to "Some Jerk"

  • Hulio (unregistered) in reply to pbean
    pbean:
    What are the "fancy html comments" I keep reading about? I don't think I've ever seen them. :S And I read the first page of comments on nearly every article.
    Brillant!
  • Evoex (unregistered) in reply to Some Jerk
    Some Jerk:
    Larry:
    GettinSadda:
    the universe is about 4.6 * 10^17 seconds old, so if a device started calculating 11 billion billion GUIDs a second at the big bang, it would be running out soon.
    Kids throwing around cosmology stuff as if they know what they're talking about are TRWTF.

    First of all, an awful lot of events happened in the first second after the BB. Hell, forget the first second, let's just focus on the first thousandth of a second...

    Anyway, the point is, the Universe was so small that with the speed of light and all that you could get a hell of a lot done in a very short time. In other words, it was as if time proceeded a lot slower than it does now.

    Which means most of those GUIDs would have been calculated before the formation of the first atoms.

    Who are you trying to fool? I'm no Einstein, but isn't time constant?

    That comment, my friend, deserves a very high position in the thedailywtf hall of shame.

  • marc (unregistered)
    more likely to be struck by a meteor and lighting while winning the lottery on a Tuesday during Lent while driving your Ferrari to the diner for pancakes

    This statement suggests that all events must happen around the same time. Let's loosen the simultaneity requirement to be that all these events happen during the same hour, to be very fair.

    The probability of being hit by lightning is about 1e-6 per year or 1e-10 per hour.

    Let's assume that one person in the US gets hit by by a meteor every year, which internet searches suggest to be a high estimate. Then the probability of being hit by a meteor is about 1e-8 per year or 1e-12 per hour.

    If you play a typical lottery once a day, you have about 1e-8 probability of winning per day or about 1e-9 per hour.

    There are less than 10 Tuesdays during Lent, giving less than 1e-1 probability that any given day is a Tuesday during Lent.

    Ferrari makes about 1e4 Ferraris per year, so there are less than 1e6 Ferraris in the US. Therefore the probability that a random person in the US owns a Ferrari is less than 1e-2.

    Finally, let's say you spend 15 minutes every driving to a diner for pancakes. This gives 1e-2 probability that you are driving to a diner for pancakes.

    Multiplying everything together, we get 1e-36 probability per hour. Given the roughness of the estimate, that's very close to the 1e-37 probability of collision of two completely random GUIDs. So don't be so confident.

    (Of course, a better estimate would also have to account for the fact that people have more than one hour in their lives in which to have this unfortunate accident. But a better estimate would also have to account for the fact that there are usually more than two GUIDs to collide. And because of the birthday paradox, I don't expect these additional details would weigh in favor of the article's statement.)

  • (cs) in reply to fheiwo
    fheiwo:
    Coyne:
    Remy Porter:
    Or, y'know, you could just accept the slim risk that you'll duplicate a GUID sometime before the heat death of the universe. Searching the list of pre-generated GUIDs is going to rapidly turn into a performance bottleneck.

    So? Performance is a hardware problem. Just get a bigger server (these days: buy more cloud) and everything will be well.

    (At least, that's how our vendors solve performance problems.)

    Big Blue? I guess it could be any of the others too....

    It's mostly other vendors. "Tuning" is a dead art, I guess.

  • Gruntled (unregistered) in reply to Some Jerk
    Some Jerk:
    As far as real WTFs go... the idea of insuring distinction is perhaps a bit OCD but not uncommon among us home grown developers

    It makes sense to write your code in a way that it gracefully handles a duplicate, just in case a software bug generates one and you don't want to lose data or order $100 million worth of the wrong stuff. Writing clock cycle munching code to prevent duplicates from forming defeats the purpose of using UUIDs and you might as well use a counter in a central repository. Even with locking, it's likely going to be faster than searching your entire backlog of generated ID's for duplicates like this code does...

  • Huh? (unregistered) in reply to marc
    marc:
    more likely to be struck by a meteor and lighting while winning the lottery on a Tuesday during Lent while driving your Ferrari to the diner for pancakes

    This statement suggests that all events must happen around the same time. Let's loosen the simultaneity requirement to be that all these events happen during the same hour, to be very fair.

    The probability of being hit by lightning is about 1e-6 per year or 1e-10 per hour.

    Let's assume that one person in the US gets hit by by a meteor every year, which internet searches suggest to be a high estimate. Then the probability of being hit by a meteor is about 1e-8 per year or 1e-12 per hour.

    If you play a typical lottery once a day, you have about 1e-8 probability of winning per day or about 1e-9 per hour.

    There are less than 10 Tuesdays during Lent, giving less than 1e-1 probability that any given day is a Tuesday during Lent.

    Ferrari makes about 1e4 Ferraris per year, so there are less than 1e6 Ferraris in the US. Therefore the probability that a random person in the US owns a Ferrari is less than 1e-2.

    Finally, let's say you spend 15 minutes every driving to a diner for pancakes. This gives 1e-2 probability that you are driving to a diner for pancakes.

    Multiplying everything together, we get 1e-36 probability per hour. Given the roughness of the estimate, that's very close to the 1e-37 probability of collision of two completely random GUIDs. So don't be so confident.

    (Of course, a better estimate would also have to account for the fact that people have more than one hour in their lives in which to have this unfortunate accident. But a better estimate would also have to account for the fact that there are usually more than two GUIDs to collide. And because of the birthday paradox, I don't expect these additional details would weigh in favor of the article's statement.)

    But there are more people in the world than just in the US...even if only US people get hit by meteorites, we have to take into account EVERYONE

  • Norman Diamond (unregistered)

    Out of curiosity, are UUIDs more unique than GUIDs? Yes!

    Inside curiosity, are UUIDs more unique than GUIDs? No!

    Because even if a GUID inside curiosity is duplicated by others, only the one inside curiosity is local to Mars.

  • (cs)

    The difference between a GUID and a UUID is that the same GUID can exist somewhere on another planet while a UUID cannot, it is universally unique.

    For spaceships therefore, you need UUIDs just to be safe.

  • (cs) in reply to Evoex
    Evoex:
    There's a reason that Google gives 12,600,000 results when searching for "void main". It can't be wrong then, right?

    "void main" is correct in C# and Java, incorrect in C and C++.

Leave a comment on “GUGUID”

Log In or post as a guest

Replying to comment #:

« Return to Article