It's not a question of whether it's possible to start from nothing and be well off. It certainly is, for a few select people. The question you should ask yourself is how many succeed (preemptive addendum: even if you only consider those who try). A lot of people fall prey to confirmation bias when they discuss capitalism: they see ten people that succeeded, but not the ten thousand that didn't — because no one sings the story of those that failed.
They could have implemented VirtualStore as early as Windows 95 as a stop-gap measure for write-anywhere programs. Sure, it's an approach with its own problems, but sometimes you have to trade something in for security.
low-level hardware access for sound, graphics, etc
Trap the hardware interrupts in software, then emulate the low-level I/O routines at the OS level. Possibly with a performance penalty, but again: you have to decide where your priorities are.
And yes, I know hindsight is 20/20. Maybe not all these things were obvious back then. I still think that, security-wise, Microsoft spent the whole 90s and a good part of the 00s asleep at the wheel.
I actually agree with you in that the first Unix implementations had a number of security holes, and that the so-called iron-clad Unix security only came many years later with the accumulated experience of dealing with those holes. But I take trouble with the following claim:
to this date, *nix does not support well the concept of application ownership of a file which leads to programs requiring their own user account, which is another kludge.
Would you care to explain what is kludgey in using the uid namespace to also provide per-application ownership? Arguably, it is simply a matter of implementation simplicity; you have a single namespace instead of two. That a given uid might not correspond to an actual, physical user seems to be more of a semantic problem than a design one.
I'm sorry, but getting paid for your work, in a world where money is necessary to survive, is NOT morally wrong.
I'm no hardline stallmanite, but what does this have to do with free software? Nothing in the definition of free software precludes you from making money through it. At most, it forbids certain ways of making money with it.
Actually, the problem is that "free market", as currently (ab)used, is an overloaded term that stands for two completely different concepts: absence of regulation, and perfect competition with no barriers to entry nor asymmetric information. That the second is a necessary consequence of the first is a highly contentious point, because, contrary to what libertarians believe, the state is not the only entity that is able to distort a market.
My hypothesis is this: the more high-level information you can give your compiler, the better it can optimize your programs.
It is worthwhile to point out that GCC actually adds some non-standard facilities to the C language that enable the programmer to do so; witness, for instance, the use of the likely() and unlikely() macros (the actual GCC builtins have different names) in the Linux kernel to nudge the compiler into optimizing for the common case of an if statement.
Even if your argument held water (which I don't think it does in a properly managed network), it seems rather silly to trade global end-to-end connectivity and other IPv6 niceties such as autoconfiguration for the convenience of being able to memorize network addresses or pass them over the phone.
Except that in this case you are creating a market to deal with artificial scarcity, which is just plain evil. Remember, there is no physical reason for there being only 2^32 addresses. Only the completely accidental fact that someone picked the number 32 some decades ago.
I believe the reason the host part has so many bits does not have to do with expected subnet size, but rather serves to ensure the probability that two autoconfiguring hosts coincidentally choose the same address is kept low.
I never said that the embassy guards do not have the authority to retaliate. I'm just contesting the notion that the actions of independent citizens translate as a formal declaration by their nation state. The United States, of course, are free to interpret such an attack as an act of war and declare war on Libya; but to say that Libya have declared war on the United States when the embassy was attacked flies in the face of international laws and conventions.
citizens of Libya technically declared war on the US.
Citizens do not declare war. States do.
Are you suggesting that, if a bunch of Americans vandalized a foreign embassy on US soil, that shold technically count as a declaration of war on that country by the United States of America?
A bit late in the discussion, but still. I have it you never implemented a TCP/IP stack on a barely capable embedded device, or you would understand why I call v6 a full bloat protocol rewrite.
Indeed, I haven't. I take it you have. Could you elaborate? Is the bloat due to having to support a dual stack on a tiny device, or are there concrete features/quirks in IPv6 that are difficult to implement in a constrained device? Pointers would be okay; I searched the web but nothing terribly relevant turned up.
You're right, but no solution is perfect. In this case I would be totally supportive if governments forced ISPs to deploy IPv6, but I would really like their involvement to end right there. It's complicated, I know.
Geez, why would you set up a market over such a resource as Internet addresses, which are scarce only by accident (i.e., the fact that someone chose the number 32 sometime in the past) and not by sheer necessity? I can understand a market as a way to efficiently allocate resources in the face of scarcity, but artificial scarcity is just evil.
Here's a hint: maybe not all problems in the world can be solved efficiently by a free market. Maybe in some cases you need some kind of external intervention to make sure the difficult decisions are made...
It becomes particularly not-so-funny when you have to constantly make the distinction between American and European billions (as is the case e.g. with money). If everyone agreed on using the giga and tera prefixes, that would never be a problem.
Well the speed of light can be measured fairly precisely
Actually, the speed of light is not the result of a measurement, because the meter is defined in terms of the speed of light. The speed of light, by definition, is always 299,792,458 metres per second.
They did do that (as one of the other replies points out). What I think you fail to grasp is that, no matter how "backwards-compliant" your extension is, you still have to teach everyone how to talk to the new-fangled addressed outside the original space, not just the machines that happen to be assigned the new-fangled addresses.
I'm not at all against IPv6. My perspective is just one of speculative curiosity: If IPv4 addresses were used at 100% efficiency (with inefficiency being defined as malware/botnets/spammers) how much longer would they have?
Okay, I apologise if my post came out as harsh (since you are not against IPv6, it wasn't really directed to you).
In regard to your question, I propose the following thought experiment: it seems at the point of IPv4 address exhaustion, IANA had been burning through about twenty/8's per year (source). Now, I know that addresses allocated by IANA are not immediately used by the RIRs, but I think we can safely assume that it's only a lag effect, since RIRs are not allowed to request more addresses from IANA unless they have used past allocations to a certain degree. So suppose that all 256/8's in the IPv4 addressing space were usable (some are not, for various reasons) and that, due to address squatting, spammers or whatnot, half of the currently used addresses could reasonably be reclaimed. There are rougly 221/8's usable for general-purpose addressing, so we are talking about roughly 110/8's worth to be reclaimed. At an allocation rate of 20/8's per year, you would be buying little more than 5 years. And, obviously, the fraction of reclaimable space is likely much smaller.
I should note that the crux of the above argument is that the allocation rate never slows down. (In fact, it has been increasing along the years.) We all should know that exponential growth processes cannot last forever in a finite world. However, considering that the world's population almost doubles the size of the IPv4 addressing space, and that in some regions of the globe there is already more than a single device per inhabitant connected to the Internet, I seriously doubt we are anywhere near the point where the growth curve flattens. There is a real need for a much larger address space.
One final thought: an Internet where every single IPv4 address does not go to waste is probably difficult to achieve for technical reasons. IP addresses do not serve only to identify particular machines; they are used to route packets to them, and the way we do that is by having the addresses of "nearby" machines share a common prefix. That way, routers on the Internet only have to store a handful (some thousands, perhaps) of prefixes in their routing tables, instead of a dedicated entry for every machine connected to the Internet. So there is also a case for a larger addressing space in that it allows you to keep the Internet routing table size small by making sure that you can still assign "nearby" addresses to "nearby" machines throughout the future.
I don't know where you get that IPv6 is a "full protocol rewrite" of IPv4. For the most part it does exactly the same as IPv4 except with more address bits, and in some cases it even simplifies its predecessor (e.g. no IP header checksum). Any person able to understand or implement IPv4 ought to be able to understand or implement IPv6, because there are no fundamentally new concepts. (I would venture that most people who criticise IPv6 don't even understand fully what IPv4 does, so they don't really know what they're talking about.)
I am also interested in hearing what a "simple extension of IPv4" would be, in your opinion. Odds are you will propose something to the tune of keeping the original IPv4 header and semantics, and tacking some extra address bits at the end. Except in that case you'd still have to teach every fucking router and end system in the world how to decode the new-fangled packets, which is not any different from IPv6 from a cost perspective. You might as well do it right and fix some of IPv4's warts (header checksum, autoconfiguration, node mobility, etc) instead of applying a band-aid solution.
NAT is hardly an acceptable extension of the IPv4 addressing space because NATted clients do not have the same capabilities of non-NATted clients. (Yes, I know about hole-punching techniques; they do not solve the problem fully, and in respect to what they do, they are defeated by many real-world NAT implementations.) If you don't understand the importance of this, I encourage you to read about the end-to-end principle. Finally, it is ludicrous to suggest that implementing NAT at the scale that will be required by the ever-growing Internet would be any cheaper than IPv6. Carrier-grade NAT doesn't exactly come for free.
Slashdot Mirror
It's not a question of whether it's possible to start from nothing and be well off. It certainly is, for a few select people. The question you should ask yourself is how many succeed (preemptive addendum: even if you only consider those who try). A lot of people fall prey to confirmation bias when they discuss capitalism: they see ten people that succeeded, but not the ten thousand that didn't — because no one sings the story of those that failed.
They could have implemented VirtualStore as early as Windows 95 as a stop-gap measure for write-anywhere programs. Sure, it's an approach with its own problems, but sometimes you have to trade something in for security.
Trap the hardware interrupts in software, then emulate the low-level I/O routines at the OS level. Possibly with a performance penalty, but again: you have to decide where your priorities are.
And yes, I know hindsight is 20/20. Maybe not all these things were obvious back then. I still think that, security-wise, Microsoft spent the whole 90s and a good part of the 00s asleep at the wheel.
I actually agree with you in that the first Unix implementations had a number of security holes, and that the so-called iron-clad Unix security only came many years later with the accumulated experience of dealing with those holes. But I take trouble with the following claim:
Would you care to explain what is kludgey in using the uid namespace to also provide per-application ownership? Arguably, it is simply a matter of implementation simplicity; you have a single namespace instead of two. That a given uid might not correspond to an actual, physical user seems to be more of a semantic problem than a design one.
I'm no hardline stallmanite, but what does this have to do with free software? Nothing in the definition of free software precludes you from making money through it. At most, it forbids certain ways of making money with it.
The question is whether openness is possible (or rather: assured) in a free market without regulation.
Actually, the problem is that "free market", as currently (ab)used, is an overloaded term that stands for two completely different concepts: absence of regulation, and perfect competition with no barriers to entry nor asymmetric information. That the second is a necessary consequence of the first is a highly contentious point, because, contrary to what libertarians believe, the state is not the only entity that is able to distort a market.
It is worthwhile to point out that GCC actually adds some non-standard facilities to the C language that enable the programmer to do so; witness, for instance, the use of the likely() and unlikely() macros (the actual GCC builtins have different names) in the Linux kernel to nudge the compiler into optimizing for the common case of an if statement.
Even if your argument held water (which I don't think it does in a properly managed network), it seems rather silly to trade global end-to-end connectivity and other IPv6 niceties such as autoconfiguration for the convenience of being able to memorize network addresses or pass them over the phone.
The grandparent is not talking about static addresses, he/she is talking about public addresses which are not the same thing.
Except that in this case you are creating a market to deal with artificial scarcity, which is just plain evil. Remember, there is no physical reason for there being only 2^32 addresses. Only the completely accidental fact that someone picked the number 32 some decades ago.
And how is this any different from IPv4, where the residence gets a public address from the ISP? Unless your ISP is using carrier-grade NAT, that is.
I believe the reason the host part has so many bits does not have to do with expected subnet size, but rather serves to ensure the probability that two autoconfiguring hosts coincidentally choose the same address is kept low.
Try reading what I said again.
I never said that the embassy guards do not have the authority to retaliate. I'm just contesting the notion that the actions of independent citizens translate as a formal declaration by their nation state. The United States, of course, are free to interpret such an attack as an act of war and declare war on Libya; but to say that Libya have declared war on the United States when the embassy was attacked flies in the face of international laws and conventions.
Citizens do not declare war. States do.
Are you suggesting that, if a bunch of Americans vandalized a foreign embassy on US soil, that shold technically count as a declaration of war on that country by the United States of America?
And that was precisely my point.
Indeed, I haven't. I take it you have. Could you elaborate? Is the bloat due to having to support a dual stack on a tiny device, or are there concrete features/quirks in IPv6 that are difficult to implement in a constrained device? Pointers would be okay; I searched the web but nothing terribly relevant turned up.
You're right, but no solution is perfect. In this case I would be totally supportive if governments forced ISPs to deploy IPv6, but I would really like their involvement to end right there. It's complicated, I know.
Geez, why would you set up a market over such a resource as Internet addresses, which are scarce only by accident (i.e., the fact that someone chose the number 32 sometime in the past) and not by sheer necessity? I can understand a market as a way to efficiently allocate resources in the face of scarcity, but artificial scarcity is just evil.
Here's a hint: maybe not all problems in the world can be solved efficiently by a free market. Maybe in some cases you need some kind of external intervention to make sure the difficult decisions are made...
It becomes particularly not-so-funny when you have to constantly make the distinction between American and European billions (as is the case e.g. with money). If everyone agreed on using the giga and tera prefixes, that would never be a problem.
Actually, the speed of light is not the result of a measurement, because the meter is defined in terms of the speed of light. The speed of light, by definition, is always 299,792,458 metres per second.
They did do that (as one of the other replies points out). What I think you fail to grasp is that, no matter how "backwards-compliant" your extension is, you still have to teach everyone how to talk to the new-fangled addressed outside the original space, not just the machines that happen to be assigned the new-fangled addresses.
Okay, I apologise if my post came out as harsh (since you are not against IPv6, it wasn't really directed to you).
In regard to your question, I propose the following thought experiment: it seems at the point of IPv4 address exhaustion, IANA had been burning through about twenty /8's per year (source). Now, I know that addresses allocated by IANA are not immediately used by the RIRs, but I think we can safely assume that it's only a lag effect, since RIRs are not allowed to request more addresses from IANA unless they have used past allocations to a certain degree. So suppose that all 256 /8's in the IPv4 addressing space were usable (some are not, for various reasons) and that, due to address squatting, spammers or whatnot, half of the currently used addresses could reasonably be reclaimed. There are rougly 221 /8's usable for general-purpose addressing, so we are talking about roughly 110 /8's worth to be reclaimed. At an allocation rate of 20 /8's per year, you would be buying little more than 5 years. And, obviously, the fraction of reclaimable space is likely much smaller.
I should note that the crux of the above argument is that the allocation rate never slows down. (In fact, it has been increasing along the years.) We all should know that exponential growth processes cannot last forever in a finite world. However, considering that the world's population almost doubles the size of the IPv4 addressing space, and that in some regions of the globe there is already more than a single device per inhabitant connected to the Internet, I seriously doubt we are anywhere near the point where the growth curve flattens. There is a real need for a much larger address space.
One final thought: an Internet where every single IPv4 address does not go to waste is probably difficult to achieve for technical reasons. IP addresses do not serve only to identify particular machines; they are used to route packets to them, and the way we do that is by having the addresses of "nearby" machines share a common prefix. That way, routers on the Internet only have to store a handful (some thousands, perhaps) of prefixes in their routing tables, instead of a dedicated entry for every machine connected to the Internet. So there is also a case for a larger addressing space in that it allows you to keep the Internet routing table size small by making sure that you can still assign "nearby" addresses to "nearby" machines throughout the future.
I don't know where you get that IPv6 is a "full protocol rewrite" of IPv4. For the most part it does exactly the same as IPv4 except with more address bits, and in some cases it even simplifies its predecessor (e.g. no IP header checksum). Any person able to understand or implement IPv4 ought to be able to understand or implement IPv6, because there are no fundamentally new concepts. (I would venture that most people who criticise IPv6 don't even understand fully what IPv4 does, so they don't really know what they're talking about.)
I am also interested in hearing what a "simple extension of IPv4" would be, in your opinion. Odds are you will propose something to the tune of keeping the original IPv4 header and semantics, and tacking some extra address bits at the end. Except in that case you'd still have to teach every fucking router and end system in the world how to decode the new-fangled packets, which is not any different from IPv6 from a cost perspective. You might as well do it right and fix some of IPv4's warts (header checksum, autoconfiguration, node mobility, etc) instead of applying a band-aid solution.
NAT is hardly an acceptable extension of the IPv4 addressing space because NATted clients do not have the same capabilities of non-NATted clients. (Yes, I know about hole-punching techniques; they do not solve the problem fully, and in respect to what they do, they are defeated by many real-world NAT implementations.) If you don't understand the importance of this, I encourage you to read about the end-to-end principle. Finally, it is ludicrous to suggest that implementing NAT at the scale that will be required by the ever-growing Internet would be any cheaper than IPv6. Carrier-grade NAT doesn't exactly come for free.