4 ms·

I don't get why this is interesting. The RFC for UUID type 4 says the digit "4" must be set on the 14th byte. The loop checks to see if this is the case, and lo

I don't get why this is interesting. The RFC for UUID type 4 says the digit "4" must be set on the 14th byte. The loop checks to see if this is the case, and loops if it is. Unsurprisingly the UUID generator returns valid type 4 UUIDs so the loop is infinite. This is like making a blog post called "From Integers to Infinite Loops" and then creating a loop that tests if 1==1. I mean, yes it's an infinite loop, but why is that worth blogging about? PS: I tried commenting this on the actual site as well.

madsbuch 3y ago
The question is more why this is HN worthy. The fact that people blog about trivial results should be celebrated. After all, it is blogging.
- dmvdoug 3y ago
  Indeed. I think one potential cure to what most people here recognized as the enshittification of the internet would be if people just blogged about things that interested them, regardless of whether some third-party thinks the topic(s) merited.
  - adamnaga 3y ago
    [flagged]
- lolsal 3y ago
  I’ve been using uuids for over a decade and didn’t realize there were fixed bits in version 4. I learned something and am thankful it was posted here. Much more interesting than a lot of other submissions.
susam 3y ago
> The RFC for UUID type 4 says the digit "4" must be set on the 14th byte. The loop checks to see if this is the case, and loops if it is. The RFC for UUID type 4 states that bits 48 through 51 (0-based indexing) are set to 4, resulting in the character at position 14 (0-based indexing) of the hyphenated string representation being '4'. Also, this post does a little more than that. It also notes that the version 4 UUIDs we use in software today are variant 10₂ UUIDs. This is quite unsurprising too because the other variants are reserved. There is a second infinite loop in the post that demonstrates this by testing the two bits that represent the variant number. > why is that worth blogging about? Hello! I am the author of this post. This is my weblog, so I log about things that I find interesting here. In this case, the interesting thing for me was not so much that we can make an infinite loop out of a triviality but the triviality itself, i.e., not all bits of variant 10₂ of version 4 UUIDs are random, and then finding the sections in the RFC that define these bits. The infinite loops only serve as demos that there are definitely six bits that are not random. Indeed the infinite loop is just testing whether a version 4 variant 10₂ UUID is a version 4 variant 10₂ UUID and that is bound to be an infinite loop. However, I also wanted to document on my weblog where exactly the version and variant bits are located along with references to the relevant sections of the RFC. That is slightly less trivial than documenting that 1 is 1. I understand this is not going to be interesting to everyone. But this is my weblog, so I don't have to subscribe to others' notion of what is interesting to decide what I must add to my own weblog. I believe a more meaningful question would be whether this post is worthy of HN or not. Well, the moderators and the community determine that by voting with their fingers. In this case, it looks like this post is indeed not too interesting for HN, so I would have agreed with you if that were your point.
- muhehe 3y ago
  I agree with both of you. It is quite weak article with weird jump to the infinite loop. But then again you are right too - it's your blog you can write whatever you want. Don't get discouraged and keep doing what you like!
  - susam 3y ago
    Thank you for your comment! About the weird jump to the infinite loop, it is meant to be a quick-and-dirty demonstration of the fixed bits. It serves as an alternative to visually checking the fixed bits and confirming that they agree with the RFC. However, after reading some of the comments here, I realise that the original title of the post was creating the impression that the post may contain something more interesting than its actual content which is simply a discussion of the fact that there are six fixed bits in version 4 UUIDs. I have now updated the title of my post to: Fixed Bits of Version 4 UUID. P.S. Thanks to @dang for making the corresponding update to the title of this story on HN.
    - marcus_holmes 3y ago
      Thank you for taking the criticism positively :)

madsbuch 3y ago

The question is more why this is HN worthy. The fact that people blog about trivial results should be celebrated. After all, it is blogging.

dmvdoug 3y ago
Indeed. I think one potential cure to what most people here recognized as the enshittification of the internet would be if people just blogged about things that interested them, regardless of whether some third-party thinks the topic(s) merited.
- adamnaga 3y ago
  [flagged]
lolsal 3y ago
I’ve been using uuids for over a decade and didn’t realize there were fixed bits in version 4. I learned something and am thankful it was posted here. Much more interesting than a lot of other submissions.

susam 3y ago

> The RFC for UUID type 4 says the digit "4" must be set on the 14th byte. The loop checks to see if this is the case, and loops if it is. The RFC for UUID type 4 states that bits 48 through 51 (0-based indexing) are set to 4, resulting in the character at position 14 (0-based indexing) of the hyphenated string representation being '4'. Also, this post does a little more than that. It also notes that the version 4 UUIDs we use in software today are variant 10₂ UUIDs. This is quite unsurprising too because the other variants are reserved. There is a second infinite loop in the post that demonstrates this by testing the two bits that represent the variant number. > why is that worth blogging about? Hello! I am the author of this post. This is my weblog, so I log about things that I find interesting here. In this case, the interesting thing for me was not so much that we can make an infinite loop out of a triviality but the triviality itself, i.e., not all bits of variant 10₂ of version 4 UUIDs are random, and then finding the sections in the RFC that define these bits. The infinite loops only serve as demos that there are definitely six bits that are not random. Indeed the infinite loop is just testing whether a version 4 variant 10₂ UUID is a version 4 variant 10₂ UUID and that is bound to be an infinite loop. However, I also wanted to document on my weblog where exactly the version and variant bits are located along with references to the relevant sections of the RFC. That is slightly less trivial than documenting that 1 is 1. I understand this is not going to be interesting to everyone. But this is my weblog, so I don't have to subscribe to others' notion of what is interesting to decide what I must add to my own weblog. I believe a more meaningful question would be whether this post is worthy of HN or not. Well, the moderators and the community determine that by voting with their fingers. In this case, it looks like this post is indeed not too interesting for HN, so I would have agreed with you if that were your point.

muhehe 3y ago
I agree with both of you. It is quite weak article with weird jump to the infinite loop. But then again you are right too - it's your blog you can write whatever you want. Don't get discouraged and keep doing what you like!
- susam 3y ago
  Thank you for your comment! About the weird jump to the infinite loop, it is meant to be a quick-and-dirty demonstration of the fixed bits. It serves as an alternative to visually checking the fixed bits and confirming that they agree with the RFC. However, after reading some of the comments here, I realise that the original title of the post was creating the impression that the post may contain something more interesting than its actual content which is simply a discussion of the fact that there are six fixed bits in version 4 UUIDs. I have now updated the title of my post to: Fixed Bits of Version 4 UUID. P.S. Thanks to @dang for making the corresponding update to the title of this story on HN.
  - marcus_holmes 3y ago
    Thank you for taking the criticism positively :)