So, if you're like me you find yourself wondering why your broadband provider has a /32 IPv6 prefix assigned, and yet chooses not to use it, forcing one to either be IPv4-only (how 20'th century) or use an IPv6-over-IPv4 tunnel solution.
Fortunately there is a simple and free solution out there, courtesy of Hurricane Electric's rather fabulous tunnelbroker service. Obtaining an IPv6 prefix and setting up the tunnel is covered, extensively, so I won't go into it. It's also rather easy to set the tunnel up on an OpenWRT based router, like mine. The default setup is rather nice, but there are some changes you can make to your router configuration that will make it even nicer.
One of the most dangerous books I've ever even partially read is MJD's Higher Order Perl. In particular, its description of subroutine currying -- that is, building more specific functions out of more general purpose ones -- is a pattern I find incredibly useful.
The other day I found myself writing a number of routines that were surprisingly similar... kinda. They all implemented a common pattern, but across routines that were rather... different. I found myself wistfully longing for the familiar pattern of currying, and then realized -- I'm working in PERL, DAMNIT.
This is part of recent work of
Test::Moose::More to use subtests where they make sense. Here I was able to
curry one function --
_validate_subtest_wrapper() -- by passing it a
reference to another function, that it then invokes.
Excellent. Life is easier, as it should be.
...largely because I needed to relax, and wrote MooseX::Meta::TypeConstraint::Mooish :)
That means you can now pass a coderef to has() in isa that, like with Moo, dies on validation failure and lives on validation success:
This requires a little magic, unfortunately; either the driver, system, hardware itself, or some combination thereof do not operate well with autosuspend enabled. Disabling autosuspend for this device does appear to resolve dropped / corrupted / weird bluetooth issues.
Based on my googling, I do not believe this to be Thinkpad-specific, rather something the Intel 7260AC firmware isn't handling properly at the moment. FWIW, I'm running Ubuntu 13.10 (saucy) on the thinkpad in question, and 12.04LTS (precise) on my destop, with the same card sold by Intel in a PCI-e mount.
Based on one posting in particular, the following solution presents itself:
This isn't ideal -- as it should Just Work -- but it works, and is certainly less drastic than turning off USB autosuspend globally. In retrospect, having the bluetooth device drop out shortly after boot/resume, but always be available after resuming, was a big clue.
Never, ever update on a Friday.