Technical Stuff

I have a Netgear WNDAP360 ap which is pretty hard core for home use.  It was an upgrade from a previous netgear prosafe ap that just 802.11b/g.  The WNDAP360 is 802.11a/b/g/n and supports dual radio data pathing for much faster throughput. When I had just the single radio AP I used 2 different SSIDs, one for the trusted wireless network at home and one for the untrusted.  Why 2 for home?  Well, when family members visit with Microsoft boxes they clearly get put on untrusted, while Linux and Apple generally go on the trusted side. So when I implemented the dual radio AP, I initially created SSIDs with the same name on each of the different radios.  So for the A radio, I used untrusted and trusted SSIDs.  Then on the B radio, I used untrusted and trusted.  I figured that devices would happily discover both untrusted and both trusted and pick the radio that was the fastest.  In practice however, that was not the case.  Devices seemed to lock the SSID name to a particular band which re

https://bugzilla.redhat.com/show_bug.cgi?id=1028272 Recently hit this bug where terminals (urxvt256c) were not getting the ^C interrupt.  It is amazing how many times you use this combination in normal work. The Redhat guys think it is the Nvidia driver which sucks, but at least there is work around.  I used a script to start my xterms so I just added an intermediate shell call. New script for xfce4 to call: ~/bin/generic/run-urxvt #!/bin/bash # wrapper to work around ^C bug exec /bin/csh -c "$0.real $@" Which calls: ~/bin/generic/run-urxvt.real #!/bin/bash cd || ( echo "can't cd to ${HOME}" > /dev/console; exit 127) COLOR[0]=cyan COLOR[1]=green COLOR[2]=orange COLOR[3]=red COLOR[4]=white COLOR[5]=yellow COLOR[6]=lightskyblue COLOR[7]=#B94949 COLOR[8]=#FDCB54 COLOR[9]=mistyrose COLOR[10]=GhostWhite COLOR[11]=khaki COLOR[12]=SlateGray COLOR[13]=mediumaquamarine COLOR[14]=#7459C5 COLOR[15]=violet COLOR[16]=orang