Any derived work of something, like git, which is GPLed, must be GPLed. That means that if you fork, the main branch, the main branch is free to use your extensions. This makes it difficult for replacement to work.

I think that neither the on-disk nor wire protocols of git have special copyright protection. If it so chose, Microsoft could develop a fully closed-source git implementation from scratch that is "fully compatible" with, say, git1.8 but has proprietary Windows extensions.

Afaict git has no good system for answering these questions. Reflog can give you this information but afaict it can only be used if you have direct shell access to the main repository and only if the relavent entries haven't been expired from the reflog.

Set up a central, "authoritative" git server for a project that rejects all non-fastforward pushes, and you have exactly the same guarantees. In the meantime, local developers who don't need monotonic history can use the full features of git, and the restrictions can also be relaxed if necessary. For example, a dedicated (trusted) project maintainer could be permitted to make non-ff merges, so development-branch history can still be retained in the central repository.

Subversion doesn't break these guarantees, but that's because it's not powerful enough to do so.

Oh, the dictionary argument: since the dictionary contains all English words, no composition using strictly dictionary words should be copyrightable. Eh, eh? *wink wink*

It's bull.

When you have "the text of all national security documents" et cetera inside pi, it's all useless unless you have a key to actually specify and find the information you're looking for. By uniquely specifying a position and length within the digits of pi, you've just defined an encoding.

You're precisely one step beyond "it can't be a movie, it's just a string of ones and zeroes!" It's juvenile and unoriginal.

Speaking seriously, it's unlikely that the math here involves the same kind of statutory damages that arise from copyright violations in the US. Statutory damages are the result of the $500/share/song fees, and those are allowed specifically by law as a penalty. Since this set of copyright-suspensions is fully legal, US law would doubly-not-apply on the matter. At best, this might be calculated based on retail price.

... in what fantasy world would this have worked? Upgrading the IP version number by itself is an incompatible change, and any address-space extension means that a stateless, 1:1 address mapping is impossible. Once a stateless mapping is impossible, we're right back to the current mess of transition, since new-IP hosts would not be able to talk to old-IP hosts without an intermediary.

Carrier Grade NAT refers to an implementation of NAT444. What distinguishes this implementation is that the customer is given an IP address (or several) from within a private or shared range managed by the ISP, which is itself address-translated to a small pool of public addresses.

Hence, a customer's home network (IPv4) is translated to a provider's private network (IPv4) and again to the public Internet at large (on IPv4): NAT444.

Algorithmically it's the same network address translation you do at home, but if you were to stack two NAT-routers on top of each other to build a double-NAT at home you'd be a damn fool. When the provider does it, it gets a fancy name.

And even worse, there's no way for either end to tell - unlike IPv4 where if your local IP is in the reserved range, you can pretty much assume NAT, with IPv6, you can get a route check and get a valid IP for the 'net (the machine will also have a link-local and maybe a reserved address as well, hence doing a route-check and figuring out which IP you will be using), and not realize that you still can't communicate.

If, if business or network requirements mandate the use of NAT66 for reasons that can't be worked-around with other, more sensible approaches, then local hosts should exclusively use addresses from the Unique Local Address space. It's like private IPv4 addresses, only with near-zero chance of collision if different domains interact (like VPNs, organization mergers, or leaking of private addresses onto public spaces). A host with (seeming) internet connectivity that has an address in a ULA range must obviously be behind address translation.

Besides, what really breaks devices isn't NAT so much as many-to-one NAT. If (again, for some bizarre reason) an organization chooses to implement NAT66, then they should be using many-to-many NAT, where each internal host still maps to a unique -- but not predictable -- public address. If the public address is rotated every few minutes/hours for new connections (like already happens with stateless autoconfiguration + privacy extensions), then it will be impossible for an attacker to track hosts over the long-term.

I never really understood why we didn't just map all the IPv4 addresses to a IPv6 subset and provide a very simple rule to translate, say by adding all zeros or some other number to the IPv4 address to get its IPv6 one.

We can do that; for legacy reasons IPv4 addresses can be embedded perfectly in the IPv6 space. However, there's no way to do so and ensure compatibility, because an IPv4-only application will simply be unable to handle IPv6 addresses. For IPv4-only applications (on either endpoint) to work on an IPv6 connection, some device in between has to translate the network addresses, or some anagram thereof.

