ck's Weblog: Existence, Eroticized

I've been using IPv6 at work without even noticing. Nice work, Network Engineering!

Last week, I got my usual email stating that I'd been auto-billed $2.84 for the week's Mad Men episode. When I tried to watch that evening, the episode was listed in my watch list, but was marked "unavailable." I watched something else, and when I tried again the next night, Mad Men was working as expected.

I'd forgotten about the inconvenience until I received today from Amazon customer service:

Hello,

We're contacting you about your TV Pass order. We recently learned that the delivery of your television episode from the week of April 15, 2013 was delayed. We're very sorry about this.

To help make it up to you, we've applied a $5.98 promotional certificate to your account that will be automatically applied to your next eligible Amazon Instant Video purchase. You can find your available promotional balance by clicking the "View Balance" link under the video player on any Instant Video product page:

They chose to automatically credit me double the full price (as opposed to the discounted price I paid as part of a TV pass). I'm impressed, and feeling even better about relying on their service in the future.

A few weeks ago, as an academic exercise, I tried to figure out how much it would cost to watch all of the household's normal TV programming via legal online streaming. The result surprised me.

With a combination of Hulu Plus and Amazon Instant Video, most of our favorite programs are covered. Even paying per-episode rates on Amazon for full seasons of every show we watch, the spreadsheet forecasts a $522.36 annual savings compared to DirecTV.

We'll have to give up some content. ESPN, for instance, offers its programming exclusively through subscription-based TV providers. But pretty much everything else has a streaming solution that's good enough (e.g. pbs.org/nova).

So after all that research, thought, and discussion, I scheduled my DirecTV cancellation this evening. It's a (much cheaper) brave new world, where I no longer need to fear that a thunderstorm will cut off the last few minutes of Mad Men.

My remaining Gentoo Linux systems recently upgraded to udev version 200, which features predictable network interface names. I let it rename my ethernet devices according to the defaults, and I can't say that it's improved things:

Reading the documentation, I understand why the two interfaces hit different rules for naming conventions. Still my preference would be that:

1. By default, all interfaces are named according to the same convention.
2. Device numbering should start at the same value in all naming conventions.

In this case, it seems sensible that eno1 should instead be enp1s0 or eno0. Or am I missing something?

Copying the reference 80-net-name-slot.rules file into /etc/udev/rules.d/ and commenting out the ID_NET_NAME_ONBOARD section made it behave like I think it should. But I'm hoping there's still some time to learn from these scenarios and come up with something more predictable (to humans) before this makes its way into RHEL.

In the process of moving my blog to its new cloud hosting, I decided that I don't like the way I wrote some of the backend code, which I last looked at around 2007. One thing led to another, and now I've got a new database schema, a trimmed down website, and a much better, cleaner code base.

For my reference as much as anything else, the major changes:

1. All database calls are now going through PEAR's MDB2 module.
2. Everything is quoted appropriately.
3. Multiple theme support has been dropped, as my implementation required an embarrassing amount of of "<div> soup."
4. I dropped parts of the site which had fallen out of maintenance and/or have been deprecated by social networks.
5. All static content is being served from Dropbox, now that I can be billed for excessive outgoing bandwidth.

Had I known going in how much I would end up fixing, I would have given serious thought to dropping PHP entirely and writing some Python scripts to manage files that would be served out as static content.

Lines of code is down 40% and page generation time is measured in thousandths of a second, so I'm comfortable for now.