ZFS appears to combine all the benefits of RAID6, LVM, and a high-performance file system all in one package. Now, I recognize the benefits of each of those technologies: RAID6 gives you powerful redundancy and reliability features and combining RAID6 with LVM on hot-swappable drives gives you all kinds of flexibility about how much storage you have and how you allocate it, and XFS on top of that gives you a file system that you can expand if you need to without umounting it. What is less clear to me is the benefit of combining all that functionality into a single logical thing. I suppose there is some performance benefit to be gained, but any performance gain would have to be pretty massive for them to be noticeable on modern processors. Besides, file systems are already massively complicated things and I would think that adding complexity to it would just make it fragile and I shudder when I think about the sort of recovery tools you're going to need to fix a hosed ZFS file system. Not that I won't ever use ZFS for anything, but I'm certainly not going to be an early adopter.
It's just you. The IPv4 address space was way too small, probably because the guys who invented IP never envisioned the sheer volume of computers that want to connect to the Internet, and was allocated extremely inefficiently at first, probably because there was no obvious reason to be frugal with addresses, which led to the inequities of allocation that people complain about. The rising cost of addresses has caused people to become much more efficient in their allocations, but the inequities remain. Further, when IPv6 was just getting started, a large router might have 16 megabytes of RAM in it, so routing table size was a major concern, although the massive decrease in the cost of memory means that this also is less of an incentive than it once was.
I think that the real problem with IPv6 lies not in any part of the IPv6 design, but in the transition plan. I mean, the 6bone folks were the transition plan and, as soon as the backbones thought they knew what they were doing, they pulled the plug on the 6bone. The problem, of course, is that demand for addresses happens not at the backbones, but at the leaves. Since, at the time they pulled the plug on the 6bone, there was not one single piece of end user access equipment available, there was no demand for the native IPv6 transport that the 6bone folks assured me was available. Also at the time there was no way to do IPv6 multihoming without being a TLA. (That's "Top Level Aggregator", which is IETF-speak for "one who purchases his addresses straight from the source.") I don't know if that's been changed or not, as multihoming started being a lot less interesting to me right about then. I do know there were draft specifications addressing that very topic.
So, the transition is going very slowly. However, to assume that it isn't happening at all is to make the same mistake that short-sighted companies make. However badly those clueless individuals at the IETF managed to screw up the transition, the lack of IPv4 address space is a real problem now and that will only get worse in the future, and although NAT is easy to implement and quick to deploy, using NAT really is much less convenient than having live, routable addresses for all your systems.
The point is that things have a way of changing and those changes are happening right now. All my access gear and workstations are now IPv6 capable and, in fact, make use of IPv6, although that's through near heroic effort on my part. In fact, I have been told by my hosting provider that they're going to start providing native IPv6 transport to my virtual servers. An email to Comcast (my home's feed is through Comcast business service) asking about IPv6 got me, not one, but two telephone calls from someone who was nice enough to explain Comcast's IPv6 deployment strategy, which boils down to: We're deploying native IPv6 transport to end users as soon as DOCSIS 3 is widely available. I can't wait.
So, while I can count the number of actual live, remote IPv6 users that have hit my Web servers on my appendages without taking off my shoes, and I have never (not once) had a Gnutella connection over IPv6 despite supporting it for years, I have no doubt that the transition is well under way.
Nor is the size of the address space particularly insane. The idea is to use extreme inefficiency of address allocation to make certain hard tasks easier. The point is not to allow every grain of sand to have it's own IP address, but is, instead, to reduce the likelihood that an automatic host address assignment would result in an address collision to the point where it's not worth worrying about, and that point is actually achieved. The other objection that is commonly raised, that you can't memorize IPv6 addresses the way you memorize IPv4 addresses, gets a big "so what?" from me. Nobody memorizes IPv4 addresses, either. That's what name servers are for.
In an odd coincidence, the quota of the day today is this:
The trouble with fighting for human freedom is that one spends most of one's time defending scoundrels. For it is against scoundrels that oppressive laws are first aimed, and oppression must be stopped at the beginning if it is to be stopped at all.
HL Mencken
In this case, everyone agrees that the "misogynists" are scoundrels. For my own part, I don't find the harm done to the women to be all that concrete and I don't find the danger to society to be all that abstract.
On the other hand, we might find out that environmental impact studies were completed on all those oil and gas wells before the leases were granted. Those granted in the last 30 years, at least. Why should solar industry be exempt from the requirement to have environmental impact studies done?
Would you care to point out where in the question TihSon specifies that it has to work after dark? Please? How about where he describes the activities he expects to do in this large shed that implies that he expects it to work after dark or that he has specialized lighting or power requirements? Anything? In the absence of information, one can make up any additional requirements one likes or can make up any utilization pattern one wants.
The sort of thing I would use a large shed for (storage of stuff I don't want to keep in my garage because I would kind of like to keep my cars in there some day) there would be very little requirement for lighting it after dark because I would mostly be interested in doing things in it during daylight hours. For the rest, well, I have several LED flashlights and I can acquire chemical lights, if necessary.
Of course, if TihSon wishes to use the shed as a work area, then he will probably want to do something a little more advanced. However, the best advice I can give toward that end is "don't do it". Work benches that include access to commercial power and so forth are a whole lot easier to set up and use than a shed out back. (For the record, I'm anticipating creating a hinged workbench in the garage, just as soon as I clear some of the crap out of it. That plan has been in my family for generations, so don't hold your breath waiting for it.)
It is my understanding that punishment serves as a deterrent effect, but the deterrence comes from the certainty of the punishment rather than the severity of it. I don't think that the postulate concerning long prison terms leading to murder is likely to be true, primarily due to the large taboo about killing that most people have.
You know, if "diet and exercise" had to pass the usual FDA tests before it could be prescribed as a treatment for obesity, it would fail to be approved due to lack of efficacy because it only works about five percent of the time.
"Uninitialized" does NOT equate to "random". In fact, my experience suggests that the contents of uninitialized blocks of memory are remarkably consistent given similar execution histories and I believe that using an uninitialized buffer as a "source of randomness" is simply stupid.
"Bondage and discipline" languages do absolutely nothing to prevent "sloppy hack jobs". The best they can do is make those sloppy hack jobs somewhat more verbose, which is hardly the same as preventing them. To see this, you need look no farther than various comments in this discussion by skilled Ada people talking about how less skilled people had to write huge amounts of code because they did things the wrong way. That wrong way was a sloppy hack job and it clearly wasn't prevented.
A computer program language has very little effect on the likelihood that a given program written in that language will be written on time and under budget. When I look back on the errors that I spend my time wrestling with (mostly in C and C++, although I've written in everything from assembly language to Modula-[23] and Lisp) I find that a relatively small number of those errors were due to what are traditionally considered to be the "source of common errors", like pointers and unenforced array constraints, that language books spend all their time berating C programmers for using, and a vanishingly small number of the errors that I found difficult to find were due to those "common" sources of errors. As I've said before, if a programming language could flag an error when I reversed a branch, I'd marry it. The errors that are hardest to find are "cognitive errors" where you somehow know that that statement is right, so you don't bother checking it closely. Don't say that you don't do that. You're human, so you do it.
A lot of noise has been made about Ada's type checking system, and how the system is so picky that once you simply get the program to compile that you can be fairly confident that it works. When I first read that, I had a good belly laugh. Since then, that assertion has been repeated over and over and, well, I am aghast that there are so many people repeating that untruth because it is simply wrong. When you get the program to compile, you still have to do all the testing. In fact, a rigid type system is just a sort of a test and you'll find all the type errors in dynamically typed languages as soon as you exercise all of the paths through the code, which is an essential process if you want your program to be considered "tested."
On the other hand, the main reason why Ada was never very popular has nothing to do with its verbosity or its type enforcement. Rather, it's because there were no inexpensive compilers for it back when it had a chance to achieve a critical mass of users. I know that's why I never tried to learn it back in the 80's. The irony of the situation, for me at least, is that this article came out now, and I happen to be reading Grady Booch's book on Ada. I bought it for $1 off the clearance rack at Half Price Books.
You do know that AM stations in the USA have been limited to 50kW or less for decades, don't you? Kilowatt stations are not pocket change, but are well within the reach of an interested amateur on a limited budget. FM stations and television stations use much more power, but not necessarily that much. Educational (FM in the 88-90 Mhz range) stations are often set up running 20W or even less, and they don't have all that grandiose an equipment requirement, but they're not who you're competing with. None of these services are really on frequencies of much interest to the sort of high-speed data transmission that most people are interested in.
It's interesting to note that broadcasters have minimum power requirements specifically to make it reasonably expensive to operate stations. I believe that this is due to the desire to not have a single interest purchase all of the available channels in a given area and only set up one real station on it, but I don't actually know the rationale given for the rule.
I looked at the link, and I am, well, I'm not impressed, although I seem to remember that I was in 2002 when I first read about these papers. I know that the wireless networks that I have experience with tend to interfere with each other and so don't get the infinite bandwidth predicted by Dr. Reed. He mentions that 802.11 is a crappy ("does not in practice scale very well at all") protocol, but he doesn't seem to have anything on his site but papers about various theories that there's no hardware for. In particular, I need a link to a paper describing an experiment with actual hardware before I get enthusiastic about any of this. For a variety of reasons, radio networks are hard to model so anything that doesn't have any experimental data behind it is just so much BS.
Those seeking longer copyright terms are most definitely those whose assets are generating income. However, the problem with the current copyright system is that the copyright terms cover those works which will not generate income over even a 20 year span. I honestly don't have a problem with a perpetual copyright as long as the work so protected is generally available without violating the law. The current copyright law effectively un-publishes most works and that is precisely contrary to society's reason for providing copyright protection in the first place. Requiring that intellectual property be taxed provides a means for deciding when it is appropriate for a particular work to enter the public domain.
You know, when a megabyte was a lot of RAM, this whole "routing table is getting too big" argument carried some weight. The size of the routing table is an incredibly stupid thing to worry about, now. Perhaps it isn't because people don't do routing the way that they should.
With BGP, you're not going to route anything smaller than a/24, so your entire routing table can be an array with 2^24 entries in it. Those entries are going to be (for the most part) outbound queues, one per interface, so all you need in most cases is a single 8-bit number with the queue number in it. I can buy 16 MBytes of RAM with pocket change, nowadays.
To route a packet, you simply shift the destination address right eight bits, look up the queue number, and put the packet in that queue. The total elapsed time for that operation is easily measured in nanoseconds. Some queues might do further routing (you might have a queue to route local packets, for example,) but you wouldn't see a lot of those on any router that needs a full picture of the Internet.
Now, building that array is a lot more work, but it's not that much more work and, besides, it's the handling of the incoming packets that is time-critical. Processing of BGP (or RIP or OSPF or whatever) can take a lot more time and still be plenty fast enough to handle the changes as they happen.
On that list, there are four ISPs listed as serving customers in the US. Of those, it appears as if three of them provide consumer-grade access. Of those, none, that is not a single one, offers service in my area, which happens to be Houston, Texas, US. So, can you name one broadband IPv6 provider that is willing to sell me the services I'm willing to buy (I get business-class cablemodem service) in a place that I either live or work?
When you authenticate using OpenID, what happens is that the system you're trying to authenticate at goes to the URI that you specify and asks it to authenticate you. In effect, an OpenID login is a proof that you control the content at a particular URI. What I was missing was that my AIM ID was an AOL ID. That's true because of how AOL chooses to handle accounts, but isn't true in general.
Did I mention I spent a couple of weeks reviewing the OpenID spec in some detail? I also spent quite a while looking at it because of the "pull email" proposal I was looking at at the same time. In any case, the opinion that OpenID doesn't authenticate to identifiers that are email addresses isn't my opinion, it's that of the OpenID developers.
Nevertheless, to be sure that I didn't miss something since I last looked at it, I checked out the Web sites that you link to, and dug into V2 of the OpenID spec, and I don't see where any OpenID spec says that it includes "mailto:" URI's. It's also not clear how that would work because the OpenID authentication process relies upon doing an HTTP POST on the URI, which is not supported on "mailto:" URI's. Well, version 2 of the spec does talk about something called XRI's, which may include mailto identifiers, but the mechanisms used to verify the identity are all based on HTTP, which isn't not what is used for a mailto. All the examples, which of course are not normative, use HTTP, HTTPS, and XRI URI's as well with nary a "mailto:" in sight.
Could you explain in more detail how using OpenID to verify to a mailto: URI would work?
The last time I looked, which was a couple of years ago, OpenID was simply a way of verifying that a person was associated with a particular URL. In particular, the OpenID folks were resisting (and with good reason) all the pressure to use OpenID for things like, say, verifying that a user was associated with a particular email address, despite how useful that would be. So, how can Yahoo and AIM logins be OpenID logins? That seems to be inconsistent with the previous stance of the OpenID people. In particular, there seems to be no URL associated with either of those types of logins.
But that's just wrong. People DO know something about IP, even if they don't know that they know. They know that they have to buy IP connectivity from a provider, that they can't get on the Internet without that connectivity, and they know how much that provider charges for that service. Contrast this with your explanation of 6to4.
You say that "6to4 requires no configuration or state in the network" so how does the network know that I'm using 6to4? Does it read my mind? Do I have to write a letter to that effect and then burn it so that the smoke carries my plea to the 6to4 gods that will do the magic to establish connectivity? What? What is different about a computer that is using 6to4 as opposed to one that merely has IPv4 connectivity? I'm not trying to be difficult, I'm just trying to understand.
I suppose what's really going on is that there is some router somewhere that knows that one side has IPv6 addresses and the other side gets a feed from some place that knows what to do with the packets, but that router has to be configured and, given the current dismal state of the IPv6 connectivity in the world, that means that the end user has to know how to do it. What that means that it breaks the "the end user doesn't understand anything about IP" model which you describe (and I generally agree with...assuming that by "understand" you mean "knows any of the technical details of") in your first paragraph. Either that, or you're counting on the ISP to set that up and, well, if they're getting the explanations I'm getting (to wit: "there's no setup involved") then they're going to throw their hands up in the air and go play "Guitar Hero" at that point.
In other words, 6to4 appears to simply fail the "requires no configuration" requirement on the part of people who consider themselves competent to know what that means. It's easier to understand tunnel brokers, but a tunnel to one of a handful of tunnel brokers that is not networked near to me and with an uncertain bandwidth aggregated among a potentially large number of users lacks a lot of appeal to an ISP and, well, the lack of access equipment speaks for itself.
Of course, it's far from clear that keeping the 6bone around would have had the effect of boosting IPv6 adoption, because the lack of adoption among end users (my stats show something like a dozen IPv6 hits from outside my household LAN in the last three years) has more to do with the lack of access equipment that backbone availability, but it still sticks in my craw that they declared "IPv6 available to everybody" before it was really available to anybody.
The 6bone is only obsolete because they pulled the plug on it. My 6bone connection (to Sprint) was SOLID, even after I disconnected my direct feed to Sprint, but my tunnel broker connections have bounced up and down like rubber balls. That means that IPv6 was useful for me back in the days of the 6bone, but is now useless for just about anything. I don't know about 6to4 because I have never understood what 6to4 was and every new explanation of 6to4 seems to make less sense than the one before.
You might consider the last part a warning about the lack of utility of 6to4. If I can't figure it out, and I've been using IPv6 for, wow, it's a decade now, then someone who has no clue (and such people make up the bulk of the people you're trying to get to use IPv6) is not going to have a chance.
They should have left the 6bone up and had people adopt IPv6 from the outside in rather than believing that the job was finished when the backbones were sort-of IPv6 capable. Demand for addresses comes from the leaves, not the trunk.
I have deployed IPv6 on my home network, just for giggles. At home, my main router firewall box is based on FreeBSD and maintains a tunnel to freenet6 and I use ipfilter to accomplish the sort of firewalling that you're talking about. Right now, it's pretty safe because nobody's using it for anything as shown by the fact that I've run IPv6 connected Web servers for years and have seen fewer than 2-dozen page loads in all that time, My router statistics imply that less than 1% of all network traffic arriving at my router is IPv6, and my statistics show more IPv6 usage than most people's will because I use IPv6 between my home network and some computers on a different network. That tells me that that the entire IPv6 Internet is, well, it's pretty useless. That will likely change at some point.
The good news is that the freenet6 used to die in a matter of hours and now stays up for weeks at a time. So, I'm ready for end users.
You should look up the old Allen Sherman song "The Let's All Call Up AT&T and Protest to the President March". You might find it interesting, considering the gist of your post.
I read a book recently that posits, among other things, that intelligence in humans basically fills the same role in humans that a peacock's tail fills in peafowl. Since the question of why human intelligence evolved is a major puzzle, or so I am given to understand, this simple explanation has a definite appeal. Unfortunately, it makes "Idiocracy" somewhat less than likely.
For my own part, I question the whole premise. Will a person who is smart always breed less than a person who is stupid, given similar circumstances? What evidence, other than, "I know a bunch of people who are like me, and therefore smart, and none of us wants any kids" and "I know that stupid people are always breeding" does anyone have about this?
Actually, what I wonder is not how we survived the 80's at all, but when people started believing that the appropriate response to obnoxious behavior is behavior that is even more obnoxious. My guess is that it's something that is part of our genetic makeup and is something that we should be working hard to overcome.
Slashdot Mirror
ZFS appears to combine all the benefits of RAID6, LVM, and a high-performance file system all in one package. Now, I recognize the benefits of each of those technologies: RAID6 gives you powerful redundancy and reliability features and combining RAID6 with LVM on hot-swappable drives gives you all kinds of flexibility about how much storage you have and how you allocate it, and XFS on top of that gives you a file system that you can expand if you need to without umounting it. What is less clear to me is the benefit of combining all that functionality into a single logical thing. I suppose there is some performance benefit to be gained, but any performance gain would have to be pretty massive for them to be noticeable on modern processors. Besides, file systems are already massively complicated things and I would think that adding complexity to it would just make it fragile and I shudder when I think about the sort of recovery tools you're going to need to fix a hosed ZFS file system. Not that I won't ever use ZFS for anything, but I'm certainly not going to be an early adopter.
I think that the real problem with IPv6 lies not in any part of the IPv6 design, but in the transition plan. I mean, the 6bone folks were the transition plan and, as soon as the backbones thought they knew what they were doing, they pulled the plug on the 6bone. The problem, of course, is that demand for addresses happens not at the backbones, but at the leaves. Since, at the time they pulled the plug on the 6bone, there was not one single piece of end user access equipment available, there was no demand for the native IPv6 transport that the 6bone folks assured me was available. Also at the time there was no way to do IPv6 multihoming without being a TLA. (That's "Top Level Aggregator", which is IETF-speak for "one who purchases his addresses straight from the source.") I don't know if that's been changed or not, as multihoming started being a lot less interesting to me right about then. I do know there were draft specifications addressing that very topic.
So, the transition is going very slowly. However, to assume that it isn't happening at all is to make the same mistake that short-sighted companies make. However badly those clueless individuals at the IETF managed to screw up the transition, the lack of IPv4 address space is a real problem now and that will only get worse in the future, and although NAT is easy to implement and quick to deploy, using NAT really is much less convenient than having live, routable addresses for all your systems.
The point is that things have a way of changing and those changes are happening right now. All my access gear and workstations are now IPv6 capable and, in fact, make use of IPv6, although that's through near heroic effort on my part. In fact, I have been told by my hosting provider that they're going to start providing native IPv6 transport to my virtual servers. An email to Comcast (my home's feed is through Comcast business service) asking about IPv6 got me, not one, but two telephone calls from someone who was nice enough to explain Comcast's IPv6 deployment strategy, which boils down to: We're deploying native IPv6 transport to end users as soon as DOCSIS 3 is widely available. I can't wait.
So, while I can count the number of actual live, remote IPv6 users that have hit my Web servers on my appendages without taking off my shoes, and I have never (not once) had a Gnutella connection over IPv6 despite supporting it for years, I have no doubt that the transition is well under way.
Nor is the size of the address space particularly insane. The idea is to use extreme inefficiency of address allocation to make certain hard tasks easier. The point is not to allow every grain of sand to have it's own IP address, but is, instead, to reduce the likelihood that an automatic host address assignment would result in an address collision to the point where it's not worth worrying about, and that point is actually achieved. The other objection that is commonly raised, that you can't memorize IPv6 addresses the way you memorize IPv4 addresses, gets a big "so what?" from me. Nobody memorizes IPv4 addresses, either. That's what name servers are for.
One opinion, worth what you paid for it.
In this case, everyone agrees that the "misogynists" are scoundrels. For my own part, I don't find the harm done to the women to be all that concrete and I don't find the danger to society to be all that abstract.
On the other hand, we might find out that environmental impact studies were completed on all those oil and gas wells before the leases were granted. Those granted in the last 30 years, at least. Why should solar industry be exempt from the requirement to have environmental impact studies done?
The sort of thing I would use a large shed for (storage of stuff I don't want to keep in my garage because I would kind of like to keep my cars in there some day) there would be very little requirement for lighting it after dark because I would mostly be interested in doing things in it during daylight hours. For the rest, well, I have several LED flashlights and I can acquire chemical lights, if necessary.
Of course, if TihSon wishes to use the shed as a work area, then he will probably want to do something a little more advanced. However, the best advice I can give toward that end is "don't do it". Work benches that include access to commercial power and so forth are a whole lot easier to set up and use than a shed out back. (For the record, I'm anticipating creating a hinged workbench in the garage, just as soon as I clear some of the crap out of it. That plan has been in my family for generations, so don't hold your breath waiting for it.)
It is my understanding that punishment serves as a deterrent effect, but the deterrence comes from the certainty of the punishment rather than the severity of it. I don't think that the postulate concerning long prison terms leading to murder is likely to be true, primarily due to the large taboo about killing that most people have.
You know, if "diet and exercise" had to pass the usual FDA tests before it could be prescribed as a treatment for obesity, it would fail to be approved due to lack of efficacy because it only works about five percent of the time.
"Uninitialized" does NOT equate to "random". In fact, my experience suggests that the contents of uninitialized blocks of memory are remarkably consistent given similar execution histories and I believe that using an uninitialized buffer as a "source of randomness" is simply stupid.
A computer program language has very little effect on the likelihood that a given program written in that language will be written on time and under budget. When I look back on the errors that I spend my time wrestling with (mostly in C and C++, although I've written in everything from assembly language to Modula-[23] and Lisp) I find that a relatively small number of those errors were due to what are traditionally considered to be the "source of common errors", like pointers and unenforced array constraints, that language books spend all their time berating C programmers for using, and a vanishingly small number of the errors that I found difficult to find were due to those "common" sources of errors. As I've said before, if a programming language could flag an error when I reversed a branch, I'd marry it. The errors that are hardest to find are "cognitive errors" where you somehow know that that statement is right, so you don't bother checking it closely. Don't say that you don't do that. You're human, so you do it.
A lot of noise has been made about Ada's type checking system, and how the system is so picky that once you simply get the program to compile that you can be fairly confident that it works. When I first read that, I had a good belly laugh. Since then, that assertion has been repeated over and over and, well, I am aghast that there are so many people repeating that untruth because it is simply wrong. When you get the program to compile, you still have to do all the testing. In fact, a rigid type system is just a sort of a test and you'll find all the type errors in dynamically typed languages as soon as you exercise all of the paths through the code, which is an essential process if you want your program to be considered "tested."
On the other hand, the main reason why Ada was never very popular has nothing to do with its verbosity or its type enforcement. Rather, it's because there were no inexpensive compilers for it back when it had a chance to achieve a critical mass of users. I know that's why I never tried to learn it back in the 80's. The irony of the situation, for me at least, is that this article came out now, and I happen to be reading Grady Booch's book on Ada. I bought it for $1 off the clearance rack at Half Price Books.
It's interesting to note that broadcasters have minimum power requirements specifically to make it reasonably expensive to operate stations. I believe that this is due to the desire to not have a single interest purchase all of the available channels in a given area and only set up one real station on it, but I don't actually know the rationale given for the rule.
I looked at the link, and I am, well, I'm not impressed, although I seem to remember that I was in 2002 when I first read about these papers. I know that the wireless networks that I have experience with tend to interfere with each other and so don't get the infinite bandwidth predicted by Dr. Reed. He mentions that 802.11 is a crappy ("does not in practice scale very well at all") protocol, but he doesn't seem to have anything on his site but papers about various theories that there's no hardware for. In particular, I need a link to a paper describing an experiment with actual hardware before I get enthusiastic about any of this. For a variety of reasons, radio networks are hard to model so anything that doesn't have any experimental data behind it is just so much BS.
Those seeking longer copyright terms are most definitely those whose assets are generating income. However, the problem with the current copyright system is that the copyright terms cover those works which will not generate income over even a 20 year span. I honestly don't have a problem with a perpetual copyright as long as the work so protected is generally available without violating the law. The current copyright law effectively un-publishes most works and that is precisely contrary to society's reason for providing copyright protection in the first place. Requiring that intellectual property be taxed provides a means for deciding when it is appropriate for a particular work to enter the public domain.
With BGP, you're not going to route anything smaller than a
To route a packet, you simply shift the destination address right eight bits, look up the queue number, and put the packet in that queue. The total elapsed time for that operation is easily measured in nanoseconds. Some queues might do further routing (you might have a queue to route local packets, for example,) but you wouldn't see a lot of those on any router that needs a full picture of the Internet.
Now, building that array is a lot more work, but it's not that much more work and, besides, it's the handling of the incoming packets that is time-critical. Processing of BGP (or RIP or OSPF or whatever) can take a lot more time and still be plenty fast enough to handle the changes as they happen.
On that list, there are four ISPs listed as serving customers in the US. Of those, it appears as if three of them provide consumer-grade access. Of those, none, that is not a single one, offers service in my area, which happens to be Houston, Texas, US. So, can you name one broadband IPv6 provider that is willing to sell me the services I'm willing to buy (I get business-class cablemodem service) in a place that I either live or work?
When you authenticate using OpenID, what happens is that the system you're trying to authenticate at goes to the URI that you specify and asks it to authenticate you. In effect, an OpenID login is a proof that you control the content at a particular URI. What I was missing was that my AIM ID was an AOL ID. That's true because of how AOL chooses to handle accounts, but isn't true in general.
Nevertheless, to be sure that I didn't miss something since I last looked at it, I checked out the Web sites that you link to, and dug into V2 of the OpenID spec, and I don't see where any OpenID spec says that it includes "mailto:" URI's. It's also not clear how that would work because the OpenID authentication process relies upon doing an HTTP POST on the URI, which is not supported on "mailto:" URI's. Well, version 2 of the spec does talk about something called XRI's, which may include mailto identifiers, but the mechanisms used to verify the identity are all based on HTTP, which isn't not what is used for a mailto. All the examples, which of course are not normative, use HTTP, HTTPS, and XRI URI's as well with nary a "mailto:" in sight.
Could you explain in more detail how using OpenID to verify to a mailto: URI would work?
The last time I looked, which was a couple of years ago, OpenID was simply a way of verifying that a person was associated with a particular URL. In particular, the OpenID folks were resisting (and with good reason) all the pressure to use OpenID for things like, say, verifying that a user was associated with a particular email address, despite how useful that would be. So, how can Yahoo and AIM logins be OpenID logins? That seems to be inconsistent with the previous stance of the OpenID people. In particular, there seems to be no URL associated with either of those types of logins.
You say that "6to4 requires no configuration or state in the network" so how does the network know that I'm using 6to4? Does it read my mind? Do I have to write a letter to that effect and then burn it so that the smoke carries my plea to the 6to4 gods that will do the magic to establish connectivity? What? What is different about a computer that is using 6to4 as opposed to one that merely has IPv4 connectivity? I'm not trying to be difficult, I'm just trying to understand.
I suppose what's really going on is that there is some router somewhere that knows that one side has IPv6 addresses and the other side gets a feed from some place that knows what to do with the packets, but that router has to be configured and, given the current dismal state of the IPv6 connectivity in the world, that means that the end user has to know how to do it. What that means that it breaks the "the end user doesn't understand anything about IP" model which you describe (and I generally agree with...assuming that by "understand" you mean "knows any of the technical details of") in your first paragraph. Either that, or you're counting on the ISP to set that up and, well, if they're getting the explanations I'm getting (to wit: "there's no setup involved") then they're going to throw their hands up in the air and go play "Guitar Hero" at that point.
In other words, 6to4 appears to simply fail the "requires no configuration" requirement on the part of people who consider themselves competent to know what that means. It's easier to understand tunnel brokers, but a tunnel to one of a handful of tunnel brokers that is not networked near to me and with an uncertain bandwidth aggregated among a potentially large number of users lacks a lot of appeal to an ISP and, well, the lack of access equipment speaks for itself.
Of course, it's far from clear that keeping the 6bone around would have had the effect of boosting IPv6 adoption, because the lack of adoption among end users (my stats show something like a dozen IPv6 hits from outside my household LAN in the last three years) has more to do with the lack of access equipment that backbone availability, but it still sticks in my craw that they declared "IPv6 available to everybody" before it was really available to anybody.
You might consider the last part a warning about the lack of utility of 6to4. If I can't figure it out, and I've been using IPv6 for, wow, it's a decade now, then someone who has no clue (and such people make up the bulk of the people you're trying to get to use IPv6) is not going to have a chance.
They should have left the 6bone up and had people adopt IPv6 from the outside in rather than believing that the job was finished when the backbones were sort-of IPv6 capable. Demand for addresses comes from the leaves, not the trunk.
Comcast is my provider. Who do I call at Comcast to get them to route me a /48 natively?
The good news is that the freenet6 used to die in a matter of hours and now stays up for weeks at a time. So, I'm ready for end users.
You should look up the old Allen Sherman song "The Let's All Call Up AT&T and Protest to the President March". You might find it interesting, considering the gist of your post.
For my own part, I question the whole premise. Will a person who is smart always breed less than a person who is stupid, given similar circumstances? What evidence, other than, "I know a bunch of people who are like me, and therefore smart, and none of us wants any kids" and "I know that stupid people are always breeding" does anyone have about this?
Shuttles will be flying from Vandenburg? The next shuttle launch from California will be the first.
Actually, what I wonder is not how we survived the 80's at all, but when people started believing that the appropriate response to obnoxious behavior is behavior that is even more obnoxious. My guess is that it's something that is part of our genetic makeup and is something that we should be working hard to overcome.