FWIW I got about 8mbits/s down and 1.2mbits/s up on 4g when I was in Santa Fe Springs CA on my Sprint HTC EVO 4g using the Speedtest.net app.

But the resultant ASCII compatible domain names are just ... ugly: xn--4gbrim.xn----rmckbbajlc6dj7bxne2c.xn--wgbh1c

Yikes. Looking at stuff like that in my zone files every day would probably give me a headache. :p

It's really the combination two problems. 1) The particular OS is configured to prefer 6to4 connectivity to native IPv4, 2) 6to4 isn't supported well on many ISPs for various reasons, and there can also be LAN issues which make 6to4 not work well, or at all. So you could say #2 here is a problem with 6to4 implementation.

Most OSes by default (Windows, and most distros of Linuxes, and BSDs) are configured to prefer using a native IPv4 address before an IPv6 6to4 or Teredo (another automatic tunneling method) address (see RFC 3484) for connections. Apparently OS X isn't. So, when a site has both an IPv4 and an IPv6 address, OS X will prefer the IPv6 address even if the system's IPv6 connectivity is via 6to4. Since 6to4 is often slow, slow to start, or just plain doesn't work on a particular LAN/ISP depending on a plethora of reasons, you'll get timeouts and such. This is one of the reasons why services like Google have a separate domain name for IPv6 based services (ipv6.google.com), instead of just putting up both A and AAAA DNS records.

If using a 6to4 connection, YMMV depending on your LAN configuration, your ISP, routes it receives, proximity to a 6to4 relay, whether the 6to4 anycast address (192.88.99.1) your ISP sees routes to a reasonable place, etc. This is why it's so problematic. There are a lot of variables which can make it either not work at all, or affect its performance. Plus, being a tunneling scheme, performance is already degraded vs. a "native" protocol even if it worked perfectly.

6to4 works by constructing an IPv6 address in a special range reserved for it (2002::/16) which encodes your IPv4 address into the IPv6 address (i.e. if your IPv4 is 192.0.2.10, the 6to4 IPv6 prefix will be 2002:c000:20a::/48, out of which you can subnet and make /64s, etc). The traffic is then sent over a IPv4 6in4 (IPv4 protocol 41) tunnel to the "nearest" 6to4 relay which is reached via the 6to4 anycast address (unless the relay server is configured manually). Unfortunately, many ISPs have this anycast routed to a far away relay. For instance, two friends' separate cable ISPs I tested this on had the traffic routing from eastern Canada and the western USA to a relay server in Sweden!

Traffic from the IPv6 internet to the 6to4 space is routed from its source to the "closest" relay server advertising the 6to4 space in BGP. The relay extracts the IPv4 address from the 6to4 IPv6, and the IPv6 packet is encapsulated in a IPv4 6in4 tunnel packet and sent to the extracted IPv4, which should be the user's 6to4 router. This trip from the origin to the 6to4 relay can also often be a long distance, depending on the origin of the traffic, and then of course the tunnel packets have to make their way over the IPv4 internet to your 6to4 router. Obviously this can make for some pretty serious asymmetric routing which can cause its own problems.

Other problems such as 6in4 being blocked anywhere along the forward or reverse path to the user's 6to4 router will cause it to fail. Also, if the implementation isn't smart enough to know that a particular box is behind a NAT, and constructs a 6to4 IPv6 address based on the NATed address instead of the public IPv4, it will obviously fail, since the return traffic will be sent to a private IPv4 address by the relay server instead of the user's public. I don't know if OS X does this or not. And finally, most firewall/nat boxes with a single public IP shared by many computers can only support a single 6in4 (and therefor 6to4) tunnel behind them, since unless they inspect and track the tunneled IPv6 packets (plus some other implementation enhancements), there's no way it can know which inside host to send return traffic to when it deNATs them.

Note, that none of this is a basic failing of IPv6! The problems here are with implementation details of a well intentioned automatic tunneling method designed to provide IPv6 access to IPv4 only users in a "automatic" manner which doesn't require much user knowledge or intervention. Unfortunately, it didn't "work as intended" based on some of the factors I mentioned above, plus probably others I haven't thought of. :-)

