> The Lettre Verte example actually reinforces the point: service got slower, then slower again, not because physics demanded it but because maintaining the previous standard became inconvenient.
Well, it did indeed become inconvenient... for the customers!
Rule no. 0 of economics states that a decreasing demand yields decreasing prices, but rule no. 1 concerns fixed costs: when demand is too low, each customer has to bear a larger share of them.
In marketing their is a distinction between direct response ads (get people to take action) vs brand ads (force people to just watch, no immediate action needed).
Unskippable ads are almost always brand ads focusing on total view time.
It 100% was about optimization. Introducing new devices, with more capabilities (storage place recommendations for example), that weren't 10 years old and broke every 2 weeks is optimizing.
We replaced VHS with DVDs. It took 42 years before we gave up on VHS. DVDs have been around for 29 years but were mostly replaced with BDs before disappearing off the shelves in favor of streaming.
We replaced records with tapes, tapes with more tapes, and more tapes with CDs before they, too, disappeared from the shelves in favor of streaming. Except that some stalwarts have successfully resurrected vinyl.
We replaced AM with FM, and analog radio with digital radio, then streaming. We replaced broadcast analog TV with digital, then cable and satelite, then streaming. Mostly.
None of these changes were backwards compatible, and all of them were meant for the general public. They took a while. They were successful.
Anyone who bought DVD player immediately had the benefits of better quality. The same applies to all other examples.
The problem with IPv6 is that you don't get benefits. If the designed protocol needs an equivalent of big bang, it's doomed. ASCII->UTF8 didn't need big bang. x86 to Itanium needed big bang.
You'd think it would be long enough for people to realize that v6 is backwards compatible! Yet no, here we are, constantly dealing with people making the same damn claim that it isn't every single time a v6 story is posted.
v6 is about as backwards compatible with v4 as it's possible to be. If you have a way to make it more backwards compatible then I'd love to hear it, but when I ask this all I ever get are things that don't work, or things that v6 already does.
It's not that simple at all. For one thing, having a v6 network doesn't mean you can't have a v4 network. You can run v4 in exactly the same way you currently do, with exactly the same software, and it'll work no worse than it already does.
But for another, the v4 space is available as a subset of the v6 space:
$ ping 64:ff9b::8.8.8.8
PING 64:ff9b::8.8.8.8(64:ff9b::808:808) 56 data bytes
64 bytes from 64:ff9b::808:808: icmp_seq=1 ttl=113 time=9.82 ms
That's from a machine on a network with no v4, and it works fine. I can reach v4-only sites from it too. I could even do this using v4 addresses if I wanted, but if I showed you the output from that you'd just claim I was using v4.
The point of backwards compatibility would be to allow IPv4 devices to work on an IPv6 network. Not to run a parallel stack.
127.0.0.1 needed to be a valid IPv6 address, along with all the others. Pick a particular prefix, say 0...* and any address with that would be extended to 128 bits. That would have been backwards compatible.
No, that would be forwards compatibility. v4 doesn't have forwards compatibility with any address protocol that uses addresses bigger than 32 bits, and it never will regardless of how that protocol is designed because the flaw is in v4's design.
There is no possible way to design an address protocol with bigger addresses than v4 that a) makes v4 forward compatible with it, and b) can actually work. Feel free to suggest one.
> .0.0.1 needed to be a valid IPv6 address, along with all the others. Pick a particular prefix, say 0...* and any address with that would be extended to 128 bits
That prefix is ::ffff:0:0/96. 127.0.0.1 is ::ffff:127.0.0.1 (::ffff:7f00:1). 30 years and you still haven't realized v6 has this?
It's often impossible to make backwards-compatible changes to a format which wasn't designed to allow for future changes and which is designed to be as space-efficient as possible.
That doesn't mean that the limits of the old design won't hit anyway and force a switch off it.
v4 supports extension headers and over a thousand bytes of arbitrary payload so if the only thing you needed was a couple of bits in the packet, there was never any issue with finding them.
The problem is that you can't use those bits to expand v4's address space, without taking all of the same steps v6 needed to do. v4 has no mechanism to get v4 hosts to understand extra address bits, wherever you put them.
Oh, that and the fact that IP addresses are stored in many more places than just the v4 packet header. Consider DNS, DHCP, ARP, gethostbyname(), struct sockaddr_in, databases using VARCHAR(15), etc etc etc. The packet header is only a tiny part of the story.
The problem is that IPv4 has no provisions to be forward-compatible with anything with a larger address space. Thus whatever replacement you can think of will have the same problems as IPv6.
If the insects are fed naturally, it would probably be more cost effective to feed the chickens whatever you are feeding the insects. The only reason to introduce the insects would be if you were using something the chicken cannot eat, like wood.
Well, it did indeed become inconvenient... for the customers!
Rule no. 0 of economics states that a decreasing demand yields decreasing prices, but rule no. 1 concerns fixed costs: when demand is too low, each customer has to bear a larger share of them.
reply