The Angry Dome

Snow Pea!

Jeremy — Wed, 26 May 2010 20:41:09 -0400

I asked Alix of arixystix.com to make a Plants vs Zombies Snow Pea for me (as a gift to my wife). He came in today, and he's totally rad; check him out!

From

My Morning Jacket

Jeremy — Wed, 12 May 2010 11:18:55 -0400

I don't usually go to many live concerts (maybe 3 or 4 a year), so it's a bit of an oddity that two of my favorite bands have been in town within the past two weeks, and I've managed to see both of them.

First up: My Morning Jacket.

From My Morning Jacket

This is a band I've been watching for the past couple of years; their first performance on Austin City Limits piqued my interest with songs mostly from 2005's "Z," and their later performance featured songs from 2008's "Evil Urges." I found the latter to be especially impressive, and afterward I went back through their earlier albums to find solid but... well, rather less interesting music. This is a band that has evolved and improved with each album, so in a way I found their back catalog a bit of a disappoint.

Anyway, they're on tour, and their RDU stop was in the Koka Booth Amphitheatre in Cary. I've now seen three concerts in that venue, and my feelings about it are... mixed.

MMJ's performance itself was stellar, as I expected it would be having seen them execute two nearly flawless performances on ACL. They started off a bit slow with their "classic" material, ramping up to a pretty beefy set that included probably half of the songs from Z or Evil Urges. Jim James is quite a showman, flaunting a cape worn in several odd manners throughout the show; if his voice wasn't so completely out of this world, you might imagine the cape trick to be a bit bizarre, but somehow it all seems to work.

Unfortunately, a couple of things about the concert bothered me. For one, this place was filled with drunks. I mean, EVERYWHERE. There were 20ish kids all over the place; smoking pot, drinking, talking loudly in that I'm-too-drunk-to-modulate-my-voice manner, tripping over each other, and paying absolutely no attention to the band. Why are you guys here? Is MMJ so popular that people who don't care about the music show up just for street cred?

I think part of the issue may be Koka Booth itself. Our "seats" were rather lousy, being stuck back in the lawn. It's not as bad as the cheap seats at Walnut Creek (which are so far away you can't even *see* the performers without looking at the giant TV), but they're a long way away. And while Koka Booth is an attractive stage, their audio was very, very quiet to my ears; a fact that effectively amplified the noise of the crowd in comparison to the music. Some venues crank the volume till your ears bleed, and I'm not asking for that, but... maybe if it was just a bit louder, these kids wouldn't be so distracting.

I got the distinct impression that the real fans were close to the stage, where they got both a good view and, presumably, better companionship.

The net result was a bittersweet experience; as much as I loved seeing James and the crew live, and as awesome as the band was, I couldn't help but be disappointed by the environment. I'm pretty much resolved to never sit in the cheap section at Koka Booth again.

The photographer is dead; long live the photographer

Jeremy — Thu, 15 Apr 2010 15:22:01 -0400

Technology is a marvelous thing. At its best, it enables people to express themselves, to do things that had once been impossible or impractical; but as it does so, the wizards of the old domain find that their arcane knowledge loses value dramatically.

Consider, if you will, the photographer.

Initially, photography was a purely technical exercise, which required not only technical expertise but the possession of costly and cumbersome machinery. There were very few wizards, and everything they did was magic.

As the 20th century progressed, things began to change. 35mm cameras were available in a (relatively) affordable form, and the value proposition shifted. Operating and owning the machine was no longer an impenetrable barrier to entry; people could actually do so in their own homes. They could capture photographs of their own lives.

Of course, there was still magic to it: even though a home user could afford to take photos, the costs were still significant, and the technical skill required to operate consumer-grade devices was still decidedly non-trivial. Technology had facilitated the notion of an "amateur photographer," but an "amateur photographer" was, himself, still something of a wizard.

For the utter non-wizard, there arose "point and shoot" and instant cameras. Anybody who wanted to take a picture was eventually able to do so; but, even so, these devices were still cumbersome, and for any larger prints one still needed at least an amateur wizard.

In parallel to the proliferation of photographic equipment developed a new notion: that of photography as art. It's undeniable that some people have a gift in this respect, some special capacity to capture a specific moment, framed a certain way, optimally composed to elicit a certain response. Entire schools of study were devoted to this art form, and the photographer became more than a technical wizard, he also became viewed as an artist.

