Shallow Thoughts : : Feb

Akkana's Musings on Open Source Computing and Technology, Science, and Nature.

Wed, 28 Feb 2007

Random Wallpaper

I was talking about desktop backgrounds -- wallpaper -- with some friends the other day, and it occurred to me that it might be fun to have my system choose a random backdrop for me each morning.

Finding backgrounds is no problem: I have plenty of images stored in ~/Backgrounds -- mostly photos I've taken over the years, with a smattering of downloads from sites like the APOD. So all I needed was a way to select one file at random from the directory.

This is Unix, so there's definitely a commandline way to do it, right? Well, surprisingly, I couldn't find an easy way that didn't involve any scripting. Some shells have a random number generator built in ($RANDOM in bash) but you still have to do some math on the result.

Of course, I could have googled, since I'm sure other people have written random-wallpaper scripts ... but what's the fun in that? If it has to be a script, I might as well write my own.

Rather than write a random wallpaper script, I wanted something that could be more generally useful: pick one random line from standard input and print it. Then I could pass it the output of ls -1 $HOME/Backgrounds, and at the same time I'd have a script that I could also use for other purposes, such as choosing a random quotation, or choosing a "flash card" question when studying for an exam.

The obvious approach is to read all of standard input into an array, count the lines, then pick a random number between one and $num_lines and print that array element. It took no time to whip that up in Python and it worked fine. But it's not very efficient -- what if you're choosing a line from a 10Mb file?

Then Sara Falamaki (thanks, Sara!) pointed me to a page with a neat Perl algorithm. It's Perl so it's not easy to read, but the algorithm is cute. You read through the input line by line, keeping track of the line number. For each line, the chance that this line should be the one printed at the end is the reciprocal of the line number: in other words, there's one chance out of $line_number that this line is the one to print.

So if there's only one line, of course you print that line; when you get to the second line, there's one chance out of two that you should switch; on the third, one chance out of three, and so on.

A neat idea, and it doesn't require storing the whole file in memory. In retrospect, I should have thought of it myself: this is basically the same algorithm I used for averaging images in GIMP for my silly Chix Stack Mars project, and I later described the method in the image stacking section of my GIMP book. To average images by stacking them, you give the bottom layer 100% opacity, the second layer 50% opacity, the third 33% opacity, and so on up the stack. Each layer makes an equal contribution to the final result, so what you see is the average of all layers.

The randomline script, which you can inspect here, worked fine, so I hooked it up to accomplish the original problem: setting a randomly chosen desktop background each day. Since I use a lightweight window manager (fvwm) rather than gnome or kde, and I start X manually rather than using gdm, I put this in my .xinitrc:

(xsetbg -fullscreen -border black `find $HOME/Backgrounds -name "*.*" | randomline`) &

Update: I've switched to using hsetroot, which is a little more robust than xsetbg. My new command is:

hsetroot -center `find -L $HOME/Backgrounds -name "*.*" | randomline`

So, an overlong article about a relatively trivial but nontheless nifty algorithm. And now I have a new desktop background each day. Today it's something prosaic: mud cracks from Death Valley. Who knows what I'll see tomorrow?

Update, years later: I've written a script for the whole job, randombg, because on my laptop I want to choose from a different set of backgrounds depending on whether I'm plugged in to an external monitor or using the lower resolution laptop display.
But meanwhile, I've just been pointed to the shuf command, which does pretty much what my randomline script did. So you don't actually need any scripts, just

hsetroot -fill `find ~/Images/Backgrounds/1680x1050/ -name '*.jpg' | shuf -n 1`

Tags: , ,
[ 14:02 Feb 28, 2007    More programming | permalink to this entry | ]

Sun, 25 Feb 2007

Slide Presentations in HTML and JavaScript

I've used HTML for presentations -- instead of open office, or magicpoint, or powerpoint -- for several years now.

I like using HTML because I can put my slides online and people can view them directly, without needing to download a whole presentation and run some kind of special viewer for it. It's also lightweight (the files are fairly small), I get to write in a language I already know pretty well, and Firefox is already installed on my laptop and works nicely as a presentation tool.

There are plenty of packages to generate HTML slides -- like S5. But they weren't very well developed when I first got interested in HTML presentations, so I rolled my own Javascript-based slideshow and have been gradually tweaking it ever since.