From the perspective of the IPv6-end of things, this is a solvable problem. NAT64 effectively allows a router to proxy the entire IPv4-space, allowing a 6-only host to more-or-less transparently deal with IPv4-only hosts. DNS64 also proxies the DNS records to construct suitable (NAT64-based) addresses for hosts with only A (IPv4) DNS records.

The problem of IPv6 adoption is a classic chicken-and-egg. The differing address lengths mean that compatibility for IPv4-hosts must be broken; the pigenhole principle means that there literally cannot be a stateless mapping between IPv4 addresses and IPv6 addresses, even ignoring the traditional NAT problems of addresses-in-protocols. Some kind of translation intermediate will be necessary until we can finally turn off the IPv4 lights.

Those numbers are a bit out of date. The current Wikipedia page has an updated bar graph; in the most recent quarter listed (Jul-Sept 2012), the iPhone sold 26.9 million units.

If we're to assume that Nokia's goal is to sell a dominant phone platform, rather than a very niche product, these reported sales figures are underwhelming.

ISPs don't want to do carrier-grade NAT, because then they have to maintain carrier-grade NAT.

CGN is a stateful protocol, meaning that each of their implementing-boxes needs to maintain and process state for each data flow to or from your devices. That's no big deal for a single home, but it's a problem for a carrier. If the boxes are too far towards the customer-end of their network, they will be small but they will also be numerous, making maintenance more frequent. If the boxes are too far towards the core of their network, an ISP will only need a few, but the hardware requirements are much heftier to provide acceptable performance. (Already, bittorrent can saturate some of the cheaper home routers).

Simply routing packets is technically far, far easier than running network address translation. Even ISPs that use deep-packet inspection have the option of turning it off if things go wrong -- the network fails open. Carrier grade NAT doesn't have that option.

It's probably the index of your machine's IP that received the echo reply. An IPv6-connected host will have many addresses of different scope, so some implementations use the "%" to distinguish which of your addresses has handled a connection.

If DNS/DHCP is so difficult, then you can do exactly the same address assignment with ipv6 that you do with ipv4: give out a static /64 to each group-of-VMs, and let the testers/devs themselves pick individual machine numbers from that prefix.

If you want to be really short, then generate an unique local prefix (/48) for your test networks, and subdivide from there according to whatever scheme you want, like fd8a:db80:db80:building:floor::[machine]

That won't work in the long-term. The problem with carrier-grade NAT is that the ISPs have to... maintain carrier-grade NAT.

Network Address Translation is a stateful protocol, and it's orders of magnitude more expensive to maintain connection tracking on a per-connection basis for your customers than it is to simply route packets between networks. Even ISPs that use Deep Packet Inspection have the luxury of looking at selected traffic flows; carrier-grade NAT has to cover everything or it doesn't work.

Not even then. I've accidentally killed computing nodes before by overloading system memory with job submission. Technically the system doesn't die, but swap-storms made it so unresponsive that the sysop had to get to the physical console to reboot.

I'm not sure what it is about the US that makes it impossible to have more than 2 parties, but first past the post isn't it.

For the presidency, the US has a double first-past-the-post system for a single seat. Electing a minor party requires winning a majority of a pluralities: a plurality in enough states to get an electoral college majority. That's a very tough task, somewhat harder than trying to elect a Green party candidate nationwide if all Canadians voted for a single "Prime Minister Seat."

Parliamentary systems like Canada also do more to encourage minority parties at the per-seat level, for a few reasons:

• In a minority government, like Canada has seen for much of the last decade, minority parties like the NDP and BQ really do have legitimate power to shape the national agenda.
• In a majority government, nobody expects the opposition parties -- any of them -- to have much if any influence on the agenda, so to first order it doesn't matter what party you vote for provided it's not for the nationwide winner. Strategic voting does affect this, but it also cuts both ways if a minority party puts out a strong, local showing.
• Party discipline is also much stronger in Canada than the United States, so the parties occupy correspondingly smaller ideological grounds. In the States, a Republican in New York City is not necessarily the same as a Republican in Alabama, and a southern Democrat will still tend to be more conservative than a Northern counterpart -- and this really does influence legislation, to both good and ill. The upshot is that third parties are less likely to get a consistent regional base in the States, since the local duopoloy will incorporate the regional idiosyncrasy.