This should explain the problem as well as I understand it. Hope it wasn't too boring. :p

I presume these systems have filters to filter out undesired wavelengths such as UV so that one wouldn't get a sun burn indoors? Or perhaps those wavelengths are attenuated by the delivery system itself. Just curious about this aspect.

Great idea though, although not the first time I've seen it. Systems like this have been around a long time. From fancy sun tracking systems like this, to systems which use fiber optics, to simple sky lights which were once popular in homes. :)

I bought two old mobos with CPUs for $20/ea and a few five port switches they had piled up in a box there for $9.99 each. Unfortunately the two mobos failed pretty quickly (one lasted about a year, the other one is juts flaky from day one). But the switches are still going strong. :P

They re-enable IPv6, or whatever was broken that they had to disable it in the first place gets fixed. Failing that, if they leave it disabled, or have devices for which IPv6 isn't available, there are solutions like Dual-Stack Lite which will allow IPv4 only nodes to still get to the IPv4 internet (IPv4 traffic is tunneled through an IPv4-in-IPv6 tunnel on their CPE router to a Large Scale NAT device at the ISP.

There may be ways for these same users to get to IPv6 only web sites, etc, but I haven't actually looked into that, so I'm not sure. It would have to be some sort of proxy solution, or something like DNS64/NAT64 in reverse. :p

IMHO, these IPv4 only devices should be upgraded, or go away as soon as possible. :-)

The entire 2002::/16 IPv6 block is reserved for 6to4. The address above isn't a full address, it's a 6to4 prefix (more succinctly represented as 2002:5e4b:cf23::/48). Basically, a 6to4 prefix is 2002:[half of your IPv4 in hex]:[2nd half]::/48. The 5e 4b cf 23 is 94.75.207.35 in hex. So the address is correct.

You then take your prefix and use it as /64s on your interface and LAN(s), giving you 16 bits of network field to work with (yes, 65,536 subnets possible). For instance, you could set your 6to4 router's 6to4 interface address to 2002:5e4b:cf23::1/64 (which is shorthand for 2002:5e4b:cf23:0000:0000:0000:0000:0001/64 ... double colon represents a run of zeros). Then you could set your inside LAN prefix to say 2002:5e4b:cf23:1::/64 (2002:5e4b:cf23:0001:0000:0000:0000:0000/64), so the inside LAN IPv6 on your 6to4 router might be 2002:5e4b:cf23:1::1/64 (as in IPv4 I tend to use host number 1 as my router IP). You have the entire 4th quad to use for LANs/subnets (2002:5e4b:cf23:0:: - 2002:5e4b:cf23:ffff::), so you could use any of 'em.

Your 6to4 router will encapsulate your IPv6 traffic in a a 6in4 tunnel packet (IPv4 protocol 41), and send it to the 6to4 tunnel server. If you use the anycast address for 6to4 servers (192.88.99.1) for the tunnel destination, it's supposed to send it to the closest 6to4 server, but unfortunately it's at the mercy of your ISP & BGP where it goes, so sometimes it's best to find the closest one to you and use that instead of the anycast.

Return traffic gets sent back to the IPv4 address encoded in the 2nd and 3rd quads of the IPv6 address. Obviously, if your ISP changes your IPv4 frequently, this could be annoying, since your IPv6 prefix will change with it. One of the reasons I stick with statically configured 6in4 tunnels for my IPv6 connectivity. :)

Also, word to the wise, if you get IPv6 going one way or another, make sure you have ip6tables running and configured on your router, otherwise all your machines will be wide open on the IPv6 internet with no firewall!

I set up a 6to4 on a Canadian friend's router (Eastlink) and it routed to Sweden. A friend in Fremont, CA, USA also routes the anycast to Sweden. My ISP routes it to HE a few hops away. :lol:

