Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Every V4 UUID

everyuuid.com

Post reply on HN
Print view View original

281–290 of 381 posts

Re: Every V4 UUID

#281

Post by zzo38computer »

Dylan16807 wrote: post #255
saagarjha wrote: post #247

Earlier quoted context omitted.

The last line of https://xkcd.com/566/ , except it's UUID formats.

Are you suggesting we should never have made the random one, and stuck with mac address plus timestamp forever?

I think object identifiers would be better, althoug they should add another arc that does not require registration, based on: (fixed prefix).(type of identifier).(number of days past epoch).(parts according to type of identifier).(optional extra parts). (I had partially written my proposal, and I would want ITU and/or ISO (preferably ITU) to approve it and then manage it.) For example, type 0 could mean international telephone numbers, type 1 could mean version 4 IP address, type 2 could mean domain names (encoding each part as bijective base 37, from right to left), 3 could mean a combination of geographic coordinates with radio frequencies, 4 could mean telephone numbers with auto-delegated telephone extensions, etc. (I had also considered such things as automatic delegation, clock drift, etc; it is more carefully considered than UUID and some other types of identifiers.)

Re: Every V4 UUID

#282

Post by saagarjha »

Dylan16807 wrote: post #274
saagarjha wrote: post #260

Earlier quoted context omitted.

I actually believe we shouldn't have made any of them

Oh okay. That's a pretty different suggestion from the comic. Would you suggest random 128 bit numbers, then? Otherwise it's hard to see what else would serve the same role without being UUID in a trenchcoat. And having identifiers is important.

Yeah I would really like if UUID was just 128 bits of randomness and nothing else. The whole version thing sucks, and my point (which you are right in that the ordering is a little off) is that UUIDv4 is the only good one and the rest basically should not exist. UUIDv4 itself is ruined by the fact that it needs to have a version embedded in it because the other ones exist.

Re: Every V4 UUID

#283

Post by shwouchk »

Terr_ wrote: post #153
lxgr wrote: post #121

Earlier quoted context omitted.

A great example of Teller's observation that "sometimes magic is just someone spending more time on something than anyone else might reasonably expect."

> Ninety per cent of most magic merely consists of knowing one extra fact. -- Night Watch by Terry Pratchett

Thanks for this reference to one of my favorite books of all time, out of one of my favorite series of all time

Re: Every V4 UUID

#285

Post by chrismorgan »

> Browsers do not want to render a window that is over a trillion trillion pixels high, so I needed to handle scrolling and rendering on my own

What’s fun is what actually happens when you try to do these things. It’s disappointing, you can’t even get anywhere near one trillion pixels.

The limits I found five years ago when working at Fastmail, after a customer using IE found their scrollbar broke when they had around 200,000 emails in a mailbox (plus I just checked a couple of them again now):

• Firefox: a few years ago, ignored declarations that resolved to a value higher than 17,895,697 pixels (a smidgeon under 2³⁰ sixtieth pixels). Now, it clamps at that point instead, but maybe three pixels more or less, not immediately clear quite what’s going on and I can’t be bothered investigating. (All browsers seem to have inconsistencies in how clientHeight/getBoundingClientRect/dev tools/whatever report things, that close to the boundaries of possibility. It’s mildly fascinating.)

• IE: ignores declarations that resolve to a value equal to or higher than 10,737,418.23 pixels (2³⁰ − 1 hundredth pixels).

• WebKit: clamps values somewhere around 2²⁵ (~33,554,432) pixels.

• Chromium: matched WebKit when I tested, now it’s clamping around 22,360,882 pixels, but I’m on a 1.5× display, so the 2²⁵ could be connected with device pixels or such. But I think I was on a 2× display when I did the initial testing!

See also https://news.ycombinator.com/item?id=34299569 where I wrote more about it, with links to relevant source code.

Re: Every V4 UUID

#287

Post by textlapse »

I got it to search e1e1e0 and got it up to twice.

Repeating it three times though I couldn’t (even with dashes added). :) I am sure I am holding the phone wrong.

0d42d789-fd08-44ec-a46e-e1e10e1e10e1

Re: Every V4 UUID

#288

Post by dirkc »

I love this kind of thing!

Now all I need to do is hold my finger on the down arrow and keep watching for a *little* while to see every V4 UUID.

Re: Every V4 UUID

#289

Post by Dylan16807 »

zzo38computer wrote: post #281
Dylan16807 wrote: post #255

Earlier quoted context omitted.

Are you suggesting we should never have made the random one, and stuck with mac address plus timestamp forever?

I think object identifiers would be better, althoug they should add another arc that does not require registration, based on: (fixed prefix).(type of identifier).(number of days past epoch).(parts according to type of identifier).(optional extra parts). (I had partially written my proposal, and I would want ITU and/or ISO (preferably ITU) to approve it and then manage it.) For example, type 0 could mean international…

Sounds like you're in the realm of URNs? I don't know about that description, I think there's a benefit to a short and fixed-size ID. Though maybe for the domain name example you could have an alternate form that hashes any domain that goes over 20-30 characters.
Post reply on HN