Links:

Categories

Recent Posts

Bookmarks

Recent Status

Upcoming Events

Site search

Categories

January 2009
M T W T F S S
« Dec    
 1234
567891011
12131415161718
19202122232425
262728293031  

Tags

Blogroll

Navbar

Related

Puppet on the IT Management Podcast

I was a guest on last week’s IT Management Podcast again last week, and we ended up talking a lot about Puppet and the difficulties in running an open source software company.  As always, John Willis and Coté are informed and interesting.  Give it a listen, and maybe subscribe to the whole series.

Puppet and OpenQRM

Matt Rechenburg is the author of OpenQRM, a multi-platform provisioning tool (competing with tools like Kickstart and FAI).  He has recently announced integration between it and Puppet:

…this step is another milestone for the openQRM project which now includes the automatic configuration management features for the managed appliances powered by Puppet. With integrating Puppet into openQRM the mission is to provide a generic web-based user interface for the Puppet manifest. The current state already provides some pre-made classes like web-server, database-server, lamp etc. and automatically sets up Puppet for the openQRM environment in best-practice  manner by keeping the manifest in an snv-repository.

John Willis had a say, too:

The important thing, in my opinion, about the the openQRM Puppet integration transaction is that it exposes the exciting and beautiful things about open source. From a discussion about the importance of the integration of provisiong and configuration management, (i.e., openQRM and Puppet), to a fully developed integrated solution, only took 3 weeks. Imagine this discussion happening between even the most agile of proprietary vendors and the time line of something like this to happen. In the proprietary example they would still be playing phone tag just to figure out how their lawyers could talk. I am pretty sure Matt never even called Luke once during that whole process.

I haven’t yet had the chance to give OpenQRM a try, but hopefully this will encourage others to try it, and maybe one of those others will let me know how it goes for them. :)

iPhone thoughts so far

Yes, I know, I owe you the third and final Puppet history post, and I’ve got a few other posts brewing in there, but, well, I just can’t seem to muster up the energy in the hour or two between the girls going to sleep and my own descent into fearful (of waking babies) slumber.

I’ve now had my iPhone for a bit over two weeks, and it seems to be easier to write about others’ gadgets than my own software, so here’s a bit about this one.  Note that this isn’t an attempt at a structured review — it’s a conversational, “luke hates stuff” review.  I do a much better version in person, so feel free to corner me at the next conference.

Overall, I think I made the right decision.  The momentum (and thus the developers, the apps, etc.) is clearly behind the iPhone, but more importantly, my wife can easily use hers while nursing, or sitting with sleeping babies, which turns out to be really important.  The fact that the iPhone never requires two hands is critical for her.

See, I think the g1 was actually a better option for me, but the iPhone is a dramatically better option for her, and my geek snobbery loses out to her practicality.  It’s also true that the device itself is much better — I can comfortably put it in my pocket, and I find that the soft keyboard is just as good as the g1’s physical keyboard.  And all of you crackberry addicts whining about two-thumbed typing, I do it all the time on my iphone and I’m about 10x faster that way, probably about as fast as I was on the g1.

That being said, my main conclusion about the iphone is, “welcome to 1987″. That’s the last year you couldn’t run multiple apps at the same time on the Mac, and this is one of the two main things that sticks out about the iphone for me.  That, and the modal notification dialogs.

For those who didn’t suffer through MacOS 7.x and earlier, modal dialogs require your attention and will not go away or let you do anything else until you deal with them.  And they suck, horribly.  There’s absolutely no excuse for them in a modern operating system, and yet…

Here, on the iPhone, we have an OS that can’t run multiple apps at the same time, and if I get a text message while I’m working, I can’t do a damn thing until I deal with the text.  These, combined with the lack of any real task switching (”it’s easy - press home to start all over again!”), mean that you’re pretty much back in the 80s computing experience, except with a touchscreen and the interwebs.

Obviously I’m exaggerating, but it really is ironic that Apple going to have to relearn the MultiFinder and modal dialog lessons all over again.  I’m sorry, this push thing just won’t work — even if the technology works, and the devs adopt it, and it scales for ten million poorly written iphone apps, you still have the modal notification dialogs to deal with.

The g1 had this completely licked — it had a single notification space, and you had both non-modal notifications, and something like builtin task-switching because you could go from the different notifications straight to the correct app.  Oh, and you could hold down the home key to get a list of the most recent six apps.  Crappy task switching, but task switching nonetheless.  Whereas the iPhone just says, “hit the home key!”

