Talk:Universally unique identifier

From Wikipedia, the free encyclopedia
Jump to: navigation, search
          This article is of interest to the following WikiProjects:
WikiProject Systems  
WikiProject icon This article is within the scope of WikiProject Systems, which collaborates on articles related to systems and systems science.
 ???  This article has not yet received a rating on the project's quality scale.
 ???  This article has not yet received a rating on the project's importance scale.
Taskforce icon
This article is not associated with a particular field. Fields are listed on the template page.
 
WikiProject Computing / Software (Rated Start-class)
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Start-Class article Start  This article has been rated as Start-Class on the project's quality scale.
 ???  This article has not yet received a rating on the project's importance scale.
Taskforce icon
This article is supported by WikiProject Software.
 
WikiProject Free Software / Software / Computing  (Rated Start-class)
WikiProject icon This article is within the scope of WikiProject Free Software, a collaborative effort to improve the coverage of free software on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Start-Class article Start  This article has been rated as Start-Class on the project's quality scale.
 ???  This article has not yet received a rating on the project's importance scale.
Taskforce icon
This article is supported by WikiProject Software.
Taskforce icon
This article is supported by WikiProject Computing.
 

LVM UUID / Non-standard UUIDs[edit]

The Logical Volume Manager (Linux) seems to use a non-standard form of UUID using digits and upper and lowercase letters, for a space of size 62^32 = 2.27x10^57 or 2^190. An LVM UUID of "VexQRf-qHxg-dQ8N-AM6r-Xtf0-WvItBa" does not fit the standard referenced in this article. The LVM code at http://git.fedorahosted.org/git/?p=lvm2.git;a=tree;f=lib/uuid;hb=HEAD documents the implementation. Should the page cover non-standard UUIDs like this? Drf5n (talk) 20:15, 30 July 2012 (UTC)

Not the only one horrified...[edit]

..but perhaps for a different reason, namely that UUIDs involve, in principle, the computer telling lies to the user about what an object's real name or identifier is. A disk partition is not /dev/sda1, it is actually 87937597593793753.... A user in Active Directory, likewise. This is obfuscation of the worst possible kind, and ought to be avoided if at all possible. It creates numerous operational difficulties where legitimate and normal changes to a computer give rise to unexpected and unpredictable results, and in some circumstances can cause backups to be unusable or data to be lost. --Anteaus (talk) 19:10, 13 September 2012 (UTC)

Fortunately, in most of the examples you mention, the computer is not lying. The thing has one or more names and one or more numbers, some of those numbers happen to be UUIDs. A disk partition is /dev/sda1 (meaning the first partition on the first disk that uses a libscsi driver with your current kernel and boot timing), partition # xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx in the GPT partition table on disk # yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy, the partition named "MyHomes" inside its superblock, the partition numbered zzzzzzzz-zzzz-zzzz-zzzz-zzzzzzzzzzzz inside itsown superblock and the partition currently mounted as /home until you change your mind. A user in active directory is user RID #1011 in domain foo.example (which has # S-1-5-21-yyyyyyyyy-yyyyyyyyy), it is also SID S-1-5-21-yyyyyyyyy-yyyyyyyyy-1011, user "John Doe", login username jd@foo.example and AD object {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}. Users can (with some difficulty) see all these numbers and names, but tends to prefer some to others.
The operational difficulties are mostly caused by the other numbers, not the UUIDs, or by trying to use configuration files that refer to UUIDs that were not restored (such as creating a new filesystem with a new UUIDs and then restoring an /etc/fstab that refers to those UUIDs, or upgrading to a kernel that renames /dev/hda1 to /dev/sda1 as happened recently to all Linux users).
I will admit though that some recent operating systems (from both camps) tend to go out of their way to hide the real names of things from users, resulting in much operational difficulty, but the UUIDs are the least of the problems here, using pretty names such as "John Doe" while hiding the more specific names such as "jd" is a much bigger problem.
77.215.46.17 (talk) 03:43, 26 November 2012 (UTC)

Why the format?[edit]

One thing this article currently doesn't address is WHY this canonical format was chosen: Why 8-4-4-4-12, instead of 8-8-8-8, or 4-4-4-4-4-4-4-4, or something else altogether? Having 5 blocks of variable size (instead of power-of-2 blocks of fixed size) just doesn't look like something an IT guy would normally do. I guess it might have to do with the blocks using information from different sources in the initial scheme of MAC address+time, but I'm not sure about that. If information about this exists, it would be nice if it was added to the article. -- 91.48.253.170 (talk) 09:12, 3 April 2013 (UTC)

If you read the RFC, it's fairly obvious why the 8-4-4-4-12 was chosen. The UUID is (originally, and mostly) a 64-bit integer timestamp, a 16-bit counter in case you generate UUIDs faster than once every 100ns, and a 48-bit MAC address. That would give you
AAAAAAAAAAAAAAAA-DDDD-EEEEEEEEEEEE
Except that most systems at the time did not have a native 64-bit integer construct. For example, Windows uses a structure (ULONGLONG) that glues two 32-bit values together. And when dealing the the UUID structure in memory, it is helpful to have the two 32-bit values:
AAAAAAAA-BBBBBBBB-DDDD-EEEEEEEEEEEE
Next is the issue that 4 bits inside the "B" chunk are stripped out, and used to indicate a version. In order to make addressing that value easy (either reading or writing), it helps to split the "B" chunk also into two 16-bit chunks:
AAAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEEEE
In other words, speaking as a programmer, it's obviously all a practical matter. Unfortunately in the original RFC the author didn't give what he was **thinking** at the time. So without any verifiable source of the author's thoughts (aside from the author himself telling us what he thought) there is no verifiable source. So if anyone explaining what i just said will have it removed from Wikipedia.
Pauladin (talk) 15:59, 10 April 2014 (UTC)