These reports are that we've reached or passed the "peak addresses" point, where 50% of the addresses have been used up. These reports by communists are overstated- addresses are never going to run out due to market forces preventing this./sarcasm
It's not that it's regulated, it's what the regulations ARE that matter.
The roads are regulated. They work fine (well apart from congestion, but I doubt that's the regulations fault.)
The real network neutrality problem is to do with prioritisation. We need several levels of prioritisation, and we need guaranteed bandwidth at some level (for example, the ISPs could be forced to quote a contention ratio, and STICK TO IT.) And they need to tell us how much bandwidth of each prioritisation level we get to use per payment period and... that's about it.
Infinite bandwidth simply doesn't exist and any ISP that claims that they give that, need to be regulated to stop. And all of the bandwidth that you do get is paid for by the subscribers, one way or another. All you can eat doesn't work if you have infinite hunger, and on the internet, some people do.
Okinawans live quite a long while and seem to live on a low calorie, nutrient rich diet though.
The problem is that 80 years is actually not long, since nobody has completed a controlled experiment, even with monkeys yet. If the experiment with humans will take about 85 years, and nobody has started it yet, the lack of evidence doesn't really mean anything!
It's going to be OK, provided it's only a small amount of traffic involved. But if everyone starts sending a lot of traffic like this... boom!
In a sense Google are just saying that their search results are high priority traffic, and they've optimised it like that. Which is probably fair enough.
But if you did that to anything that creates huge numbers of connections very rapidly and then sends a lot of data, perhaps using it for peer-peer networks, the network would start to suffer collapse.
It depends on how the blocking is done. If the car sends a signal to the phone, then the phone can disable everything except emergency services and possibly the operator.
And if they just simply jammed the phone, I'm sure the FCC would have something to say, for that reason.
"Meanwhile people who are thousands of times more likely to be an issue can't be targeted even though it makes good sense."
Sorry that's wrong.
I don't mean that it's racist, although it is.
It's wrong because it doesn't work.
The problem is that you don't know who actually is a suicide bomber, based on the color of their skin or their general appearance. And if you only search certain ethnic groups, then the terrorists will just get bombers from different ethnic groups to do it.
The wanna-be shoe bomber, wasn't ethnically anything other than white male.
Yeah, but the 'balance' they've chosen is to put the code segment of the freaking benchmark into their peephole optimizer, and then published it as if that's representative of their compiler.
A lot of magazines just run all the benchmark tests and print the average of all the tests. Even a single test that comes back a lot quicker can change the average enough to make the overall results much better than your competitors results.
"The benchmark runs an expensive loop, and then does nothing with the results; the benchmark is written exactly in a way that triggers this general optimization [dead code elimination].
Of course, the benchmark could be rewritten to avoid triggering this optimization, which would bring our performance on this specific benchmark in line with other browsers.
The interest in this issue is a great example of why these microbenchmarks fail to represent the real world web. Webkit Sunspider uses an expensive JavaScript loop to approximate sine and cosine. Real world sites would actually use the much faster and CPU-optimized functions already available in JavaScript engines.
These optimizations are relatively new to the world of JavaScript runtimes even though there are many examples of dead code in real-world JavaScript on the Web. These optimizations often require significant flow analysis of the code, and in a real world site, spending too much time analyzing code can reduce the responsiveness of the page. The Chakra engine picks the right balance between code quality and analysis time, and only performs a small set of dead code optimizations. We continue to tune this for IE9, and bugs reported via Microsoft Connect are examples of where the optimization could do more. We continue to tune these and other optimizations for the final release."
In other words, they don't think dead code elimination is really worth it, so they only do a bit, and when they do it, it 'just happens' to optimise this benchmark. They've done no general optimisations.
That's corporate speak for: "Yup, we cheated! Doesn't everyone? The test was stupid anyway!"
Which bit of the term NETWORK neutrality don't you understand??
The NETWORK is the bit that *connects* computers together, not the computers themselves.
It's not a violation of network neutrality if you try to get a service from a server across a network, but that server doesn't want to give it to you. Almost no server on the internet will give you any significant level of service at all, and never have.
The difference is that we *pay* the network to relay our packets around, and we expect them to actually do that, and not get into bed with some other entity and deliberately drop some of our packets because of it.
There's different levels of blocking anonymous editors. Mostly likely they'll set it so that only existing wikipedia editors would be able to edit, so Wikipedia will probably block new account creation for that IP range as well..
No, *Verizon* have a vandal, that is paying Verizon money to vandalise the Wikipedia.
Often the vandal is breaking multiple laws, and the ISP is enabling them, for money, and refusing to investigate it or even warn the user off.
It's not an ethically or legally neutral position for Verizon to take, and Verizon have failed to act before with other vandals. It's almost certain that the vandal is breaking Verizon's own terms and conditions as well.
In some cases if people can't quantify things, then they will make completely the wrong decisions.
Obviously if something can't be quantified anyway, that's one thing. But if you can quantify it, and you fail to, then you can make majorly bad screw-ups.
Something can sound like the *best* thing in the world, but when you do the numbers, it messes up. For example, making bioethanol from corn in the united states seems to have been a really bad move. Making it from sugar beet or cane gives many times more energy for the same initial fuel in a tractor.
And of course his engine will be so much more efficient that oil won't run out within the next 20 years anymore, and if it does, it will be so much more flexible that it will be able to burn coal, or run off solar, of course.
Oh! Wait!
Electric vehicles are essentially the ultimate flex-fuel car; anything you can turn into electricity, they can use, with low additional losses.
If you're being strict, your proof is slightly wrong; you have to do something like express it as the limit of 1-0.1^n and then take n to infinity and show that the error goes to zero.
Just doing 0.99(9) and dividing by 9 - you have a different number of 9s when you do the subtraction. In this case it happens to give the right answer, but the method you used can give the wrong answer in other somewhat similar cases, whereas if you use limits then you get sensible answers.
I think the chosen strategy is mostly tunnelling. You sit the IPv6 on top of IPv4. IPv4 can then be NATTED up the wazzoo, and then you do all the packet routing at the IPv6 level. There's a small performance hit from that, but when we run out of IP addresses, it will be the cheapest way, and it won't be *that* slow, and it's easiest to deploy.
I mean really, the joke about their being 'internets' is now true. We have two internets, IPv4 and IPv6. They're completely different protocols and internets that don't interwork, and there's even RFC 4966 that says you're not supposed to make them interwork using NAT because it works even worse than NAT does on IPv4 only networks for various reasons.
P2P is an edge application, and hence is the easiest type of thing to move to IPv6. A few weeks hacking and turning on tunneling and poof, IPv6 enabled.
The tuff stuff is the website and hardware that keeps the IPv4 going. A lot of that proably isn't going to change for years or even decade(s). I mean, if you're an ISP, you've got IPv4, and that's about it.
Slashdot Mirror
No, it still seems to be leaking memory here; closing tabs does reclaim much of the memory, but not all of it.
Firefox 3 recently had a major bugfix that seems to have fixed that for me though; hopefully it will get propagated into Firefox 4 as well.
You need to follow the money. If he was as nutty as he seemed to be he would certainly have been fired by now. He's being paid to spout this crap.
What kind of communist nonsense is this?
When somebody has done something good, their childrens childrens children* deserve an ongoing income too!!!
* -copyright is life plus 70 years, possibly longer if Disney pays up again to the right politicians
I agree, and there's no way that they could predict that this could help them sell new routers to monetize from IPv6 upgrades either.
All economic booms are fraudulent.
Modern economies grow between -1 to 3%, with no lower limit on shrinkage.
Anything above that, somebody somewhere is bubbling, and in the middle of it is fraud.
These reports are that we've reached or passed the "peak addresses" point, where 50% of the addresses have been used up. These reports by communists are overstated- addresses are never going to run out due to market forces preventing this. /sarcasm
People always talk about global pole shifting, but nobody ever does anything about it!
It's not that it's regulated, it's what the regulations ARE that matter.
The roads are regulated. They work fine (well apart from congestion, but I doubt that's the regulations fault.)
The real network neutrality problem is to do with prioritisation. We need several levels of prioritisation, and we need guaranteed bandwidth at some level (for example, the ISPs could be forced to quote a contention ratio, and STICK TO IT.) And they need to tell us how much bandwidth of each prioritisation level we get to use per payment period and... that's about it.
Infinite bandwidth simply doesn't exist and any ISP that claims that they give that, need to be regulated to stop. And all of the bandwidth that you do get is paid for by the subscribers, one way or another. All you can eat doesn't work if you have infinite hunger, and on the internet, some people do.
Okinawans live quite a long while and seem to live on a low calorie, nutrient rich diet though.
The problem is that 80 years is actually not long, since nobody has completed a controlled experiment, even with monkeys yet. If the experiment with humans will take about 85 years, and nobody has started it yet, the lack of evidence doesn't really mean anything!
It's going to be OK, provided it's only a small amount of traffic involved. But if everyone starts sending a lot of traffic like this... boom!
In a sense Google are just saying that their search results are high priority traffic, and they've optimised it like that. Which is probably fair enough.
But if you did that to anything that creates huge numbers of connections very rapidly and then sends a lot of data, perhaps using it for peer-peer networks, the network would start to suffer collapse.
You must be in quite a state.
IBM were allowed to make changes between games, and there's no evidence that any tweaking was done during a single game.
It depends on how the blocking is done. If the car sends a signal to the phone, then the phone can disable everything except emergency services and possibly the operator.
And if they just simply jammed the phone, I'm sure the FCC would have something to say, for that reason.
"Meanwhile people who are thousands of times more likely to be an issue can't be targeted even though it makes good sense."
Sorry that's wrong.
I don't mean that it's racist, although it is.
It's wrong because it doesn't work.
The problem is that you don't know who actually is a suicide bomber, based on the color of their skin or their general appearance. And if you only search certain ethnic groups, then the terrorists will just get bombers from different ethnic groups to do it.
The wanna-be shoe bomber, wasn't ethnically anything other than white male.
Yeah, but the 'balance' they've chosen is to put the code segment of the freaking benchmark into their peephole optimizer, and then published it as if that's representative of their compiler.
It's basically corrupt and fraudulent.
A lot of magazines just run all the benchmark tests and print the average of all the tests. Even a single test that comes back a lot quicker can change the average enough to make the overall results much better than your competitors results.
They've more or less admitted it at: http://blogs.msdn.com/b/ie/archive/2010/11/17/html5-and-real-world-site-performance-seventh-ie9-platform-preview-available-for-developers.aspx
"The benchmark runs an expensive loop, and then does nothing with the results; the benchmark is written exactly in a way that triggers this general optimization [dead code elimination].
Of course, the benchmark could be rewritten to avoid triggering this optimization, which would bring our performance on this specific benchmark in line with other browsers.
The interest in this issue is a great example of why these microbenchmarks fail to represent the real world web. Webkit Sunspider uses an expensive JavaScript loop to approximate sine and cosine. Real world sites would actually use the much faster and CPU-optimized functions already available in JavaScript engines.
These optimizations are relatively new to the world of JavaScript runtimes even though there are many examples of dead code in real-world JavaScript on the Web. These optimizations often require significant flow analysis of the code, and in a real world site, spending too much time analyzing code can reduce the responsiveness of the page. The Chakra engine picks the right balance between code quality and analysis time, and only performs a small set of dead code optimizations. We continue to tune this for IE9, and bugs reported via Microsoft Connect are examples of where the optimization could do more. We continue to tune these and other optimizations for the final release."
In other words, they don't think dead code elimination is really worth it, so they only do a bit, and when they do it, it 'just happens' to optimise this benchmark. They've done no general optimisations.
That's corporate speak for: "Yup, we cheated! Doesn't everyone? The test was stupid anyway!"
Which bit of the term NETWORK neutrality don't you understand??
The NETWORK is the bit that *connects* computers together, not the computers themselves.
It's not a violation of network neutrality if you try to get a service from a server across a network, but that server doesn't want to give it to you. Almost no server on the internet will give you any significant level of service at all, and never have.
The difference is that we *pay* the network to relay our packets around, and we expect them to actually do that, and not get into bed with some other entity and deliberately drop some of our packets because of it.
There's different levels of blocking anonymous editors. Mostly likely they'll set it so that only existing wikipedia editors would be able to edit, so Wikipedia will probably block new account creation for that IP range as well..
No, *Verizon* have a vandal, that is paying Verizon money to vandalise the Wikipedia.
Often the vandal is breaking multiple laws, and the ISP is enabling them, for money, and refusing to investigate it or even warn the user off.
It's not an ethically or legally neutral position for Verizon to take, and Verizon have failed to act before with other vandals. It's almost certain that the vandal is breaking Verizon's own terms and conditions as well.
In some cases if people can't quantify things, then they will make completely the wrong decisions.
Obviously if something can't be quantified anyway, that's one thing. But if you can quantify it, and you fail to, then you can make majorly bad screw-ups.
Something can sound like the *best* thing in the world, but when you do the numbers, it messes up. For example, making bioethanol from corn in the united states seems to have been a really bad move. Making it from sugar beet or cane gives many times more energy for the same initial fuel in a tractor.
And of course his engine will be so much more efficient that oil won't run out within the next 20 years anymore, and if it does, it will be so much more flexible that it will be able to burn coal, or run off solar, of course.
Oh! Wait!
Electric vehicles are essentially the ultimate flex-fuel car; anything you can turn into electricity, they can use, with low additional losses.
If you're being strict, your proof is slightly wrong; you have to do something like express it as the limit of 1-0.1^n and then take n to infinity and show that the error goes to zero.
Just doing 0.99(9) and dividing by 9 - you have a different number of 9s when you do the subtraction. In this case it happens to give the right answer, but the method you used can give the wrong answer in other somewhat similar cases, whereas if you use limits then you get sensible answers.
I think the chosen strategy is mostly tunnelling. You sit the IPv6 on top of IPv4. IPv4 can then be NATTED up the wazzoo, and then you do all the packet routing at the IPv6 level. There's a small performance hit from that, but when we run out of IP addresses, it will be the cheapest way, and it won't be *that* slow, and it's easiest to deploy.
I mean really, the joke about their being 'internets' is now true. We have two internets, IPv4 and IPv6. They're completely different protocols and internets that don't interwork, and there's even RFC 4966 that says you're not supposed to make them interwork using NAT because it works even worse than NAT does on IPv4 only networks for various reasons.
P2P is an edge application, and hence is the easiest type of thing to move to IPv6. A few weeks hacking and turning on tunneling and poof, IPv6 enabled.
The tuff stuff is the website and hardware that keeps the IPv4 going. A lot of that proably isn't going to change for years or even decade(s). I mean, if you're an ISP, you've got IPv4, and that's about it.