For those of you saying, “oh, well, sure, maybe for *some* people, but that doesn’t matter to me!”, I have a relatively normal scenario for you.  I went for a bike ride the other day, and I chose to involve two apps:  I was listening to podcasts, and I was using TrackThing to track my bike ride.  Unfortunately, my podcast was 50 minutes, and my ride was an hour and a half.  Thus, partway through the ride, my soundtrack ends, and I have to switch apps.  Because TrackThing is stupid, I thus lose my current ride state.  Actually, in retrospect, I don’t think the state was gone, I think it just looked like it, because it used a stupid snapshot as its startup screen, implying there was no data.  The point is, something changes and you have to switch apps, and most of the time you really do have to switch apps, and now you’re stuck.  Especially since one of the favorite techniques to get you to pay for an app is to provide storage in the paid version.

But I have a simpler example of how the lack of background apps and the lack of non-modal dialogs suck:  Instant messaging.  I was an IMing fool on my G1 — it was almost justification for the phone by itself.  But I can’t use IM at all on my iphone, because none of the apps can run in the background.  And imagine what life would look like if they could:  You’d constantly be being interrupted, being forced to deal with each new IM.  This problem is exactly why Growl on the Mac is so great:  Passive notification but no need to act immediately.

The lack of backgrounding  means that the *only* option for IM is a solution from Apple.  There’s just no way anyone else can provide anywhere near a sufficient solution.  Sure, I can use Meebo or Palringo, which will keep me logged in for a few minutes, but I’ll have to continually switch out of my current app to the IM app (going back to home, then the IM app) to see if there are replies or whatever.  Useless.

And the worst thing is, even if Apple does provide a great IM app, it’ll still suck because of the modal notifications.  If I’m writing an email or reading an article, I don’t want to deal with the IM that second — I want to deal with it in a couple of minutes, when I’m ready.  This is exactly how we’ve all learned to do IM by now, but you can tell the iPhone will never allow it.

And for those of you saying, “oh, well, I don’t use two apps in the same day, and I don’t use IM”, then suck it, because you also can’t use Facebook or Twitter or whatever.  Or rather, you can, but you can only use one of them, else you’ll constantly be rotating around each of these apps.  I have this list of applications that I just open periodically on my iphone to see if anything new is happening, because they can’t notify me.  And for the record, Mail isn’t one of them — I actually don’t want push email, but I need push IM, and I wouldn’t mind some forms of push Twitter and Facebook.

And for those of you saying, “Oh, I use SMS instead of IM”, please, make a single friend in another country, and you’ll be so busy in the second job you’ll need to pay for the text messages that we won’t have to listen to your silliness.

Now that I’ve gotten past the really annoying, in your face, this-is-stupid part of the review, let’s cover a couple of other bits.  First, there are some great things about it.  The touchscreen, and the keyboard, are great.  It’s a device I constantly want to use, want to find a use for.

The app store has clearly inspired people and companies to make apps they wouldn’t have made for any other phone, and it’s very clear that plenty of people are making real money on the apps, which is a great thing.  I think Apple’s store and the dev community around it are 90% of what’s great about the iPhone vs. the g1 (the device itself being the other 10%, but that hopefully won’t hold up as more Android phones get released).

I’m a bit shocked how few apps deal with both landscape and portrait mode, and especially shocked that the Home screen doesn’t.  In retrospect, the g1 apps, including the main screen, were surprisingly good at this.

I really like how few buttons the iphone has.  I like the lock button, the volume buttons, and I *love* the silence switch.  Love it.  And I love that the touchscreen is used for everything.  Except…

Why aren’t there more interesting gestures used on the iPhone?  Can you even name a single gesture used other than the flick used to switch albums in the iPod or whatever?  Why can’t I use gestures to authenticate?  Why aren’t there other gestures (e.g., ones with more than one direction) available for things like app shortcuts, app switching, phone speed dials, or whatever?  While Apple is making steady progress in the things you can do with their trackpads (albeit still annoyingly focused on straight lines), the gestures available on the iPhone seem to match their absolute earliest efforts with trackpads.

And that’s mostly it; that’s been my iPhone experience so far.  This may seem like an unnecessarily negative review.  To some extent, that’s true — I’m a hater and always have been.  But at the same time, my stupid Razr four years ago did AIM pretty damn well and it was a total piece of crap (although notifications *were* modal).