It's astounding, then, to watch the extent to which technology has changed the equation. It is true that every advance in the film era (and there were many) opened the gates a little wider, but the real revolution has come from the digital age.

I own a Sony A700, which is a fully digital SLR. This is a device that would have been completely unfathomable 15 years ago, and the notion of such equipment as a mass market consumer product would have been equally unfathomable as recently as 7 years ago. Think about how significant this is: within a mere 15 years, we've gone from something that was almost unimaginable at any cost, to something that almost any middle class enthusiast can find a way to afford.

The readily available Digital SLR has effectively killed photography as technical wizardry. Gone are the physical machinations inherent to film processing. Gone is the wait between capture and development. Gone is the limitation of sharing an image only through a physical object. Even gone is the required expertise and ridiculously specialized equipment required to create images which can be printed at poster quality.

Compared to what came before, this machine is so magical that anybody who touches it becomes a wizard.

I feel a bit for the purely technical career photographer, who strikes me as the equivalent of a gas station attendant as self-serve fuel pumps are developed. His specific form of wizardry is devalued, and his craft has become a commodity. The truly exceptional photographers (who have a knack for consistently finding a powerful image) will always remain in demand, but just being a guy with a camera who knows how to use it is no longer enough to make a living.

One can lament the plight of the technician photographer, but society as a whole clearly wins in this bargain. The notion of "photography as art" is now not only nearly universally recognized, but is also nearly universally accessible, and we currently witness the creation of photographic images the likes and volume of which would have been just as unimaginable as my camera 20 years ago. Artists no longer must emerge as a subset of the small pool of technical wizards, but from the massive pool of... well, virtually everybody who can post a picture online.

The notion of photographer as a technician is nearly dead, but the photographer as an artist? He's more alive than ever; and he is everybody.

Why does my browser have a wrench menu?

Jeremy — Wed, 14 Apr 2010 14:34:41 -0400

I'm using Google Chrome more and more. In addition to my earlier gripe about password saving, there are various other perplexing design decisions. To me, none is more odd than Chrome's menu icons.

For Linux or Windows builds, Chrome/Chromium has no traditional "File/Edit/Tools/Whatever" menu headers, and instead uses a couple of icons on the toolbar:

Google apparently hates the old style menu bar, and rightfully so, since it steals valuable screen real estate from the in-browser apps that it thinks are the future of computing.* Google decides they want nothing to do with it in Chrome, but instead of creating something new (like MS has done with its "Ribbon"), they take those same old menu items and bury them into two "toolbar menus" represented by icons: a "rectangle with a triangle in the upper right corner" icon, and a "wrench" icon.

Right there, some alarm bells are going off. What is a rectangle icon? Is that the page? A document? What the hell is a wrench for? I've never used a wrench on a computer (well, there was that one time...). Based on its usage in other applications I can guess it means advanced settings or... something... right?

(Incidentally, Sun servers have a "wrench" light on them, which indicates they need... an oil change, I guess?)

So, say you're a user staring at a Rectangle menu and a Wrench menu. Under which menu would you expect to find "Developer" menu options? Under which menu would you expect to open a new tab? (I'm aware that you can cheat by looking at my screenshot. Feel free, if that makes you feel better).

Answer: New tab is under wrench, developer is under rectangle. Clear as mud, right? Never mind that "wrench" normally means something like "tinkering" or "settings" or "change oil," and that the "rectangle" menu kinda looks like an empty document. We're in the google world now, it makes perfect sense!**

Of course, all those nasty menu items must go somewhere, and it's not exactly obvious where "somewhere" should be. Google probably figures they can just give the user a couple of obscure icons and let them work it out by the process of elimination. This is probably a valid assumption, but it doesn't make the icons themselves any less perplexing.

Bottom line: apparently, Google has solved the problem of incoherent menu bars - with incoherent toolbars. So... yay?

* To be clear, I'm no File/Edit/Tools/Whatever menu apologist. That's a dated UI paradigm that doesn't map well to many modern real world scenarios; for example, Firefox's "File" menu contains such gems as "Work Offline." What does that have to do with a file? And why is "Print" in the file menu of a web browser? I'm printing a web page, not a file, right? Why is "Find" in an "Edit" menu? I'm not editing anything!

