4 ms·

I really want one of these to take a git sha1 and make a unique code name for continuous releases ... but I haven't wanted to take the time to make sure no part

I really want one of these to take a git sha1 and make a unique code name for continuous releases ... but I haven't wanted to take the time to make sure no particular word combos wouldn't be offensive. And 160 bits is quite a large domain, but I think occasional rare duplicates would be ok. Has anyone already solved this?

sillysaurusx 5y ago
I (ab)use gfycat. #!/bin/sh curl -s -X POST "https://api.gfycat.com/v1/gfycats" -H "Content-Type: application/json" | exec jq .gfyname -r It generates a name like HardDisastrousJaguar. Thus far, all other code name formats seem to suck -- e.g. they're 12 words, they don't start with adjectives and end with nouns, etc. So the trick is to map a specific continuous release back to a name like HardDisastrousJaguar. Any ol' database would do the trick. And the best database is the code release itself; you can throw the above code into your continuous release process to generate a unique name during the release. But, like you, I would love it if there was a way to map 160 bits to a name like HardDisastrousJaguar without relying on external services. Unfortunately, us nerds seem to get caught up on correctness ("There might be collisions! We need 12 words for 160 bits!") while losing sight of the fact that it's supposed to be for humans to read. HardDisastrousJaguar is memorable; <12 random english words> is better than 160 random bits, but it's a long way from HardDisastrousJaguar.
- collegeburner 5y ago
  There's a bitcoin wordlist that can encode 2^11 bits per word, so 3 words could hold a 32-bit hash. You'd need a pretty large wordlist for 3 words to hold 128 bits.
  - sillysaurusx 5y ago
    Collisions are fine. The point is to give it a memorable name, not to represent 128 bits. (It's the same reason a CRC is 32 bits.)
  - adzm 5y ago
    Do you have a link or reference to this word list? Additionally with just 256 words you can easily do four words for 32 bits.
    - deleted 5y ago
      [deleted]
    - gruez 5y ago
      https://github.com/bitcoin/bips/blob/master/bip-0039/bip-0039-wordlists.md https://github.com/bitcoin/bips/blob/master/bip-0039/bip-003...
Zababa 5y ago
I think it has been solved a good amount of time considering how frequent the list of adjectives and names are on "modern" websites. I don't know if any of these implementations is FOSS though.
ay 5y ago
Just an idea, even if it may not sound as cool: Why not use a number YYYY.mmm.dd.seq (seq being the ordinal number of the commit within a 24h UTC period starting at 00:00Z), and you would get something that is relatively easily parsed by humans (you can omit year/month when talking about recent releases), has a simple 1:1 mapping to the git commit, and has the added benefit of being easily sortable - if you zero-pad the numbers, it will become lexicographically sortable without losing much readability. This assumes you only release from one branch, of course.

sillysaurusx 5y ago

I (ab)use gfycat. #!/bin/sh curl -s -X POST "https://api.gfycat.com/v1/gfycats" -H "Content-Type: application/json" | exec jq .gfyname -r It generates a name like HardDisastrousJaguar. Thus far, all other code name formats seem to suck -- e.g. they're 12 words, they don't start with adjectives and end with nouns, etc. So the trick is to map a specific continuous release back to a name like HardDisastrousJaguar. Any ol' database would do the trick. And the best database is the code release itself; you can throw the above code into your continuous release process to generate a unique name during the release. But, like you, I would love it if there was a way to map 160 bits to a name like HardDisastrousJaguar without relying on external services. Unfortunately, us nerds seem to get caught up on correctness ("There might be collisions! We need 12 words for 160 bits!") while losing sight of the fact that it's supposed to be for humans to read. HardDisastrousJaguar is memorable; <12 random english words> is better than 160 random bits, but it's a long way from HardDisastrousJaguar.

collegeburner 5y ago
There's a bitcoin wordlist that can encode 2^11 bits per word, so 3 words could hold a 32-bit hash. You'd need a pretty large wordlist for 3 words to hold 128 bits.
- sillysaurusx 5y ago
  Collisions are fine. The point is to give it a memorable name, not to represent 128 bits. (It's the same reason a CRC is 32 bits.)
- adzm 5y ago
  Do you have a link or reference to this word list? Additionally with just 256 words you can easily do four words for 32 bits.
  - deleted 5y ago
    [deleted]
  - gruez 5y ago
    https://github.com/bitcoin/bips/blob/master/bip-0039/bip-0039-wordlists.md https://github.com/bitcoin/bips/blob/master/bip-0039/bip-003...

Zababa 5y ago

I think it has been solved a good amount of time considering how frequent the list of adjectives and names are on "modern" websites. I don't know if any of these implementations is FOSS though.

ay 5y ago

Just an idea, even if it may not sound as cool: Why not use a number YYYY.mmm.dd.seq (seq being the ordinal number of the commit within a 24h UTC period starting at 00:00Z), and you would get something that is relatively easily parsed by humans (you can omit year/month when talking about recent releases), has a simple 1:1 mapping to the git commit, and has the added benefit of being easily sortable - if you zero-pad the numbers, it will become lexicographically sortable without losing much readability. This assumes you only release from one branch, of course.