In the meantime but to some extent on a related note, I’m disabling all comments here.  Mostly it’s because the spammers have gotten so far ahead of the spam processors that I’ve gotten 10x spam vs comments in the last couple of years (which probably says more about my lack of commenters, but meh).  It’s also because people tend to reply on twitter or their own blogs, rather than on the actual post.

So, if you want to comment, drop me a line on twitter.  And feel free to harass me for never posting.

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.

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.

ISconf

Puppet was heavily influenced by two tools, but almost more importantly, it was heavily influenced by what I couldn’t do with those tools.  I attended LISA in 2001, where I saw Steve Traugott give his talk on automating infrastructures.  I was impressed enough that I convinced my then-company to bring him in for a week of consulting.  During that week, he convinced me to give a tool he’d written, ISconf, a try.

ISconf is an insanely simple tool — it’s just a way to apply a set of make stanzas in the same order every time.  Steve’s theory was that the only way to get consistency from your computers was to do exactly the same thing on them every time.  So, he wrote up everything he did as a make stanza, and then built ISconf as a way of executing them in a consistent order.

Or at least, that was the theory.  When I got his code for ISconf, it was, em, not terribly usable.  It was written in shell and perl, with shell calling perl calling shell calling shell calling perl then exploding.  I had already bought into the basic theory, but I couldn’t see how to his code (which he was calling ISconf 2), so I rewrote it with some pretty significantly different functionality but following, as closely as possible, his basic theory. Naturally, I called this ISconf 3. On the ISconf web site, you can read more of this history, along with Steve’s relatively bitter version of how this portion of the history goes. (Incidentally, I wrote the majority of the content on that site.)

I won’t go into the detail of how it worked, except that all of the actual work happened with make stanzas.  This meant that, really, ISconf was a huge collection of very small shell scripts. This seems straightforward, until you start thinking about things like package installation — the command to install one package is almost the same as that to install a different package, which meant that a lot of my make stanzas had a lot of duplication.

To make my life easier, I started abusing the hell out of make, switching to gmake, and starting to make simple rules using ‘%’ to avoid duplication:

pkg/%:
...

I can’t even remember how this worked, thankfully; I just know you can extract what the ‘%’ matches and use it to choose the package name when installing a package.

This worked great for packages, since in most cases (and all the cases I was dealing with), you can easily specify a package by name.  It didn’t work so well for things like cron jobs, though — you’ve got between 1 and 6 fields, and the last field can have spaces and all manner of crap.  So, I started maintaining a separate file of all of these cron jobs, written in a perl Data::Dumper format, with each cron job having a unique name.  Then my make stanza would just refer to the arbitrary name I’d chosen.

This at least made ISconf more usable, but there were still a lot of problems.  You can read my writeup from around then in my LISA paper, but there were some serious problems with using ISconf.  First and foremost, it wasn’t a real solution — it was just a way to organize billions of little shell scripts, and as most anyone knows by now, I’m not so fond of shell scripts.  Also, the whole theory was bogus — there’s just no way you can guarantee consistency, not through order or any other mechanism.  Your dev servers and test servers can never be exactly the same, so stupidly replaying the same scripts in order also can’t guarantee sameness.  As a ridiculous example, I’ve seen printers that don’t work if their hostnames have an odd number of characters, and there’s just no way you can test this kind of case.

Beyond the theoretical problems, though, there were even worse practical issues.  You were supposed to never touch any code once it’d been deployed to a machine, because otherwise you couldn’t guarantee consistent behaviour, but this is just silly, because it means that you can never refactor code or change how you manage a given aspect of your system.  Imagine a solution that required immediate calcification of anything you ever did — once you deploy it, it’s deployed like that forever, even if it’s stupid.  No reason to learn; even worse, you get punished for learning, because you just add a new system to maintain every time you learn anything.

So, I wanted the ability to refactor my solutions, and ISconf couldn’t deliver that, so I started looking for something else that could.  Check back for part 2 to see what I did next.

One thing some people apparently don’t realize is that Puppet couldn’t have been created without Reductive Labs — there’s no way I would have had the time or motivation to create Puppet without a company devoted to funding its development.  All of the money that Reductive Labs makes goes back into funding Puppet, mostly in the form of development, marketing, and community management (although less of the latter, recently).  Almost all of the money I spend on marketing is in the form of conference speaking, so don’t think I’m spending big coin on TV spots or anything, but these conferences have been *huge* sources of community growth.

