Sigh. We've been over this countless times. Even if you managed to reclaim all IPv4 ranges that are not being completely used presently, you would buy yourself only a few more months (at current growth rates) until you ran out of addresses again.
I seriously have a hard time trying to understand why so many people on Slashdot seem to be militantly against IPv6. You'd expect more of an allegedly technologically literate audience.
You are right that getting a complete working driver can be problematic for some of the "bigger" stuff like graphics, and perhaps near-impossible without strong vendor commitment; but, as you said yourself, once the driver is mainlined the kernel community will make sure it is not broken by future releases. That alone defeats the misconception that not having a stable ABI somehow creates trouble for vendors because they have to update their drivers every time a new kernel is released.
That said, there are trade-offs involved, and one of them is that some hardware vendors aren't willing to invest the effort required to maintain Linux drivers.
It's not even clear that maintaining Linux drivers entails that much of an effort. History has shown that, if vendors open-source their drivers (or at least document the hardware interfaces), the kernel community will happily take it upon themselves to maintain them.
Hell, how stupid do you have to be, to not see that obviously, there’s a reason we have the foreskin, since otherwise those without it would have long won natural selection.
is faulty logic. The only thing you can infer from the fact that the foreskin survived natural selection is that its presence does not become a disadvantage for human males. It may well be that the foreskin is simply useless(*). Evolution does not remove unneeded features, it just removes those that reduce the survival chance of an individual.
(*) N.B. I do not actually believe it is useless, but I don't think evolution is the right way to argue about it.
Maybe it happens that way to other people. It certainly didn't happen in my case; as far as I can recollect, I just gradually went from a state where I didn't really care about the question into one where I understood the question didn't have to have an answer. The fact that I was exposed to science and scientific thought from an early age surely has something to do with it.
Of course if you can avoid (or get past ) all that, you may eventually lose the fear of not knowing [youtube.com], the moment of genuine acceptance is an experience many have described as "religious" - as in the natural buzz one gets from surviving "a leap of faith".
I find it intriguing that you consider "losing the fear of not knowing" to be akin to a religious experience. Actually, the role of most religions is precisely to provide (irrational) explanations to what we don't know, so that we don't have to face the fact that we don't have answers for them. When Feynman says he's not troubled by "being lost in a mysterious universe without having any purpose, which is the way it really is, as far as [he] can tell", he's not surviving a leap of faith; he simply does not have anything to leap over because, as far as he can tell, there is no precipice in front of him.
(1) Mbps is not an SI standard measurement. Its use is incorrect.
Maybe I'm not getting your point, but what does the SI system have to do with this? Granted, if you have to be formal, the correct unit should be "per second" and not "bits per second", since bits are just the result of a counting process and thus adimensional; but 1 Mbps, as commonly used, is 1e6 bits per second and not 1024^2, as is the case of other computer-related units that use the mega prefix incorrectly.
A valid assumption given the audience. We will be extinct from zombies before technology related jobs become insecure.
I'm not American, so I can't really assess how much that is true. But what about the "becoming unable to work" scenario? (As in, becoming incapacitated by an accident or disease?) Are most Americans with technology-related jobs insured against that scenario? What about the years after they retire? A retirement plan is a form of saving money, after all.
Your analysis only makes sense if you assume you will always have steady income and that it will always be enough to satisfy your needs. What if you become unemployed or unable to work? I would argue that's the first and foremost reason to save money; whether you keep it under the mattress, stashed in a bank account, or invest it in stocks is an entirely separate matter. Naturally, some choices may be better than others, depending on what you believe the future will be.
Routers and end systems would still need to be taught how to speak a new protocol; machines that only know how to construct and decode packets in IPv4 format would be unable to deal with your "extended addresses". What exactly would you gain?
Also, IPv6 is much more than just an extension of the addressing space. I won't bother listing all the niceties here since it has been done before (and you can find them easily). But to think that everything IPv6 has to offer is a lot more addresses is extremely narrow-minded.
I've just realized that my example is wrong, because it seems to me that for the shortest-path version of TSP you can get away with a binary search over all the possible lengths (since the length of a path is upper bounded in a finite graph), which is just a (polynomial-time) iteration over the decision problem. I'm fairly certain that my comment on the differing complexities is true in general, but I'd rather someone else chime in with a correct example:)
You're entirely correct, but I would add the following. You can rephrase non-decision problems as decision problems, but the computational complexity of the two versions may not be the same. As an example, even if you had a polynomial-time algorithm for the decision problem version of TSP, it would not be obvious at all whether you could use it to solve the shortest-path version in polynomial time, since the number of distinct path lengths in a graph is exponential in the general case.
Because of Occam's Razor. An extraordinary theory requires extraordinary evidence. Guess which theory is the most extraordinary (and the one with less evidence to support it) in this case.
Right. There are commonly error checking at the link layer below IP as well as in the transport layer on top of IP. And both of them will cover the IP header. It was considered redundant to have three separate layers compute checksums of the IP header, thus it was removed. It never covered anything but the header itself.
Also, there is something important to be said about link-layer error detection: it is not end-to-end. If corruption occurs while the packet is being handled by a router (as opposed to while it is traversing a link), the link-layer won't be able to detect it.
A few other changes were made at the same time to make up for the loss of the IP checksum. For UDP the checksum was made mandatory. It used to be optional, an IPv4 packet can carry UDP with a checksum of 0, and it will be considered valid for any data. Unlike UDP and TCP, the checksum in ICMP didn't cover any of the header bytes in IPv4. In IPv6 this was changed such that the ICMPv6 checksum also covers the IP addresses. If you for some reason don't like the fact that you are now being forced to checksum all data send over UDP, you can develop new applications using UDPlite. With UDPlite the checksum is mandatory, but it does not have to cover all the data. It covers the IP and UDP headers and as many of the data bytes as you like it to.
And one might point out the importance of always checking the IP headers end-to-end: it provides protection against misrouted packets caused by header corruption that passes undetected at the link layer. I suppose that's why the ICMPv6 checksum was changed to also include the IP header, as well as why even UDP-lite always checks the IP header, if anything else; they compensate for the missing header checksum in IPv6.
In the end those checksums are not really great. It turns out 16 bits of checksum is not enough to catch all the random errors that do occur. The probability that all 16 bits do by chance match when corruption happened is a bit too high. So in many cases you will make use of stronger checksums at a higher layer, in many cases even a cryptographic message-authentication-code. You can use MD5 at the TCP layer. At higher layers there are even more options.
Yes, I would agree with that. Checksums were nice back when you didn't have that much computing power to waste on protocol overhead, but better error detection mechanisms are now feasible at a fraction of the cost. I do wonder, though, how many people actually use TCP-MD5 these days?
Not quite. In IPv4, both the network layer (IP) and transport layer (TCP) detect transmission errors via checksums. In IPv6, the network layer does not actually detect errors at all (I believe this is so in order to speed up routers by not having them calculate checksums). There's only the TCP checksum and whatever link-layer error detection you have protecting you from corrupted packets.
Sure, the filesystem itself does journalling, which translates into additional writes. But if no application writes anything to disk, the state of the filesystem does not change; thus, pretty much by definition, there is nothing for NTFS to journal during those periods. On the other hand, if you are going to write something anyway because an application requests so, the additional cost of journalling (either in terms of I/O performance or flash wear) is probably not that much. Hence my reasoning that poorly designed applications are the real culprit for poor I/O performance.
Regarding defragmentation, you might have a point; I'm not aware of how NTFS defragmentation works.
I wonder if that is really NTFS's problem. There is no reason for a filesystem (even a poorly designed one) to be writing sectors to disk all the time unless running programs request the OS to do so. The most likely culprits are poorly-designed Windows applications that write to disk all the time.
Indeed. There is nothing empirical about Computer Science, since it's just a branch of mathematics. Perhaps a more apt name would be "Computer Theory", since this seems to be a pattern for fields of mathematics (Graph Theory, Group Theory, etc.)
Indeed, you did not. Blame it on the ever decreasing quality of Slashdot comments; these days, some people here actually mean stuff like that when they say it. I do apologise for misjudging your intelligence.
FWIW, "more particles than the atoms in the computer" would be impossible with current technology since (presumably) you'd need to store at least one bit of state per particle, and current computers need more than an atom to store a single bit.
"Computing teaching" is correct (despite sounding unusual) if you assume "computing" is a noun and not a verb (as in "maths teaching", i.e. the act of teaching maths). But it does lend itself to confusion.
Slashdot Mirror
Sigh. We've been over this countless times. Even if you managed to reclaim all IPv4 ranges that are not being completely used presently, you would buy yourself only a few more months (at current growth rates) until you ran out of addresses again.
I seriously have a hard time trying to understand why so many people on Slashdot seem to be militantly against IPv6. You'd expect more of an allegedly technologically literate audience.
Except for the one-time pad.
Surely you mean Mr Russell?
You are right that getting a complete working driver can be problematic for some of the "bigger" stuff like graphics, and perhaps near-impossible without strong vendor commitment; but, as you said yourself, once the driver is mainlined the kernel community will make sure it is not broken by future releases. That alone defeats the misconception that not having a stable ABI somehow creates trouble for vendors because they have to update their drivers every time a new kernel is released.
It's not even clear that maintaining Linux drivers entails that much of an effort. History has shown that, if vendors open-source their drivers (or at least document the hardware interfaces), the kernel community will happily take it upon themselves to maintain them.
I actually agree with you, but the sentence
is faulty logic. The only thing you can infer from the fact that the foreskin survived natural selection is that its presence does not become a disadvantage for human males. It may well be that the foreskin is simply useless(*). Evolution does not remove unneeded features, it just removes those that reduce the survival chance of an individual.
(*) N.B. I do not actually believe it is useless, but I don't think evolution is the right way to argue about it.
Maybe it happens that way to other people. It certainly didn't happen in my case; as far as I can recollect, I just gradually went from a state where I didn't really care about the question into one where I understood the question didn't have to have an answer. The fact that I was exposed to science and scientific thought from an early age surely has something to do with it.
I find it intriguing that you consider "losing the fear of not knowing" to be akin to a religious experience. Actually, the role of most religions is precisely to provide (irrational) explanations to what we don't know, so that we don't have to face the fact that we don't have answers for them. When Feynman says he's not troubled by "being lost in a mysterious universe without having any purpose, which is the way it really is, as far as [he] can tell", he's not surviving a leap of faith; he simply does not have anything to leap over because, as far as he can tell, there is no precipice in front of him.
Maybe I'm not getting your point, but what does the SI system have to do with this? Granted, if you have to be formal, the correct unit should be "per second" and not "bits per second", since bits are just the result of a counting process and thus adimensional; but 1 Mbps, as commonly used, is 1e6 bits per second and not 1024^2, as is the case of other computer-related units that use the mega prefix incorrectly.
I'm not American, so I can't really assess how much that is true. But what about the "becoming unable to work" scenario? (As in, becoming incapacitated by an accident or disease?) Are most Americans with technology-related jobs insured against that scenario? What about the years after they retire? A retirement plan is a form of saving money, after all.
Your analysis only makes sense if you assume you will always have steady income and that it will always be enough to satisfy your needs. What if you become unemployed or unable to work? I would argue that's the first and foremost reason to save money; whether you keep it under the mattress, stashed in a bank account, or invest it in stocks is an entirely separate matter. Naturally, some choices may be better than others, depending on what you believe the future will be.
In RIM's case, I seriously doubt step 3 is profit...
Routers and end systems would still need to be taught how to speak a new protocol; machines that only know how to construct and decode packets in IPv4 format would be unable to deal with your "extended addresses". What exactly would you gain?
Also, IPv6 is much more than just an extension of the addressing space. I won't bother listing all the niceties here since it has been done before (and you can find them easily). But to think that everything IPv6 has to offer is a lot more addresses is extremely narrow-minded.
I've just realized that my example is wrong, because it seems to me that for the shortest-path version of TSP you can get away with a binary search over all the possible lengths (since the length of a path is upper bounded in a finite graph), which is just a (polynomial-time) iteration over the decision problem. I'm fairly certain that my comment on the differing complexities is true in general, but I'd rather someone else chime in with a correct example :)
You're entirely correct, but I would add the following. You can rephrase non-decision problems as decision problems, but the computational complexity of the two versions may not be the same. As an example, even if you had a polynomial-time algorithm for the decision problem version of TSP, it would not be obvious at all whether you could use it to solve the shortest-path version in polynomial time, since the number of distinct path lengths in a graph is exponential in the general case.
Magic is claiming that a creator just appeared for no reason out of nothing and started moving and doing shit.
Do you get my point?
Because of Occam's Razor. An extraordinary theory requires extraordinary evidence. Guess which theory is the most extraordinary (and the one with less evidence to support it) in this case.
Also, there is something important to be said about link-layer error detection: it is not end-to-end. If corruption occurs while the packet is being handled by a router (as opposed to while it is traversing a link), the link-layer won't be able to detect it.
And one might point out the importance of always checking the IP headers end-to-end: it provides protection against misrouted packets caused by header corruption that passes undetected at the link layer. I suppose that's why the ICMPv6 checksum was changed to also include the IP header, as well as why even UDP-lite always checks the IP header, if anything else; they compensate for the missing header checksum in IPv6.
Yes, I would agree with that. Checksums were nice back when you didn't have that much computing power to waste on protocol overhead, but better error detection mechanisms are now feasible at a fraction of the cost. I do wonder, though, how many people actually use TCP-MD5 these days?
Thanks a lot for your reply!
Not quite. In IPv4, both the network layer (IP) and transport layer (TCP) detect transmission errors via checksums. In IPv6, the network layer does not actually detect errors at all (I believe this is so in order to speed up routers by not having them calculate checksums). There's only the TCP checksum and whatever link-layer error detection you have protecting you from corrupted packets.
Sure, the filesystem itself does journalling, which translates into additional writes. But if no application writes anything to disk, the state of the filesystem does not change; thus, pretty much by definition, there is nothing for NTFS to journal during those periods. On the other hand, if you are going to write something anyway because an application requests so, the additional cost of journalling (either in terms of I/O performance or flash wear) is probably not that much. Hence my reasoning that poorly designed applications are the real culprit for poor I/O performance.
Regarding defragmentation, you might have a point; I'm not aware of how NTFS defragmentation works.
I wonder if that is really NTFS's problem. There is no reason for a filesystem (even a poorly designed one) to be writing sectors to disk all the time unless running programs request the OS to do so. The most likely culprits are poorly-designed Windows applications that write to disk all the time.
Indeed. There is nothing empirical about Computer Science, since it's just a branch of mathematics. Perhaps a more apt name would be "Computer Theory", since this seems to be a pattern for fields of mathematics (Graph Theory, Group Theory, etc.)
Indeed, you did not. Blame it on the ever decreasing quality of Slashdot comments; these days, some people here actually mean stuff like that when they say it. I do apologise for misjudging your intelligence.
FWIW, "more particles than the atoms in the computer" would be impossible with current technology since (presumably) you'd need to store at least one bit of state per particle, and current computers need more than an atom to store a single bit.
"Computing teaching" is correct (despite sounding unusual) if you assume "computing" is a noun and not a verb (as in "maths teaching", i.e. the act of teaching maths). But it does lend itself to confusion.