Talk:Universally unique identifier

Bring back the stat!

I am saddened that this article no longer includes this stat in the opening paragraph: "A UUID is a 16-byte (128-bit) number. The number of theoretically possible UUIDs is therefore 216*8 = 2128 = 25616 or about 3.4 × 1038. This means that 1 trillion UUIDs would have to be created every nanosecond for 10 billion years to exhaust the number of UUIDs." It made the article several times more readable, and gave the context straight away, even if it is not genuinely of mathematical use... — Preceding unsigned comment added by 87.127.211.206 (talk) 13:37, 25 August 2011 (UTC)

Doesn't a 128-bit number have 2^128 possible values (where ^ means "raised to the power"). I don't understand the phrase "216*8 = 2128 = 25616 or about 3.4 × 1038". 2128 is not equal to 25616, and 216*8 is not 2128.

I have read, elsewhere, that there are enough UUIDs to assign one to every atom in the known universe. On the other hand, http://en.wikipedia.org/wiki/Observable_universe says that the known universe has about 10^80 atoms. I think that 10^80 is about 2^265, which is larger than 2^128. I'm confused. 75.146.141.142 (talk) 22:19, 27 April 2012 (UTC)

We need more material in this article

As a Linux user, I understand the importance and awesomeness of UUIDs. However, I'd like to know more. For instance, when did the idea of UUID come into creation? When was it created as a set standard? What I'm trying to say is that this article needs more dates, years, names of people related to those things. --Cyberman (talk) 02:31, 14 June 2008 (UTC)

ETC

What is Leach-Salz? --Abdull 15:16, 4 April 2007 (UTC)

The UUID variant described in RFC 4122, "A Universally Unique IDentifier (UUID) URN Namespace", by Paul Leach, Michael Mealling, and Rich Salz. Guy Harris 17:44, 4 April 2007 (UTC)

Perfect answer, thank you very much! I first thought it has something to do with salt... --Abdull 18:55, 4 May 2007 (UTC)

private-use UUIDs?

The article doesn't make clear if there is a "private-use" address space for UUIDs, i.e., some rules to create UUIDs not intended to be exported from a closed system, like we have IPv4 and IPv6 private networks, Unicode's Private Use Area, the .local domain name, local-use EAN-13 barcodes and so on... The most logical idea is to use a specific reserved version number, but the RFC 4122 doesn't seem to mention anything other than the 5 versions (clock, dce, md5, random and sha1). --Juliano (T) 01:39, 20 August 2007 (UTC)

AFAIK there are not such "private use" UUIDs. The inventors of these UUIDs claim that the collision risk is small enough that in practise there are no collisions, so there is no need for "private use" UUIDs. --81.27.124.161 (talk) 21:22, 9 April 2008 (UTC) (RokerHRO)

AFAIK?? Seems like that acronymn is a good example of private use UUIDs. The acronym is unintelligible, its meaning known only to only a select few ... as the link provided demonstrates.

K. Kellogg-Smith (talk) 13:09, 20 October 2011 (UTC)

Collisions

"This means that 1 trillion UUIDs would have to be created every nanosecond for 10 billion years to exhaust the number of UUIDs." this leads to misunderstanding. While the number space is that big, chance for a collision are much higher, indeed! I.e. see http://en.wikipedia.org/wiki/Birthday_paradox —Preceding unsigned comment added by 84.129.161.7 (talk) 03:16, August 30, 2007 (UTC)

Duplicate UUID's on hosts

IS it possible to have same valid UUID on multiple hosts in a network? —Preceding unsigned comment added by 128.222.37.20 (talk) 05:15, 13 September 2007 (UTC)

It is, but very unlikely as explained in the article if the UUIDs are chosen randomly. --81.27.124.161 (talk) 21:24, 9 April 2008 (UTC) (RokerHRO)

"Well Known" UUID's

Perhaps a section should be added to list some well known UUIDs. The article already uses the MS IUnknown UUID as an example of such a UUID - however a more exhaustive list of "known" aka documented UUIDs that are for specific uses should be added.Myrdred (talk) 16:43, 9 February 2008 (UTC)

Am I the only one horrified by this idea?

What a terrible idea! So basically because we can't be bothered to create a central listing of things, we're just generating an enormous gillion-character string and "hoping" that since it's so big it's not going to collide?! This is used in ext3?! Wow I feel great knowing that the only reason my filesystem isn't catastrophically corrupted is because I'm lucky. This type of thing might have limited applications where it's impossible to safely merge IDs that could potentially collide (can't imagine why it would be impossible but maybe for some crazy deep space probe where energy can't be spared for merging processing and high bandwidth is critical), but for labelling articles on E's website?! This is terrible programming! :D\=< (talk) 02:11, 2 March 2008 (UTC)

It is not enormous, it is not gillion-character, and it is not a string. It is a 128-bit number. The purpose of UUID is to be used when you simply don't have any means of using a central registry. Two autonomous systems, with no previous established communication between them, or access to the Internet may create lots of objects identified by UUIDs, than they can merge together into one, and their objects will still be unique.