To top it all off, literally ever person I’ve ever asked has said that I absolutely must have a case on my iPhone (one Apple employee even implied a case would help me fraudulently convince Apple to replace my iPhone if I broke it), yet the iPhone 3g dock won’t work with any case.  Oh, and it would cost me $100 to have a dock that I can plug into the wall ($30 each for the dock and power, $20 for the cable).  Considering that the iPhone must be charged every night, this is almost a necessary investment for each of our phones, so my wife and I can easily charge while we sleep.  Crazy.

So, we’ve got a phone that is absolutely ground breaking, sets a completely new interface standard, is a great device.  And it constantly pisses me off for being not quite there, and it’s especially bad because it brings back all the horrors of really early operating systems.  Remember how much you loved having computers that couldn’t do symmetric multiprocessing?  Yeah, me neither.

In Praise of Snobbery

I’m all kinds of snob:  Bike snob, beer snob, whisky snob, shoe snob, pants snob (yes, pants), and much more.  I get called this by friends and family because nearly everything I own I’m particular about — I don’t just buy or wear stuff, I spend too much time researching, deeply assess a purchased object, and then return (or give away, if necessary) those I don’t like.

Really, I usually preempt people by calling myself a snob, because I think it’s silly to be anything else.  Why own something you don’t care about?  You’ve got to wear a given amount of clothing, use a computer a given amount of time, own a given amount of dishes and furniture and stuff — why not surround yourself with things you actually like and prefer, rather than just settling for whatever crap wanders along?

Of course, this isn’t entirely feasible — I have plenty of bookshelves I don’t really care for, but my spending priorities don’t currently including spending a bunch of money on replacements, for example.  But certainly, all things being equal, care about what you buy and use.  Be a snob.

I was considering blogging this anyway, because it gives me a reason for writing a bit of a gadget blog — not specifically gadget, but review-oriented.  Obviously I’m not going to switch to all reviews all the time, but my research is thorough enough and (according to friends) my reviews are humourous enough that I figure it’s worth writing some of these things down.  Given I was already thinking of this, I was happy to see (via BoingBoing) that Bruce Sterling agrees:

It's not  bad to own fine things that you like.  What you need are things that
you GENUINELY like.  Things that you cherish, that enhance your existence in the
world.  The rest is dross.

Do not "economize."  Please.  That is not the point.  The economy is clearly
insane.  Even its champions are terrified by it now.  It's melting the North
Pole.  So "economization" is not your friend.  Cheapness can be value-less.
Voluntary simplicity is, furthermore, boring.  Less can become too much work.

The items that you use incessantly, the items you employ every day, the normal,
boring goods that don't seem luxurious or romantic: these are the critical ones.
 They are truly central.  The everyday object is the monarch of all objects.
It's in your time most, it's in your space most. It is "where it is at," and it
is "what is going on."

I completely agree.

So, you may see a few more reviews here than you might expect from a sysadmin blog, but hopefully you’ll find them useful and entertaining; and if not, you can always just call me a sock snob at the next conference. :)

Actually, I sent the gPhone back

Yes, I lied.  In the end, I kinda panicked and sent the phone back.

It was definitely a non-rational response, and I feel stupid-guilty about it, and I’m still not quite sure it was the right move.  The main reason I did so is because I just wasn’t sure, at least not enought to commit to 2 more years with T-Mobile.  What wasn’t I sure of?

Well, I wasn’t sure if T-Mobile would ever have a 3G network worth a damn.  They don’t have 3G in Nashville, nor any announced plans to ever do so, but even worse, their network is really young and they’ve got no real track record, other than being last to the party.

I also am not exactly confident of Google’s ability to maintain a phone OS.  All they’ve really demonstrated excellence at so far is making money from ads and building a search engine — every app on my start page is still in beta, none of them talk, and there’s still some weird, nebulous difference between normal Google apps and Apps for your Domain apps (e.g., I can’t use Reader with my madstop.com account).

I’m not confident in Google’s Market.  Did they do a good job with API design? Again, they have no history, Apple has tons and it’s directly portable.  Their decision to wait until early next year to allow non-free apps means a lot of developers won’t show up until then, which means you just might not know until then.

I’m not confident in the device.  It’s bloody stupid that it doesn’t have a headphone jack, but I could have stored my credit cards between screen and keyboard after only 2 weeks — slightly frightened what it would look like after 2 years.  I’m not sure how much better the battery was ever going to get, either.

I think in the end, though, what made me send it back is that I didn’t want to be the only guy in the room with a Zune.  And it would have been worse here, because there’s no network affect with mp3 players — my ipod never got more valuable because my friends have one, but my iPhone will quite likely increase in value as more of my friends have them, because we can all use the same apps and services.

