Shallow Thoughts : : Sep

Butterfly romance!

I was in the back yard pruning the star jasmine when something came buzzing through the air and smacked into my shoulder.

It turned out to be two skipper butterflies, locked in what I can only presume was an amorous embrace.

Dave got his camera and documented the scene: butterfly romance photos.

They stayed on my shoulder for another 20 minutes, imperturbable, while I continued with yard work.

Tags: nature, butterfly
[ 16:20 Sep 27, 2009    More nature | permalink to this entry | ]

Article: Building Your Own Linux Kernel, Part I

My latest article is up on Linux Planet: Building Your Own Linux Kernel, Part I.

"But aren't there a gazillion howtos already on the web on kernel building?" I thought so too. But when someone showed up on LinuxChix recently asking for help building her kernel, I went looking -- and all the howtos I could find were out of date (even the README in the very latest kernel gives instructions based on LILO, not GRUB).

More important, none of them offered help in that all-important question: How do I start with a configuration file I know will work?

My quick-and-dirty howto shows you how to take your distro's configuration file and build the latest mainstream kernel based on it. The next article will cover how to change that configuration and tune it for your own machine.

Tags: writing, linux, kernel
[ 10:45 Sep 25, 2009    More writing | permalink to this entry | ]

LCD monitor burn-in, revisited

Back in March I wrote about a burn-in problem I was seeing with my Dell S-IPS LCD monitor. I got varying reports on the web on whether this was likely to be a temporary or a permanent problem; so here's an update six months later.

The problem I noticed back in March was that my xchat window, always positioned at the same spot on the screen, was getting burned into the monitor. Against a blank white or grey screen, I could clearly see where that window's titlebar normally was, and rows of horizontal lines where the text was.

