I despair again at how protobuf's line format can be so efficient while its implementation is such a performance problem for so many people (especially in Go, sadly).

Okay, it was dumb when everybody started making the "log in" button two clicks and the "sign up" button one click.  But I think you've gone over the line when you remove the login button altogether.

System A has problems, where it will fail deterministically in a random 10% subset of cases.

System B has different problems, where it will fail deterministically in a different random 10% subset of cases.

Assuming the problems in each system are independent, the chance that a particular failure mode affects both system A and system B is only 10%*10% = 1%.  Thus, the chance that a problem which occurs in system A, is gone when you switch to system B, is about 90%.

And that's why replacing your broken wifi router with a different wifi router usually makes your problem go away.

"Note: It looks like leadership has stated this shouldn’t be the solution."

I call this confident decision making.  Well, I think I do.  Well, it looks like I do.  It looks like someone does.  Okay, it looks like someone doesn't not.  But anyway, I think we have a solution.  Not this one though.

Remember, if the read rate is always below average... it's never below average.

"The second mouse enjoys the cheese."

"...require each post to have two out of three of 'true, kind, and necessary'..."  I've never heard that one before today, but it really strikes home for me.  A lot of flamewars arise from people making statements they believe are true, but could never honestly argue are kind or necessary.

YES.  Widespread hamburger menus were one of the worst things that came around the time of iOS 7. http://deep.design/the-hamburger-menu/

"The best solution so far seems to be a tab bar, either at the top or bottom of the screen (probably top for responsive websites), with 4-5 icon+text buttons for the primary navigation options." ...oh, you mean like they had on the iPhone 1.

http://wondermark.com/1k34/

There has got to be one of these that's only slightly less awesome and slightly more poisonous and much more affordable.

So, I finally found a good reason to hate python refcounting (other than the usual spurious incorrect ones): if you pre-allocate a bunch of objects, then fork(), then try to run two instances, you don't save any memory because the refcounts rapidly end up dirtying almost every single page.

But I'm not so easily defeated!  I decided to modify my copy of the python interpreter as follows: there's a new global flag that says "all objects you touch from now on should be marked as permanent."  Permanent means that, next time you go to increment/decrement the refcount on that object, you skip it, thus avoiding dirtying the page. So the process is something like:
- set global perm flag
- allocate a bunch of heavy objects
- clear global perm flag

I was able to confirm with a synthetic test that this at least basically worked: I allocated a bunch of objects in a big list, forked, and looked at all the objects. With my patch, memory only contained one of each.  Without my patch, the memory usage doubled.

Unfortunately, in the actual case I care about (imported python modules, etc) most of the pages seem to still be getting dirtied shortly after the fork.

Friday philosophizing: If your threat model includes untrusted devices plugged into your wire, you might as well be wireless. Because wireless interfaces already worry about that.

First guess is correct.  Retried in incognito mode just to make sure it's not creepy.  Nope, just uncanny.

First Justin Bieber, and now this?!

http://business.financialpost.com/fp-tech-desk/cio/google-inc-unveils-cylinder-shaped-onhub-wi-fi-router-with-made-in-canada-software

Hawaii, essentially.

"99.6% of log lines are fully-analyzed within 2 minutes of the event happening on the CPE."

The even better part is 60 seconds of this is a delay before uploading logs on the device itself (should be fixable if we do streaming uploads), and the other 60 seconds is just buffering (should also be fixable).  In other words, almost all our remaining latency is fixable.  Whoa.

It's official: iOS supports 802.11v Fast BSS Transition.  We now have actual test results showing it.

What this means: tens of milliseconds to roam from one wifi AP to another, instead of 2+ seconds.  Done right, that means your voice calls and Netflix streams will have zero interruption as you move around in the house.

The future is coming fast!