LISA ‘08

I just got back from LISA, and as has happened for the last few years, I was pretty disappointed. I think the thing that sticks out the most is how isolated the community is.  Maybe it’s because I’m used to hanging out with developers, entrepreneurs, and Web 2.0 types, who are always looking for the next cool thing, but sysadmins claim to be geeks, and any credible geek is doing the same thing.

Except not at LISA.  Check a Twitter Search, for example — very few twitterers, almost none about the actual sessions, and no visibility within LISA of any twittering.  Or blogging.  This is the first conference I’ve gone to in ages that didn’t have a standard tag mentioned for blogging et al, which makes it hard to find blogs about a conference named ‘LISA’.  Technorati finds 7 results, but most of those seem to be about a completely different conference.

It’s very frustrating, because it’s still one of the best conferences to go to as a sysadmin (although Velocity is quickly becoming better), but the attendees don’t seem to be pushing the conference, and the conference definitely isn’t pushing the attendees.

I’m once again friends with the guy running the conference, Adam Moskowitz, so hopefully I can pressure him into making it a bit more online somehow.  I’m not sure there’s much he can do, though — he needs to somehow get the community interested, and one thing we’ve pretty clearly established is that we don’t have much of a community.

Data Lifetimes and Cache Expiration

This stuff drives me crazy.   (I can’t seem to say “drives me nuts” any more because of the damn joke.  That, and hanging out with too many Brits.)  I’m putting this post in ‘programmer therapy’ because it’s written more for me than for you, but maybe you’ll get something out of it.

Anyway, so I’m once again wrestling with data lifetime in Puppet.  This is one of those problems that always seems licked but then crops up again.

See, there’s plenty of data in a Puppet transaction whose lifetime should only be that transaction:  File stats, user name to gid mappings, and all kinds of information about the current state of the machine.  We need to collect this information, and we don’t want to collect it more than once a transaction (e.g., we need a file’s uid, gid, and mode, but we can get them all from a single Stat instance); but we also don’t want the data lying around for the next transaction.

So Puppet has support for a ‘flush’ method throughout most of the RAL:  By default, the transaction calls ‘flush’ on each resource, and the resource calls ‘flush’ on its provider.  This makes it easy to get rid of data that should be cleared up after the transaction.

Kind of.  See, the *real* reason for the ‘flush’ method is actually to flush changes to disk; e.g., the provider might have multiple attributes changed, and then you call ‘flush’ on it to make all of those changes at once.  It’s just that it’s also a convenient place to clean up data because, well, it’s the only place to do so.  So some time in the last few months or years or decades, my brain decided it does both things, but it seemed to hide this conclusion from me until yesterday.

But yesterday I was trying to fix all of the broken tests resulting from my file serving refactoring, and I was finding that, not surprisingly, I kept having these cached stat instances lying around — but *only* if the file hadn’t changed.  E.g., consider this code:


assert_events([], resource)
File.unlink(file)
assert_events([:file_created], resource)

Ignore, please, whether this is a good idea or what; the point is that the first line runs a transaction that results in a cached stat but no changes; and because there are no changes, there’s nothing to flush to disk; and because there’s nothing to flush to disk, ‘flush’ isn’t called; and because ‘flush’ isn’t called, the ’stat’ is lying around still.  Which means the next transaction uses the cached stat, but of course, reality has changed in the meantime.

So, I need something that will make it easy for my data to match the lifetimes I want.  I made this Cacher Module that purportedly solves this problem for me, but noooo, it solves a different data-lifetime problem:  I have a lot of initialization code that generally only runs once but ends up running many times during testing, so I needed a clean way to remove the initialized data after every test.  So, this module has a single, global boolean that defines whether a given chunk of data is expired or still valid.  That’s all fine and dandy for one-time configuration data, but it doesn’t work for transactions.

So, now I’m trying to enhance that module to support either the global expiration marker or a per-instance marker, so that I can have all of the resources use a timestamp in their catalog to determine whether their cached data is expired.

One of the hard problems here is that you don’t want to find yourself maintaining a global list of anything anywhere.  My first design for the Cacher module involved it keeping a reference to all the cached data, which would have made it easy to clear the cache but would have had lots of code accessing tons of global data; stupid.  Instead, everyone keeps references to their own data, and the only global data is the expiration marker.  This works great for global things.

