So, a motherboard with no RAM and no CPU, in the $100 range, I can see. But with Thunderbolt, too? I know the Thunderbolt cables are a bit pricey because of the chips built into those, but are the Thunderbolt controller chips *that* much cheaper than the cable chips?

I must admit, the first thought that came to my mind when reading this is, this sounds like a great setting for some spy thriller or such. I mean, an abandoned military base with launch silos, its own nuclear power, and slowly being destroyed by encroaching ice?

The perfect location to have the mastermind's base located in. At the end, the heroes have to race out of the base as it is finally being destroyed by the ice.

Just where exactly are these 'test servers' in relation to you? What, exactly, was this 'test'? This seems a bit of a worthless test. It's entirely possible your DSL has less than 100 ms latency, but the delay is on the server end or the links in between. This is too vague a scenario to comment on.

My feelings about 'acceptable' latency depend on how much I am paying for it, at what bandwidth, with what level of SLA, and for what purpose.

In some ways, a lot of what is being added to C++ makes me think of Scala, just less readable.

While the additions and extensions certainly make things more interesting and potentially more powerful/easier for the *individual* programmer, I look forward to seeing what sort of interesting train wrecks happen when larger teams try to make use of these features. I certainly hope the debuggers are being updated to be useful when someone's written a template that uses a #define'd macro to specify a closure that is passed through an anonymous function, etc.

This strikes me as the next generation's 'multi-threading' -- where almost every programmer claims they can handle multi-threaded programming, but very few actually do it well. Particularly in teams when interactions require coordination. Going to take a whole new round of winnowing the wheat from the chaff when it comes to finding developers who can actually use these features well without driving their coworkers insane.

Live with the tedium of doing in manually. It sucks, but unless you are going to have to do this exact operation again in the future, don't bother with automating it. Possibly the solution of taking out the hard drive, putting in a drive dock on another computer, and letting that computer back-up and wipe the drive might be slightly less tedious, depending on the situation.

Because, if you listen to what you are asking, you are trying to set up an automated back-up and erase system. Unless you have a Lot Of Time to Test this BEFORE HAND, you could easily end up with an automated screw-up-the-back-up and nuke-everything system. If you successfully manage to create a system that erases several hundred computers without making usable back-ups, that might be a career-limiting move.

You are asking for replacing a single-shot pistol with a high-powered Gatling gun -- this is not unreasonable. However, if you shoot yourself in the foot with such a thing because you are not careful, there will not be a lot of remains left over.

If all the computers are absolutely identical, you might be able to do an automated system, test it against a couple machines, and be able to get it to work. Otherwise, the amount of time you will spend making sure that the automated system does exactly what you need it to do, safely, without ever failing, may end up being as much time as it takes to do it manually.

Oh, you are verifying that your back-ups are usable before nuking the drives, right?

Sorry, I already explained how it would be possible to take things like SRV records and deal hostname resolution through NAT. It's certainly possible to do. Now you are dismissing DNS as not usable. I'm not sure if there's going to be fruitful discussion.

Wow. You are very IP address-centric. Have you ever considered that there are other network types out there?

Try this:
Alice wants to talk to Bob. She puts a universal identifier for Bob (say, 'bob@bob.com') in. Her local system contacts the local network (which runs protocol A) directory service resolution for "bob@bob.com". It's not a locally known identifier, so the local directory checks its peer system for knowledge of that identifier. (Like route discovery for a block of IP addresses, even.) The AB gateway from network A to network B thinks it handles "bob.com" and checks its internal network (which runs protocol B) for "bob@bob.com", and finds it at The AB gateway sets up a translation so that on the A network is mapped to the B network to (with a reverse mapping). The AB gateway returns to Alice's machine, and says use this.

Now, Alice tells Bob to talk to "Charlie@charlie.com". Bob's network, running protocol B, does a directory look up on that, and decides it's not local. It contacts it's various gateways/peers, and the gateway BC thinks it can handle it. It sets up the translation between BC just like the translation for Alice to Bob was done between A and B.