Or do you really want to force everyone making a filesystem on a newly-installed system to have an Internet connection, in order for mke2fs to connect to a central registry to create the UUID of your partition? And even in the remote possibility of two objects in the universe having the same UUID, it is easier to believe in the existence of the Invisible Pink Unicorn than they happening to coexist on the same context.

Your filesystem won't be catastrophically corrupted just because it has the same UUID of a news article on some website. It won't be corrupted even it there was another object on the same computer with the same UUID. You have to be extremely unlucky to get two partitions with the same UUID on the same computer, and even so, your biggest problem will be referencing one of them by UUID when mounting, something very simple to fix.

The principle is the same of hashing. For mission-critical systems, you either won't depend on UUIDs or will properly handle UUIDs so that they don't collide or collisions will be treated accordingly.

--Juliano (T) 17:00, 9 March 2008 (UTC)

And how is a filesystem not mission-critical? And give one example where you can't have a central registry. I don't understand why partitions have UUIDs- they're already registered in the drive's partition table, and each hard drive's partitions are numbered and made available by the BIOS. No need for an internet connection of course. Obviously there are cases where data needs to be merged and still have a unique identifier but if you actually give some processing to sorting through the data and preventing collisions, reissuing identifiers, and generally doing what a merge should be doing, then you have no problems. It's a lot slower than just issuing huge UUIDs to everything and crossing your fingers, which does work, but come on! How ugly! This is not the right thing. :D\=< (talk) 15:19, 10 March 2008 (UTC)

Yes, sure a filesystem is mission-critical... but the data contained into it, not its identification along all the partitions of the system. Once you build a mission-critical system, the UUIDs of the partitions are set on stone and won't change anymore during its mission-critical activity. You use UUIDs only to identify each partition among the others, only. Once mounted, the kernel uses its (major, minor) tuple to access it. And you are thinking too strictly... forget the BIOS and the drive's partition table. A computer is not restricted to having a single drive.

Think you have 2 hard drives on your computer, each one with a few partitions, and each partition identified by its UUID. If you consider the possibility of changing their internal connections, referring them by their /dev/sdXY path becomes inherently broken. Using UUIDs, you buy a new SATA PCI card and move one of the disks to it, the system will boot with all mount points in place, like if nothing changed. Or you buy an USB enclosure, put the other disk into it and plug it into the USB port, the system will still boot and mount all the partitions properly on their mount points, since they still have the same UUIDs they had when created. You bring a hard drive from a friend, and plug it anywhere on your system reassured that it would be easier to win three consecutive times the Lottery's full-prize than having his partitions colliding with yours (unless he knew beforehand one of your systems partitions UUID and set on his drive, but this is another problem).

With dynamic and redundant disk systems, like LVM and RAID, where disks and partitions may be freely moved and newly ones added, UUIDs are even more important. You ask for one example where you can't have a central registry... disk partitioning is pretty much an excellent example. Creating and formatting RAID partitions on hardware RAID implementations are done by the BIOS, before the operating system is loaded. How you can think of using a central registry in this case?

I work with distributed computing, process migration and some grid computing. We use UUIDs extensively to identify nodes, tasks and all sort of objects being processed and passed around. Objects must be unique on a system that is not fully connected. Sections of the system get disconnected from the rest and get reconnected a few hours later. The idea of a central registry for UUIDs is simply crazy and stupid. Half the objects created don't even live for more than a few seconds. A central registry not only would slow everything down, it would break its mobility and create a single point of failure, for no added value. Such a distributed system is inherently designed with fault-tolerance in mind, since you may spawn a task to a node, the node crashes and you won't ever receive its answer back. UUID collision is not even considered, it is a non-issue.

And talking about BIOS, your worst nightmare is already becoming true. The BIOS is obsolete and is currently being replaced with the Extensible Firmware Interface, which in turn replaces the old and obsolete Master Boot Record with the new GUID Partition Table, heavily based on UUIDs. Sorry.

--Juliano (T) 17:19, 10 March 2008 (UTC)

Froth, I thought about this problem too. I guess I would feel safer if all programs that use UUID's are written to handle UUID collisions safely, but I guess the probability of collision is known to be too small to bother with. I wonder if there are many life-and-death applications that blindly depend on uniqueness of UUIDs, e.g.avionics, railways, medical equipment. Perhaps only the most hardnosed engineer/mathematician-types would feel safe. Glueball (talk) 11:47, 21 April 2008 (UTC)

xxxxxxxx-xxxx-3xxx-xxxxxxxxxx

This pattern is supplied in the section on Version 3 UUIDs. Isn't there a group of four hex digits missing here? I hesitate to correct it myself in case I'm missing a key point about version 3. Jimgawn (talk) 18:36, 11 April 2008 (UTC)

 Fixed. You are right. It should be (and now is) xxxxxxxx-xxxx-3xxx-xxxx-xxxxxxxxxxxx . --68.0.124.33 (talk) 06:07, 15 January 2009 (UTC)

Also it would be better write "340 282 366 920 938 463 463 374 607 431 768 211 456 possible UUIDs", in stead of "There are 340,282,366,920,938,463,463,374,607,431,768,211,456 possible UUIDs". — Preceding unsigned comment added by Palladipeloarancione (talk • contribs) 13:47, 5 April 2012 (UTC)