But resources and catalogs aren’t global.  Even worse, I’m (reasonably) using an internal class to check expiration.  So, that internal class needs to have access to the catalog’s timestamp in order to figure out if its cached data is still valid.  This is automatically ugly — an instance you shouldn’t even need to know exists now needs access to a big collection of resources.  Yuck.  Without this, the internal class doesn’t have a reference to anything except the data it’s managing, but there’s just no escaping it needing access to that timestamp somehow, so you either give it a reference, or you pass it one every time you check for a value.

The *stupid* thing is that this isn’t the problem I want to solve.  I just want the old fileserving behaviour but now with gooey RESTfulness.  That, plus the fact that I’ve apparently decided that I can no longer use spackle and sheetrock mud during development means that I have to fix this even though it wouldn’t normally be on my critical path.  Yuck.

A Short Puppet History, pt. 2: Cfengine

Now that I’ve gone through the ISconf years (although it was really less than a year), it’s time to move on to how Cfengine affected Puppet.  There seems to be a pervasive belief that Puppet is an attempt to make a Cfengine++, and I’m hoping that this article will dispel that silly notion.

As mentioned previously, I’d concluded that ISconf wasn’t sufficient, because it was theoretically bogus (maintaining order didn’t guarantee you all that much), it precluded refactoring, and it didn’t actually make my sysadmin work easier, really — I was still writing tons of little shell scripts.  As I described it in my paper: “In choosing between ISconf and most other [configuration management systems], this is largely a choice between a tool which easily organizes work and a tool which makes the work itself easier.”

Order Matters

Given the situation at the time, and the fact that Cfengine’s author, Mark Burgess, was having a kind of war of words with the author of ISconf, Steve Traugott,  it made sense to look at Cfengine.  I want to step aside for a moment, though, and discuss this war of words.  The summary of the war is “order matters”, and when I hear that it’s like “where’s the beef” or “it has what plants crave” — it’s a simple phrase but one that brings up context, hilarity, and stupidity all at once.  Steve maintained that order matters when managing systems, and Mark theoretically maintained that it did not.  These respective beliefs were evident in that Steve’s tool, ISconf, was really just a means of guaranteeing order and nothing more, and Mark’s tool, Cfengine, made it ridiculously difficult to maintain order.

The truth, of course, is that order does matter, but only as a prerequisite, not the end-all be all.  You obviously can’t start a service if you haven’t installed its package yet, but there is such a thing as orthogonal services, and you definitely, definitely don’t want to build all of your systems with the assumption that every chunk of work requires every other chunk of work ever performed.

My hopefully-reasonable summary should not imply that their conversations were reasonable; they were not. It was an infantile and annoying conversation all around, and to me, the phrase “order matters” will always evoke laughter, pity, and a desire to drink heavily while spouting epithets. When I was first exposed to this conversation, I was an ISconf user (well, *the* ISconf user — one other person adopted it, and I suppose Steve used it, but…), so everyone assumed I was on Steve’s side, but I’m not much of an ideologue, and I certainly wasn’t committed that early.

Integrating Cfengine

Anyway. So, I decided to look at Cfengine.  It’s a completely different kind of tool than ISconf — it’s organized around what it calls “actions”, although none of them are verbs, for some reason.  These are things like files, shellcommands, processes, and many others.  The immediate, obvious difference between the two is that Cfengine is a tool focused on what you’re trying to do, and ISconf is a tool that just cares about in what order you do it.

The other thing about Cfengine is it has this whole “control” section that’s all about setting up variables and making decisions, and you can set booleans (which Cfengine calls classes) that can then be used to make decisions throughout the whole configuration.  I immediately imported a lot of the convoluted logic I had hidden in ISconf make files into Cfengine and saved myself a ton of headache; then I integrated the two tools, such that ISconf could take advantage of all of the knowledge and context that Cfengine had, and Cfengine could take advantage of all of the information I’d already input into ISconf.

This, of course, meant I was going to hell. I wrote an article describing my experiences with each tool, plus how I integrated them, and there were some interesting conversations as a result.  Initially, the integration was focused on not throwing away the work I’d done with ISconf, but over time, I stopped adding code to ISconf and largely just focused on Cfengine, and in the end, I found it was more effective to just do my work directly through Cfengine.

At the same time, I started a consulting company to focus on helping other companies with with configuration management problems, since so few organizations seemed to have a decent solution, and I was more interested in continuing to refine my solution than I was in moving on to more mundane sysadmin problems like backups or monitoring.