First, I changed my ways to avoid having windows in the same place all the time. I changed my window manager settings to remove most window placement settings, I removed directives to show any windows on all desktops, and a worked on developing a habit of moving windows around periodically to slightly different locations (I think I'll have my Firefox window on the upper right this afternoon). I don't really like that -- I guess I'm enough stuck in my ways that I like knowing that I can look to the upper left for web pages and the lower right for IRC -- but it's not that bit a deal.

And, happiness, my burned in xchat lines went away. My old bad behavior had not permanently burned in the pixels on my nice monitor.

But that's only part of the story -- because if you look at the photo from March, xchat is not all you see that's burned in. There's also the wavy stuff going across the lower 1/4 of the screen -- and that didn't correspond to any window I'd been running.

I thought maybe it was left over from some Windows wallpaper used by the monitor's previous owner. But none of the standard wallpapers on my Vaio's WinXP partition have this pattern. (What it reminds me most is the data I used to analyze from a cell-sorting machine in my first computer job. Somehow I suspect that's not the culprit.)

These patterns, unfortunately, are not going away. In fact, the ones along the top and bottom left edges are pretty clearly getting worse, and eventually, alas, I'll probably have to replace the monitor. But meanwhile, they vary a lot.

When I first turn on the monitor in the morning, most of the time I can't see the burn-in at all. After a long day of use, it's usually pretty obvious. In between, though, there's huge variation. Sometimes they appear after an hour of use; sometimes I can go most of the day before the burn-in starts becoming visible.

It doesn't seem to be particularly temperature sensitive, and it doesn't seem to vary much with which background image I'm using that day. Sometimes when I'm going to be away for a while, I display an all white screen -- I've read a few reports indicating that can help, and anecdotally I think it does. I should probably keep better statistics on temperature, background color and time to find out what's really affecting this. Maybe I could use it as a homework project in the new Linuxchix R/Stats course!

Tags: LCD, monitor, S-IPS, burn-in, image persistence
[ 12:47 Sep 23, 2009    More tech | permalink to this entry | ]

A new theory of orbital dynamics

This PG&E billboard just went up down the street from where I live.

"Solar Power: Making planets orbit and bagels toast."

And here all this time I'd been under the impression that orbits had mostly to do with gravity. Somehow I'd missed the influence of light pressure when writing my orbital software.

Or is the sun's gravitational influence considered a part of "solar power"? Can we look forward to the upcoming generation of gravitovoltaic solar cells?

Tags: humor, astronomy
[ 20:13 Sep 18, 2009    More humor | permalink to this entry | ]

GTK dialogs in GIMP (and updated wallpaper script)

I've been getting tired of my various desktop backgrounds, and realized that I had a lot of trip photos, from fabulous places like Grosvenor Arch (at right), that I'd never added to my background collection.

There's nothing like lots of repetitions of the same task to bring out the shortcomings of a script, and the wallpaper script I threw together earlier this year was no exception. I found myself frequently irritated by not having enough information about what the script was doing or being able to change the filename. Then I could have backgrounds named grosvenor.jpg rather than img2691.jpg.

Alas, I can't use the normal GIMP Save-as dialog, since GIMP doesn't make that dialog available to plug-ins. (That's a deliberate choice, though I've never been clear on the reason behind it.) If I wanted to give that control to the user, I'd have to make my own dialogs.

It's no problem to make a GTK dialog from Python. Just create a gtk.Dialog, add a gtk.Entry to it, call dialog.run(), then check the return value and get the entry's text to see if it changed. No problem, right?

Ha! If you think that, you don't work with computers. The dialog popped up fine, it read the text entry fine ... but it wouldn't go away afterward. So after the user clicked OK, the plug-in tried to save and GIMP popped up the JPEG save dialog (the one that has a quality slider and other controls, but no indication of filename) under my text entry dialog, which remained there.

All attempts at calling dialog.hide() and dialog.destroy() and similar mathods were of no avail. A helpful person on #pygtk worked with me but ended up as baffled as I was. What was up?

The code seemed so simple -- something like this:

    response = dialog.run()
    if response == gtk.RESPONSE_OK :
        pathname = pathentry.get_text()
        dialog.hide()
        dialog.destroy()
        pdb.gimp_file_save(newimg, newimg.active_layer, pathname, pathname,
                           run_mode=0)

In the end, GIMP guru Sven pointed me to the answer. The problem was that my dialog wasn't part of the GTK main loop. In retrospect, this makes sense: the plug-in is an entirely different process, so I shouldn't be surprised that it would have its own main loop. So when I hide() and destroy(), those events don't happen right away because there's no loop in the plug-in process that would see them.

The plug-in passes control back to GIMP to do the gimp_file_save(). GIMP's main loop doesn't have access to the hide and destroy signals I just sent. So the gimp_file_save runs, popping up its own dialog (under mine, because the JPEG save dialog is transient to the original image window while my python dialog isn't). That finishes, returns control to the plug-in, the plug-in exits and at that point GTK cleans up and finally destroys the dialog.

The solution is to loop over GTK events in the plug-in before calling gimp_file_save, like this:

    response = dialog.run()
    if response == gtk.RESPONSE_OK :
        pathname = pathentry.get_text()
        dialog.hide()
        dialog.destroy()
        while gtk.events_pending() :
            gtk.main_iteration()
        pdb.gimp_file_save(newimg, newimg.active_layer, pathname, pathname,
                           run_mode=0)

That loop gives the Python process a chance to clean up the dialog before passing control to GIMP and its main loop. GTK in the subprocess is happy, the user is happy, and I'm happy because now I have a much more efficient way of making lots of desktop backgrounds for lots of different machines.

The updated script, along with a lot more information on how to use it and how to set up tool presets for it.

Tags: programming, gimp, gtk
[ 23:21 Sep 15, 2009    More gimp | permalink to this entry | ]

Installing Flash on Linux, for Newbies

Dear Adobe: Please update your instructions when you update your install packages

I had a circus a few nights ago trying to help my mom get her flash plugin updated. Not because of anything she was doing; because Adobe's out of date instructions were just plain wrong.

It gave me more insight into why people say "Linux is hard to use" ... which has little to do with Linux, and everything to do with outside forces that seem to go out of their way to make things hard for Linux users.

See, Mom's Firefox auto-updated to a new version, which started whining about her flash version being insecure and telling her to update it. It pointed her to Adobe's site, get.adobe.com/flashplayer.

She went there and was presented with a long list of options for different types of download. She's on Ubuntu, so the Ubuntu deb might have worked -- but it might not, since she's running a Firefox from Mozilla.org rather than the one from Ubuntu. (Ubuntu's Firefox on Hardy was notoriously crashy, and she has enough problems with the Mozilla version crashing.)

I told her I usually use the tarball, and install it as myself, not as root. In the past, the flash installer has always been very good about noticing I'm not root and installing to ~/.mozilla/plugins. I didn't expect problems.

So she downloaded the tarball and tried to follow their instructions, which look like this:

1. Click the download link to begin installation. A dialog box will appear asking you where to save the file.
2. Save the .tar.gz file to your desktop and wait for the file to download completely.
3. Unpackage the file. A directory called install_flash_player_10_linux will be created.
4. In terminal, navigate to this directory and type ./flashplayer-installer to run the installer. Click Enter. The installer will instruct you to shut down your browser(s).
5. Once the installation is complete, the plug-in will be installed in your Mozilla browser. To verify, launch Mozilla and choose Help > About Plug-ins from the browser menu.

The first problem is "Unpackage the file." Honestly, how hard is it to give people a hint that "unpackage" means "type tar xf install_flash_player_10_linux.tar.gz"? As long as you're writing instructions anyway, why not tell people the actual command instead of expecting them to figure it out somehow?

"In terminal, navigate to this directory" -- if you know your user will be typing shell commands in a terminal, why not tell them to cd rather than expecting them to figure that out from "navigate"? (Mom figured that one out -- go Mom! -- but a lot of users wouldn't.)

Except -- OOPS! try following the instructions and you can't cd ... because it turns out the flash 10 "installer" doesn't contain a directory, or indeed an installer, at all. It's a tarball containing one file, libflashplayer.so.

Now, setting aside the question of why anyone would use tar to package a single file -- why not just make the file available for download and tell users where to put it? -- they give you no hint as to where this libflashplayer.so file is supposed to go. If you don't happen to know how Firefox sets up its plugins, you're out of luck.

Fortunately, I happen to know where the file goes. I told Mom to mv libflashplayer.so ~/.mozilla/plugins/ and all was well. But ... sheesh! With instructions like this on something as (unfortunately) widely needed as the Flash plugin, how can a newbie ever expect to get anywhere?

For newbies reading this, the real instructions for installing Adobe's flash 10 tarball are:

1. Download their file, which is named install_flash_player_10_linux.tar.gz
2. Open a terminal and cd to wherever you downloaded it, e.g. cd ~/Desktop
3. tar xf install_flash_player_10_linux.tar.gz
4. mv libflashplayer.so ~/.mozilla/plugins/
5. Restart firefox, make sure flash works, and (once you're sure, at your option)
   rm install_flash_player_10_linux.tar.gz

Tags: linux, help, newbie, flash
[ 23:53 Sep 13, 2009    More linux | permalink to this entry | ]

Article: Linux on Multicore Processors

Linux Planet requested an article on multicore processors and how to make the most of them. Happily, I've been playing with that anyway lately, so I was happy to oblige:

Get the Most Out of Your Multicore Processor: Two heads are better than one!

Tags: writing, linux, performance
[ 22:59 Sep 11, 2009    More writing | permalink to this entry | ]

Using apt-file to track down build errors

Someone was asking for help building XEphem on the XEphem mailing list. It was a simple case of a missing include file, where the only trick is to find out what package you need to install to get that file. (This is complicated on Ubuntu, which the poster was using, by the way they fragment the X developement headers into a maze of a xillion tiny packages.)

The solution -- apt-file -- is so simple and easy to use, and yet a lot of people don't know about it. So here's how it works.

The poster reported getting these compiler errors:

ar rc libz.a adler32.o compress.o crc32.o uncompr.o deflate.o trees.o zutil.o inflate.o inftrees.o inffast.o
ranlib libz.a
make[1]: Leaving directory `/home/gregs/xephem-3.7.4/libz'
gcc -I../../libastro -I../../libip -I../../liblilxml -I../../libjpegd -I../../libpng -I../../libz -g -O2 -Wall -I../../libXm/linux86 -I/usr/X11R6/include   -c -o aavso.o aavso.c
In file included from aavso.c:12:
../../libXm/linux86/Xm/Xm.h:56:27: error: X11/Intrinsic.h: No such file or directory
../../libXm/linux86/Xm/Xm.h:57:23: error: X11/Shell.h: No such file or directory
../../libXm/linux86/Xm/Xm.h:58:23: error: X11/Xatom.h: No such file or directory
../../libXm/linux86/Xm/Xm.h:59:34: error: X11/extensions/Print.h: No such file or directory
In file included from ../../libXm/linux86/Xm/Xm.h:60,
                 from aavso.c:12:
../../libXm/linux86/Xm/XmStrDefs.h:1373: error: expected `=', `,', `;', `asm' or `__attribute__' before `char'
In file included from ../../libXm/linux86/Xm/Xm.h:60,
                 from aavso.c:12:
../../libXm/linux86/Xm/XmStrDefs.h:5439:28: error: X11/StringDefs.h: No such file or directory
In file included from ../../libXm/linux86/Xm/Xm.h:61,
                 from aavso.c:12:
../../libXm/linux86/Xm/VirtKeys.h:108: error: expected `)' before `*' token
In file included from ../../libXm/linux86/Xm/Display.h:49,
                 from ../../libXm/linux86/Xm/DragC.h:48,
                 from ../../libXm/linux86/Xm/Transfer.h:44,
                 from ../../libXm/linux86/Xm/Xm.h:62,
                 from aavso.c:12:
../../libXm/linux86/Xm/DropSMgr.h:88: error: expected specifier-qualifier-list before `XEvent'
../../libXm/linux86/Xm/DropSMgr.h:100: error: expected specifier-qualifier-list before `XEvent'

How do you go about figuring this out?

When interpreting compiler errors, usually what matters is the *first* error. So try to find that. In the transcript above, the first line saying "error:" is this one:

../../libXm/linux86/Xm/Xm.h:56:27: error: X11/Intrinsic.h: No such file or directory

So the first problem is that the compiler is trying to find a file called Intrinsic.h that isn't installed.

On Debian-based systems, there's a great program you can use to find files available for install: apt-file. It's not installed by default, so install it, then update it, like this (the update will take a long time):

$ sudo apt-get install apt-file
$ sudo apt-file update

Once it's updated, you can now find out what package would install a file like this:

$  apt-file search Intrinsic.h
libxt-dev: /usr/include/X11/Intrinsic.h
tendra: /usr/lib/TenDRA/lib/include/x5/t.api/X11/Intrinsic.h

In this case two two packages could install a file by that name. You can usually figure out from looking which one is the "real" one (usually the one with the shorter name, or the one where the package name sounds related to what you're trying to do). If you're stil not sure, try something like apt-cache show libxt-dev tendra to find out more about the packages involved.

In this case, it's pretty clear that tendra is a red herring, and the problem is likely that the libxt-dev package is missing. So apt-get install libxt-dev and try the build again.

Repeat the process until you have everything you need for the build.

Remember apt-file if you're not already using it. It's tremendously useful in tracking down build dependencies.

Tags: open source, linux, programming, debian, ubuntu
[ 11:25 Sep 06, 2009    More linux | permalink to this entry | ]

On the difference between techies and non-techies

It's so easy as a techie to forget how many people tune out anything that looks like it has to do with technology.

I've been following the terrible "Station fire" that's threatening Mt Wilson observatory as well as homes and firefighters' lives down in southern California. And in addition to all the serious and useful URLs for tracking the fire, I happened to come across this one: http://iscaliforniaonfire.com/

Very funny! I laughed, and so did the friends with whom I shared it. So when a non-technical mailing list began talking about the fire, I had to share it, with the comment "Here's a useful site I found for tracking the status of California fires."

Several people laughed (not all of them computer geeks). But one person said,

All it said was "YES." No further comments.

The joke seems obvious, right? But think about it: it's only funny if you read the domain name before you go to the page. Then you load the page, see what's there, and laugh.

But if you're the sort of person who immediately tunes out when you see a URL -- because "that's one of those technical things I don't understand" -- then the page wouldn't make any sense.

I'm not going to stop sharing techie jokes that require some background -- or at least the ability to read a URL. But sometimes it's helpful to be reminded of how a lot of the world looks at things. People see anything that looks "technical" -- be it an equation, a Latin word, or a URL -- and just tune out. The rest of it might as well not be there -- even if the words following that "http://" are normal English you think anyone should understand.

Tags: tech, humor
[ 21:48 Sep 01, 2009    More misc | permalink to this entry | ]