It's not "peer reviewed". At best, it's "peer read". Google's data is only 100% valid for GOOGLE. It's their data on their infrastructure. Unless you happen to have a Google Datacenter, the results aren't that valuable to you.
I keep my DC (~800sq.ft) at 68F. Mostly because I prefer to work in a cool space. (well, cool while I'm in the cool isle.) But also because of cooling capacity; if the HVAC is off, how long does it take to reach 105F? from 68, about 15 min, from 82 a few minutes. However rare that may be, it's still non-zero.
I've said this before... Temperature stability is the important part. The actual setpoint is of little importance. Google has been doing this on such a large scale, long enough to have the data to tweak their setpoint. (I still say it's voodoo science as they're aiming at a very mobile target -- hard drive logevity.)
Actually, we *ARE* building new ones. The problem is how long it takes to build, and the fact that we're building *very few* new reactors.
Every reactor we have (in the US) is over 30 years old (most over 40!) They were not designed to be in continuous use for this long. They've held up quite well, but 3-4 decades of neutron bombardment is not healthy for the containment vessel. There's a simply hideous accident in our future.
The same was said of the switch to digital OTA. It is necessary as NTSC over cable is outdated (old), inefficient, and wasteful. In fact, the largest push-back has always been people's hatred of a "cable box". With almost everyone using DVRs now, you will already have an extra box anyway.
In the space used by a single, standard definition, analog channel, they can broadcast 12+ digital SD stations (which, btw, they already do!), or 3-6 HD stations. When the cableco is *still* broadcasting 50-60(!!) analog channels for the old farts who cannot be bothered to move into the now, that's an absolute f***-load of bandwidth being wasted.
('tho politically, they keep analog around so they can charge a premium for "digital cable")
"digital only" refers to the cable side. The rules still require cable receivers be able to process NTSC (analog) channels. I, for one, wish the morons in charge of cable companies would just cut it out and drop the waste of space that is analog channels.
It was so obvious 15 years ago when Tivo, Inc. did it, NO ONE ELSE WAS. So it wasn't all that "obvious". (In fact, they put a lot of work into the exact correction factors. And they've refined them since then.)
30min to 80% is still a horrible joke. Even more so for a car with about 100 mile range. But "range" isn't the issue here. Time to getting that full range back is the real problem. (we used to drive around in cars that had 100-200 mile range, back in the era of heavy steel cars that ran under 10mpg.)
And rapid charging is very bad for batteries. If you rapid charge it to 80%, you cannot get it to 100%. It's a lot like packing a suitcase; you can get more stuff in there if you pack it slow and neat vs. just throwing shit in it and running. If you do it regularly, it tends to damage the battery.
Joule per joule, yes electric motors are much more efficient. However, factoring in capacity and recharge times, EVs are HORRIBLE. My gas car (hybrid / lexus HS, very small batteries) can go 450-500 miles before refueling -- that's 2-3 weeks. It takes 2 minutes to pump 12gal into it. Find me ANY battery powered car that can go even half that, that doesn't take hours to recharge to the point it can do it again. There are plenty of "toy cars" that can run around a city during the day (~100miles) but then it takes 8-12hrs to fully recharge it (i.e. all night to recharge)
No, no I haven't... because I've seen the insides of a cellphone and tablet. I'm surprised it's not smaller!
[*] 90% of a cellphone is it's battery; even more for a tablet. If there were no need for a screen or keypad, the whole thing would be the size of a sugar packet.
You still miss the point entirely. How does one device find another on the wire? IPv4 uses "arp", which is a layer-2 broadcast that every device on the network will see, even if it's not interested in IPv4. IPv6 uses "nd", which is a layer-2 multicast that only interested devices will see. They are functionally the same. As you add more devices to the network, the amount of broadcast (v4) or multicast (v6) traffic increases. Eventually, it becomes a problem.
(This problem has been around for a long time. IPv6 hasn't magically fixed it.)
You go right ahead and build your 10Gb multi-thousand dollar *home* network. I'll happily countinue counting my wads of cash next to my multi-hundred dollar 1gig network.
(actually $99 exactly. that's what I paid for that old nortel ERS5510-48T)
What they didn't tell you about that Magic(tm) IPv6 setup... a) it's not "native" IPv6; it's a 6rd tunnel, b) it's not firewalled. So all of your windows boxes were put on the internet naked and you didn't even know it. Sure, 2 machines in a 2^64 sea is a bit of a hunt, and with privacy extentions the addresses aren't guessable, but the instant you connect to someone, you aren't hidden anymore.
* It doesn't take a couple of months to a year. For small businesses, it takes 5 seconds to plug in a new router from an ISP that offers dual stack IPv6. All current end user machines already support IPv6, even phones and tablets.
Sure, it might take 5s to plug it in, but it will take months to a) find that ISP, and b) get the circuit from that ISP installed, and c) get the ISP to turn up that service. (I've not managed "a" yet, but I've been through "b" and "c" too many times.)
* It doesn't require expert networking folks to implement it. IPv6 is MUCH simpler than IPv4, it's totally plug'n'play because IPv6 router advertisements handle everything....
It's p-n-p at the desktop, NOT THE ROUTER. Having unskilled morons screwing with your router(s) is a recipe for Bad Things Happening(tm).
And there's more work necessary than just the network. Any internal services will need to be dealt with as well. (esp. your internal DNS server(s))
* It's not risky, because IPv6 runs alongside IPv4
Famous last words from someone who hasn't done a live deployment! IPv6 hosts tend to prefer IPv6 over IPv4 where both are available. So, the second IPv6 is available -- literally within seconds of the RA -- those hosts are going to start trying to make IPv6 connections. If your new IPv6 network is not 100% perfectly operational and as fast as your IPv4 network, everything is going to go to hell quickly. All of a sudden, pages that loaded instantly take seconds to *begin* to load and take minutes to finish... because it's trying to make every connection over an IPv6 network that isn't working, then it falls back to IPv4; for every connection.
* What companies get out of it is that their customer base grows, because they become reachable by all the Pacific Rim users that are being allocated IPv6 addresses because IPv4 address space ran out for them a while back.
Actually, I've known a great many US businesses that would prefer most of Asia wasn't on the internet! (99% of their spam and network attacks come from there, while 0% of their business does.)
Negative. The *ONLY* thing that says "/64" is SLAAC. You can make a LAN segment any size you want. If it's not a/64, then the lame address autoconfiguration won't work, but everything else will.
That said, ISPs aren't going to make a ton more work for themselves here. So a/64 is likely the smallest thing you'll get from them. Ya' know, when they can be bothered to "do" IPv6 at all.
You're thinking Uverse. Comcast dropped tunnels as a F'ing Bad Idea(tm). Where they do IPv6 (read: not many places), it's a native IPv6 (dual-stack) transport. There are no bandwidth wasting, latency robbing tunnels involved.
Actually, most routers today are not IPv6 firewalls. Their firewall capabilities are tied to NAT. For example, the most basic Cisco IOS feature set includes NAT, but it does not include an IPv6 firewall; for that, you have to go to a "security" image.
Indeed. I've said that, too. Nobody learned the lessons from the early "land rush" days of IPv4.
When it comes to the US DoD, they tend to use globally unique address space in secure private networks. The existing SIPRnet uses ("used" as they're supposed to be v6 now) "public" IPv4 address numbers. This is to avoid confusion, and know when someone has leaked classified networking data. (also "because we f'ing can")
It simply IS an alternate configuration. The IPv6 firewall needs every bit the same complex intelligence as the IPv4 firewall -- it won't have to rewrite packets, 'tho.
I don't doubt your admins have put far more effort than necessary into blocking IPv6. It's actually *really* trivial to block... if you understand how IPv6 works.
it provides a whole host of IP addresses that can be used to enhance their security.
It, in fact, does the exact opposite. IPv6 removes the one thing that effectively secures their current network: NAT. In the IPv6 world, everything has a globally routable address (sometimes more than one); every host can talk to every other host at will. One will have to setup/configure a proper firewall on the IPv6 network to limit inbound connections, and track (and maybe limit) all outbound connections. That v6 stateful firewall will still need the same hundreds of protocol helpers to look into the payload to know what holes to poke in the inbound wall.
Comcast is doing nothing more than hand-wavey marketing BS. "See, we support IPv6" *micro print*to 0.001% of our customers, in 2 markets, if they go to a hidden, unpublished website to sign up, and then configure it themselves*micro print*
AT&T Uverse is just as bad with their complete and utter bull**** of 6rd tunnels. And that's their internally and externally documented plan for the future. At least Comcast realized tunnels are completely wrong.
This, too, has been debated into infinity. Had IANA/ARIN started the process the day the IPng working-group was formed, maybe they be done with the court cases by now. Even if every legacy/8 holder returned that space, we still have the same problem... We will run out of IPv4 addresses. Legacy space would, at best, drag it out another year. Not. F'ing. Worth it.
VLANs are layer-2 technology; they're used for layer-2 reasons -- limiting/isolating broadcast domains. Those reasons still exist in v6 networks. In most cases, even more so due to the potentially enormous segment sizes (read: 2^64, not that anyone can possibly put anywhere near that many machines in a single segment. This has been debated in networking circles at length, repeatedly.)
In software (slowest path), maybe. In hardware... that's not true. An modern network should've been upgraded to support hardware switching of IPv6 by now, but there are many that haven't. (I've had this arguement before: you're a moron if you've refreshed your hardware and not considered IPv6.)
Looking at linux (since it's right here)... the ipv4 stack is about 600k. the ipv6 stack (module) is 400-500k. Those numbers will changes depending on the selected options, but that's a good baseline. They gzip to 200k and 145k, respectively. As most router vendors treat flash like it's made of alien rocks, an extra ~200k of flash simply may not be there -- all the tools/UI's have to support v6 too. And then there's the very limited ram as well.
As one who's worked with a lot of Cat6, this is true. The cable is larger, stiffer, and has a nylon spacer in the center to properly align the pairs (reduces crosstalk.) It's only slightly more work to deal with. (read: termination is a slower process)
It's not "peer reviewed". At best, it's "peer read". Google's data is only 100% valid for GOOGLE. It's their data on their infrastructure. Unless you happen to have a Google Datacenter, the results aren't that valuable to you.
I keep my DC (~800sq.ft) at 68F. Mostly because I prefer to work in a cool space. (well, cool while I'm in the cool isle.) But also because of cooling capacity; if the HVAC is off, how long does it take to reach 105F? from 68, about 15 min, from 82 a few minutes. However rare that may be, it's still non-zero.
I've said this before... Temperature stability is the important part. The actual setpoint is of little importance. Google has been doing this on such a large scale, long enough to have the data to tweak their setpoint. (I still say it's voodoo science as they're aiming at a very mobile target -- hard drive logevity.)
Actually, we *ARE* building new ones. The problem is how long it takes to build, and the fact that we're building *very few* new reactors.
Every reactor we have (in the US) is over 30 years old (most over 40!) They were not designed to be in continuous use for this long. They've held up quite well, but 3-4 decades of neutron bombardment is not healthy for the containment vessel. There's a simply hideous accident in our future.
The same was said of the switch to digital OTA. It is necessary as NTSC over cable is outdated (old), inefficient, and wasteful. In fact, the largest push-back has always been people's hatred of a "cable box". With almost everyone using DVRs now, you will already have an extra box anyway.
In the space used by a single, standard definition, analog channel, they can broadcast 12+ digital SD stations (which, btw, they already do!), or 3-6 HD stations. When the cableco is *still* broadcasting 50-60(!!) analog channels for the old farts who cannot be bothered to move into the now, that's an absolute f***-load of bandwidth being wasted.
('tho politically, they keep analog around so they can charge a premium for "digital cable")
"digital only" refers to the cable side. The rules still require cable receivers be able to process NTSC (analog) channels. I, for one, wish the morons in charge of cable companies would just cut it out and drop the waste of space that is analog channels.
It was so obvious 15 years ago when Tivo, Inc. did it, NO ONE ELSE WAS. So it wasn't all that "obvious". (In fact, they put a lot of work into the exact correction factors. And they've refined them since then.)
30min to 80% is still a horrible joke. Even more so for a car with about 100 mile range. But "range" isn't the issue here. Time to getting that full range back is the real problem. (we used to drive around in cars that had 100-200 mile range, back in the era of heavy steel cars that ran under 10mpg.)
And rapid charging is very bad for batteries. If you rapid charge it to 80%, you cannot get it to 100%. It's a lot like packing a suitcase; you can get more stuff in there if you pack it slow and neat vs. just throwing shit in it and running. If you do it regularly, it tends to damage the battery.
Joule per joule, yes electric motors are much more efficient. However, factoring in capacity and recharge times, EVs are HORRIBLE. My gas car (hybrid / lexus HS, very small batteries) can go 450-500 miles before refueling -- that's 2-3 weeks. It takes 2 minutes to pump 12gal into it. Find me ANY battery powered car that can go even half that, that doesn't take hours to recharge to the point it can do it again. There are plenty of "toy cars" that can run around a city during the day (~100miles) but then it takes 8-12hrs to fully recharge it (i.e. all night to recharge)
No, no I haven't... because I've seen the insides of a cellphone and tablet. I'm surprised it's not smaller!
[*] 90% of a cellphone is it's battery; even more for a tablet. If there were no need for a screen or keypad, the whole thing would be the size of a sugar packet.
You still miss the point entirely. How does one device find another on the wire? IPv4 uses "arp", which is a layer-2 broadcast that every device on the network will see, even if it's not interested in IPv4. IPv6 uses "nd", which is a layer-2 multicast that only interested devices will see. They are functionally the same. As you add more devices to the network, the amount of broadcast (v4) or multicast (v6) traffic increases. Eventually, it becomes a problem.
(This problem has been around for a long time. IPv6 hasn't magically fixed it.)
You go right ahead and build your 10Gb multi-thousand dollar *home* network. I'll happily countinue counting my wads of cash next to my multi-hundred dollar 1gig network.
(actually $99 exactly. that's what I paid for that old nortel ERS5510-48T)
What they didn't tell you about that Magic(tm) IPv6 setup... a) it's not "native" IPv6; it's a 6rd tunnel, b) it's not firewalled. So all of your windows boxes were put on the internet naked and you didn't even know it. Sure, 2 machines in a 2^64 sea is a bit of a hunt, and with privacy extentions the addresses aren't guessable, but the instant you connect to someone, you aren't hidden anymore.
Sure, it might take 5s to plug it in, but it will take months to a) find that ISP, and b) get the circuit from that ISP installed, and c) get the ISP to turn up that service. (I've not managed "a" yet, but I've been through "b" and "c" too many times.)
It's p-n-p at the desktop, NOT THE ROUTER. Having unskilled morons screwing with your router(s) is a recipe for Bad Things Happening(tm).
And there's more work necessary than just the network. Any internal services will need to be dealt with as well. (esp. your internal DNS server(s))
Famous last words from someone who hasn't done a live deployment! IPv6 hosts tend to prefer IPv6 over IPv4 where both are available. So, the second IPv6 is available -- literally within seconds of the RA -- those hosts are going to start trying to make IPv6 connections. If your new IPv6 network is not 100% perfectly operational and as fast as your IPv4 network, everything is going to go to hell quickly. All of a sudden, pages that loaded instantly take seconds to *begin* to load and take minutes to finish... because it's trying to make every connection over an IPv6 network that isn't working, then it falls back to IPv4; for every connection.
Actually, I've known a great many US businesses that would prefer most of Asia wasn't on the internet! (99% of their spam and network attacks come from there, while 0% of their business does.)
Negative. The *ONLY* thing that says "/64" is SLAAC. You can make a LAN segment any size you want. If it's not a /64, then the lame address autoconfiguration won't work, but everything else will.
That said, ISPs aren't going to make a ton more work for themselves here. So a /64 is likely the smallest thing you'll get from them. Ya' know, when they can be bothered to "do" IPv6 at all.
You're thinking Uverse. Comcast dropped tunnels as a F'ing Bad Idea(tm). Where they do IPv6 (read: not many places), it's a native IPv6 (dual-stack) transport. There are no bandwidth wasting, latency robbing tunnels involved.
Actually, most routers today are not IPv6 firewalls. Their firewall capabilities are tied to NAT. For example, the most basic Cisco IOS feature set includes NAT, but it does not include an IPv6 firewall; for that, you have to go to a "security" image.
Indeed. I've said that, too. Nobody learned the lessons from the early "land rush" days of IPv4.
When it comes to the US DoD, they tend to use globally unique address space in secure private networks. The existing SIPRnet uses ("used" as they're supposed to be v6 now) "public" IPv4 address numbers. This is to avoid confusion, and know when someone has leaked classified networking data. (also "because we f'ing can")
It simply IS an alternate configuration. The IPv6 firewall needs every bit the same complex intelligence as the IPv4 firewall -- it won't have to rewrite packets, 'tho.
I don't doubt your admins have put far more effort than necessary into blocking IPv6. It's actually *really* trivial to block... if you understand how IPv6 works.
It, in fact, does the exact opposite. IPv6 removes the one thing that effectively secures their current network: NAT. In the IPv6 world, everything has a globally routable address (sometimes more than one); every host can talk to every other host at will. One will have to setup/configure a proper firewall on the IPv6 network to limit inbound connections, and track (and maybe limit) all outbound connections. That v6 stateful firewall will still need the same hundreds of protocol helpers to look into the payload to know what holes to poke in the inbound wall.
Comcast is doing nothing more than hand-wavey marketing BS. "See, we support IPv6" *micro print*to 0.001% of our customers, in 2 markets, if they go to a hidden, unpublished website to sign up, and then configure it themselves*micro print*
AT&T Uverse is just as bad with their complete and utter bull**** of 6rd tunnels. And that's their internally and externally documented plan for the future. At least Comcast realized tunnels are completely wrong.
This, too, has been debated into infinity. Had IANA/ARIN started the process the day the IPng working-group was formed, maybe they be done with the court cases by now. Even if every legacy /8 holder returned that space, we still have the same problem... We will run out of IPv4 addresses. Legacy space would, at best, drag it out another year. Not. F'ing. Worth it.
VLANs are layer-2 technology; they're used for layer-2 reasons -- limiting/isolating broadcast domains. Those reasons still exist in v6 networks. In most cases, even more so due to the potentially enormous segment sizes (read: 2^64, not that anyone can possibly put anywhere near that many machines in a single segment. This has been debated in networking circles at length, repeatedly.)
In software (slowest path), maybe. In hardware... that's not true. An modern network should've been upgraded to support hardware switching of IPv6 by now, but there are many that haven't. (I've had this arguement before: you're a moron if you've refreshed your hardware and not considered IPv6.)
Looking at linux (since it's right here)... the ipv4 stack is about 600k. the ipv6 stack (module) is 400-500k. Those numbers will changes depending on the selected options, but that's a good baseline. They gzip to 200k and 145k, respectively. As most router vendors treat flash like it's made of alien rocks, an extra ~200k of flash simply may not be there -- all the tools/UI's have to support v6 too. And then there's the very limited ram as well.
As one who's worked with a lot of Cat6, this is true. The cable is larger, stiffer, and has a nylon spacer in the center to properly align the pairs (reduces crosstalk.) It's only slightly more work to deal with. (read: termination is a slower process)
"LAWYERS"