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:
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
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.
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)
(mark-whole-buffer)
(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?
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 linux.com
story,
or in Linus'
actual email in the Desktop_architects list, where you can also
follow the rest of the thread.
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
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.
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.
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.)
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:
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.)
![[Nautilus with Fibonacci spiral]](/blog/images/NautilusCutawaySpiral.jpg)
![[RSS feed]](https://shallowsky.com/images/logos/rssicon-25x25.png){kind=small}
![[Twitter]](https://shallowsky.com/images/logos/twitter-bird-white-on-blue-25x25.png){kind=small}
![[envelope]](https://shallowsky.com/images/logos/envelope-25x25.png){kind=small}
