$ git push gh master
Address 188.8.131.52 maps to github.com, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
Aw, you're so cute. Trying to implement security using the DNS protocol in 2014.
Weird, this topic just came up yesterday. Sounds like this sort of thing definitely does happen in the wild: wifi "monitoring" systems that forge deauth packets as if they came from your AP, causing stations to disconnect.
(There are new 802.11 standards that provide for signing your management frames, which would prevent this attack on devices which understand the new standard. Not sure if anyone implements it yet.)
Hmm, this is a pretty good chart and is meaningful to me. Earlier this year I think I got somewhere between "exhaustion" and "burnout" which was not pleasant, but seeming better now. I think I'm still somewhere in the "difficulty concentrating" to "confused" region.
I am however concerned about the placement of "irritable." As I get more anxious and confused, I generally get less irritable, because who am I to complain about you being stupid when I'm busy being stupid? I find my irritability is somewhere near the "optimum" level. Too bad for y'all when that happens. :)
I think the question that's generally not adequately addressed is whether it's good to be optimum at delivering on moderate demands, or sub-optimal at delivering on much more difficult demands.
"I'm sure it's a hard algorithm to implement, but in the end statically setting the channel to 1 (avoids microwaves and what we determined outside most the HME headsets) is WAY more stable then relying on [vendor auto channel] to decide the channel. We literally had no more wifi complaints after we did this. Before, [vendor auto channel] would switch channels so much (i.e. 300+ a day, reset the radio, etc) causing issues for users. Let the protocol deal with minor interference instead of blindly switching around."
Surprised at how bad some of this stuff can be.
"I did not either prepare or submit a presentation. Who put me in the schedule?"
– Simon Wunderlich
upon presenting at the Linux Plumbers Conference. (I'm pretty sure he was serious, but he forged on anyway.)
You have not truly experienced bufferbloat until you have a 1 Mbps link to the Internet and you try to do a hangout while your company-encrufted Macbook tries to upload and download boatloads of undefined probably-auditing-related junk in the background. Yay 30 second ping times!
To add insult to injury, Xcode comes with a tool called "Network Link Conditioner." It nominally allows you to simulate various poor-quality links for testing your programs. One of the options is to set a maximum upload/download speed, so I thought, hey! Perfect! I'll set a limit lower than the Internet link and dodge the bufferbloat, as I've previously done using tc on Linux.
Well, the joke's on me. I don't know what Network Link Conditioner does, but the end result is it can take a good link and make it act like it has a ton of ... bufferbloat. Sigh. I guess the good news is that's exactly what you should be testing your apps against since that's what people have. But no, it's not really what I was going for.
I think I should start carrying around a Linux-based wifi repeater box wherever I go. It'll have rate limiting features built in and I'll just pipe all my traffic through that.
"Lol. If I could get 650mps on wireless I'd be flying to CA to hug every team member. That would be something! :-)"
- from the forums