After a few months of consulting, though, I found that Cfengine could be painfully low-level.  It could do files, commands, and processes, but it couldn’t do users, groups, or packages.  Also, I was maintaining Cfengine configurations for multiple platforms, and it was a real nightmare managing Cfengine code that did the same thing in different ways, or even just used different paths.

Even worse, though, I found I couldn’t keep promises to my customers.  Cfengine often wouldn’t compile on a given platform across releases, I couldn’t consistently get bug fixes or refactorings accepted into the code base, and I had no ability to influence the direction of its development.  Mark Burgess was the main developer, and he was very defensive of any attempt to refactor significant parts of the code.  He also, somewhat notoriously, said he considered version control to be overhead, which meant we kept magically getting bug regressions.

Looking for other options

So, frustrated with Cfengine and its lack of a developer community, I started looking around for other options. I tried out Quattor, LCFG, SmartFrog, Bcfg2, psgconf, and probably more, but none of them seemed like they would allow the kind of extension and abstraction that I was looking for.  I was afraid I was going to have to make my own tool, but I really didn’t want to.  As an interim step, in the summer of 2004 I decided to fork Cfengine and fix some of its problems.  I called this fork cfng (it’s completely dead now).

One of the things that drove me most crazy about Cfengine was that it had 25 different syntaxes for its 33 or so different actions — ‘processes’ was *slightly* different from ’shellcommands’, for no good reason.  Really, there were all kinds of scary implementation decisions.  My fork was meant to fix these problems. Unfortunately, I never got it to work; it was just too much work pushing that much spaghetti C code around, at least for me.

Around the time I gave up on rewriting Cfengine, my friend Kent Skaar decided to go work for BladeLogic, and he somehow convinced me to join and them to hire me.  However, I was, for good reason, concerned about retaining the rights to ideas I’d already developed, so I took some time before joining to write a prototype roughly implementing the product I was thinking of building.  At the time, the product was code-named ‘Blink’.

The LISA Configuration Management Community

I have to make another aside here and mention that through this whole period I was attending the configuration management workshops at the USENIX LISA conference.  On the one hand, these were great workshops, because they were full of smart people talking about interesting problems, but on the other hand, they were just horrible.  It seemed that no one was interested in making a truly useful, simple tool, and there was this ridiculous, inane focus on theory in lieu of practice.  I was told multiple times that it just wasn’t possible to write a good tool until the theory was solved, and I should just wait until it was.  Any scientist could tell you that, in nearly all cases, theory comes from data, and data comes from wandering around randomly, so this theory-then-tool idea was just BS.

Over the course of my years in the workshops, I’d come to the conclusion that building some kind of resource abstraction layer was the key to building a great tool.  I reasoned that this layer would function as a means of abstracting the operating system and allowing the sysadmin to focus on the what rather than the how, and I figured the abstraction layer could be the first step in a real sysadmin tool stack.

My ideas were met with outright derision.  I was told the theory was utter crap, unworkable *and* stupid, and uninteresting to boot.  As time went on, the criticism from certain parties got downright ridiculous, to the point where half of why I built Puppet in the end was to prove these jackasses wrong.

I don’t think it was coincidental that I was the only person in the room out selling my services as a consultant, rather than sitting in a stable job and just working on config-mgmt a limited amount of time.  This sales requirement put a very different spin on how I thought about things, and my understanding of the requirement for simplicity and reuse seemed unique in the group.  While Bcfg2’s author has bragged that you can get an install up and running in as little as a few days, I’ve always said if it takes you more than an hour to do something useful with Puppet, I’ve screwed up.

So anyway, I’m going to these conferences, sharing my ideas, and getting absolutely nowhere.  Everyone in the room has his (yes, his) own tool, and no one’s really moving anywhere.  I’m feeling pretty insulted most of the time and getting pretty tired of people just categorically saying I’m wrong while being unwilling to listen to me or, really, even try other tools out (at that point, I was the only person who had downloaded and tried out every other tool in the group).

The Prototype

So, for all these reasons and more, I decided to see if I could make a prototype that had the functionality I was looking for.  I knew I wanted:

  • High-level resources:  Users, not useradd; packages, not apt-get; and hosts, not /etc/hosts.
  • Simple cross-platform naming: The ability to use different names for the same resource on different platforms; e.g., the ssh package or the location of the sshd configuration file
  • Easy extensibility: I wanted users to be able to add custom resource types.

