Obsolete Your Idols

While I slept last night I thought of a gadget. Here’s the quick pitch:  imagine the portable music player you travel with seeking out more music of the kind you like from the people around you, automatically.

First, the disclaimers. Maybe this already exists, I haven’t looked. Maybe you already had this idea and I read about it and forgot I read it. If that’s the case, I apologize.  Because of the way ideas come to me they’re often indistinguishable from memories. This almost certainly couldn’t work in our existing legal framework where creativity and sharing is squashed by big cartels buying legislation and courts fearing innovation as I’m imagining it. That said, here’s some more of my thinking about how it might work.

Second, the mechanics.  The key element of it are the software smarts; it can be bolstered by hardware but I think the kinds of actions the device need to make can’t be solved with hardware alone.  So it could be an application on your Android or other smart phone, on your PDA, your laptop or a dedicated piece of hardware running the application.

Dedicated hardware could  provide Local Area Wireless Network options, such as bluetooth, IR, 802.11s (mesh) and whatever else people can find local peers with.  Otherwise, avahi or another zeroconf on a LAWN connected laptop or even devices wired to a LAN could potentially perform the exploration and exchange.

Each potential participant in the exchange needs to share information about what it seeks and what it has.  It needs to make decisions about whether what it’s being offered meets its seek criteria sufficiently well to attempt a transfer.  It needs to detect and deal with Byzantine faults.  It needs to negotiate a transfer rate with multiple simultaneous partners which won’t saturate itself or its peers.

Here’s what I was imagining an exchange playing out like

• A: Hi, is someone there?
• B: Hello, A.  I know protocols purple, green and blue.
• C: Hello, A.  I know protocols purple, blue and yellow.
• M: Hello, A.  I know protocols red, orange, yellow, green, blue, indigo, purple and many more!
• A: B,  let’s switch to protocol green. C.  let’s switch to protocol blue. M, let’s switch to protocol red.
• B:  Pleased to meet you, A. Do you have any Creative Commons licensed music?
• C: Pleased to meet you, A.
• M: Pleased to meet you, A.  Do you have any Windows executables with the DRM removed?
• A: B, yes, I do.  Do you have any public domain ebooks?  Let’s work out an exchange.
• A: C, do you have this specific list of public domain ebooks I lack? [List is the subset from B which A is interested in, thus allowing it to use something like bit torrent to transfer parts from each of them both to distribute demand and allow comparison of pieces to verify the content is accurate.]
• A: M, no I don’t and your question makes me nervous. [A then puts M on a ignore-with-timeout list.]

Some of the things I’m trying to show there is that your device may want to use different protocols with different peers, to avoid collision or because some devices are more capable in some modes; that a device is expected to interact in various ways, by making requests, responding to requests, prioritizing tasks.  There’s some thinking about detecting suspicious peers and treating these LAWN gnomes as a tiny cloud where nodes would become eventually consistent, so that B and C and M have all been neighbors long enough that B and C have nothing to say to each other when A arrives, they’ve already reached an equilibrium and have exchanged all the files they care to (until A starts to provide B with new music at which point B might tell C ‘let us resume our earlier negotiations, I have something new to trade’) and neither B nor C is talking to M, having long since moved this obvious commercial software troll on an ignore-no-timeout list.  Oh, and it’s not just music being exchanged, though that’s the sexiest use case.  If your ebook reader built up your library based on books you already had, probably no one would hate that.

Third, a stab at addressing some concerns I raised to myself and then answered. In terms of evaluating if a given music offer matches seek criteria, I’m pretty sure data from last.fm could be very handy. It would perhaps be possible to build a similar dataset and heuristics around ebooks or other mobile data usage.  You’d tend to be a lot more successful in finding acceptable offers in places where you tend to be around people you share tastes with.  Like going to a show by a band makes it more likely you’d find acceptable the music on offer from the devices of the people around you over the offerings you’d find standing in line at a grocery store. It seems impossible to me to avoid copyright infringement even if you hardcode into the device only accepting content which is appropriately licensed because it could doubtlessly be jailbroken or its peers could conspire, but maybe raising the bar on doing so would mitigate some of the risk of inadvertant exposure (since it’s not a protection from being sued into poverty, the risk never goes away entirely).

