I did a Physics undergrad in the UK about 10 years ago, so I can give you one overseas data point.
They made us learn FORTRAN77 (shudder) for one semester, but it honestly wasn't used much in the curriculum beyond that class. I did a bunch of programming outside of that because my senior (third year...same thing) projects were entirely theoretical, but that was entirely self-taught...there was little to no formal system for getting students into serious programming.
For an undergrad curriculum, I'm not sure you really do need programming. For grad work, or for some of the advanced theory, you *definitely* need it.
The question is, are you aiming to teach just the science (which doesn't really need programming to be understood, let's be honest), or are you aiming to prepare students for research/grad school (where they will definitely need it)?
associative arrays...I think you're looking for dictionaries. IronPython has them because regular python has them. testDict = {} testDict['foo'] = "bar"
Same goes with cameras in stores. Most of the time no one is monitoring the cameras and if anything their used to watch employees over customers. But their deterring employees from doing anything unethical or illegal and they deter people from stealing. Really? Ask the folks in London how that's working out for them.
Yeah, and don't expect that even the high-priority data centers are all paying attention. At one of the high-profile data centers where I used to work (didn't tier I used to be what people bragged about?), there was a guy sleeping under the raised floor for a few months before people finally caught on. He had a sleeping bag, food, etc down there....as long as he only went down there after regular business hours, his odds of bumping into someone were pretty low.
As someone who's done a bunch of interviewing of candidates over the past 3 or 4 years, I'll second the "it doesn't really matter" vote.
In fact, I'd go a bit farther and argue that the program that's heavier on theory is a better bet (assuming they do eventually get out of the theory and into practice). The theory will give you the grounding in the field, making learning a new language a matter of syntax & the libs, rather than trying to learn whole paradigms.
ARIN, RIPE, etc, get their addresses allocated to them from IANA. IANA is run under ICANN (ye, gods, too many acronyms). Basically, they manage the IP addresses of the 'net in much the same way that they manage the DNS of the 'net: they're the high-level policy folks, but not the ones you get numbers or names from.
Or because it works. This is something lots of technologists keep missing. It doesn't matter if the tech is old. If it works and serves it's purpose, the argument to replace it has to be really compelling. "It's old" is not a compelling argument.
Nice try. The text you quoted only prohibits "selection of the material" (eg, the web page, email, etc) by Comcast. It says nothing about method by which it's transmitted.
Going only by that provision, if Comcast were selectively blocking certain torrents that would be a problem. Blanket blocking of the torrent protocol overall is totally fine.
I am well aware of this, which is why I said that DHCP was a % chance of helping, but was not an absolute.
Dumping arp/cam tables is something you can't do regularly for busy switches, as the CPUs on Cisco devices are notoriously underpowered, and the arp table request is handled entirely in the CPU. We have had several situations where monitoring systems that dump arp/cam tables pushed switches and routers to 100% CPU for a noticeable period of time.
We still do collect that data periodically, and it also has a % chance of giving us the information we need...but it's also not perfect. For example, a system may come up, do stuff, and go away again in between your table dump...you'd never know they were there if you relied purely on the arp tables. In practice, you need to do both of them. Sucks, but that's life.
One of the things the zeroconf and autoconf folks keep missing is that large organizations (like where I am) need to know which host had a given IP at a given time in the past. We need records and accounting, basically. While DHCP isn't perfect, by any stretch, a fully-autoconf (or zeroconf) network doesn't fill that need, and would be an absolute nightmare for the security folks.
For example, if I get a complaint about a laptop a few days after the event, how am I supposed to find that host once it's moved onto another network? Are people seriously saying I should have to walk every single router neighbor table (or arp table, if we're talking v4) looking for a specific 64-bit number? The network I work on has literally thousands of routers & switches. That's simply a non-starter. With DHCP, I at least have a > 50% chance of finding the MAC of a host (and where it is now) with a simple query.
In short, business needs are driving it. Almost every discussion I've seen of IPv6 for large enterprises (not ISPs) has assumed that DHCPv6 will be used, and that autoconf + zeroconf will not.
What I also find interesting about that answer is his reliance on people joining to work for a "cause." I don't want to belittle that, but relying on people working for a "cause" runs the risk of the team self-selecting to a very narrow mindset. Tunnel-vision can be a huge problem for a discipline that's as ephemeral as computer security. While I'm not saying that heartless mercenaries are the way to go, cynicism is a very valuable trait for security people. True believers, who are there for the cause, rarely make good cynics.
Yeah..."using IPv6" has been re-defined a bit. (disclaimer: I'm a contractor to the feds these days) The end result of the interpretation is that the agencies have to prove they can do it, but they can turn it off after proving that.
Really? Using your own link, there were 12/8 blocks allocated in 2007, leaving IANA with 43 available. Assuming we continue on the present allocation path of 10-12 per year, that puts IANA out of addresses ~ 2011-2012 with no growth in allocation rate. The problem is our allocation rate is increasing, especially in ASIA (responsible for 7 of the 12/8 blocks last year). So, even with the data in your link, IANA will be out of addresses to assign to the RIRs in 2-3 years.
Yes, the RIRs will still have addresses to allocate to end sites when that happens, but the clock will have started ticking...if they need more, they're screwed.
Well...sort of. That OMB mandate requires US gov't agencies to prove that they're IPv6 *capable*. However, once they prove that they can run IPv6 on their core, there's nothing in the mandate that requires them to actually use it. (Unfortunately.)
God damn, I'm tired of fighting this meme. Look, as I mentioned in another response, we allocate 10-12/8's every year, and that rate is increasing. Reclaiming MIT & IBM's/8's would buy us at approximately 2 months at our present allocation rate. The negotiation to make that allocation possible would take far longer. Reclaiming space is not a useful activity at this time.
And you would be wrong. We burn through 2-3/8's every few months. The effort to reclaim the legacy/8's would take longer than the time we'd gain from reclaiming them.
Larger address space
This is the address exhaustion argument.
Stateless address autoconfiguration (SLAAC)
Interesting, but not a selling point for users, and will make administrative management a pain in the ass. Most networks will use DHCPv6 to have records of which host had a given IP address...but they'll still have to run AutoConf to get a default gateway. This kind of split is annoying more than it's helpful.
Multicast
This is really only used on the link level, with one or two site-level things. I don't think this will not be used heavily. Also, if you want multicast, it's already available in IPv4. So this isn't really a gain with IPv6.
Link-local addresses
End users don't care, most sites won't care. In fact, the only people who do care are the authors of EIGRPv6 and OSPFv6 implementation. This isn't really a gain...just a difference.
Jumbograms
The first possibly interesting thing in the list. It won't be used by many places, but DB->App server jumbograms are a common thing in IPv4, and making those bigger & standard is a reasonable gain.
Network-layer security
aka IPSec. Implemented, but key exchange is left as an exercise for the reader. (In other words, it's not happening.) This will be used very, very rarely. This is also something that's already available in IPv4, so not a gain for IPv6.
Mobility
Interesting, and also something definitely new....but not actually implemented anywhere. Not clear if this will fly at all.
No more checksum at the network layer
I'm not sure if anyone really cares.
In short, the single biggest selling point for the vast majority of businesses and users really is the extra size. The other stuff is either already available in IPv4, or only useful for some rare cases. In the majority of cases, the extra IP space is IPv6's only real selling point.
So much misunderstanding crammed into such a small post. I'm impressed.
However, IPv6 has no firewall/NAT support
IPv6 partisans strongly discourage NAT, but there is nothing in IPv6 that will prevent it. Firewalling is still possible in IPv6, and is assumed to continue.
You can't tunnel or VPN
Where in the world did you get that from? There are several tunneling protocols supported as standard in IPv6. 6-in-6, IPSec, GRE...take your pick.
Finally, it doesn't support a person having their own permanent IP range. You are forced to use a subset of the range of whomever you are connecting to, and if you change ISPs or peers, you have to completely re-IP your servers.
This is untrue. ARIN (and most other RIRs) changed their allocation policy a year and a half ago. At present, if you qualify for Provider-Independent space in IPv4, you will also qualify for PI-space in IPv6.
Slashdot Mirror
Probably. But, great tits are still okay.
I did a Physics undergrad in the UK about 10 years ago, so I can give you one overseas data point.
They made us learn FORTRAN77 (shudder) for one semester, but it honestly wasn't used much in the curriculum beyond that class. I did a bunch of programming outside of that because my senior (third year...same thing) projects were entirely theoretical, but that was entirely self-taught...there was little to no formal system for getting students into serious programming.
For an undergrad curriculum, I'm not sure you really do need programming. For grad work, or for some of the advanced theory, you *definitely* need it.
The question is, are you aiming to teach just the science (which doesn't really need programming to be understood, let's be honest), or are you aiming to prepare students for research/grad school (where they will definitely need it)?
associative arrays...I think you're looking for dictionaries. IronPython has them because regular python has them.
testDict = {}
testDict['foo'] = "bar"
Yeah, and don't expect that even the high-priority data centers are all paying attention. At one of the high-profile data centers where I used to work (didn't tier I used to be what people bragged about?), there was a guy sleeping under the raised floor for a few months before people finally caught on. He had a sleeping bag, food, etc down there....as long as he only went down there after regular business hours, his odds of bumping into someone were pretty low.
As someone who's done a bunch of interviewing of candidates over the past 3 or 4 years, I'll second the "it doesn't really matter" vote.
In fact, I'd go a bit farther and argue that the program that's heavier on theory is a better bet (assuming they do eventually get out of the theory and into practice). The theory will give you the grounding in the field, making learning a new language a matter of syntax & the libs, rather than trying to learn whole paradigms.
ARIN, RIPE, etc, get their addresses allocated to them from IANA. IANA is run under ICANN (ye, gods, too many acronyms). Basically, they manage the IP addresses of the 'net in much the same way that they manage the DNS of the 'net: they're the high-level policy folks, but not the ones you get numbers or names from.
Or because it works. This is something lots of technologists keep missing. It doesn't matter if the tech is old. If it works and serves it's purpose, the argument to replace it has to be really compelling. "It's old" is not a compelling argument.
No, you'll get 80's-furry-S&M-food porn. If that's what you want, more power to you. Just don't ask me to visit.
Does anyone here speak jive?
Nice try. The text you quoted only prohibits "selection of the material" (eg, the web page, email, etc) by Comcast. It says nothing about method by which it's transmitted.
Going only by that provision, if Comcast were selectively blocking certain torrents that would be a problem. Blanket blocking of the torrent protocol overall is totally fine.
I am well aware of this, which is why I said that DHCP was a % chance of helping, but was not an absolute.
Dumping arp/cam tables is something you can't do regularly for busy switches, as the CPUs on Cisco devices are notoriously underpowered, and the arp table request is handled entirely in the CPU. We have had several situations where monitoring systems that dump arp/cam tables pushed switches and routers to 100% CPU for a noticeable period of time.
We still do collect that data periodically, and it also has a % chance of giving us the information we need...but it's also not perfect. For example, a system may come up, do stuff, and go away again in between your table dump...you'd never know they were there if you relied purely on the arp tables. In practice, you need to do both of them. Sucks, but that's life.
One of the things the zeroconf and autoconf folks keep missing is that large organizations (like where I am) need to know which host had a given IP at a given time in the past. We need records and accounting, basically. While DHCP isn't perfect, by any stretch, a fully-autoconf (or zeroconf) network doesn't fill that need, and would be an absolute nightmare for the security folks.
For example, if I get a complaint about a laptop a few days after the event, how am I supposed to find that host once it's moved onto another network? Are people seriously saying I should have to walk every single router neighbor table (or arp table, if we're talking v4) looking for a specific 64-bit number? The network I work on has literally thousands of routers & switches. That's simply a non-starter. With DHCP, I at least have a > 50% chance of finding the MAC of a host (and where it is now) with a simple query.
In short, business needs are driving it. Almost every discussion I've seen of IPv6 for large enterprises (not ISPs) has assumed that DHCPv6 will be used, and that autoconf + zeroconf will not.
What I also find interesting about that answer is his reliance on people joining to work for a "cause." I don't want to belittle that, but relying on people working for a "cause" runs the risk of the team self-selecting to a very narrow mindset. Tunnel-vision can be a huge problem for a discipline that's as ephemeral as computer security. While I'm not saying that heartless mercenaries are the way to go, cynicism is a very valuable trait for security people. True believers, who are there for the cause, rarely make good cynics.
It was in the firehose entry...why the editors removed that bit of info is not clear:
http://www.networkworld.com/community/node/25435
Well, since the euro has only existed for 9 years, lowest ever == lowest in 9 years.
Yeah..."using IPv6" has been re-defined a bit. (disclaimer: I'm a contractor to the feds these days) The end result of the interpretation is that the agencies have to prove they can do it, but they can turn it off after proving that.
Really? Using your own link, there were 12 /8 blocks allocated in 2007, leaving IANA with 43 available. Assuming we continue on the present allocation path of 10-12 per year, that puts IANA out of addresses ~ 2011-2012 with no growth in allocation rate. The problem is our allocation rate is increasing, especially in ASIA (responsible for 7 of the 12 /8 blocks last year). So, even with the data in your link, IANA will be out of addresses to assign to the RIRs in 2-3 years.
Yes, the RIRs will still have addresses to allocate to end sites when that happens, but the clock will have started ticking...if they need more, they're screwed.
Well...sort of. That OMB mandate requires US gov't agencies to prove that they're IPv6 *capable*. However, once they prove that they can run IPv6 on their core, there's nothing in the mandate that requires them to actually use it. (Unfortunately.)
I get that info from here which is looking at the actual allocation rates from the RIRs.
God damn, I'm tired of fighting this meme. Look, as I mentioned in another response, we allocate 10-12 /8's every year, and that rate is increasing. Reclaiming MIT & IBM's /8's would buy us at approximately 2 months at our present allocation rate. The negotiation to make that allocation possible would take far longer. Reclaiming space is not a useful activity at this time.
We allocate 10-12 /8's every year, and that rate is increasing. Reclaiming legacy allocations is not going to help.
And you would be wrong. We burn through 2-3 /8's every few months. The effort to reclaim the legacy /8's would take longer than the time we'd gain from reclaiming them.
Yes, lets take a look at those:
Larger address space
This is the address exhaustion argument.
Stateless address autoconfiguration (SLAAC)
Interesting, but not a selling point for users, and will make administrative management a pain in the ass. Most networks will use DHCPv6 to have records of which host had a given IP address...but they'll still have to run AutoConf to get a default gateway. This kind of split is annoying more than it's helpful.
Multicast
This is really only used on the link level, with one or two site-level things. I don't think this will not be used heavily. Also, if you want multicast, it's already available in IPv4. So this isn't really a gain with IPv6.
Link-local addresses
End users don't care, most sites won't care. In fact, the only people who do care are the authors of EIGRPv6 and OSPFv6 implementation. This isn't really a gain...just a difference.
Jumbograms The first possibly interesting thing in the list. It won't be used by many places, but DB->App server jumbograms are a common thing in IPv4, and making those bigger & standard is a reasonable gain.
Network-layer security
aka IPSec. Implemented, but key exchange is left as an exercise for the reader. (In other words, it's not happening.) This will be used very, very rarely. This is also something that's already available in IPv4, so not a gain for IPv6.
Mobility
Interesting, and also something definitely new....but not actually implemented anywhere. Not clear if this will fly at all.
No more checksum at the network layer
I'm not sure if anyone really cares.
In short, the single biggest selling point for the vast majority of businesses and users really is the extra size. The other stuff is either already available in IPv4, or only useful for some rare cases. In the majority of cases, the extra IP space is IPv6's only real selling point.
IPv6 partisans strongly discourage NAT, but there is nothing in IPv6 that will prevent it. Firewalling is still possible in IPv6, and is assumed to continue.
You can't tunnel or VPNWhere in the world did you get that from? There are several tunneling protocols supported as standard in IPv6. 6-in-6, IPSec, GRE...take your pick.
Finally, it doesn't support a person having their own permanent IP range. You are forced to use a subset of the range of whomever you are connecting to, and if you change ISPs or peers, you have to completely re-IP your servers.This is untrue. ARIN (and most other RIRs) changed their allocation policy a year and a half ago. At present, if you qualify for Provider-Independent space in IPv4, you will also qualify for PI-space in IPv6.