Beyond that, there were some more specific bits I knew I wanted, but that was the main list.  When I started on this, I was a perl developer, so I tried it in that, but I just couldn’t conceive of how to implement the class relationships I was envisioning.  This was 2004, when everyone was hotting up Python, so I decided to give it a try, but Python just makes my eyes bleed.  No, it’s not the whitespace — that’s just silly, not painful.  It was things like ‘len’ being a function, rather than a method, and the fact that ‘print’ with a trailing comma behaves differently than without one.

I had a friend at the time who’d heard Ruby was cool (although never tried it himself), so I decided to give that a try, and in four hours I went from having never seen a line of Ruby to having a functional prototype of the resource abstraction layer.  Boom, I was off.

BladeLogic and Beyond

Now that I had the prototype and I was comfortable that I had code that outlined the ideas I was coming to the table with, I accepted the job at BladeLogic.  My wife was still working on her Phd in cancer biology, so we couldn’t move to Boston (where they are located); instead, I would get an apartment there and work there 2/3 or 3/4 of the time and work from Nashville the rest of the time.

My understanding of my role there was to help them design configuration management tools, but that didn’t seem to be why they actually hired me — they were far more interested in my helping to set up a test lab or some junk.  I was pretty impatient with the job, given that I was never seeing my wife, so I was pushing until it either became what I wanted or broke, and it only took 5 months for me to decide it wasn’t worth it and quit.

I went back home and took stock.  One of my main complaints about BladeLogic was that I didn’t think they were producing software that I would want to use or even recommend to others, yet I still thought there was a clear opportunity.  Cfengine had the widest deployment, but, well, it was a piece of crap.  No version control, horrible implementation, no marketing, no commercial backing, etc.

In addition to the opportunity, I thought I actually had some decent ideas, and I was pretty confident in my ability to make a living selling them. Yes, selling — I’m a very technical person, but I completely understand the value and necessity of selling my ideas, whether it be to colleagues, coworkers, employees, or customers.

So, in March of 2005, I decided to take my paltry savings and a small loan from family and start a software company focused on producing a better configuration management tool.  After realizing that there were already multiple software projects called ‘Blink’, and much hemming and hawing and thinking, I decided to call this project Puppet.

The next installation in this series will actually cover the history of Puppet itself, hopefully all the way to the present day.

LinkedIn and TripIt

As many know, LinkedIn has finally added support for applications, and one of the first applications they’ve added is TripIt:

TripIt integration on LinkedIn

TripIt integration on LinkedIn

TripIt is my very favorite travel-related web site — I forward all of my confirmations to them and they automatically build a schedule with all of the confirmation codes and everything.  I print a copy of this out, and I always have everything I need to know where and when to be on a trip, and I can always prove I have a reservation without relying on ‘net access.  It also makes it easy to manage all the trips I take, which is important since I traveled more than 75k miles this year.

I’m pretty excited about this integration - I’m hoping it will make LinkedIn a bit more useful, and add some Dopplr-like serendipity to my LinkedIn network.

I realize now that my excitement over this integration is a bit irrational; that’s most likely because my fondness for TripIt is a bit irrational — it makes travel organization trivial, they’re fabulous in response to feedback, and I just really like the product.

I’m keeping my Google Phone

Well, I’ve had my gPhone (aka Android phone aka T-Mobile HTC G1) for about ten days, and after using it a lot and playing with a couple of iPhones a few times, I think I’m going to keep the G1.  And on a side note, I’m making an attempt, from now on, to make this blog more conversational.  I’ve done a horrible job of importing how I talk into how I write here, and it’s both made the blog worse and made me less interested in writing.  Yay.

Fundamentally, the main reasons I’m keeping it are that I couldn’t see a huge differentiator pushing me toward the iPhone, I didn’t really want to switch from TMobile to ATT (TMobile will unlock my phones for me and has said they don’t mind tethering apps), and I like the more open nature of the gPhone.  Assuming someone actually makes a tethering app at some point, it could save me and everyone at my company about $60/month, since we’d otherwise need to buy a separate device to get constant ‘net access for our laptops.