Strangely, I’ve heard complaints that I’m focusing too much on the company and not enough on the project, and as a result the product is suffering.  I find this strange because the project doesn’t pay my bills, feed my children, or buy my beer, the company does, and without those things, the project itself couldn’t exist.  If, instead, I had taken some corporate sysadmin job, I’d have been spending maybe 5-10 hours a week on Puppet, instead of between 10 and 60 hours a week like I’ve been doing for the last three and a half years.  This, I think, is the thing that people tend to forget about open source — yes, you can make money doing open source, but in doing so you almost always put yourself in conflict between making money and writing code.

The key is that Reductive Labs doesn’t make money when I write Puppet code, it makes money by helping people with existing code; yet, my business model is based on plowing that money into writing code, on the assumption that the code will make the product better, increasing the market, and hopefully allowing both project and company to grow.

This gets especially complicated when my own goals show up.  I’ve always seen Puppet as the first step toward building a significantly enhanced toolchain for system administration, and it was always my goal to use Puppet as a launchpad to having Reductive Labs fund other great projects.  (This phrasing is important — I need to make money to do development full time, so Reductive Labs (currently) needs to make money to fund that development.)  This is why I’ve always resisted billing us as “the Puppet company” — I don’t want to be pigeonholed in the event we have other successes, which I hope we will.

These longer-term goals are also why I’ve avoided joining other companies and just doing part-time development on Puppet for them.  Leaving aside that none of them would have considered hiring me until I’d already had significant success with Puppet (which puts us in a strange Catch-22, where they’d only offer to hire me once I’d shown I didn’t need their help), no one has ever expressed an interest in hiring me to build a product group, which is what I’m trying to do here.

Going back to finding that balance, one of the things I’ve foolishly allowed myself to do in the last year is get too caught up in fixing bugs, rather than adding functionality or doing interesting refactoring.  It’s amazing how disheartening and depressing it is to spend all of your days fixing bugs in code you wrote, all the while struggling to make enough money to pay people to help you fix those bugs.  Having more people at the company has helped bring focus to my efforts and those of the company as a whole, and having many more people involved in the project has helped bring focus to the needs of the project.

I think that’s about all I have to say on the subject right now — a presentation of the problem, a statement of the status quo, and a wandering finish.  Now that I’ve introduced the topic, though, I hope to be able to post more lucidly and usefully about it in the future.

Generally, of course, I’m basically split between trying to build my company and trying to maintain Puppet.  It’s an interesting struggle, because the company exists to support Puppet, and Puppet exists because of how I’ve been able to fund its development through the company.  I don’t think this struggle is ever going to go away, and it’s going to get even more interesting as I do other projects.

The company is going pretty well — we’ve get three employees (me, Teyo, and Andrew), and we’re apparently managing to get paid enough to make it through.  We are providing support, consulting, training, and some custom development, all focused on Puppet and how best to use it.

The product, however, is doing even better.  Its popularity seems to be exploding, and just in the last few months we’re getting a ton of developer contributions.  Every week I hear from a company looking for employees with Puppet expertise, and I now rarely meet people who are in the industry and haven’t heard of Puppet.

We’ll be releasing 0.24.6 in the next week or so, and even though it’s only been three months since the last release, this one is looking to be a really large release with a bunch of new bug fixes but even more new functionality.  We’re also making good progress on the mythical 0.25 release — all of the necessary plumbing is done, and it actually seems likely that it’ll be out this year.  Then we’ll just have to struggle with maintaining stable and dev releases at the same time, which will be an interesting challenge.

Ok, that’s our short update.  Now I’m just going to act like I’ve been posting frequently for a while, and I’ll just post what I can, when I can.  One thing I’ve decided to do is to more clearly make this “my” blog as opposed to the “Puppet” blog.  This means I’m going to try to talk more about my other interests, like random technology, cycling, entrepreneurship, and other stuff.

Talk to you soon, hopefully.

My blog has been in need of transitioning for the last few months (it was being hosted by Spike and he needed the server back), and it’s taken me this long to get my act together (although I’ve been a bit busy in the mean time).

I’ll hopefully be posting more often again, and I also hope to play with the many widgets available for WordPress, so you might find a bit more context available now.