What a loaded article. It sounds like Foxconn's working conditions are actually much better than most companies in China...
Attack of the Apple apologists. What it actually shows is that Apple in fact has done little to correct the widely publicized working condition problems in its supply chain. Whether these problems exist in China or anywhere else is immaterial: Apple is the beneficiary of these oppressive labour practices in any case. Now Apple is faced with trimming its fat margins as opposed to its usual strategy of hammering its suppliers in underdeveloped economies in order to maintain its precious stock price. As it should have done in the first place, but reality distortion is Apple's entrenched culture. In the best case Apple begins to purge that ethical and moral rot along with some of the other less admirable legacy of its late founder. But the proof is action, not spin, and so far we have just seen spin from Apple.
And bear in mind that the Fair Labour Association is on the payroll of Apple and other perps. In other words, the primary purpose of the FLA is to "accredit" the supply chain on behalf of the corps that pay its bills. What is the real truth that would be revealed by a truly independent watchdog?
OK, I checked out the merurial repo (good taste!), built it and ran hello.go. Just one thing: the syntax "go run hello.go" is stupid, it should be "go hello.go" and --options for anything else you want to do.
I have a generally better feeling about this project than I ever did about Java or C#. It seems like the prevailing sentiment is common sense. But mind you, maybe that is becuase I have not yet tried it. But I will fix that now.
Yes we can. If the low order byte of host B's address is zero, they can communicate, otherwise A needs to upgrade in order to establish a direct connection with B.
I want to send a message to host A from host B. Host A is on IPv4. Host B is NOT. Host B does NOT have an IPv4 address because ah...well they ran out and running out has consequences.
How does host B know if host A will be able to receive host B's message?
Simple: if host A does not understand 5 byte IPv4+, it cannot establish a direct connection with host B. Host A should upgrade if it wants to connect directly to host B. Meanwhile, host B, with a 5 byte address, can connect directly to any IPv4+ enabled host whether the other host has a four or five byte address. To connect to an unaware IPv4 host, host B needs some help from a NAT. This is where having the fifth byte on the low order end is really helpful: the NAT does not need to be stateful and does not need to delve into protocols. It just needs to manage its pool of dynamic IPs as dynamic IP shemes already do.
Now here is the thing: dotcoms can run a 5 byte-aware stack while having a 4 byte address themselves. Unlike the big adminstrative headache of IPv6 dual stack, all the dotcom needs is the equivalent of apt-get upgrade. So IPv4+ traffic can just grow organically as routes appear and hosts come online, and there is none of this take a leap of faith and jump off the cliff into the huge, empty IPv6 internet that has dogged IPv6 from the start.
Had the industry started w/ 64-bit CPUs and OSs, that would have been fantastic.
OK, you sent the message loud and clear: you have no concept whatsoever of the advantages of pragmatism. Like a typical IPv6 booster, you live in a cloud where efficiency does not matter, compatibility does not matter, only forcing the wodl to accede to the brilliance of the great new white elephant matters.
Hint: if intel had tried to market a 64 bit microprocessor instead of an 8 bit, or indeed, 4 bit processor they would have been years late to market and nobody would know about them now, nor care.
these days, it seems like it isn't the MS zealots that come out foaming anymore anyway. (If I say more, I'll be accused of flamesturbaiting.)
True, their numbers and ardour are greatly dimiished. They seem to be about ready to admit deat. Still, Microsoft has a few nasties left in its bag of tricks, and at no point seems to have equired an ethical spine.
Introduce an "intenet repair tax" that applies for Windows users. And they can just go on being lazy and fearful of changing to something better designed, but at least they will contribute towards paying for the damage.
We can not know if host A communicating via IPv4 can also reach host B on IPvDP...
Yes we can. If the low order byte of host B's address is zero, they can communicate, otherwise A needs to upgrade in order to establish a direct connection with B.
...or what router along the path prevent host A from communicating with Host B.
IPv6 has the same issue.
If the address spaces are kept separate this is not an issue. Operationally this is critical to facilitiate migration.
What? Your leap of logic escapes me.
You could solve the problem for peers only by giving all existing IPv4 hosts addresses on the new extension network...
As I already stated. Standard IPv4 addresses are extended with a byte of zero at the low order end.
but this does not address routers, requires everyone renumber anyway...
How do you conclude that renumbering is required?
and is therefore no better than IPv6.
You haven't proved that, especially not without filling in your logical holes above.
Operationally IPv6 massive address space is a huge win for operators and end users
Both those claims are firmly in the "hopefully, one day" category.
and is well on its way to full deployment.
That requires a creative definition of "well on the way". And what would be the use of "fully deployed" (if that ever happens) but not used? The generally accepted term for that is white elephant. In Canada we had an airport like that, Mirabel, all shiny and new and sitting for years with virtuatlly no planes on it because everybody preferred the old airport. Now redeveloped I believe.
I don't see why that's a straw man. An unaware network driver could just read what's in the source and destination addresses...
Not if it's an invalid packet according to an unaware network driver. For example, the checksum might be wrong. There are all kinds of things that can go wrong if an application tries to act on addresses contained in an invalid packet indeed. Delivery to the wrong protocol for example. What a mess that would make. An unintentional straw man is still a straw man, and you knocked that one down yet again.
Also, this proposal essentially means kicking the can down the road, requiring a future generation to have to deal w/ it.
Sure. We need time, and this buys time. If you are saying that is a bad thing, your argument is weak. We kicked the can down the road when we went from 8 to 16 bit microprocessors, and again when me moved to 32 bit. What would have happened if the industry had decided to start off with 64 bit processors, just to avoid "kicking the can down the road"?
The rational question is "how much time would this buy?" And I say, a lot. More than enough so that a long term solution, even an ugly one like IPv6, can set itself in place in such a way as to enable a smooth cutover. Very definitely not the case with the current fiasco.
But people are always going to find excuses not to switch, thereby putting off indefinitely the improvements that have been engineered into IPv6.
None of the "bundled" IPv6 improvements is compelling. The only item in the compelling category is the address space fix. And there is more than one way to do that, and as we see here, there are ways that do not require every network admin in the world to relearn their basics.
People are especially going to find excuses not to switch when the switch is to something unfamiliar, or to something that does not work perfectly. Both very much the case with IPv6.
If these changes required no changes to all the networking equipment out there, I'd agree w/ you. But the minimum it needs is a firmware upgrade, and guess what - that's exactly what they'd need to be IPv6 compliant.
IPv6 switching requires considerably more hardware resources than IPv4, so network operators are faced not only with reflashing, but reprovisioning. And why? Customers are not beating down the door to get IPv6, so why should they bulldoze all their existing routers?
Then there is the question of ASICs as you say. That hardware is engineered for 32 bit addresses, not 128. An extended IPv4+ would still route most of the traffic through the hardware switch and only need to take extended packets out of line. For IPv6, you need new hardware, period.
So, summary. Your argument that existing IPv4 stacks would necessarily misinterpret extended addresses is most probably wrong, given that a suitable method of invalidating extended packets from the viewpoint of unaware network stacks is available. The argument that we need to go immediately to addresses greater than the number of the atoms in the earth to avoid need to extend addresses again during the lifetime of your grandchild is weak. Your argue that people will not switch anyway, even if the slightest thing is different. But this argument is wrong. People upgrade their operating systems all the time, there are very few who do not. Provided that everything just works, that is not an issue. An IPv4+ stack could easily be deployed to end users, just as the IPv6 dual stack was, except an IPv4+ stack would not be dual, and therefore even less disruptive. In fact, the way has already been paved by the IPv6 dual stack deployment process in many respects. For example, replacing all the 32 bit oriented network APIs.
Final total: one straw man, one weak argument, one incorrect argument. See, it is a fact that IPv6 deployment has failed to cover the gap between address depletion and takeup of a solution. No possibility of argument ther
Nice straw man. You assumed that an some of the bits of an extended address could be interpreted as a valid address and nasty things would happen. But these nasty things will not happen if an IPv4+ packet with extended addresses is constructed to appear invalid to an unaware network driver. So basically you could have saved typing your last two paragraphs.
Your question of where to put the new addresses bits is constructive. The obsoletestream id option seems like a reasonable candidate, providing additional two octets, enough to supply the world's burgeoning address requirements for quite some time. Not a grandious 128 bits like IPv6, but just a modest expansion to take care of our needs basically for you and me, our kids, and our kids kids. That ought to be enough time to come up with some further *sensible* address expansion scheme.
So the principle is this: two extended address bytes are tucked away in places that will not destroy the internet. Such packets are constructed to appear invalid to unaware applications. If a path exists between a source and a destination both supportting extended addresses then the source and destination can communicate in the extended address space. The new byte goes at the least significant end, not the most significant, so that routing databases do not need to change.
See, it could work, and please aim mud at the argument, not your own straw man.
Actually, you can pack extra bits into an IPv4 packet in such a way that a) valid packets using 32 bit addresses remain valid and b) packets with extra address bits are seen as invalid by unaware network drivers. Therefore "they" are *not* all going need to be retrained, only thoes that want to access a wider address range. So how much smoother that would have been rollout wise? We would already be there by now if a sensible approach like this had been adopted instead of the throw out the baby with the bathwater approach we now struggle with. It is by no means impossible that if an extended IPv4 was introduced today, it could exceed IPv6 adoption levels long before IPv6 manages to attract enough web sites to be worth the bother.
No, that would require every OS to replace the TCP/IP stack. No backwards compatibility and no better off than IPv6.
IPv6 boosters are fond of this talking point, but "no backward compatibility" is a gross exaggeration, or to be precise it is a false dichotomy, when in fact the ability to preserve front end interfaces that are familiar to users and administrators is a form of backward compatibility. But that certainly would not be the only form of backward compabitility offered by an extended IPv4 stack.
You are free to make changes, period. Sun is free to drag their heels about certifying your changed code base as "Java" and that they do. So in general you may not call it Java. Which is where Microsoft went wrong (intentionally) and had to pay out billions. You are not only confused, but you are spreading FUD about what one may or may not do with GPL licensed software.
Slashdot Mirror
Foxconn is a sub-contractor of multiple companies so really Apple should not be the fall guy.
Utter rubbish. Apple is by far the biggest beneficiary of these oppressive practices and is riding high on the hog in part because of these abuses.
Wow, Apple astroturfers hoarded away plenty of points for modbombing today.
Foxconn is a sub-contractor of multiple companies so really Apple should not be the fall guy.
Utter rubbish. Apple is by far the biggest beneficiary of these oppressive practices and is riding high on the hog in part because of these abuses.
It's not an Apple problem...
...according to Apple apologists. Of which a huge herd appears to have swooped upon Slashdot the moment this article appeared.
This is China we're talking about
This is Apple we're talking about.
What a loaded article. It sounds like Foxconn's working conditions are actually much better than most companies in China...
Attack of the Apple apologists. What it actually shows is that Apple in fact has done little to correct the widely publicized working condition problems in its supply chain. Whether these problems exist in China or anywhere else is immaterial: Apple is the beneficiary of these oppressive labour practices in any case. Now Apple is faced with trimming its fat margins as opposed to its usual strategy of hammering its suppliers in underdeveloped economies in order to maintain its precious stock price. As it should have done in the first place, but reality distortion is Apple's entrenched culture. In the best case Apple begins to purge that ethical and moral rot along with some of the other less admirable legacy of its late founder. But the proof is action, not spin, and so far we have just seen spin from Apple.
And bear in mind that the Fair Labour Association is on the payroll of Apple and other perps. In other words, the primary purpose of the FLA is to "accredit" the supply chain on behalf of the corps that pay its bills. What is the real truth that would be revealed by a truly independent watchdog?
OK, I checked out the merurial repo (good taste!), built it and ran hello.go. Just one thing: the syntax "go run hello.go" is stupid, it should be "go hello.go" and --options for anything else you want to do.
I have a generally better feeling about this project than I ever did about Java or C#. It seems like the prevailing sentiment is common sense. But mind you, maybe that is becuase I have not yet tried it. But I will fix that now.
No. It statically links all the IO libraries. Which seem pretty bloaty but it's a bloaty world isn't it. Not the bloatiest pig on the farm though.
Yes we can. If the low order byte of host B's address is zero, they can communicate, otherwise A needs to upgrade in order to establish a direct connection with B.
I want to send a message to host A from host B. Host A is on IPv4. Host B is NOT. Host B does NOT have an IPv4 address because ah ...well they ran out and running out has consequences.
How does host B know if host A will be able to receive host B's message?
Simple: if host A does not understand 5 byte IPv4+, it cannot establish a direct connection with host B. Host A should upgrade if it wants to connect directly to host B. Meanwhile, host B, with a 5 byte address, can connect directly to any IPv4+ enabled host whether the other host has a four or five byte address. To connect to an unaware IPv4 host, host B needs some help from a NAT. This is where having the fifth byte on the low order end is really helpful: the NAT does not need to be stateful and does not need to delve into protocols. It just needs to manage its pool of dynamic IPs as dynamic IP shemes already do.
Now here is the thing: dotcoms can run a 5 byte-aware stack while having a 4 byte address themselves. Unlike the big adminstrative headache of IPv6 dual stack, all the dotcom needs is the equivalent of apt-get upgrade. So IPv4+ traffic can just grow organically as routes appear and hosts come online, and there is none of this take a leap of faith and jump off the cliff into the huge, empty IPv6 internet that has dogged IPv6 from the start.
Had the industry started w/ 64-bit CPUs and OSs, that would have been fantastic.
OK, you sent the message loud and clear: you have no concept whatsoever of the advantages of pragmatism. Like a typical IPv6 booster, you live in a cloud where efficiency does not matter, compatibility does not matter, only forcing the wodl to accede to the brilliance of the great new white elephant matters.
Hint: if intel had tried to market a 64 bit microprocessor instead of an 8 bit, or indeed, 4 bit processor they would have been years late to market and nobody would know about them now, nor care.
yeah, except for giving apple 30% off the top and not being able to offer the book for less anywhere else...
Wow, that sure does sound like price fixing.
these days, it seems like it isn't the MS zealots that come out foaming anymore anyway. (If I say more, I'll be accused of flamesturbaiting.)
True, their numbers and ardour are greatly dimiished. They seem to be about ready to admit deat. Still, Microsoft has a few nasties left in its bag of tricks, and at no point seems to have equired an ethical spine.
And I would be far from surprised to learn he is an inveterate Windows user.
they keep writing free software faster than we can use it!!111 halp!
Now that's scary.
Introduce an "intenet repair tax" that applies for Windows users. And they can just go on being lazy and fearful of changing to something better designed, but at least they will contribute towards paying for the damage.
The only current smartphone OS that is safe against exploits and vulnerabilities is Windows Phone 7.
Because nobody has bothered? Or perhaps because your bold claim just is not true?
I hope you realize that ICMP does not replace layer 2. And that IPv6 is always encapsulated in some layer 2 protocol like ethernet, just as IPv4 is.
We can not know if host A communicating via IPv4 can also reach host B on IPvDP...
Yes we can. If the low order byte of host B's address is zero, they can communicate, otherwise A needs to upgrade in order to establish a direct connection with B.
...or what router along the path prevent host A from communicating with Host B .
IPv6 has the same issue.
If the address spaces are kept separate this is not an issue. Operationally this is critical to facilitiate migration.
What? Your leap of logic escapes me.
You could solve the problem for peers only by giving all existing IPv4 hosts addresses on the new extension network...
As I already stated. Standard IPv4 addresses are extended with a byte of zero at the low order end.
but this does not address routers, requires everyone renumber anyway...
How do you conclude that renumbering is required?
and is therefore no better than IPv6.
You haven't proved that, especially not without filling in your logical holes above.
Operationally IPv6 massive address space is a huge win for operators and end users
Both those claims are firmly in the "hopefully, one day" category.
and is well on its way to full deployment.
That requires a creative definition of "well on the way". And what would be the use of "fully deployed" (if that ever happens) but not used? The generally accepted term for that is white elephant. In Canada we had an airport like that, Mirabel, all shiny and new and sitting for years with virtuatlly no planes on it because everybody preferred the old airport. Now redeveloped I believe.
Your hack not so much.
Nice rhetoric, but I you didn't prove that.
I don't see why that's a straw man. An unaware network driver could just read what's in the source and destination addresses...
Not if it's an invalid packet according to an unaware network driver. For example, the checksum might be wrong. There are all kinds of things that can go wrong if an application tries to act on addresses contained in an invalid packet indeed. Delivery to the wrong protocol for example. What a mess that would make. An unintentional straw man is still a straw man, and you knocked that one down yet again.
Also, this proposal essentially means kicking the can down the road, requiring a future generation to have to deal w/ it.
Sure. We need time, and this buys time. If you are saying that is a bad thing, your argument is weak. We kicked the can down the road when we went from 8 to 16 bit microprocessors, and again when me moved to 32 bit. What would have happened if the industry had decided to start off with 64 bit processors, just to avoid "kicking the can down the road"?
The rational question is "how much time would this buy?" And I say, a lot. More than enough so that a long term solution, even an ugly one like IPv6, can set itself in place in such a way as to enable a smooth cutover. Very definitely not the case with the current fiasco.
But people are always going to find excuses not to switch, thereby putting off indefinitely the improvements that have been engineered into IPv6.
None of the "bundled" IPv6 improvements is compelling. The only item in the compelling category is the address space fix. And there is more than one way to do that, and as we see here, there are ways that do not require every network admin in the world to relearn their basics.
People are especially going to find excuses not to switch when the switch is to something unfamiliar, or to something that does not work perfectly. Both very much the case with IPv6.
If these changes required no changes to all the networking equipment out there, I'd agree w/ you. But the minimum it needs is a firmware upgrade, and guess what - that's exactly what they'd need to be IPv6 compliant.
IPv6 switching requires considerably more hardware resources than IPv4, so network operators are faced not only with reflashing, but reprovisioning. And why? Customers are not beating down the door to get IPv6, so why should they bulldoze all their existing routers?
Then there is the question of ASICs as you say. That hardware is engineered for 32 bit addresses, not 128. An extended IPv4+ would still route most of the traffic through the hardware switch and only need to take extended packets out of line. For IPv6, you need new hardware, period.
So, summary. Your argument that existing IPv4 stacks would necessarily misinterpret extended addresses is most probably wrong, given that a suitable method of invalidating extended packets from the viewpoint of unaware network stacks is available. The argument that we need to go immediately to addresses greater than the number of the atoms in the earth to avoid need to extend addresses again during the lifetime of your grandchild is weak. Your argue that people will not switch anyway, even if the slightest thing is different. But this argument is wrong. People upgrade their operating systems all the time, there are very few who do not. Provided that everything just works, that is not an issue. An IPv4+ stack could easily be deployed to end users, just as the IPv6 dual stack was, except an IPv4+ stack would not be dual, and therefore even less disruptive. In fact, the way has already been paved by the IPv6 dual stack deployment process in many respects. For example, replacing all the 32 bit oriented network APIs.
Final total: one straw man, one weak argument, one incorrect argument. See, it is a fact that IPv6 deployment has failed to cover the gap between address depletion and takeup of a solution. No possibility of argument ther
Nice straw man. You assumed that an some of the bits of an extended address could be interpreted as a valid address and nasty things would happen. But these nasty things will not happen if an IPv4+ packet with extended addresses is constructed to appear invalid to an unaware network driver. So basically you could have saved typing your last two paragraphs.
Your question of where to put the new addresses bits is constructive. The obsoletestream id option seems like a reasonable candidate, providing additional two octets, enough to supply the world's burgeoning address requirements for quite some time. Not a grandious 128 bits like IPv6, but just a modest expansion to take care of our needs basically for you and me, our kids, and our kids kids. That ought to be enough time to come up with some further *sensible* address expansion scheme.
So the principle is this: two extended address bytes are tucked away in places that will not destroy the internet. Such packets are constructed to appear invalid to unaware applications. If a path exists between a source and a destination both supportting extended addresses then the source and destination can communicate in the extended address space. The new byte goes at the least significant end, not the most significant, so that routing databases do not need to change.
See, it could work, and please aim mud at the argument, not your own straw man.
Actually, you can pack extra bits into an IPv4 packet in such a way that a) valid packets using 32 bit addresses remain valid and b) packets with extra address bits are seen as invalid by unaware network drivers. Therefore "they" are *not* all going need to be retrained, only thoes that want to access a wider address range. So how much smoother that would have been rollout wise? We would already be there by now if a sensible approach like this had been adopted instead of the throw out the baby with the bathwater approach we now struggle with. It is by no means impossible that if an extended IPv4 was introduced today, it could exceed IPv6 adoption levels long before IPv6 manages to attract enough web sites to be worth the bother.
Wah wah, we can't figure out where to put some more bits. There must be just no way. Right.
No, that would require every OS to replace the TCP/IP stack. No backwards compatibility and no better off than IPv6.
IPv6 boosters are fond of this talking point, but "no backward compatibility" is a gross exaggeration, or to be precise it is a false dichotomy, when in fact the ability to preserve front end interfaces that are familiar to users and administrators is a form of backward compatibility. But that certainly would not be the only form of backward compabitility offered by an extended IPv4 stack.
You are free to make changes, period. Sun is free to drag their heels about certifying your changed code base as "Java" and that they do. So in general you may not call it Java. Which is where Microsoft went wrong (intentionally) and had to pay out billions. You are not only confused, but you are spreading FUD about what one may or may not do with GPL licensed software.
That was over the trademark. You are confused.