Maybe network A is running IPv4, maybe not. Maybe network B is running IPv6, maybe not. Maybe network C is running IPX. Doesn't matter because the applications don't concern themselves with it.

You almost have it! Except the 'highest level necessary'. It should be as low as possible.

Yes -- that is correct. Which should be independent of IPv4, IPv6, or IPvWhatever. The unified addressing system CANNOT be IP addresses, because you can't hand an IPv6 address to an IPv4 system.

See the above system. Identifiers are resolved within the local network to locally understood protocols.

Here's how I look at the situation. IPv4 was a 32-bit box. It started getting crowded, so people started carving crude doorways in the side of the box to join other boxes (i.e. private network address spaces) to the main box with things like NAT. This was a bit of a hack and wasn't always perfect, and the box was still getting crowded.

However, people decided the solution was to make one reallllly big box, the 128 bit box, and trap everyone inside it. There was enough space for everyone in the monocultural entity that was the One Big Box, and that that way no one would have to ever make doors again. A lot of people think that the One Big Box is so good, we will never need another, because it's just so big. And it's easier to monitor/manage/control.

My feelings it that instead of making One Big Box, the door thing should have been developed more, so people could have kept adding their own boxes. Or cylinders. Or dodecahedrons, and the doors should have let people wander from one to the other as they wanted without hindering them, so that people could choose what worked best for them instead of being stuck in the One Big Box all the time. It also provides escape routes and competition to the One Big Box should problems happen with the Titanic v6.

So, because I like the ideas of doorways and freedom, I find people who keep insisting that doorways and gateways and translations are bad or unnecessary because we should all be Happy in the One Big Box to be tiresome.

If ultimately, that's all you want is the One Big Box, then that's fine.

You can't add it back in if it's just going to break all the applications that continue to depend on knowing more about the network than they need to.

No, *something* is needed so that the other application knows where to send the data to. That identifier does not and should not be a network specific implementation in my opinion.

The point is when we switch *from* IPv6.

Let's say this guy call FireFury03 is struck with a brilliant idea and comes up with a new version of IP, IPvFF, that is simply *awesome*. It fixes stuff people never thought about, it ends world hunger, it solves privacy issues, etc. It's simply an amazing step forward!

Except, it's not IPv6 compatible.

Now what?

The point of supporting/having NAT is to allow the network to be modular/segmented, so you aren't stuck waiting for a the last few people on the other side of the world to upgrade to the latest protocol, or having to wait for them to upgrade every one of their applications which depends on having 'IP addresses'. It's so people can run what they want on their networks and still use applications that work across heterogeneous networks. It's so people can experiment with IPv6.1.5 in their LANs and still communicate across the network.

It's so people needing really tight performance could use something with a smaller address space for their LAN to minimize wasted bytes, but still get out when they needed to. It's so we there doesn't have to be a single mono-culture network that can be hamstrung by things like the IANA, ICANN, etc.

Part of the value of the digital age has been that data can be translated from one format to another -- speech to text, text to speech, images to bytes, etc. Searched, edited, copied, etc. Nearly every activity of value involves the ability to transform or migrate data -- and things like DRM which prevent that are a nuisance that degrade value. I want to see the ability to translate between protocols supported because I think the ability to adapt old data/protocols to new forms is very useful and important.

Sorry, I disagree. It is only not needed if we assume that IPv6 is the end of the road for protocol design. If there is every anything after it, then having the migration mechanisms already in place and supported will speed the transition. -- and speeding of the transition should be encouraged, so we can then work on the next generation after that, and the next generation after that. Migration mechanism are always 'not needed'... until you suddenly need them.

Counter-argument: That is essentially "Since I don't need X now, I will design so I will never be able to use X in the future." That's a *big* assumption. I disagree with this. You may believe it, but I do not.