This post is addressed to people who more or less are in the situation I was in two months ago.  Notably:

1. you manage an environment which is mostly Ubuntu 8.04.mumble LTS
2. you know enough Ruby to recognize it when you see it
3. you want to start using Puppet to manage your environment

I wrote this post because you’ll run into problems trying to use the probably otherwise fine examples in the documentation, through a combination of puppet being a moving target and LTS being a static environment.

First, if you get inexplicable errors about certificates while configuring and tweaking and experimenting, shut down the puppetmasterd on the master server, kill any puppet process on the client machine, and remove the contents of /var/lib/puppet/ssl on both systems involved.  This seems especially common if you’re doing any hostname tomfoolery.

Second, here’s what a very basic puppet.conf file might look like:

# This file is managed in //depot/ops/puppet/
[main]
logdir=/var/log/puppet
vardir=/var/lib/puppet
ssldir=/var/lib/puppet/ssl
rundir=/var/run/puppet
factpath=$vardir/lib/facter
pluginsync=true
certname=mask.play

[puppetmasterd]
templatedir=/var/lib/puppet/templates
server=mask.play

The only real changes from the shipped default are an explicit certname and server value. It might not be obvious what I’ve set them to, here, but that’s a server name (on an internal only TLD). On the client machines you won’t need either of those set and you can squelch some noise by getting rid of the pluginsync= option.  In my environment, because of DNS tomfoolery, I had to explicitly make a record in /etc/hosts for the puppetmasterd’s server on the client systems, telling them to look for puppet at a specific address.

To get started setting up puppet, refer to the Simplest Puppet Recipe page specifically Step four: Run a client.  What you’re wanting to achieve here is an introduction between the puppet client node and the puppetmasterd server.  You’ll see your success or failure in /var/log/daemon.log on both systems.  Now about the rest of that Simplest Puppet Recipe page.

If you read it in conjunction with the Puppet Best Practices page, you may get confused like I got confused, especially if you’re a congruent kind of dumb.  After going round and round, here’s what my puppet tree looks like in SCM and implicitly on the puppetmasterd server:

puppet
puppet/services
puppet/manifests
puppet/plugins
puppet/notes
puppet/clients
puppet/modules
puppet/modules/appserver
puppet/modules/appserver/manifests
puppet/modules/curl
puppet/modules/curl/manifests
puppet/modules/snmpd
puppet/modules/snmpd/manifests
puppet/modules/snmpd/files
puppet/modules/user
puppet/modules/screen
puppet/modules/screen/manifests
puppet/modules/ntp
puppet/modules/ntp/manifests
puppet/modules/ntp/files
puppet/modules/sudo
puppet/modules/sudo/manifests
puppet/modules/sudo/files
puppet/modules/bacula
puppet/modules/bacula/templates
puppet/modules/bacula/manifests
puppet/tools

You can see that most of the action is in puppet/modules.  Specifically, I would have started (if I knew then what I know now) with puppet/modules/sudo.  Notice two subdirectories under that.  The puppet/modules/sudo/files directory has in it the sudoers file we want to deploy to client systems.  The puppet/modules/sudo/manifests directory has in it the init.pp file.  For reference, here’s what my version of their simplest recipe looks like:

# /etc/puppet/modules/sudo/manifests/init.pp

class sudo {
	package { sudo: ensure => latest }

	file {
		"/etc/sudoers":
			owner => "root",
			group => "root",
			mode  => 440,
			source => "puppet:///sudo/sudoers",
			require => Package["sudo"];

		"/usr/bin/sudo":
			owner => "root",
			group => "root",
			mode  => 4755;
    }
}

As I recall, the permissions on Ubuntu 8.04 are different from those in the example and my choice of layout and file placement dictated the source parameter.  Speaking of file placement, the fileserver.conf I use:

