Google DNS is being hardcoded into a significant number of devices now. Which is nice, because it pretty much always works.

…except when you’re trying to use Netflix and you have a tunnelbroker IPv6 tunnel. Ugh.

So, this is a brief followup to Stupid OpenWRT tricks. Or maybe “Getting Netflix to work when your ISP doesn’t support IPv6 yet” is a better way to put it…

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 just released MooseX::AttributeShortcuts 0.028; it incorporates Moo-style type constraints. …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: -- 1 2 3 4 5 6 7 8 # easiest is via AttributeShortcuts use MooseX::AttributeShortcuts 0.028; has foo => ( is => 'rw', # $_[0] == the value to be validated isa => sub { die unless $_[0] == 5 }, );

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.

Never, ever update on a Friday. GitHub: Automattic/jetpack #284: use content, attribute 0 -or- ‘id’ le sigh