12 is very useful because it's divisible by 2, 3, and 4 -- the most common number of pieces you might want to cut a year into. (Same reason it's better to cut pizzas into 12 than 8 or 16...)
If you want a better calendar, make weeks six days long, months five weeks long, and throw a slush week of five or six days (depending on leap year) over christmas vacation. Then the number of months is divisible by 2, 3, and 4, and the number of weeks (not counting the slush week) by 2, 3, 4, and 5! And the number of days in a week would be divisible by 2 and 3, as opposed to our current 7 which is an annoyingly prime.
The obvious day to cut is Wednesday:
Mon = one
Tue = two
Thu = three
Fri = four
Coincidence?
And if you really want to confuse the world for the better, add two more digits to our vocabulary between nine and ten so we do all our math in base twelve. Wouldn't it be handy if ten were evenly divisible by 2, 3, and 4?
And Now for Something Completely Different
on
Pirate DNS?
·
· Score: 2
In the long run, the idea of a global name space doesn't make sense. Global identifier, yes, but not name. Here is a proposal for an alternate system:
Instead of having a single, context-insensitive name space, allow anyone to create a name space, or many. Bare with me here.. I'll try to illustrate how it would actually work in practice with some examples:
First, I would have my own name space (actually, I would have many; more on that below). This would essentially be a mapping from names as I know them to Poi numbers (Permanent Object Identifiers, a unique numbering space for everything--see below). Generally this would behave like a local cache, fairly transparent to the user. But the key point behind it is: when I use a name, I get what I got last time, period (unless I've gone out of my way to specifically reassign the name to something else). So, for instance, the Slashdot home page would have an associated Poi number (forever!), and in my name space it may simply be called "Slashdot". (Note, in practice I would have a specific name space for web pages, which would be different than my name space for email addresses, and so on, so in theory I could simply enter "Slashdot" in my web browser Goto: line and be there.) If slashdot moves to a new domain, or IP, or even changes its name to something else due to Microsoft inventing a time machine and going back in time to trademark the name, Slashdot would nonetheless keep the same Poi number (forever!) and so I'd still go where I wanted when I typed "Slashdot". Key point: the Poi space is effectively infinite and context independent (truly global) and has *no implicit mapping to reality whatsoever* so there is no risk of losing a Poi number over trademark, geographic, or network topology issues.
Next, say I do a Google search, and click on a link.. What happens? Well, the link just contains a Poi number (and optionally Google's name for it), so I'm brought straight to the web page (I'll discuss mapping Poi to IP's and whatnot below) and if I bookmark it, it's bookmarked by Poi number which means even if the web page is moved to a different host my bookmark still works. Note that by bookmarking it, I am effectively expanding my personal name space. Bookmarks would again be a separate name space from the generic "web page" namespace, though my browser may allow me to assign a name in that space too: E.g., I may have a bookmark called "Slashdot User Profile" which I also call "slashuser" in my "web page" namespace (so I can just type "slashuser" at the Goto: prompt). A simple utility could search all my name spaces to show me aliases of the same Poi in case I forget one.
Now, what if a friend wants to tell me a web page over the phone? In a pinch, he could read me the Poi number (a pain, but doable), but more likely he'd point me at a *common name space* and tell me the name. E.g., he'd say "Go to Yahoo/Companies/Redhat". Here it is assumed that Yahoo is already in my private name space (maybe it came with my browser; maybe I got it from a friend; whatever -- more on this below!), and the "/" is a path separator as in a file system, except that instead of assuming a hierarchy it's just a search through consecutive name spaces (may be arbitrarily complex graph, not a tree): Start with Yahoo (who's Poi I already know), ask Yahoo for Companies (returns a new Poi number -- namespaces themselves have Poi numbers too!), ask Companies for Redhat. Done!
So, in effect, it creates a competitive market for name spaces, which will most likely result in a few dominant players (e.g., Yahoo) at any given time, but affords no inherent monopoly to anyone. Note there is no one root! The "root" of the name space is implicit in the current body of popular name spaces!
Note also that the name spaces are of varying specificity, so for example say there are twenty companies in the country called "ACME Services" -- Yahoo/Companies/ACMEServices may return nothing, may return a list of all twenty, or may return a default one, according to Yahoo's (or the requester's?) choice, while Yahoo/Companies/California/SanDiego/ACMEServices may return just the one you're looking for.
Obviously the line between searching and DNS is being blurred here (see also Erik's post, subject: "This is bound to fail"), but the distinction from pure searching is that there would still be well-known name spaces (though many instead of just one) and the names within those spaces may still be concise and definitive so that, for instance, once I get yahoo/people/brandyn to Poi'nt to my page, I really can tell someone that over the phone and it's not like they have to do a Google search and sift through fifty returns (assuming yahoo was maintaining uniqueness in that particular name space).
Next there's the question of mapping Poi to IPs and whatnot, which could be implemented as a cached, distributed database -- ideally when you Get a Poi (e.g., via a Google link or whatnot), the Poi of the giver (Google) is also remembered with it, so when you look up a Poi, if it isn't already locally cached, you ask (first) the associated giver (Google) for the info. Once you actually get the Poi info, part of the record would be the current preferred giver, which would be the first place you would go later if the cached info proved antiquated. Typically, the preferred giver would be the host actually serving the Poi, which would provide forwarding service (that is, it would tell you who to ask instead) if the Poi were later moved away.
Note that what a Poi maps TO may change with time. For now, for instance, most Poi might map to urls (with hard-coded IP's in place of host names), but they could also map to other protocols/hardware addressing schemes entirely. The good thing about a Poi is it is NOT an IP address, nor a host name, nor an Appletalk node name, nor a filename, nor a phone number... it is just the universal "name" of the object you want to reach. Today it maps to an IP and url (or IP and port number for other services like telnet), but tomorrow who knows.
Lastly, there's the question of the Poi numbering space itself. How do you prevent monopoly concerns here? Obviously we need *some* central control (world-wide!), so I would propose something like this:
Some non-profit org would sell large chunks of Poi space -- let's say they sell chunks for $10 per bit, so I could buy 65K unique Poi from them for $160 (but I wouldn't -- read on). The presumption, then, is that other organizations would buy huge chunks of Poi space, and resell them at a lower cost per bit (but a higher cost per Poi). As an end-user, I ought to be able to get Poi practically free (ISPs could pay trivial fees to provide an endless supply to their users), to use for all sorts of things.... This scheme keeps Poi arbitrarily cheap while still not burdening the top-level Poi service with lots of small requests. Each re-seller would be responsible for verifying a Poi's authenticity, simply by identifying which block it came from and where that block was purchased (thus providing an audit trail straight back to the top level). Note that these services *only* assure uniqueness of the Poi -- they do not store any information about their use!
(I already have this set up on my machine for my personal use. Poi can be any number of bits, so you can't run out, and even if I chewed through them at thousands per second they still wouldn't get very large before the sun went cold.)
-Brandyn (Poi #1000000000000001b;)
"No one ever went broke underestimating the intelligence of the American public" -PT Barnum "Yeah, what he said!" -Bill Gates
Slashdot Mirror
Optimistic Muffin marketting.
Heh heh.
-Brandyn
Indeed! I routinely wait for the shower curtain to suck in before I get in the shower -- it sucks in as soon as the water gets hot!
12 is very useful because it's divisible by 2, 3, and 4 -- the most common number of pieces you might want to cut a year into. (Same reason it's better to cut pizzas into 12 than 8 or 16...)
If you want a better calendar, make weeks six days long, months five weeks long, and throw a slush week of five or six days (depending on leap year) over christmas vacation. Then the number of months is divisible by 2, 3, and 4, and the number of weeks (not counting the slush week) by 2, 3, 4, and 5! And the number of days in a week would be divisible by 2 and 3, as opposed to our current 7 which is an annoyingly prime.
The obvious day to cut is Wednesday:
Mon = one
Tue = two
Thu = three
Fri = four
Coincidence?
And if you really want to confuse the world for the better, add two more digits to our vocabulary between nine and ten so we do all our math in base twelve. Wouldn't it be handy if ten were evenly divisible by 2, 3, and 4?
Instead of having a single, context-insensitive name space, allow anyone to create a name space, or many. Bare with me here.. I'll try to illustrate how it would actually work in practice with some examples:
First, I would have my own name space (actually, I would have many; more on that below). This would essentially be a mapping from names as I know them to Poi numbers (Permanent Object Identifiers, a unique numbering space for everything--see below). Generally this would behave like a local cache, fairly transparent to the user. But the key point behind it is: when I use a name, I get what I got last time, period (unless I've gone out of my way to specifically reassign the name to something else). So, for instance, the Slashdot home page would have an associated Poi number (forever!), and in my name space it may simply be called "Slashdot". (Note, in practice I would have a specific name space for web pages, which would be different than my name space for email addresses, and so on, so in theory I could simply enter "Slashdot" in my web browser Goto: line and be there.) If slashdot moves to a new domain, or IP, or even changes its name to something else due to Microsoft inventing a time machine and going back in time to trademark the name, Slashdot would nonetheless keep the same Poi number (forever!) and so I'd still go where I wanted when I typed "Slashdot". Key point: the Poi space is effectively infinite and context independent (truly global) and has *no implicit mapping to reality whatsoever* so there is no risk of losing a Poi number over trademark, geographic, or network topology issues.
Next, say I do a Google search, and click on a link.. What happens? Well, the link just contains a Poi number (and optionally Google's name for it), so I'm brought straight to the web page (I'll discuss mapping Poi to IP's and whatnot below) and if I bookmark it, it's bookmarked by Poi number which means even if the web page is moved to a different host my bookmark still works. Note that by bookmarking it, I am effectively expanding my personal name space. Bookmarks would again be a separate name space from the generic "web page" namespace, though my browser may allow me to assign a name in that space too: E.g., I may have a bookmark called "Slashdot User Profile" which I also call "slashuser" in my "web page" namespace (so I can just type "slashuser" at the Goto: prompt). A simple utility could search all my name spaces to show me aliases of the same Poi in case I forget one.
Now, what if a friend wants to tell me a web page over the phone? In a pinch, he could read me the Poi number (a pain, but doable), but more likely he'd point me at a *common name space* and tell me the name. E.g., he'd say "Go to Yahoo/Companies/Redhat". Here it is assumed that Yahoo is already in my private name space (maybe it came with my browser; maybe I got it from a friend; whatever -- more on this below!), and the "/" is a path separator as in a file system, except that instead of assuming a hierarchy it's just a search through consecutive name spaces (may be arbitrarily complex graph, not a tree): Start with Yahoo (who's Poi I already know), ask Yahoo for Companies (returns a new Poi number -- namespaces themselves have Poi numbers too!), ask Companies for Redhat. Done!
So, in effect, it creates a competitive market for name spaces, which will most likely result in a few dominant players (e.g., Yahoo) at any given time, but affords no inherent monopoly to anyone. Note there is no one root! The "root" of the name space is implicit in the current body of popular name spaces!
Note also that the name spaces are of varying specificity, so for example say there are twenty companies in the country called "ACME Services" -- Yahoo/Companies/ACMEServices may return nothing, may return a list of all twenty, or may return a default one, according to Yahoo's (or the requester's?) choice, while Yahoo/Companies/California/SanDiego/ACMEServices may return just the one you're looking for.
Obviously the line between searching and DNS is being blurred here (see also Erik's post, subject: "This is bound to fail"), but the distinction from pure searching is that there would still be well-known name spaces (though many instead of just one) and the names within those spaces may still be concise and definitive so that, for instance, once I get yahoo/people/brandyn to Poi'nt to my page, I really can tell someone that over the phone and it's not like they have to do a Google search and sift through fifty returns (assuming yahoo was maintaining uniqueness in that particular name space).
Next there's the question of mapping Poi to IPs and whatnot, which could be implemented as a cached, distributed database -- ideally when you Get a Poi (e.g., via a Google link or whatnot), the Poi of the giver (Google) is also remembered with it, so when you look up a Poi, if it isn't already locally cached, you ask (first) the associated giver (Google) for the info. Once you actually get the Poi info, part of the record would be the current preferred giver, which would be the first place you would go later if the cached info proved antiquated. Typically, the preferred giver would be the host actually serving the Poi, which would provide forwarding service (that is, it would tell you who to ask instead) if the Poi were later moved away.
Note that what a Poi maps TO may change with time. For now, for instance, most Poi might map to urls (with hard-coded IP's in place of host names), but they could also map to other protocols/hardware addressing schemes entirely. The good thing about a Poi is it is NOT an IP address, nor a host name, nor an Appletalk node name, nor a filename, nor a phone number... it is just the universal "name" of the object you want to reach. Today it maps to an IP and url (or IP and port number for other services like telnet), but tomorrow who knows.
Lastly, there's the question of the Poi numbering space itself. How do you prevent monopoly concerns here? Obviously we need *some* central control (world-wide!), so I would propose something like this:
Some non-profit org would sell large chunks of Poi space -- let's say they sell chunks for $10 per bit, so I could buy 65K unique Poi from them for $160 (but I wouldn't -- read on). The presumption, then, is that other organizations would buy huge chunks of Poi space, and resell them at a lower cost per bit (but a higher cost per Poi). As an end-user, I ought to be able to get Poi practically free (ISPs could pay trivial fees to provide an endless supply to their users), to use for all sorts of things.... This scheme keeps Poi arbitrarily cheap while still not burdening the top-level Poi service with lots of small requests. Each re-seller would be responsible for verifying a Poi's authenticity, simply by identifying which block it came from and where that block was purchased (thus providing an audit trail straight back to the top level). Note that these services *only* assure uniqueness of the Poi -- they do not store any information about their use!
(I already have this set up on my machine for my personal use. Poi can be any number of bits, so you can't run out, and even if I chewed through them at thousands per second they still wouldn't get very large before the sun went cold.)
-Brandyn (Poi #1000000000000001b;)
"No one ever went broke underestimating the intelligence of the American public" -PT Barnum
"Yeah, what he said!" -Bill Gates