Why is this a 'preferred convention' for Python3? Doing this causes a lot of confusion for Python beginners that write code in Python2 (i.e. it causes them to accidentally use old-style classes). A better practice is to add the extra word i.e. 'class ClassName(object):' for both Python2 and Python3 code. This is especially true if you are writing Python tutorials. Since we are going through this Python2 to Python3 transition it is better to minimize the differences in the cases where they don't really matter (i.e. add the extra 'object' word).
Paying teachers more does not necessarily get higher quality teachers. If teachers were judged on merit and poor teachers were fired, then paying teachers more might be reasonable. But since teachers unions insist on tenure, have pay based on seniority, and make it exceptionally difficult to fire poor teachers, paying teachers more will not generally result in better quality education.
As someone else pointed out above, there are much more fundamental issues than pay--notably being able to fire poor teachers, elimination of tenure, pay based on merit/not seniority.
Enough with the fear mongering headlines already. Yes, IANA allocated the last 5 /8's to the regional registries. IPv4 is not going anywhere anytime soon.
I edited out over and replaced it with depleted to satisfy the concern about the headline, but I didn't even like doing that. The cavalier attitude that "nothing is really wrong, keep doing what we're doing" has been an extensive contributor to the problematic situation we're in right now.
People have been beating the drum, as you say, because this day was foreseen more than a decade ago. IPv6 has been in use for far longer than a decade. It was anticipated that we'd be most of the way through the transition by now, but we're not, partially due to "nothing's wrong" attitudes.
Edit: By it in the first sentence, I meant IPv4's time (and was responding to the parent's usage of time running out). I don't mean IPv4 addresses have been exhausted, as I'm quite aware they're not. However, IPv4 has reached the end of its usefulness, is the underlying root of my meaning.
IPv4 addresses are not "out". There are a finite number of IPv4 addresses just as there is a finite amount of land on earth. We are not "out" of land are we? The regional registries haven't even finished allocating the addresses (let alone the low utilization rate of allocated addresses).
If the need of migrating to IPv6 is so great and it so valuable to do so, why the need for artificial pronouncements?
Yes, IPv6 is about 13-years old (from draft RFC approval in 1998). I view this as a more of a failure of IPv6, however.
By my calculations, you'd only need to spin up 50 or so amazon instances, and they could cover the entire IP space in a day doing 1k pings/second each.
These guys have been mapping the IPv4 space via ping over time (since 2003) and have an interactive browsable map that also shows blocks marked for localhost/private networks/multicast, etc and which registrars control which regions. It is pretty neat. Most recent data is Nov 2010. Since then the 11 /8 blocks that show as free have been allocated.
If your application doesn't work behind an IPv4 NAT box, then your application is broke already. It will likely be broke in IPv6 as well since firewalls are not going away (and many of the same protocols that break because of NAT also break with stateful firewalls).
I'm implying a legacy application that only works with IPv4 addresses, and doesn't work well behind a NAT. I know those are two separate issues, but the transition to IPv6 will likely require those software packages to be rewritten anyways so the idea that it will be broken even on IPv6 is moot because it won't even work on IPv6 as it currently is.
So the application is broke with IPv4 and NAT, it is broke with IPv6 as it currently is, and somehow in the future it will be able to be re-written in IPv6 and made to work?
Most of the problems that I encounter with NAT and applications deal with protocols that have a control channel and then spawn separate streams frequently which are UDP. H323 is a perfect example. Both ends and the intermediate NAT devices have to understand how to handle the sub-channels.
This problem won't go away with IPv6 as firewalls will still need to understand the sub-flows. Additionally, we will be living in an IPv4 AND IPv6 world with NAT so not only will you likely have to go through an IPv4 NAT you also probably will have to go through a protocol tunneling device for some large set of users.
Those most likely are not running against the internet as a whole or at random, or they would be screwed already.
VPNs and IPv4 networks that exist today won't disappear...
Why wouldn't they? The IPv4 addresses would either be behind some sort of NAT, or they would be IPv4 addresses in IPv6. If the apps can't handle IPv6, then they can't handle IPv4 addresses in IPv6, and they definitely won't be able to communicate with newer hosts that have IPv6 addresses outside of the range of IPv4.
It is not so easy--large networks will have a lot of redundancy built-in. Consequently, even shutting down a single large BGP autonomous system is not a simple problem and would have a lot of unintended consequences.
Wikileaks is not a good analogy. Wikileaks is more analogous to black-holing one small AS.
As opposed to "reclaiming" addresses i.e. returning addresses to the registries, we should come up with a scheme were institutions can sell their addresses (i.e. IPv4 addresses should become property). This would give institutions that possess very large blocks of addresses a large incentive to effectively utilize their address space.
We could go on for a long-time with IPv4 if the above were to occur.
Yes, they definitely should have used 64-bits instead of 128-bits for the IPv6 address. At 64-bits, you have over 2 billion addresses per person on earth. At 128-bits, the number of addresses, you have is close to incomprehensible.
You don't need the host component of the IPv6 address to be 64-bits in length.
Also, they made the network component unnecessarily long in order to improve summarization. But until you solve the multi-homing problem summarization won't work.