With regards to glibc, 2.3.6 is stone old. RFC 3484 support has matured a lot since Etch:-) Actually you need to go to Debian unstable to find a glibc that's patched to prefer NATed IPv4 over 6to4.
I think my rebuttal of your OS X analysis was a bit unclear, so let me try to make it a bit better. First of all, note that the sentence you're quoted does not mention 6to4 in any way. Second, note the part I wrote about “hits that come through”. The User-Agent is recorded every time the experiment is sent out, not only when it comes in. Thus, you can draw a direct correlation of OS X in the User-Agent string less likely to come back; your analysis was “browsers with Mac OS X in the User-Agent string are more commonly using 6to4 addresses”, which just isn't the same. (It's also true, of course, but the “OS X more often is broken” analysis doesn't depend on that at all.) If you did an experiment which only registered IPv6 hits that actually came through, your criticism would have been valid, but that's not how this was done.
Look at the page -- several Linux distributions (Fedora, Ubuntu, Gentoo, SuSE, Mandriva, Debian) now prefer IPv4 over 6to4 pretty unconditionally (unless you're trying to connect to a 6to4 host, but that's pretty obscure for a web server). The rest only prefer IPv4 over 6to4 when the IPv4 is not NAT-ed.
No, the reality is that getaddrinfo() on most platforms actually follow RFC3484 and prioritize IPv4 over 6to4. (There's a clear distinction in the RFC between 6to4 and other forms of IPv6.) OS X doesn't and uncritically tries IPv6 -- that is, of course, assuming you don't crash into any of the other resolver bugs they introduced in 10.5.
It should be said that if you follow RFC3484 to the letter, 6to4 will be preferred over NAT-ed IPv4. However, that was most likely just an oversight in the standard (the draft revision makes changes to fix that), and most vendors (certainly Microsoft, and most of the major Linux distros, although not glibc upstream yet) has made that change. However, this is moot with regards to OS X, since they don't actually seem to follow RFC3484 in the first place.
You are also wrong in the Airports are the only CPEs that try to enable 6to4 out of the box -- some Linksys models do this, among others. The Airports are, however, most likely the most common. You're also right in that uncritically enabling this is not a good idea; the CPE should at least have done a routability test first.
Finally, you're assuming the statistics here are based only on the User-Agent string on the dualstack hits that come through. They're not -- please read the experiment design more carefully. There is a direct correlation measured between using OS X (as seen in the User-Agent string that fetches the iframe) and inability to fetch the dualstack image. In no way does this result depend on correlation between OS X and 6to4.
Hi. I work (among other things) with IPv6 in Google, although I was only distantly released to this launch (some of my code was used in the monitoring components). It's nice to see we're getting attention:-)
You're entirely right that at the moment, only web search has an AAAA record. (However, with some trickery, you can get several other Google services running too -- just add/etc/hosts lines to the same IP, and you'll probably be able to run Maps, GMail and several others over IPv6.) We don't yet crawl, send or receive e-mail, or support GTalk over IPv6, and we definitely cannot guarantee anything about the uptime of the IPv6 versions of our services. (We've had a few years to make a production-grade IPv4 network, give us some time to make it IPv6-ready too!) Think of it as the first baby step; although we don't have a roadmap published (we almost never talk about future products in Google) I think it's pretty safe to say that there will be more.
Whether there should be services that are not available over IPv4, though, is an entirely different discussion. If you had a cool service and could offer it to the world, would you keep it away from 99.9% of the Internet just because you could?
These are basically the oddest benchmarks I've seen in a while, and nobody even seems to notice. Take for instance the "Cinema 4D R9" test; single Opteron, dual Opteron and dual-core Opteron are basically tied (the singe single-core is even a tiny bit faster!), but dual-core+single-core Opteron is a lot faster... Shouldn't such oddities (and that's not an isolated case) be at least commented on and explained in some sort of way if you want people to buy into your statistics at all? And why didn't they benchmark the rather obvious configuration of two dual-core CPUs?
Then what is the use of the aliases? The main point is: Constant warnings like that are way too annoying to do any good; people start ignoring them in various ways all too soon, if only mentally.
Yeah, that's really nice... except after a while people get really tired of the endless "do you want to delete this? do you want to delete that?" and then go on to add -f to everything. Whoops, suddenly you get no warning when you rm something read-only (and when something is read-only in *nix, it's usually for a good reason)...
There is support in newer Linux kernels for doing just this, only for SCSI (or was it an external patch)? I think it was originally meant for SANs and such, but you could probably get about the effect you want from it if you can find the patch:-)
No, it isn't from expert mode -- OTOH he's consequently picking the manual route where he could have gone for automatic behaviour (at least in the boot process and the partitioning). Most of the screens are non-interactive or can normally be answered by pressing "enter" anyhow, so it's not really that hard:-)
Funny, I've tested a lot (well, at least several) of different RDP solutions, from multiple different clients (both rdesktop, Microsoft's own Remote Desktop Client and dedicated RDP thin clients) to multiple different servers (both Windows XP machines and dedicated Win2000/Win2003 terminal servers), and most of these are just painful to work with, even when I'm virtually alone on the server. (The machines are also mostly administrated by different people, so if there is a severe misconfiguration it must obviously be very easy to make.:-) )
I must admit the Sunrays I've used are rarely ever really loaded, though -- I guess any solution becomes slow under too heavy load.:-)
The most impressive part of the Sunrays is definitely that they don't feel like thin clients. Things zap around like as if you were on a local computer -- in contrast, a terminal server running Windows feels extremely sluggish, even with a powerful server and dedicated thin clients (which is basically what you have with the Sunrays:-) ).
The solution that probably will be taken, after sarge, is multiarch; forget/usr/lib32 and/usr/lib64, think/usr/i486-linux/lib and/usr/x64_64-linux/lib. Solves the problem of both two and more (remember, the IA64 can both emulate IA32 and stuff like HPPA, for instance) architectures, but requires some work that most people probably won't let delay sarge.
Find a few friends and try dibs. Should be one of the cheapest solutions (basically, you'll need about as much storage space as you want to backup yourself -- ideally a bit more), as long as you can find enough friends:-)
No, you would not be forced to install GNOME, you would be forced to install a few GNOME libraries, which would occupy a few megabytes and basically not be in your way otherwise. That is not really a big problem unless you make it one.
Almost sounds like a candidate for simply topologically sorting the entire dependency graph and then processing the tasks in order. You'll eventually end up with several non-connecting subgraphs which can be parallelized; the big remaining problem seems to be prioritizing the tasks if you don't want them to be run equally often, but I'm not really sure if I've understood your problem correctly.:-)
pkgsync. Invaluable for keeping lots of Debian machines in sync with respect to installed packages. (But that's perhaps since I wrote it myself to solve my problems:-P).
Slashdot Mirror
With regards to glibc, 2.3.6 is stone old. RFC 3484 support has matured a lot since Etch :-) Actually you need to go to Debian unstable to find a glibc that's patched to prefer NATed IPv4 over 6to4.
I think my rebuttal of your OS X analysis was a bit unclear, so let me try to make it a bit better. First of all, note that the sentence you're quoted does not mention 6to4 in any way. Second, note the part I wrote about “hits that come through”. The User-Agent is recorded every time the experiment is sent out, not only when it comes in. Thus, you can draw a direct correlation of OS X in the User-Agent string less likely to come back; your analysis was “browsers with Mac OS X in the User-Agent string are more commonly using 6to4 addresses”, which just isn't the same. (It's also true, of course, but the “OS X more often is broken” analysis doesn't depend on that at all.) If you did an experiment which only registered IPv6 hits that actually came through, your criticism would have been valid, but that's not how this was done.
/* Steinar */
Look at the page -- several Linux distributions (Fedora, Ubuntu, Gentoo, SuSE, Mandriva, Debian) now prefer IPv4 over 6to4 pretty unconditionally (unless you're trying to connect to a 6to4 host, but that's pretty obscure for a web server). The rest only prefer IPv4 over 6to4 when the IPv4 is not NAT-ed.
/* Steinar */
No, the reality is that getaddrinfo() on most platforms actually follow RFC3484 and prioritize IPv4 over 6to4. (There's a clear distinction in the RFC between 6to4 and other forms of IPv6.) OS X doesn't and uncritically tries IPv6 -- that is, of course, assuming you don't crash into any of the other resolver bugs they introduced in 10.5.
It should be said that if you follow RFC3484 to the letter, 6to4 will be preferred over NAT-ed IPv4. However, that was most likely just an oversight in the standard (the draft revision makes changes to fix that), and most vendors (certainly Microsoft, and most of the major Linux distros, although not glibc upstream yet) has made that change. However, this is moot with regards to OS X, since they don't actually seem to follow RFC3484 in the first place.
You are also wrong in the Airports are the only CPEs that try to enable 6to4 out of the box -- some Linksys models do this, among others. The Airports are, however, most likely the most common. You're also right in that uncritically enabling this is not a good idea; the CPE should at least have done a routability test first.
Finally, you're assuming the statistics here are based only on the User-Agent string on the dualstack hits that come through. They're not -- please read the experiment design more carefully. There is a direct correlation measured between using OS X (as seen in the User-Agent string that fetches the iframe) and inability to fetch the dualstack image. In no way does this result depend on correlation between OS X and 6to4.
/* Steinar */
Hi,
A few errors here:
/* Steinar */
Hi. I work (among other things) with IPv6 in Google, although I was only distantly released to this launch (some of my code was used in the monitoring components). It's nice to see we're getting attention :-)
You're entirely right that at the moment, only web search has an AAAA record. (However, with some trickery, you can get several other Google services running too -- just add /etc/hosts lines to the same IP, and you'll probably be able to run Maps, GMail and several others over IPv6.) We don't yet crawl, send or receive e-mail, or support GTalk over IPv6, and we definitely cannot guarantee anything about the uptime of the IPv6 versions of our services. (We've had a few years to make a production-grade IPv4 network, give us some time to make it IPv6-ready too!) Think of it as the first baby step; although we don't have a roadmap published (we almost never talk about future products in Google) I think it's pretty safe to say that there will be more.
Whether there should be services that are not available over IPv4, though, is an entirely different discussion. If you had a cool service and could offer it to the world, would you keep it away from 99.9% of the Internet just because you could?
/* Steinar */
- Software engineer, Google Norway
There's a www.ipv6.cisco.com, but it has MTU issues, at least from here. /* Steinar */
These are basically the oddest benchmarks I've seen in a while, and nobody even seems to notice. Take for instance the "Cinema 4D R9" test; single Opteron, dual Opteron and dual-core Opteron are basically tied (the singe single-core is even a tiny bit faster!), but dual-core+single-core Opteron is a lot faster... Shouldn't such oddities (and that's not an isolated case) be at least commented on and explained in some sort of way if you want people to buy into your statistics at all? And why didn't they benchmark the rather obvious configuration of two dual-core CPUs?
/* Steinar */
-f.
/* Steinar */
Then what is the use of the aliases? The main point is: Constant warnings like that are way too annoying to do any good; people start ignoring them in various ways all too soon, if only mentally.
/* Steinar */
Yeah, that's really nice... except after a while people get really tired of the endless "do you want to delete this? do you want to delete that?" and then go on to add -f to everything. Whoops, suddenly you get no warning when you rm something read-only (and when something is read-only in *nix, it's usually for a good reason)...
/* Steinar */
There is support in newer Linux kernels for doing just this, only for SCSI (or was it an external patch)? I think it was originally meant for SANs and such, but you could probably get about the effect you want from it if you can find the patch :-)
/* Steinar */
Am I the only one who's amused at the footer? :-)
Copyright 2005 The Associated Press. All rights reserved. This material may not be published, broadcast, rewritten or redistributed.
/* Steinar */
Already existed in 2002 ;-)
/* Steinar */
No, it isn't from expert mode -- OTOH he's consequently picking the manual route where he could have gone for automatic behaviour (at least in the boot process and the partitioning). Most of the screens are non-interactive or can normally be answered by pressing "enter" anyhow, so it's not really that hard :-)
/* Steinar */
Ubuntu doesn't use Anaconda, you must be confusing it with Progeny.
/* Steinar */
Use Coral (given that they manage to get through at least once and cache the page) :-)
/* Steinar */
You can AFAIK connect any monitor you'd like to them -- the newer Sun Rays even have DVI output.
/* Steinar */
Funny, I've tested a lot (well, at least several) of different RDP solutions, from multiple different clients (both rdesktop, Microsoft's own Remote Desktop Client and dedicated RDP thin clients) to multiple different servers (both Windows XP machines and dedicated Win2000/Win2003 terminal servers), and most of these are just painful to work with, even when I'm virtually alone on the server. (The machines are also mostly administrated by different people, so if there is a severe misconfiguration it must obviously be very easy to make. :-) )
I must admit the Sunrays I've used are rarely ever really loaded, though -- I guess any solution becomes slow under too heavy load. :-)
/* Steinar */
The most impressive part of the Sunrays is definitely that they don't feel like thin clients. Things zap around like as if you were on a local computer -- in contrast, a terminal server running Windows feels extremely sluggish, even with a powerful server and dedicated thin clients (which is basically what you have with the Sunrays :-) ).
/* Steinar */
The solution that probably will be taken, after sarge, is multiarch; forget /usr/lib32 and /usr/lib64, think /usr/i486-linux/lib and /usr/x64_64-linux/lib. Solves the problem of both two and more (remember, the IA64 can both emulate IA32 and stuff like HPPA, for instance) architectures, but requires some work that most people probably won't let delay sarge.
/* Steinar */
The GR is rescinded -- Chris Cheney rescinded his backing of the GR, so it doesn't have enough sponsors.
Of course, if another Debian developer would sponsor it, it would be re-added and the whole process would start anew.
/* Steinar */
Find a few friends and try dibs. Should be one of the cheapest solutions (basically, you'll need about as much storage space as you want to backup yourself -- ideally a bit more), as long as you can find enough friends :-)
/* Steinar */
No, you would not be forced to install GNOME, you would be forced to install a few GNOME libraries, which would occupy a few megabytes and basically not be in your way otherwise. That is not really a big problem unless you make it one.
/* Steinar */
Almost sounds like a candidate for simply topologically sorting the entire dependency graph and then processing the tasks in order. You'll eventually end up with several non-connecting subgraphs which can be parallelized; the big remaining problem seems to be prioritizing the tasks if you don't want them to be run equally often, but I'm not really sure if I've understood your problem correctly. :-)
/* Steinar */
pkgsync. Invaluable for keeping lots of Debian machines in sync with respect to installed packages. (But that's perhaps since I wrote it myself to solve my problems :-P).
/* Steinar */