In general, that could be said of (almost) every single software package of any substance. If you want it to run well, you have got to roll your own. Well, almost. In theory, there's nothing to stop a vendor with a decent server farm gathering your system info then compiling the RPMs for you for that specific system, and/or having a set of stock ISOs rolled for, say, the five most-popular systems.
A central build has the advantage over something like Gentoo in that vendors can usually afford better horsepower and can auto-tune the options per application better than the average Joe could ever hand-tune them. It's also more supportable, as the vendor then has the exact information for each package, as they would have had they rolled the RPMs from their own default configurations, which a totally user-defined setup would deprive them of.
There's also the dependency hell and the namespace clash that "standard" distros suffer from all the time. I've never come across a distribution YET that supplies stock binaries that is capable of supplying ones that actually work together. First rule, guys, is that if package A is rebuilt, ALL packages in which A is directly or indirectly a dependency should automatically be rebuilt. It should not be possible, using JUST the stable packages (DEB or RPM), to get into a situation where packages barf or cannot resolve their own dependency requirements.
(I won't even get into the issue of broken packages in the stable updates, where you cannot complete an install or a deinstall because the flippin' scripts don't work and don't cleanly handle the case where something breaks, effectively barfing over the disk and the package database.)
The more I use Linux, the more I am convinced that the distros out there are operating on a flawed assumption. They work great, but only when that assumption holds true, but will catastrophically fail outside of those bounds. This assumption is that people will use the distro with a relatively narrow aim on relatively generic systems.
Java is OO, so the abstraction layer should hide the implementation details. At a high enough level of object abstraction, all communications classes in Java should look identical to the application - the compiler should optimize out the abstraction to make it efficient, not the programmer. Well, in theory.
Heh. Standards should be the starting point, not the end goal (or, in IE's case, the work of fiction based on the screenplay based on a True Story of one man and his chair).
Let's see. MPLS, SCTP, STP (Scheduled Transfer Protocol), UDP-over-v4, TCP-over-v4, MPLS, UDP-over-v6, TCP-over-V6, IP-over-ATM, IP-over-SCSI, IP-over-IB, IP-over-power, IP-over-carrier-pidgeon, V6-over-V4, V4-over-V6, V6-over-V6, optional recognition of TOS, optional handling of ECN, scalable reliable multicast, anycast, optional recognition of source-based routing, optional recognition of TCP cookies, optional support for packet dropping (RED, GRED, WRED, BLUE, Stochastic Blue, GREEN, BLACK, PURPLE, WHITE), optional support for enhanced authentication packets, IPv6 extended headers, support for unidirectional links, optional support for transitory addressing schemes, optional support for Mobile IP, optional support within Mobile IP for routing realignment, optional support for NEMO, optional use of any of the experimental protocols defined under the names of TUBA, IPv5 and IPv7, anything-over-IPSEC (tunnel or host), anything-over-SKIP -- I've not bothered to keep count, but my Internet link hasn't fallen over yet from diversity. Pity to hear about yours.
If that's the British DHS, the American counterpart is Home Depot, and it should be obvious why they'd want to spy on people. This isn't really a security issue in the same sense broken encryption or the loss of unencrypted data is a security issue, though, so can someone icon and section to "mindless stupidity in protocol design" and/or add "Stone De Croze" to the tags?
They gave away Microsoft's private keys to someone who called them, a while back, in a rather infamous case that forced Microsoft to change their entire update system and their collection of "secure" sites. If they've done it once, it can clearly happen again, and the lack of publicity may simply be evidence of better media management. I'd be very wary of trusting them with anything and would be skeptical of any institution that relied on Verisign for any kind of critical proof-of-identity situation, though they're probably reasonable enough for personal certs.
BGP is supposed to be authenticated between peers, but clearly not nearly enough. If IPSEC was enabled (it's likely to already be present) on all routers, then BGP traffic between routers would be guaranteed both encrypted AND authenticated. Or, if you prefer, there are a very very few other routing protocols for WANS - ESES probably being the one most taken seriously. (ESES is the exterior gateway version of ISIS. Both are mature protocols with a lot of hardware out there that can support them.)
Find me an internet provider not using BGP, and I'll show you a European who favours ESES. Yes, this is a major problem, BGP is (almost) the only WAN protocol anyone takes seriously and is the only one meaningfully deployed. I've worried about the possibility of BGP poisoning attacks myself, but only because we have a virtual monoculture and monocultures are generally a Bad Idea. They are dangerous animals.
Well, as yet, I don't know of a way of using the dot-over-number nomenclature in HTML used for finite amd infinite sequences of repeating numbers.:) Yes, if there are infinite zeros, the proof you outlined is correct for showing that infinitesimal (literally) quantities are indeed zero. (Mind you, that buggers up the trivial proof for calculus, which assumes infinitesimal merely approaches zero as close as you like but is never actually equal, so that the difference function is guaranteed asymptotic to the gradient at a given point and doesn't hit any weird singularities at the limit.)
Well, yes, 0.0(recurring)1 is technically larger than 0. However, given the extensive support in Linux for so-called "Windows-only" formats - in addition to the majority of open formats - it actually takes a LOT of skill and effort to make something NOT work with Linux. I doubt it was deliberate on the part of the Democratic party leadership, but it has to have been deliberate on the part of somebody. I guess sabotaging an entire sector of the electorate is "technically savvy" in its own way, and since it is almost certainly not going to sway anyone one way or the other when it comes to the election, they can get away with it. The technologists and technocrats have no meaningful voice and have often opposed any and all efforts to give them one, so why expect them to be heard?
Information is context-sensitive. The VERY first thing you learn when using encryption systems is that it's much easier to crack something where you know what the plaintext should look like. The second thing you learn is that the information around the encrypted data is often far more valuable intelligence-wise than the encrypted stuff. That's why those of you who have ever been instructed on the use of STU-III phones were told NOT to chat before inserting the encryption card. (You WERE paying attention to those talks, right? Right???)
Next, there's this thing called the European Union. They're getting, oh, just a little sensitive about personal information these days. You know, what with German banks freely selling personal data (such as bank account details) to anyone who calls up, despite some of the toughest data protection laws in the world. Americans may view them as unimportant nobodies, but they are at least grasping the idea that ANY unnecessary exposure of personally-identifying information is a very high risk to the individual (identity theft) and a fairly substantial risk to the economy as a whole (such theft costs - and it costs a whole lot more than any "terrorist" threat ever did).
Name and address "high risk information"? If it can be used in a social engineering attack on a bank, credit card company or Government department (and usually such people do not make much effort to validate who a person is), then it is high risk. It doesn't matter if such information has always been viewed as public, as long as human operators (and computer programs) are satisfied that such information proves identity, it is not safe to expose.
Oh, and as for the fact that this information is actually used as a substitute for secure passwords, The Cheshire Catalyst was responsible for publishing a rather pointed song on the subject by breaking into the PRESTEL account of a BBC presenter whilst he was demonstrating the service live on BBC television. The lyrics should be required reading material for anyone who uses any kind of online service, and failure to heed its warnings should be considered no different from reckless driving or setting off fireworks inside a furniture store.
Yes, and often far more data is held than is necessary. Also, if you subscribe to the notions of grid computing and cloud computing, why store the data at all? All you need to do is tell an authorized holder of the data what operation you wish to perform, and get the results, entirely black-box. You need never see the data at all.
In terms of liability, I would argue that the rule should be a generic one: if you assume control of data, you assume responsibility for that data - its accuracy, its security and its legitimacy. The distinction should come in the degree of reasonableness. It is reasonable for a non-mathematical corporation to trust RSA and Elliptic Curve public-key encryption, AES and the SHA-256, Tiger and Whirlpool cryptographic hashes. It is not reasonable for any corporation to trust unencrypted and unsigned sources - they wouldn't trust unsigned paperwork and physical signatures are easier to forge. Organizations which can be reasonably assumed to be aware of security bulletins, the assorted cryptographic lounges and other such sources should be held to the higher standard of being expected to discontinue additional use of vulnerable methods with a migration of legacy data in circulation within a sensible period.
It is never reasonable to hold data a corporation cannot use in future, cannot be sure is authentic or accurate, and/or cannot be sure is serving any legitimate purpose on the system. Since there is no excuse to hold such data, there is less of an excuse to lose it. You can't lose what you don't have, so any loss of such data - regardless of method - can never be passed off as unavoidable. It was easily avoidable. Don't keep such data. Likewise, if an individual within that corporation is provided access to information they didn't actually need, and that data is subsequently lost as a result, that should be an automatic crime even if every precaution was taken, simply because it was an unnecessary gamble and therefore not entitled to any protection or justification.
Data that is accurate, legitimate and in active use should be considered as highly sensitive, and companies that do not treat the data with the respect and maturity they are capable of and for which the data is deserving should find themselves less in hot water than boiling oil. Like I said earlier, this depends on what the company can be regarded as being aware of. All companies can be deemed aware of published security patches, common security software (Tripwire, RSA and PGP are hardly obscure!) and software equivalents of practices already in place for physical documents. Government (including military and veterans affairs) and computationally advanced organizations, as I said, should be aware of relatively mainstream peer-reviewed discoveries, not just pre-packaged solutions, and should also be aware of vulnerability scanners (Nessus, nCircle, SARA/TARA, and so on) and advanced access controls, where the size and type of organization is going to dictate what sort of preventative measures are cost-effective.
Where a company falls below what can reasonably be expected of it, and loses data, that's boiling oil time. Where a company meets or exceeds a rational, sane level of protection and still loses data it needed to have, it should still be responsible for contributing towards cleaning up the mess (same as you would in a truly no-fault car accident) but shouldn't be punished for what was beyond its abilities to deal with. (That "needed to have" qualifier really is important.)
If a company deliberately places data in a dangerously exposed context (eg: pushing personal data onto unsecure systems overseas to avoid any national laws on data security), then they deserve not only the boiling oil treatment but a loss of right to operate. Dodging the law or evading responsibility is not a helpful way to tackle data insecurity, even if it looks like a cheap way to solve the problem for the company.
To those who argue that this is a slippery slope, I'd say that reasonable conduct can never be a slope, nor can it be slippery. If anything, it is a great leveler and a superb provider of grip and balance.
How about this - I won't blame you, but I WILL blame some of the egotistical b* who have happily caused harm to Linux and the free software movement in order to plunder corporations and organizations and destroy genuine attempts at real innovation for the sake of raking in the cash and fluffing up their egos. You've probably encountered some, I certainly have. I won't name names because I happen to know they can afford considerably better lawyers, and some accusations are - by nature - rather hard to prove. But if Linux fails, it is because it has been sabotaged from within, it is because innovators and inventors are being given a raw deal far too often.
(Yes, I'm extremely angry. Not at just one person, but many who feel that they are far more important than the free software that they ride the coat-tails of. Over the past 12 years, I've seen enough to convince me that Linux' success is by the fortune of competent, ethical developers outnumbering the highway robbers. The Linux Foundation and its members' biggest contribution will be on how well they ensure it stays that way.)
Also bear in mind that variable-length addresses were proposed as a part of the IPv6 specification (TUBA) but were rejected on the grounds of making the hardware over-complicated. I personally thought the idea quite neat, but admit that there isn't a vast amount of value in it. IPv6 addressing mimics variable-length addressing by means of the prefix, so you end up checking only one byte prior to the end of your prefix and one byte after, which is what you'd be doing with variable-length addresses.
One thing that surprises me in the IPv6 discussion is that although people talk quite happily about data centers and high-end servers, not all such systems are set up on Ethernet. A fair percentage are set up on Infiniband, particularly for network storage, on account of the far lower latencies and far greater bandwidth. Infiniband is designed to cooperate with IPv6 - any packet on one can be trivially mapped onto the other - but there is no way of mapping Infiniband onto IPv4. NAT only goes so far. This means a data center with Infiniband local networking and IPv6 remote networking is simple to set up, simple to administrate, simple to develop, simple to maintain. Sure, it's not the dominant architecture, but by definition data centers are thin on the ground anyway. You don't want data centers to be a common design, you do want them to be an efficient design.
1. Vendors won't support IPv6 because users don't need it for their current apps.
2. Vendors won't add IPv6 to their current apps because it's not being supported by vendors.
I don't see the users getting much input in all of this. The vendors won't create a killer IPv6 app because vendors won't support IPv6 on the network, and vice versa. The user is completely ignored and is totally outside of that equation. But the user is then blamed for the lack of IPv6 adoption on both sides, for failing to demand what was never on the table to begin with.
1. Not too many processors allow you to handle 1-bit or 4-bit structures, of which the IPv4 header contains many. The difference is the direction, not the direct handling.
2. Since IPv6 should have fewer exceptions to general cases, the number of nodes in the radix tree should be significantly lower, so giving you a net save.
3. Performance is so unimportant that IPv4 latency is one of the biggest things people loath and despise about IPv4. ATM is hardly a decent protocol, the payloads are absurdly small, but the latency is almost non-existent. As grids and clouds increase in usage, network latency is going to be the only latency that people will care about.
There are ISPs that provide IPv6 in the US and who can "replace" your existing ISP, but coverage is not that great. Tunnels, via services like Hurricane Electric, are generally better.
All the good terms were written down by H. G. Welles and a rogue band of cryogenically frozen ancient Greek scientists, then trademarked at suitable points in the future. He is currently living with Elvis, who had stumbled on his ruse after discovering his latest hits were written five years after being published.
Slashdot Mirror
In general, that could be said of (almost) every single software package of any substance. If you want it to run well, you have got to roll your own. Well, almost. In theory, there's nothing to stop a vendor with a decent server farm gathering your system info then compiling the RPMs for you for that specific system, and/or having a set of stock ISOs rolled for, say, the five most-popular systems.
A central build has the advantage over something like Gentoo in that vendors can usually afford better horsepower and can auto-tune the options per application better than the average Joe could ever hand-tune them. It's also more supportable, as the vendor then has the exact information for each package, as they would have had they rolled the RPMs from their own default configurations, which a totally user-defined setup would deprive them of.
There's also the dependency hell and the namespace clash that "standard" distros suffer from all the time. I've never come across a distribution YET that supplies stock binaries that is capable of supplying ones that actually work together. First rule, guys, is that if package A is rebuilt, ALL packages in which A is directly or indirectly a dependency should automatically be rebuilt. It should not be possible, using JUST the stable packages (DEB or RPM), to get into a situation where packages barf or cannot resolve their own dependency requirements.
(I won't even get into the issue of broken packages in the stable updates, where you cannot complete an install or a deinstall because the flippin' scripts don't work and don't cleanly handle the case where something breaks, effectively barfing over the disk and the package database.)
The more I use Linux, the more I am convinced that the distros out there are operating on a flawed assumption. They work great, but only when that assumption holds true, but will catastrophically fail outside of those bounds. This assumption is that people will use the distro with a relatively narrow aim on relatively generic systems.
Young whippershnappers! Down't know what the wuuuurlds coming to. All these IP prints, all over my beautiful lawn!
Java is OO, so the abstraction layer should hide the implementation details. At a high enough level of object abstraction, all communications classes in Java should look identical to the application - the compiler should optimize out the abstraction to make it efficient, not the programmer. Well, in theory.
Only on Slashdot could that be both insightful and correct.
Heh. Standards should be the starting point, not the end goal (or, in IE's case, the work of fiction based on the screenplay based on a True Story of one man and his chair).
Let's see. MPLS, SCTP, STP (Scheduled Transfer Protocol), UDP-over-v4, TCP-over-v4, MPLS, UDP-over-v6, TCP-over-V6, IP-over-ATM, IP-over-SCSI, IP-over-IB, IP-over-power, IP-over-carrier-pidgeon, V6-over-V4, V4-over-V6, V6-over-V6, optional recognition of TOS, optional handling of ECN, scalable reliable multicast, anycast, optional recognition of source-based routing, optional recognition of TCP cookies, optional support for packet dropping (RED, GRED, WRED, BLUE, Stochastic Blue, GREEN, BLACK, PURPLE, WHITE), optional support for enhanced authentication packets, IPv6 extended headers, support for unidirectional links, optional support for transitory addressing schemes, optional support for Mobile IP, optional support within Mobile IP for routing realignment, optional support for NEMO, optional use of any of the experimental protocols defined under the names of TUBA, IPv5 and IPv7, anything-over-IPSEC (tunnel or host), anything-over-SKIP -- I've not bothered to keep count, but my Internet link hasn't fallen over yet from diversity. Pity to hear about yours.
If that's the British DHS, the American counterpart is Home Depot, and it should be obvious why they'd want to spy on people. This isn't really a security issue in the same sense broken encryption or the loss of unencrypted data is a security issue, though, so can someone icon and section to "mindless stupidity in protocol design" and/or add "Stone De Croze" to the tags?
Fixed SMTP is called X.400.
They gave away Microsoft's private keys to someone who called them, a while back, in a rather infamous case that forced Microsoft to change their entire update system and their collection of "secure" sites. If they've done it once, it can clearly happen again, and the lack of publicity may simply be evidence of better media management. I'd be very wary of trusting them with anything and would be skeptical of any institution that relied on Verisign for any kind of critical proof-of-identity situation, though they're probably reasonable enough for personal certs.
BGP is supposed to be authenticated between peers, but clearly not nearly enough. If IPSEC was enabled (it's likely to already be present) on all routers, then BGP traffic between routers would be guaranteed both encrypted AND authenticated. Or, if you prefer, there are a very very few other routing protocols for WANS - ESES probably being the one most taken seriously. (ESES is the exterior gateway version of ISIS. Both are mature protocols with a lot of hardware out there that can support them.)
Find me an internet provider not using BGP, and I'll show you a European who favours ESES. Yes, this is a major problem, BGP is (almost) the only WAN protocol anyone takes seriously and is the only one meaningfully deployed. I've worried about the possibility of BGP poisoning attacks myself, but only because we have a virtual monoculture and monocultures are generally a Bad Idea. They are dangerous animals.
Paranoid. Microsoft. One of these words is redundant.
Well, as yet, I don't know of a way of using the dot-over-number nomenclature in HTML used for finite amd infinite sequences of repeating numbers. :) Yes, if there are infinite zeros, the proof you outlined is correct for showing that infinitesimal (literally) quantities are indeed zero. (Mind you, that buggers up the trivial proof for calculus, which assumes infinitesimal merely approaches zero as close as you like but is never actually equal, so that the difference function is guaranteed asymptotic to the gradient at a given point and doesn't hit any weird singularities at the limit.)
That's warkittehs!
The LEGO Mindstorm version will be released any day now!
Well, yes, 0.0(recurring)1 is technically larger than 0. However, given the extensive support in Linux for so-called "Windows-only" formats - in addition to the majority of open formats - it actually takes a LOT of skill and effort to make something NOT work with Linux. I doubt it was deliberate on the part of the Democratic party leadership, but it has to have been deliberate on the part of somebody. I guess sabotaging an entire sector of the electorate is "technically savvy" in its own way, and since it is almost certainly not going to sway anyone one way or the other when it comes to the election, they can get away with it. The technologists and technocrats have no meaningful voice and have often opposed any and all efforts to give them one, so why expect them to be heard?
Information is context-sensitive. The VERY first thing you learn when using encryption systems is that it's much easier to crack something where you know what the plaintext should look like. The second thing you learn is that the information around the encrypted data is often far more valuable intelligence-wise than the encrypted stuff. That's why those of you who have ever been instructed on the use of STU-III phones were told NOT to chat before inserting the encryption card. (You WERE paying attention to those talks, right? Right???)
Next, there's this thing called the European Union. They're getting, oh, just a little sensitive about personal information these days. You know, what with German banks freely selling personal data (such as bank account details) to anyone who calls up, despite some of the toughest data protection laws in the world. Americans may view them as unimportant nobodies, but they are at least grasping the idea that ANY unnecessary exposure of personally-identifying information is a very high risk to the individual (identity theft) and a fairly substantial risk to the economy as a whole (such theft costs - and it costs a whole lot more than any "terrorist" threat ever did).
Name and address "high risk information"? If it can be used in a social engineering attack on a bank, credit card company or Government department (and usually such people do not make much effort to validate who a person is), then it is high risk. It doesn't matter if such information has always been viewed as public, as long as human operators (and computer programs) are satisfied that such information proves identity, it is not safe to expose.
Oh, and as for the fact that this information is actually used as a substitute for secure passwords, The Cheshire Catalyst was responsible for publishing a rather pointed song on the subject by breaking into the PRESTEL account of a BBC presenter whilst he was demonstrating the service live on BBC television. The lyrics should be required reading material for anyone who uses any kind of online service, and failure to heed its warnings should be considered no different from reckless driving or setting off fireworks inside a furniture store.
Yes, and often far more data is held than is necessary. Also, if you subscribe to the notions of grid computing and cloud computing, why store the data at all? All you need to do is tell an authorized holder of the data what operation you wish to perform, and get the results, entirely black-box. You need never see the data at all.
In terms of liability, I would argue that the rule should be a generic one: if you assume control of data, you assume responsibility for that data - its accuracy, its security and its legitimacy. The distinction should come in the degree of reasonableness. It is reasonable for a non-mathematical corporation to trust RSA and Elliptic Curve public-key encryption, AES and the SHA-256, Tiger and Whirlpool cryptographic hashes. It is not reasonable for any corporation to trust unencrypted and unsigned sources - they wouldn't trust unsigned paperwork and physical signatures are easier to forge. Organizations which can be reasonably assumed to be aware of security bulletins, the assorted cryptographic lounges and other such sources should be held to the higher standard of being expected to discontinue additional use of vulnerable methods with a migration of legacy data in circulation within a sensible period.
It is never reasonable to hold data a corporation cannot use in future, cannot be sure is authentic or accurate, and/or cannot be sure is serving any legitimate purpose on the system. Since there is no excuse to hold such data, there is less of an excuse to lose it. You can't lose what you don't have, so any loss of such data - regardless of method - can never be passed off as unavoidable. It was easily avoidable. Don't keep such data. Likewise, if an individual within that corporation is provided access to information they didn't actually need, and that data is subsequently lost as a result, that should be an automatic crime even if every precaution was taken, simply because it was an unnecessary gamble and therefore not entitled to any protection or justification.
Data that is accurate, legitimate and in active use should be considered as highly sensitive, and companies that do not treat the data with the respect and maturity they are capable of and for which the data is deserving should find themselves less in hot water than boiling oil. Like I said earlier, this depends on what the company can be regarded as being aware of. All companies can be deemed aware of published security patches, common security software (Tripwire, RSA and PGP are hardly obscure!) and software equivalents of practices already in place for physical documents. Government (including military and veterans affairs) and computationally advanced organizations, as I said, should be aware of relatively mainstream peer-reviewed discoveries, not just pre-packaged solutions, and should also be aware of vulnerability scanners (Nessus, nCircle, SARA/TARA, and so on) and advanced access controls, where the size and type of organization is going to dictate what sort of preventative measures are cost-effective.
Where a company falls below what can reasonably be expected of it, and loses data, that's boiling oil time. Where a company meets or exceeds a rational, sane level of protection and still loses data it needed to have, it should still be responsible for contributing towards cleaning up the mess (same as you would in a truly no-fault car accident) but shouldn't be punished for what was beyond its abilities to deal with. (That "needed to have" qualifier really is important.)
If a company deliberately places data in a dangerously exposed context (eg: pushing personal data onto unsecure systems overseas to avoid any national laws on data security), then they deserve not only the boiling oil treatment but a loss of right to operate. Dodging the law or evading responsibility is not a helpful way to tackle data insecurity, even if it looks like a cheap way to solve the problem for the company.
To those who argue that this is a slippery slope, I'd say that reasonable conduct can never be a slope, nor can it be slippery. If anything, it is a great leveler and a superb provider of grip and balance.
How about this - I won't blame you, but I WILL blame some of the egotistical b* who have happily caused harm to Linux and the free software movement in order to plunder corporations and organizations and destroy genuine attempts at real innovation for the sake of raking in the cash and fluffing up their egos. You've probably encountered some, I certainly have. I won't name names because I happen to know they can afford considerably better lawyers, and some accusations are - by nature - rather hard to prove. But if Linux fails, it is because it has been sabotaged from within, it is because innovators and inventors are being given a raw deal far too often.
(Yes, I'm extremely angry. Not at just one person, but many who feel that they are far more important than the free software that they ride the coat-tails of. Over the past 12 years, I've seen enough to convince me that Linux' success is by the fortune of competent, ethical developers outnumbering the highway robbers. The Linux Foundation and its members' biggest contribution will be on how well they ensure it stays that way.)
Also bear in mind that variable-length addresses were proposed as a part of the IPv6 specification (TUBA) but were rejected on the grounds of making the hardware over-complicated. I personally thought the idea quite neat, but admit that there isn't a vast amount of value in it. IPv6 addressing mimics variable-length addressing by means of the prefix, so you end up checking only one byte prior to the end of your prefix and one byte after, which is what you'd be doing with variable-length addresses.
One thing that surprises me in the IPv6 discussion is that although people talk quite happily about data centers and high-end servers, not all such systems are set up on Ethernet. A fair percentage are set up on Infiniband, particularly for network storage, on account of the far lower latencies and far greater bandwidth. Infiniband is designed to cooperate with IPv6 - any packet on one can be trivially mapped onto the other - but there is no way of mapping Infiniband onto IPv4. NAT only goes so far. This means a data center with Infiniband local networking and IPv6 remote networking is simple to set up, simple to administrate, simple to develop, simple to maintain. Sure, it's not the dominant architecture, but by definition data centers are thin on the ground anyway. You don't want data centers to be a common design, you do want them to be an efficient design.
1. Vendors won't support IPv6 because users don't need it for their current apps.
2. Vendors won't add IPv6 to their current apps because it's not being supported by vendors.
I don't see the users getting much input in all of this. The vendors won't create a killer IPv6 app because vendors won't support IPv6 on the network, and vice versa. The user is completely ignored and is totally outside of that equation. But the user is then blamed for the lack of IPv6 adoption on both sides, for failing to demand what was never on the table to begin with.
I thought it was 74.8% of percentages and 89.2% of all other statistics.
1. Not too many processors allow you to handle 1-bit or 4-bit structures, of which the IPv4 header contains many. The difference is the direction, not the direct handling.
2. Since IPv6 should have fewer exceptions to general cases, the number of nodes in the radix tree should be significantly lower, so giving you a net save.
3. Performance is so unimportant that IPv4 latency is one of the biggest things people loath and despise about IPv4. ATM is hardly a decent protocol, the payloads are absurdly small, but the latency is almost non-existent. As grids and clouds increase in usage, network latency is going to be the only latency that people will care about.
There are ISPs that provide IPv6 in the US and who can "replace" your existing ISP, but coverage is not that great. Tunnels, via services like Hurricane Electric, are generally better.
All the good terms were written down by H. G. Welles and a rogue band of cryogenically frozen ancient Greek scientists, then trademarked at suitable points in the future. He is currently living with Elvis, who had stumbled on his ruse after discovering his latest hits were written five years after being published.