One of the most dangerous words in engineering is “statisticaly impossible”
At enough scale edge cases stop to be theoretical and start become production events.
Ask HN: We just had an actual UUID v4 collision...
291–300 of 369 posts
Re: Ask HN: We just had an actual UUID v4 collision...
#292Earlier quoted context omitted.
I too have witnessed a "add two numbers" service! Turns out you can be too extreme with rules for isolating out business logic..
Same! It had validation on each number before adding them. Poor design, but that's how it worked.
I find this so hard to believe, but I've nearly always worked in small groups/companies. Can you, or any of the commenters above, explain why the reasoning that leads to such a service isn't rejected by, well, common sense? Some super-special requirements?
Re: Ask HN: We just had an actual UUID v4 collision...
#293This reminds me of a passage from the book "Pro Git". https://git-scm.com/book/en/v2 > "Here’s an example to give you an idea of what it would take to get a SHA-1 collision. If all 6.5 billion humans on Earth were programming, and every second, each one was producing code that was the equivalent of the entire Linux kernel history (6.5 million Git objects) and pushing it into one enormous Git repository, it would take…
Hasn't the Git team been hard at work to optionally offer other hashes, like SHA256, in addition to SHA-1?
They have been not at work on doing that.
Re: Ask HN: We just had an actual UUID v4 collision...
#294Earlier quoted context omitted.
> There is the Von Neumann method of generating an unbiased coin from a biased coin. Of throwing it twice, and checking if you got HT or TH. And completely discarding all HH or TT results. It doesn't matter if the coin you are using is 20% or 80%, the result will be a true 50/50. This blew my mind. Thank you! I had to think about it a bit, so for anyone scratching their head right now trying to figure it out, conside…
And for people who like equations, here is my attempt at explaining it. Assume each flip is independent and the bias remains same in each flip. Let P(H) = p, P(T) = 1 - p. Then P(HH) = p^2, P(HT) = p(1 - p), P(TH) = (1 - p)p, P(TT) = (1 - p)^2. Therefore P(HT or TH) = 2p(1 - p). Now calculate P(HT | HT or TH) = p(1 - p) / (2p(1 - p)) = 1/2, P(TH | HT or TH) = (1 - p)p / (2p(1 - p)) = 1/2.
You don't need conditional probability here, as the flips are independent.
It's just p(H)p(T).
And p(H)p(T) = p(T)p(H), thus 2*p(H)p(T) = 2p(1-p).
Re: Ask HN: We just had an actual UUID v4 collision...
#295Earlier quoted context omitted.
Same! It had validation on each number before adding them. Poor design, but that's how it worked.
I find this so hard to believe, but I've nearly always worked in small groups/companies. Can you, or any of the commenters above, explain why the reasoning that leads to such a service isn't rejected by, well, common sense? Some super-special requirements?
In the case I mentioned at https://news.ycombinator.com/item?id=48062322, it was because the Infrastructure org had grown out of what had previously been Datacenter Operations.
So they had a team of SWEs who knew the system they were responsible for was absurd, but they weren't able to adequately explain that to the senior management folk who came from that DCOps culture and held asset management & configuration tracking to be paramount. The uniqueness was seen less as an inherent property, and more as a constraint that needed to be enforced.
My team of DevOps-y proto-Platform Engineers struggled with the org's culture in similar ways, so I had a lot of sympathy for the situation they found themselves in and how they were handling it. I believe their Zookeeper-based system was intended to be more of generic lightweight config registry which would eventually have replaced the gigantic SOAP-based CMDB nightmare - basically Consul a year or two before Consul existed.
The reason why they struggled to get it into production was that it would have been so obviously useful that they kept having additional requirements and use cases forced into their "MVP". That sort of scope creep, driven by tech leadership wanting to make their mark on a successful project, is also pretty common in large orgs.
Re: Ask HN: We just had an actual UUID v4 collision...
#296All the comments I've been able to read are missing the elephant in the room: no high-quality entropy source can turn a "should" into a "must".
If you want something that is difficult to guess, ask the cryptography guys. But if you need something that is -_guaranteed_ unique, you must build it yourself.
Re: Ask HN: We just had an actual UUID v4 collision...
#297Earlier quoted context omitted.
If I understand it the Lava lamps are 90% PR/fun. They have a lot of other sources for entropy that scales better.
Yes, they also have wave machines, pendulums, and mobiles :) https://blog.cloudflare.com/harnessing-office-chaos/ https://blog.cloudflare.com/chaos-in-cloudflare-lisbon-offic...
Wouldn’t thermal noise in a resistor make more practical sense?
Re: Ask HN: We just had an actual UUID v4 collision...
#298This is surprisingly common. The security of UUIDv4 is based on the assumption of a high-quality entropy source. This assumption is invalidated by hardware defects, normal software bugs, and developers not understanding what "high-quality entropy" actually means and that it is required for UUIDv4 to work as advertised. It is relatively expensive to detect when an entropy source is broken, so almost no one ever does.…
This is why CloudFlare has done what they did with the lava lamp wall. Not that the wall is such a great source of entropy on its own - I'm sure it's not their only source, but you can never have too many sources of entropy - but it makes it visible in a way that can grab those who don't fully understand the concepts of RNGs and how entropy plays into that. The more sources of entropy, the more closely you approach "…
> This is why CloudFlare has done what they did with the lava lamp wall.
Interesting. I wonder how true it actually is that they use it like they claim here: https://www.cloudflare.com/learning/ssl/lava-lamp-encryption.... It's in one of their lobbies, so doesn't that make it susceptible to an attack in some way? I'm not knowledgeable enough to know, but I figured if they actually used that method, they'd have a more controlled environment.
I also don't fully understand it. A large part of that wall is static. And the camera isn't going to pick up on the stochastic properties of the lava as much as exists in the real world. So it feels like their images will be very statistically similar.
Re: Ask HN: We just had an actual UUID v4 collision...
#299Earlier quoted context omitted.
This is why CloudFlare has done what they did with the lava lamp wall. Not that the wall is such a great source of entropy on its own - I'm sure it's not their only source, but you can never have too many sources of entropy - but it makes it visible in a way that can grab those who don't fully understand the concepts of RNGs and how entropy plays into that. The more sources of entropy, the more closely you approach "…
The lava lamps are just for show. You can get entropy just by plugging an oscilloscope into a pile of dirt and cranking the gain up.
Meh. The problem is that it might start receiving you local radio station and end up deterministic enough to screw you. So you need to shield the dirt properly.
Re: Ask HN: We just had an actual UUID v4 collision...
#300Earlier quoted context omitted.
> you can never have too many sources of entropy This is so true. And the beauty is that with algorithms, we don't even need to know much about the entropy to be able to extract it. There is the Von Neumann method of generating an unbiased coin from a biased coin. Of throwing it twice, and checking if you got HT or TH. And completely discarding all HH or TT results. It doesn't matter if the coin you are using is 20%…
> There is the Von Neumann method of generating an unbiased coin from a biased coin. Of throwing it twice, and checking if you got HT or TH. And completely discarding all HH or TT results. It doesn't matter if the coin you are using is 20% or 80%, the result will be a true 50/50. This blew my mind. Thank you! I had to think about it a bit, so for anyone scratching their head right now trying to figure it out, conside…
Thanks for your explanation. I did not get it in the first read, and was too lazy to think, until saw your comment.
Just want to point out, that one is actually doing the experiment with a biased coin, then one must ignore all pairs.
e.g in case a coin which is heavily biased, say .9 H and .1 T. One should start with ignoring all the HH pairs, and start only at odd index. Lest, one picks a value like HHHHT (in the case the 2nd HH pair was not skipped, instead they greedily picked up the first HT, which will make the experiment HT biased).