The disagreement is whether or not the recipient needs to know *IP* addressing information. Sending application level data across the network 'encapsulates' the data in an IP packet. IP packets are NOT the application. You may disagree. You may think that IP is, in itself, an application. I do not. I view it as transport, just like any other lower layer in the network.

If you feel that the structure and information of an IP datagram is inherently part of the application data, then the IP network design is a lock-in design because the applications are being written to use IP network information. I feel that applications should be separate from the network. You may disagree.

Do not get me started on SIP. I've worked with SIP since 1999. It's really bad.

Please note -- if you are serious about VoIP and SIP, IPv6 sucks. The larger header size per packet can really hurt RTP stream bandwith, because it can make a noticeable (10%+) size increase per RTP packet for voice.

Actually, people could, but they don't. What it would require would be to take something like SRV records. A server behind NAT would have to inform the NAT device that it is offering service X on port Y for domain Z. The NAT server would have to server up a NAT rule for an outside port A to map to the inside server on port Y. Then it handles DNS requests for domain Z and returns SRV records (or similiar) saying that if you want to reach service X for domain Z, connect to the NAT server on port Y.

This isn't an impossible problem.

Lets be clear on this: application data should *not* break if it's encapsulated in IPv4, and then unecapsulated, then re-encapsulated in IPv6. The application data should be separate from IP information just as it is separate from other encapsulation.

Anything else is network lock-in. You may disagree.

The ability to write directly to the memory of a data structure may be considered advantageous in some situations. Yet, a lot of people prefer object-orientated programming or styles with getters and setters which can manage this access. You may disagree.

See above. It is perfectly possible to do translation set-up and tear down to access machines behind NAT. Switched networks have to do the same all the time.

The initial move is to stop demonizing NAT.

I mean, seriously. We have networking traffic that moves from optical to wired to wireless, across all sorts of protocols and encapsulations, constantly. No one freaks out, no one complains. Suddenly, if the specter is raised of changing the sacred IP Address, everyone freaks out. NAT only impinges the functionality of software because the software and protocols are badly designed -- i.e. they insist on using IP information inside application level protocols instead of application-level identifiers (i.e. hostnames rather than IP addresses.) If applications had been properly separated from the network information to start with, then the migration from IPv4 to IPv6 would have been even smoother because the applications and protocols would never have had to be re-written.

If the applications never deal with IP addresses and instead have the operating system/network API handle the details, then the applications become independent of the network protocol, just like applications (generally) do not have to care about the difference between wired and wireless ethernet. At that point, it is possible to implement protocol to protocol conversions and translations at the network level that does not impact the applications or their functionality.

If applications do not break or fail to work because my traffic switches from wireless to wired to optical data transport, or because the encapsulation changes (ethernet frames vs. ppp vs. ATM vs. frame relay), then they should also not break because the network protocol changes (i.e. IPv4 to IPv6 and back again.) People blame NAT for the problems, but it is not that NAT *breaks* the applications, it is that the applications were *already broken* in design, and NAT just reveals the flaws.

I am not enthusiastic about how the response to the flaws of badly written applications has been to make a huge address space instead of fixing the design of the application and protocols. That's kind of like saying the answer to a memory leak is to add a petabyte of RAM to a computer.

If we worked on fixing the applications and protocol stack instead (i.e. pushing IP handling completely into the OS layer and keeping it out of the applications), then applications would not have to care about dual stack, triple stack, NAT, etc. at all. This means that it would become much easier to migrate to new network technologies without disrupting the applications. This would also allow people to run specialized or experimental networking protocols on their own networks for their own purposes while still using the same applications.

If applications and protocols continue to be developed where they expect "IPv4 or IPv6 formatted address only", then that locks them in. They have to be rewritten whenever something changes at the network layer (i.e. NAT, new versions of IP, etc.) If the applications stayed out of the network layer, then only the operating system would have to be updated to support new networking technologies, which is easier than updating every application everywhere.

Sigh. It's not about more addresses. It's about better protocols. There's a difference.

So, you are correct. You do suffer from a lack of imagination.