As my kids are starting to want to "look for things on the internet", I started caring about what they might accidentally stumble onto, even in an appropriately supervised context.

I had vaguely heard about OpenDNS for some time, but had not really paid much attention to it. A few relatively recent articles on using it to make an internet connection somewhat more "family-friendly" caught my attention, and I finally signed up for a free account to try it out.

I have a local caching bind which forwarded to the nameservers that TWC provides to me (and to which I redirect all outgoing nameserver traffic via firewall rules), and I really haven't noticed nameservice being slow, so the "speed up your internet" advertising from OpenDNS wasn't ringing true. But the ability to filter out the worst of the sites dedicated to things that I think don't have a place in my home was interesting. So I signed up for a free account, changed a few lines in my bind configuration, and packaged and installed ddclient according to OpenDNS's instructions so that OpenDNS will continue to associate my home network with my home network settings on those rare occasions when my IP changes.

We weren't seeing lots of questionable content before the switch, so the fact that we've seen a total of two sites blocked since we signed up for the service is fine. It says that I can establish what I think are reasonable controls and it won't get in the way of normal activities.

Purely because I appreciate the service (I don't really care very much about saving statistics for longer), I signed up for a paid account. This service seems to me to be worth the $9.95/year.

A few days ago, OpenDNS rolled out a new free service called FamilyShield -- you can use a pre-configured set of filters without setting up any account at all merely by using 208.67.222.123 and 208.67.220.123 as your DNS servers (they include detailed instructions for how to do this on many different OS variants). This is exactly the same thing you'd get by signing up for their service and enabling the same set of filters for your account, so it's easy enough to upgrade to their free service if you want to customize the filters -- you just sign up for a free account, change the IP address you use for the resolvers, choose the filters you want, associate your IP address with your account, and (if you, like most people, have a dynamic IP) set up one of the many dynamic DNS clients available (they list several) to keep that association up to date.

I'm just a satisfied customer.

My wife found her smartphone screen cracked recently. AT&T told her to suck it up and buy a new phone, and the local independent shop couldn't fix her phone. I had a great deal of trepidation about sending the phone off to some random place I googled, but in the end sent it off to Jet City Devices in Seattle.

They turned the repair in about an hour from the phone's arrival on a Saturday (!) afternoon, and had it back in the mail same day, so that it arrived back in North Carolina on Monday with a new screen.

Good Work!

We have been importing sets of RPMs into Conary capsule packages, and yesterday we announced why.

Capsules are simple. We wrap existing packages provided in some other format (RPM, in the first instance, but we expect others) in rich Conary metadata (file-based dependencies based on deep file inspection, groups, and so forth), and store the combination of the unmodified package and metadata in the Conary repository. To install the package on a Conary-managed system, Conary calls the native package management code.

This works amazingly well. You can even mix native Conary packages with capsules.

This capsule feature can even help find bugs in RPM packages!

As part of this work, we imported RPMs from the original Red Hat Enterprise Linux 5 ISO images into a repository and tried to build a Conary group containing those packages. Unfortunately, this group was not dependency-complete. It appears that during RHEL 5 development, several packages were built against Firefox 1.5.0.7. Then (I would suspect near the end of RHEL 5 development, though I haven't checked build dates) Firefox was updated to 1.5.0.9. Someone remembered that the yelp package would need to be rebuilt against Firefox 1.5.0.9 to function. No one, apparently, remembered that gnome-python2-extras also needed to be rebuilt against Firefox 1.5.0.9. I don't blame anyone for this; I wouldn't either. But with Conary, all we had to do was try to add all the packages to a group and Conary complained and told us exactly what was wrong. By contrast, RHEL 5 was released with gnome-python2-extras that included an RPATH entry referencing a directory that does not exist: a broken dependency. As far as RPM's more limited view of dependencies is concerned, RHEL 5 was dependency-complete, but the combination of Conary's deep file inspection and group dependency checking caught this bug immediately.

At the post office, I found myself writing a bit of a pastiche of an old classic:

Passport Hours: 10:30-4:30

Nice work hours if you can get 'em

NOTICE: TO SERVE YOU BETTER, PASSPORT SERVICE IS NOW BY APPOINTMENT ONLY

And you can work less, if you try!

1:40 PM:

Applicant has been waiting since around 1:30 PM, occasionally ringing doorbell.

Postal Service Employee (annoyed, poking head around door she is holding mostly closed): When's your appointment?

Applicant: My appointment was at 1:30, Ma'am

Postal Service Employee (even more annoyed): Can't be at this post office. You must be at the wrong post office. I have lunch from 1 to 2.

...

Suddenly, I find myself thinking that privatizing postal service might be a good idea after all. Also, putting the phrase "to serve you better" on a sign or form should be a federal offense, publishable by standing in line at a post office for 10 years.

I will be presenting and giving a tutorial (two separate sessions) about Application-Centric Systems Management at LinuxCon 2009 September 21-23 in Portland, Oregon.

Application-Centric Systems Management: Presentation

Historically, applications have been managed separately from the operating system, which have been managed separately from frameworks. The OS and frameworks have been managed with a one-size-fits-all homogeneous approach, leading to large OS+framework installations that support all relevant applications. Application developers have been expected to develop applications to a platform with minimal version changes, without taking advantage of new features and bug fixes. This wastes time and money. rPath's tools deeply introspect all software components and provide strong version control management of all system image file contents. This allows application-centric system image definition that reduces collateral damage from OS/framework updates while allowing agile application development and deployment.

Application-Centric Systems Management: Tutorial

A practical follow-on to to the Application-Centric Systems Management presentation, this tutorial will guide the participants through the use of several of rPath's tools (particularly Conary, rMake, and rBuild) for application-centric management of heterogeneous systems. This will include packaging source code and binaries, composing them into groups, and managing a sample software lifecycle including application development, QA, and releases. This will be a hands-on tutorial that requires participants to bring working systems with virtualization software already installed. The techniques taught will not be specific to virtualization, but virtualization will be used to facilitate development and testing during the tutorial session.