** In case you're curious, these icons actually do represent logical groupings, but good luck guessing what they are by icon alone. The "rectangle" menu contains actions limited in scope to the current document (well this is, actually, a lie - for example the "zoom" options impact all chrome processes - however this is the way the menu is conceived). The "wrench" option is a sort of "Meta" menu, responsible for managing chrome as a whole.

Puppet Array Concatenation

Jeremy — Mon, 22 Mar 2010 17:45:55 -0400

One of puppet's design goals is to be legible and useful to non-programmers. This is a laudable objective; not all sysadmins know how to write code, or are interested in doing so. However, this sometimes makes it necessary to... work around the limitations of the language.

Prime annoyance to myself: concatenating arrays for use in templates.

There's only one way in puppet language to concatenate arrays, and that's using the += operator on an array that was defined in a higher scope. Since puppet variables are immutable by design, this itself is actually a bit of chicanery: the += operator expands the variable from a higher scope, appends the data on the right side of the operator to that, and creates a new variable in the current scope with the same name as the one from the higher scope.

Sound confusing? Well, it is a bit. Here's an example of what it looks like:

$sshusers = [ "bob", "sally" ]
class ssh::accounts {
$sshusers += [ "tim", "thelma" ]
}

Within the scope of the ssh::accounts class, "sshusers" will be created as a new local variable, which expands to [ "bob", "sally", "tim", "thelma" ], and can no longer be modified. The original "sshusers" variable in the higher scope has not been modified.

So there you have it. That's how you append arrays in puppet. And that's the *only* way you can append to arrays in puppet.

At first, it might not be evident just how limiting this is. But consider the case that you have a lot of groups of users, defined in variables, and you want to use them all as elements in a single array:

$sysadmins = [ "bob", "sally" ]
$users = [ "tim", "thelma" ]
$dbas = [ "kip", "jim" ]

This is where things get nasty.

So, we know our += trick, but that can only combine *two* arrays at a time, so the only way to get all that junk into a single array is to chain += to get the mega-array we want. We now have a construct like this:

$sysadmins += $users
$dbas += $sysadmins
$sshusers = $dbas

Well, that works, but what if we want to get at only the DBAs for another template or definition? What if we want one definition that uses $sysadmins and $dbas, but another that uses $users and $sysadmins?

Basically, += does make this technically possible, but it makes it ugly. Wouldn't it be better if we could combine an arbitrary number of arrays in a single statement?

As far as I know, while there is no way to concatenate more than two arrays in puppet, you can still combine them into a single variable, like so:

$allusers = [ $dbas, $users, $sysadmins ]

All right, so this should trigger some warning bells. In a normal language, allusers would be an array which contains 3 other arrays. In puppet, though, there's not really a notion of nested arrays anywhere within the DSL itself; using $allusers as a variable in puppet definitions will work as if all the nested arrays have been expanded into a single array, which is what we really want.

For all practical purposes, within puppet's DSL, arrays that contain multiple sub-arrays function as if they are a single array containing all elements of the sub arrays.

Notice a very important qualification in my statement: "within puppet's DSL." This works fine when you're working within the puppet configuration itself, calling definitions, realizing users, etc; but if you try to use such a combined array in a template, it suddenly turns into a nested array again.

I find this duality very confusing; within the DSL, my variable is, in every way that I can interact with it, a single array of 6 strings. But if I try to use this array in a template, all of a sudden it's composed of 3 nested arrays which are in turn composed of 2 strings each.

Here's an example. Say you'd like to construct an sshd_config "AllowUsers" line in a template, which grants access to all of our users. AllowUsers should look like so:

AllowUsers bob sally tim thelma kip jim

Given that, you might define $sshusers like to combine your 3 arrays into a single variable:

$sshusers = [ $dbas, $users, $sysadmins ]

And call an ERB template that looks like:

<% sshusers.each { |i| -%>
<%= i + " "-%>
<% } ->

If sshusers is really an array of strings, this will do what you want: print out each element of the array followed by a space. But that's not what we get if we've combined our 3 smaller arrays, as we did above:

err: Could not retrieve catalog from remote server: Error 400 on SERVER: Failed to parse template ssh/sshd_config_new.erb: can't convert String into Array at /etc/puppet/modules/ssh/manifests/init.pp:79

