Nautilus annoyance

When using gnome with ion3 as the window manager, it makes sense to have nautilus not draw the desktop. Unfortunately, that gconf setting causes nautilus to die and restart repeatedly (https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/325973), which one can notice by watching the nautilus PID increase every fraction of a second or so. Until the bug is fixed, it's simplest to turn desktop drawing back on, and just hide the window that's produced. Ugh.

Night photography

Some results from the recent "Big city nights" houston photography meetup (http://www.meetup.com/HoustonPhotography/):

Photowalk pictures

Sarah and I spent the morning of 18 July at the Houston zoo as part of Scott Kelby's worldwide photowalk (http://worldwidephotowalk.com/).

Here's some pictures (Sarah took most of these pictures):









.

Frodo

Six months old, and far too cute.

Photo taken by Sarah Goodyear.

Migrated to blogger

I seem to have better things to keep me occupied these days than keeping my pyblosxom blog spam-free, so I'm moving my blog into the cloud and letting Google take care of things for me. The gdata python package made migrating the blog fairly painless, except for moving the comments. There haven't been so many comments, so I just migrated them by hand.

Tethered capture with gphoto2

It turns out that it's fairly easy to use a linux box to
take pictures using my Nikon D50 and display the results
to the screen:

$ gphoto2  --capture-image --interval 10 -F 2 --hook-script showpic.sh

The above takes two frames ten seconds apart (making a D50 into
a very expensive webcam). Alternatively, I could use the following
to use the camera normally but have the pictures show up on the
computer screen:

$ gphoto2 --capture-tethered --hook-script showpic.sh

The "hook script" is what does the actual display after each shot:

$ cat showpic.sh
#! /bin/bash

self=`basename $0`

case "$ACTION" in
    init)
    echo "$self: INIT"
    # exit 1 # non-null exit to make gphoto2 call fail
    ;;
    start)
    echo "$self: START"
    ;;
    download)
    echo "$self: DOWNLOAD to $ARGUMENT"
    eog ${ARGUMENT} &
    ;;
    stop)
    echo "$self: STOP"
    ;;
    *)
    echo "$self: Unknown action: $ACTION"
    ;;
esac

exit 0

Pretty darn cool!

Thought for the day

In drobbins' post today, http://blog.funtoo.org/2008/02/refocus.html,
he offers the following advice:

If a project doesn't meet your needs, I encourage you to create your own
project. If you do, I recommend keeping the development team small,
tight-knit and independent. I think this will maximize your productivity
as well as your overall enjoyment of collaborative and open development.

Is that the future for Gentoo? It's already happening to some extent.
The next generation of the (in)famous Gentoo init system is now
an independent project (http://roy.marples.name/openrc). Paludis
(http://paludis.pioto.org/) and pkgcore (http://www.pkgcore.org/trac/pkgcore)
are independent package managers designed to work with Gentoo's
portage tree. Drobbins independently releases x86 and amd64
stage tarballs (http://www.funtoo.org/linux/). Anybody who
wants to can create their own overlay repository such as those
at http://overlays.gentoo.org/.

Internally, though, Gentoo works pretty much the same way. Take
a look at
http://www.gentoo.org/proj/en/index.xml?showlevel=3
sometime. Most Gentoo developers spend their time toiling
on a handful of specific projects. Yet that specialization inside
Gentoo seems to contribute to the feeling that Gentoo lacks any
sort of coherent direction. Would things really be that different
if those projects were independent, external projects?

I've no idea. Thoughts / comments welcome.