IMHO, nothing significant is going to happen until some real pain starts to be experienced as IPv4 addresses near exhaustion. When the cost of IPv4 blocks starts going way up, or they simply become unavailable to businesses hosting servers, or when end users get put behind CGN devices via things like DS-Lite and NAT64/DNS64 because of lack of public IPv4s, then I think we'll really see IPv6 kick into high gear as far as deployment/adoption.

I get my IPv6 connectivity via a tunnel. My ISP doesn't offer it, and when I asked, doesn't have any plans to offer it. Even to static IP customers like myself.

X2. Best for supporting people who are completely clueless about computers and/or networking. All it takes is an app install, and a button click and you're in, even if they're behind a typical NAT firewall. It gets by firewalls (I believe) by using a rendezvous server. It may also use techniques such as hole punching, not sure. I also noticed that if there's a way to direct connect, it'll take that option. You don't even need to get an IP address from the person you are supporting. It uses a short numeric "partner ID" and password which it shows the person so they can read it off to you (it can also send invitations). Been a real lifesaver for "family IT" support.

I agree. Pulling a mobile phone out of your pocket to check the time and (with many of them) having to wake up the display to see it is a pain. I'd rather just raise my wrist and look. My Casio Pathfinder also charges itself (solar), sets its own time via the NIST WWV radio signal ("atomic watch"), has an altimeter, barometer, thermometer, and digital compass, stopwatch w/ split time, countdown timer, alarms, world time, and is water resistant to 100 meters. And it all sits on my wrist. I won't be giving up watches any time soon. :P

Even today things are still going badly. I was able to get through a lot of the training missions, then the auth server went away again.

Basically, when you do a training mission, it's a crap shoot whether the auth server will register the results which will allow you to advance in the game.

Apparently there was a server side patch done today, and things do seem to work a bit faster when the auth server is up.

There are also still plenty of little bugs in the game itself, and who knows how/when they'll be fixed since they shut down the dev studio.

Apparently, development is moving to Redstone Arsenal in Alabama. I'm not sure who's going to be working on it though. They assure us that the game will go on, so I guess they have a team or will hire one.

Even with all the problems, I think it still may have potential. But I'm looking at this as still in beta phase. I'm hoping that by next weekend we'll actually be able to play "normally". :P

Get a grip. The article didn't come to the conclusion of your strawman at all. And your reactionary stereotyping of Americans isn't "helpful" either.

The article merely notes that the philosophies of Boeing and Airbus regarding "humans in the loop" are different, and presumes that it may be a reflection of cultural differences.

Obviously, the companies do have different philosophies, but whether it's really a reflection of American vs. European culture or world view is of course highly debatable. It probably shouldn't have been included in the article, but it is an interesting topic/debate.

But lets set that argument aside and get back to the real topic.

If we presume that the accident was due to faulty data from the pitot/static system, and the software had no way to compensate for this, then wouldn't Boeing's philosophy of allowing pilot override make sense? Obviously, it would in this scenario. But would such overrides ultimately result in more accidents than they prevent?

Personally, I take the Boeing side of the argument. Not because I'm an American or having anything to do with "individual freedom" or whatever, but just because it makes sense to me.

Software has bugs. Hardware can fail. Sensor systems can fail. Even highly redundant systems. I think it's a dangerous to presume that the engineers who designed the systems and software of an aircraft have imagined or anticipated every scenario, every failure mode, every situation. I like the idea of a pilot being able to 'stick & rudder' the aircraft in a situation where the computers and associated systems aren't working right.

Hrm. I was hoping for color ePaper by now. I love the look of ePaper. I've played with the Sony reader and the Kindle and the displays look just like a piece of paper. So much more pleasant to read than an LCD or similar display! But was hoping for color by now.

Sure, the average novel doesn't require color, but any book with illustrations, graphs, photographs or maps (as often found in Sci-Fi/Fantasy novels) would really benefit from color.

I've followed the ePaper tech for a bit and I know color is being worked on. Once it's out, ePaper will be able to display just about anything which can be printed in a book or magazine (albeit with lower resolution).