> 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.
> 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 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.
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 18.104.22.168
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
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.
You can tune a piano, but you can't tuna fish. You can tune a filesystem, but you can't tuna fish. -- from the tunefs(8) man page