Category: Miscellaneous

Tiny Robot, Nice Lens

Here’s a toy I picked up recently in New York at the Moma Store:

It’s a little robot you build yourself from cleverly designed rolls of paper. He’s called a Piperoid (he’s apparently called "Jet Jonathan") and is from Piperoid Japan.  In the US, Piperoids seem to be available only from the MOMA Store.

This was a fun toy to build: the build process was logical, didn’t take too long, and required just enough effort to feel satisfying.  No glue is needed.  The joints are movable and we’ve had fun with that.  He’s about 5 inches tall.

This shot also demonstrates another toy, the Nikon AF Nikkor 50mm f/1.8D lens that Danek lent me to try out on my Nikon D40.   This picture was shot in dim incandescent light, although I did add a white LED point source to throw shadows– due to color correction it appears somewhat blue in this picture.  I originally tried to shoot at f/1.8 (wide open, with the shallowest depth of field, and allowing the most light) but the depth of field is really narrow and I couldn’t get enough of him in focus.  Focus was also tough because this lens is manual focus on the D40.  In the end I had to stop down to f/2.0 and settle for a slightly longer exposure time.  I needed to use my gorillapod wrapped over the back of a chair because the exposure was 1/5 sec.  To post-process I simply did an auto-normalize and and auto-white-balance in The Gimp.  For kicks, I tried the same shot on the kit lens (The AF-S DX 18-55mm f/3.5-5.6G) that comes with the D40: to get a similar shot I needed about a 1.6 second exposure, and the results weren’t nearly as nice.  For just over $100 USD, the 50mm lens is a good deal, but I sure wish Nikon would bring out some auto-focus prime lenses fully suited to the D40.  Thanks Danek!


I’m taking a few days off following the OpenSolaris 2008.05 release to attend a wedding in New York.  Here are a couple of better shots from Manhattan, where I spent the weekend:

The Roasting Plant, an innovative coffee shop/roastery; everything is automated and all of the machinery was designed by the owners.  Beans swirl through the store in pneumatic tubes (click for larger versions):

Four seconds at Grand Central:

MOMA (from the Eliasson retrospective):

The view from Central Park:

I haven’t yet had time to even do a basic editing pass over these.  The MOMA shot needs a bit of effort, I think.  I like the Grand Central shot quite a bit, but I really wish I’d had image stabilization.  At 100% the fine details are blurry.  I had a gorillapod, but the shot was tough to get, as people’s footsteps on the stairway I was shooting from caused a fair amount of jiggle.

Finding bugs in python code, using DTrace

I have spent a lot of time in recent months helping the IPS project.  This week I integrated usability improvements, and tracked down two different performance problems.  The first was notable because I think it’s the kind of thing that would have been hard to find without DTrace.   Here’s a writeup I did, cribbed from the bug report:

While doing work on IPS I discovered a large number of system calls being made
during the "creating plan" phase of a fresh installation of the
‘redistributable’ cluster of packages.

I used the following crude dtrace script to track down the problem:

#!/usr/sbin/dtrace -Fs

/copyinstr(arg1) == $$2/

/copyinstr(arg1) == $$2 && self->t/


printf("calls: %d", calls);

No points for elegance but it works.

Successive guesses allowed me to narrow this down to the get_link_actions()
routine. Here’s an example of its system call impact during the following

# rm -fr /tmp/foo
# export PKG_IMAGE=/tmp/foo
# pkg image-create -a foo=http://ipkg.eng /tmp/foo
# pkg install -n redistributable

I ran the D script as follows:

$ dtrace -s /s4pyfunc.d `pgrep client` get_link_actions

And once the command was done, got this output:

CPU     ID                    FUNCTION:NAME
0 2 :END calls: 880

brk 26
stat64 774400
close 775280
fcntl 775280
fsat 775280
fstat64 775280
getdents64 1553200

So here we can see that something is amiss– this routine is the source
of 4.7 million syscalls.
Here’s the code:

        def get_link_actions(self):
""" return a dictionary of hardlink action lists indexed by
target """
(a) if self.link_actions:
return self.link_actions

d = {}
for act in self.gen_installed_actions():
if == "hardlink":
t = act.get_target_path()
if t in d:
d[t] = [act]

self.link_actions = d
return d

When Bart and I first looked at this, it seemed by inspection to be working as
designed– the first time the routine is called, we populate a cache, and
subsequently the cache is returned. At some point Bart went "Aha!" and we
realized that the problem here was that the comparison at (a) wasn’t working
right, and that, for a not-yet-installed image, the link_actions dictionary is
exactly equal to {}, the empty dictionary. That evaluates to "false" in
python. So we always think that we haven’t yet filled out the link_actions
cache, and go to fill it. That sends us into gen_installed_actions(), which is
expensive. It seems to get more and more expensive as we accumulate more
manifests, as well.

