There is prior art. There has been talk about using ASN.1 encoding (used by SNMP) for XML documents. Fortunately everyone either ignored it or laughed at it. Note that most tags in ASN.1 encoding probably take up less than a byte, so it is a bit more efficient than you propose. It has the disadvantage that both sender and receiver has to agree on the exact DTD used; without the DTD the data is probably worthless. Contrast that with XML, where the data can usually be extracted even without the DTD if they have not been intentionally obscured. With XML you can also usually get away with adding new tags without breaking old programs. Not so with ASN.1. The only advantage of ASN.1 is that it can be applied as a separate compression/uncompression step, just like bzip. However, there is not all that much compression gained by using ASN.1 instead of bzip.
The neat thing about protocols is that it is reasonably cheap to support several of them. IPv4 will stay around for a long long time. You can still find IPX in places. That does not make IPv4 a failure.
The fact that Microsoft is sitting on a lot of cash does not mean that amount of cash is taken out of the economy. I really doubt that Microsoft has a vault full of cash somewhere, and even if they did, taking such an amount of money out of the economy would cause a revaluation of the US dollar and make it possible for the central bank to print more money, thereby making people richer on average in the US.
The glass beads we trade to the natives are getting ever more shiny.
The architecture would be that of a GPU (highly parallel and pipelines with slow individual steps) rather than that of a CPU. Your advantages likely won't appear though: GPUs expose a lot of their parallelism to software, and I doubt hardware can do that better. I bet graphics memory will continue to be separate from main memory, unless a cheap very fast memory technology comes along.
Once generic math moves to the GPU, the main CPU really does not need all that much power. It can just be a small bit with maybe 100 or 200 million transistors, stuck in the corner somewhere, and the GPU can get all the real power of perhaps a billion transistors.
It does not really matter that you cannot upgrade the CPU separately. Today you do not complain that the FPU cannot be upgraded separately from the CPU. Assuming that it was possible, a 5 times faster FPU would leave the important applications (that is, games) CPU starved, and a 5 times faster CPU would leave them starved on the FPU. So you need to upgrade both at once. I bet graphics will be like that. Classical FPUs are doomed though, anything they can do, a GPU can do better (except right now GPU makers don't include double precision, but that will chance.)
I haven't had to kill Epiphany in a long time, but with Fedora, the desktop keeps track of whether the application reacts to a close window request. If nothing happens, a prompt will appear, asking whether to kill the application. It works very nicely.
Since the population who would be most interested in this product are those with substantial long distance bills, this isn't a very safe bet.
Fortunately there are a lot of suckers like me who love flat rates but never use the service all that much. It is just a good feeling to use something and know it does not cost you anything extra.
People have been starting to see Microsoft as a vendor of poorly-written, insecure software. What this offer makes people see is that Microsoft is just the victim of evil criminals. And you can never blame the victim for the crime...
Ice is less dense than water. So, an ice cube melting in a glass of water will cause the level of water to rise. If you don't believe me then try it.
You really should try out your experiments before spouting off about the results. The only way a melting ice cube would make the water level rise is if it was stuck to the glass. Luckily the arctic ice is floating. Unfortunately, the antarctic ice is stuck to the bottom, so when that melts, sea levels will rise.
With IPv6 it will be very very very hard for a worm to find even one machine to spread to. On average it will have to scan at least 2^32 IP addresses, assuming that the average IPv6 network has 65000 hosts on it (10 is probably more likely) and that the worm knows enough to only scan networks that have hosts on them at all. That's like scanning the whole IPv4 Internet from a single machine -- not likely. So IPv6 should help a lot.
Your IPv6 address cannot follow you. Instead IPv6 offers quick renumbering features and there is a lot of work on mobility and multihoming. I bet that in 10 years you will be used to the IP addresses of the gadgets you carry will be able to change every five minutes (or even faster) if you are moving, and your applications will never notice it.
If you like to keep your MAC there, you can use that. It has a lot of advantages. But if you don't like it, you don't have to use it. It's a free world. You can number your machines in a Fibonacci sequence if you prefer.
Or they could just keep selling IPs at premium and make even MORE money.
Sure they could. But since my provider was foolish enough to give me one single IPv4 IP, I automatically have 2^80 IPv6 IPs. I probably won't run out soon. And if they had given me a fake address (IPv4 NAT), I could use Teredo to get the same amount. If ISPs one day decide that giving out single IPv6 addresses to customers is a winning prospect, they will have to deal with the whole tunnelling infrastructure that has sprung up around IPv6. I would gladly give out some of my IPv6 addresses to other nearby users, perhaps in blocks of 2^64. That would let me supply 65000 people with a decently large allocation each. (Of course I'd run out of bandwidth if I did that, but lots who are better connected would do it too.)
With IPv6 the addresses will be competed so far down in price that there is no point in charging for them.
I have no idea why you think going IPv6 is expensive. Going dual-stack is trivial (I know because I did it, and it really was trivial). Then in 20 or 40 years when everyone else has switched and all applications upgraded, you can turn off the IPv4 stack.
You rarely read a book with page after page detailing how the main character fetches wood in the forest. That is the kind of thing the character should do when the player is not online.
You may just as well just give it to your solicitor instead of mailing it. The date stamp proves nothing - you might have sent an empty open letter, then put the CD or print in afterwards.
There are certainly cases where many cards have managed to get the same MAC address. In all the cases I have heard of, reputable vendors treated that as a bug. The only exception is Sun, which (used to?) assign a single hardware address to a machine by default, no matter how many interfaces. The theory was that each interface would connect to a different network. Easy to switch off in the PROM, luckily.
There are also stories about companies making clones of the cards from vendors like 3com, but giving all of them the same MAC. I have never to my knowledge seen such a card. Anyway, if you get two cards with the same MAC address onto the same network, things will break -- IPv6 or not.
If food production was a million times greater than consumption, it would be hard to imagine that someone could still be starving.
When there is a shortage of something in a free market system, the price rices. The price for IP addresses is now high enough that I cannot afford them. With IPv6 the price is low enough that I already have 2^80 addresses. The scarcity of IPv4 addresses is artificial insofar as it is not based on a natural limitation in routers or hosts. It is simply the result of a choice made long ago which has turned out to be bad.
With music, the artificial scarcity is created by legal barriers.
Header checksums need to be recalculated if options are changed. This is a slow operation for hardware routers. It's not like anything can be done about a checksum failure anyway, you just have to throw the packet away. The faulty packet would most likely have been thrown away anyway, without the checksum.
Ease of routing is the reason. With 64 bits you have to be careful how many IPs you give to each ISP. If you give too few you have to renumber or add disjoint addresses, polluting the routing table. If you give too many, you could still run out. You would also give just a few addresses to end users, say 256. That makes it impossible to do proper routing at the customer end, and addresses still have to be carefully assigned by hand or by DHCP. With 128 bits you can afford to embed the MAC address in the IP address, guaranteeing that it is unique. Goodbye to (stateful) DHCP.
That is just one suggested way of assigning addresses. It is very popular though. Anyway, if an ISP does not give you enough address, you just tunnel somewhere that does. Lots of providers of tunnels already. If all else fails, I am sure you can find a friend that is close to you latency-wise who is willing to let you have 2^64 addresses out of the 2^80 he has...
Slashdot Mirror
There is prior art. There has been talk about using ASN.1 encoding (used by SNMP) for XML documents. Fortunately everyone either ignored it or laughed at it. Note that most tags in ASN.1 encoding probably take up less than a byte, so it is a bit more efficient than you propose. It has the disadvantage that both sender and receiver has to agree on the exact DTD used; without the DTD the data is probably worthless. Contrast that with XML, where the data can usually be extracted even without the DTD if they have not been intentionally obscured. With XML you can also usually get away with adding new tags without breaking old programs. Not so with ASN.1. The only advantage of ASN.1 is that it can be applied as a separate compression/uncompression step, just like bzip. However, there is not all that much compression gained by using ASN.1 instead of bzip.
The old SGI logo stands for the hope that SGI will one day returns to both its old coolness and its real logo.
The neat thing about protocols is that it is reasonably cheap to support several of them. IPv4 will stay around for a long long time. You can still find IPX in places. That does not make IPv4 a failure.
The glass beads we trade to the natives are getting ever more shiny.
The architecture would be that of a GPU (highly parallel and pipelines with slow individual steps) rather than that of a CPU. Your advantages likely won't appear though: GPUs expose a lot of their parallelism to software, and I doubt hardware can do that better. I bet graphics memory will continue to be separate from main memory, unless a cheap very fast memory technology comes along.
It does not really matter that you cannot upgrade the CPU separately. Today you do not complain that the FPU cannot be upgraded separately from the CPU. Assuming that it was possible, a 5 times faster FPU would leave the important applications (that is, games) CPU starved, and a 5 times faster CPU would leave them starved on the FPU. So you need to upgrade both at once. I bet graphics will be like that. Classical FPUs are doomed though, anything they can do, a GPU can do better (except right now GPU makers don't include double precision, but that will chance.)
I haven't had to kill Epiphany in a long time, but with Fedora, the desktop keeps track of whether the application reacts to a close window request. If nothing happens, a prompt will appear, asking whether to kill the application. It works very nicely.
Fortunately there are a lot of suckers like me who love flat rates but never use the service all that much. It is just a good feeling to use something and know it does not cost you anything extra.
People have been starting to see Microsoft as a vendor of poorly-written, insecure software. What this offer makes people see is that Microsoft is just the victim of evil criminals. And you can never blame the victim for the crime...
You really should try out your experiments before spouting off about the results. The only way a melting ice cube would make the water level rise is if it was stuck to the glass. Luckily the arctic ice is floating. Unfortunately, the antarctic ice is stuck to the bottom, so when that melts, sea levels will rise.
With IPv6 it will be very very very hard for a worm to find even one machine to spread to. On average it will have to scan at least 2^32 IP addresses, assuming that the average IPv6 network has 65000 hosts on it (10 is probably more likely) and that the worm knows enough to only scan networks that have hosts on them at all. That's like scanning the whole IPv4 Internet from a single machine -- not likely. So IPv6 should help a lot.
Your IPv6 address cannot follow you. Instead IPv6 offers quick renumbering features and there is a lot of work on mobility and multihoming. I bet that in 10 years you will be used to the IP addresses of the gadgets you carry will be able to change every five minutes (or even faster) if you are moving, and your applications will never notice it.
If you like to keep your MAC there, you can use that. It has a lot of advantages. But if you don't like it, you don't have to use it. It's a free world. You can number your machines in a Fibonacci sequence if you prefer.
Sure they could. But since my provider was foolish enough to give me one single IPv4 IP, I automatically have 2^80 IPv6 IPs. I probably won't run out soon. And if they had given me a fake address (IPv4 NAT), I could use Teredo to get the same amount. If ISPs one day decide that giving out single IPv6 addresses to customers is a winning prospect, they will have to deal with the whole tunnelling infrastructure that has sprung up around IPv6. I would gladly give out some of my IPv6 addresses to other nearby users, perhaps in blocks of 2^64. That would let me supply 65000 people with a decently large allocation each. (Of course I'd run out of bandwidth if I did that, but lots who are better connected would do it too.)
With IPv6 the addresses will be competed so far down in price that there is no point in charging for them.
I have no idea why you think going IPv6 is expensive. Going dual-stack is trivial (I know because I did it, and it really was trivial). Then in 20 or 40 years when everyone else has switched and all applications upgraded, you can turn off the IPv4 stack.
You rarely read a book with page after page detailing how the main character fetches wood in the forest. That is the kind of thing the character should do when the player is not online.
You may just as well just give it to your solicitor instead of mailing it. The date stamp proves nothing - you might have sent an empty open letter, then put the CD or print in afterwards.
There are also stories about companies making clones of the cards from vendors like 3com, but giving all of them the same MAC. I have never to my knowledge seen such a card. Anyway, if you get two cards with the same MAC address onto the same network, things will break -- IPv6 or not.
When there is a shortage of something in a free market system, the price rices. The price for IP addresses is now high enough that I cannot afford them. With IPv6 the price is low enough that I already have 2^80 addresses. The scarcity of IPv4 addresses is artificial insofar as it is not based on a natural limitation in routers or hosts. It is simply the result of a choice made long ago which has turned out to be bad.
With music, the artificial scarcity is created by legal barriers.
I don't want to go through a gateway. I want VoIP to the phone. And as you say, NAT and SIP don't play nice together. The solution is IPv6.
Header checksums need to be recalculated if options are changed. This is a slow operation for hardware routers. It's not like anything can be done about a checksum failure anyway, you just have to throw the packet away. The faulty packet would most likely have been thrown away anyway, without the checksum.
Ease of routing is the reason. With 64 bits you have to be careful how many IPs you give to each ISP. If you give too few you have to renumber or add disjoint addresses, polluting the routing table. If you give too many, you could still run out. You would also give just a few addresses to end users, say 256. That makes it impossible to do proper routing at the customer end, and addresses still have to be carefully assigned by hand or by DHCP. With 128 bits you can afford to embed the MAC address in the IP address, guaranteeing that it is unique. Goodbye to (stateful) DHCP.
I want it. And I will get it, assuming legislation does not get in the way. It is already almost there, with a VoIP-capable PDA and a GPRS phone.
That is just one suggested way of assigning addresses. It is very popular though. Anyway, if an ISP does not give you enough address, you just tunnel somewhere that does. Lots of providers of tunnels already. If all else fails, I am sure you can find a friend that is close to you latency-wise who is willing to let you have 2^64 addresses out of the 2^80 he has...
2002:c329:1d04:4:202:2dff:fe61:791f