That's not a very descriptive error (pointing out only the line in which the template is called), but it gives us a clue as to the type conversion problem at the root of our issue. What's happening here is that string concatenation fails since i is not a string. If you omit the '+ " "' stuff and run this template just printing 'i' as you iterate through the array, you see a list of all 6 items all bunched together. But the second you try to manipulate each element of the array, you realize that it's actually operating on 3 arrays, not 6 strings.

Bottom line is: you cannot combine more than two arrays in puppet to form an array of strings for use in a template, except by chaining += statements.

You can sort of work around this in some ways. One option would be to pass multiple variables to your template and use conditionals in the ERB to handle them properly. Thus, you have users1, users2, users3,... - but that leaves us with a rather unfortunate hack. Sure, it's fine for a small number of entries, but how many do you want to support? Wouldn't it be better if we could just get a darn array of strings?

Well, here's the hack I finally came up with. Embedded in my ERB, I declare a function to "flatten" these nested arrays. It drills down into the sub-arrays, iterates over them, and dumps each individual item into a single new array, which it returns:

<% def walkarrays(a)
c = []
if a.class == Array
a.each { |b|
c.concat(walkarrays(b))
}
return c
else
c << a
end
return c
end -%>

And instead of directly using my variable as above, I use walkarrays:

<% walkarrays(sshusers).each { |i| -%>
<%= i + " "-%>
<% } ->

Now, what do I get:

AllowUsers bob sally tim thelma kip jim

Success!

So, here's the thing - I'm convinced that there must be a better way to do this. I want somebody to google this post and tell me the right way to do what I want to do, because this is simply way too hard. Keep in mind that I use the ssh config as only an example; there are many other instances where I would want to accept an array and operate on each item in a template. I'm not out to solve ssh, I'm out for a generic solution that lets me do what I describe.

Is the design notion that I should be writing my own types and functions, rather than be using templates for such things at all? And if so, isn't that at odds with the puppet DSL's KISS design philosophy which has lead to this situation to begin with?

Shooting The Moon

Jeremy — Mon, 01 Mar 2010 09:27:58 -0500

Here's the moon, a waxing gibbous from Saturday night; read on for details.

From Nature

My gear: Sony A700, Minolta 500mm f/8 Reflex (a fixed aperture catadioptric lens), tripod.

I found getting good shots more difficult than I had expected. I'm relatively new to photography and while I understand the basics, trying to shoot the moon pretty much causes all those automatic bells and whistles on your camera to become useless.

For starters, the metering system isn't very useful; if you leave it on matrix or center weighted with a lens of this length, it's going to blow out highlights badly due to all the black in the frame. Spot metering is closer to right, but it's still sketchy. The best technique I found so far is going full on manual exposure.

I found that the best results were with shutter speeds in the 1/125 range at ISO 200 (at least, this was the best when the moon was about halfway between the horizon and directly above - it should put off more light the higher it is in the sky). Incidentally, this isn't far off from the "sunny 16" rule, which makes perfect sense when you think about it; the moon is not a source of light in and of itself, rather it's reflected sunlight, so it's logical to use the calculation based on a sunny day. Sunny 16 underexposes by about 2-3 stops in my tests, due to the impact of atmosphere.

Now 1/125 second is going to be difficult to handhold with a 500mm lens. When hand holding, you need the ISO jacked up to around 1600 or better to get shutter speeds high. I try to avoid going that high if I can, so I used a tripod and longer exposure.

Automatic white balance is equally sketchy. It actually did OK sometimes, but it was hit or miss. You either need to set the WB manually, or just plan on fixing it in post processing (I chose the latter).

Now, depending on how accurate your exposure is, you have some work to do in software. The JPEG engine on my A700 did a really poor job with contrast, so I used RAW. I use ufraw and the GIMP; at 1/125 second all I really needed to do was bring up the black point to enhance contrast on the moon's surface. If you underexpose (as I did in this sample) you have to bring the white point down as well.

I had to use the GIMP and ufraw for this since Picasa's contrast adjustments were inadequate. "Auto contrast" is a disaster, but worse is that Picasa "guesses" some initial EV values when using RAW, and those guesses were already clipping highlights. It's not even possible to bring these back down to proper levels within Picasa!