So, while there are exactly zero link actions we need to worry about, we rescan
all manifests for every new manifest we evaluate.

This is a situation which will crop up most often with zones, since that’s the
place we’re most likely to create new images from scratch.

The fix is very simple: set self->link_actions to None initially (in the object
constructor), and change the comparison at (a) to test against None explictly.

Having fixed this, the impact of get_link_actions is:

CPU     ID                    FUNCTION:NAME
0 2 :END calls: 880

stat64 3
close 4
fcntl 4
fsat 4
fstat64 4
getdents64 8

Or, basically, nothing. In some informal testing I got these numbers
with ptime(1):

real     1:26.730
user 1:10.988
sys 11.624


real     1:12.932
user 1:02.475
sys 6.361

Or about a 19% improvement in real time. And quite a bit in sys time. Not a huge win, but not too shabby either.

I used the same technique to find a similar bug in another part of the code, but alas, Danek had already found the same bug, so I can’t claim it.

Solaris 8 Migration Assistant (Etude) Launch, live from CEC

I was lucky enough to get to attend CEC (Sun’s Customer Engineering Conference) in Las Vegas, although not lucky enough to win anything at the casino.  So now, I’m sitting in the CEC System Launch session, and John Fowler is launching the new T5120 and T5220 systems.  Thankfully there is ample wifi here in the hall.

The best news for me is that John just announced the product I’ve been working on, the Solaris 8 Migration Assistant (or Project Etude) and showed how it can help with migration and consolidation activities.  A FAQ has been posted over here.  That’s not to say that you can download and use it now.  But very soon!  I think that these new systems in combination with the Solaris 8 Migration Assistant will make a very tempting combination for our customers who are still running Solaris 8 on older hardware.  You can upgrade and reduce your service costs, rack space, cooling, power costs, and get greater performance and bandwidth.

A Trip to the Faire

Today was the first day of the first Maker Faire, put together by O’Reilly’s MAKE Magazine.
Here’s my photo gallery of my wanderings through the Faire.
It’s very late so I’ll just note my principle impressions:

  • Kids love this stuff. It was nice to see so many parents and their children engaged in what is basically science education.
  • The Faire had a lot to offer– it was bigger and more interesting than I’d expected
  • Sun had a booth, and the dedicated folks from Sun Labs were showing off an impressive series of Sun SPOT demos.

If you live in the Bay Area, I recommend that you take a look tomorrow (Sunday, Apr 23).

50! Why I like Bloglines

Subscribe with Bloglines

Ok, the obligatory ‘blog about ‘blogging. Today I checked my bloglines account. If you’re feeling a little overwhelmed by the quantity of blogs out there, bloglines can really help to tame the chaos, providing you a centralized place to sift through the new entries in the blogs you read. I like it because, as a web service, I can log into it anywhere in the world, on any machine. It’s nice to have stuff centralized. There’s also a nice Firefox biff which can notify you of new entries ready for consumption!

One feature I especially like is that bloglines allows you to see how many other bloglines users have subscribed to a particular blog. This of course means that you can watch the stats on your own blog as well. So today I reached fifty bloglines users who are reading my blog; that makes me able to guess that my real readership must be quite a bit higher than that. While I’m dwarfed by some of our blogging giants like Bryan (132) and Eric (114), I’m feeling good about fifty.

An additional cool feature is that a bloglines user can choose to share his or her subscriptions with the world; this means that I even know who some of my 50 subscribers are (surely there is some sort of neat social networking/visualization project to be done here!). So, if you’re a bloglines subscriber– share your subscriptions! To do so, visit the “Account” link, go to “Account Settings” and choose “Yes, Publish my Blog/Blogroll.”

In other news, I’ve posted notification of Solaris Express builds to

Three Cheers for Firefox’s “Web Developer”

Wow. If you ever have to spend time writing HTML or CSS, have I got a treat for you. Check out the Web Developer Extension written by Chris Pederick.

This thing is great because it lets you reveal the structure of your page, including anchors, blocks, deprecated elements, image meta-data, edit the CSS of a page, validate HTML, CSS, and other characteristics, and make good choices about accessability. It also includes handy buttons which take you to the relevant standards. It’s thoughtfully organized, and has attractive, colorful icons.

Probably the two features which really made my jaw drop are Display Topographic Information which re-renders your page to show you the level of nesting using topographic-map style colors; and View Style Information, which converts your mouse cursor to a crosshair. As you mouse over different page elements,
it shows you the “path” to the object. So on this page, when you mouse over The View from the Moon in the title, you see:

html > body > table > tbody > tr > td.title > div > div.website_title

in the status bar. Clicking on the element pops up a new tab which contains the style information
pertinent to that element. So if you ever wondered “how did they do that?” or “what do I have to do to the CSS to affect this element?” it’s now trivial to figure out.