Imagine office integration where you can easily share documents, send messages, and video conference among LinkedIn contacts.
What a horrible thought. I can't see anybody being comfortable with exposing their internal business processes to M$ spying. Granted, M$ always has big thoughts. Linkedin users have one simple thought: what are the alternatives?
A fragile, expensive, complicated, inefficient vehicle that won't fly or drive very well, that few people can actually operate safely and that nobody actually needs?
They also need a new power source... because the current real problem with flying cars is the energy problem...
There are many problems, among them: extra weight needed for street legal operation; conflict between aerodynamic configuration and road vehicle form factor including need to fit into a standard parking space; payload constraints; weight and balance (forget the back seat); safety (what is the glide angle if any if the engine stops); noise control; limited market; regulation. Even Mr fusion won't solve all the problems.
It is abundantly clear that the vtol light private plane problem needs to be solved first, before imposing additional constraints to make it roadworthy.
Grossly energy inefficient, noisier and considerably more dangerous, rather like a helicopter. The notion of making such a vehicle street legal is, in a word, absurd. If you can afford such a toy then you can afford to have someone meet you at the landing pad with a real car.
Yeah? It's not fundamentally any different to a v4 header. It's got a new protocol number and more of it is dedicated to storing addresses. Yes, it's 2x the size, but that's because the src+dst addresses are already 32 bytes to v4's 20 bytes total.
Presumably you were suggesting to do the same thing, because there's no way to fit a pair of 128-bit addresses into the v4 header without making it bigger.
(Ab)using the version field (not the protocol field!) is not the only way to extend IPv4, probably not even a good way, however that is a red herring. The point is, there is no such thing as an IPv6 packet that looks like IPv4, even when the source and destination addresses permit it. That is the big gaping flaw of IPv6 that lead to the adoption fiasco.
Nothing wrong with the technique, but there's something wrong with IPv6, namely not the slightest attempt to retain backward compatibility with IPv4 at the protocol level.
Well, there's that version number in the header, which allows the two to coexist.
Not only as separate protocols, but separate infrastructures. IPv6 has its own home rolled approach to multicast for example, which nobody uses as opposed to IPv4 multicast which is heavily used (and will not be going away any time soon because it runs the world's financial systems). IPv6 has its own NIH address syntax. Everything that could possibly be made different about IPv6 was made different. Second system syndrome in its most ugly form.
But more to the point: how is your v4x any different to this? You're suggesting doing exactly the same things v6 did.
(Note that I'm not shouting you down here; I'm pointing out that you're proposing essentially the thing that we already did.)
I'm not making a proposal. I am saying that the time is right to make a proposal. I didn't know that there's actually a proposal on the table, here. I will be taking some time to study it, I suggest you do too. It seems I'm far from the only person who thinks that IPv6 is still a disaster and there is room to attack the problem from another direction.
Since you consider yourself an expert, would you care to explain why you think that IPv6 is especially routable? (Hint: don't bother parroting the lame handwaving from wikipedia)
Second thing is, have you seen any IPv4 successor proposals? Link please.
Funnily enough, what you've described there is basically IPv6.
In some wildly theoretical sense, it is something like IPv6, but then it isn't at all. Do you even know what an IPv6 header looks like?
If you think that NAT is the way to go about connecting to legacy v4-only hosts, then what's wrong with NAT64 in IPv6, which does exactly that?
Nothing wrong with the technique, but there's something wrong with IPv6, namely not the slightest attempt to retain backward compatibility with IPv4 at the protocol level.
There is no possibility for a "properly backward compatible variant of IPv4." Any change to the protocol in which the goal is to increase the address space, which is the mean impetus for all of this, required a re-write which means no backward compatibility.
You seem to be unclear on the definition of backward compatibility. This means that the old protocol is a subset of the new one. There are countless examples where protocol backward compatibility has been achieved in a useful way. Unfortunately, IPv6 is not one of them.
Dual stack is already backwards compatible with v4 in some awkward way, so it's an existence proof. The object of the exercise would be to do it less awkwardly, in a single protocol. Clearly, an extended protocol, say, v4x, must tuck away some more address bits in the already crowded header. To reliably identify extended addresses on v4x aware hosts and to make them fail on v4x unaware host, it would be enough to change the protocol number. (There happens to be a good candidate available for historical reasons.) Extended address hosts would not be able to connect directly to non-extended address hosts, but we already have a way of dealing with that: NAT. Over time, extended address hosts could drop the NAT. Not straightforward, but doable if the will is there. Naturally, any proposal remotely like that is going to get shouted down by the IPv6 mafia without any technical analysis at all, but who knows what might happen if in another year or two IPv6 still looks like it's not going to break the 50% barrier in the next decade. One thing IPv6 did succeed at: all the kernel and library plumbing now supports at least 128 bit addresses, which would considerably ease the pain of trying again with something that looks and acts a lot more like IPv4, the protocol that will not die.
Eleven percent adoption hardly constitutes "well on its way", it's more like "finally getting some traction". In the sense of resource wastage and slow adoption, there is no question at this point that IPv6 is one of the great failures of technology history. While IPv6 did not die, what it has failed to do is replace IPv4, and at this point, it quite possibly never will. If IPv6 had been well designed it would be handling 90% of internet traffic long ago and IPv4 would be well on its way to being as dead as DOS.
I would not discount the possibility of a properly backward compatible variant of IPv4 emerging, to address the very real needs of popular web servers that have no economically viable choice other than maintaining compatibility with IPv4 far into the future.
While we're on the subject Carthage, it's worth noting that the history of the city did not end with the last Punic war... 200 years later Carthage had been rebuilt by the Romans and had a population of half a million, second only to Rome itself in the western empire. Carthage eventually evolved into Tunis, of which the archeological site is a suburb. So that "sowing to salt" thing makes a great sound bite, but it was hardly permanent.
The first and most significant layer of stupid is the user who keeps subjecting themselves to this year in and year out when they know perfectly well what they need to do to end the pain.
not because Linux makes such as great desktop but because microsoft has become such incompetent assholes and windows has become such a pain the ass to bother with
I had the unfortunate experience of using Windows yesterday because I got a plea for help from somebody who needed to get a CD track onto a usb stick. I was astounded how far Windows has fallen behind Linux in user experience, reliability, performance, everything. Gave up trying to do that simple task with Windows after an hour... who know what the problem was, functionality intentionally omitted, malware, bugs, design flaws, what? Any random Linux machine can do this a dozen different ways. Took roughly 2 minutes with a Linux laptop including installing k3b.
The way Slashdot is battering us daily with "Windows 10 Upgrade Horror Stories" is exactly like the way the Get Windows 10 nagware update screens batter the Windows 7 owners.
Speak for yourself. I like these regular updates on the slow motion train wreck that is Windows.
Microsoft doesn't care because the legal institutions that supposedly protect users from this kind of misuse of their computing hardware apparently don't care.
No, sorry, it is not the responsibility of legal institutions to protect users from doing stupid things like relying on Microsoft. As long as users are too lazy and/or apathetic to take control of their own computing devices using the alternatives available then they will continue to suffer abuse and loss of productivity, and that is self-inflicted.
Legal institutions are supposed to protect consumers from harm by trust-making activities by corporations, it's pretty hard to spin these abusive upgrade shenanigans as that. You might hope for some relief from consumer protection agencies, but good luck with that. Your only realistic alternative is to vote with your install disk.
Microsoft doesn't want to invest the time and money.
It's not just that, it is also clear the the time and money required is significant, which in turn indicates that the code base is a rambling disaster. Big surprise or what?
Note: the Linux ecosystem accomplished the 64 bit transition for essentially all projects with just a handful of developers per project, suggesting that an open source code base tends to be better structured than Microsoft's.
Slashdot Mirror
There's only one way to read this: OMG next quarter's loss will make the last one look like a profit, we need a distraction fast.
Imagine office integration where you can easily share documents, send messages, and video conference among LinkedIn contacts.
What a horrible thought. I can't see anybody being comfortable with exposing their internal business processes to M$ spying. Granted, M$ always has big thoughts. Linkedin users have one simple thought: what are the alternatives?
They will keep doing these random acquisitions until something works or they run out of capital.
Or until a corporate raider moves in and fires the board.
Why are they running Windows?
A fragile, expensive, complicated, inefficient vehicle that won't fly or drive very well, that few people can actually operate safely and that nobody actually needs?
Much like a sailboat.
But will it fold into a briefcase?
Can it travel beneath the sea? Tunnel through solid rock? Fly to the moon? Does it have a jacuzzi?
They also need a new power source... because the current real problem with flying cars is the energy problem...
There are many problems, among them: extra weight needed for street legal operation; conflict between aerodynamic configuration and road vehicle form factor including need to fit into a standard parking space; payload constraints; weight and balance (forget the back seat); safety (what is the glide angle if any if the engine stops); noise control; limited market; regulation. Even Mr fusion won't solve all the problems.
It is abundantly clear that the vtol light private plane problem needs to be solved first, before imposing additional constraints to make it roadworthy.
will this really make commuting easier?
Grossly energy inefficient, noisier and considerably more dangerous, rather like a helicopter. The notion of making such a vehicle street legal is, in a word, absurd. If you can afford such a toy then you can afford to have someone meet you at the landing pad with a real car.
Yeah? It's not fundamentally any different to a v4 header. It's got a new protocol number and more of it is dedicated to storing addresses. Yes, it's 2x the size, but that's because the src+dst addresses are already 32 bytes to v4's 20 bytes total.
Presumably you were suggesting to do the same thing, because there's no way to fit a pair of 128-bit addresses into the v4 header without making it bigger.
(Ab)using the version field (not the protocol field!) is not the only way to extend IPv4, probably not even a good way, however that is a red herring. The point is, there is no such thing as an IPv6 packet that looks like IPv4, even when the source and destination addresses permit it. That is the big gaping flaw of IPv6 that lead to the adoption fiasco.
Nothing wrong with the technique, but there's something wrong with IPv6, namely not the slightest attempt to retain backward compatibility with IPv4 at the protocol level.
Well, there's that version number in the header, which allows the two to coexist.
Not only as separate protocols, but separate infrastructures. IPv6 has its own home rolled approach to multicast for example, which nobody uses as opposed to IPv4 multicast which is heavily used (and will not be going away any time soon because it runs the world's financial systems). IPv6 has its own NIH address syntax. Everything that could possibly be made different about IPv6 was made different. Second system syndrome in its most ugly form.
But more to the point: how is your v4x any different to this? You're suggesting doing exactly the same things v6 did.
(Note that I'm not shouting you down here; I'm pointing out that you're proposing essentially the thing that we already did.)
I'm not making a proposal. I am saying that the time is right to make a proposal. I didn't know that there's actually a proposal on the table, here. I will be taking some time to study it, I suggest you do too. It seems I'm far from the only person who thinks that IPv6 is still a disaster and there is room to attack the problem from another direction.
Since you consider yourself an expert, would you care to explain why you think that IPv6 is especially routable? (Hint: don't bother parroting the lame handwaving from wikipedia)
Second thing is, have you seen any IPv4 successor proposals? Link please.
Funnily enough, what you've described there is basically IPv6.
In some wildly theoretical sense, it is something like IPv6, but then it isn't at all. Do you even know what an IPv6 header looks like?
If you think that NAT is the way to go about connecting to legacy v4-only hosts, then what's wrong with NAT64 in IPv6, which does exactly that?
Nothing wrong with the technique, but there's something wrong with IPv6, namely not the slightest attempt to retain backward compatibility with IPv4 at the protocol level.
There is no possibility for a "properly backward compatible variant of IPv4." Any change to the protocol in which the goal is to increase the address space, which is the mean impetus for all of this, required a re-write which means no backward compatibility.
You seem to be unclear on the definition of backward compatibility. This means that the old protocol is a subset of the new one. There are countless examples where protocol backward compatibility has been achieved in a useful way. Unfortunately, IPv6 is not one of them.
Dual stack is already backwards compatible with v4 in some awkward way, so it's an existence proof. The object of the exercise would be to do it less awkwardly, in a single protocol. Clearly, an extended protocol, say, v4x, must tuck away some more address bits in the already crowded header. To reliably identify extended addresses on v4x aware hosts and to make them fail on v4x unaware host, it would be enough to change the protocol number. (There happens to be a good candidate available for historical reasons.) Extended address hosts would not be able to connect directly to non-extended address hosts, but we already have a way of dealing with that: NAT. Over time, extended address hosts could drop the NAT. Not straightforward, but doable if the will is there. Naturally, any proposal remotely like that is going to get shouted down by the IPv6 mafia without any technical analysis at all, but who knows what might happen if in another year or two IPv6 still looks like it's not going to break the 50% barrier in the next decade. One thing IPv6 did succeed at: all the kernel and library plumbing now supports at least 128 bit addresses, which would considerably ease the pain of trying again with something that looks and acts a lot more like IPv4, the protocol that will not die.
According to the statistics available here, https://www.google.ca/intl/en/... IPv6 is well on it's way.
Eleven percent adoption hardly constitutes "well on its way", it's more like "finally getting some traction". In the sense of resource wastage and slow adoption, there is no question at this point that IPv6 is one of the great failures of technology history. While IPv6 did not die, what it has failed to do is replace IPv4, and at this point, it quite possibly never will. If IPv6 had been well designed it would be handling 90% of internet traffic long ago and IPv4 would be well on its way to being as dead as DOS.
I would not discount the possibility of a properly backward compatible variant of IPv4 emerging, to address the very real needs of popular web servers that have no economically viable choice other than maintaining compatibility with IPv4 far into the future.
While we're on the subject Carthage, it's worth noting that the history of the city did not end with the last Punic war... 200 years later Carthage had been rebuilt by the Romans and had a population of half a million, second only to Rome itself in the western empire. Carthage eventually evolved into Tunis, of which the archeological site is a suburb. So that "sowing to salt" thing makes a great sound bite, but it was hardly permanent.
It's about the showdown between Facebook and Google Plus.
It's about the showdown between psycho Zuck and social misfit Larry.
Understanding a particular spectacle require some knowledge of his culture.
The commentary I saw from Swiss sources was consistently that they were embarrassed by it, even apologize for it.
Windows is mainly still alive because of the network effect, that's why they can release every crap without fearing to lose market share.
They are losing market share.
The first and most significant layer of stupid is the user who keeps subjecting themselves to this year in and year out when they know perfectly well what they need to do to end the pain.
not because Linux makes such as great desktop but because microsoft has become such incompetent assholes and windows has become such a pain the ass to bother with
I had the unfortunate experience of using Windows yesterday because I got a plea for help from somebody who needed to get a CD track onto a usb stick. I was astounded how far Windows has fallen behind Linux in user experience, reliability, performance, everything. Gave up trying to do that simple task with Windows after an hour... who know what the problem was, functionality intentionally omitted, malware, bugs, design flaws, what? Any random Linux machine can do this a dozen different ways. Took roughly 2 minutes with a Linux laptop including installing k3b.
The way Slashdot is battering us daily with "Windows 10 Upgrade Horror Stories" is exactly like the way the Get Windows 10 nagware update screens batter the Windows 7 owners.
Speak for yourself. I like these regular updates on the slow motion train wreck that is Windows.
Microsoft doesn't care because the legal institutions that supposedly protect users from this kind of misuse of their computing hardware apparently don't care.
No, sorry, it is not the responsibility of legal institutions to protect users from doing stupid things like relying on Microsoft. As long as users are too lazy and/or apathetic to take control of their own computing devices using the alternatives available then they will continue to suffer abuse and loss of productivity, and that is self-inflicted.
Legal institutions are supposed to protect consumers from harm by trust-making activities by corporations, it's pretty hard to spin these abusive upgrade shenanigans as that. You might hope for some relief from consumer protection agencies, but good luck with that. Your only realistic alternative is to vote with your install disk.
Even In Remotest Africa, Windows Ruins Your Day
Microsoft doesn't want to invest the time and money.
It's not just that, it is also clear the the time and money required is significant, which in turn indicates that the code base is a rambling disaster. Big surprise or what?
Note: the Linux ecosystem accomplished the 64 bit transition for essentially all projects with just a handful of developers per project, suggesting that an open source code base tends to be better structured than Microsoft's.
I was not whining about how patronizing others are
Yes you were. Mirror. Self.
Google employee much?