If we did, china would let it go on for a year or two, then wait till all the investors dump huge loads of cash into the business to expand and streamline. After fortunes are invested, China will stop any existing embargos and then triple their rare earth mining output just to slam all the competitors into the ground.
Not without violating numerous international treaties on fair trade.
I would say drivers are even more of an issue on Windows given the lack of interest from hardware vendors in supporting older versions of windows and apparent aversion to fixing bugs.
Over the past few years, modern Linux distributions such as Ubuntu have utterly transformed the open-source desktop user experience into something sleek and simple, while arguably surpassing Windows and Mac OS in both security and stability.
...and usability. I installed and played a new A list title on Windows last week and every minute of the experience made me want to scream. From the surprise reboot due to virus patches to the 25 digit "authorization" code that has to be entered manually, to the many step, go back to the beginning and try to figure it out again installation process, to the jerky video, to the clumsy user interface, it all trails the modern Linux desktop experience by a wide country mile. I swear, this is the last time I will ever run a game of any description on Windows, or any application that I am not absolutely forced to. These days that happens about once every two years, and fallilng.
If anything, shouldn't the "do no evil" Google be paying some amount (couple mil) voluntary for the upkeep of Java, even if it didn't have to, if we're going to talk about morality?
It is always wrong to pay off a thug. Sometimes necessary, but always wrong.
Google has gotten away with not making Android a real Java, and thus not subject to Oracle's rules for the platform.
The idea that a computer language should have rules imposed by a vendor is as absurd as the idea that a spoken language should have rules imposed by a government. In most civilized countries there is no such absurdity.
Fuck you Oracle. Android is the only mobile OS worth using on the market right now, why are you trying to fuck that up? Its not like Apple's garbage is worth using.
Oracle wants to get money from Google and control the Android phone market. Evil? No question about it. Moral? Not a bit. Good for users? No. Good for the economy? Certainly not. Yet another typical dickhead move by Larry Ellison? You bet.
So, I'll take the karma hit and ask - to all the people that rant and rave about how closed and proprietary Apple is and how wonderful Android is, how does this sit within your vision of things?
It sucks and it makes Google evil, but it doesn't make Apple less evil.
please explain to me how it is an actual violation of that license
Section 3, paragraph 11, about a third of the way down, "Don't be evil."
Indeed. For anyone under misapprehsion that Google does not have the propensity for evil, or is not already evil, this should remove any remaining doubt.
If the issue is not resolved satisfactorily, and by that I mean by Google and not by the usual ever-vigilant outside developers, I will simply return the G2 I bought yesterday. I was perfectly happy with my nonsmart Nokia music phone, which has the additional advantages that it fits comfortably in my pocket and runs for several days without a recharge.
Exceeding the size of a traditional socket addr was a monumentally bad idea, it greatly increased the scope of what had to be rewritten, and even today many programs do not work because they have not been converted to use interfaces that support larger socket addrs.
As I said, this problem is common to any extended address format. Adding more addresses means programs need to be updated to handle a new address format. You can't fit any more addresses into 32 bits than already exist.
Nonsense. sockaddr_in is 16 bytes, plenty of room to fit a uint64_t address for IPv4.5 (hypothetical name). Not enough for a 128 byte address. See, the IPv6 committee was completely and utterly stupid in this regard.
It does matter whether the user is required to manage two network stacks or one.
I'll grant you this, but there is nothing about IPv6 that mandates managing two network stacks separately; that is simply how the UIs have been designed. One could create tools for unified IPv4 and IPv6 management.
That would have been almost sensible, but no such sensible things were done, again due to the directions set out by the IPv6 committee.
The question of bumping the protocol number or not is a very good one. I think most probably "not" is the right design point but I haven't actually tried this.
It does matter that the new address format is unfamiliar and in no way an extension of the familiar format.
Now you're really grasping at straws.
That's a straw? Ask any administrator who has been force-fed the new regimen whether they think this detail is a nothing more than a little straw.
Who exactly does it matter to? How many people do you think deal directly in IP addresses, particularly now that we have mDNS?
Everybody who runs the internet and all the IT departments, that's a pretty big who.
...but IPv6 addresses will become familiar soon enough for anyone who has to work with them.
In somebody's dreams maybe. The fact is, nobody needs to work with IPv6 today because nobody (relatively speaking) is using it, and nobody (relatively speaking) will be using it in the foreseeable future. It's dead, Jim.
Any variation on extended IP addresses will require just as much support from applications as IPv6.
This is your mistake. You see this question in black and white, whereas the real world works in shades of gray. It does matter _how much_ the new protocol breaks the stack. Exceeding the size of a traditional socket addr was a monumentally bad idea, it greatly increased the scope of what had to be rewritten, and even today many programs do not work because they have not been converted to use interfaces that support larger socket addrs. It does matter whether the user is required to manage two network stacks or one. It does matter that the new address format is unfamiliar and in no way an extension of the familiar format.
But these issues, huge to actual users, are just considered minor theoretical details by IPv6 cheerleaders. And these are just a few that came to mind. They do matter, I see that first hand.
IPv6 has failed, the adoption curve is a flat as a pancake. IPv6 is just as dead as Itanic. And for the same reason: the designers were not mindful of backward compatibility.
Redundant or not, you can't put anything other than a valid checksum in the IP checksum field without breaking every device which has to examine (and thus validate) the IP header. That includes every single router. If you're going to drop backward-compatibility anyway, why not fix the other problems with IPv4 at the same time?
The expected behavior is that a router that doesn't understand the extended address will drop the packet. Check.
Your argument in favor of throwing out all of IPv4 is flawed, it is a false dichotomy. In fact, there exist degrees of breakage. A responsible engineer tries to minimize breakage when breakage is necessary. The degree to which the IPv6 wallowed in breaking the existing network stack is, in a word, unconscionable. My thesis is that, in order to 'save the internet' by extending the range of routable addresses we must begin by admitting IPv6 has failed, which ought to be clear to all but the most tenacious IPv6 diehards by now.
IPv6 certainly isn't perfect. However, implementing any of the alternatives proposed in this thread would cost nearly as much, without addressing the long-term issue: non-hierarchical address allocation and the resulting exponential growth of routing tables.
The great saving of the proposal in this thread is that interoperability with the existing internet is never lost. Clients could migrate to this hypothetical extended IPv4 addressing scheme at their convenience, as routes open up due to routers being upgraded. It may be that it is not convenient at any point in the near future for a.com server to migrate to an extended address, however there are certainly enough non-extended IPv4 addresses available to handle all.coms for now and a long, long time.
The long term problem of heirarchical routing... IPv6 fails to make the problem go away with its stupidly long addresses due to multihomed hosts and other issues. CIDR does a perfectly good job, and where it suffers strain the issue should be solved by extending router-router protocols, not client-client.
Actually, the IP checksum isn't as redundant as you think. It provides end-to-end protection for the IP packet; the ethernet checksum is link-level, and changes every time the packet it forwarded (due to different MAC addresses, if nothing else). You need both to deal with the possibility of malfunctioning routers.
...which is why the IPv6 designers felt it necessary to include header checksums in IPv6. Oh wait, they didn't.
Putting the remaining 2 sections on separate portion of the packet, keeping the first 4 sections normal, would allow legacy hardware to route these, yet trivial to make new hardware to understand
They will fit nicely in the checksum field, which is redundant. Less one bit, used to make the checksum invalid so that routers will not attempt to route the packet if they do not understand the extension scheme. The two extension bytes properly belong on the low order end of the address so that the existing CIDR continues to work properly.
Of course, that would still not be a good long-term solution. After a little while, you'd end up with the port field being shortened so much that people would complain. You'd also have the problem that you actually use the variable-length port field, every machine on your local segment would need an upgraded network stack, and protocols that expected to be able to use high port numbers would have serious problems.
So instead of stealing address bits from the port field grab the checksum field, it isn't doing anything useful that the ethernet checksum doesn't already do.
The problem with the approach is that it's very difficult to do in a way that doesn't break backwards compatibility, and if you're going to break compatibility then you may as well fix other things at the same time.
...and that was all the justification the committee needed to succumb fully to second system syndrome.
Junta summarized it satisfactorily. I could elaborate, but what would be the point? Oh well. For example going to 128 bit addresses was in a word idiotic. It failed to ameliorate router loading issues as hoped, and in fact made things worse by imposing a bigger cache footprint than necessary. It also broke every network library to a much worse extent than necessary by exceeding the 16 bytes allowed from the dawn of time for socket addresses, which design point was chosen by people who knew what they were doing as opposed to the people who ended up on the IPv6 committee.
The big fail is that IPv6 and IPv4 hosts cannot communicate in any way that could remotely be described as natural. What commercial web site wants to cut over to an IPv6 address today, or any time in the foreseeable future?
All agreed, except that IPv6 leaders won't extract their heads from their asses, I have seen this first hand. This does not negate your argument, it just says that the IPv6 leaders are not the right people to fix the problem.
The real issue is that IPv6 was horribly badly misconceived and misdesigned right from the start, in such a way that it was doomed to become the epic fail we know and love today. I am very skeptical that ipv6 can be fixed.
Slashdot Mirror
What a precious gift to humanity you are.
If we did, china would let it go on for a year or two, then wait till all the investors dump huge loads of cash into the business to expand and streamline. After fortunes are invested, China will stop any existing embargos and then triple their rare earth mining output just to slam all the competitors into the ground.
Not without violating numerous international treaties on fair trade.
I would say drivers are even more of an issue on Windows given the lack of interest from hardware vendors in supporting older versions of windows and apparent aversion to fixing bugs.
Over the past few years, modern Linux distributions such as Ubuntu have utterly transformed the open-source desktop user experience into something sleek and simple, while arguably surpassing Windows and Mac OS in both security and stability.
...and usability. I installed and played a new A list title on Windows last week and every minute of the experience made me want to scream. From the surprise reboot due to virus patches to the 25 digit "authorization" code that has to be entered manually, to the many step, go back to the beginning and try to figure it out again installation process, to the jerky video, to the clumsy user interface, it all trails the modern Linux desktop experience by a wide country mile. I swear, this is the last time I will ever run a game of any description on Windows, or any application that I am not absolutely forced to. These days that happens about once every two years, and fallilng.
If anything, shouldn't the "do no evil" Google be paying some amount (couple mil) voluntary for the upkeep of Java, even if it didn't have to, if we're going to talk about morality?
It is always wrong to pay off a thug. Sometimes necessary, but always wrong.
Google has gotten away with not making Android a real Java, and thus not subject to Oracle's rules for the platform.
The idea that a computer language should have rules imposed by a vendor is as absurd as the idea that a spoken language should have rules imposed by a government. In most civilized countries there is no such absurdity.
Fuck you Oracle. Android is the only mobile OS worth using on the market right now, why are you trying to fuck that up? Its not like Apple's garbage is worth using.
Oracle wants to get money from Google and control the Android phone market. Evil? No question about it. Moral? Not a bit. Good for users? No. Good for the economy? Certainly not. Yet another typical dickhead move by Larry Ellison? You bet.
once public the Google CEO makes a statement of being against it
May I have a link to Eric's statement please?
So, I'll take the karma hit and ask - to all the people that rant and rave about how closed and proprietary Apple is and how wonderful Android is, how does this sit within your vision of things?
It sucks and it makes Google evil, but it doesn't make Apple less evil.
please explain to me how it is an actual violation of that license
Section 3, paragraph 11, about a third of the way down, "Don't be evil."
Indeed. For anyone under misapprehsion that Google does not have the propensity for evil, or is not already evil, this should remove any remaining doubt.
If the issue is not resolved satisfactorily, and by that I mean by Google and not by the usual ever-vigilant outside developers, I will simply return the G2 I bought yesterday. I was perfectly happy with my nonsmart Nokia music phone, which has the additional advantages that it fits comfortably in my pocket and runs for several days without a recharge.
Exceeding the size of a traditional socket addr was a monumentally bad idea, it greatly increased the scope of what had to be rewritten, and even today many programs do not work because they have not been converted to use interfaces that support larger socket addrs.
As I said, this problem is common to any extended address format. Adding more addresses means programs need to be updated to handle a new address format. You can't fit any more addresses into 32 bits than already exist.
Nonsense. sockaddr_in is 16 bytes, plenty of room to fit a uint64_t address for IPv4.5 (hypothetical name). Not enough for a 128 byte address. See, the IPv6 committee was completely and utterly stupid in this regard.
It does matter whether the user is required to manage two network stacks or one.
I'll grant you this, but there is nothing about IPv6 that mandates managing two network stacks separately; that is simply how the UIs have been designed. One could create tools for unified IPv4 and IPv6 management.
That would have been almost sensible, but no such sensible things were done, again due to the directions set out by the IPv6 committee.
The question of bumping the protocol number or not is a very good one. I think most probably "not" is the right design point but I haven't actually tried this.
It does matter that the new address format is unfamiliar and in no way an extension of the familiar format.
Now you're really grasping at straws.
That's a straw? Ask any administrator who has been force-fed the new regimen whether they think this detail is a nothing more than a little straw.
Who exactly does it matter to? How many people do you think deal directly in IP addresses, particularly now that we have mDNS?
Everybody who runs the internet and all the IT departments, that's a pretty big who.
...but IPv6 addresses will become familiar soon enough for anyone who has to work with them.
In somebody's dreams maybe. The fact is, nobody needs to work with IPv6 today because nobody (relatively speaking) is using it, and nobody (relatively speaking) will be using it in the foreseeable future. It's dead, Jim.
Any variation on extended IP addresses will require just as much support from applications as IPv6.
This is your mistake. You see this question in black and white, whereas the real world works in shades of gray. It does matter _how much_ the new protocol breaks the stack. Exceeding the size of a traditional socket addr was a monumentally bad idea, it greatly increased the scope of what had to be rewritten, and even today many programs do not work because they have not been converted to use interfaces that support larger socket addrs. It does matter whether the user is required to manage two network stacks or one. It does matter that the new address format is unfamiliar and in no way an extension of the familiar format.
But these issues, huge to actual users, are just considered minor theoretical details by IPv6 cheerleaders. And these are just a few that came to mind. They do matter, I see that first hand.
IPv6 has failed, the adoption curve is a flat as a pancake. IPv6 is just as dead as Itanic. And for the same reason: the designers were not mindful of backward compatibility.
Some have claimed that open source developers go into Google and disappear. This is correct. I can confirm it from firsthand experience.
Redundant or not, you can't put anything other than a valid checksum in the IP checksum field without breaking every device which has to examine (and thus validate) the IP header. That includes every single router. If you're going to drop backward-compatibility anyway, why not fix the other problems with IPv4 at the same time?
The expected behavior is that a router that doesn't understand the extended address will drop the packet. Check.
Your argument in favor of throwing out all of IPv4 is flawed, it is a false dichotomy. In fact, there exist degrees of breakage. A responsible engineer tries to minimize breakage when breakage is necessary. The degree to which the IPv6 wallowed in breaking the existing network stack is, in a word, unconscionable. My thesis is that, in order to 'save the internet' by extending the range of routable addresses we must begin by admitting IPv6 has failed, which ought to be clear to all but the most tenacious IPv6 diehards by now.
IPv6 certainly isn't perfect. However, implementing any of the alternatives proposed in this thread would cost nearly as much, without addressing the long-term issue: non-hierarchical address allocation and the resulting exponential growth of routing tables.
The great saving of the proposal in this thread is that interoperability with the existing internet is never lost. Clients could migrate to this hypothetical extended IPv4 addressing scheme at their convenience, as routes open up due to routers being upgraded. It may be that it is not convenient at any point in the near future for a .com server to migrate to an extended address, however there are certainly enough non-extended IPv4 addresses available to handle all .coms for now and a long, long time.
The long term problem of heirarchical routing... IPv6 fails to make the problem go away with its stupidly long addresses due to multihomed hosts and other issues. CIDR does a perfectly good job, and where it suffers strain the issue should be solved by extending router-router protocols, not client-client.
It's redundant enough to make the concept I described perfectly feasible.
Actually, the IP checksum isn't as redundant as you think. It provides end-to-end protection for the IP packet; the ethernet checksum is link-level, and changes every time the packet it forwarded (due to different MAC addresses, if nothing else). You need both to deal with the possibility of malfunctioning routers.
...which is why the IPv6 designers felt it necessary to include header checksums in IPv6. Oh wait, they didn't.
Putting the remaining 2 sections on separate portion of the packet, keeping the first 4 sections normal, would allow legacy hardware to route these, yet trivial to make new hardware to understand
They will fit nicely in the checksum field, which is redundant. Less one bit, used to make the checksum invalid so that routers will not attempt to route the packet if they do not understand the extension scheme. The two extension bytes properly belong on the low order end of the address so that the existing CIDR continues to work properly.
is why didn't we just go for an extension?
That would have made too much sense and the IPv6 committee wanted to build a monument.
Of course, that would still not be a good long-term solution. After a little while, you'd end up with the port field being shortened so much that people would complain. You'd also have the problem that you actually use the variable-length port field, every machine on your local segment would need an upgraded network stack, and protocols that expected to be able to use high port numbers would have serious problems.
So instead of stealing address bits from the port field grab the checksum field, it isn't doing anything useful that the ethernet checksum doesn't already do.
The problem with the approach is that it's very difficult to do in a way that doesn't break backwards compatibility, and if you're going to break compatibility then you may as well fix other things at the same time.
...and that was all the justification the committee needed to succumb fully to second system syndrome.
IPv6 is the Duke Nukem Forever of the internet.
Junta summarized it satisfactorily. I could elaborate, but what would be the point? Oh well. For example going to 128 bit addresses was in a word idiotic. It failed to ameliorate router loading issues as hoped, and in fact made things worse by imposing a bigger cache footprint than necessary. It also broke every network library to a much worse extent than necessary by exceeding the 16 bytes allowed from the dawn of time for socket addresses, which design point was chosen by people who knew what they were doing as opposed to the people who ended up on the IPv6 committee.
The big fail is that IPv6 and IPv4 hosts cannot communicate in any way that could remotely be described as natural. What commercial web site wants to cut over to an IPv6 address today, or any time in the foreseeable future?
All agreed, except that IPv6 leaders won't extract their heads from their asses, I have seen this first hand. This does not negate your argument, it just says that the IPv6 leaders are not the right people to fix the problem.
Like it or not, Oracle is part of the OSS community.
True, and liberating Openoffice from their rapacious tentacles will not change that.
You mean like Wireshark vs Ethereal? Oh wait, everybody uses Wireshark now and Ethereal is sinking slowly into obscurity, as is right and proper.
The real issue is that IPv6 was horribly badly misconceived and misdesigned right from the start, in such a way that it was doomed to become the epic fail we know and love today. I am very skeptical that ipv6 can be fixed.