I also applied some unsharp mask (.4 as the value) in the GIMP. I think I'm hitting the limitations of the lens in terms of resolving power, and it just can't fill the A700's entire 12MP sensor. This is another good reason to try and avoid high ISO, as USM will sharpen noise if it exists.

So anyway... that's shooting the moon! It's not hard when you know how to do it, but it took me a bit of time to learn.

Schneier on Airline Security

Jeremy — Thu, 31 Dec 2009 09:37:53 -0500

I rarely use this site to simply post links, but Bruce Schneier has an excellent article on the security theater of the TSA and other governmental organizations. As he says:

When people are scared, they need something done that will make them feel safe, even if it doesn't truly make them safer. Politicians naturally want to do something in response to crisis, even if that something doesn't make any sense...

Our current response to terrorism is a form of "magical thinking." It relies on the idea that we can somehow make ourselves safer by protecting against what the terrorists happened to do last time.

Schneier is one of the most respected experts in security - electronic or otherwise - and when somebody of his stature speaks out on these issues it gives me some hope that change might be possible.

Not much, mind you.

Google Chrome has no Master Password

Jeremy — Thu, 17 Dec 2009 16:52:15 -0500

I've been using Chrome recently, since they've finally released betas for both OS X and Linux.

By and large, it's a great product. It's fast, lightweight, and it has a very minimal UI. I'm nearly ready to throw firefox away and switch for good (in fact, I have switched on my netbook, where Chrome's advantages are paramount).

I'm not switching on my primary system, though. Why? Well, it turns out that Chrome has no facility to store passwords and encrypt them with a master password.

I mention this limitation not because it's overly interesting from a technical perspective, but because I find the Chrome team's process of repeatedly punting on bugs fairly amusing. Firefox's master password feature is certainly no panacea - indeed, if you care about security greatly, you would never store passwords at all - but it's better than nothing. It prevents casual access to stored passwords, and allows a user to be fairly certain that if they forget to lock their workstation a passerby will not then be able to immediately harvest all their credentials.

But reading through the comments in the Chrome bug tracker, it's clear that the engineers completely discount this use case. They claim (rightfully, of course) that an attacker with physical access to a system would then have the ability to gain much of the information stored therein (via a keylogger or other mechanisms) regardless of whether the browser utilized a master password.

They're right, but they're missing the point. Sure, physical access makes it possible for an attacker to gain information by compromising system integrity, but in the real world this isn't the person you're most likely to need protection from. The encrypted password file, combined with a master password, provides nearly complete protection from the most likely enemy: an attacker of opportunity who would casually grab your credentials if it was easy enough, but is not willing to risk detection by manipulating your system.

Chrome on Linux currently stores passwords plaintext on the filesystem, without any encryption. How this is deemed superior to Firefox's master password feature - which encrypts stored passwords using 3DES in CBC mode - is beyond me.

The old saying goes that an illusion of security can be worse than no security at all, which is the argument that the Chrome engineers use to downplay the utility of this feature. But Firefox's mechanism provides more than a simple illusion - it really does make it exceptionally difficult for an attacker to get your passwords, even if they have acquired the file. Contrast with Chrome's technique of providing no security at all, and I'm still going to cast my lot with Firefox on systems where I store passwords.

T-Rex plus T-Rex

Jeremy — Thu, 15 Oct 2009 10:04:51 -0400

I find Dinosaur Comics to be one of the funnier things I've seen on the internets. It's great, and you should read it.

In homage, or something, I've been generating a random 2-panel combination of comics. It's actually sometimes quite funny, and I'm posting the best results to a wordpress blog.

Anyway, check it out!

Left 4 Dead

Jeremy — Fri, 01 May 2009 09:53:18 -0400

I finally got a chance to play Left 4 Dead multiplayer last night, and man... it's a lot of fun.

In some ways the game reminds me of Serious Sam - fast, furious, straightforward. L4D has a bit more depth to it, but it also has a of purity of concept that just makes it work so well. There's no fluff here, no needless complexity - you and 3 buddies simply kill zombies, and lots of them.

The awesome B-movie horror styling and the cheesy one-liners from the characters are just icing on the cake.

L4D is on sale for $23.99 for the next few days. If you don't already own it, you should pick up a copy.