"You demonstrate the real reason IPv6 isn't mainstream at this point - you've bought into the ignorant naysayers' arguments and know nothing about what IPv6 does, how to use it, or what it offers."
Right, by doing nothing!
What's there to buy into? The problems with IPv6 and its lack of adoption are widely discussed on mailing lists (it's got many warts, the need for 'AAAA' records, needless complexity, etc., etc., and even people who write firewall code and run ISPs for a living will tell you they'd rather run carrier grade NAT. If it is automatic and easy, why haven't we switched yet when so many SOHO routers still have trouble with IPv4!? By doing nothing??
The problem with IPv6 adoption is its design, not politics. It was designed as a replacement instead of IPv4 backward-compatible extension. An administrator and end-users have to go through hoops to make this garbage work, and that's why nobody wants to. Why should/would they? IPv6 should have been designed such that neither administrators, nor end-users would have to do much to upgrade.
The mere presence of kludges like NAT64 and DNS64 (and these have to be proven useful) points to the fact that IPv6 is misdesigned, which is the article's complaint, and it's a rightful one.
I don't agree at all with this article. The author claims that IPv6 should have been designed as an extension to IPv4 so that IPv4 and IPv6 hosts can communicate with each other directly. This is fundamentally impossible. The IPv4 host can only send packets to IP addresses with 32 bit. Any longer number is not understood by the IPv4 host. In order to make this work, the IP stack of every IPv4 host would need to be updated. Guess what has to be done to have IPv4 and IPv6 dual stack? The IP stack of every IPv4 host needs to be updated!
That's right. IPv4 should have been able to talk to IPv6 and vice/versa. Nobody wants to upgrade as long as IPv6 remains useless (because it can't talk to IPv4, and IPv4 can't talk to IPv6). The IPv6 design requires every server administrator to upgrade to IPv6 (but where is the incentive for this massive undertaking?) while it remains "useless" (since few clients have IPv6). Few clients have any incentives to upgrade to IPv6 because very few servers have IPv6. It's a really shitty situation, thanks to a shitty design.
The best thing to do is not get into that situation. For long-running services, for example, you can limit their maximum allowed memory usage with an rlimit() utility like 'softlimit' from 'daemontools'. I also wish I could shut overcommit off on BSDs. At least Linux lets you do that.
Not to be specific about SMT. Assembly too hard? You people haven't heard of Forth, right? Just use ficl, or some other embeddable forth instead of assembler, will save you lots of time. Better debugging too, since forth is interactive.
You may not be aware of this, but soy products contain plant estrogens and other nasties that lower libido, contribute to prostate and other gland problems.
"aid that, I do agree that a good autoconf configuration is very hard to acomplish, mainly when you doing it for the first time."
If autoconf is so problematic and PITA, why use it in the first place? autoconf/make is more trouble than it's worth. Portable makefiles and small portability test programs is the right way to do it.
Some people just don't value complexity enough. These tools are needlessly complex. This page has more info: http://www.ohse.de/uwe/articles/aal.html
It wouldn't be Linux, but it could be one of the exokernel OSes. With an exokernel you can have the UNIX/POSIX compatibility in one of the libraries. This way you get flexibility and performance of an exokernel for new software, and legacy support for the existing UNIX apps.
Exokernels are just hardware multiplexors to support concurrent access, etc., the rest of the system is built from libraries (modules). This way a developer can have a much closer view of the hardware. A typical Unix developer has to deal with Unix APIs and a large, complex and quite an unpredictable (performance-wise) kernel to access the hardware, which trades flexibility and performance for portability (and even writing good portable Unix software is hard in practice). A database or a web server with a specialized file system would be a good example of an app taking advantage of an exokernel I think. A several hundred percent improvement in performance over a legacy Unix server such as the new Apache with a standard Unix FS and kernel wouldn't be surprising.
This is a backwards approach to fix the problem. What software that depends on DNS supports Punycode right now? All that software will be broken. Why not first fix other software first, MTA, MUA, browsers, etc to support UTF-8, then fix the servers?
"You can't just say "Such and such is 8-bit clean, so encode however you want" if "such and such" interprets some characters specially. You need to ensure those characters don't show up in your encoding."
No. It's 8-bit clean, so you can serve UTF-8 data. Other software needs to be fixed, including web browsers.
"A lot of old DNS implementations would choke (and properly so) on UTF-8 encoded DNS names."
Those old implementations need to be fixed instead of forcing new broken standards on the rest of us.
"In the meantime the old DNS and it's anglo-centric presumptions and restrictions are with us for the next few years (or decades, as the case may be). Clearly some people feel the need to live within those restrictions."
Aaaarg!
Those people need to wake up and redesign their broken software instead of introducing yet more brokenness to the standards for work-arounds that (the standards) unfortunately now follow broken implementations. Cough BIND cough.
It's a crappy solution to get rid of the symptoms - 8-bit brokenness of DNS and SMTP servers and web browsers. Those apps should be fixed in the first place to be 8-bit clean so we can finally use something other than ASCII that actually makes sense, such as UTF-8.
Does xinetd support access control per IP address/IP block? Does xinetd set environment variables per IP address/block? Does it chew up CPU time when under load like there is no tomorrow? Does it use a giant configuration file for all services? Does it require you to restart all services to reread the configuration file?
Yes, DJBs init script replacement is a great timesaver for admins, and is therefore the path of least resistance. The run scripts are several times smaller and easier to write than init scripts. Plus pid files is a stupid, unreliable idea.
If you don't like daemontools then try runit or minit. They're GPLed too.
The third argument is actually very good. Can you say modularity? Without modular design you end up with shit like sendmail.
So what's the beef with running two services instead of one on your machine at home? It only takes several minutes to install both, and both are very low on memory usage.
Slashdot Mirror
"You demonstrate the real reason IPv6 isn't mainstream at this point - you've bought into the ignorant naysayers' arguments and know nothing about what IPv6 does, how to use it, or what it offers."
Right, by doing nothing!
What's there to buy into? The problems with IPv6 and its lack of adoption are widely discussed on mailing lists (it's got many warts, the need for 'AAAA' records, needless complexity, etc., etc., and even people who write firewall code and run ISPs for a living will tell you they'd rather run carrier grade NAT. If it is automatic and easy, why haven't we switched yet when so many SOHO routers still have trouble with IPv4!? By doing nothing??
The problem with IPv6 adoption is its design, not politics. It was designed as a replacement instead of IPv4 backward-compatible extension. An administrator and end-users have to go through hoops to make this garbage work, and that's why nobody wants to. Why should/would they? IPv6 should have been designed such that neither administrators, nor end-users would have to do much to upgrade.
MOD PARENT UP.
Mod parent up....
The mere presence of kludges like NAT64 and DNS64 (and these have to be proven useful) points to the fact that IPv6 is misdesigned, which is the article's complaint, and it's a rightful one.
Not so fast:
http://cr.yp.to/djbdns/ipv6mess.html
I don't agree at all with this article. The author claims that IPv6 should have been designed as an extension to IPv4 so that IPv4 and IPv6 hosts can communicate with each other directly. This is fundamentally impossible. The IPv4 host can only send packets to IP addresses with 32 bit. Any longer number is not understood by the IPv4 host. In order to make this work, the IP stack of every IPv4 host would need to be updated. Guess what has to be done to have IPv4 and IPv6 dual stack? The IP stack of every IPv4 host needs to be updated!
That's right. IPv4 should have been able to talk to IPv6 and vice/versa. Nobody wants to upgrade as long as IPv6 remains useless (because it can't talk to IPv4, and IPv4 can't talk to IPv6). The IPv6 design requires every server administrator to upgrade to IPv6 (but where is the incentive for this massive undertaking?) while it remains "useless" (since few clients have IPv6). Few clients have any incentives to upgrade to IPv6 because very few servers have IPv6. It's a really shitty situation, thanks to a shitty design.
IPV6 has implementation issues, AND it has some engineering mistakes built in. it's not that simple.
http://cr.yp.to/djbdns/ipv6mess.html
http://marc.info/?l=openbsd-misc&m=128822984018595&w=2
You don't get it - IPv6 itself is a misengineered piece of crap.
Not so fast:
http://cr.yp.to/djbdns/ipv6mess.html
http://marc.info/?l=openbsd-misc&m=128822984018595&w=2
Agreed. Mod parent up.
The best thing to do is not get into that situation. For long-running services, for example, you can limit their maximum allowed memory usage with an rlimit() utility like 'softlimit' from 'daemontools'. I also wish I could shut overcommit off on BSDs. At least Linux lets you do that.
Not to be specific about SMT. Assembly too hard? You people haven't heard of Forth, right? Just use ficl, or some other embeddable forth instead of assembler, will save you lots of time. Better debugging too, since forth is interactive.
You may not be aware of this, but soy products contain plant estrogens and other nasties that lower libido, contribute to prostate and other gland problems.
"aid that, I do agree that a good autoconf configuration is very hard to acomplish, mainly when you doing it for the first time."
If autoconf is so problematic and PITA, why use it in the first place?
autoconf/make is more trouble than it's worth. Portable makefiles and small portability test programs is the right way to do it.
Some people just don't value complexity enough. These tools are needlessly complex. This page has more info: http://www.ohse.de/uwe/articles/aal.html
It wouldn't be Linux, but it could be one of the exokernel OSes. With an exokernel you can have the UNIX/POSIX compatibility in one of the libraries. This way you get flexibility and performance of an exokernel for new software, and legacy support for the existing UNIX apps.
Exokernels are just hardware multiplexors to support concurrent access, etc., the rest of the system is built from libraries (modules). This way a developer can have a much closer view of the hardware. A typical Unix developer has to deal with Unix APIs and a large, complex and quite an unpredictable (performance-wise) kernel to access the hardware, which trades flexibility and performance for portability (and even writing good portable Unix software is hard in practice). A database or a web server with a specialized file system would be a good example of an app taking advantage of an exokernel I think. A several hundred percent improvement in performance over a legacy Unix server such as the new Apache with a standard Unix FS and kernel wouldn't be surprising.
This is a backwards approach to fix the problem. What software that depends on DNS supports Punycode right now? All that software will be broken. Why not first fix other software first, MTA, MUA, browsers, etc to support UTF-8, then fix the servers?
"You can't just say "Such and such is 8-bit clean, so encode however you want" if "such and such" interprets some characters specially. You need to ensure those characters don't show up in your encoding."
No. It's 8-bit clean, so you can serve UTF-8 data. Other software needs to be fixed, including web browsers.
So does most DNS software support Punicode? If not, then how is Punycode a smooth plan for transition? Fix the problem, not the symptoms.
"A lot of old DNS implementations would choke (and properly so) on UTF-8 encoded DNS names."
Those old implementations need to be fixed instead of forcing new broken standards on the rest of us.
"In the meantime the old DNS and it's anglo-centric presumptions and restrictions are with us for the next few years (or decades, as the case may be). Clearly some people feel the need to live within those restrictions."
Aaaarg!
Those people need to wake up and redesign their broken software instead of introducing yet more brokenness to the standards for work-arounds that (the standards) unfortunately now follow broken implementations. Cough BIND cough.
"djbdns doesn't support unicode either, although it doesn't rely on standard c-libraries, so unicode support might only take a few weeks to add."
djbdns is 8-bit clean. Use UTF-8 all you want right now.
It's a crappy solution to get rid of the symptoms - 8-bit brokenness of DNS and SMTP servers and web browsers. Those apps should be fixed in the first place to be 8-bit clean so we can finally use something other than ASCII that actually makes sense, such as UTF-8.
Erlang is one of the few languages that has lightweight and scalable concurrency, distribution and fault isolation/control built it.
Java is a far worse contender for such a project. Unless you hate functional style.
Does xinetd support access control per IP address/IP block? Does xinetd set environment variables per IP address/block? Does it chew up CPU time when under load like there is no tomorrow? Does it use a giant configuration file for all services? Does it require you to restart all services to reread the configuration file?
Yes, DJBs init script replacement is a great timesaver for admins, and is therefore the path of least resistance. The run scripts are several times smaller and easier to write than init scripts. Plus pid files is a stupid, unreliable idea.
If you don't like daemontools then try runit or minit. They're GPLed too.
If this patch is insufficient, we'll write a different patch.
About DoS. Take a look at BIND DoS advisories.
The third argument is actually very good. Can you say modularity? Without modular design you end up with shit like sendmail.
So what's the beef with running two services instead of one on your machine at home? It only takes several minutes to install both, and both are very low on memory usage.