IIRC, it doesn't say that it's charging, but it will trickle-charge. The problem is that USB ports don't provide enough power for a device that current-hungry to charge from. My ASUS Transformer Pad Inifinity is the same way: It doesn't say it's charging when I plug it into my computer, but it will slowly charge if I'm not using it (1% every 10 minutes or so).

The battery in my 2-year-old iPhone 4 still lasts almost as long as it did new. I go through a day which includes some web browsing and app usage and it's still only at 70% when I get home.

It'd be the perfect cover in case the actual thing gets leaked!

As an applicant, you are not yet an employee. If they want to demand that I give them that information after I am an employee, and I refuse, I would not be surprised if there can be a wrongful termination lawsuit.

I'm switching to Sprint as soon as I can afford the initial investment, and/or my AT&T contract expires. Though, my AT&T phone actually works in my apartment now, so it isn't as pressing of an issue...

> Plus, don't most lights go to flashing yellow (= 4 way stop) at off-peak times?

Traffic lights on side streets, or business intersections, perhaps. But not all lights. And it'd be flashing red if it'd be a 4-way stop. Most of the ones I see do flashing red to the smaller road and flashing yellow to the through road.

I was able to dual-boot Android on my iPhone 3G a year and a half ago. It was pretty bad, but it ... functioned.

> HDMI allows sending audio over the same cable, DVI does not.

Actually, you can get audio out of a DVI port on a video card. I have a GTX570, with one of its DVI ports connected to an HDMI port on my TV with a DVI to HDMI cable, and audio routes over that cable just fine. I was actually surprised the first time it happened, for I thought the same as you.

You still have to actually dial "911" after hitting the emergency call button. All it does is give you a dialpad (which pretty much only lets you dial 911, or whatever the local emergency number is).

The trash icon changes into an eject icon when you're dragging an umountable volume. It's still undiscoverable, but it isn't quite as silly.

You have higher cognitive ability, you realize how the world runs, you get depressed. Not the other way 'round.

or try http://springrts.com/

Open source RTS engine which formed around the idea of being a '3d TA' . There's a bunch of variations of TA for it and some nice other games.

A lot of old TA and SupCom players come to spring.

less polish more game.

I've found that the combination of a PC and a Wii serves my gaming needs excellently. The Wii has an excellent set of casual games (Wii Sports, Wii Fit, Mario Kart, Super Smash Bros, etc) that I can pick up and play with my gf whenever we have a few minutes to kill. The PC is great for serious gaming. A keyboard and mouse are, IMO, the best input controllers ever and the graphics on a mid-range gaming PC beat those on a 360 or PS3. I also like the fact that my games are all $50 (and not $60) new at retail.

Of course, everyone is different and I do miss out on a few 360 and PS3 exclusives, but nothing has come out for either system that has been that compelling for me.

I think when people say the Wii has "no good games", they mean it doesn't have good games like GTA, CoD, WoW, and other TLAs. But it has a ton of quick and fun, easy to learn, easy to play games that are great to play with friends, coworkers, kids, gf's, non-gamers etc.

Firewalls are capable of providing all of the positive benefits of NAT (transient traffic flow approval instead of mapping for example, blocking traffic not originated from the LAN, etc) save obfuscating the source address. Obfuscating the source address isn't particularly relevant from an attack perspective given that the entire LAN is still protected by the same Firewall process, NAT or not.

For example: you could NAT your LAN in 192.168.10.x space behind IP 1.2.3.4 .. you connect to shady.com port 80 sport 192.168.10.101:2000, NAT/firewall allocates 1.2.3.4:3000 for you. Shady sees all the traffic coming from 1.2.3.4:3000, but has no way (short of client-side malware) to know that maps to 192.168.10.101; nor can Shady care since all access to 192.168.10.101 is mediated by 1.2.3.4. Shady.com might try to port scan 1.2.3.4, and see any port forwards your entire LAN uses in one swoop, try to exploit them if possible. Moral: make sure you know what you are doing when you port forward.

Or, if you use IPv6 for your LAN, let's say you are allocated 1:2:3::/112. No need to NAT it, so you just firewall behind your gateway, let's say 1:2:3::4. You connect to shady.com port 80, sport [1:2:3::101]:2000. Firewall doesn't have to allocate a damned thing for you, but instead records the flow for [1:2:3::101]:2000 shady.com:80 as established from within the LAN and thus authorized. Shady sees all the traffic coming from [1:2:3::101]:2000, but it's not relevant since all access to 1:2:3::101 is still mediated by the firewall at gateway 1:2:3::4. Shady.com can port scan 1:2:3::101 if it likes, but won't see any open ports if you only allow LAN established traffic, or else sees your whitelisted ports for that IP only (instead of your entire LAN). Just like the IPv4/NAT scenario, keep your open ports secure.

As you can see, source IP obfuscation provides no meaningful advantage to the end user in this scenario. If anything, IPv6 users who feel like they want to use NAT could have the firewall choose random source addresses as well as random source ports out of their /112, and hide their 3 LAN devices within a pool of 65 thousand addresses. Would that not confuse a would-be attacker?

Still, the major drawback to be avoided with NAT is in breaking the globally unique address space and complicating inbound connection access, which will become a growing part of popular network policy over the next few decades. One thing Bit Torrent teaches us is that "the server" will less and less frequently have resources comparable to the "client swarm", so crowdsourcing the heavy lifting (from distribution to content creation to editing to caching) becomes vital to any scaling strategy worth it's salt. The hub/spoke communication model is slowly eroding in the presence of more sophisticated, decentralized many-to-many connection models.

NAT reduces a peer to a "consumer" which can only fetch data, but never re-offer it without convoluted port forwarding messes. Entire LAN's are limited to one named service per outbound IP, unless one wishes to screw with what port they offer services on, further complicating the job for other firewalls and participants of the content network.

You'll know what I mean if you've ever tried to configure mobile SIP access. Half the time you are behind a NAT, and you'll never know in advance if it's full cone, symmetric, or just somehow pathological. Sometimes you are nested within multiple NATs which each behave differently!

Some legacy UDP protocols I've worked with need to make connections to thousands of remote IP addresses at multiple, highly transient port mappings which bring NAT mapping tables to their knees. In a firewall-only environment, it's easy to whitelist access to swaths of ports for clients and then the gateway need not maintain tables for related traffic, but can continue to protect unrelated ports unlike with SOHO DMZ.

To sum up, NAT is not only a bandaid, but it's already pulling at our short-hairs.

And then they wonder why noone is taking the FSF seriously. Thankfully, they are not representative of the open source movement.