I've never tried to package up my presentation system; my setup is pretty simple (one javascript file, one CSS file, and the set of HTML slides), and I figure there are enough prepackaged setups around that there's no need for another one.

But I have been meaning to put a sample presentation online which describes how the system works and how to copy and adapt it. So here it is, a presentation about making presentations: Slide Presentations in HTML and JavaScript.

[ 18:12 Feb 25, 2007    More tech | permalink to this entry | ]

Mon, 19 Feb 2007

Emacs with Long Lines

I don't like composing text documents in word processors like Open Office. Call it a quirk if you like, but I find them intrusive: they take up a lot of CPU and memory, they take up a lot of window space for stuff I don't need while I'm writing (all those margins and rulers and toolbars and such) making it hard to compare two documents at once, and they tend to have intrusive focus behavior (like popping windows to the front when I didn't ask for it).

So when I need to write a paper (or a book), I prefer to compose in a text editor like vim or emacs, something that won't get in the way of my train of thought. When it's mostly written and ready to format, then I start up the big heavyweight word processor and import or paste the text into it.

(For those of you who think I'm insane and should just live in Open Office all day, the same problem comes up for people who do a lot of composing for web applications, such as an online blog, gmail, a web forum, or a wiki, and for people who want a choice of editor for their GUI mail app.)

Fine, but that introduces a problem. See, text editors have a fixed line width (typically 80 characters, though of course you can adjust this) and paragraphs are usually separated by blank lines (two newline characters together). Word processors expect each paragraph to be one long line for the whole paragraph, and line breaks are used as paragraph breaks (but you only want one of them, not two). How do you reconcile these two models in order to paste plaintext from an editor into a word processor?

Several years ago when I first encountered this problem, I investigated solutions in both vim and emacs (oddly enough, I'm an editor agnostic and equally happy in either one).

For vim, I never did find a solution to the problem, so that settled the editor choice for me. Perhaps some vim expert can let me know what I missed.

For emacs, I found longlines-mode, a hack which lets long lines appear to be wrapped while you're editing them even though they're really not. Apparently Wikipedia has this issue and some Wikipedia contributors use longlines-mode too. (That page also has brief notes on alternate solutions.)

I used longlines-mode for a long time, and it's more or less functional, but I was never really happy with it. It turns out to have some pretty annoying bugs which I was forever needing to work around, and it doesn't solve the blank-lines problem -- you still need to delete blank lines before or after pasting.

Yesterday I was working on an essay for a class I'm taking and decided I'd had enough of longlines-mode and wanted a better solution. I poked around and chatted with the nice folks on #emacs (hoping that someone had come up with a better solution, but no one knew of one) and based on some ideas they had, I came up with one of my own.

My new method is to edit the text file normally: line breaks where they look good, blank lines to separate paragraphs. When I'm finished writing and ready to paste, I run M-x wp-munge, which calls up a very simple function I wrote and added to my .emacs:

;; For composing in emacs then pasting into a word processor,
;; this un-fills all the paragraphs (i.e. turns each paragraph
;; into one very long line) and removes any blank lines that
;; previously separated paragraphs.
(defun wp-munge () "un-fill paragraphs and remove blank lines" (interactive)
  (let ((save-fill-column fill-column))
    (set-fill-column 1000000)
    (fill-individual-paragraphs (point-min) (point-max))
    (delete-matching-lines "^$")
    (set-fill-column save-fill-column) ))

So simple! Why didn't I think of doing it that way before?

Tags: ,
[ 21:10 Feb 19, 2007    More linux/editors | permalink to this entry | ]

Sat, 17 Feb 2007

Linus vs. GNOME, part deux: Linus Sends Patches

Remember a bit over a year ago when Linus Torvalds slapped GNOME for removing all their configuration options and assuming a "users are idiots mentality"?

Here's the latest installment.

Linus, challenged to "start a constructive dialog" by using GNOME for a while then giving a talk on his experiences, went them one better: he sent in patches to fix the usability problems he experienced.

An excerpt from his posting to the Desktop_architects list:

I've sent out patches. The code is actually _cleaner_ after my patches, and the end result is more capable. We'll see what happens.

THAT is constructive.

What I find unconstructive is how the GNOME people always make *excuses*. It took me a few hours to actually do the patches. It wasn't that hard. So why didn't I do it years ago?

I'll tell you why: because gnome apologists don't say "please send us patches". No. They basically make it clear that they aren't even *interested* in fixing things, because their dear old Mum isn't interested in the feature.

Do you think that's "constructive"?

and, later,
Instead, I _still_ (now after I sent out the patch) hear more of your kvetching about how you actually do everything right, and it's somehow *my* fault that I find things limiting.

Here's a damn big clue: the reason I find gnome limiting is BECAUSE IT IS.

Linus is back, and he's pissed. Go Linus!

Read more details in the story, or in Linus' actual email in the Desktop_architects list, where you can also follow the rest of the thread.

Tags: ,
[ 21:05 Feb 17, 2007    More linux | permalink to this entry | ]

Autologin under Upstart

The simple auto-login without gdm which I described a year ago stopped working when I upgradeded to "Edgy Eft". As part of Ubuntu's new "Upstart" boot system, they've replaced /etc/inittab with a new system that uses the directory /etc/event.d.

There's a little bit of documentation available, but in the end it just came down to fiddling. Here's how it works:

First, use the same /usr/bin/loginscript you used for the old setup, which contains something like this:

#! /bin/sh
/bin/login -f yourusername

Then edit /etc/event.d/tty1 and find the getty line: probably the last line of the file, looking like

respawn /sbin/getty 38400 tty1
Change that to:
respawn /sbin/getty -n -l /usr/bin/loginscript 38400 tty1

That's it! If you want to run X (or anything else) automatically, that works the same way as always.

Update: This changed again in Hardy. Here are the details. And then changed again in Karmic Koala: the file has moved from /etc/event.d/tty1 to /etc/init/tty1.conf.

Tags: , ,
[ 13:37 Feb 17, 2007    More linux | permalink to this entry | ]

Thu, 15 Feb 2007

Logitech Cordless Presenter

I got a nifty new toy: a Logitech Cordless Presenter.

I've been watching some of the videos from LCA2007, and I like how some of the speakers made their presentations smoother, and avoided being tied to standing next to their computer, by using remote slide-changing gizmos. It wouldn't help for my GIMP presentations, since those are usually live demos, but I do give other types of talks.

I didn't find much on the web about remote presenters and Linux, and wasn't at all sure whether or how they worked. As usual with hardware, the only way to find out is to buy one and try it.

As it turns out, it works just fine, so I wrote up a review with details.

Tags: ,
[ 15:34 Feb 15, 2007    More linux | permalink to this entry | ]

Thu, 08 Feb 2007

The Fibonacci Spiral and the Nautilus

or, don't believe everything you read

I've been working on a short talk on Fibonacci numbers for a friend's math class.

Back when I was in high school, I did a research project on Fibonacci numbers (their use in planning the growth of a city's power stations), and for a while I had to explain the project endlessly, so I thought I remembered pretty well what sorts of visuals I'd need -- some pine cones, maybe some flower petals or branching plants, graphics of the golden ratio and the Fibonacci/ Golden Spiral, and some nice visuals of natural wonders like the chambered nautilus and how that all fits in with the Fibonacci sequence.

I collected my pine cones, took some pictures and made some slides, then it was time to get to work on the golden spirals. I wrote a little GIMP script-fu to generate a Fibonacci spiral and set of boxes, then I went looking for a Chambered Nautilus image on which I could superimpose the spiral, and found a pretty good one by Chris 73 at Wikipedia. I pasted it into GIMP, then pasted my golden spiral on top of it, activated the Scale tool (Keep Aspect Ratio) and started scaling.

And I just couldn't get them to match!

[Nautilus with Fibonacci spiral]
Nautilus image credit: CHris73 on Wikimedia Commons

No matter how I scaled or translated the spiral, it just didn't expand at the same rate as the nautilus shell.

So I called up Google Images and tried a few different nautilus images -- with exactly the same result. I just couldn't get my Fibonacci spiral to come close.

Well, this Science News article entitled Sea Shell Spirals says I'm not the only one. In 1999, retired mathematician Clement Falbo measured a series of nautilus shells at San Francisco's California Academy of Sciences, and he found that while they were indeed logarithmic spirals (like the golden spiral), their ratios ranged from about 1.24 to 1.43, with an average ratio of about 1.33 to 1, not even close to the 1.618... ratio of the Golden Spiral. In 2002,John Sharp noticed the same problem (that link doesn't work for me, but maybe you'll have better luck).

As the Science News article points out,

Nonetheless, many accounts still insist that a cross section of nautilus shell shows a growth pattern of chambers governed by the golden ratio.

No kidding! Google on fibonacci nautilus and you'll get a boatload of pages using the chambered nautilus as an illustration of the Fibonacci (or Golden) spiral in nature. It's not just the web, though -- I've been reading about nautili as Fibonacci examples for decades in books and magazines. All these writers just pass on what they've read elsewhere ... just like I did for all those years, never actually measuring a nautilus shell or trying to inscribe a golden spiral on one.

Now do a Google image search for the same terms, and you'll get lots of beautiful pictures of sectioned nautilus shells. You'll also get quite a few pictures of fibonacci spirals. But none of those beautiful pictures will actually have both the nautilus and the spiral in the same image.

And now I know why -- because they don't match!

(Happily, this actually may be a better subject for my talk than the nautilus illustration I'd originally planned. "Don't believe everything you read" is always a good lesson for high schoolers ... and it's just as relevant for us adults as well.)

(Slides from the talk I wrote start here: The Rabbit, the Nautilus and the Pine Cone.)

[ 22:15 Feb 08, 2007    More science | permalink to this entry | ]

Wed, 07 Feb 2007

Udev Tidbits Picked Up at LCA

A couple of udev tips I picked up at LinuxConf, mostly from talking to folks in the hallways:

I'd been having trouble getting my laptop to read its built-in memory stick since upgrading to Ubuntu Edgy. It's basically the same problem I described in an earlier article: the machine boots, sees the built-in reader with no card there, and udev creates /dev/sda but not /dev/sda1. Later, I insert a memory stick, but the reader (like so many other USB-based flash card readers) does not generate an event, so no new device is created.

In that earlier article, the solution was to change the udev rule that creates the device and add something like NAME{all_partitions}="stick". The all_partitions tells it to create /dev/stick1, /dev/stick2 etc. up through the possible maximum number of partitions. (It would be nice to limit it just to /dev/stick1, but there doesn't seem to be any way to do that.)

Unfortunately, in edgy, the udev rules have been rewritten to be a lot more general, and adding {all_partitions} wasn't working. But LinuxConf gave me two solutions to this problem:

First, I was able to pester one of the hal developers about hal's annoying mandatory polling. (This is the official Ubuntu solution to the problem, by the way: if you let hald wake up twice a second to poll every device on the USB bus to see whether anything new has been added, then you'll get that /dev/sda1 device appearing. I wasn't the only one at the conference, I was happy to find, who was unhappy about this hald misbehavior. It got mentioned in at least two other talks as an example of inefficient behavior that can eat batteries and CPU, and a questioner during the hal talk echoed my opinion that the polling should be made optional for those of us who don't want it.)

Anyway, I asked him what hald does to create the /dev/sda1 device once it sees a card. It turns out that touch /dev/sda causes udev to wake up and re-check the device, and create any new device nodes which might have appeared. Hurrah! That's a much cleaner workaround than sudo mknod.

But at breakfast a few days later, I found myself sitting next to a udev expert. He took a look at the file I'd created, /etc/udev/rules.d/memstick.rules, and after a few minutes of fiddling discovered what it was missing: a crucial ACTION=="add" directive which hadn't been required under the old system. The working line now looks like this:

KERNEL=="sda", ACTION=="add", OPTIONS=="all_partitions", NAME{all_partitions}="stick"

Tags: , ,
[ 22:14 Feb 07, 2007    More linux | permalink to this entry | ]

Fri, 02 Feb 2007

Sydney Photos

Too many pictures! Choosing a subset to put on the web is always a daunting task, and no doubt I don't narrow down the selection quite enough and still upload too many photos. But there was so much interesting and scenic stuff to see around Sydney!

So here they are, my Sydney photos, with some annotations which were previously intended to be blog entries. (Though I'm sure I'll have more to say about Australia once I sort through the notes I made at the time.)

Tags: ,
[ 20:31 Feb 02, 2007    More travel/sydney | permalink to this entry | ]