In a discussion of overall system quality, today someone told me I cut fewer corners than any other engineer they know.

SCARIEST COMPLIMENT EVER.

This article says two things to me:

1) You'd better plan for your wifi router to have auto-updating software.

2) You should expect to have to support your devices for years and years.  You can't just stop with updates when the next model comes out.  

http://news.cnet.com/8301-1009_3-57596851-83/wi-fi-routers-more-security-risks-than-ever/

"The shortest explanation is that the inhomogenous forcing terms in the
Fokker-Planck equation vanish and the remaining terms are highly
damped.  But I don't suppose this means much to anyone (it
doesn't mean much to me)." – Van Jacobson on congestion control

http://root.org/ip-development/email/vanj.88feb11.txt

From the "customer service people have tact, and that's why they're allowed to do customer service" department:

Person: So, um, I was wondering, are you guys thinking of, um, changing anything about how the wifi works in the new Network Box?

Avery: Do you mean actually making it not suck?

Person: Well, I wasn't going to jump right to that question, but...

Avery: Yes.

Working with wifi bugs: sucks.

Working at a company big enough that the wifi chipset vendors care about you: I'll be honest, it kinda makes it feel better.

"Working as intended" is the most insulting of all possible bug resolutions.  Use it wisely.

Once upon a time, I thought it was surreal when I watched a recorded training video of a salesperson explaining the features of a product I had worked on, complete with using silly placeholder feature names I had invented (like "Tunnel Vision" for our VPN) with a straight face.

It's sort of like that watching someone else show me all the results of running that benchmark program I wrote one night when I needed to test something.  The graphs!  They are so much prettier than my graphs.

Excellent article about how QoS is a failure on the open Internet.

http://www.potaroo.net/ispcol/2012-06/noqos.html

tl;dr Google Fiber + QoS is kind of a silly idea.  Relatedly, keeping queue lengths short makes a huge difference; prioritizing packets doesn't particularly.

Wait a minute, how can the definition of insanity be "doing the same thing over and over again and expecting different results"?  I'm pretty sure that's the definition of "boring."  It would seriously suck to be both boring and insane.

Under the theory that "a watched pot never boils," I shall write a tool that just always watches the wifi really closely.

Somehow, I can spend uncountable hours sending different kinds of packets through a wifi adapter and failing to reproduce any useful problems, and that's okay.  But I really can't imagine spending the time to draw 178 different unique custom whiteboard cartoons.  And they're all funny.  And different from each other.

So many articles on how to choose a baby monitor that won't interfere with your wifi.  But why not articles on how to choose one that will interfere with your wifi?  Dammit, I never have normal people's problems.

Good grief.  Every now and then I am lucky enough to forget that computing used to be like this for everybody, all the time.

Now it's only like this for... well, 90% of the people... um, 90% of the time.  Poor saps.

http://www.kirpininyeri.com/2012/05/asus-zenbook-wireless-problem-solution/

I'm pretty sure Linux drivers would be much better if:

1) Vendors released datasheets for their chipsets

and

2) The upstream maintainers absolutely, positively, never ever accepted any code from a vendor ever.

Ugh.

So as far as I can tell, there's no sign at all that "radio frequency management" across your home, ie. carefully selecting the "right" channels for each of your wifi Access Points, will make any difference.

This is not to say that choosing channels carefully never makes a difference.  For example, at an office, you have very large rooms, very good signal propagation, and a lot of computers (and APs) in a small space.  If you don't manage your spectrum in that situation, you're screwed.  Enterprise APs do an amazing job at this.

But in your home, it's different.  There are far fewer people.  There are far more walls.  There are neighbours who aren't cooperating anyhow with whatever scheme you choose.  There are only 3 frickin' channels to choose from anyhow, on 2.4 GHz.  (And on 5 GHz, there are so many channels, and so little penetration through walls, that you don't need to be careful.)

In such a setting, I literally don't think you can make any improvement over simply having a decent (non-coordinated) autochannel selection on each access point separately.

Can anyone point to any research that disagrees?

Re: this debate about 20% time being deprecated or whatever.

After thinking about it for a while, I'm pretty sure I'm working on 20% projects 100% of the time.  Then my manager notices what I'm doing and adds it to the team goals.  But I'm not fooled.  Here's hoping you are!

I'm pretty sure I wasn't even mean when filling out the Amazon.com support form indicating that the device they sent me was not as advertised.  But this has got to be one of the most apologetic emails of all time.

"""
I'm so sorry about the problem you had with your "[...awesome wifi interference generator...]." 

I realize that this has caused utter disappointment on your part. To say that this is an inconvenience would be a complete understatement. 

At this point, I need to look into the problem and I'm going to create a ticket for this to confirm from our suppliers and from our Fulfillment specialists if the item is really [technical detail thing]. 

I just wanted to let you know I'll write back in 1-2 business days with more information. 

I realize that at this point of time, this would be disappointing, but in a situation like this, it is very important for us that we provide you with accurate and expedient resolution and I find that this is the best way to be certain that your issue is resolved more appropriately. 

Hoping for your continued patience and understanding and thanks for giving me time to find the best solution.
"""

Wireless transmitters powered by other people's wireless transmissions!  It seems sort of like LCD for RF.

http://txchnologist.com/post/58795707354/no-batteries-needed-next-gen-wireless-sensors-talk

One thing I realized a few days ago is that there is plenty of usability research that says programmers can't think like new users - because once you understand something, it's hard to pretend that you don't understand it and thus imagine how users will experience your thing the first time they see it.  I think it's pretty well known at this point that this usability research exists.

What I haven't actually heard is the usability research that says that software developers are no good at understanding the needs of their users outside of this specific new-user situation.

I think people are nowadays trying to claim the latter while using data from the former.  And I think I have fallen for it myself.

Okay, I think I've been convinced that "device trees" (the new Linux kernel thing for identifying not-easily-probe-able devices, mostly on embedded platforms) are a good idea.

I thought you were supposed to add them as an extra file in your finished build image, ie. kernel + rootdisk + devicetree, which seemed like it was just complicating something that already worked.  But in fact the goal is for the bootloader to have a hardcoded, non-changing devicetree that it hands out to every kernel it boots.  That way, the kernel and rootdisk could theoretically work on more than one hardware platform, and always know which devices to expect, because the bootloader will tell them.

That seems like a good idea.  It's basically PCI device probing, only without requiring the actual devices to implement the probing data structures, which means you save money.

"Trick for productionizing research: read 3-5 pubs and note the stupid simple thing they all claim to beat, implement that."

–@jaykreps on Twitter

The good news: vendor says I'm supposed to have to write all this glue code on top of their driver to make it work over SPI bus.  So I guess I wasn't wasting my time.

The bad news: Linux's SPI layer seems pretty standardized if you ask me. The code I wrote so far is not specific to the chipset we're using. So I'm pretty sure they could have done it properly if they cared.

Oh well, now I know about the SPI bus.