[files]
  path /etc/puppet/modules/*/files
  allow *.playsomething.com
  allow *.play

Upon shutdown, puppetmasterd complains bitterly about that asterisk but it seems to otherwise work. I surmise I could well enumerate all the paths explicitly and shut up that bit of noise but it hasn’t seemed worth it, to date. The default fileserver.conf that ships in Ubuntu 8.04 expects you to serve files from /etc/puppet/files but that seems to conflict with the Puppet Best Practices so I went with the fancier place.

So under puppet/manifests are where your rules for which modules get applied to which systems.  Mine has three files, modules.pp, nodes.pp and site.pp.  They look like this:

# /etc/puppet/manifests/modules.pp
# managed from //depot/ops/puppet/manifests/modules.pp

import "sudo"

and

# /etc/puppet/manifests/nodes.pp
# managed at //depot/ops/puppet/manifests/nodes.pp

node basenode {
	include curl
	include ntp
	include screen
	include snmpd
	include sudo
}

node 'exhaust', 'gasket' inherits basenode {
	include bacula
}

node 'manifold', 'header' inherits basenode {
	include appserver
}

and

# /etc/puppet/manifests/site.pp

import "modules"
import "nodes"

filebucket { main: server => 'mask.play' }

File { backup => main }
Exec { path => "/usr/bin:/usr/sbin/:/bin:/sbin" }

Package {
	provider => $operatingsystem ? {
		debian	 	=> aptitude,
		openbsd		=> freebsd,
	}
}

If you can read between the lines there, puppet reads the site.pp file. That tells it, among other things, to read the modules.pp and nodes.pp files. The openbsd operatingsystem part is untested so don’t count on it, but that Ubuntu systems identify as debian is true and somewhat important to know.

The nodes.pp file is where all the action happens.  I’ve got five modules there defined as necessary for all kinds of systems; your environment almost certainly varies.  Then there are two kinds of nodes which inherit from basenode and add another module; each of those child node types names two servers which are that kind of a node, and includes a different module.  In this case, exhaust, gasket, manifold and header are all names of servers.

You can probably generalize from this to get a boost on rolling out Puppet.  Each of the things you want a server or set of similar servers to do is a module in puppet/modules/NAME/ with manifests/init.pp telling puppet all the rules of that module, and files/WHATEVER containing any files which should be pushed as part of enforcing that module.  You may have noticed that my puppet/modules/bacula doesn’t have a files subdirectory, but does have a templates subdirectory.

Here’s what the init.pp for bacula looks like:

# /etc/puppet/modules/bacula/manifests/init.pp

class bacula {

	package { bacula-client: ensure => latest }

    file {
		"/etc/bacula/bacula-fd.conf":
			owner => "root",
			group => "root",
			mode  => 640,
			content => template("bacula/bacula-fd.conf.erb"),
			require => Package["bacula-client"];

		"/usr/sbin/bacula-fd":
			owner => "root",
			group => "root",
			mode  => 755
    }

	exec {
		"/etc/init.d/bacula-fd restart":
			subscribe 	=> File["/etc/bacula/bacula-fd.conf"],
			refreshonly	=> true
	}
}

I’m providing it not because it’s the most awesome use of templates ever but because I found using templates very intimidating as a non-Ruby coder, so I had to do a couple shots of tequila before trying to write one. And here’s the puppet/modules/bacula/templates/bacula-fd.conf.erb file:

# /etc/bacula/bacula-fd.conf
# managed from //depot/ops/puppet/modules/bacula/templates/

Director {
	Name = akadi-dir
    Password = "yrmomsaidimthebestlickintown"
}

FileDaemon {
	Name = <%= hostname %>-fd
    FDport = 9102
	WorkingDirectory = /var/lib/bacula
	Pid Directory = /var/run/bacula
	Maximum Concurrent Jobs = 20
}

Messages {
	Name = Standard
    director = akadi-dir = all, !skipped, !restored
}

It’s a tiny substitution, just customizing the bacula-fd.conf file on the client systems to name themselves distinctly.  The point being I just took a bacula-fd.conf, figuring out the piece which needs to be different on different systems, and substituted a variable to differentiate them.  It’s easy.  There, I just saved you $7 on tequila.

Oh, so the last detail of absolute square one stuff.  Getting the important bits from your SCM workspace to the puppetmasterd workspace.  In our environment, we use a lot of Makefiles to deploy files from SCM so that’s what I did here.  It’s dead-simple but just in case you need a nudge, it looks like this:

# Makefile for puppetmasterd configuration.
# binder@manjusri.org takes the blame for this one

mask.push:
	rsync -av --delete --exclude '*/README' --exclude 'Makefile' .  root@mask.play:/etc/puppet/