Where UUID stored?

Please say where the UUID number is stored in flash memory cards.

I have a CF card that shows up as

/dev/disk/by-uuid/2004-1223 -> ../../sdb1

and an SD card that doesn't seem to have a UUID. Can one use e.g., the GNU/Linux dd command to see where the UUID is stored? Jidanni (talk) 01:24, 13 July 2008 (UTC)

It is not a property of the SD card, but of the partitions contained in it. It is part of the filesystem, depending on which filesystem you have in it. This number (2004-1223) is most likely to be a 32-bit FAT volume serial number, which is not an UUID as described in this article.

This number is chosen when you create the filesystem in (ie, format) the SD card. On Linux, you may force a given number by passing the -i xxxxxxxx parameter to mkdosfs.

The FAT article tells exactly where the serial number is stored inside the partition, but this is out of the scope of this article. UUIDs are not used by Windows to identify its partitions.

--Juliano (T) 17:35, 13 July 2008 (UTC)

Is there an error or am I a bad counter?

I think, that 8+4+4+4+12=32 not 36? —Preceding unsigned comment added by BartekBl (talk • contribs) 20:19, 14 November 2008 (UTC)

32 hexadecimal digits, plus 4 dashes, equals to 36 characters in the textual representation. --Juliano (T) 11:31, 15 November 2008 (UTC)

NCS UUID

When I first came across UUIDs they always seemed to be referred to as NCS UUIDs, but there is no mention of NCS in the article. I don't know where NCS fits in, but I would like to. —Preceding unsigned comment added by 170.148.215.156 (talk) 14:16, 5 March 2009 (UTC)

Too many implementations

Am I the only one who thinks that mentioning implementations of UUIDs in every possible language/environment (29 currently) only clutters the article and doesn't belong to encyclopedia? I think the section should either be removed or shortened a lot. Svick (talk) 18:55, 7 October 2009 (UTC)

I think it's useful to continue to include them. They might be moved to List of UUID implementations, but that seems like overkill. Maybe change the list to a toggled table? Ant (talk) 15:29, 19 November 2010 (UTC)

Why do you think it's useful? Could you elaborate on that? Keep in mind that Wikipedia is not a repository of links. Svick (talk) 17:51, 20 November 2010 (UTC)

"Sufficient entropy" requirement for collision avoidance

However, these probabilities only hold when the UUIDs are generated using sufficient entropy. [1]

This is true, but it seems to gloss over an important factor. Some UUID allocation schemes are deliberately running with reduced entropy. On the same page, for example, SQL Server's NEWSEQUENTIALID() is mentioned, and there's the practice of overwriting a portion of the GUID with predictable information, for example the wFormatTag/GUID conversion used in WAVE_FORMAT_EXTENSIBLE headers. I don't assert that either of these examples drastically reduce the safety of the system, but similar implementations may be more greedy with the number of predictable bits, and substantially increase the risk of collision. --ToobMug (talk) 13:36, 10 February 2010 (UTC)

Such schemes generally use the MAC address based form of UUIDs. Those do not depend on entropy for uniqueness, only the improbability of generating two UUIDs exactly 2^60 / 10 ^ 7 seconds (which is more than 3600 years) apart and expecting them to differ. Everything else is by central authority: First digits of MAC address allocated by IEEE to hardware maker, remaining digits of MAC allocated by hardware maker (one per card made), 60 bit Date/time allocated by the clock on the computer with that card, 14 bit reboot counter allocated by OS of that computer, variant and type bits fixed by standard. To generate sequential UUIDs with this scheme, simply reserve a continuous time interval of the needed number of 100ns units, and allocate them all as a block from the system daemon/facility that ensures only one program gets the UUID for a given moment in time. 77.215.46.17 (talk) 23:38, 18 April 2011 (UTC)

Compress the Implementations section?

Would anybody mind if I replaced the entire Implementations section with just a list of languages in which implementations exist (to give a feel for how widespread adoption is) and all the citations? I think that would improve overall readability of the article and detract almost nothing from the content. Anybody who is looking for a specific implementation need only google "uuid <language name>". -- RoySmith (talk) 18:05, 26 June 2011 (UTC)

Yes, I would mind. Implementations are not always conformant (e.g. CouchDB's) or may offer differing features, licensing, be target for different compilers, etc. Lambda-mon key (talk) 01:17, 24 August 2011 (UTC)

"In perspective"

Regarding the paragraph "To put these numbers into perspective, one's annual risk of being hit by a meteorite...", this is bad exposition. People are notoriously bad at having an intuition for these types of odds, so if your goal is to assess risk, this isn't helpful. — Preceding unsigned comment added by 17.209.4.116 (talk) 06:19, 23 February 2012 (UTC)

entropy

the Author wrote: >>However, these probabilities only hold when the UUIDs are generated using sufficient entropy. >>Otherwise the probability of duplicates may be significantly higher, since the statistical dispersion may be lower.

So what is required to provide "sufficient entropy?" — Preceding unsigned comment added by Eostermueller (talk • contribs) 15:37, 24 February 2012 (UTC)