Here are some things I particularly like about the gPhone:

  • The Status bar: I really like this.  I like one place for notifications and information, and a single consistent interface for all of them, along with my ability to either answer them or ignore them.
  • The Dialer Application: I think this is great.  I don’t know that it’s a ton different from the iPhone’s, but I really liked this version.  I liked the previous calls list, the favorites list, and easy searching for contacts.
  • The mid-call menu: I didn’t get a chance to try this out on the iPhone, but I loved this on the gPhone.  Press the menu button and you can enable/disable your bluetooth headset, switch calls, put someone on hold, and more.  Call switching and conference calling was astoundingly faster than doing so with any other phone I’ve had, which is pretty awesome considering how often I make conferences calls between myself, Andrew, and Teyo.
  • Task switching: You can hold the ‘home’ button down for a second or so to get a list of the last six applications you’ve used, and you can switch right to the application without having to go to the home screen.  On the iPhone, you always have to go to the home screen to get to another application.  Welcome to 1987, people — this is MacOS 6, but with no excuse.  Android also has a Task Switcher application that just switches across all installed applications; it mostly sucks, but it’s encouraging that task switching is one of the first problems attacked in the OS.
  • Notification lights: This seems like a small thing, but the phone has three small, colored LEDs; a green LED for message notification, a red light for low-battery, and an orange light for charging.  I really like these — they’re small enough that they don’t stab you like so many LEDs do these days, and they provide a great, simple way to know what’s going on with your phone, without having random vibrations every who-knows-how often.  I was using a friend’s iPhone, and it literally vibrated every three or four minutes without any indication why.  I’m assuming it was a notification I was supposed to track down, but there was no way to figure it out without going to the home screen and searching for red numers.
  • Home screen vs. App Management: Android has a home screen with three panes, and you can arrange them however you want — apps, links to URLs, etc.  It also has an applications tab pull with every app on the system, arranged heirarchically.  This is great because you can set up a subset of your applications on the home screen, arranged how you want, and then you can peruse the whole app list alphabetically.  The iPhone, on the other hand, only has the home screen — you add more apps, and it adds more panes.  You apparently can’t change the four “most common” apps on the bottom, and there’s apparently no easy way to browse the apps alphabetically.

The combination of app management and task switching go a long ways toward making this phone feel more like a real operating system on a phone, rather than the iPhone which feels more like a phone trying to be a real operating system.  It’s weird, because I know the iPhone has a real OS under there somewhere; it’s just not acting like one.

I kinda like the keyboard, although I don’t know if it’s that big of a difference for me (I’m hopefully never going to be much of an emailer with my phone), and I like how responsive the phone is.

There are some things I really don’t like about it, though.  Browsing is a generally crappy experience — the zoom thingie completely blows, in that it inconsistently accepts touches and it’s just a crappy interface in general, and it’s also not-quite-impossible to actually click the links you want.  However, using apps like  Google Reader works fine, and I expect it will only get better.  And, again, this isn’t what I mainly expect to use the phone for.  It’s fine for stop-gap, like sitting in the Doctor’s office waiting room; it’s just not something I’d want to do a ten day trip with.

I’m pretty concerned about the durability of the hardware; I could already store my credit cards between the sliding screen and the keyboard.  Hopefully I’ll be able to replace the phone as necessary for the first year, and by then I hope they’ve got it figured out.

I do really wish the phone supported multi-touch, and with it the multi-finger gestures like the iPhone pinch.

I also wish there were just a Quicksilver-like interface for the whole phone — give me a single gesture to bring up Quicksilver, and I’ll never go to the home screen again.

An Aside

This is neither iPhone nor Android, but it must be said.  What is up with how unimaginative people are being with the touchscreen support?  Why is it that the only way to interact with either of these things is directly touching visible objects, or a traditional keyboard?  Where are my full-screen gestures that I can define, where are my accelerometer-based navigation, where, basically, is anything that really takes advantage of the form factor and touchscreen to be different?

The gPhone has pretty cool gesture recognition for unlocking — you get a grid of nine dots and have to make a specific gesture to unlock the phone.  Why can’t this same theme be used for, well, everything?  I’d like global gesture support for shortcuts to my most common applications, for instance — a Z to open one app, a loop to open another.  I haven’t seen a single situation where I need to drag in multiple directions without lifting my finger, so I don’t see what it would interfere with.

Both of these phones basically suck for context and task management.  Each phone has a “back” button, where the iPhone’s is on-screen and the gPhone’s is physical.  What?  A back button?  Back buttons suck in browsers, why would anyone ever think they make sense as the primary navigational paradigm in, well, anything, ever?  Sure, if you’re stuck in a completely linear world, sure, but on a phone where I regularly use 5-10 applications a day, and could conceivably use 20 or more, a back button just doesn’t suffice.

It bugs the hell out of me that people aren’t taking the Wii as their example — do something different, something weird.  If people aren’t laughing at your ideas, then you’re not trying hard enough.

Cheers.