It’s just an invocation of rsync which blows away any local crap, leaves the README and Makefile files in the SCM workspace, and copies everything else into the /etc/puppet directory on the puppetmasterd server. Reloading of the daemon is done manually at this point but you could always modify this Makefile to reload your configuration once you push.

OK, that’s it.  That’s everything I think I know about Puppet which I didn’t know two months ago.

Or what I learned from Werner Vogels at LISA 2009.

I’ve been at LISA 2009 and saw the keynote given by Amazon’s CTO.  Here’s what I learned from it:  figure out what you’re spending more than 50% of your resources doing, then figure out how to eliminate it.  Repeat.

Before I go deeper into why I thought that’s what he was saying, two points.

1. Yes, I saw the sexist slide.  I didn’t feel offended at the time because it seemed his reaction was genuine. He prefaced his talk by saying many people had asked him to restructure his talk to target it more at the audience of system administrators.  He explained he’d rearranged his slide deck and there had already been some spots where it seemed to me he was working to change his usual points.  So when he pulled up a slide with a girl pointing a gun and seemed to blank on what he wanted to say, it seemed genuine to me.  It could have been staged.  What seemed like an attempt to get a laugh out of the audience and move on could have been scripted.  But it didn’t seem that way to me at the time.
2. My closest friends may well be wondering why I’m taking seriously anything Amazon has to say.  I’m still mad about the 1-click patent, I actively advocate for people to buy from Powell’s if they want to buy books online, I haven’t bought anything from Amazon from years and even then it was gifts for other people. The crowd around me during his speech reacted badly, perceiving it as nothing more than a sales pitch for Amazon Web Services.  Which, yes, there was a lot of that to it.  But I think that’s understandable.  If you’re a CxO at a company and you’re speaking to an audience and you’re not selling your company at least a little bit all the time, you worry me more.

So.  Why would I be talking about Amazon’s CTO?  It’s because of what I thought I was hearing when I filtered out the sales pitch.  Perhaps it’s just the CTOs I’ve worked with recently but it seemed to me that there was a pattern to the way they think about company operations that I can finally wrap my head around and see the similarities in.  It’s this:  a CTO looks for big technological patterns inside and outside the organization.  I know, I’m the last to notice this.

But now I took this observation and tried to think like a CTO for myself and I realized the first thing I need to do is get better at measuring the time I put in to things.  My intuition is that better than half of my time is spent changing configurations.  Maybe I’m wrong, but it’s something I can record and measure and analyze.  Whatever it is that’s consuming all of my time at work, I can look for a way to drastically reduce it.  Whether it’s as simple as stopping doing it or as complex as automating it or as pedestrian as paying someone else to do it, I think I can take this epiphany and I make my job better.

So that’s what I got out of his talk.

I hated it less than some other people, less than I expected myself to.  In fact, I didn’t hate it at all, I learned something from it and it’s going to change how I do my job.  Which is perhaps the best I can hope for from a keynote address at a technical conference.

inboxzero

Originally uploaded by Binder Of Daemons

BEHOLD MY GLORY.

I read another Charles Stross novel, Halting State. Overall, I think I enjoyed Glasshouse slightly more, but this one was more amusing more often. It starts with a bank inside an MMORPG getting robbed and ends with a 419 nod, so it’s an internet-savvy narrative. It’s got some characters who are likable, though their flaws don’t seem to really hinder them. The shy nerd with a sexcrime history gets laid, the cop with the uppity kid never has to take time off from the case to settle his hash, the accountant with the brittle work situation never suffers from office politics during the course of the story. It’s pretty light on the characters but correspondingly there’s some meaty cryptographic and augmented reality dealt to the reader in careful doses.

The more I think about it, the less satisfied I am with the way things resolve, so I’m optimistic about a rumored sequel which I hope will explain more about why Scotland’s software infrastructure survives the threat which emerges in this novel, but that’s just quibbling. This is a pretty good near future sf novel with varied characters and a briskly moving storyline.

Who might like it

• Gamers, both the tabletop and mmorpg flavors, and possibly casino to a lesser degree.
• Fans of nerd protagonists.
• People who just can’t get enough of the intricate crinkling of police procedurals.

Who might not like it

• People who think you’re getting a whole novel about people playing an MMORPG.
• People who felt Orcbusters in The Computer Always Shoots Twice was fundamentally cheating.

I made some tiny updates to bring my resume up to date since it’d been awhile and put it online again. It’s linked from the top of the manjusri.org domain.

Then I played around a little bit with the Powell’s Partner Bookshelf thing and have a shelf of some of my favorite books.

Also added to the Socialize Me page if you want it again later.

Did you like Brimstone? Did you like Unknown Armies? The novel Godwalker? The comic book Lucifer? Immortal the RPG?  Delta Green?

If you didn’t say yes to at least one of those, you’re excused.  Go skip ahead to something else in your flist or your feed reader.

Still here? Then you’ll like Sandman Slim.  It’s a novel which could have been told as a story in any of those settings but wasn’t, because it was told by Richard Kadrey.  It’s a revenge story, it’s a modern era magic story, it’s a buddy story, it’s a story about a lucky loser who more or less emerges triumphant from his character arc.  It’s really good.  But I don’t know how much appeal it’ll have to someone who isn’t already into that gritty street magic paranormal anti-romance groove when this book hits their eyes.

For those of you would like this, go read it.  It’s a fast moving story with very few aggravations.  If you’re not one of the people who would like this, you suck.  What are you doing still reading this, anyway?  I told you to beat it!

Remember when I read Revelation Space and wrote a brief review? Between then and now, probably while in Denver at a reading with Vylar, I picked up Redemption Ark, the sequel. Seems to be the middle book in a trilogy. It does a solid job of being the middle child, not wasting too many pages recapitulating the plot of the first book, sheds a new light on what’s gone before and foreshadows, hopefully, a resolution to The Big Problem forthcoming in the third book. Well, forthcoming to me. It’s been in print for some time now, I suppose.

It’s more space opera, with some striking relativistic scale combats, some tough people solving thorny problems, some unlucky people failing, compromises made with the best of intentions and blowing up in everyone’s faces.

Who might like this

• Fans of space opera
• People who read the first book and wonder what happens next
• Fans of tough women and wily old men

Who might not like this

• Fans of dragons, unicorns, wizards, magicians, chicken pablum for the soul
• Readers who find middle books in trilogies disappointing in general
• People looking for a fast breezy read

I’m testing something minor and not very sexy but if you read this post, please make a brief comment telling me where you read it.  I’m anticipating answers like ‘on Livejournal’, ‘in Google Reader’, ‘in Google Reader shared by <someone>’, ‘on your planet’, etc.  Surprise me if it’s something I didn’t anticipate or reassure me of my powers of interpretation, if you would.

ETA: if you are seeing this in livejournal and have no idea how to comment click on the link ‘Obsolete Your Idols’ after Mirrored from. That will bring you to the blog itself where you can comment. Sorry for the hassle.

This kludgy patch is the minimum needed to get peep-0.5.0-rc2 to compile without warning or error.  If I liked it more, I’d try to feed it upstream.  As it is, this is a place for me to tuck this so I don’t lose it. peep patch